CN101127712B - 一种解决rtp会话中同步源标识冲突的方法 - Google Patents
一种解决rtp会话中同步源标识冲突的方法 Download PDFInfo
- Publication number
- CN101127712B CN101127712B CN2007101430064A CN200710143006A CN101127712B CN 101127712 B CN101127712 B CN 101127712B CN 2007101430064 A CN2007101430064 A CN 2007101430064A CN 200710143006 A CN200710143006 A CN 200710143006A CN 101127712 B CN101127712 B CN 101127712B
- Authority
- CN
- China
- Prior art keywords
- participant
- message
- synchronization source
- rtp
- session
- 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.)
- Active
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种解决RTP会话中同步源标识冲突的方法,在建立RTP会话后,如果该会话中的一个参与者一发现自己的同步源标识与新加入该会话的参与者二的同步源标识发生冲突,则立即更新自己的同步源标识,并继续发送报文;所述参与者二在发现自己的同步源标识与所述参与者一发生冲突时也立即更新其同步源标识,并继续发送报文;该会话中的其它参与者在发现参与者二的同步源标识与参与者一发生冲突时,直接丢弃所述参与者二的报文,继续接收参与者一的报文。采用本发明的方法不启用RTCP就可以解决RTP会话中的SSRC冲突,通过对报文中的Sequence Number的分析,保证了在SSRC发生冲突的时候已建立连接的语音不受影响,且只需短暂的时间就可以恢复通话。
Description
技术领域
本发明属于VoIP(Voice over Internet Protocol,IP语音技术)技术领域,具体涉及一种在RTCP(RTP Control Protocol,RTP控制协议)不启动的情况下,解决RTP(Real-Time Transport Protocol,实时传输协议)会话中SSRC(Synchronization source,同步源标识)冲突的方法。
背景技术
RTP为实时数据提供端到端的传输功能,如交互的音频视频数据。功能包括载荷类型辨别,序列号编码,时戳,传输监控。RTP在UDP(User DatagramProtocol,用户数据报协议)协议之上,利用UDP复用,包校验功能协作共同完成传输层功能。
RTP协议包括两部分:RTP(用于传输实时数据)和RTCP(用于RTP业务质量监控)会话信息交互。RTP部分主要完成载荷封装,序列号管理,时戳编码,同步源标识符功能。RTCP周期地向RTP会话的各方发送控制报文。RTCP实现的主要功能是:提供数据传输质量的反馈;这也就是RTP作为传输层协议提供流控、拥塞控制的一个部分,这个反馈可用于自适应编码的控制,用于监控本地或远端错误,对于IP组播可提供给第三方作网络监控用。RTCP报文分为SR(发送者报告)、RR(接收者报告)、SDES(信源说明)、BYE(会话结束)、APP(特定应用报文)五种类型。
RTP报文格式如图1所示,其中
版本号V(Version):2位,代表RTP的版本号;
填充标识P(Padding):1位,当P=1时表示包含一个或多个填充字节以进行32位对齐;
扩展位X(EXtension):1位,表示是否包括扩展头部;
CSRC计数器CC(CSRC Count):4位,表示CSRC的计数(CSRC Count);
标记位M(Marker):1位,由Profile文件定义,允许重要事件如帧边界在数据包流中进行标记;
载荷类型PT(Payload Type):7位,标识了RTP载荷的格式,它决定了应用程序如何对载荷解码;
序列号(Sequence Number):16位,用来检测RTP报文丢失和报文乱序时排序的参考,发送方如一个SSRC每发出一个RTP报文,SequenceNumber增加1,Sequence Number的初始值随机产生,接收方可以由该域检测包的丢失并恢复数据包序列;
时间戳(Timestamp):32位,记录数据包中数据的第一个字节的采样时刻;
同步源标识(SSRC):32位,标识一个RTP数据流的源,SSRC的产生是随机的,这样,也就有可能在有多个参与者的时候,发生冲突;
贡献源标识(CSRC,Contributing Source):0~15项,每项32位用于识别该RTP数据包中的有效载荷的贡献源。
RFC3550是RTP协议的标准。此标准有如下一些定义:
1,在同一个RTP会话中,所有参与者的SSRC字段要唯一;如果一个RTP会话的参与者发现SSRC冲突(即在一个RTP会话中,参与者的SSRC不唯一),通过发送RTCP BYE报文,退出会话,然后重新生成一个SSRC标识,加入会话;
2,在多方会话时,如果某一个参与者发现RTP会话另外两个参与者的SSRC冲突,则会尽可能的通过判断网络传输层地址或者判断RTCP SDES中的内容来区分报文,直到SSRC不再冲突;
3,在一个RTP会话中,一个新的SSRC被其它参与者认为是有效的数据流的条件是:至少收到2个从这个SSRC发出的连续的RTP报文。
虽然RFC3550有这些定义,但是,RTCP并不是必须启用的。不启用RTCP可以带来的好处是:节约链路带宽,提高语音质量,有时甚至是还没有实现RTCP的功能。在这种情况下(RTCP不启用),如果出现了SSRC冲突,如何解决,协议并没有说明。
发明内容
本发明要解决的技术问题是提供一种在RTCP不启动的情况下,解决RTP会话中SSRC冲突的方法。
为了解决上述问题,本发明提供了一种解决RTP会话中同步源标识冲突的方法,在建立RTP会话后,如果该会话中的一个参与者一发现自己的同步源标识与新加入该会话的参与者二的同步源标识发生冲突,则立即更新自己的同步源标识,并继续发送报文;所述参与者二在发现自己的同步源标识与所述参与者一发生冲突时也立即更新其同步源标识,并继续发送报文;该会话中的其它参与者在发现参与者二的同步源标识与参与者一发生冲突时,直接丢弃所述参与者二的报文,继续接收参与者一的报文。
进一步地,上述的方法还可以具有如下特点:所述参与者一在更新自己的同步源标识后,按照已有的频率继续发送报文,所述会话中的其它参与者通过分析所接收的报文中的序列号得到所述参与者一发送的报文。
进一步地,上述的方法还可以具有如下特点:在所述参与者一与所述参与者二均立即更新同步源标识后,所述参与者一及所述会话中的其它参与者即可正常接收所述参与者二发送的报文。
进一步地,上述的方法还可以具有如下特点:所述参与者二加入所述会话后,开始发送报文,所述参与者一是在收到所述参与者二发送的所述报文后,发现自己的同步源标识与所述参与者二发生冲突。
进一步地,上述的方法还可以具有如下特点:所述参与者二是在收到所述参与者一发送的报文后,发现自己的同步源标识与所述参与者一发生冲突。
进一步地,上述的方法还可以具有如下特点:所述建立RTP会话的参与者最初有两个或更多。
进一步地,上述的方法还可以具有如下特点:所述同步源标识的更新是由实时传输协议完成。
通过本发明的方法可以很快消除RTP会话中的SSRC冲突,并且通过对报文中的Sequence Number的分析,保证了在SSRC发生冲突的时候已建立连接的语音不受影响,在发生冲突的SSRC均立即更新之后,只需短暂的时间就可以恢复通话。
附图说明
图1是RTP报文格式;
图2是本发明实施例多个参与者进行RTP会话的示意图。
具体实施方式
本发明解决SSRC冲突(不启用RTCP)的主要思想是:一旦发现冲突,参与者立即更新自己的SSRC标识,并通过判断发送频率或者序列号字段,尽可能地保证RTP报文的不丢失。
由于RTP只传送实时数据,本身并不提供任何保证实时传送数据和服务质量的能力,因此,本发明通过RTP提供的序列号信息,在接收端根据报文中的这些信息来判断和接收正确的报文数据。
下面结合附图及具体实施例对本发明作进一步详细描述。
参见图2,A,B,C三个参与者通过IP网络连接,进行RTP会话。
例如,A,B两个参与者已经开始RTP会话,相互之间在发送RTP报文,SSRC没有冲突;这时C加入进来,C开始向A和B发送RTP数据,C的SSRC与A的SSRC冲突。下面分别介绍A,B,C这三个参与者的动作。
A:A收到C发送的RTP报文,发现C的SSRC与自己的一样,发生了冲突,这时,A立刻将自己的SSRC更换掉(自己随机产生一个新的SSRC标识),不过,重要的是,A的RTP报文的发送不受SSRC更换的影响,只是发送出去的RTP报文中的SSRC字段在某一个时刻发生了变化。
C:C将收到A的RTP报文,发现A的SSRC与自己的一样,发生了冲突,这时,C立刻将自己的SSRC更换掉,RTP报文的发送保持不变。
B:B收到C发送的RTP报文后,发现C的SSRC与A的SSRC一样,发生了冲突,这时,B直接丢弃C的RTP报文,继续接收A的RTP报文。
B要做到这一点,可以通过分析Sequence Number进行判断,虽然A发出的RTP报文在某一个时刻SSRC发生了变化,但是Sequence Number还是保持连续的,B通过分析Sequence Number的连续性来得到A发出的RTP报文,丢弃C发来的RTP报文。
A和C都更换了SSRC之后,这个RTP会话就不再有SSRC冲突,A和B也就开始正常接收C的RTP报文了。
上述的实施例是最初建立RTP会话的参与者有两个的情形,本发明同样适用于最初参与者有三个或三个以上的情形,例如最初已建立会话的还有一个参与者D,则当A和新加入会话的C的同步源标识出现冲突时,参与者D的处理动作与上述实施例中的B的动作相同。
综上所述,通过本发明的方法可以很快消除RTP会话中的SSRC冲突,并且通过对Sequence Number的判断,暂时丢弃新加入的参与者,保证了在SSRC发生冲突的时候已建立连接的语音不受影响,在发生冲突的SSRC均立即更新之后,只需短暂的时间就可以恢复通话。
需要注意的是,本发明有一个潜在默认条件,即在SSRC发生冲突的时候,Sequence Number不能冲突。事实上,由于SSRC标识是32位随机数,其本身发生冲突的概率已经很小,Sequence Number的初始值也是16位的随机数,因此,SSRC标识与Sequence Number两者同时发生冲突的概率可以认为是0。
Claims (7)
1.一种解决RTP会话中同步源标识冲突的方法,其特征在于,在建立RTP会话后,如果该会话中的一个参与者一发现自己的同步源标识与新加入该会话的参与者二的同步源标识发生冲突,则立即更新自己的同步源标识,并继续发送报文;所述参与者二在发现自己的同步源标识与所述参与者一发生冲突时也立即更新其同步源标识,并继续发送报文;该会话中的其它参与者在发现参与者二的同步源标识与参与者一发生冲突时,直接丢弃所述参与者二的报文,继续接收参与者一的报文。
2.如权利要求1所述的方法,其特征在于,
所述参与者一在更新自己的同步源标识后,按照已有的频率继续发送报文,所述会话中的其它参与者通过分析所接收的报文中的序列号得到所述参与者一发送的报文。
3.如权利要求1所述的方法,其特征在于,
在所述参与者一与所述参与者二均立即更新同步源标识后,所述参与者一及所述会话中的其它参与者即可正常接收所述参与者二发送的报文。
4.如权利要求1或2或3所述的方法,其特征在于,
所述参与者二加入所述会话后,开始发送报文,所述参与者一是在收到所述参与者二发送的所述报文后,发现自己的同步源标识与所述参与者二发生冲突。
5.如权利要求4所述的方法,其特征在于,
所述参与者二是在收到所述参与者一发送的报文后,发现自己的同步源标识与所述参与者一发生冲突。
6.如权利要求5所述的方法,其特征在于,
所述建立RTP会话的参与者最初有两个或更多。
7.如权利要求1所述的方法,其特征在于,
所述同步源标识的更新是由实时传输协议完成。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007101430064A CN101127712B (zh) | 2007-08-20 | 2007-08-20 | 一种解决rtp会话中同步源标识冲突的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2007101430064A CN101127712B (zh) | 2007-08-20 | 2007-08-20 | 一种解决rtp会话中同步源标识冲突的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101127712A CN101127712A (zh) | 2008-02-20 |
CN101127712B true CN101127712B (zh) | 2011-05-25 |
Family
ID=39095638
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2007101430064A Active CN101127712B (zh) | 2007-08-20 | 2007-08-20 | 一种解决rtp会话中同步源标识冲突的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101127712B (zh) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101369880B (zh) * | 2008-09-28 | 2012-09-19 | 华为技术有限公司 | 一种时间标签跳变的检测处理方法和装置 |
CN102594776B (zh) * | 2011-01-11 | 2016-08-03 | 中兴通讯股份有限公司 | 一种同步源标识更新的方法、装置和*** |
CN105743549B (zh) | 2014-12-10 | 2019-02-01 | 展讯通信(上海)有限公司 | 用户终端及其音频蓝牙播放方法、数字信号处理器 |
CN108259208B (zh) * | 2016-12-29 | 2021-03-30 | 华为技术有限公司 | 一种检测报文染色位冲突的方法和设备 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040165527A1 (en) * | 2002-12-20 | 2004-08-26 | Xiaoyuan Gu | Control traffic compression method |
CN1885857A (zh) * | 2005-06-20 | 2006-12-27 | 华为技术有限公司 | 识别网络中的rtp媒体流的方法 |
CN1996897A (zh) * | 2005-12-28 | 2007-07-11 | 中兴通讯股份有限公司 | 一种在rtp中实时检测网络传输时延的方法 |
-
2007
- 2007-08-20 CN CN2007101430064A patent/CN101127712B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040165527A1 (en) * | 2002-12-20 | 2004-08-26 | Xiaoyuan Gu | Control traffic compression method |
CN1885857A (zh) * | 2005-06-20 | 2006-12-27 | 华为技术有限公司 | 识别网络中的rtp媒体流的方法 |
CN1996897A (zh) * | 2005-12-28 | 2007-07-11 | 中兴通讯股份有限公司 | 一种在rtp中实时检测网络传输时延的方法 |
Also Published As
Publication number | Publication date |
---|---|
CN101127712A (zh) | 2008-02-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8467308B2 (en) | Communication session quality indicator | |
US7936695B2 (en) | Tunneling reports for real-time internet protocol media streams | |
CN100568828C (zh) | 一种在rtp中实时检测网络传输时延的方法 | |
CN101867453B (zh) | 一种rtp抗丢包的方法 | |
CN101364999B (zh) | 一种基于流的服务质量处理的方法、设备及*** | |
EP1943858B1 (en) | Traffic generation during a state of an inactive user plane | |
Hellstrom et al. | RTP payload for text conversation | |
JP2009118498A (ja) | サービス品質に関する埋込み情報の送信 | |
JP2004208292A (ja) | 制御トラフィック圧縮方法 | |
EP2515481A1 (en) | Transmission control method, access equipment and transmission system | |
US20090238346A1 (en) | Method of Copying Voice Messages in the Form of Text Messages in a Packet Communication Network | |
CN113014586B (zh) | Rtp数据包乱序处理及重组帧方法和*** | |
CN105915904A (zh) | 一种宽带集群呼叫业务的视频流Qos控制方法 | |
CN101127712B (zh) | 一种解决rtp会话中同步源标识冲突的方法 | |
JP4600513B2 (ja) | データ送信装置、送信レート制御方法およびプログラム | |
US7756108B2 (en) | Transmission of voice over a network | |
US8391284B2 (en) | Usage of feedback information for multimedia sessions | |
KR100541523B1 (ko) | 이동통신망에서 멀티미디어 콘텐츠 제공을 위한 채널 제어방법 | |
EP3095230B1 (en) | Processing of data files | |
Gruen et al. | Interactive RTP services with predictable reliability | |
KR100612674B1 (ko) | 이동통신 시스템에서 양방향 멀티미디어 콘텐츠 서비스제공 방법 | |
CN101159746B (zh) | 一种自适应方法及*** | |
KR20080037950A (ko) | 데이터를 송수신하는 방법 및 장치 | |
Hellstrom et al. | RFC 4103: RTP Payload for Text Conversation | |
KR20050068433A (ko) | 통신 시스템에서의 혼잡 제어 방법 및 장치 |
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 |