音视频--DTMF信号发送及检测

参考资料

https://zh.wikipedia.org/wiki/%E5%8F%8C%E9%9F%B3%E5%A4%9A%E9%A2%91
https://www.cnblogs.com/lijingcheng/p/4454932.html

1. DTMF是什么

1.1 DTMF定义

双音多频信号（英语：Dual-Tone Multi-Frequency，简称：DTMF），电话系统中电话机与交换机之间的一种信令，最常用于拨号时发送被叫号码。不过双音多频的发明，除了缩短拨号时间，也扩展了拨号之外的功能，例如自动总机、交互式语音应答。

1.2 DTMF对按键的编码

双音多频的拨号键盘是4*4，有10个数字键和6个字符键，每个数字或字符都是由两个单频信号的组合来进行传输。换句话说每一行代表一个高频，每一列代表一个低频。也就是说每按一个键就发送一个高频和低频的正弦信号组合，比如’1’相当于697和1209赫兹（Hz）。交换机可以解码这些频率组合并确定所对应的按键。 AT&T贝尔实验室提出用DTMF信号作为音频电话的拨号信号，因为这种方式可以提供更高的拨号速率，且容易被自动检测和识别。但反之，DTMF信号的这个优点也很容易变成致命的缺点，因为容易被交换机检测和识别，也就意味着容易被意图为之第三方破解。破解的原理很简单，只要能估计出DTMF信号中两个单频信号的频率值，再根据底下电话机键盘的频率数组表格的对应关系就可以反推出按键值。
在这里插入图片描述

2. DTMF信号的产生和发送

2.1 DTMF信号的产生

可以基于软件或者硬件(一般是芯片)根据下列函数产生对应的数字信号
在这里插入图片描述
其中fL和fH分别表示按键所在的行和列对应的频率值。DTM信号本身就是两个不同频率正弦波相加组合而成的。
Matlab中对几个键盘值的表示如下：

fs=8000;
t=(0:800)/fs;
fcolumns1 = 697;fcolumns2 = 770;fcolumns3 = 852;fcolumns4 = 941;
frow1 = 1209;frow2 = 1336;frow3 = 1477;
num0 = sin(2*pi*fcolumns4*t)+sin(2*pi*frow2*t); %數字0
num1 = sin(2*pi*fcolumns1*t)+sin(2*pi*frow1*t); %數字1
num2 = sin(2*pi*fcolumns1*t)+sin(2*pi*frow2*t); %數字2
num3 = sin(2*pi*fcolumns1*t)+sin(2*pi*frow3*t); %數字3
num4 = sin(2*pi*fcolumns2*t)+sin(2*pi*frow1*t); %數字4
num5 = sin(2*pi*fcolumns2*t)+sin(2*pi*frow2*t); %數字5
num6 = sin(2*pi*fcolumns2*t)+sin(2*pi*frow3*t); %數字6
num7 = sin(2*pi*fcolumns3*t)+sin(2*pi*frow1*t); %數字7
num8 = sin(2*pi*fcolumns3*t)+sin(2*pi*frow2*t); %數字8
num9 = sin(2*pi*fcolumns3*t)+sin(2*pi*frow3*t); %數字9
numStar = sin(2*pi*fcolumns4*t)+sin(2*pi*frow1*t); %符號*
numJin = sin(2*pi*fcolumns4*t)+sin(2*pi*frow3*t); %符號#
blank = zeros(size(num1)); %間隔
f = [fcolumns1 fcolumns2 fcolumns3 fcolumns4 frow1 frow2 frow3];
f_Low = [fcolumns1 fcolumns2 fcolumns3 fcolumns4];
f_High = [frow1 frow2 frow3];

2.2 DTMF信号的传输方式

DTMF信号传输现有的两种方案如下：

2.2.1 SIPINFO

