RTP Message Format
The RTP message consists of two parts: header and payload. The RTP header format is shown in the following illustration, where:
L The version number of the V:RTP protocol, which accounts for 2 digits, and the current protocol version number is 2.
L P: Fill mark, 1 digits, if p=1, then fill one or more additional eight-bit groups at the end of the message, they are not part of the payload.
L X: Extended flag, 1 digits, if x=1, then there is an extension header followed by the RTP header.
L CC:CSRC counter, accounting for 4 digits, indicating the number of the CSRC identifiers.
L M: Mark, 1 bits, different payloads have different meanings, for video, mark the end of a frame; for audio, mark the beginning of a session.
L Synchronous Source (SSRC) Identifier: 32 bits for identifying a sync source. The identifier is randomly selected and two sync sources that participate in the same video conference cannot have the same ssrc.
L Special Source (regulatory Commission) identifier: each CSRC identifier is 32 digits and can be 0~15. Each of the regulatory Commission identifies all the special sources contained within the payload of the RTP message.
L PT: Payload type, accounted for 7 bits, used to explain the type of payload in RTP, such as GSM audio, JPEM image, etc.
L serial Number: 16 digits, used to identify the sender sent the RTP message serial number, each send a message, serial number 1. The receiver detects the packet loss by serial number, reorder the message, and recovers the data.
L time Stamp (Timestamp): 32 bits, the timestamp reflects the sampling moment of the first eight-bit group of the RTP message. The receiver uses a timestamp to compute the delay and delay jitter and to synchronize control.
V |
P |
X |
Cc |
M |
Pt |
Serial number |
Time stamp |
Sync Source (SSRC) identifier |
Special Source (Regulatory Commission) identifier |
··· |
RTP Header Format
RTP Header format
The sync source here is the source that generates the media stream, which is identified by a 32-bit numeric SSRC identifier in the RTP header, not a network address. The receiver will distinguish the different sources according to the SSRC identifier and carry out the grouping of RTP packets. A special source means that when the mixer receives the RTP message of one or more synchronous sources, a new combined RTP message is generated by a mixed process, and the mixer is used as the ssrc of the combined RTP message, and all the original SSRC are transmitted to the receiver as the regulatory Commission. Let the receiver know the various ssrc that compose the composition message.
on the sender side, the upper application is grouped in the form of the encoded media data to the RTP communication module, as the effective load of RTP, RTP communication module will be based on the upper application of the parameters provided in the payload before the effective load to add RTP headers, to form a RTP message, Through the socket interface to select the UDP protocol sent out.
at the receiving end, the RTP communication module receives the RTP message through the socket interface, separates the RTP header for the corresponding processing, and then transmits the payload of the RTP message to the upper level application as a data packet.
Considering that video conferencing is held in a complex environment such as the Internet, RTP defines two intermediate systems: the mixer (Mixer) and the converter (Translator).
When video conferencing is held on the Internet, a small number of participants may be connected by a low-speed link to most participants who use high-speed networks. To not force all conference participants to use low bandwidth and low quality data encoding, RTP allows the mixer to be used as a RTP repeater near a low-bandwidth area. The mixer receives RTP messages from one or more sources, synchronizes and slipstreams the incoming data packets, mixes the data streams into a single data stream, converts the data encoding to a type available at low bandwidth, and forwards the low bandwidth area through the low-speed link. In order to synchronize multiple input sources uniformly, the mixer adjusts the timing of multiple media streams to produce its own timing synchronization, so all packets output from the mixer take the mixer as the synchronous source. In order to ensure that the receiver can correctly identify the original message sender before the mixer is processed, the mixer has set up the CSRC identifier queue in the RTP header to identify the original synchronization source that produces the mixed message.
In an Internet environment, participants in some meetings may be quarantined outside the application-level firewall, which is prohibited from using the IP multicast address directly, although they may be connected through a high-speed link. In these cases, RTP allows the converter to be used as a RTP-level repeater. A converter is installed at both ends of the firewall, the converter outside the firewall filters all received group broadcasts, and passes a secure connection to the converters within the firewall, which the internal converters forward to the multicast group members on the internal network.
The above part is the reprint address: http://hi.baidu.com/chuangbao/blog/item/f27209df252b601a62279854.html
The following is my use of live555 as a server, VCL player as the client, grab the results (RTP/RTCP,,RTSP packet) (part) (on the server side of the grab) (playback of the H.264 video stream (no sound))
The mark has a marker meaning to say the end of this frame. That is, each frame of the video may be too large for a UDP message to be sent. So we use a few messages. Marker represents the last message in this video frame.
In this session, the SSRC is unchanged. Within the same frame the timestamp is unchanged.
RTP English document for RFC 1889 download: http://www.ietf.org/rfc/rfc1889.txt
Chinese version of RTP protocol Ppt:http://wenku.baidu.com/view/7209e10e844769eae009edd8.html?from=related&hasrec=1
This ppt is very good, suggest to me just learn rtsp,rtp/rtcp look. I looked at it carefully, looking at the Rtp/rtcp bag (using Wireshark grab bag). Server side uses http://www.live555.com/liveMedia/public/inside, with vs compile (oneself build a console project, then put all of. Hh,.h; c;. CPP file added to the line, do not care about those. Make file.
The client uses VLC media player.
For example, the following for me to grab a rtcp bag, Wireshark can identify the RTCP package, and show it:
This RTCP package is a RR (Receiver the +bye package) (what is a RR packet, see the PPT)