北京
一个金融客户部署语音AI后，PIN输入环节的弃话率高达34%。排查三天后发现：平台配了RFC 2833，运营商默认走带内传输，双方握手成功，按键却像石沉大海。没有报错，没有日志，只有沉默的失效。
DTMF是什么，为什么语音AI绕不开它
DTMF（双音多频）是电话按键背后的技术。按下"1"，电话同时发出697Hz和1209Hz两个音调；按下"#"，则是941Hz+1477Hz的组合。语音AI依赖它完成：PIN验证、账户查询、信用卡号输入（避开语音识别）、菜单导航等关键场景。
但DTMF配置错误不会触发任何告警——通话继续，按键消失，用户只能在沉默中重复输入，最终愤怒挂断。
三种传输模式：选错即灾难
模式一：带内传输（In-band）——现代编解码器的陷阱
音调直接塞进RTP音频流。G.729和Opus为节省带宽会压缩音频，恰好破坏DTMF依赖的精确频率组合。结果？按键音被"优化"掉，系统毫无察觉。仅在G.711 PCMU环境下可用。
模式二：RFC 2833/4733——2024年的唯一正解
DTMF事件作为独立RTP包传输，与音频流隔离，不受编解码影响。Twilio、Plivo及主流运营商均支持。SDP中声明为：
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
模式三：SIP INFO——遗留系统的孤岛
通过SIP信令通道传输，常见于老旧Cisco、Avaya PBX。若企业客户使用遗留系统，务必先确认其发送模式再配置平台。
最隐蔽的错配：双方都"成功"的握手失败
平台配RFC 2833，运营商走带内——SDP协商显示一切正常，实际按键永不送达。这种错配在三次企业部署中重复出现，每次都需要数天抓包才能定位。
上线前的强制检查清单：向运营商书面确认DTMF传输模式；在SDP中显式声明a=fmtp；用实际按键测试端到端，而非仅验证通话建立；监控"按键后无响应"的异常通话模式。
DTMF不会自己报错。等用户开始挂断，损失已经造成。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
