1. DTMF概述
DTMF (双音多频, Dual-Tone Multi-Frequency) 是电信系统中使用的按键音信令系统。在SIP (会话初始协议) 通信中：
– DTMF代表按下电话键盘上按键时产生的音调
– 每个按键会同时产生两个特定频率的音调(因此称为”双音”)
– 这些音调用于传输拨号数字或与自动系统交互
2. DTMF传输方式
在基于SIP的VoIP系统中，DTMF可以通过不同方式传输：
2.1 带内传输(In-band)
真正的带内传输是指DTMF音调作为音频信号直接嵌入在语音流中传输：
– 音调信号与语音信号混合在同一音频流中
– 使用相同的音频编解码器（如G.711、G.729等）
– 接收端通过音频信号处理识别DTMF音调
– 特点：
– 不需要额外的信令或协商支持
– 可能受到音频编解码器的影响（压缩可能损坏音调）
– 在某些情况下可能不够可靠
– 无法与语音信号清晰分离
2.2 带外传输(Out-of-band)
重要概念澄清：带外传输是指DTMF信息不作为音频信号传输，而是通过其他方式传输，包括：
– RFC 2833 (推荐)：通过RTP事件包传输
– SIP INFO：通过SIP INFO消息传输
– SIP NOTIFY：通过SIP NOTIFY消息传输
– KPML：键盘标记语言
– H.245：H.323协议族中的控制协议
本文主要介绍RFC 2833和SIP INFO两种常用方式：
3. SIP INFO方式详解
3.1 SIP INFO概述
SIP INFO是一种在已建立的SIP会话中传输应用信息的方法。对于DTMF传输：
– 使用SIP INFO消息承载DTMF按键信息
– 在已建立的SIP对话(Dialog)中发送
– 需要双方都支持此方式
3.2 SIP INFO消息格式示例
发送DTMF按键”5″的SIP INFO消息：
INFO sip:user@192.168.1.100:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.101:5060;branch=z9hG4bK-1234567890
From: <sip:caller@192.168.1.101>;tag=abc123
To: <sip:user@192.168.1.100>;tag=def456
Call-ID: call-12345@192.168.1.101
CSeq: 101 INFO
Content-Type: application/dtmf-relay
Content-Length: 23
Signal=5
Duration=100
主要头域说明：
– Content-Type: application/dtmf-relay：指示内容为DTMF中继信息
– Signal=5：表示按下的按键为”5″
– Duration=100：按键持续时间，单位为毫秒
3.3 SIP INFO的优缺点
优点：
– 实现相对简单
– 不依赖RTP流
– 可以携带额外的按键信息（如持续时间）
缺点：
– 依赖SIP信令路径
– 可能受到SIP代理服务器的影响
– 延迟相对较高
– 不是标准化的方法（各厂商实现可能不同）
4. RFC 2833方式详解
4.1 RFC 2833概述
RFC 2833定义了”RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals”：
– 通过RTP事件包传输DTMF
– 使用特定的RTP payload类型（通常为101）
– 是目前最推荐和广泛使用的方式
– 将DTMF作为”媒体事件”而非”信令事件”处理
4.2 RFC 2833工作原理
- SDP协商：在会话建立时协商RFC 2833支持
m=audio 5004 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
- RTP事件包结构：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | 序列号 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 时间戳 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 事件 |E|R| 音量 | 持续时间 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
字段说明：
– 事件(Event)：DTMF按键编码（0-9,,#,A-D对应0-15）
– E标志：事件结束标志
– R标志：保留位
– 音量(Volume)：按键音量（0-63，0表示最大音量）
– 持续时间(Duration)*：按键持续时间
4.3 DTMF按键编码表
| 按键 | 编码值 | 按键 | 编码值 |
|---|---|---|---|
| 0 | 0 | 1 | 1 |
| 2 | 2 | 3 | 3 |
| 4 | 4 | 5 | 5 |
| 6 | 6 | 7 | 7 |
| 8 | 8 | 9 | 9 |
| * | 10 | # | 11 |
| A | 12 | B | 13 |
| C | 14 | D | 15 |
4.4 RFC 2833传输示例
按键”5″的传输过程：
- 按键开始时发送多个相同的包（确保可靠性）
- 按键结束时设置E标志
- 示例包序列：
包1: Event=5, E=0, Duration=160 (按键开始)
包2: Event=5, E=0, Duration=320 (按键持续)
包3: Event=5, E=0, Duration=480 (按键持续)
包4: Event=5, E=1, Duration=640 (按键结束, E标志置1)
包5: Event=5, E=1, Duration=640 (重复发送确保接收)
包6: Event=5, E=1, Duration=640 (重复发送确保接收)
4.5 RFC 2833的优缺点
优点：
– 标准化程度高，兼容性好
– 传输可靠性高（冗余发送）
– 延迟低，实时性好
– 不受音频编解码器影响
缺点：
– 需要RTP流支持
– 实现相对复杂
– 依赖媒体路径
4.6 传输路径对比
带内传输：
用户A按键 → 语音+按键音混合 → RTP音频包 → 用户B听到按键音
SIP INFO传输：
用户A按键 → SIP INFO消息("按了5") → SIP服务器转发 → 用户B收到通知
RFC 2833传输：
用户A按键 → RTP事件包("Event=5") → 直接发送 → 用户B收到事件数据
关键差异：
- 带内：按键音混在语音里，对方听到的是声音
- RFC 2833：按键信息单独打包发送，对方收到的是数据
- SIP INFO：通过信令通道告诉对方，像发消息一样
4.7 为什么RFC 2833是带外传输？
虽然RFC 2833通过RTP媒体流传输，但它仍然是带外传输，原因：
-
数据格式不同：
– 带内：DTMF是音频信号（模拟音调的数字化）
– RFC 2833：DTMF是数字事件数据（事件编码） -
Payload类型不同：
– 带内：使用音频payload类型（如0=PCMU，8=PCMA）
– RFC 2833：使用专门的事件payload类型（通常101） -
处理方式不同：
– 带内：接收端需要音频信号处理来检测音调
– RFC 2833：接收端直接解析事件数据 -
与音频的关系：
– 带内：DTMF音调与语音混合在一起
– RFC 2833：DTMF事件与音频完全分离
示例对比：
带内传输的RTP包（音频payload）：
RTP头 + 音频数据（包含DTMF音调的PCM/压缩音频）
PT=0 (PCMU) 或 PT=8 (PCMA)
RFC 2833的RTP包（事件payload）：
RTP头 + 事件数据（Event=5, Duration=160...）
PT=101 (telephone-event)
4.8 为什么RFC 2833不需要SIP信令？
RFC 2833的设计理念是将DTMF作为”媒体事件”而不是”信令事件”：
- 媒体层面处理：DTMF被视为音频流的一部分，只是用特殊编码
- 实时性要求：按键需要实时传输，RTP比SIP信令更快
- 网络拓扑独立：不依赖SIP代理的路由，直接点对点传输
- 标准化考虑：RTP是媒体传输的标准协议
SDP协商示例对比：
RFC 2833需要的SDP协商：
m=audio 5004 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000 ← 关键：声明支持电话事件
a=fmtp:101 0-15 ← 支持的事件范围
SIP INFO不需要特殊SDP协商：
m=audio 5004 RTP/AVP 0
a=rtpmap:0 PCMU/8000
# 不需要额外的telephone-event声明
5. 带内传输方式详解
5.1 带内传输工作原理
带内传输是最传统的DTMF传输方式：
- 音频生成：按键时生成对应的双音频信号
- 混合传输：DTMF音调与语音信号混合在同一RTP音频流中
- 音频检测：接收端通过DSP算法检测特定频率组合
5.2 带内传输示例
RTP音频包内容：
RTP头 + 音频数据（语音 + DTMF音调的混合PCM数据）
PT=0 (PCMU) 或 PT=8 (PCMA) 或其他音频编解码器
5.3 带内传输的问题
- 编解码器影响：G.729等有损压缩可能损坏DTMF音调
- 检测困难：需要复杂的信号处理算法
- 误检率高：语音中的某些音调可能被误识别为DTMF
- 延迟检测：需要收集足够的音频样本才能确认
6. 三种方式的详细对比
6.0 三种DTMF传输方式的本质差异
重要概念理解：
1. 带内传输(In-band)：
– DTMF作为音频信号在语音流中传输
– 使用音频payload类型（PT=0, 8等）
– 接收端通过音频信号处理识别音调
2. SIP INFO方式（带外）：
– 使用SIP信令通道传输DTMF信息
– DTMF信息封装在SIP INFO消息中
– 走的是SIP信令路径（通过SIP代理服务器）
– 与音频RTP流完全独立
3. RFC 2833方式（带外）：
– 使用RTP媒体通道但传输数字事件数据（非音频）
– DTMF信息封装在特殊的RTP事件包中（PT=101）
– 走的是RTP媒体路径但不是音频数据
– 虽然在媒体流中，但仍属于带外传输
通俗理解三种方式：
-
带内传输：
– DTMF音调混合在语音里，跟着语音流一起走
– 就像在通话中直接播放按键音，对方听到的是音频信号
– 一个RTP包里既有语音又有按键音 -
RFC 2833：
– DTMF信息是单独的数据包发给对方
– 不是音频，是纯数字信息（告诉对方”按了5键”）
– 虽然也走RTP，但是独立的包，与语音包分开 -
SIP INFO：
– DTMF信息通过SIP消息告诉对方
– 就像发短信告诉对方”我按了5键”
– 完全不走语音通道，走信令通道
形象比喻：
– 带内：在电话里直接按键让对方听到”嘟嘟”声
– RFC 2833：发个数据包告诉对方”我按了5″（对方收到数字信号）
– SIP INFO：发个短信告诉对方”我按了5″（通过信令通知）
6.1 详细对比表
| 特性 | 带内传输 | SIP INFO | RFC 2833 |
|---|---|---|---|
| 数据性质 | 音频信号 | 信令消息 | 数字事件数据 |
| 传输通道 | RTP音频流 | SIP信令通道 | RTP事件流 |
| Payload类型 | 音频PT(0,8等) | N/A(SIP消息) | 事件PT(101) |
| 传输路径 | RTP媒体路径 | SIP信令路径 | RTP媒体路径 |
| SDP协商 | 不需要 | 不需要特殊协商 | 需要telephone-event |
| 依赖关系 | 独立传输 | 依赖SIP代理服务器 | 独立于SIP信令 |
| 编解码器影响 | 受影响 | 不受影响 | 不受影响 |
| 信号处理 | 需要音频检测 | 直接解析消息 | 直接解析事件 |
| 标准化程度 | 标准(但可靠性差) | 非标准化 | 标准化(RFC 2833) |
| 实现复杂度 | 中等 | 简单 | 中等 |
| 传输可靠性 | 较低 | 中等 | 高(冗余发送) |
| 传输延迟 | 低 | 较高(信令处理) | 低(直接传输) |
| 推荐程度 | 不推荐 | 备用方案 | 首选方案 |
7. 实际应用建议
7.1 优先级建议
- 首选：RFC 2833 (telephone-event) – 带外传输
- 备选：SIP INFO – 带外传输
- 避免：带内传输 – 可靠性差，易受编解码器影响
7.2 配置建议
- 在SDP中明确声明支持的DTMF方式
- 确保网络设备支持RFC 2833包的正确转发
- 配置适当的RTP事件包冗余发送次数
- 测试DTMF在不同网络条件下的可靠性
7.3 故障排除
常见问题：
1. DTMF丢失或识别错误
2. 按键重复或延迟
3. 某些按键无法识别
排查方法：
1. 检查SDP协商是否正确
2. 抓包分析RTP事件包
3. 验证音频编解码器设置
4. 检查网络QoS配置
8. 总结
DTMF是VoIP系统中重要的用户交互方式，正确理解和配置DTMF传输方式对于保证通话质量和用户体验至关重要。
核心理解要点：
1. SIP INFO方式：属于SIP信令层面的解决方案，DTMF信息通过SIP消息传输
2. RFC 2833方式：属于RTP媒体层面的解决方案，DTMF信息通过特殊的RTP包传输
3. 这两种方式使用完全不同的传输路径和协议层面
实际应用建议：
– 首选RFC 2833：标准化程度高，传输可靠，延迟低
– SIP INFO作为备选：在RFC 2833不可用时的后备方案
– 同时支持多种方式：提高系统兼容性和可靠性
理解这些传输方式的本质差异有助于在实际部署中做出正确的技术选择和故障排除。