CN109587096A - 一种识别rtp尾部丢包的方法及装置 - Google Patents
一种识别rtp尾部丢包的方法及装置 Download PDFInfo
- Publication number
- CN109587096A CN109587096A CN201710898612.0A CN201710898612A CN109587096A CN 109587096 A CN109587096 A CN 109587096A CN 201710898612 A CN201710898612 A CN 201710898612A CN 109587096 A CN109587096 A CN 109587096A
- Authority
- CN
- China
- Prior art keywords
- rtp
- link
- moment
- packet loss
- data flow
- 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.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明实施例提供一种识别RTP尾部丢包的方法及装置。所述方法包括:获取同一链路的RTP数据流和SIP信令;根据所述RTP数据流中最后传输的RTP包,确定所述RTP数据流的传输结束时刻;根据所述SIP信令确定所述链路对应的通话结束时刻;根据所述传输结束时刻和所述通话结束时刻,判断所述链路是否存在RTP尾部丢包。本发明实施例提供的识别RTP尾部丢包的方法,通过同一链路中的RTP数据流的传输结束时刻和通话结束时刻,判断链路是否存在RTP尾部丢包,解决了RTP尾部丢包检测问题,能够准确地评估网络内的RTP丢包情况,进而提高了对网络传输质量评估的正确率,有助于网络维护和优化。
Description
技术领域
本发明实施例涉及网络通信技术领域,具体涉及一种识别RTP尾部丢包的方法及装置。
背景技术
VoLTE是基于IP多媒体子系统(IP Multimedia Subsystem,IMS)的语音业务,实时传输协议(Real-time Transport Protocol,RTP)是VoLTE中的网络传输协议,RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议从上层接收流媒体信息码流,装配成RTP数据包(简称RTP包)发送给下层,实现音视频传输。为检验VoLTE网络传输质量,需要对RTP包进行校验,计算丢包率,以评估VoLTE网络传输质量。
在RTP包的包头中包含RTP包的序列号(Sequence Number),占16位,用于标识发送者所发送的RTP包的序列号,每发送一个RTP包,序列号加1。目前RTP的丢包检测使用序列号进行检测,获取RTP包,解析该RTP包,判断RTP包的序列号与上一个RTP包的序列号是否连续,连续则表示未丢包,否则丢包。根据RTP丢包数与RTP包的总数的比值计算RTP丢包率。
现有的RTP丢包检测技术需要通过后一个RTP包的序列号和前一个RTP包的序列号进行比较后判断,如果没有后续RTP包则认为该RTP流传输完成,不再进行丢包检测。然而,如果RTP流尾部的RTP包全部丢失,现有的RTP丢包检测方法将无法发现,从而导致丢包率计算错误,影响对VoLTE网络传输质量的评估。
发明内容
针对现有技术中的缺陷,本发明实施例提供了一种识别RTP尾部丢包的方法及装置。
第一方面,本发明实施例提供一种识别RTP尾部丢包的方法,包括:
获取同一链路的RTP数据流和SIP信令;
根据所述RTP数据流中最后传输的RTP包,确定所述RTP数据流的传输结束时刻;
根据所述SIP信令确定所述链路对应的通话结束时刻;
根据所述传输结束时刻和所述通话结束时刻,判断所述链路是否存在RTP尾部丢包。
第二方面,本发明实施例提供一种识别RTP尾部丢包的装置,包括:
获取模块,用于获取同一链路的RTP数据流和SIP信令;
第一确定模块,用于根据所述RTP数据流中最后传输的RTP包,确定所述RTP数据流的传输结束时刻;
第二确定模块,用于根据所述SIP信令确定所述链路对应的通话结束时刻;
判断模块,用于根据所述传输结束时刻和所述通话结束时刻,判断所述链路是否存在RTP尾部丢包。
第三方面,本发明实施例提供一种电子设备,包括:
存储器和处理器,所述处理器和所述存储器通过总线完成相互间的通信;所述存储器存储有可被所述处理器执行的程序指令,所述处理器调用所述程序指令能够执行如下方法:获取同一链路的RTP数据流和SIP信令;根据所述RTP数据流中最后传输的RTP包,确定所述RTP数据流的传输结束时刻;根据所述SIP信令确定所述链路对应的通话结束时刻;根据所述传输结束时刻和所述通话结束时刻,判断所述链路是否存在RTP尾部丢包。
第四方面,本发明实施例提供一种存储介质,其上存储有计算机程序,该计算机程序被处理器执行时实现如下方法:获取同一链路的RTP数据流和SIP信令;根据所述RTP数据流中最后传输的RTP包,确定所述RTP数据流的传输结束时刻;根据所述SIP信令确定所述链路对应的通话结束时刻;根据所述传输结束时刻和所述通话结束时刻,判断所述链路是否存在RTP尾部丢包。
本发明实施例提供的识别RTP尾部丢包的方法,通过同一链路中的RTP数据流的传输结束时刻和通话结束时刻,判断链路是否存在RTP尾部丢包,解决了RTP尾部丢包检测问题,能够准确地评估网络内的RTP丢包情况,进而提高了对网络传输质量评估的正确率,有助于网络维护和优化。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为现有技术中IMS网络中呼叫保持信令图;
图2为本发明实施例提供的识别RTP尾部丢包的方法流程示意图;
图3为本发明又一实施例提供的识别RTP尾部丢包的方法流程示意图;
图4为本发明实施例提供的识别RTP尾部丢包的装置;
图5为本发明实施例提供的电子设备的结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
图2为本发明实施例提供的识别RTP尾部丢包的方法流程示意图,如图1所示,所述方法包括:
步骤S11、获取同一链路的RTP数据流和SIP信令;
具体地,在IMS系统中,SIP(Session Initiation Protocol,会话初始协议)信令记录了VoLTE通话中的信令传输过程,例如INVITE请求、BYE请求等,RTP包携带音视频数据信息,通常在一组VoLTE通话中,存在多个RTP包。
在实际应用中通过网络侧的GM接口可以采集SIP信令,SIP信令包括了源IP、源端口、目的IP和目的端口,简称四元组信息,例如,源IP为网络IP,源端口为网络端口,目的IP为终端IP,目的端口为终端端口。通过网络侧的抓包工具可以抓取RTP包,RTP包包括源IP、源端口、目的IP和目的端口,多个RTP包构成了RTP数据流,RTP数据流既包括了RTP包,又包括了抓取该RTP包的时刻,记作抓取时刻。这样可以对采集到的SIP信令四元组信息和RTP包四元组信息进行匹配,获得同一链路的RTP数据流和SIP信令。
例如,终端IP、终端端口、网络IP、网络端口相同的RTP数据流和SIP信令为同一链路的RTP数据流和SIP信令,在一个链路中,包含一个终端,因此,VoLTE通话中,至少包括两个链路,一个为包含主叫终端的链路,另一个为包含被叫终端的链路。
步骤S12、根据所述RTP数据流中最后传输的RTP包,确定所述RTP数据流的传输结束时刻;
具体地,根据RTP数据流中最后传输的RTP包的抓取时刻,确定RTP数据流的传输结束时刻,例如,RTP数据流中,最后一个RTP包的抓取时刻为10:03:03:56,则该链路的RTP数据流的传输结束时刻为10:03:03:56。
在实际应用中,RTP数据流的识别通过两端的IP地址和端口进行识别,使用终端IP地址和端口作为发送端,接收端为网络IP地址和端口的为上行数据流,使用网络IP地址和端口作为发送端,接收端为终端IP地址和端口的为下行数据流,这样RTP数据流就可以分为上行数据流和下行数据流,获取上行数据流中最后传输的RTP包的抓取时刻,和下行数据流中最后传输的RTP包的抓取时刻,将上述两个抓取时刻中最晚的一个时刻作为RTP数据流的传输结束时刻。
步骤S13、根据所述SIP信令确定所述链路对应的通话结束时刻;
具体地,在一组VoLTE通话中,当用户选择挂机操作时,用户代理客户端(UserAgent Client,UAC)创建BYE请求,并向用户代理服务器(User Agent Server,UAS)发送BYE请求,在SIP协议中,UAC认为当BYE请求发送到客户端事物,则表明会话结束,因此也就停止发送或接收媒体流,即RTP包停止传输。在本发明实施例中,当链路的终端为主动挂机终端,BYE请求是终端UAC发出的,因此以该终端UAC发送BYE请求时间点作为该链路的通话结束时刻;若链路的终端为被动挂机终端,则BYE请求是该终端UAS接收的,因此以该终端UAS接收BYE请求的时间点作为该链路的通话结束时刻。
步骤S14、根据所述传输结束时刻和所述通话结束时刻,判断所述链路是否存在RTP尾部丢包。
具体地,根据RTP数据流传输结束时刻和通话结束时刻,判断该链路是否存在RTP尾部丢包,例如,待识别链路包含主动挂机终端,则将该链路的SIP信令中,UAC发送BYE请求的时间点作为该链路的通话结束时刻,根据该通话结束时刻和传输结束时刻判断链路是否存在RTP尾部丢包。
本发明实施例提供的识别RTP尾部丢包的方法,通过同一链路中的RTP数据流的传输结束时刻和通话结束时刻,判断链路是否存在RTP尾部丢包,解决了RTP尾部丢包检测问题,能够准确地评估网络内的RTP丢包情况,进而提高了对网络传输质量评估的正确率,有助于网络维护和优化。
在上述实施例的基础上,进一步地,所述根据所述传输结束时刻和所述通话结束时刻,判断所述链路是否存在RTP尾部丢包,包括:
若判断获知所述传输结束时刻在所述通话结束时刻之前,则根据所述SIP信令判断所述链路对应的通话是否存在呼叫保持信息,根据所述呼叫保持信息判断所述链路是否存在RTP尾部丢包。
一般地,在VoLTE中,当通话结束时,RTP包停止传输,但是当链路中存在呼叫保持信息时,若链路中包含呼叫保持请求终端,则在呼叫保持建立后,链路中的RTP传输中止,此时若被保持方等待时间较长而主动挂机拆链的话,从现象上看,RTP传输结束时刻早于通话结束时刻,这种是正常现象,不应该归于RTP尾部丢包。
具体地,图1为现有技术中IMS网络中呼叫保持信令图,如图1所示,呼叫保持过程包括:
步骤S21、用户终端A向终端A代理服务器(Proxy-Call Session ControlFuntion,P-CSCF)发送INVITE请求,该INVITE请求携带sendonly参数,表示用户终端A发起呼叫保持;
具体地,P-CSCF是IMS中用户在信令平面的第一个联系节点,从SIP的角度来看,它是一个出站/入站的SIP代理服务器,所有的SIP信令,无论是来自用户设备,还是发送给用户设备的,都必须经过P-CSCF。终端使用本地服务呼叫会话控制功能(Serving-CallSession Control Function,CSCF)发现机制可以获得P-CSCF的地址。P-CSCF负责验证请求,将它转发给指定的目标,并且处理和转发响应。
步骤S22、终端A的P-CSCF向会话控制服务器(Serving-Call Session ControlFunction,S-CSCF)转发该INVITE请求;
步骤S23、S-CSCF向应用服务器(AS)转发该INVITE请求;
步骤S24、AS向资源服务器(Multimedia Resource Function,MRF)转发该INVITE请求,MRF预留资源;
步骤S25、AS向S-CSCF转发该INVITE请求,表示资源预留完成;
步骤S26、S-CSCF向终端B的代理服务器P-CSCF B转发该INVITE请求;
步骤S27、P-CSCF B向终端B转发该INVITE请求;
步骤S28、终端B响应该INVITE请求,向P-CSCF B回复200OK响应信息,并设置参数为recvonly,表示终端B只收不发,是听保持音;
步骤S29、P-CSCF B向S-CSCF转发200OK响应信息;
步骤S210、S-CSCF向AS转发200OK响应信息;
步骤S211、AS指示MRF向终端B播放声音文件;
步骤S212、AS向S-CSCF转发200OK响应信息,表示已经向终端B播放声音文件;
步骤S213、S-CSCF向P-CSCF A转发200OK响应信息;
步骤S214、P-CSCF A向终端A转发200OK响应信息;
步骤S215、终端A响应该200OK响应信息,向P-CSCF A发送ACK确认消息;
步骤S216、P-CSCF A向S-CSCF转发ACK确认消息;
步骤S217、S-CSCF向AS转发ACK确认消息;
步骤S218、AS向MRF发送ACK确认消息,MRF确认后,AS向S-CSCF转发ACK消息;
步骤S219、S-CSCF向P-CSCF B转发ACK消息;
步骤S220、P-CSCF B向终端B转发ACK消息。
至此,呼叫保持建立完成。用户终端A为呼叫保持发起终端,用户终端B为被呼叫保持终端。
若链路中包含呼叫保持发起终端,则在呼叫保持建立后,链路停止传输RTP包,即上行数据流和下行数据流均停止传输RTP包。此时若判断获知传输结束时刻在通话结束时刻之前,则解析SIP信令,获取终端接收200ok的时刻作为第一时刻,对比RTP传输结束时刻与第一时刻,若RTP传输结束时刻早于第一时刻第一预设时长,例如RTP传输结束时刻早于第一时刻1s,则表明该链路存在RTP尾部丢包。在实际应用中,由于以上行数据流和下行数据流中最后一个传输的RTP包的抓取时刻为RTP数据流的传输结束时刻,因此,当RTP传输结束时刻早于第一时刻第一预设时长,表明该链路的上行数据流和下行数据流均存在RTP尾部丢包。
若RTP传输结束时刻不早于第一时刻第一预设时长,还需要判断上行数据流的传输结束时刻与下行数据流的传输结束时刻,只有上行数据流的传输结束时刻与下行数据流的传输结束时刻都不早于第一时刻第一预设时长,且上行数据流的传输结束时刻与下行数据流的传输结束时刻都不早于通话结束时刻,才表明该链路不存在RTP尾部丢包。
若链路中包含被呼叫保持终端,则无论链路所对应的通话是否存在呼叫保持,该链路的RTP传输结束时刻都应该与通话结束时刻相同,这是由于呼叫保持建立后,上行数据流不再传输RTP包,但是下行数据流仍然传输RTP包,该链路的RTP传输结束时刻以上下行数据流中最晚的RTP包的抓取时刻为准,此时,若RTP传输结束时刻在通话结束时刻之前,则表明链路存在RTP尾部丢包,若上行传输结束时刻和下行传输结束时刻都不在通话结束时刻之前,则表明链路不存在RTP尾部丢包。
此外,若通过对SIP信令解析获知,链路中不存在呼叫保持,则若判断获知RTP数据流的传输结束时刻在通话结束时刻之前,则确定述链路存在RTP尾部丢包。
例如,链路的上行数据流的传输结束时刻为16:00:04:02,下行数据流的传输结束时刻为16:00:04:08,则该链路的RTP数据流的传输结束时刻为16:00:04:08,此时,若该链路的通话结束时刻为16:01:04:19,则判断链路中是否存在呼叫保持信息,通过解析SIP信令,若链路中包含呼叫保持发起终端,则确定终端接收到200ok的时间为16:00:04:08,与RTP数据流的传输结束时刻相同,则表明该链路的上行数据流和下行数据流都不存在RTP尾部丢包。若通过解析SIP信令,确定链路中的终端为被呼叫保持终端,则由于RTP数据流的传输结束时刻早于通话结束时刻,因此,该链路的上行数据流和下行数据流都存在RTP尾部丢包。
本发明实施例提供的识别RTP尾部丢包的方法,通过判断同一链路中的RTP数据流的传输结束时刻是否在通话结束时刻之前,并根据SIP信令判断链路中是否存在呼叫保持信息,根据呼叫保持信息判断链路的上行数据流和下行数据流是否存在RTP尾部丢包,提高了识别RTP尾部丢包的正确率,进而提高了对网络传输质量评估的正确率,有助于网络维护和优化。
在上述各实施例的基础上,进一步地,所述根据所述传输结束时刻和所述通话结束时刻,判断所述链路是否存在RTP尾部丢包,还包括:
若判断获知所述传输结束时刻不在所述通话结束时刻之前,则确定所述RTP数据流的上行传输结束时刻和下行传输结束时刻;
根据公式:Tm=T2-T1,计算所述上行传输结束时刻与所述下行传输结束时刻的差值;
根据所述差值确定所述链路是否存在RTP尾部丢包;
其中,T1为所述上行传输结束时刻,T2为所述下行传输结束时刻。
具体地,若判断获知链路中RTP数据流的传输结束时刻不在通话结束时刻之前,则根据RTP数据流的上行数据流确定上行传输结束时刻T1,根据RTP数据流的下行数据流确定下行传输结束时刻T2,根据公式Tm=T2-T1计算上行传输结束时刻与下行传输结束时刻之间的差值Tm,根据该差值确定链路是否存在RTP尾部丢包,一般地,在同一链路中,上行数据流的传输结束时刻与下行数据流的传输结束时刻相近,若上行数据流的传输结束时刻与下行数据流的传输结束时刻之间的差值较大,则表明链路存在RTP尾部丢包,具体地,上行数据流的传输结束时刻与下行数据流的传输结束时刻的差值Tm为正数,则表明上行数据流存在RTP尾部丢包;上行数据流的传输结束时刻与下行数据流的传输结束时刻的差值Tm为负数,则表明下行数据流存在RTP尾部丢包。
例如,在网络侧获取RTP数据流,以终端IP地址和端口作为发送端,接收端为网络IP地址和端口的RTP数据流作为上行数据流,以网络IP地址和端口作为发送端,接收端为终端IP地址和端口的RTP数据流作为下行数据流,确定上行数据流的传输结束时刻和下行数据流的传输结束时刻,计算上行传输结束时刻与下行传输结束时刻的差值,根据差值确定所述是否存在RTP尾部丢包。
本发明实施例提供的识别RTP尾部丢包的方法,通过判断同一链路中的上行数据流的传输结束时刻和下行数据流的传输结束时刻,判断链路的上行数据流或下行数据流是否存在RTP尾部丢包,进一步提高了识别RTP尾部丢包的正确率,进而提高了对网络传输质量评估的正确率,有助于网络维护和优化。
在上述各实施例的基础上,进一步地,所述根据所述差值确定所述链路是否存在RTP尾部丢包,包括:
若判断获知所述差值大于预设阈值,则根据所述SIP信令判断所述链路对应的通话是否存在呼叫保持信息;
根据所述呼叫保持信息判断所述链路是否存在RTP尾部丢包。
具体地,终端A发起呼叫保持流程,终端A的AS通过sendonly参数判断终端A发起呼叫保持业务,通知MRF准备给被保持方(终端B)放音。终端B收到INVITE消息后,回复200ok,并将SDP中的a line设置为recvonly,代表只收不发(听保持音)。故在被保持方的媒体面,只有下行的RTP包而没有上行的RTP包,如果被保持方等待时间过长而主动挂机拆链的话,从现象上看,RTP包上行传输的结束时间要早于下行,这种情况是正常现象,不该归为尾部丢包。
具体地,根据SIP信令中INVITE请求是否携带sendonly参数确定通话是否存在呼叫保持信息,当通话中存在呼叫保持信息时,上行数据流的传输结束时刻与下行数据流的传输结束时刻不同,如果被保持方等待时间过长而主动挂机拆链的话,从现象上看,RTP数据流的上行传输结束时刻要早于RTP数据流的下行传输结束时刻,这种情况属于正常现象,不能归属于RTP尾部丢包。因此在本发明实施例中,若判断获知上行数据流的传输结束时刻与下行数据流的传输结束时刻的差值大于预设阈值,则根据SIP信令判断该链路对应的通话中是否存在呼叫保持信息,若通话中不存在呼叫保持信息,则确认链路存在RTP尾部丢包。
具体地,若通话中存在呼叫保持信息,则根据SIP信令确认链路对应的终端是否为被呼叫保持终端,如果是,则根据SIP信令确定终端发送200ok的时刻,作为第二时刻,若判断上行传输结束时刻与第二时刻相同,下行传输结束时刻晚于第二时刻,并且与通话结束时刻相同,则表明该链路不存在RTP尾部丢包。
若判断上行传输结束时刻早于第二时刻且下行传输结束时刻不早于通话结束时刻,则表明该链路中只有上行数据流存在RTP尾部丢包,若上行传输结束时刻与第二时刻相同,下行传输结束时刻早于通话结束时刻,则表明该链路中只有下行数据流存在RTP尾部丢包。
若通话中存在呼叫保持信息,根据SIP信令确认链路对应的终端为呼叫保持发起终端,此时若上行传输结束时刻与下行传输结束时刻的差值大于阈值,且下行传输结束时刻不早于通话结束时刻,则表明该链路中只有上行数据流存在RTP尾部丢包。
例如,上行传输结束时刻为10:06:00,下行传输结束时刻为10:06:23,则上行传输结束时刻与下行传输结束时刻的差值为23s,若预设阈值为1s,则需要判断链路中是否存在呼叫保持信息,若存在呼叫保持信息,则根据SIP信令判断链路终端为被呼叫保持终端,根据SIP信令获取终端发送200ok的时刻为10:06:00,则表明上行数据流不存在RTP尾部丢包。
若该链路中不存在呼叫保持,则表明上行数据流存在RTP尾部丢包。若上行传输结束时刻为10:06:23,下行传输结束时刻为10:06:00,则上行传输结束时刻与下行传输结束时刻的差值为-23s,表明该链路存在RTP尾部丢包,具体为下行数据流存在RTP尾部丢包。
在本发明实施例中,通过对在网络侧获取的SIP信令进行解析,若获知INVITE请求携带sendonly参数,则表示该链路存在呼叫保持,此时若上行数据流的结束时间在下行数据流的结束时间之前,且与呼叫保持启动时间相同,则表明这是正常的呼叫保持通话,不存在RTP尾部丢包。若INVITE请求未携带sendonly参数,则表示该链路没有呼叫保持,此时若上行数据流的结束时间在下行数据流的结束时间之前,则表明上行数据流存在RTP尾部丢包。
图3为本发明又一实施例提供的识别RTP尾部丢包的方法流程示意图,如图3所示,所述方法包括:
获取同一链路的RTP数据流和SIP信令,然后对通话结束时刻和RTP流传输结束时刻进行判断,若传输结束时刻早于通话结束时刻预设第一时长,则解析SIP信令,若通话中存在呼叫保持,则继续判断传输结束时刻是否早于呼叫保持启动时刻预设第二时长,若早于,则确定该链路存在RTP尾部丢包,若传输结束时刻不早于通话结束时刻预设第一尝试,则对RTP数据流的上行传输结束时刻和下行传输结束时刻进行判断,若上行传输结束时刻与下行传输结束时刻的差值大于预设阈值,例如,差值大于1s,则进行呼叫保持判断,若链路存在呼叫保持,则判断链路中上行传输结束时刻是否早于呼叫保持启动时刻预设第二时长,若早于则链路存在RTP尾部丢包,具体为上行传输存在RTP尾部丢包,否则链路不存在RTP尾部丢包。
在实际应用中,还可以对获取到的SIP信令进行解析,生成SIP-CALL表,在该表中,对每组VoLTE通话,设置独一无二的CALL-ID,SIP-CALL表包括主叫号码、被叫号码、通话起始/结束时间、呼叫保持标识、呼叫保持启动时刻等,SIP-CALL表中有四元组信息,RTP数据流中也有四元组信息,因此就能把RTP数据流与SIP-CALL表关联,进而关联主被叫号码、通话起始/结束时间等信息,这样通过读取SIP-CALL表就能确定同一链路的RTP数据流以及SIP信令、链路是否存在呼叫保持等信息,通过这些信息就可以判断该链路是否存在RTP尾部丢包。
本发明实施例提供的识别RTP尾部丢包的方法,通过判断链路中是否存在呼叫保持,将正常的上下行数据流结束时刻不一致的情况予以剔除,进一步提高了识别RTP尾部丢包的正确率,进而提高了对网络传输质量评估的正确率,有助于网络维护和优化。
图4为本发明实施例提供的识别RTP尾部丢包的装置,如图4所示,该装置包括:获取模块41、第一确定模块42、第二确定模块43和判断模块44,其中:
获取模块41用于获取同一链路的RTP数据流和SIP信令;第一确定模块42用于根据所述RTP数据流中最后传输的RTP包,确定所述RTP数据流的传输结束时刻;第二确定模块43用于根据所述SIP信令确定所述链路对应的通话结束时刻;判断模块44用于根据所述传输结束时刻和所述通话结束时刻,判断所述链路是否存在RTP尾部丢包。
具体地,获取模块41获取网络侧的GM接口采集到的SIP信令,SIP信令包括了源IP、源端口、目的IP和目的端口,简称四元组信息,获取模块41获取网络侧的抓包工具抓取的RTP包,RTP包包括源IP、源端口、目的IP和目的端口,多个RTP包构成了RTP数据流,RTP数据流既包括了RTP包,又包括了抓取该RTP包的时刻,记作抓取时刻。这样可以对采集到的SIP信令四元组信息和RTP包四元组信息进行匹配,获得同一链路的RTP数据流和SIP信令。第一确定模块42根据RTP数据流中最后传输的RTP包的抓取时刻,确定RTP数据流的传输结束时刻,RTP数据流的识别通过两端的IP地址和端口进行识别,使用终端IP地址和端口作为发送端,接收端为网络IP地址和端口的为上行数据流,使用网络IP地址和端口作为发送端,接收端为终端IP地址和端口的为下行数据流,这样RTP数据流就可以分为上行数据流和下行数据流,获取上行数据流中最后传输的RTP包的抓取时刻,和下行数据流中最后传输的RTP包的抓取时刻,将上述两个抓取时刻中最晚的一个时刻作为RTP数据流的传输结束时刻。当链路的终端为主动挂机终端,BYE请求是终端UAC发出的,因此第二确定模块43以该终端UAC发送BYE请求时间点作为该链路的通话结束时刻;若链路的终端为被动挂机终端,则BYE请求是UAS接收的,因此第二确定模块43以该终端UAS接收BYE请求的时间点作为该链路的通话结束时刻。判断模块44根据RTP数据流传输结束时刻和通话结束时刻,判断该链路是否存在RTP尾部丢包,例如,待识别链路包含主动挂机终端,则将该链路的SIP信令中,UAC发送BYE请求的时间点作为该链路的通话结束时刻,根据该通话结束时刻和传输结束时刻判断链路是否存在RTP尾部丢包。本发明实施例提供的装置,用于实现上述方法,其功能具体参照上述方法实施例,此处不再赘述。
本发明实施例提供的识别RTP尾部丢包的装置,通过同一链路中的RTP数据流的传输结束时刻和通话结束时刻,判断链路是否存在RTP尾部丢包,解决了RTP尾部丢包检测问题,能够准确地评估网络内的RTP丢包情况,进而提高了对网络传输质量评估的正确率,有助于网络维护和优化。
在上述实施例的基础上,进一步地,所述判断模块包括:
第一识别单元,用于若判断获知所述传输结束时刻在所述通话结束时刻之前,根据所述SIP信令判断所述链路对应的通话是否存在呼叫保持信息,根据所述呼叫保持信息判断所述链路是否存在RTP尾部丢包。
一般地,在VoLTE中,当通话结束时,RTP包停止传输,但是当链路中存在呼叫保持信息时,若链路中包含呼叫保持请求终端,则在呼叫保持建立后,链路中的RTP传输中止,此时若被保持方等待时间较长而主动挂机拆链的话,从现象上看,RTP传输结束时刻早于通话结束时刻,这种是正常现象,不应该归于RTP尾部丢包。
若链路中包含呼叫保持发起终端,则在呼叫保持建立后,链路停止传输RTP包,此时第一识别单元若判断获知所述传输结束时刻在所述通话结束时刻之前,则解析SIP信令,获取终端接收200ok的时刻作为第一时刻,对比RTP传输结束时刻与第一时刻,若RTP传输结束时刻早于第一时刻,则表明该链路存在RTP尾部丢包,若RTP传输结束时刻不早于第一时刻,则表明该链路不存在RTP尾部丢包。若链路中包含被呼叫保持终端,则无论链路所对应的通话是否存在呼叫保持,该链路的RTP传输结束时刻都应该与通话结束时刻相同,此时,若RTP传输结束时刻在通话结束时刻之前,则表明链路存在RTP尾部丢包,若RTP传输结束时刻不在通话结束时刻之前,则表明链路不存在RTP尾部丢包。
本发明实施例提供的装置,用于实现上述方法,其功能具体参照上述方法实施例,此处不再赘述。
本发明实施例提供的识别RTP尾部丢包的装置,通过判断同一链路中的RTP数据流的传输结束时刻是否在通话结束时刻之前,并根据SIP信令判断链路中是否存在呼叫保持信息,根据呼叫保持信息判断链路的上行数据流和下行数据流是否存在RTP尾部丢包,提高了识别RTP尾部丢包的正确率,进而提高了对网络传输质量评估的正确率,有助于网络维护和优化。
在上述各实施例的基础上,进一步地,所述判断模块还包括:
分析单元,用于若判断获知所述传输结束时刻不在所述通话结束时刻之前,则确定所述RTP数据流的上行传输结束时刻和下行传输结束时刻;
计算单元,用于根据公式:Tm=T2-T1,计算所述上行传输结束时刻与所述下行传输结束时刻的差值Tm;
处理单元,用于根据所述差值确定所述链路是否存在RTP尾部丢包;
其中,T1为所述上行传输结束时刻,T2为所述下行传输结束时刻。
具体地,分析单元若判断获知链路中RTP数据流的传输结束时刻不在通话结束时刻之前,则根据RTP数据流的上行数据流确定上行传输结束时刻T1,根据RTP数据流的下行数据流确定下行传输结束时刻T2,计算单元根据公式:Tm=T2-T1,计算上行传输结束时刻与下行传输结束时刻之间的差值Tm,处理单元根据该差值Tm确定链路是否存在RTP尾部丢包,一般地,在同一链路中,上行数据流的传输结束时刻与下行数据流的传输结束时刻相近,若上行数据流的传输结束时刻与下行数据流的传输结束时刻之间的差值较大,则表明链路存在RTP尾部丢包,具体地,上行数据流的传输结束时刻与下行数据流的传输结束时刻的差值Tm为正数,则表明上行数据流存在RTP尾部丢包;上行数据流的传输结束时刻与下行数据流的传输结束时刻的差值Tm为负数,则表明下行数据流存在RTP尾部丢包。本发明实施例提供的装置,用于实现上述方法,其功能具体参照上述方法实施例,此处不再赘述。
本发明实施例提供的识别RTP尾部丢包的装置,通过判断同一链路中的上行数据流的传输结束时刻和下行数据流的传输结束时刻,判断链路的上行数据流或下行数据流是否存在RTP尾部丢包,进一步提高了识别RTP尾部丢包的正确率,进而提高了对网络传输质量评估的正确率,有助于网络维护和优化。
在上述各实施例的基础上,进一步地,所述处理单元包括:
呼叫保持判断单元,用于若判断获知所述差值大于预设阈值,则根据所述SIP信令判断所述链路对应的通话是否存在呼叫保持信息;
第二识别单元,用于根据所述呼叫保持信息判断所述链路是否存在RTP尾部丢包。
具体地,当通话中存在呼叫保持时,上行数据流的传输结束时刻与下行数据流的传输结束时刻不同,如果被保持方等待时间过长而主动挂机拆链的话,从现象上看,RTP数据流的上行传输结束时刻要早于RTP数据流的下行传输结束时刻,这种情况属于正常现象,不能归属于RTP尾部丢包。因此在本发明实施例中,呼叫保持判断单元若判断获知上行数据流的传输结束时刻与下行数据流的传输结束时刻的差值大于预设阈值,则根据SIP信令判断该链路对应的通话中是否存在呼叫保持信息,第二识别单元根据所述呼叫保持信息判断所述链路是否存在RTP尾部丢包。
具体地,若通话中存在呼叫保持信息,第二识别单元则根据SIP信令确认链路对应的终端是否为被呼叫保持终端,如果是,则根据SIP信令确定终端发送200ok的时刻,作为第二时刻,若判断上行传输结束时刻与第二时刻相同,下行传输结束时刻晚于第二时刻,并且与通话结束时刻相同,则表明该链路不存在RTP尾部丢包。
若判断上行传输结束时刻早于第二时刻且下行传输结束时刻不早于通话结束时刻,则表明该链路中只有上行数据流存在RTP尾部丢包,若上行传输结束时刻与第二时刻相同,下行传输结束时刻早于通话结束时刻,则表明该链路中只有下行数据流存在RTP尾部丢包。
若通话中存在呼叫保持信息,根据SIP信令确认链路对应的终端为呼叫保持发起终端,此时若上行传输结束时刻与下行传输结束时刻的差值大于阈值,且下行传输结束时刻不早于通话结束时刻,则表明该链路中只有上行数据流存在RTP尾部丢包。本发明实施例提供的装置,用于实现上述方法,其功能具体参照上述方法实施例,此处不再赘述。
本发明实施例提供的识别RTP尾部丢包的装置,通过判断链路中是否存在呼叫保持,将正常的上下行数据流结束时刻不一致的情况予以剔除,进一步提高了识别RTP尾部丢包的正确率,进而提高了对网络传输质量评估的正确率,有助于网络维护和优化。
图5为本发明实施例提供的电子设备的结构示意图,如图5所示,所述设备包括:处理器(processor)501、存储器(memory)502和总线503;
其中,处理器501和存储器502通过所述总线503完成相互间的通信;
处理器501用于调用存储器502中的程序指令,以执行上述各方法实施例所提供的方法,例如包括:获取同一链路的RTP数据流和SIP信令;根据所述RTP数据流中最后传输的RTP包,确定所述RTP数据流的传输结束时刻;根据所述SIP信令确定所述链路对应的通话结束时刻;根据所述传输结束时刻和所述通话结束时刻,判断所述链路是否存在RTP尾部丢包。
本发明实施例公开一种计算机程序产品,所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序,所述计算机程序包括程序指令,当所述程序指令被计算机执行时,计算机能够执行上述各方法实施例所提供的方法,例如包括:获取同一链路的RTP数据流和SIP信令;根据所述RTP数据流中最后传输的RTP包,确定所述RTP数据流的传输结束时刻;根据所述SIP信令确定所述链路对应的通话结束时刻;根据所述传输结束时刻和所述通话结束时刻,判断所述链路是否存在RTP尾部丢包。
本发明实施例提供一种非暂态计算机可读存储介质,所述非暂态计算机可读存储介质存储计算机指令,所述计算机指令使所述计算机执行上述各方法实施例所提供的方法,例如包括:获取同一链路的RTP数据流和SIP信令;根据所述RTP数据流中最后传输的RTP包,确定所述RTP数据流的传输结束时刻;根据所述SIP信令确定所述链路对应的通话结束时刻;根据所述传输结束时刻和所述通话结束时刻,判断所述链路是否存在RTP尾部丢包。
本领域普通技术人员可以理解:实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成,前述的程序可以存储于一计算机可读取存储介质中,该程序在执行时,执行包括上述方法实施例的步骤;而前述的存储介质包括:ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
以上所描述的装置等实施例仅仅是示意性的,其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下,即可以理解并实施。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件。基于这样的理解,上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在计算机可读存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
最后应说明的是:以上各实施例仅用以说明本发明的实施例的技术方案,而非对其限制;尽管参照前述各实施例对本发明的实施例进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明的实施例各实施例技术方案的范围。
Claims (10)
1.一种识别RTP尾部丢包的方法,其特征在于,包括:
获取同一链路的RTP数据流和SIP信令;
根据所述RTP数据流中最后传输的RTP包,确定所述RTP数据流的传输结束时刻;
根据所述SIP信令确定所述链路对应的通话结束时刻;
根据所述传输结束时刻和所述通话结束时刻,判断所述链路是否存在RTP尾部丢包。
2.根据权利要求1所述的方法,其特征在于,所述根据所述传输结束时刻和所述通话结束时刻,判断所述链路是否存在RTP尾部丢包,包括:
若判断获知所述传输结束时刻在所述通话结束时刻之前,则根据所述SIP信令判断所述链路对应的通话是否存在呼叫保持信息,根据所述呼叫保持信息判断所述链路是否存在RTP尾部丢包。
3.根据权利要求1所述的方法,其特征在于,所述根据所述传输结束时刻和所述通话结束时刻,判断所述链路是否存在RTP尾部丢包,包括:
若判断获知所述传输结束时刻不在所述通话结束时刻之前,则确定所述RTP数据流的上行传输结束时刻和下行传输结束时刻;
根据公式:Tm=T2-T1,计算所述上行传输结束时刻与所述下行传输结束时刻的差值Tm;
根据所述差值确定所述链路是否存在RTP尾部丢包;
其中,T1为所述上行传输结束时刻,T2为所述下行传输结束时刻。
4.根据权利要求3所述的方法,其特征在于,所述根据所述差值确定所述链路是否存在RTP尾部丢包,包括:
若判断获知所述差值大于预设阈值,则根据所述SIP信令判断所述链路对应的通话是否存在呼叫保持信息;
根据所述呼叫保持信息判断所述链路是否存在RTP尾部丢包。
5.一种识别RTP尾部丢包的装置,其特征在于,包括:
获取模块,用于获取同一链路的RTP数据流和SIP信令;
第一确定模块,用于根据所述RTP数据流中最后传输的RTP包,确定所述RTP数据流的传输结束时刻;
第二确定模块,用于根据所述SIP信令确定所述链路对应的通话结束时刻;
判断模块,用于根据所述传输结束时刻和所述通话结束时刻,判断所述链路是否存在RTP尾部丢包。
6.根据权利要求5所述的装置,其特征在于,所述判断模块包括:
第一识别单元,用于若判断获知所述传输结束时刻在所述通话结束时刻之前,则根据所述SIP信令判断所述链路对应的通话是否存在呼叫保持信息,根据所述呼叫保持信息判断所述链路是否存在RTP尾部丢包。
7.根据权利要求5所述的装置,其特征在于,所述判断模块包括:
分析单元,用于若判断获知所述传输结束时刻不在所述通话结束时刻之前,则确定所述RTP数据流的上行传输结束时刻和下行传输结束时刻;
计算单元,用于根据公式:Tm=T2-T1,计算所述上行传输结束时刻与所述下行传输结束时刻的差值Tm;
处理单元,用于根据所述差值确定所述链路是否存在RTP尾部丢包;
其中,T1为所述上行传输结束时刻,T2为所述下行传输结束时刻。
8.根据权利要求7所述的装置,其特征在于,所述处理单元包括:
呼叫保持判断单元,用于若判断获知所述差值大于预设阈值,则根据所述SIP信令判断所述链路对应的通话是否存在呼叫保持信息;
第二识别单元,用于根据所述呼叫保持信息判断所述链路是否存在RTP尾部丢包。
9.一种电子设备,其特征在于,包括:
存储器和处理器,所述处理器和所述存储器通过总线完成相互间的通信;所述存储器存储有可被所述处理器执行的程序指令,所述处理器调用所述程序指令能够执行如权利要求1至4任一所述的方法。
10.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现如权利要求1至4任一所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710898612.0A CN109587096B (zh) | 2017-09-28 | 2017-09-28 | 一种识别rtp尾部丢包的方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710898612.0A CN109587096B (zh) | 2017-09-28 | 2017-09-28 | 一种识别rtp尾部丢包的方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN109587096A true CN109587096A (zh) | 2019-04-05 |
CN109587096B CN109587096B (zh) | 2021-09-14 |
Family
ID=65913154
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201710898612.0A Active CN109587096B (zh) | 2017-09-28 | 2017-09-28 | 一种识别rtp尾部丢包的方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109587096B (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112688824A (zh) * | 2019-10-17 | 2021-04-20 | 中国移动通信集团浙江有限公司 | Rtp丢包检测方法、装置、设备及计算机可读存储介质 |
Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070274284A1 (en) * | 2006-05-03 | 2007-11-29 | Raghunath Dendukuri | Media Inactivity detection in VoIP networks |
US20080002669A1 (en) * | 2001-09-14 | 2008-01-03 | O'brien Ray | Packet voice gateway |
CN101523809A (zh) * | 2006-09-28 | 2009-09-02 | 高通股份有限公司 | 用于确定通信链路质量的方法和装置 |
CN101771599A (zh) * | 2008-12-26 | 2010-07-07 | 中国移动通信集团公司 | 一种rtp数据包接收处理方法及装置 |
CN102546081A (zh) * | 2010-12-21 | 2012-07-04 | 中兴通讯股份有限公司 | 丢包检测方法、系统和媒体客户端 |
CN102572531A (zh) * | 2012-02-21 | 2012-07-11 | 德科仕通信(上海)有限公司 | 一种iptv网络丢包故障定界方法及系统 |
CN103067393A (zh) * | 2012-12-30 | 2013-04-24 | 四川九洲电器集团有限责任公司 | 一种rtp包的丢包检测和快速存取方法 |
WO2013098811A1 (en) * | 2012-01-01 | 2013-07-04 | Video Flow Ltd. | Packets recovery system and method |
CN104283850A (zh) * | 2013-07-05 | 2015-01-14 | 中国移动通信集团浙江有限公司 | 一种网络内部媒体流完整性判断方法及系统 |
-
2017
- 2017-09-28 CN CN201710898612.0A patent/CN109587096B/zh active Active
Patent Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080002669A1 (en) * | 2001-09-14 | 2008-01-03 | O'brien Ray | Packet voice gateway |
US20070274284A1 (en) * | 2006-05-03 | 2007-11-29 | Raghunath Dendukuri | Media Inactivity detection in VoIP networks |
CN101523809A (zh) * | 2006-09-28 | 2009-09-02 | 高通股份有限公司 | 用于确定通信链路质量的方法和装置 |
CN101771599A (zh) * | 2008-12-26 | 2010-07-07 | 中国移动通信集团公司 | 一种rtp数据包接收处理方法及装置 |
CN102546081A (zh) * | 2010-12-21 | 2012-07-04 | 中兴通讯股份有限公司 | 丢包检测方法、系统和媒体客户端 |
WO2013098811A1 (en) * | 2012-01-01 | 2013-07-04 | Video Flow Ltd. | Packets recovery system and method |
CN102572531A (zh) * | 2012-02-21 | 2012-07-11 | 德科仕通信(上海)有限公司 | 一种iptv网络丢包故障定界方法及系统 |
CN103067393A (zh) * | 2012-12-30 | 2013-04-24 | 四川九洲电器集团有限责任公司 | 一种rtp包的丢包检测和快速存取方法 |
CN104283850A (zh) * | 2013-07-05 | 2015-01-14 | 中国移动通信集团浙江有限公司 | 一种网络内部媒体流完整性判断方法及系统 |
Non-Patent Citations (2)
Title |
---|
SHAFQAAT AHMAD: "A Dynamic Congestion Control Mechanism for Real Time Streams over RTP", 《THE 9TH INTERNATIONAL CONFERENCE ON ADVANCED COMMUNICATION TECHNOLOGY》 * |
裴红津: "无线视频传输的RTP/RCU丢包检测", 《信息通信》 * |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112688824A (zh) * | 2019-10-17 | 2021-04-20 | 中国移动通信集团浙江有限公司 | Rtp丢包检测方法、装置、设备及计算机可读存储介质 |
CN112688824B (zh) * | 2019-10-17 | 2022-09-27 | 中国移动通信集团浙江有限公司 | Rtp丢包检测方法、装置、设备及计算机可读存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN109587096B (zh) | 2021-09-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9686412B2 (en) | System and method for offline voicemail deposit | |
CN102138313B (zh) | 针对rfc 3313的带内dpi媒体预留修改 | |
US8194825B2 (en) | Methods and apparatus for call surveillance in internet protocol communication networks | |
US9026663B2 (en) | Method, apparatus and program product for merging communication sessions in an IMS | |
US11252201B2 (en) | Communications methods, apparatus and systems to provide optimal media routing | |
JP5606074B2 (ja) | 通信ネットワークにおける動的サービストリガ | |
CN103685200B (zh) | 接入协商、释放中服务质量承载资源控制的方法及系统 | |
JP2010535451A (ja) | Sessioninitiationprotocolベースのネットワークでの複数のアプリケーション・サーバを用いる呼転送 | |
EP3420464B1 (en) | Initiation of conference and transfer call in internet protocol multimedia subsystem based emergency services network | |
CN1988546A (zh) | 获取会话起始协议消息传输路径的方法及系统 | |
CN109587096A (zh) | 一种识别rtp尾部丢包的方法及装置 | |
EP2385675A1 (en) | Termiinal, system and method for inter-cutting information | |
US9641379B2 (en) | Caching of announcements at the edge of a packet switched telecommunication network | |
CN109104391A (zh) | 三角信令分析方法、装置、系统及计算机可读存储介质 | |
US9071669B2 (en) | Method and network node for monitoring a quality of media transfer in a session initiation protocol based voice over internet protocol communications network | |
WO2016162061A1 (en) | In-session communication | |
US8606243B2 (en) | Mobile network system and guidance message providing method | |
EP3732841B1 (en) | Method, system and entity for a media transfer session in an ims infrastructure | |
JP5575001B2 (ja) | ネットワーク制御方法、及びセッション処理装置 | |
CN104901922A (zh) | 基于会话初始协议sip的数据业务处理方法及装置 | |
CN110710180B (zh) | 用于触发呼叫的服务逻辑执行记录的方法和设备 | |
CN113676604B (zh) | 一种语音处理方法、相关设备和存储介质 | |
CN110089097B (zh) | 通信网络中的呼叫碰撞解决 | |
CN116886501A (zh) | 一种电力交换网ims信令监测系统和监测方法 | |
US20060133292A1 (en) | System and method for measuring performance of internet phone protocol |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |