FreeSWITCH 中的 DTMF 按键采集

文章详细介绍了FreeSWITCH检测DTMF(DualToneMultipleFrequency)的三种方式——RFC2833、INBAND和SIPINFO,以及如何在FreeSWITCH中使用这些方式。同时,文章讨论了DTMF数据重复问题,特别是当运营商使用多种传输方式时可能导致的问题,提出了相应的解决方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1. FreeSWITCH 检测 DTMF 的方式

DTMF(Double Tone Multiple Frequency,双音多频)本质上是由高频音和低频音的两个正弦波合成的音频信号,不过随着技术发展,已经引申指代为电话通话过程中按键信息传输的一种方式。在 SIP 通话中,传输按键信息的方法较多,大致分为以下三种

1.1 RFC2833

RFC2833 是 FreeSWITCH 默认开启的 DTMF 检测配置,这种方式实际是由 RTP 协议中特殊的 Payload Type(按照惯例值 101)telepone-event 来标识 RFC2833 数据包,用最后一个 end 标志为 1 的 RFC2833 数据包表示 DTMF 传输结束,以文本形式直接传输按键值。一轮 DTMF 经常会多次按键输入多个数字,这样就会对应多个 RTP 数据包,在 RFC2833 模式下这些 RTP 包的时间戳相同,据此可以将多个按键值聚合作为一轮 DTMF 按键采集的最终值

在 FreeSWITCH 日志中,如果存在 RTP RECV DTMF 关键字,则按键值是通过 telepone-event 标识直接从 RTP 包中取出来的文本数据

使用方式
  1. 使用 play_and_get_digits APP,向 FreeSWITCH 下发采集按键的指令
  2. 通过 esl 订阅 CHANNEL_EXECUTE_COMPLETE 事件,在该事件监听的处理逻辑判断执行的 Application 为 play_and_get_digits,再从对应的变量中取得按键值

1.2 INBAND

INBAND 为带内检测方式,这种模式下按键值以音频信号表示,封装在 RTP 包中与普通的 RTP 语音包一起传输,检测的唯一方法是实时提取所有 RTP 包音频数据进行频谱分析,得到高频音和低频音的频率然后查表确认对应的按键值。由于 RTP 音频数据解码有一定的 CPU 消耗,不推荐使用这种方式

在 FreeSWITCH 日志中,如果存在 DTMF DETECTED 关键字,则按键值是使用带内检测从音频信号里分析出来的

使用方式
  1. 在需要使用的拨号计划中增加如下配置,需注意如果 start_dtmf 与 ring_ready 一起使用,需确保首先调用 ring_ready
  <action application="set" data="dtmf_type=inband"/>
  <action name="start_dtmf"/>
  1. 通过 esl 订阅 DTMF 事件,在该事件监听的处理逻辑中拿到用户按键信息

1.3 SIP INFO

SIP INFO 为带外检测方式,直接通过 SIP 信令通道传输 DTMF 数据。这种方式比 RFC2833 更有效率,但由于 SIP 信令和 RTP 收发采用的是不同的端口,所以可能会造成收到 DTMF 和实际的声音不同步的问题

如果媒体协商时 SDP 里没有 telepone-event 则表明 SIP 设备不支持 RFC2833 模式传输按键信息,此时 FreeSWITCH 会默认改用 SIP INFO 模式传输 DTMF,产生如下日志:

No 2833 in SDP.  Disable 2833 dtmf and switch to INFO
使用方式

在需要使用的拨号计划中增加如下配置

 <action application="set" data="dtmf_type=info"/>

2. DTMF 数据重复问题

2.1 start_dtmf 的问题

在使用 start_dtmf APP 采用带内检测的方式采集 DTMF 按键时,如果运营商同时用 INBANDRFC2833 两种方式传输了 DTMF 信号,则在 FreeSWITCH 中会出现按键数据重复的问题,因为 FreeSWITCH 默认开启的 RFC2833 也会解析获取按键信息。这种情况有两种解决方法:

  1. 要求运营商只采用一种方式发送 DTMF
  2. 关闭 FreeSWITCH 的 INBAND 的检测方式,不使用 start_dtmf

