本帖最后由 siyzhang 于 2015-7-16 16:33 编辑
以下是使用第二种方法（RFC2833）的详细介绍
当前对于DTMF事件的传送有三种途径：
1. In-band 带内
2. RFC2833
3. SIP INFO消息
一般来说，第一种和第二种方法都需要支持。
对于第二种方法，SDP使用audio/telephone-event或audio/tone媒体类型。详情查看RFC4733（RFC2833的升级）。
以下是使用第二种方法（RFC2833）的详细介绍
SIP中检测DTMF数据的方法：SIPINFO、RFC2833、INBAND
1）SIPINFO
为带外检测方式，通过SIP信令通道传输DTMF数据。没有统一的实现标准，目前以Cisco SIPINFO为标准，通过SIPINFO包中的signal字段识别DTMF按键。注意当DTMF为“*”时不同的标准实现对应的signal=*或signal=10。SIPINFO的好处就是不影响RTP数据包的传输，但可能会造成不同步。
2）RFC2833
为带内检测方式，通过RTP传输，由特殊的rtpPayloadType即TeleponeEvent来标示RFC2833数据包。同一个DTMF按键通常会对应多个RTP包，这些RTP数据包的时间戳均相同，此可以作为识别同一个按键的判断依据，最后一包RTP数据包的end标志置1表示DTMF数据结束。另外，很多SIP UA 包括IAD都提供TeleponeEvent的设置功能如3CX Phone，Billion-IAD，ZTE-IAD等默认的TeleponeEvent都为101，但可以人为修改，这时要求在进行RFC2833 DTMF检测之前需事先获取SDP协商的TeleponeEvent参数。
3）INBAND
为带内检测方式，而且与普通的RTP语音包混在一起传送。在进行INBAND DTMF检测时唯一的办法就是提取RTP数据包进行频谱分析，经过频谱分析得到高频和低频的频率，然后查表得到对应的按键。在选择压缩比很高码率很低的codec，比如G.723.1和G.729A等，建议不要使用INBAND模式，因为INBAND DTMF数据在进行复杂编解码后会产生失真，造成DTMF检测发生偏差或失败。
一．IP电话传送DTMF的方式
DTMF就是双音多频，我们日常生活中拨打电话的过程中经常会用到，如拨打用户的分机号码，输入帐号和密码等。而随着IP电话的大量使用如何实现传送DTMF成为IP电话中的一个技术问题。
目前传送DTMF信号普遍有两种方式：带内传送和带外传送。
其中带外传送主要通过将DTMF消息封装到协议中进行传送，如H323协议中可以通过Q931和H245进行传送DTMF。
而带内传输主要有两种：透明传送和RFC2833方式。所谓透明传送就是将DTMF音作为语音一起打包到RTP中进行发送。由于网络丢包的影响，有时会造成DTMF信号丢失，而且DTMF音混合在语音包中，容易产生偏差，造成信号失真。所以目前普遍采用的是RFC2833方式，就是将DTMF数字按照一个的规则和格式组成一个数据包，然后封装到RTP中发送。接收端接收后进行解析，再还原成相应的DTMF信号，这种方式的优点是对丢包的容错性强以及识别差错率低。
二.RTP
在介绍RFC2833前，先来了解一下RTP（Real Time Protocal），该协议可参见RFC1889。RTP协议是IP电话中以及NGN中最经典的协议。无论采用H323，H248，MGCP还是SIP，这些都属于信令层的协议，他们之间进行互通、交换其最终目的是为了实现媒体流的收发。而所有的媒体流都是采用RTP协议，无论是视频，语音还是图象，包括本文所提到的DTMF都是建立在RTP的基础上的。
RTP协议用以传送实时数据。RTP协议通常运行在UDP层之上，二者共同完成运输层的功能。UDP提供复用及校验和服务，也就是通过分配不同的端口号传送多个RTP流。协议规定，RTP流使用偶数（2n）端口号，相应的RTCP流使用相邻的奇数（2n+1）端口号。因此，应用进程应在一对端口上接收RTP数据和RTCP控制数据，同时向另一对端口上接收RTP数据和RTCP控制数据。
RTP分组由RTP头部和净荷数据组成；RTP分组由UDP包来进行传输，通常一个UDP包仅含一个RTP分组，若采用一定的封装方法，也可以包含多个RTP分组；其中的RTP净荷就是RTP传送的语音数据。RTP分组的头部的格式如表1：
表1 RTP分组头部格式
RTP分组头部的各字段含义为：
1．V：RTP版本号。为“10”。
2．P：填充指示位。
P为“1”时表示分组结尾含有1个或多个填充字节。
3．X：扩展指示位。
X为“1”时，则表示固定头部后还有一个扩展头部，这种情况较复杂，很少使用。
4．CC：CSRC计数。
指示固定头部后的CSRC的个数
5．M：
由应用文档解释，通常不用。
6．PT：净荷类型
表示RTP分组的净荷类型。我们常用的有：
¨ “0”： G.711μ
¨ “8”： G.711A
¨ “4”： G.723.1
¨ “18”： G.729
¨ “96”：RFC2833
7．序号：
序号顾名思义就是表示RTP分组的次序。初值为随机数，每发送一个增加1。可供接收方检测分组丢失和恢复分组次序。
8．时戳：
表示RTP分组第一个字节的取样时刻。其初值为随机数，每个采用周期加1。如果每次传送20ms的数据，由于音频的采样频率为8000Hz，即每20ms有160次采样，则每传送20ms的数据，时戳增加160。
9．SSRC：同步源标识（Synchronous Source）
表示信号的同步源，其值应随机选择，以保证同一个RTP会话中任意两个同步源的SSRC标识不同。
10．CSRC：分信源标识（Contributing Source）
CSRC标识由混合器插入，其值就是组成复合信号的各个分信号的SSRC标识，用以标识各个组成分信号的信源。RTP分组的头部最多可以包含15个CSRC标识，其数目由CC字段指明。
三．RFC2833
1．标准格式
RFC2833(RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals)是IETF制定的，它规定了传送DTMF数字以及其他电话音和信号的标准。
图2 RFC2833 净荷格式
图2给出RFC2833的标准格式：
events: 事件号，8位，用于说明本数据包的事件。RFC2833除了传送DTMF信号外还能传送传真，调制解调器，MF信号等。
有关DTMF的事件看见表2。
表2 DTMF的事件
volume: 音量，6位，用于说明DTMF信号的音频功率级，范围从(0~ -63dbm)。有效的DTMF范围是从0 到-36 dBm0；低于-55 dBm0则必须丢弃。
duration：数字信号的宽度，16位，以时戳单元表示。这样，事件从RTP时间戳表示的瞬间开始，并一直持续到该参数表示的长度。事件可以已经结束也可以没有结束。以8000赫兹
取样来说，本字段最长可以表示8秒。
E：结束位,1位，若设置为1表明数据包中含有事件的结束。因此上述的duration参数即测定了事件的完整宽度。
R：本字段为以后使用而保留。发送方必须将它设为0，接收端则应忽略它。
2．举例
以下是抓抓取的数据包表3 DTMF ‘5’的数据格式
在表3中净荷类型为96，这是RFC2833中规定的，在实际情况下可以自己定义类型，只要通信双方能够确认即可。
对于同一个DTMF信号，其时戳是相同的，这样接收方可以通过判断时戳来剔除冗余信息。
对于第三种方法，在SDP中带有事件。此时可以使用的媒体类型为application/dtmf-relay或application/dtmf或application/kpml。
1. application/dtmf-relay为思科VOIP产品所用，但不能成为注册的MMIE.
2. application/dtmf也没成为注册的MMIE，详见seedraft-kaplan-sipping-dtmf-package-00.txt
3. application/kpml为注册的MMIE，是建议使用的类型。详见draf-sipping-sip-interaction-framework。