用SIP信令的INFO方法携带DTMF信号
该方法是用SIP信令的INFO方法来明文定义来代表DTMF信号。目前以Cisco SIPINFO为标准，通过SIPINFO包中的signal字段识别DTMF按键。注意当DTMF为“*”时不同的标准实现对应的signal=*或signal=10。有专家认为其并不适用，主要缺陷是因为SIP控制信令和媒体传输（RTP）是分开传输，很容易造成DTMF信号和媒体包不同步。

简单举个例子，在 Voice Mail应用中，用户根据提示音输入一个DTMF信号，随后开始留言。Server是在接受到该DTMF信号后开始保存用户的留言。然而由于DTMF信号是通过SIP信令来传输的，而媒体流是通过RTP来传输的，有可能用户留言的RTP包先到，而该DTMF信号的INFO消息延迟，导致Server不保存用户的语音留言直至接受到INFO消息。

INFO包举例：

INFO sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP alice.uk.example.com:5060
From: <sip:[email protected]>;tag=d3f423d
To: <sip:[email protected]>;tag=8942
Call-ID: 312352@myphone
CSeq: 5 INFO
Content-Length: 24
Content-Type: application/dtmf-relay

Signal=5
Duration=160

上述包中Signal字段的值就表示传输的按键值；

2.2.2 INBAND 和 RFC2833

在RTP媒体传输中携带DTMF信号
该方法是将DTMF信号和媒体流一样，用RTP包来传输，因而没有DTMF信号和媒体流不同步的问题，使用H323信令的VOIP就是采用该种方法，相对来说比较成熟。该方法有分为以下两种方式

1) INBAND：In Band DTMF是指直接将DTMF的音频数字信号不经任何处理直接打成RTP包在IP网中传输。其中可能和用户的语音媒体流混合（mix）在一起传输。程序要获知哪个包有DTMF信号，是什么DTMF信号，必须实时检查每个RTP包里面的媒体流数据，分析它的频域。

DTMF 频谱分析得到按键值 https://blog.csdn.net/cg1510167/article/details/114279633

针对上述方法无法通过分析RTP包查看所携带的号码信息。但是通过wireshark的抓包对RTP流进行播报可以听到按键音的播放。

2) RFC 2833：该方法是将DTMF信号用专门的RTP包进行标识，在RTP包的头域中就可得知该包是DTMF包，并且知道是什么DTMF信号。RFC2833专门对此有专门定义。

RFC2833 原文： http://rfc2cn.com/rfc2833.html