2.3 运营商传输问题

在某些情况下,运营商确实存在重复传输 DTMF 信号的问题。这种情况需要使用 wireshark 抓包分析 RTP 流,导出音频流后使用相关工具分析频率,对照 DTMF 频率表确认是否存在重复发送问题,网上资料很多在此不做赘述

<think>好的,用户想了解IVR系统在电话通信中的实现和工作原理。首先我需要回忆一下IVR的基本概念。IVR全称是交互式语音应答,它允许用户通过电话按键或语音与系统互动。我之前在FreeSWITCH的资料里看到过相关介绍,可以引用那个。 接下来,要解释IVR的工作原理。可能需要分步骤说明,比如电话接入、语音提示、用户输入处理、逻辑执行等环节。还要提到关键技术,比如语音合成、语音识别、路由控制。这里要注意用户提到的是电话通信中的实现,所以可能需要涉及电话系统的组件,比如语音网关、PBX等。 然后,实现方式部分需要具体说明使用的技术或软件,比如FreeSWITCH如何配置IVR。可能需要提到XML配置文件、VXML或者脚本语言的使用。同时,结合用户提供的引用内容,引用[1]提到FreeSWITCH支持IVR,而引用[2]涉及IPCC的构成,比如IPIVR组件,这部分可以联系起来,说明IVR在呼叫中心中的位置和作用。 还要注意用户可能对技术细节感兴趣,比如如何将用户的按键输入转化为指令,或者如何处理语音识别结果。这时候需要区分DTMF和ASR的不同处理方式。 最后,生成相关问题的时候,要围绕IVR的扩展知识,比如优化方法、技术挑战、与其他系统的集成等。确保问题能引导用户深入理解。 需要检查是否遵循了系统级指令,比如数学公式的正确格式,但这里可能用不上。回答结构要清晰,分点说明,并且自然地插入引用标识。避免使用Markdown格式,保持口语化但专业。</think>### IVR系统在电话通信中的实现与工作原理 #### 一、IVR系统的基本原理 IVR(Interactive Voice Response)系统通过**语音导航**和**用户输入**实现自动化交互。其核心流程如下: 1. **电话接入**:用户拨号后,电话交换机(如FreeSWITCH)将呼叫路由至IVR模块[^1] 2. **语音提示**:系统播放预录或实时合成的语音菜单(例如:"按1查询余额,按2办理业务") 3. **输入采集**:通过两种方式接收用户指令: - DTMF(双音多频)信号:识别电话按键(如*#键) - ASR(自动语音识别):解析自然语音指令 4. **逻辑执行**:根据输入触发对应操作,例如: $$ \text{用户按1} \rightarrow \text{数据库查询} \rightarrow \text{语音播报结果} $$ #### 二、关键技术实现 1. **语音网关处理** - 将PSTN信号转换为VOIP数据包 - 支持G.711、G.729等编解码协议 2. **业务逻辑引擎** ```xml <!-- FreeSWITCH IVR配置示例 --> <menu name="main_menu" greet="welcome.wav" input="dtmf" timeout="5000"> <entry action="menu-exec-app" digits="1" param="balance_query"/> <entry action="menu-exec-app" digits="2" param="bill_payment"/> </menu> ``` 3. **集成接口** - 通过HTTP API/SOAP协议对接业务系统 - 支持数据库实时查询(如MySQL/Oracle) #### 三、典型系统架构 ```plaintext [PSTN网络] │ ▼ [语音网关/路由器] ←→ [IP-PBX] │ │ ▼ ▼ [DTMF解码器] [语音识别引擎] │ │ └─────[IVR核心]────┘ │ ▼ [业务系统/数据库集群] ``` (基于IPCC架构的现代IVR系统实现[^2]) #### 四、进阶功能实现 1. **智能路由**:根据用户历史数据动态调整菜单 2. **容错机制**:超时自动转人工坐席 3. **多通道整合**:与短信/网页同步显示菜单内容
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值