CN101127712A - A method for solving synchronization source identity confliction in RTP session - Google Patents
A method for solving synchronization source identity confliction in RTP session Download PDFInfo
- Publication number
- CN101127712A CN101127712A CNA2007101430064A CN200710143006A CN101127712A CN 101127712 A CN101127712 A CN 101127712A CN A2007101430064 A CNA2007101430064 A CN A2007101430064A CN 200710143006 A CN200710143006 A CN 200710143006A CN 101127712 A CN101127712 A CN 101127712A
- 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.)
- Granted
Links
Images
Abstract
The utility model discloses a method to solve the conflict of the synchronous source labels in the RTP conversation. After building the RTP conversation, if a participator I in the conversation finds the self-synchronous source label has conflict with the synchronous source label of a new participator II, the synchronous source label of the participator I is updated immediately and the message is transmitted continuously; the synchronous source label of the participator II is updated immediately when the participator II finds the self- synchronous source label has conflict with the synchronous source label of the participator I and continues the message transmission; when finding that the synchronous source label of the participator II has conflict with the synchronous source label of the participator I, the other participators in the conversation directly discard the message from the participator II and continue to receive the message from the participator I. The utility model can solve the SSRC conflict in the RTP conversation without starting the RTCP, ensure that the current connected voice is not impacted during the SSRC conflict through analyzing the Sequence Number in the message and recover the conversation in a short period.
Description
Technical field
The invention belongs to VoIP (Voice over Internet Protocol, the ip voice technology) technical field, be specifically related to a kind of at RTCP (RTP Control Protocol, under the situation about RTP Control Protocol) not starting, solve RTP (Real-Time Transport Protocol, RTP) method of SSRC (Synchronization source, Synchronization Source) conflict in the session.
Background technology
RTP provides transfer function end to end for real time data, as mutual audio-visual data.Function comprises that load type distinguishes serial number codes, time stamp, transmitting, monitoring.RTP utilizes UDP multiplexing on UDP (User DatagramProtocol, User Datagram Protoco (UDP)) agreement, and transport layer functionality is finished in the cooperation of bag verifying function jointly.
Real-time Transport Protocol comprises two parts: RTP (being used for transmitting real-time data) and RTCP (being used for the monitoring of RTP quality of service) session information interacting.The RTP part is mainly finished the load encapsulation, sequence number management, time stamp coding, synchronous source identifier function.RTCP sends the control message to the each side of RTP session periodically.The major function that RTCP realizes is: the feedback that data transmission quality is provided; This just RTP provide a part of Flow Control, congested control as transport layer protocol, this feedback can be used for the control of adaptive coding, is used to monitor this locality or far-end mistake, can offer the third party for the IP multicast and do network monitoring and use.The RTCP message is divided into five types of SR (Sender Report), RR (Receiver Report), SDES (information source explanation), BYE (conversation end), APP (application-specific message).
The RTP message format as shown in Figure 1, wherein
The V of version number (Version): 2, represent the version number of RTP;
Fill sign P (Padding): 1, when P=1, represent to comprise one or more byte of paddings to carry out 32 alignment;
Extension bits X (EXtension): 1, whether expression comprises extended head;
CSRC counter CC (CSRC Count): 4, the counting (CSRC Count) of expression CSRC;
Marker bit M (Marker): 1,, allow critical event such as frame boundaries in data packet stream, to carry out mark by the Profile document definition;
Load type PT (Payload Type): 7, identified the form of RTP load, it has determined how application program decodes to load;
Sequence number (Sequence Number): 16, the reference of sorting when being used for detecting RTP message dropping and packet out-ordering, transmit leg whenever sends a RTP message as a SSRC, SequenceNumber increases by 1, the initial value of Sequence Number produces at random, and the recipient can detect losing of bag and restore data packet sequence by this territory;
Timestamp (Timestamp): 32, the sampling instant of first byte of data in the record data bag;
Synchronization Source (SSRC): 32, the source of a RTP data flow of sign, the generation of SSRC is at random, like this, also just might clash when a plurality of participants are arranged;
Contribution source sign (CSRC, Contributing Source): 0～15,32 every the contribution sources that are used for discerning the payload of this RTP packet.
RFC3550 is the standard of Real-time Transport Protocol.This standard has the following definition:
1, in same RTP session, all participants' SSRC field is unique; If the participant of a RTP session finds SSRC conflict (promptly in a RTP session, participant's SSRC is not unique), by sending RTCP BYE message, withdraw from session, regenerate a SSRC sign then, add session;
2, when multi-party conversation,, then can distinguish message by the content among judgement Network Transmission layer address or the judgement RTCP SDES as much as possible if some participants find two other participant's of RTP session SSRC conflict, no longer conflict up to SSRC;
3, in a RTP session, a new SSRC is thought that by other participant the condition of active data stream is: receive 2 continuous RTP messages that send from this SSRC at least.
Though RFC3550 has these definition,, RTCP must enable.Not enabling the benefit that RTCP can bring is: save link bandwidth, improve voice quality, sometimes or even also do not realize the function of RTCP.(RTCP does not enable) in this case, if the SSRC conflict, how to solve not explanation of agreement.
Summary of the invention
The technical problem to be solved in the present invention provides a kind of under the situation that RTCP does not start, and solves the method for SSRC conflict in the RTP session.
In order to address the above problem, the invention provides the method for Synchronization Source conflict in a kind of RTP of solution session, after setting up the RTP session, if a participant in this session one finds Synchronization Source of oneself and the new Synchronization Source that adds the participant two of this session and clashes, then upgrade the Synchronization Source of oneself immediately, and continue to send message; Described participant two is finding that own Synchronization Source and described participant one also upgrade its Synchronization Source immediately when clashing, and continuation transmission message; When other participant in this session clashes with participant one at the Synchronization Source of finding participant two, directly abandon described participant's two message, continue reception participant's one message.
Further, above-mentioned method can also have following characteristics: described participant one is behind the Synchronization Source that upgrades oneself, continue to send message according to existing frequency, other participant in the described session obtains the message that described participant one sends by the sequence number of analyzing in the message that is received.
Further, above-mentioned method can also have following characteristics: after described participant one all upgraded Synchronization Source immediately with described participant two, other participant in described participant one and the described session can normally receive the message that described participant two sends.
Further, above-mentioned method can also have following characteristics: after described participant two adds described session, begin to send message, described participant one is after receiving the described message that described participant two sends, and finds that Synchronization Source of oneself and described participant two clash.
Further, above-mentioned method can also have following characteristics: described participant two is after receiving the message that described participant one sends, and finds that Synchronization Source of oneself and described participant one clash.
Further, above-mentioned method can also have following characteristics: the participant of the described RTP of foundation session has two or more at first.
Further, above-mentioned method can also have following characteristics: the renewal of described Synchronization Source is to be finished by RTP.
By method of the present invention can be very fast SSRC conflict in the elimination RTP session, and by analysis to the Sequence Number in the message, guaranteed that the voice that connected are unaffected when SSRC clashes, after the SSRC that clashes all upgrades immediately, only need the of short duration time just can recover conversation.
Description of drawings
Fig. 1 is the RTP message format;
Fig. 2 is the schematic diagram that a plurality of participants of the embodiment of the invention carry out the RTP session.
Embodiment
The main thought that the present invention solves SSRC conflict (not enabling RTCP) is: in case find conflict, the participant upgrades the SSRC sign of oneself immediately, and by judging transmission frequency or sequence-number field, guarantees not losing of RTP message as much as possible.
Because RTP only transmits real time data, the ability of any assurance transmitting data in real time and service quality is not provided itself, therefore, the sequence number information that the present invention provides by RTP is judged according to these information in the message and is received correct message data at receiving terminal.
Below in conjunction with drawings and the specific embodiments the present invention is described in further detail.
Referring to Fig. 2, A, B, three participants of C connect by IP network, carry out the RTP session.
For example, A, two participants of B have begun the RTP session, are sending the RTP message each other, and SSRC is conflict not; At this moment C adds to come in, and C begins to send the RTP data to A and B, and the SSRC of C conflicts with the SSRC of A.Introduce A below respectively, B, these three participants' of C action.
A:A receives the RTP message that C sends, the SSRC that finds C is the same with oneself, conflict has taken place, at this moment, A more changes the SSRC of oneself (oneself producing a new SSRC sign at random) at once, but, and importantly, the influence that the transmission of the RTP message of A is not changed by SSRC, variation has taken place in some moment in the SSRC field in the RTP message that just sends.
C:C will receive the RTP message of A, and the SSRC of discovery A is the same with oneself, and conflict has taken place, and at this moment, C more changes the SSRC of oneself at once, and the transmission of RTP message remains unchanged.
After B:B receives the RTP message of C transmission, find that the SSRC of C is the same with the SSRC of A, conflict has taken place, at this moment, B directly abandons the RTP message of C, continues to receive the RTP message of A.
B will accomplish this point, can judge by analyzing Sequence Number, though variation has taken place at some moment SSRC in the RTP message that A sends, it is continuous that but Sequence Number still keeps, B obtains the RTP message that A sends by the continuity of analyzing Sequence Number, abandons the RTP message that C sends.
A and C have changed after the SSRC, and this RTP session just no longer includes the SSRC conflict, and A and B also just begin normally to have received the RTP message of C.
The above embodiments are that the participant who sets up the RTP session at first has two situation, the present invention is equally applicable to initial participant situation more than three or three, for example set up at first the participant D that also has of session, then when conflict appears in A and the new Synchronization Source that adds the C of session, the action of the B in the processing action of participant D and the foregoing description is identical.
In sum, by method of the present invention can be very fast SSRC conflict in the elimination RTP session, and by judgement to Sequence Number, temporarily abandon initiate participant, guaranteed that the voice that connected are unaffected when SSRC clashes, after the SSRC that clashes all upgrades immediately, only need the of short duration time just can recover conversation.
It should be noted that the present invention has a potential implied terms, promptly when SSRC clashed, Sequence Number can not conflict.In fact, because the SSRC sign is 32 random numbers, the probability that itself clashes is very little, and the initial value of Sequence Number also is 16 a random number, therefore, the SSRC sign can think 0 with the probability that Sequence Number clashes simultaneously.
Claims (7)
1. one kind solves the method that Synchronization Source conflicts in the RTP session, it is characterized in that, after setting up the RTP session, if a participant in this session one finds Synchronization Source of oneself and the new Synchronization Source that adds the participant two of this session and clashes, then upgrade the Synchronization Source of oneself immediately, and continue to send message; Described participant two is finding that own Synchronization Source and described participant one also upgrade its Synchronization Source immediately when clashing, and continuation transmission message; When other participant in this session clashes with participant one at the Synchronization Source of finding participant two, directly abandon described participant's two message, continue reception participant's one message.
2. the method for claim 1 is characterized in that,
Described participant one continues to send message according to existing frequency behind the Synchronization Source that upgrades oneself, other participant in the described session obtains the message that described participant one sends by the sequence number of analyzing in the message that is received.
3. the method for claim 1 is characterized in that,
After described participant one all upgraded Synchronization Source immediately with described participant two, other participant in described participant one and the described session can normally receive the message that described participant two sends.
4. as claim 1 or 2 or 3 described methods, it is characterized in that,
After described participant two adds described session, begin to send message, described participant one is after receiving the described message that described participant two sends, and finds that Synchronization Source of oneself and described participant two clash.
5. method as claimed in claim 4 is characterized in that,
Described participant two is after receiving the message that described participant one sends, and finds that Synchronization Source of oneself and described participant one clash.
6. method as claimed in claim 5 is characterized in that,
The participant of the described RTP of foundation session has two or more at first.
7. the method for claim 1 is characterized in that,
The renewal of described Synchronization Source is to be finished by RTP.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2007101430064A CN101127712B (en) | 2007-08-20 | 2007-08-20 | A method for solving synchronization source identity confliction in RTP session |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2007101430064A CN101127712B (en) | 2007-08-20 | 2007-08-20 | A method for solving synchronization source identity confliction in RTP session |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101127712A true CN101127712A (en) | 2008-02-20 |
| CN101127712B CN101127712B (en) | 2011-05-25 |
Family
ID=39095638
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN2007101430064A Active CN101127712B (en) | 2007-08-20 | 2007-08-20 | A method for solving synchronization source identity confliction in RTP session |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101127712B (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102594776A (en) * | 2011-01-11 | 2012-07-18 | 中兴通讯股份有限公司 | Method, device and system for updating synchronous source identifier |
| CN101369880B (en) * | 2008-09-28 | 2012-09-19 | 华为技术有限公司 | Detection processing method and apparatus for time label jumping |
| CN105743549A (en) * | 2014-12-10 | 2016-07-06 | 展讯通信（上海）有限公司 | User terminal, audio Bluetooth play method and digital signal processor thereof |
| CN108259208A (en) * | 2016-12-29 | 2018-07-06 | 华为技术有限公司 | A kind of method and apparatus of detection messages dyeing bit swiping |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1432196A1 (en) * | 2002-12-20 | 2004-06-23 | Matsushita Electric Industrial Co., Ltd. | Control traffic compression method in media data transmission |
| CN100505756C (en) * | 2005-06-20 | 2009-06-24 | 华为技术有限公司 | Method for recognizing RTP media stream in network |
| CN100568828C (en) * | 2005-12-28 | 2009-12-09 | 中兴通讯股份有限公司 | A kind of method that in RTP, detects network transfer delay in real time |
-
2007
- 2007-08-20 CN CN2007101430064A patent/CN101127712B/en active Active
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101369880B (en) * | 2008-09-28 | 2012-09-19 | 华为技术有限公司 | Detection processing method and apparatus for time label jumping |
| CN102594776A (en) * | 2011-01-11 | 2012-07-18 | 中兴通讯股份有限公司 | Method, device and system for updating synchronous source identifier |
| CN102594776B (en) * | 2011-01-11 | 2016-08-03 | 中兴通讯股份有限公司 | The methods, devices and systems that a kind of Synchronization Source updates |
| CN105743549A (en) * | 2014-12-10 | 2016-07-06 | 展讯通信（上海）有限公司 | User terminal, audio Bluetooth play method and digital signal processor thereof |
| US10007479B2 (en) | 2014-12-10 | 2018-06-26 | Spreadtrum Communications (Shanghai) Co., Ltd. | User terminal, method for playing audio data via bluetooth, and digital signal processor |
| CN105743549B (en) * | 2014-12-10 | 2019-02-01 | 展讯通信（上海）有限公司 | User terminal and its audio bluetooth playback method, digital signal processor |
| CN108259208A (en) * | 2016-12-29 | 2018-07-06 | 华为技术有限公司 | A kind of method and apparatus of detection messages dyeing bit swiping |
| CN108259208B (en) * | 2016-12-29 | 2021-03-30 | 华为技术有限公司 | Method and equipment for detecting message dye bit conflict |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101127712B (en) | 2011-05-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN100568828C (en) | A kind of method that in RTP, detects network transfer delay in real time | |
| CN101364999B (en) | QoS processing method, apparatus and system based on stream | |
| CN101867453B (en) | RTP anti-packet-loss method | |
| CN102546081B (en) | Method for detecting packet loss, system and media client | |
| EP1943858B1 (en) | Traffic generation during a state of an inactive user plane | |
| US20100040050A1 (en) | Communication session quality indicator | |
| Hellstrom et al. | RTP payload for text conversation | |
| JP2004208292A (en) | Control traffic compression method | |
| JP2009118498A (en) | Transmission of embedded information relating to quality of service | |
| EP2515481A1 (en) | Transmission control method, access equipment and transmission system | |
| EP2153622B1 (en) | A method for efficient feedback of receiving channel conditions in adaptive video multicast and broadcast systems | |
| CN113014586B (en) | RTP data packet out-of-order processing and framing method and system | |
| CN105915904A (en) | Video stream Qos control method for broadband trunking call service | |
| CN101127712B (en) | A method for solving synchronization source identity confliction in RTP session | |
| CN101039325B (en) | Method for configuring real-time transmission protocol packet based on mixer | |
| JP4600513B2 (en) | Data transmission apparatus, transmission rate control method, and program | |
| US7756108B2 (en) | Transmission of voice over a network | |
| US8391284B2 (en) | Usage of feedback information for multimedia sessions | |
| KR100541523B1 (en) | Method of Controlling Channel for Providing Multimedia Contents in Mobile Communication Network | |
| EP3095230B1 (en) | Processing of data files | |
| CN101159746B (en) | Self-adaptive method and system | |
| KR100612674B1 (en) | Method for Providing of Interactive Multimedia Contents Service in Mobile Communication System | |
| KR20080037950A (en) | Method and apparatus for transmitting/receiving data | |
| CN105827575A (en) | Transmission control method, transmission control device and electronic devices | |
| Hellstrom et al. | RFC 4103: RTP Payload for Text Conversation |
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 |