(1）SIPINFO
该方法为带外检测方式，通过SIP信令通道传输DTMF数据。没有统一的实现标准，目前以Cisco SIPINFO为标准，通过SIPINFO包中的signal字段识别DTMF按键。注意当DTMF为“*”时不同的标准实现对应的signal=*或signal=10。SIPINFO的好处就是不影响RTP数据包的传输，但可能会造成不同步。
简单举个例子，在 Voice Mail应用中，用户根据提示音输入一个DTMF信号，随后开始留言。Server是在接受到该DTMF信号后开始保存用户的留言。然而由于DTMF信号是通过SIP信令来传输的，而媒体流是通过RTP来传输的，有可能用户留言的RTP包先到，而该DTMF信号的INFO消息延迟，导致Server不保存用户的语音留言直至接受到INFO消息。
(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数据包进行频谱分析，经过频谱分析得到高频和低频的频率，然后查表得到对应的按键，进行频谱分析的算法一般为Goertzel，这种算法的实现也很简单，网上有很多可以下到，但建议采用定点算法，浮点算法效率很低。
在选择压缩比很高码率很低的codec，比如G.723.1和G.729A等，建议不要使用INBAND模式，因为INBAND DTMF数据在进行复杂编解码后会产生失真，造成DTMF检测发生偏差或失败。
另外，还特别需要注意的一点就是很多SIP UA中INBAND都是伴随着RFC2833和SIPINFO同时发生的，这时需要区别对待，最好选择RFC2833和SIPINFO

3. RFC2833协议标准

RFC2833规定了DTMF信号发送的标准，该标准就是将DTMF数字按照一定的规则和格式组成一个数据包，然后封装到RTP中发送。接收端接收后进行解析，再还原成相应的DTMF信号，这种方式的优点是对丢包的容错性强以及识别差错率低。

3.1 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：

在这里插入图片描述

上述图片见 https://www.rfc-editor.org/rfc/rfc1889.html#section-5.1

前 12 个字节出现在每个 RTP 包中，仅仅在被混合器插入时，才出现 CSRC 识别符列表。各个域的含义如下所示：

（1）版本（V）：2 比特，此域定义了 RTP 的版本。此协议定义的版本是 2。(值 1 被 RTP 草案版本使用,值 0 用在最初"vat"语音工具使用的协议中。)
（2）填充（P）： 1 比特，若填料比特被设置,则此包包含一到多个附加在末端的填充比特,填充比特不算作负载的一部分。填充的最后一个字节指明可以忽略多少个填充比特。填充可能用于某些具有固定长度的加密算法，或者用于在底层数据单元中传输多个 RTP 包。
（3）扩展(X)：1 比特，若设置扩展比特,固定头(仅)后面跟随一个头扩展。
（4）CSRC 计数(CC)：4 比特，CSRC 计数包含了跟在固定头后面 CSRC 识别符的数目。
（5）标志(M)：1 比特，标志的解释由具体协议规定。它用来允许在比特流中标记重要的事件,如帧边界。
（6）负载类型(PT)：7 比特，此域定义了负载的格式，由具体应用决定其解释，协议可以规定负载类型码和负载格式之间一个默认的匹配。其他的负载类型码可以通过非 RTP 方法动态定义。RTP发送端在任意给定时间发出一个单独的 RTP 负载类型；此域不用来复用不同的媒体流。
（7）序列号(sequence number)：16 比特，每发送一个 RTP 数据包,序列号加 1，接收端可以据此检测丢包和重建包序列。序列号的初始值是随机的(不可预测),以使即便在源本身不加密时(有时包要通过翻译器,它会这样做)，对加密算法泛知的普通文本攻击也会更加困难。
（8）时间戳(timestamp) ：32 比特，时间戳反映了 RTP 数据包中第一个字节的采样时间。时钟频率依赖于负载数据格式,并在描述文件(profile)中进行描述。也可以通过 RTP 方法对负载格式动态描述。
如果 RTP 包是周期性产生的，那么将使用由采样时钟决定的名义上的采样时刻，而不是读取系统时间。例如,对一个固定速率的音频，采样时钟将在每个周期内增加 1。如果一个音频从输入设备中读取含有 160 个采样周期的块，那么对每个块,时间戳的值增加 160。时间戳的初始值应当是随机的，就像序号一样。几个连续的 RTP 包如果是同时产生的。如:属于同一个视频帧的 RTP 包,将有相同的序列号。
不同媒体流的 RTP 时间戳可能以不同的速率增长。而且会有独立的随机偏移量。因此,虽然这些时间戳足以重构一个单独的流的时间，但直接比较不同的媒体流的时间戳不能进行同步。对于每一个媒体，我们把与采样时刻相关联的 RTP 时间戳与来自于参考时钟上的时间戳(NTP)相关联。因此参考时钟的时间戳就是数据的采样时间。(即:RTP 时间戳可用来实现不同媒体流的同步，NTP 时间戳解决了 RTP 时间戳有随机偏移量的问题。)参考时钟用于同步所有媒体的共同时间。这一时间戳对(RTP 时间戳和 NTP 时间戳)，用于判断 RTP 时间戳和 NTP 时间戳的对应关系,以进行媒体流的同步。它们不是在每一个数据包中都被发送，而在发送速率更低的 RTCP 的 SR(发送者报告)中。
如果传输的数据是存贮好的，而不是实时采样得到的,那么会使用从参考时钟得到的虚的表示时间线(virtual presentation timeline)。以确定存贮数据中的每个媒体下一帧或下一
个单元应该呈现的时间。此种情况下 RTP 时间戳反映了每一个单元应当回放的时间。真正的回放将由接收者决定。
（9）SSRC：32 比特，用以识别同步源。标识符被随机生成，以使在同一个 RTP 会话期中没有任何两个同步源有相同的 SSRC 识别符。尽管多个源选择同一个 SSRC 识别符的概率很低，所有 RTP 实现工具都必须准备检测和解决冲突。若一个源改变本身的源传输地址，必须选择新的SSRC 识别符，以避免被当作一个环路源。
RTP 包流的源，用 RTP 报头中 32 位数值的SSRC 标识符进行标识，使其不依赖于网络地址。一个同步源的所有包构成了相同计时和序列号空间的一部分，这样接收方就可以把一个同步源的包放在一起，来进行重放。
举些同步源的例子，像来自同一信号源的包流的发送方，如麦克风、摄影机、RTP 混频器就是同步源。一个同步源可能随着时间变化而改变其数据格式，如音频编码。SSRC 标识符是一个随机选取的值，它在特定的 RTP 会话中是全局唯一(globally unique)的。参与者并不需要在一个多媒体会议的所有 RTP 会话中，使用相同的 SSRC 标识符；SSRC 标识符的绑定通过RTCP。如果参与者在一个 RTP 会话中生成了多个流，例如来自多个摄影机，则每个摄影机都必须标识成单独的同步源。
（10）CSRC 列表：0 到 15 项，每项 32 比特，CSRC 列表识别在此包中负载的所有贡献源。识别符的数目在 CC 域中给定。若有贡献源多于 15 个，仅识别 15 个。CSRC 识别符由混合器插入，并列出所有贡献源的 SSRC 识别符。例如语音包，混合产生新包的所有源的 SSRC 标识符都被列出，以在接收端处正确指示参与者。

若一个 RTP 包流的源，对由 RTP 混频器生成的组合流起了作用，则它就是一个作用源。对特定包的生成起作用的源，其 SSRC 标识符组成的列表，被混频器插入到包的 RTP 报头中。这个列表叫做 CSRC 表。相关应用的例子如，在音频会议中，混频器向所有的说话人(talker)指出，谁的话语(speech)将被组合到即将发出的包中，即便所有的包都包含在同一个(混频器的)SSRC 标识符中，也可让听者(接收者)可以清楚谁是当前说话人。

3.2 RF2833规定的DTMF信号发送标准头部

在这里插入图片描述
(1) events: 事件号，8位，用于说明本数据包的事件
(2) volume: 音量，6位，用于说明DTMF信号的音频功率级，范围从(0~ -63dbm)。有效的DTMF范围是从0 到-36 dBm0；低于-55 dBm0则必须丢弃。
(3) duration：数字信号的宽度，16位，以时戳单元表示。这样，事件从RTP时间戳表示的瞬间开始，并一直持续到该参数表示的长度。事件可以已经结束也可以没有结束。以8000赫兹
取样来说，本字段最长可以表示8秒。
(4) E：结束位,1位，若设置为1表明数据包中含有事件的结束。因此上述的duration参数即测定了事件的完整宽度。
(5) R：本字段为以后使用而保留。发送方必须将它设为0，接收端则应忽略它。

3.2.1 RFC2833中DTMF事件和键盘的对照表

在这里插入图片描述
上述表格表示了电话按键和真实DTMF事件的对应关系

4. SDP中关于DTMF事件发送和接受的协商

在通话建立的协商阶段，SIP信令交互中会协商对DTMF信号是否支持。在INVITE或者200OK的SDP信息中，如果包含有 a=fmtp 字段，则表示发送方和接受方支持DTMF（events 0 through 15），拨号和回铃音。

   >> 表示A支持DTMF（events 0 through 15），拨号和回铃音
   >>From A in INVITE:
        a=fmtp:101 1-15,66,70
        
   >> 表示B支持 DTMF
   >>From B in 200 OK:
        a=fmtp:101 1-15

上述过程中对telephone-event的编码采用的是101，有些可能是96,。但是两者是等效的，只是使用的习惯不相同。