CN102420920B - Voip网络中dtmf流的传输方法 - Google Patents
Voip网络中dtmf流的传输方法 Download PDFInfo
- Publication number
- CN102420920B CN102420920B CN 201110429313 CN201110429313A CN102420920B CN 102420920 B CN102420920 B CN 102420920B CN 201110429313 CN201110429313 CN 201110429313 CN 201110429313 A CN201110429313 A CN 201110429313A CN 102420920 B CN102420920 B CN 102420920B
- Authority
- CN
- China
- Prior art keywords
- dtmf
- rtp
- stream
- tcp
- steps
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种VOIP网络中DTMF流的传输方法,尤其涉及一种使用传统语音网关时采用压缩语音在因特网上传输带来的DTMF流的大量丢失的解决方案。该方法采用固定电话线路作为传输路径,传输过程包括发送端处理步骤、接收端处理步骤,将在因特网中传输DTMF流进行分类提取,并开辟只针对DTMF分类的TCP通道,使接收端可以根据DTMF序列与RTP序列进行比对,最终恢复成最佳的DTMF流输出。本发明还公开了一种基于该DTMF流传输方法的网关装置。本发明通过TCP流中的DTMF序列与RTP流的音频序列的对比,既包含校验的过程,也包括了误码恢复的过程,极大提高了数据传输的可靠性。
Description
技术领域
本发明涉及一种VOIP网络中传输DTMF(Dua-Tone MultiFrequency,双音多频)流时校验并可靠传输的方法及网关装置,尤其涉及一种使用传统语音网关时采用压缩语音在因特网上传输带来的DTMF流的大量丢失的解决方案。
背景技术
随着人们需求的不断提高,各种门禁系统,安防告警系统进入千家万户,集成的拨号告警系统在各小区、办公大楼、海关等均有大规模使用,在消息集中传送途径上,可以采用无线模式和网络模式,但使用固定电话线路作为传输路径的系统依然大量存在,主要原因在于电话拨号告警系统的线路无需架设新的资源,与办公电话系统并行存在,在日常办公时,该线路作为语音通信存在,而在下班时(即无人办公时),才设置为安防模式。同时电话系统的可靠性本来就要高过无线系统等其他环境。
原有的电话线路是采用程控交换的电路交换的物理线路,线路质量和可靠性可以达到电信级的标准为99.9999%,而随着网络时代的兴起,运营商推广“光进铜退”的NGN的建设,新装的固定电话实际上已经是VOIP的语音IP电话,而原先的一些程控交换的线路也被改造成了VOIP线路。
众所周知,VOIP语音时将语音分帧,加上RTP报头,然后加上UDP报头,变成IP报文在因特网上传输,而IP报文传输UDP帧最大的特性就是尽力而为,即不可靠交付,在传送实时性的语音时,显然没有问题,因为人耳的掩蔽效应以及上层应用的再次询问可以解决语义的识别问题。但对于采用DTMF流进行传输的门禁安防系统,由于RTP包的丢失造成的DTMF值的丢失恰恰是不可原谅的。
现有技术未考虑网络拥塞造成的RTP包丢失,只简单地将未丢失的包按TS顺序输出,由此在网络拥塞变化时造成的RTP分组的时延和抖动,最终造成安防拨号系统的DTMF值的偏差。
现有VOIP语音采用G729A语音编码,在语音通信上没有问题,在DTMF流传输上出现严重频偏,最终几乎无法恢复出原始DTMF流,出现“长0”的等待现象;如何既不影响原有语音系统的正常通信,又能满足作为安防系统的传输路径,即是当前许多电话拨号告警系统在升级时需要迫切解决的问题。
发明内容
本发明所要解决的技术问题在于针对背景技术的缺陷和不足,提出一种VOIP环境下的针对DTMF流的可靠传输方法,将在因特网中传输DTMF流进行分类提取,并开辟只针对DTMF分类的TCP通道,使接收端可以根据DTMF序列与RTP序列进行比对,最终恢复成最佳的DTMF流输出。
本发明为解决上述技术问题,采用以下技术方案:
一种VOIP网络中DTMF流的传输方法,采用固定电话线路作为传输路径,传输过程包括发送端处理步骤、接收端处理步骤,其中:
发送端处理步骤如下:
步骤A1、在发送端开辟发送缓冲区,对输入的DTMF信号进行采样并进行编码,编码形式选择常规语音编码格式;
步骤A2、对编码后的码流进行分帧处理,帧间隔为30ms;并进行短时功率检测和过零点处理,并将结果存入发送缓冲区;
步骤A3、根据步骤A2进行的短时功率检测和过零点处理结果,对所有生成的帧进行定性分类,分类的类别为间隔帧、信号帧;
对于间隔帧,按照一个间隔标记对其RTP帧的时间戳进行记录;
对于信号帧,进行DTMF检测,对检测结果属于DTMF值的信号帧,按照0~F值的类型对其RTP帧的时间戳进行记录;
步骤A4、开辟TCP端口,建立TCP通道,如链路中断,则重新握手连接;
步骤A5、将步骤A3中产生的DTMF值按4个比特组成新的缓冲队列,加上首个DTMF值对应的RTP帧的时间戳生成新的TCP包,发送到接收端;
接收端处理步骤如下:
步骤A6、在接收端开辟两个接收缓冲区,其中一个是用于接收TCP流的TCP缓冲区;另一个是用于接收RTP流的RTP缓冲区;首先执行RTP包的检测工作,将在一定时间内接收的RTP包按各个报文的时间戳进行缓冲排序,通过校验RTP帧的时间戳判断是否发生RTP丢包;
a,当未发生丢包现象,TCP缓冲区接收各RTP包的数据进行保存,进入步骤A8;
b,当发生丢包现象,则进一步判断该RTP帧的时间戳在TCP报文内是否存在,并获取TCP报文中该RTP帧对应时间戳的类值:
b-1,如果存在,则正常解码,获取TCP报文中该丢失的RTP帧对应时间戳的类值,进入步骤A7;
b-2,如果不存在,则选择邻居报文进行解码,获取邻居报文对应时间戳的类值,根据该邻居报文的时间戳在TCP流中查找相应的位置,估计出TCP报文中该丢失的RTP帧对应时间戳的类值,进入步骤A7;
b-3,如果无法获取邻居报文对应时间戳的类值,则扩大搜索范围,在16个RTP报文之内,重复b-2进行类值判定;如果16次均失败,无法进行类值检测,按照TCP流中的压缩流的定义,由发送端网关再造新的DTMF流,返回步骤A6;
步骤A7,根据上一步骤得到的发生丢包现象的各RTP帧时间戳的类值生成新的RTP报文插入RTP包队列中去;TCP缓冲区接收RTP流的数据进行保存;
步骤A8,对所有RTP报文中的净荷进行释放,恢复输出原始DTMF流,判断TCP缓冲区内是否存在DTMF信息:
A8-1,当TCP缓冲区内无DTMF信息,则认为信道无DTMF模式,将所有的RTP包进行语音净荷聚合并进行解压缩,恢复成原始语音输出;
A8-2,当TCP缓冲区内有DTMF信息,则根据对应时间戳检测TCP缓冲区内的DTMF流与RTP包里面的对应关系,将两个序列进行比对:
当比对结果一致,输出解码后的DTMF流;
当比对结果不一致,对根据TCP流中的类值进行DTMF流重构,生成新的音频段后输出。
进一步的,本发明的VOIP网络中DTMF流的传输方法的步骤A8中在将所述两个序列进行比对时,还包括检测是否有RTP包丢失的步骤,按照以下步骤进行处理:
如果有一个RTP包丢失,则对相邻RTP包进行解码,得出该丢失的RTP包中对应时间戳,进而得到与其对应TCP流中DTMF序列;根据对应TCP流中DTMF序列判断该RTP包所对应的音频信息的类型,然后根据TCP流中的分类号进行恢复生成一个新的RTP包写入RTP接收缓冲区,并重复A8步骤;
如果有n个连续RTP包丢失,其中1<n<16,同样对相邻RTP包进行解码后进行DTMF序列检测,并根据第一RTP包的和最后一个RTP包的TS区间,查找TCP缓冲区内DTMF流的记录,选择不同概率匹配模型,恢复出原始DTMF流的净荷。
进一步的,本发明的VOIP网络中DTMF流的传输方法的步骤A8中,如果收发双方没有发送DTMF流,则该TCP通道仅发送填充消息以保证链路的有效存在。
进一步的,本发明的VOIP网络中DTMF流的传输方法的步骤A5中,当发送端检测到有DTMF值时,需记录当前时间戳,并生成TCP报文发送;而直到检测出现间隔帧,才启动生成下一个TCP报文。
进一步的,本发明的VOIP网络中DTMF流的传输方法的步骤A6中,如果接收端解码RTP包时发现发送端采用的编码形式是G729A编码形式、而TCP接收表明是DTMF流时,需要根据DTMF流重新生成音频信号发送。
本发明还提出一种VOIP网络中进行DTMF流传输的网关装置,包括电源电路、全相整流桥电路、模数转换单元、中央处理器、串行通信口、网络通信模块、存储器单元;其中所述电源电路用于供电,所述全相整流桥电路的输入端接入DTMF信号,所述全相整流桥电路的输出端连接模数转换单元,所述模数转换单元与中央处理器连接,所述中央处理器分别与串行通信口、网络通信模块、存储器单元连接。
作为本发明的网关装置的进一步优化方案,还包括与中央处理器连接的状态显示模块。
作为本发明的网关装置的进一步优化方案,还包括与中央处理器连接的心跳模块。
作为本发明的网关装置的进一步优化方案,所述存储器单元包括静态随机存储器SRAM、闪存Flash,其中所述静态随机存储器SRAM、闪存Flash分别与中央处理器连接。
本发明采用以上技术方案与现有技术相比,具有以下技术效果:
通过TCP流中的DTMF序列与RTP流的音频序列的对比,既包含校验的过程,也包括了误码恢复的过程,极大提高了数据传输的可靠性。
TCP流由于只记录两个间断之间的DTMF值,而并非30ms就生成一个DTMF值,因此每产生一个RTP包(最小240个样值,及240字节),最多产生一个TCP包(5个字节),因此新增网络流量最大只增加了原先网络流量2%,由于安防系统的标准是至少50m时长的DTMF,因此新开的TCP最多只增加了网络流量的1.25%。
实验表明:在G711的A率和U率的编码下,网络拥塞达到70%时,依然可以正确恢复出DTMF流;在G723.1编码下,70%的网络拥塞率,DTMF流恢复正确率为100%,但新的DTMF流与原始DTMF流有较小差别;在G729A编码下,70%的网络拥塞率,DTMF流恢复正确率为100%,但生成的DTMF流与接收端的音频流则完全不同。本装置在安防系统的测试下,与原先程控交换系统的线路相比,输出码流达到以下技术指标:
(1)电平范围:-4~-23dbm;
(2)高低频电平差:≤4db;
(3)频偏:±1.5%;
(4)二次谐波:比基频能量至少低20db。
附图说明
图1是采用PSTN进行远程告警信息传输的示意图。
图2是本发明的网关装置的模块框图。
图3是RTU侧的系统对呼叫的音频流进行检测的流程图。
图4是起点检测与标记过程的流程图。
图5是起点检测结果示例图。
图6是RTP包封装流程图。
图7是TCP包生成流程图。
图8是TCP连接通信方法示意图。
图9是系统接收部分处理流程图。
图10是语音IP用户下发注册的DTMF流业务示意图。
具体实施方式
下面结合附图对本发明的技术方案做进一步的详细说明。
如说明书附图1所示,为采用PSTN(Public Switched Telephone Network,公用开关电话网络)进行远程告警信息传输的示意图。其中RTU(Remote Terminal Unit,远端终端单元)负责接入所有的传感器单元,CTU(Central Terminal Unit,中央终端单元)负责对多个RTU的信息进行采集和下发指令。
出于系统的兼容性,本发明的网关装置兼容原先语音网关的VOIP功能,即本装置与其他非同类型语音网关通信时,如果连续TCP握手不成功,则认为非同类型设备,则恢复为普通网关状态。
图1所示,本发明的网关装置在应用于安防系统线路时,根据使用场景,将分为两大类场合:
场合1,线路改造时采用了企业自己架设的VOIP语音网关,即向因特网的提供VOIP业务的SP商申请了VOIP线路,并设置了自己的告警中心的接入号;此种情况也可以自行搭建SIP服务器,分配SIP用户及各自号码,完成企业内容的VOIP线路。
场合1的VOIP线路较差,通常VOIP语音采用的G729A,在实际通信时DTMF丢失最严重。
场合2,线路原先申请的是运营商比如电信或网通的线路,此时由于运营商将开展语音IP的软交换业务,将带有宽带口和语音口的集成本发明的实现装置功能的ONU布置到用户接入。此时ONU的语音口出来的线路表面上与原先一致,在语音传输时难以识别,但在安防系统进行拨号系统的DTMF流传输时,会出现一定的误码率。
在场合1时,本发明的网关装置作为单独的DTMF增强装置出现,在场合2时,本发明的网关装置可以将软件功能集成到ONU的模块功能上。
本发明的网关装置首先完成兼容的SIP语音网关的功能,即具有SIP客户端注册,登记,SIP呼叫等功能,其注册号码标识为数字,以方便其他SIP用户呼叫。
运行在Internet的SIP服务器可以由本发明的网关装置的使用者架设开源的SIP服务器,比如Osip协议(轻量级)或者OpenSIPS协议栈(电信级),也可以使用Internet的VOIP的SP商提供的VOIP线路,优先推荐自己架设的开源SIP协议栈,原因是:SP商提供的VOIP语音通常都为G729A,在本系统方案设计中属于环境最恶劣情况。而自己独立架设的SIP服务器,可以将RTP的语音格式设置成G.711的A率,甚至是最佳的线性PCM编码。
本发明的网关装置作为SIP客户端登录至SIP服务器后成为一个在线SIP客户。当RTU端发出拨号请求时,SIP服务器发出SIP消息邀请,同时向对端发出TCP连接请求。呼叫成功后记录TCP连接状态(成功:对端是CTU设备;失败:对端是普通SIP客户端)。
线路接通后,当RTU发出音频流时,CPU对数据帧进行起点检测是否包含DTMF值,如是,则打上时间戳(TS),加上DTMF值,通过TCP通道发送出去;同时该数据帧也经过语音编码后,加上RTP报头,UDP报头,打上相同的TS值,作为UDP报文发送出去。
Internet或者IP城域网正常情况下,即网络未出现拥塞状况下,TCP报文和RTP报文都会到达接收端,接收端缓冲区内对所有RTP报文进行排序,将会发现未出现丢包,则不进行DTMF比对,直接将RTP报文的语音净荷进行解压缩恢复。
在网络出现拥塞,不同级别的拥塞状态对于不同格式的语音编码所造成的结果是不同的。本发明仅就常规的G711,G723.1,G729A三种编码进行处理。
如果发现有1个RTP包丢失,则对相邻RTP进行解码,并进行DTMF检测,得出检测结果;然后对该RTP包中对应TS标识查找TCP接收缓冲区DTMF流的位置,经过相应算法的比对,可以判断出该RTP包的音频信息的类型,由此生成一个替代RTP包写入RTP接收缓冲区,最终进行解压缩恢复;
如果发现有2个以上RTP包丢失,同样对相邻RTP进行解码后进行DTMF检测,并根据第一RTP包的和最后一个RTP包的TS区间,查找TCP接收缓冲区内DTMF流的记录,经过一系列算法的判断,最终生成替代的RTP包并插入。
在语音编码为G711,G723.1时可以执行以上操作,在语音编码为G729A时,由于G729A是发生谐振腔参数模型编码,对DTMF值的频偏值非常大,因此在比对TCP缓冲区的DTMF流和UDP缓冲区内的RTP流时,可以直接采用将DTMF流的数据直接按照50ms的周期间隔重新制造出音频流发送出去,前提是比对时发现RTP流中实在提取不出正确的DTMF信息。
本网关装置因为是双向通信,因此发送和接收处理分别由两个线程完成,加上TCP过程,一共有三个主要线程处理。
本发明的网关装置就是解决在VOIP的网络上传输语音的途径上,可靠保证DTMF流传输的装置,以及在语音商使用EPON网络开设的语音IP线路上可靠传输DTMF流的装置。本装置在网络中的位置如图1所示,即由实施此功能的装置开设TCP流,此TCP流与原先的RTP流通道可以互为比对,从而在概率分布上最大可能实现可靠传输。RTP数据在丢包情况下由TCP流进行修正,在无法解码情况下由TCP流完全覆盖,在TCP流无数据情况下与原先系统完全兼容。
系统硬件组成如图2所示,包括电源电路、全相整流桥电路、模数转换单元、中央处理器、串行通信口、网络通信模块、存储器单元;其中所述电源电路用于供电,所述全相整流桥电路的输入端接入DTMF信号,所述全相整流桥电路的输出端连接模数转换单元,所述模数转换单元与中央处理器连接,所述中央处理器分别与串行通信口、网络通信模块、存储器单元连接。
其中,中央处理器CPU采用TI公司的C5409芯片作为主控芯片,由片外Flash进行代码段扩充,由外置SDRAM扩大收发缓冲区大小。与RTU或CTU相连的电路等同于传统模拟电话的结构(只不具备语音通话电路),所述模数转换单元采用AD50F芯片,负责将模拟信号转换为数字信号送入DSP总线。网络通信模块采用商业化的集成了TCP/IP协议栈的RTL8019,负责将C5409生成的各种IP包发送和接收,串行通信口采用MAX232口作为通信口,可以直接对装置进行配置和访问(单机调试时用)。心跳模块由PLC16C54负责做外部看门狗电路,定时接收主CPU的心跳信号,在超时的时候进行CPU自动复位,保护主CPU不进入死锁状态。状态显示模块显示装置当前的状态,分为连接状态,工作状态,网络忙闲状态,对端是否告警状态,TCP链路连通状态。
本发明的网关装置共分为三大功能块,分别是:A,预处理部分;B,发送处理部分;C,接收处理部分。
A,预处理部分:
A1,对独立装置无预处理部分,对运营商提供语音IP业务的ONU来说,可以将本装置功能软件集成,但工作前必须由运维人员在运营和维护管理系统(BSS)上进行注册登记此DTMF流功能,并由BSS下发功能到指定的ONU的语音端口(中间经过MSCG,OLT以及物理的分光器),此功能示意如图10所示。
A2,RTU侧的装置的TCP通道握手的过程,系统开启TCP端口,根据下发信息或者配置信息,向CTU侧的装置发出TCP的连接请求,TCP连接后,还需要进行独立系统的身份认证,身份认证确认后,在系统空闲时会发送有定时的“心跳”的空信息以保证TCP通道的畅通,由于TCP所占带宽很小,对网络带宽不会影响。此步骤如图8的上半部分所示,因此此时没有有用数据传输。
B,发送处理部分:
B1,主叫RTU侧的系统首先完成VOIP的呼叫,即SIP呼叫或者H.248呼叫,此处兼容普通语音网关功能,B1步骤是标准的VOIP的呼叫过程。
B2,被叫CTU侧的装置进行应答,并接通,从而建立起VOIP的RTP通道。
B3,RTU侧的系统对呼叫的音频流进行检测,工作过程如图3所示,进行分帧检测,以30ms为一帧,通常50%的重叠模式,首先进行短时功率预测和短时过零率检测,计算后得出该帧是信号帧还是间隔帧,同时对第一个信号帧记录起点时间戳(4个字节标识),具体步骤如图4所示,起点检测后的结果示意举例如图5所示。
B4,对信号帧进行DTMF检测,本处采用成熟的Goertzel算法,由于RTU发送端的信号尚未经过网络等干扰信号,均能检测出标准的DTMF键值,保存为类型码。
B5,并行地,将B3步骤中的帧进行按照装置的配置要求,如G711, G723.1 ,G729A进行压缩编码,并加上12字节RTP报头,8字节UDP报头,20字节IP报头,通过RTL8019发送出去,如图6所示。
B6, 对于已经生成的起点检测序列,以及各端音频所检测出来的类型码,如图7所示,将用户生成TCP报文序列,TCP报文的长度为TCP头部20字节加上4个字节的时间戳和1个字节的类型码,其中需要进行判断,即只有在前一帧是间隔帧而后一帧是信号帧时才进行TCP报文的产生。
B7,虽然TCP通道质量有保证,但考虑到RTP通道和TCP通道的同时发送数据,有可能出现TCP流滞后的现象,因此在发送RTP流时会人为滞后250ms,所以同时在TCP流采用了一种新的机制:即如果发送时TCP缓冲区内已经产生多个待发TCP报文,则采用报文重新组装的形式,将多个TCP报文合并发送,如果发送完序号为n+3报文,正准备发送n+4报文时,收到了n+1报文的否认,则将n+1报文,n+2,n+3,n+4这四个报文共20个字节一并生成新的n+1报文发送,节约了往返确认的时间。具体过程如图8下半部分的TCP通信新机制所示。
C,接收处理部分:
C1,接收部分与发送部分是并行双向处理的部分,接收端开设两个接收缓冲区,一个接收的TCP流,格式为时间戳+类值+时间戳+类值;另一个是接收到RTP流缓冲区,如图9上半部分示意。
C2,接收部分首先执行RTP包的检测工作,将在一定时间内接收的RTP包按各个报文的时间戳进行排序,同时进行RTP包序号的校验,查看是否发生了RTP丢包,无论该包是由于网络延迟造成还是网络堵塞造成。
C3,如果没有发生丢包现象,则完全兼容原有语音网关功能,执行步骤C6。
C4,如果发生丢包,则结合丢包个数以及根据初设条件转C51~C53进行预测处理。
C5-1,如果没有执行50%的帧的重叠 获取该TCP报文里的类型值,根据其值生成一个新的RTP报文,插入到接收RTP包队列中去,转C6。
C5-2,如果执行了50%的帧的重叠,则将前一个RTP帧的后50%叠加后有一个RTP帧的前50%,转C6步骤。
C5-3,如果丢弃多个包,则需要对丢失的RTP的时间戳段进行分析处理,转C8步骤。
C6,对所有RTP报文中的净荷进行释放,恢复输出原始DTMF流。
C7,与TCP流里面的类值序列进行对比,如果TCP流中无数据,则直接输出;如果有数据,则同样按帧进行起点检测,如发现对应起点位置有误,则用TCP流中的类值生成新的音频段输出,结束。
C8,此步骤解决丢失RTP包时间戳不在TCP流中对应,但存在一个区间内的情况。选择该边界RTP包的净荷,进行压缩解码,进行DTMF检测,并得出其类值,如果能获得其类值,则根据其时间戳和类值在TCP报文序列中进行匹配,估算出丢失的RTP包的类值,并生成新的RTP代替包插入RTP流缓冲区,即再次进入C6;如果无法获取其类值,则扩大搜索范围,在16个RTP报文之内,进行类值判定,重复C8过程;如果16次均失败,则默认RTP流中的数据已经发生严重差错(突发差错造成的连续误码),无法进行类值检测,则立刻转入C9。
C9,按照TCP流中的压缩流的定义,由C5409再造新的DTMF流,其中两个类值之间的间隔长度为30ms,即选择30ms为一帧,其余有用信号的长度均为两个起点时间戳之差减去30ms的时长。
综上所述,本发明提供了一个在动态因特网环境下的可靠DTMF流传输的网关装置及具体实现方法,并在软交换网络中兴通信ZXSS10软交换机搭建的网络中进行测试,测试结果表明,在G711编码环境下,网络吞吐量达到70%左右,DTMF流依然可以通过TCP流中类值序列进行可靠恢复;在G729A环境下,网络吞吐量达到30%左右,DTMF流可以通过TCP流中类值序列进行可靠恢复,但超过30%,在30%~70%的范围内,DTMF流需要通过TCP流中类值序列进行全部再造,虽然输出的DTMF流与发送的DTMF流在时序和时长上完全不一致,但DTMF数据的解码正确性是100%。测试结果表明,采用G723.1的特性与采用G729A时基本相同。
表一是国标规定的DTMF键值分布,且国标规定了一定的容差范围。
表1
系统测试表明,此发明装置在做完全VOIP通信时与原系统兼容,与未开启DTMF流增强功能的软终端X.lite和multiphone通信时语音通信正常,由此表明本发明所述的方法具有实践与转化的意义。
Claims (5)
1.一种VOIP网络中DTMF流的传输方法,其特征在于,采用固定电话线路作为传输路径,传输过程包括发送端处理步骤、接收端处理步骤,其中:
发送端处理步骤如下:
步骤A1、在发送端开辟发送缓冲区,对输入的DTMF信号进行采样并进行编码,编码形式选择常规语音编码格式;
步骤A2、对编码后的码流进行分帧处理,帧间隔为30ms;并进行短时功率检测和过零点处理,并将结果存入发送缓冲区;
步骤A3、根据步骤A2进行的短时功率检测和过零点处理结果,对所有生成的帧进行定性分类,分类的类别为间隔帧、信号帧;
对于间隔帧,按照一个间隔标记对其RTP帧的时间戳进行记录;
对于信号帧,进行DTMF检测,对检测结果属于DTMF值的信号帧,按照0~F值的类型对其RTP帧的时间戳进行记录;
步骤A4、开辟TCP端口,建立TCP通道,如链路中断,则重新握手连接;
步骤A5、将步骤A3中产生的DTMF值按4个比特组成新的缓冲队列,加上首个DTMF值对应的RTP帧的时间戳生成新的TCP包,发送到接收端;
接收端处理步骤如下:
步骤A6、在接收端开辟两个接收缓冲区,其中一个是用于接收TCP流的TCP缓冲区;另一个是用于接收RTP流的RTP缓冲区;首先执行RTP包的检测工作,将在一定时间内接收的RTP包按各个报文的时间戳进行缓冲排序,通过校验RTP帧的时间戳判断是否发生RTP丢包;
a,当未发生丢包现象,TCP缓冲区接收各RTP包的数据进行保存,进入步骤A8;
b,当发生丢包现象,则进一步判断该RTP帧的时间戳在TCP报文内是否存在,并获取TCP报文中该RTP帧对应时间戳的类值:
b-1,如果存在,则正常解码,获取TCP报文中该丢失的RTP帧对应时间戳的类值,进入步骤A7;
b-2,如果不存在,则选择邻居报文进行解码,获取邻居报文对应时间戳的类值,根据该邻居报文的时间戳在TCP流中查找相应的位置,估计出TCP报文中该丢失的RTP帧对应时间戳的类值,进入步骤A7;
b-3,如果无法获取邻居报文对应时间戳的类值,则扩大搜索范围,在16个RTP报文之内,重复b-2进行类值判定;如果16次均失败,无法进行类值检测,按照TCP流中的压缩流的定义,由发送端网关再造新的DTMF流,返回步骤A6;
步骤A7,根据上一步骤得到的发生丢包现象的各RTP帧时间戳的类值生成新的RTP报文插入RTP包队列中去;TCP缓冲区接收RTP流的数据进行保存;
步骤A8,对所有RTP报文中的净荷进行释放,恢复输出原始DTMF流,判断TCP缓冲区内是否存在DTMF信息:
A8-1,当TCP缓冲区内无DTMF信息,则认为信道无DTMF模式,将所有的RTP包进行语音净荷聚合并进行解压缩,恢复成原始语音输出;
A8-2,当TCP缓冲区内有DTMF信息,则根据对应时间戳检测TCP缓冲区内的DTMF流与RTP包里面的对应关系,将两个序列进行比对:
当比对结果一致,输出解码后的DTMF流;
当比对结果不一致,对根据TCP流中的类值进行DTMF流重构,生成新的音频段后输出。
2.根据权利要求1中所述的VOIP网络中DTMF流的传输方法,其特征在于,所述步骤A8中在将所述两个序列进行比对时,还包括检测是否有RTP包丢失的步骤,按照以下步骤进行处理:
如果有一个RTP包丢失,则对相邻RTP包进行解码,得出该丢失的RTP包中对应时间戳,进而得到与其对应TCP流中DTMF序列;根据对应TCP流中DTMF序列判断该RTP包所对应的音频信息的类型,然后根据TCP流中的分类号进行恢复生成一个新的RTP包写入RTP接收缓冲区,并重复A8步骤;
如果有n个连续RTP包丢失,其中1<n<16,同样对相邻RTP包进行解码后进行DTMF序列检测,并根据第一RTP包的和最后一个RTP包的TS区间,查找TCP缓冲区内DTMF流的记录,选择不同概率匹配模型,恢复出原始DTMF流的净荷。
3.根据权利要求1中所述的VOIP网络中DTMF流的传输方法,其特征在于,所述步骤A8中,如果收发双方没有发送DTMF流,则该TCP通道仅发送填充消息以保证链路的有效存在。
4.根据权利要求1中所述的VOIP网络中DTMF流的传输方法,其特征在于,所述步骤A5中,当发送端检测到有DTMF值时,需记录当前时间戳,并生成TCP报文发送;而直到检测出现间隔帧,才启动生成下一个TCP报文。
5.根据权利要求1中所述的VOIP网络中DTMF流的传输方法,其特征在于,所述步骤A6中,如果接收端解码RTP包时发现发送端采用的编码形式是G729A编码形式、而TCP接收表明是DTMF流时,需要根据DTMF流重新生成音频信号发送。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 201110429313 CN102420920B (zh) | 2011-12-20 | 2011-12-20 | Voip网络中dtmf流的传输方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 201110429313 CN102420920B (zh) | 2011-12-20 | 2011-12-20 | Voip网络中dtmf流的传输方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102420920A CN102420920A (zh) | 2012-04-18 |
CN102420920B true CN102420920B (zh) | 2013-05-08 |
Family
ID=45945147
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN 201110429313 Expired - Fee Related CN102420920B (zh) | 2011-12-20 | 2011-12-20 | Voip网络中dtmf流的传输方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102420920B (zh) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109064823A (zh) * | 2018-09-11 | 2018-12-21 | 南京辰睿秋实信息技术有限公司 | 呼叫中心实训管理系统及其工作方法 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7039044B1 (en) * | 1999-10-14 | 2006-05-02 | Mindspeed Technologies, Inc. | Method and apparatus for early detection of DTMF signals in voice transmissions over an IP network |
US20080192623A1 (en) * | 2007-02-09 | 2008-08-14 | Mediatek Inc. | Methods and devices for dual-tone multi-frequency (dtmf) signaling |
CN101702749B (zh) * | 2009-11-03 | 2013-01-16 | 中兴通讯股份有限公司 | 双音多频事件帧处理方法、系统和媒体网关 |
-
2011
- 2011-12-20 CN CN 201110429313 patent/CN102420920B/zh not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
CN102420920A (zh) | 2012-04-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Balasubramaniyan et al. | Pindr0p: Using single-ended audio features to determine call provenance | |
CN108234421B (zh) | 一种视联网终端与互联网终端音频数据互通的方法与系统 | |
CN100521652C (zh) | 根据服务等级来信号通知VolP呼叫的方法和设备 | |
US7752297B2 (en) | Systems and methods for flow signature formation and use | |
US20020141386A1 (en) | System, apparatus and method for voice over internet protocol telephone calling using enhanced signaling packets and localized time slot interchanging | |
CN101473622A (zh) | 用于数据网络上的通信的带外鉴别方法和系统 | |
CN101517948A (zh) | 通信装置、通信方法和记录介质 | |
CN109788232A (zh) | 一种视频会议的会议记要记录方法、装置和系统 | |
CN101123641A (zh) | 基于分布式架构的无线网络电话监听装置的监听方法 | |
CN107453936A (zh) | 一种诊断语音时延的方法和网关设备 | |
CN109462761A (zh) | 一种视频解码方法及装置 | |
CN101262418A (zh) | 散置在整个压缩信息信号中的数字消息的传输 | |
WO2009036645A1 (fr) | Procede et systeme de fourniture d'informations de facturation d'elements de reseau ims et procede et systeme de facturation associes | |
CN1937544A (zh) | Ip电话监听系统 | |
CN110191304A (zh) | 数据处理方法、装置及存储介质 | |
CN102904822A (zh) | VoIP网络流量的层次化识别方法 | |
CN101043759B (zh) | 一种通过话带数据vbd方式实现数据业务的方法及其系统 | |
CN108881819A (zh) | 一种音频数据的传输方法和装置 | |
CN102420920B (zh) | Voip网络中dtmf流的传输方法 | |
WO2021174879A1 (zh) | Ai视频通话质量分析方法、装置、计算机设备及存储介质 | |
CN110620849A (zh) | 一种ims电话终端呼叫记录集中分拣方法及系统 | |
Huang et al. | Covert voice over internet protocol communications based on spatial model | |
CN111212263B (zh) | 一种监控资源数据的过滤方法和装置 | |
CN1941819B (zh) | 一种话音业务在以太网传输的方法及系统 | |
Hekmat | Communication networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20130508 Termination date: 20151220 |
|
EXPY | Termination of patent right or utility model |