CN107453936A - 一种诊断语音时延的方法和网关设备 - Google Patents
一种诊断语音时延的方法和网关设备 Download PDFInfo
- Publication number
- CN107453936A CN107453936A CN201610382565.XA CN201610382565A CN107453936A CN 107453936 A CN107453936 A CN 107453936A CN 201610382565 A CN201610382565 A CN 201610382565A CN 107453936 A CN107453936 A CN 107453936A
- Authority
- CN
- China
- Prior art keywords
- data bag
- test data
- packet
- time
- gateway
- 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.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0852—Delays
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Environmental & Geological Engineering (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种诊断语音时延的方法和网关设备,采用本发明,可记录测试数据包的发送时间和确认数据包的接收时间,根据该发送时间和接收时间计算时延,本发明中,测试数据包和确认数据包均是沿待诊断传输路径传输,确保了本发明的时延是待诊断传输路径的时延。本发明中发送时间和接收时间是由同一侧设备记录的,自然就满足了发送时间和接收时间是同一时间标准的需求,相对于现有技术中利用RTCP包确定传输路径的时延时,需要发送端和接收端支持NTP,达到时间同步的条件,本发明中,语音时延的确定不受收、发两端的设备支持NTP的限制。
Description
技术领域
本发明涉及通信技术领域,具体涉及一种诊断语音时延的方法和网关设备。
背景技术
随着通信技术的发展,在下一代网络(NGN,Next Generation Network)中,IP(Internet Protocol,网际协议)协议将作为同一的通信协议,整个网络将演变为以IP技术为核心,可以支持语音、数据、多媒体业务的融合网络,其中VOIP(Voice over Internet Protocol,IP电话)具有占用网络资源少,成本低廉等优势,很好地满足了人们的日常生活和工作的需求,是最具有潜力的应用。近年来,VOIP在世界范围内得到了飞速的发展,越来越被大众认可,相对于传统的电话网络,基于IP网络的VOIP明显具有成本低的优点,更受年轻用户的青睐。
VOIP,即将模拟语音信号通过压缩编码处理,变成语音数据流,然后按照TCP/IP标准打包,再通过分组交换网(如Internet、ATM)传输,在接收端,通过解压缩编码还原为模拟语音信号。可以想到的是,发送方的语音数据流在经过了互联网连接的机器之间的传输后到达接收方是有时延的,为了能为用户双方提供更优良的服务,需要确定VOIP语音通信的时延。一般而言,现有技术中,都是通过RTCP(Realtime Transportation Control Protocol,实时传输控制协议)包携带的时间信息来计算VOIP语音通信的时延,但是此方法要求收发RTCP包的双方支持NTP(Network Time Protocol,网络时间协议),即收发RTCP包的双发的时间是同一个时间标准比如世界时间标准,且在RTCP包中携带的时间也是NTP时间,然后接收方才能根据自身的NTP时间和RTCP包中携带的NTP时间计算出VOIP语音通信中的时延,所以现有技术中,要求收发RTCP包的双方设备支持NTP。此外,现有技术中,采用的是周期性发送RTCP报文的方式周期性地计算VOIP语音通信的时延,这会额外占用语音网关系统socket资源,并造成一定的网络资源的浪费。
发明内容
本发明要解决的主要技术问题是,提供一种诊断语音时延的方法和网关设备,解决现有技术中需要基于RTCP包携带的NTP时间计算传输路径时延带来的RTCP包的发送方和接收方设备必须支持NTP的问题。
为解决上述技术问题,本发明实施例提供一种诊断语音时延的方法,包括:
生成测试数据包;
发送测试数据包,控制其沿待诊断传输路径传输至接收网关,并记录测试数据包的发送时间;
接收确认数据包,记录确认数据包的接收时间;确认数据包为接收网关沿待诊断传输路径返回的对测试数据包的反馈
根据发送时间和接收时间计算待诊断传输路径的时延。
为解决上述的技术问题,本发明实施例还提供一种诊断语音时延的方法,包括
接收发送网关沿待诊断传输路径上传输的数据包;
判断接收的数据包是否为测试数据包;
如果是,则生成对测试数据包的确认数据包;
沿待诊断传输路径回发确认数据包至发送网关。
为解决上述的技术问题,本发明实施例提供一种网关设备,包括
生成模块,用于生成测试数据包;
第一发送模块,用于发送测试数据包,控制其沿待诊断传输路径传输至接收网关,并记录测试数据包的发送时间;
第一接收模块,用于接收确认数据包,记录确认数据包的接收时间;确认数据包为接收网关沿待诊断传输路径返回的对测试数据包的反馈;
计算模块,用于根据发送时间和接收时间计算待诊断传输路径的时延。
为解决上述的技术问题,本发明实施例还提供一种网关设备,包括
第二接收模块,用于接收发送网关沿待诊断传输路径上传输的数据包;
判断模块,用于判断接收的数据包是否为测试数据包;
第二生成模块,用于在判断模块的判断结果为是时,生成对测试数据包的确认数据包;
第二发送模块,用于沿待诊断传输路径回发确认数据包至发送网关。
采用本发明的诊断语音时延的方法和网关设备,可利用沿待诊断传输路径发送的测试数据包的接收时间,和接收待诊断传输路径传输的确认数据包的接收时间来计算待诊断传输路径的时延,相对于现有技术中,利用RTCP包确定传输路径的时延的方式,本实施例中发送测试数据包的设备和接收测试数据包的接收网关不须支持NTP协议,即使发送设备和接收网关的时间不同步,也不影响本实施例的方法计算出的时延的准确性。
附图说明
图1为本发明实施例一提供的一种诊断语音时延的方法的流程图;
图2为本发明实施例二提供的一种诊断语音时延的方法的流程图;
图3为本发明实施例三提供的一种网关设备的模块示意图;
图4为利用本发明实施例三提供网关设备实现本端话机和远端话机通话的系统构架图;
图5为利用图4中的系统进行语音时延诊断的流程图;
图6为本发明实施例四提供的一种网关设备的模块示意图。
具体实施方式
下面通过具体实施方式结合附图对本发明作进一步详细说明。
实施例一:
本实施例提出了一种诊断语音时延的方法,包括:
S101、生成测试数据包;
S102、发送测试数据包,控制其沿待诊断传输路径传输至接收网关,并记录测试数据包的发送时间;
S103、接收确认数据包,记录确认数据包的接收时间;
确认数据包为接收网关沿待诊断传输路径返回的对测试数据包的反馈,即确认数据包是接收网关从接收的数据包中识别出测试数据包后,沿待诊断传输路径回发的反馈。
S104、根据发送时间和接收时间计算待诊断传输路径的时延。
本实施例的语音通信主要涉及VOIP语音通信,即IP电话通信,通过VOIP语音通信方式实现通信的过程一般是,发送方网关对发送方的模拟语音信号进行数据采样并进行数据编码成数字信号,再将编码后的数据压缩打包成RTP(Real-time Transport Protocol,实时传输协议)包,然后发送给接收方网关,接收方网关接收到RTP包后,对RTP包的数据进行解压缩、解码,将其还原为语音信号,接收方用户就可以收听到发送方的语音。
明显,在VOIP通信中,语音数据的传输路径就是RTP包的传输路径,所以可以理解的是,本实施例中,诊断语音时延的方法涉及的时延主要是VOIP语音通信中,RTP包的传输路径的时延,所以本实施例的待判断传输路径可以理解为RTP包的传输路径。
现有技术中,为了确定传输路径的时延,选择的方法是利用两个处于相同时间标准下的设备发送RTCP包实现的,具体是发送方发送一带有符合NTP标准的发送时间的RTCP包,通过传输路径发送给接收方,接收方将RTCP包的接收时间,和RTCP包中携带的NTP时间之间的时间差作为传输路径的时延,明显,在现有技术中的时延是传输路径的单向时延,作为传输路径的起点和终点,发送方和接收方的时间标准是一致的,即发送方和接收方的时间同步。为了摆脱时间标准一致的限制,本实施例提出了诊断传输路径时延的方法,具体的过程包括上述的S101、S102、S103、S104。
本实施例的使用的发送时间和接收时间都是由初始发送测试数据包的一方记录的,所以发送时间和接收时间自然是相对于同一标准的时间。由于在本实施例中,不涉及接收网关的时间,所以接收网关的时间标准和其接收测试数据包的时间对本实施例的时延的计算没有任何的影响。
在本实施例中,测试数据包的类型没有限制,包括本身就能在待诊断传输路径上传输的数据包,比如,能在RTP包的传输路径中传输的RTP包或RTCP包;或在某种控制手段下能沿待诊断传输路径传输的数据包,例如在某种控制手段下沿待诊断传输路径传输的自定义的数据包。
当步骤S101中生成的测试数据包是RTP包或RTCP包时,由于RTP包和RTCP包本身就是沿着RTP包的传输路径传输的,即RTP包和RTCP包本身就沿待诊断传输路径传输,所以对于测试数据包为RTP包或RTCP包的情况而言,步骤S102为发送测试数据包到接收网关,记录发送测试数据包的发送时间。
当步骤S101中生成的测试数据包是自定义数据包,为了实现测试数据包沿待诊断传输路径传输的目的,可以确定发送网关到接收网关之间的待诊断传输路径的转发节点,控制测试数据包沿路径上的转发节点依次转发,直至到达接收网关。具体的,可以将转发节点的信息写入自定义数据包中,每一个转发节点收到该自定义数据包之后,可以根据自定义数据包中的转发节点的信息,将该自定义数据包转发到下一跳转发节点,实现测试数据包沿待诊断传输路径传输的目的,确保步骤S104中的时延的正确性。在上述的分析中,可以发现,将RTP包或RTCP包作为测试数据包使用时,直接发送即可,步骤简单,而将自定义数据包作为测试数据包使用时,还需要对其传输路径做限制,相对于RTP包和RTCP包而言,其使用较为复杂,不如RTP包和RTCP包使用方便。
在本实施例中,接收网关收到数据包之后,会先判断其是否为测试数据包,如果是,接收方网关会立即沿待诊断传输路径返回一个确认数据包,以便发送网关记录确认数据包的接收时间,可以想到的是,本实施例中的确认数据包的来源包括但不限于:直接将测试数据包作为确认数据包沿待诊断路径回发到发送网关,或者,重新生成数据包作为确认数据包沿待诊断传输路径回发到发送网关。
重新生成数据包的方法可以参考上述关于生成测试数据包的方法,重新生成的确认数据包也可以分为RTP包、RTCP包和自定义数据包,当回发的确认数据包属于RTP包或RTCP包时,接收网关只需执行发送操作,确认数据包即可沿待诊断传输路径传输至发送网关,当回发的确认数据包属于自定义数据包时,控制其沿待诊断传输路径回发至发送网关的方法,可以参考上述将属于自定义数据包的测试数据包发送至接收网关的方法。
在上述的描述中,相对于将重新生成的数据包作为确认数据包的方案,直接将测试数据包作为确认数据包回发的方式不需要重新生成的步骤,回发的操作简单。尤其是在测试数据包为RTP包或RTCP包的时候,接收网关直接发送测试数据包到发送网关即可,此时,测试数据包自身已经满足沿待诊断传输路径回发的要求。
在接收网关收到数据包之后,需要从数据包中识别出测试数据包,然后才能回发确认数据包,接收网关识别测试数据包的过程实际上也是需要一定的时间的,本实施例中计算的待诊断传输路径的时延实际上也包括接收网关的识别时间,但是一般而言,该识别的时间相对于数据包在待诊断传输路径的传输时间时很短暂的,所以可以忽略该识别时间对时延的影响。进一步地,为了使得本实施例的待诊断传输路径的时延更准确,可以从步骤S10中计算出来的时延中去除接收网关的识别时间。为了得到该识别时间的具体值,可以记录接收网关不间断识别n个(n为整数)测试数据包需要的总时长,再根据该总时长和测试数据包的个数n得到平均时间,将该平均时间作为识别时间使用。
可以想到的,当测试数据包是RTP包或RTCP包时,该RTP包或RTCP包需满足能与普通RTP包或RTCP包区分开的条件,接收网关才能判断收到的RTP包或RTCP包是否为测试数据包。为了能将作为测试数据包的RTP包或RTCP包与普通RTP包或RTCP包区分开,在步骤S101中,生成测试数据包时,可以先复制一个RTP包或RTCP包,然后修改RTP包的包头信息或修改RTCP包的包头信息,将修改后的RTP包或修改后的RTCP包作为测试数据包使用。对应的,接收网关判断测试数据包的规则可以包括判断RTP包或RTCP包的包头信息是否被被修改。
为了进一步保证接收网关判断的准确性,避免对正常语音通信产生干扰,在生成测试数据包时,可以将包头中的特定信息修改为预设的判断值,接收网关只要根据该数据包的包头中的特定信息是否被修改为预设的判断值,即可判断该数据包是否为测试数据包。
以RTP包为例,在生成测试数据包时,可以先复制当前时刻将要发送的RTP包,再将其中一个RTP包包头中的PT值修改为126,接着发送该修改后的RTP包,记录发送时间,并将原始的RTP包也发送给接收网关,该原始的RTP包用于正常的语音通信。接收网关在接收到RTP包后,若识别出RTP包的PT值为正常的RTP包的PT值,对该RTP包的内容进行解压缩、解码等操作,还原出模拟语音信号;若识别出包头中的PT值为126,就可以判断该RTP包为测试数据包,然后立即回发确认数据包。为了回发操作的简单,以及回发路径确保为待判断传输路径,可以直接将判断为测试数据包的RTP包回发给发送网关,发送网关收到RP值为126的RTP包后,记录接收时间,根据该RTP包的发送时间和接收时间可以计算出待判断传输路径的环回时延,待判断传输路径的单向时延是该环回时延的一半。
当该测试数据包是自定义数据包时,接收网关不能根据接收的数据包的包头信息是否改变来判断其是否为测试数据包。对此,发送网关在生成自定义数据包时,可以在测试数据包中写入指示信息指示其身份,并指示接收网关执行回发测试数据包的操作。优选的,在生成自定义数据包时,可以生成带有返回指令的自定义数据包作为测试数据包,该返回指令用于指示接收到接收网关在收到测试该数据包后,立即沿待判断传输路径回发确认数据包。
为了便于控制测试数据包的发送,达到控制诊断语音时延的目的,本实施例中,可以设置一语音时延诊断开关来实现测试数据包的生成和发送,进一步地,还提供人机交互界面以便用户控制语音时延诊断开关的使能和关闭。当需要诊断传输路径的语音时延时,使能语音时延诊断开关,开启语音时延的诊断,进行上述的S101-S104的步骤,当语音时延诊断结束后,可以关闭语音时延诊断开关,等待下一次诊断。
采用本实施例的诊断语音时延的方法,可利用沿待诊断传输路径发送的测试数据包的接收时间,和接收待诊断传输路径传输的确认数据包的接收时间来计算待诊断传输路径的时延,相对于现有技术中,利用RTCP包确定传输路径的时延的方式,本实施例中发送测试数据包的设备和接收测试数据包的接收网关不须支持NTP协议,即使发送设备和接收网关的时间不同步,也不影响本实施例的方法计算出的时延的准确性。
实施例二:
参见图2,本实施例提供一种诊断语音时延的方法,包括:
S201、接收待诊断传输路径上传输的数据包;
S202、判断接收的数据包是否为测试数据包;
S203、在判断结果为是时,生成对测试数据包的确认数据包;
S204、沿待诊断传输路径回发确认数据包至发送网关。
本实施例的上述步骤是实施例一中的接收网关接收数据包至反馈确认数据包的步骤,可以理解的是,本实施例的确认数据包发送到发送网关后,发送网关可以记录确认数据包的接收时间,再根据测试数据包的发送时间就可以计算出待诊断传输路径的时延,具体的计算公式是:时延=接收时间-发送时间。
本实施例的诊断语音时延的方法适用于VOIP,在VOIP通信中,语音数据的传输路径就是RTP包的传输路径,所以可以理解的是,本实施例中,涉及的时延主要是VOIP语音通信中,RTP包的传输路径的时延,所以待判断传输路径可以理解为RTP包的传输路径。
本实施例的测试数据包包括本身就是在待诊断传输路径上传输的数据包,比如,在RTP包的传输路径中传输的RTP包或RTCP包;或在某种控制手段下能沿待诊断传输路径传输的数据包,例如在某种控制手段下沿待诊断传输路径传输的自定义数据包。
考虑到发送网关发送的测试数据包可以是RTP包,或RTCP包,或自定义数据包,为了提高步骤S202中判断的速度和效率,在判断数据包是否为测试数据包时,可以先判断数据包是否为RTP包或RTCP包,再根据RTP包或RTCP包是否被修改判断收到的数据包是否为测试数据包。当数据包为自定义数据包时,若该数据包中返回指令,指示接收网关收到数据包后返回确认数据包,则将该数据包判断为测试数据包,然后接收网关执行该返回指令,返回确认数据包给发送网关。
可以想到的是,若发送网关在生成测试数据包时的标准是,将RTP包头中的某个信息例如PT值修改,例如修改为126,接收网关判断测试数据包的规则与发送网关生成测试数据包的标准相对应,即可以通过判断RTP包中的PT值是否为126判断RTP包是否为测试数据包。
在本实施例中,生成确认数据包的方式包括收到测试数据包后,针对该测试数据包重新生成一个新的数据包作为确认数据包。可以想到的是,本实施例重新生成的确认数据包可以是RTP包、RTCP包或自定义数据包,生成过程可以参考实施例一中的相关描述。当确认数据包是RTP包或RTCP包时,步骤S203实际上是发送RTP包或RTCP包到接收网关的步骤,确认数据包的传输路径就是待判断传输路径。当确认数据包属于自定义数据包时,需要设置确认数据包的传输路径的转发节点等信息,控制确认数据包沿待判断传输路径回发至发送网关,具体的控制方式可以参考实施例一中控制测试数据包沿待诊断传输路径传输的相关描述。
此外,生成确认数据包的方式还包括直接将识别出来的测试数据包作为确认数据包沿待判断传输路径回发给发送网关,采用此方法不用预先生成确认数据包,避免浪费网关资源。当发送网关发送的测试数据包是RTP包或RTCP包时,步骤S204可以是,在识别出测试数据包后,立即回发测试数据包。此时,步骤S204最简单,而且,由于回发的RTP包或RTCP包本身就属于能在待诊断传输路径上传输的数据包,所以无需采用其他控制手段控制确认数据包的回发路径为待诊断传输路径。当发送网关发送的测试数据包是自定义的数据包时,步骤S203中,还需要对自定义数据包进行某些修改,比如改变其携带的传输路径的转发节点信息等,才能控制自定义数据包沿待诊断传输路径返回。
可以想到的是,发送网关一侧得到的时延是根据测试数据包的发送时间和确认数据包的接收时间计算的,这其中,其实包括了接收网关收到测试数据包,到发送确认数据包之间的时间,这时间一般是用在了识别测试数据包上,所以,本实施例中,接收网关还可以记录自身识别测试数据包需要的时间,将该时间告知发送网关,以便消除该时间对时延的误差影响。
采用本实施例的诊断语音时延的方法,可以在识别出测试数据包后,立即沿待诊断传输路径回发确认数据包,以便发送网关能确定确认数据包的接收时间,识别出测试数据包后立即回发确认数据包的方式,能确保在接收网关一侧花费的时间最少,降低计算出来的时延的误差。
实施例三:
参见图3,本实施例提供一种网关设备,包括:
生成模块31,用于生成测试数据包;
第一发送模块32,用于发送测试数据包,控制其沿待诊断传输路径传输至接收网关,并记录测试数据包的发送时间;
第一接收模块33,用于接收确认数据包,记录确认数据包的接收时间;确认数据包为接收网关沿待诊断传输路径返回的对测试数据包的反馈;
计算模块34,用于根据发送时间和接收时间计算待诊断传输路径的时延。
本实施例中,计算模块34使用的发送时间和接收时间是由第一发送模块32和第一接收模块33记录的,第一发送模块32和第一接收模块33在同一设备中,使用的时间标准相同,所以发送时间和接收时间自然是相对于同一标准的时间。由于在本实施例中,不涉及接收网关的时间,所以接收网关的时间标准和其接收测试数据包的时间对本实施例的时延的计算没有任何的影响。
本实施例对生成模块31生成的测试数据包的类型没有限制,测试数据包包括本身就能在待诊断传输路径上传输的数据包,比如,能在RTP包的传输路径中传输的RTP包或RTCP包;或在某种控制手段下能沿待诊断传输路径传输的数据包,例如在某种控制手段下沿待诊断传输路径传输的自定义数据包。
当生成模块31生成的测试数据包是RTP包或RTCP包时,由于RTP包和RTCP包本身就是沿着RTP包的传输路径传输的,即RTP包和RTCP包本身就沿待诊断传输路径传输,所以对于测试数据包为RTP包或RTCP包的情况而言,第一发送模块32所做的就是发送RTP包或RTCP包到接收网关,记录发送RTP包或RTCP包的发送时间。
当生成模块31生成的测试数据包是自定义数据包时,为了实现测试数据包沿待诊断传输路径传输的目的,第一发送模块32可以通过确定发送网关到接收网关之间的待诊断传输路径的转发节点,控制测试数据包沿路径上的转发节点依次转发到达接收网关。进一步地,第一发送模块32可以将待诊断传输路径的转发节点的信息写入测试数据包中,待诊断传输路径上的每一个转发节点收到该测试数据包之后,可以根据测试数据包中的转发节点的信息,将该测试数据包转发到下一跳转发节点,实现测试数据包沿待诊断传输路径传输的目的,同时确保计算模块34计算的时延的正确性。在上述的分析中,可以发现,将RTP包或RTCP包作为测试数据包使用时,第一发送模块32直接发送数据包即可,方法简单,而将自定义数据包作为测试数据包使用时,还需要对其传输路径做限制,相对于RTP包和RTCP包而言,其使用较为复杂,不如RTP包和RTCP包使用方便。
可以想到的是,接收网关收到数据包之后,会先判断其是否为测试数据包,如果是,接收方网关会立即沿待诊断传输路径返回一个确认数据包,以便发送网关记录确认数据包的接收时间。本实施例中的确认数据包的来源包括但不限于:直接将识别出来的测试数据包作为确认数据包沿待诊断路径回发到发送网关,或者针对测试数据包重新生成数据包作为确认数据包,沿待诊断传输路径回发到发送网关。这里的重新生成数据包可以参考实施例一生成测试数据包的相关描述,确认数据包也可分为RTP包、RTCP包和自定义数据包。当接收网关回发的确认数据包属于RTP包或RTCP包时,接收网关只需执行发送确认数据包的操作,确认数据包即可沿待诊断传输路径传输至发送网关,当回发的确认数据包属于自定义数据包时,控制其沿待诊断传输路径回发至发送网关的方法,可以参考上述第一发送模块32将自定义数据包沿待诊断传输路径发送至接收网关的相关描述。
一般而言,在接收网关收到数据包之后,需要进行测试数据包的判断,才能回发确认数据包,该判断的过程实际上也是需要一定的时间。所以,本实施例中计算模块34计算的待诊断传输路径的时延实际上也包括接收网关的判断时间,但是一般而言,该判断时间相对于数据包在待诊断传输路径的传输时间时很短暂的,所以可以忽略该识别时间对时延的误差影响。若为了使得本实施例的待诊断传输路径的时延更准确,进一步地,计算模块34可以从时延中去除接收网关的判断时间。该判断时间的确定可以参考实施例一中的相关描述。
可以想到的,当生成模块31生成的测试数据包是RTP包或RTCP包时,该RTP包或RTCP包需满足能与普通RTP包或RTCP包区分开的条件,接收网关才能判断收到的RTP包或RTCP包是否为测试数据包。为了能将作为测试数据包的RTP包或RTCP包与普通RTP包或RTCP包区分开,生成模块31生成测试数据包时,可以先复制一个RTP包或RTCP包,然后修改RTP包的包头信息或修改RTCP包的包头信息,将修改后的RTP包或修改后的RTCP包作为测试数据包使用。对应的,接收网关识别测试数据包的标准可以包括判断RTP包或RTCP包的包头信息是否被被修改。为了进一步保证判断的准确性,生成模块31在生成测试数据包时,可以将包头中的特定信息修改为预设的判断值,接收网关只要根据该数据包的包头中的特定信息是否被修改为预设的判断值,即可判断该数据包是否为测试数据包。
以RTP包为例,生成模块31在生成测试数据包时,可以先复制当前时刻将要发送的RTP包,再将其中一个RTP包包头中的PT值修改为126,第一发送模块32发送该修改后的RTP包,记录发送时间,并将原始的RTP包也发送给接收网关,以便保证语音通话的正常。接收网关在接收到RTP包后,若识别出RTP包的PT值为正常的RTP包的PT值,对该RTP包的内容进行解压缩、解码等操作,还原出模拟语音信号;若识别出包头中的PT值为126,就可以判断该RTP包为测试数据包,然后立即回发确认数据包。为了回发操作的简单,以及回发路径确保为待判断传输路径,可以直接将判断为测试数据包的RTP包回发给发送网关,发送网关的第一接收模块33收到PT值为126的RTP包后,记录接收时间,根据该RTP包的发送时间和接收时间可以计算出待判断传输路径的环回时延,待判断传输路径的单向时延是该环回时延的一半。
当生成模块31生成的测试数据包是自定义数据包时,因为没有原始的数据包作对比,接收网关不能根据接收的自定义数据包的包头信息是否改变来判断其是否为测试数据包。此时,可以在自定义数据包中写入指示信息指示其身份,并指示接收网关执行回发测试数据包。优选的,生成模块31在生成测试数据包时,可以生成带有返回指令的自定义数据包作为测试数据包,该返回指令用于指示接收网关在收到测试该数据包后,立即沿待判断传输路径回发确认数据包。由此,在接收网关收到带有返回指令的数据包后,可以根据该返回指令确定该数据包为测试数据包。
下面以发送网关设备A和接收网关设备B为例,对诊断语音时延做出详细的解释。参见图4,是利用本实施例的发送网关实现本端话机和远端话机之间通话的系统构架图。包括发送网关设备A、信令服务器、接收网关设备B、本端话机A、远端话机B。
发送网关设备A、接收网关设备B是一种以网关为核心综合系统产品,包括但不受限于以下种类:各种上行的家庭网关及其上行设备、中继网关及其下挂用户接口设备、接入网关等。其中核心的网关能直接下挂话机,上行能直接或间接连接以太网。呼叫信令服务器是一种处理通话信令的设备,包括但不受限于sip服务器、软交换等。
假设发送网关设备A生成的测试数据包是RTP包,生成的方式是将RTP包的PT黑值修改为126。参见图5,图5利用图4中的系统实现时延诊断的流程图,具体的语音时延过程包括:
S501、对语音模拟信号进行采样,打包形成RTP包;
S502、在发送RTP媒体流时,检测语音延时诊断发送开关是否使能,如果是,进入S503,如果否,进入S510;
S503、发送网关设备A拷贝一份当前RTP包数据;
S504、发送网关设备A修改RTP包头中的PT值为126;
S505、发送网关设备A发送修改后的RTP包给接收网关设备B,记录当前的系统时间T1,并发送原始的RTP包,关闭语音时延诊断发送开关,使能语音时延诊断接收开关,以处理回复的RTP包;
S506、接收网关设备B接收到RTP报文,判断PT值是否为126,如果是,进入S507,如果否,进入S510;
S507、对收到的RTP包不做任何修改,立即回发给发送网关设备A;
S508、发送网关设备A收到接收网关设备B发送的RTP包,判断PT值是否为126,如果是,进入S509,如果否,进入S510;
S509、记录接收RTP包的时间T2,关闭语音时延诊断接收开关,计算T2-T1的结果,并将时延诊断结果返回给人机界面;
S510、正常语音处理。
采用本实施例的网关设备,第一发送模块能控制测试数据包沿待诊断传输路径传输,第一接收模块接收沿待诊断传输路径回发的确认数据包,测试数据包和确认数据包均沿待诊断传输路径传输,可以确保诊断的时延属于待诊断传输路径的时延,相对于现有技术中,需要发送RTCP包的发送方和接收方时间同步的限定,本实施例由同一侧记录测试数据包的发送时间和确认数据包的接收时间,满足了发送时间和接收时间是同一时间标准的需求,所以本实施例中,计算语音时延,不受发送网关和接收网关时间同步的限制。
实施例四:
参见图6,本实施例提出一种网关设备,包括:
第二接收模块61,用于接收发送网关沿待诊断传输路径上传输的数据包;
判断模块62,用于判断接收的数据包是否为测试数据包;
第二生成模块63,用于在判断模块的判断结果为是时,生成对测试数据包的确认数据包;
第二发送模块64,用于沿待诊断传输路径回发确认数据包至发送网关。
本实施例的诊断语音时延的方法适用于VOIP,在VOIP通信中,语音数据的传输路径就是RTP包的传输路径,所以可以理解的是,本实施例中,诊断语音时延的方法涉及的时延主要是VOIP语音通信中,RTP包的传输路径的时延,所以本实施例的待判断传输路径可以理解为RTP包的传输路径。
本实施例中,判断模块62判断出来的测试数据包包括本身就是在待诊断传输路径上传输的数据包,比如,在RTP包的传输路径中传输的RTP包或RTCP包;或在某种控制手段下能沿待诊断传输路径传输的数据包,例如在某种控制手段下沿待诊断传输路径传输的自定义数据包。
判断模块62判断测试数据包的规则是对应于发送网关生成测试数据包的方式的,例如,若发送网关生成测试数据包的方式是修改现有的RTP包或RTCP包,则在第二接收模块61收到数据包后,判断模块62可以先判断数据包是否为RTP包或RTCP包,再根据RTP包或RTCP包是否被修改判断收到的数据包是否为测试数据包。若发送网关生成测试数据包的方式是生成携带返回指令的自定义数据包,返回指令指示接收网关收到数据包后回发确认数据包,则在第二接收模块61收到数据包后,判断模块62可以通过判断数据包中是否携带返回指令,判断该数据包是否为测试数据包。
以RTP包为例,若发送网关在生成测试数据包时的方式是,将RTP包头中的某个信息例如PT值进行修改,例如修改为126,判断模块62识别测试数据包的规则与发送网关生成测试数据包的方式相对应,即判断模块62判断RTP包中的PT值是否为126,若是,则该RTP包为测试数据包。
可以想到的是,本实施例的确认数据包可以是RTP包、RTCP包或自定义数据包。第二生成模块63生成确认数据包的方法包括:收到测试数据包后,针对该测试数据包重新生成一个新的数据包作为确认数据包。可以想到的是,本实施例重新生成的确认数据包可以是RTP包、RTCP包或自定义数据包,生成过程可以参考实施例一中的相关描述。
当确认数据包是RTP包或RTCP包时,第二发送模块64执行发送RTP包或RTCP包到接收网关的操作,此时,确认数据包的传输路径就是待判断传输路径。当确认数据包是自定义数据包时,第二发送模块64需要设置确认数据包的传输路径的转发节点等信息,控制确认数据包沿待判断传输路径回发至发送网关,具体的控制方式可以参考实施例一中控制测试数据包沿待诊断传输路径传输的相关描述。
此外,第二生成模块63生成确认数据包的方式还包括直接将识别出来的测试数据包作为确认数据包沿待判断传输路径回发给发送网关,采用此方法不用预先生成确认数据包,避免浪费网关资源。尤其是在发送网关发送的测试数据包是RTP包或RTCP包的情况下,第二发送模块64沿待诊断传输路径回发确认数据包至发送网关实际上就是,发送RTP包或RTCP包到发送网关,由于回发的RTP包或RTCP包本身就属于能在待诊断传输路径上传输的数据包,所以无需采用其他控制手段控制确认数据包的回发路径为待诊断传输路径。
采用本实施例的网关设备,可以在识别出测试数据包后,立即沿待诊断传输路径回发确认数据包,以便发送网关能确定确认数据包的接收时间,测试数据和确认数据均在待诊断传输路径上传输,可以确保计算的时延属于待诊断传输路径的时延,其次,接收网关识别出测试数据包后立即回发确认数据包的方式,能减少接收网关一侧返回确认数据包所需的时间,有利于降低发送网关计算的时延的误差。
显然,本领域的技术人员应该明白,上述本发明的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,可选地,它们可以用计算装置可执行的程序代码来实现,从而,可以将它们存储在存储介质(ROM/RAM、磁碟、光盘)中由计算装置来执行,并且在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。所以,本发明不限制于任何特定的硬件和软件结合。
以上内容是结合具体的实施方式对本发明所作的进一步详细说明,不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干简单推演或替换,都应当视为属于本发明的保护范围。
Claims (10)
1.一种诊断语音时延的方法,包括:
生成测试数据包;
发送所述测试数据包,控制其沿待诊断传输路径传输至接收网关,并记录所述测试数据包的发送时间;
接收确认数据包,记录所述确认数据包的接收时间;所述确认数据包为所述接收网关沿待诊断传输路径返回的对所述测试数据包的反馈;
根据所述发送时间和所述接收时间计算所述待诊断传输路径的时延。
2.如权利要求1所述的诊断语音时延的方法,其特征在于,所述测试数据包包括RTP包,RTCP包和自定义数据包。
3.如权利要求2所述的诊断语音时延的方法,其特征在于,当所述测试数据包为RTP包时,所述生成测试数据包包括,修改RTP包的包头信息,将修改后的RTP包作为测试数据包;
当所述测试数据包为RTCP包时,所述生成测试数据包包括,修改RTCP包的包头信息,将修改后的RTCP包作为测试数据包;
当所述测试数据包为自定义数据包时,所述生成测试数据包包括,生成带有返回指令的自定义数据包作为测试数据包,所述返回指令用于指示接收网关在收到所述测试数据包后,沿所述待诊断传输路径回发确认数据包。
4.如权利要求1-3任一项所述的诊断语音时延的方法,其特征在于,所述确认数据包包括所述测试数据包。
5.一种诊断语音时延的方法,包括;
接收发送网关沿待诊断传输路径上传输的数据包;
判断接收的所述数据包是否为测试数据包;
如果是,则生成对所述测试数据包的确认数据包;
沿所述待诊断传输路径回发确认数据包至所述发送网关。
6.一种网关设备,其特征在于,包括:
生成模块,用于生成测试数据包;
第一发送模块,用于发送所述测试数据包,控制其沿待诊断传输路径传输至接收网关,并记录所述测试数据包的发送时间;
第一接收模块,用于接收确认数据包,记录所述确认数据包的接收时间;所述确认数据包为所述接收网关沿待诊断传输路径返回的对所述测试数据包的反馈;
计算模块,用于根据所述发送时间和所述接收时间计算所述待诊断传输路径的时延。
7.如权利要求6所述的诊断语音时延的网关,其特征在于,所述生成模块生成的测试数据包包括RTP包,RTCP包和自定义数据包。
8.如权利要求7所述的诊断语音时延的网关,其特征在于,所述生成模块用于,
当所述测试数据包为RTP包时,修改RTP包的包头信息,将修改后的RTP包作为测试数据包;
当所述测试数据包为RTCP包时,修改RTCP包的包头信息,将修改后的RTCP包作为测试数据包;
当所述测试数据包为自定义数据包时,生成带有返回指令的自定义数据包作为测试数据包,所述返回指令用于指示接收网关在收到所述测试数据包后,沿所述待诊断传输路径回发确认数据包。
9.如权利要求6-8任一项所述的诊断语音时延的网关,其特征在于,所述确认数据包包括所述测试数据包。
10.一种网关设备,其特征在于,包括:
第二接收模块,用于接收发送网关沿待诊断传输路径上传输的数据包;
判断模块,用于判断接收的所述数据包是否为测试数据包;
第二生成模块,用于在判断模块的判断结果为是时,生成对所述测试数据包的确认数据包;
第二发送模块,用于沿所述待诊断传输路径回发确认数据包至所述发送网关。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610382565.XA CN107453936A (zh) | 2016-06-01 | 2016-06-01 | 一种诊断语音时延的方法和网关设备 |
PCT/CN2017/085574 WO2017206767A1 (zh) | 2016-06-01 | 2017-05-23 | 一种诊断语音时延的方法、网关设备和计算机存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610382565.XA CN107453936A (zh) | 2016-06-01 | 2016-06-01 | 一种诊断语音时延的方法和网关设备 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN107453936A true CN107453936A (zh) | 2017-12-08 |
Family
ID=60478493
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201610382565.XA Pending CN107453936A (zh) | 2016-06-01 | 2016-06-01 | 一种诊断语音时延的方法和网关设备 |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN107453936A (zh) |
WO (1) | WO2017206767A1 (zh) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109802898A (zh) * | 2019-02-01 | 2019-05-24 | 深圳市比速智网技术有限公司 | 多链路数据传输方法、接收装置及存储介质 |
CN110300036A (zh) * | 2019-06-25 | 2019-10-01 | 广州小鹏汽车科技有限公司 | 通话网络延时测试方法和测试系统 |
CN112365902A (zh) * | 2020-10-16 | 2021-02-12 | 科大讯飞股份有限公司 | 语音处理系统的测试方法及相关设备、存储装置 |
CN113436610A (zh) * | 2020-03-23 | 2021-09-24 | 阿里巴巴集团控股有限公司 | 测试方法、装置及系统 |
CN113519146A (zh) * | 2020-02-12 | 2021-10-19 | 深圳元戎启行科技有限公司 | 流媒体网络时延确定方法、装置、计算机设备、可读存储介质和远程驾驶系统 |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117395277B (zh) * | 2023-10-13 | 2024-04-12 | 广州锡杨电子股份有限公司 | 工控机与数据监测系统 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101340441B (zh) * | 2008-08-19 | 2011-12-07 | 中兴通讯股份有限公司 | 一种测量ip网上数据包服务质量的方法和系统 |
CN101729300A (zh) * | 2008-10-28 | 2010-06-09 | 华为技术有限公司 | 一种传送测试数据包的方法和系统 |
CN103067217B (zh) * | 2012-12-14 | 2015-11-18 | 北京思特奇信息技术股份有限公司 | 一种通信网络服务质量的指示系统及方法 |
CN105071980A (zh) * | 2015-07-13 | 2015-11-18 | 中国传媒大学 | 内通语音通讯延迟测量方法 |
-
2016
- 2016-06-01 CN CN201610382565.XA patent/CN107453936A/zh active Pending
-
2017
- 2017-05-23 WO PCT/CN2017/085574 patent/WO2017206767A1/zh active Application Filing
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109802898A (zh) * | 2019-02-01 | 2019-05-24 | 深圳市比速智网技术有限公司 | 多链路数据传输方法、接收装置及存储介质 |
CN110300036A (zh) * | 2019-06-25 | 2019-10-01 | 广州小鹏汽车科技有限公司 | 通话网络延时测试方法和测试系统 |
CN113519146A (zh) * | 2020-02-12 | 2021-10-19 | 深圳元戎启行科技有限公司 | 流媒体网络时延确定方法、装置、计算机设备、可读存储介质和远程驾驶系统 |
CN113436610A (zh) * | 2020-03-23 | 2021-09-24 | 阿里巴巴集团控股有限公司 | 测试方法、装置及系统 |
CN112365902A (zh) * | 2020-10-16 | 2021-02-12 | 科大讯飞股份有限公司 | 语音处理系统的测试方法及相关设备、存储装置 |
Also Published As
Publication number | Publication date |
---|---|
WO2017206767A1 (zh) | 2017-12-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN107453936A (zh) | 一种诊断语音时延的方法和网关设备 | |
CN103428627B (zh) | 物联网系统中数据的传送方法、物联网系统及相应装置 | |
CN101517948B (zh) | 通信装置、通信方法和记录介质 | |
US7822018B2 (en) | Duplicate media stream | |
CN101146041A (zh) | 最小化分组网络上通话的端到端延迟的方法、系统和电路 | |
EP1158493A2 (en) | Concealing packet losses in a Voice of IP (VOIP) tranmission | |
US9112961B2 (en) | Audio quality analyzing device, audio quality analyzing method, and program | |
WO2006075390A1 (ja) | 中継方法、中継装置、通信システム及びコンピュータプログラム | |
US9767802B2 (en) | Methods and apparatus for conducting internet protocol telephony communications | |
CN101790754B (zh) | 用于提供amr-wb dtx同步的系统和方法 | |
CN106507024A (zh) | 一种自适应码率调整方法及装置 | |
CN101855875B (zh) | 在基于因特网协议的媒体网络中进行双音多频信号转换的方法和装置 | |
US20100262690A1 (en) | Recording communications | |
CN101114987A (zh) | 语音前向纠错信息传输在cdma2000系统中的实现方法 | |
CN109842821A (zh) | 一种视频数据传输的方法和装置 | |
CN101043756B (zh) | 核心网ip化后特殊业务的处理方法、装置及系统 | |
CN110191022A (zh) | 一种业务质量检测方法及装置 | |
JP2004266378A (ja) | パケット伝送装置 | |
CN101800680A (zh) | 一种电信系统测试装置及测试方法 | |
CN109039814B (zh) | 一种协议测试方法及装置 | |
JP3622694B2 (ja) | VoIPシステムおよびその試験方法 | |
CN100442702C (zh) | 实现调制解调器信号故障分析的方法及装置 | |
CN104184570A (zh) | 通讯系统和方法 | |
US9319874B2 (en) | Automatic channel pass-through | |
CN102255793B (zh) | 一种处理双音多频的方法及其装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
WD01 | Invention patent application deemed withdrawn after publication | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20171208 |