Real-time Transport Protocol Introduction: RTP protocol Introduction, RTCP protocol Introduction, RTSP protocol Introduction (ZZ)

http://blog.csdn.net/heanyu/article/details/6202500

RTP (Real time Transport Protocol)

RTP is a transport protocol for multimedia traffic on the Internet that is published by the IETF (Internet Engineering Task Force) as RFC1889 . RTP is defined as a one-to-many transmission, with the purpose of providing time information and implementing stream synchronization. Typical applications for RTP are built on UDP, but can also work on other protocols, such as TCP or ATM. RTP itself only guarantees the transmission of real-time data, and does not provide a reliable delivery mechanism for sequentially transmitting packets, nor does it provide traffic control or congestion control, which relies on RTCP to provide these services.

RTP working mechanism
A sharp problem in threatening multimedia data transmission is the unpredictable arrival time of data. However, the transmission of streaming media requires the timely arrival of data for playback and playback. The RTP protocol provides time tags, serial numbers, and other structures to control the exile of timely data. The "Time label" is the most important information in the concept of flow. The sending side sets the time tag in the packet in a discreet, instant sample. After receiving the packet, it is restored to the original timely data according to the time tag at the correct rate. Different media Format tune-time properties are not the same. But RTP itself is not responsible for synchronization, RTP is only the transport layer protocol, in order to simplify the transport layer processing, improve the efficiency of this layer. Move some Transport layer protocol functions (such as flow control) up to the application layer. Synchronization is the application-level protocol. It does not have the full functionality of the Transport Layer protocol, does not provide any mechanism to guarantee the real-time transmission of data, does not support resource reservation, and does not guarantee the quality of service. RTP messages do not even include descriptions of length and message boundaries. At the same time, the RTP protocol's data message and the control message use the neighboring different ports, which greatly improves the flexibility of the Protocol and the simplicity of processing.
The RTP protocol and UDP both complete the Transport Layer protocol function. The UDP protocol simply transmits packets regardless of the time sequence in which the packets are transmitted. RTP protocol data units are hosted with UDP packets. When hosting RTP packets, sometimes a frame of data is divided into several packages with the same time label, you can know that the time tag is not necessary. UDP multiplexing enables the RTP protocol to meet the needs of multimedia sessions by supporting explicit multi-point delivery.
Although the RTP protocol is a transport layer protocol, it is not implemented as a separate layer in the OSI architecture. The RTP protocol typically provides services based on a specific application, and RTP only provides a protocol framework that allows developers to fully extend the protocol based on the specific requirements of the application.
The message structure of RTP protocol
RTP Header format:

Starting 12 octal appears in each RTP package, while the CSRC identity list appears only when the mixer is inserted. The paragraphs have the following meanings:
① version (V)
Version (V): 2 bits 2 bits, identifies the RTP version, the initial version of the protocol is specified in the 0,rfc3550 version number 2:
② Fill Identification (P)
Padding (P): 1 bit 1 bits, such as setting the fill bit, contains additional additional information at the end of the package, which is not part of the payload. The last byte of the additional information represents the length of the extra additional information (including the byte itself). This field exists because some cryptographic algorithms require a fixed-size filler word, or a few RTP packets to be carried in the underlying protocol data unit.
③ Extension (X)
Extension (X): 1 bit 1 bit, if the bit is set, then there is an extension header after the fixed head, the format is defined in RFC3550 5.3.1 section.
④csrc count (CC)
CSRC count (CC): 4 bits 4 bits, CSRC count includes the number of CSRC identified immediately after the fixed head.
⑤ Mark (M)
Marker (M): 1 bit 1 bit, tag interpretation is defined by the setting to allow important events to be flagged in the package stream. The function of a bit can be defined by defining other marker bits, or by changing the number of bits to specify no mark bit. Profile can change the length of the bit, but keep the marker and payload type Total length constant (8 bit altogether).
⑥ Load Type (PT)
Payload Type (PT): 7 bits 7 bits, which records the type of Codec behind the data, and the receiver side finds the corresponding decoder, which marks the types of information that RTP packet carries, and the standard type is listed in RFC3551. If the receiver does not recognize the type, the packet must be ignored.
⑦ Serial No.
Sequence number:16 bits 16 bits, the serial number increases by 1 after each RTP packet is sent, and the receiver can rearrange the packet order or probe packet loss based on the serial number. The initial value of the serial number is random, making it more difficult to attack encrypted text.
⑧ Time Standard
Timestamp:32 bits 32 bits, which reflect the sampling moment of the first octal number in the RTP packet, must be exported from a monotonically, linearly increasing clock to allow synchronization and jitter calculations. The time mark allows the receiver side to know that the data is being played at the right time.

   from the above figure, if only the serial number, and can not be completely in order to play the data out, because if there is no data in the middle of the information, only the serial number will cause errors, need to match to let it know at which time the data is played correctly, So that we can play out the correct information.  
⑨ssrc 
ssrc:32 bits                      32-bit, SSRC segment identifies the synchronization source. This identity is not randomly selected, so that no two synchronization sources in the same RTP packet connection have the same SSRC identity, that is, each data flow should have a different ssrc in the course of an RTP session. Although the probability of selecting the same identity for multiple sources is low, all RTP implementations must probe and resolve the conflict. If the source changes the source transport address, you must also select a new SSRC identifier to avoid inserting into the loop source. &NBSP
⑩csrc list  
csrc list:0 to items     bits0 to 15 items, 32 bits per item. The CSRC list represents the source within the package that works on the payload. The number of identities is given by the CC segment. If there are more than 15 active sources, only 15 are identified. The CSRC identity is inserted by the mixer, using the SSRC identity of the action source. Only valid when there is mixer. such as a voice stream that combines multichannel voice streams into a single channel, the SSRC of each channel is listed here.
RTCP (Real time contorl Protocol)  

RTCP is responsible for managing transfer quality to exchange control information between current application processes. During the RTP session, each participant periodically transmits RTCP packets containing statistics such as the number of packets sent, the number of packets lost, and so on. As a result, the server can use this information to dynamically change the transfer rate and even change the payload type. RTP and RTCP are used together to optimize transmission efficiency with effective feedback and minimal overhead, making it ideal for transmitting real-time data on the web.
RTCP working mechanism
When an application starts an RTP session, it uses two ports: one for RTP, one for RTCP. RTP itself does not provide a reliable delivery mechanism for sequentially transmitting packets, nor does it provide traffic control or congestion control, and it relies on RTCP to provide these services. A period of time between RTP sessions some RTCP packets are used to monitor the quality of the service and to Exchange session user information and other functions. The RTCP package contains statistics about the number of packets sent, the number of packets lost, and so on. As a result, the server can use this information to dynamically change the transfer rate and even change the payload type. RTP and RTCP are used together to optimize transmission efficiency with effective feedback and minimal overhead, making it particularly suitable for transmitting real-time data on the web. According to the data transmission feedback between users, the strategy of traffic control can be developed, and the interaction of Session user information can develop the strategy of Session control.
The RTCP protocol will control the packagePeriodic sendFor all the connectors, apply the same distribution mechanism as the packet. Low-level protocols provide the multiplexing of data and control packs, such as the use of separate UDP port numbers. RTCP performs the following four functions:
The main focus is to provide quality feedback on the data release. is a part of the RTP transport protocol, which is related to the flow and blocking control of other transport protocols. Feedback has a direct effect on adaptive coding control, but IP multicast experience shows that it is important to receive feedback from the sender to diagnose sending errors. Send a receive feedback report to all participants allows the question observer to estimate whether the problem is local or global. Publishing mechanisms such as IP multicast Enable Network service provider groups to receive feedback and act as third-party monitors to diagnose network problems. The feedback function is reported by the RTCP sender and receiver.
The RTCP has an RTP source persistent transport layer identity called the canonical Name (CNAME). If a conflict is found, or the program restarts, since the SSRC identity can be changed, the recipient needs the CNAME to track the participants. The recipient also needs the CNAME to contact several data streams given in the associated RTP connection
The first two functions require all participants to send the RTCP package, so the rate must be controlled in order for RTP to scale to a large quantity. Allow each participant to send a control pack to other participants, and observe the number of participants independently. This number of terms calculates the rate at which packets are sent.
The fourth optional function is to transmit minimum connection control information, such as participant identification. Most likely used in "loose control" connections, where participants are free to enter or leave, no member control or parameter coordination, RTCP acts as a convenient channel to all participants, but does not need to support all the control communication requirements of the application. When RTP is applied in IP multicast, the first 3 functions are required and are recommended for all scenarios. RTP application designers must avoid the use of a mechanism that works only in unicast mode, which will result in the inability to scale.

RTCP Data Report
In the RTCP communication control, the function of RTCP protocol is realized by different RTCP datagram, there are several types:
①SR: Send side report, the so-called sending end refers to the application or terminal to emit RTP datagram, the sender can also be the receiving side.
②RR: The receive side reports that the so-called receiver is the application or terminal that receives but does not send RTP datagrams.
③sdes: Source Description, the main function is as a member of the session on identity information carrier, such as user name, e-mail address, telephone number, and also has the ability to communicate session control information to the session members.
④bye: Notification departure, the primary function is to indicate that one or several sources are no longer valid, that is, the other members in the notification session will exit the session themselves.
⑤app: Defined by the application itself, solves the extensibility problem of RTCP and provides a great deal of flexibility for the implementation of the Protocol.

sdes: Source Description RTCP Package
The SDEs package is a three-layer structure, consisting of a header and a block of data, a data block that can have no, or multiple, components that comprise the source indicated by the item description block. The item is described as follows:
Version (V), padding (P), length: As described in the SR package.
Package Type (PT): 8 bits, contains constant 202, identifies the RTCP SDEs package.
Source Count (SC): 5 bits, the number of SSRC/CSRC blocks contained in the SDEs package, 0 values valid, but meaningless.
The source description content is as follows:
CNAME: Canonical endpoint identity sdes The CNAME identity attribute is as follows:
In the event of a conflict or restart, a CNAME entry is required to provide a binding from the SSRC identity to the source identity that is still constant because the randomly assigned SSRC identity may change. Like the SSRC identity, the CNAME identity should be unique among all participants in the RTP connection. To provide a binding between the cross-media tools used by a participant in a related RTP connection, the CNAME should be pinned to that participant. To facilitate third-party monitoring, the CNAME should be suitable for program or personnel location sources.
Name: User name SDEs entry
BYE: Disconnecting the RTCP package
If the mixer receives a bye packet, the mixer forwards the bye package without changing the SSRC/CSRC identity. If the mixer is off, it should also issue a bye package that lists all the sources it handles, not just its own ssrc identity. As an option, the bye package can include a 8-bit octal count followed by many octal text, indicating the reason for leaving, such as "camera malfunction" or "RTP loop detected". The string has the same encoding, as described in SDEs. If the string fills the packet to the next 32-bit boundary, the string does not end with a null, otherwise the bye package is populated with an empty octal.
app: Define the app's RTCP package
App packs are used to develop experiments with new applications and features that do not require the registration of package type values. App packages with an unrecognized name should be ignored. After testing, it is recommended to redefine each app package without registering subtypes and name segments with the IANA, as determined by the wide range of applications.

RTSP (Real time streaming Protocol)
Protocol Features:

Extensibility: New methods and parameters are easy to join with RTSP.  
Easy to parse: RTSP can be parsed by a standard HTTP or MIME parser.  
Security: RTSP uses Web security.  
Independent of transport: RTSP transport channel, can use unreliable packet Protocol (UDP) or Reliable Packet Protocol (RDP), such as to achieve application-level reliability, you can use a reliable streaming protocol such as TCP.  
Record Device control: The protocol controls the recording and playback devices.  
Suitable for professional applications: with SMPTE time scales, RTSP supports frame-level accuracy, allowing remote digital editing.  
demonstrates neutrality: the protocol does not impose a special presentation or meta-file, which transmits the type of format used; However, the presentation description must contain at least one rtsp URI.  
Agent-to-firewall-friendly: The protocol can be handled by the application and transport layer firewalls. The firewall needs to understand the Setup method and open a "notch" for the UDP media stream.  
Appropriate server control: If a user initiates a stream, a stream can also be stopped.  
Transport Coordination: the user can coordinate the transfer method before the continuous media stream is actually processed.  
Performance Coordination: If the basic features are invalid, there must be a cleanup mechanism that lets the user decide that the method does not take effect. This allows the user to propose a suitable interface for themselves.  
Relationship to other protocols:

       RTSP is functionally overlapping with HTTP, and the most obvious crossover is in the publishing of streaming media content ——----mostly through web pages. The current protocol specification allows both Web servers and streaming media servers to support RTSP implementations. For example, the presentation description can be obtained via HTTP or RTSP, which reduces the round-trip time based on the browser, and also enables the standalone RTSP server to communicate with clients that do not rely on HTTP.  
      However, the essential difference between RTSP and HTTP lies in the following five aspects  
RTSP and HTTP are two different protocols that Different methods and protocol identifiers are used .   The data sent by the
RTSP protocol does not consume protocol bandwidth and is sent with a different protocol .  
HTTP is a asymmetric protocol , the client makes a request, and the server answers. In RTSP, both the client and the server can make the request, and the request is stateful.  
HTTP is a stateless protocol , and RTSP must maintain a certain state in any case, so that parameters can still be set and control the media stream for a long time after the request is confirmed.  
RTSP is defined using ISO 10646 (UTF-8) instead of the ISO 8859-1 definition, which remains consistent with the current HTML.  
       Although most live media uses RTP as the transport protocol, RTSP does not bind RTP. The ability to reuse HTTP has benefits in at least two ways: security and proxy. Because the requirements are very close, it is valuable to use HTTP functionality on caches, proxies, and authorizations.
1. Live Streaming Protocol RTSP

RTSP[3] Protocol works as a client server, a multimedia playback control protocol that enables users to control the playback of real-time data (audio and video streams) downloaded from the Internet, such as pause/resume, rewind, forward, etc. Therefore, RTSP is also known as "Internet Recorder Remote Control protocol." 1.1. RTSP Protocol Introduction

To achieve the control of RTSP, there is not only a protocol but also a dedicated media player and media server. The relationship between the media server and the media player is the relationship between the server and the customer. The biggest difference between a media server and an ordinary World Wide Web server is that the media server supports streaming audio and video transmission, so the client's media player can play while downloading (a program that needs to be cached for a short period of time). However, when downloading multimedia programs from the general World Wide Web server, the entire file is downloaded and then played back. RTSP only enables media players to control the transmission of multimedia streams. Therefore, RTSP is also referred to as out-of-band protocol, while multimedia streaming is using RTP to transmit in-band.

Figure 1 The relationship between RTSP and RTP and RTCP

1.2. RTSP's message structure

RTSP has two types of messages: Request messages and response messages .
A request message is a request message sent from a customer to the server, and a response message is an answer from the server to the customer. Since RTSP is body-oriented (text-oriented), each field in the message is a number of ASCII strings, so the length of each field is indeterminate. The RTSP message consists of three parts: the start line, the first row, and the entity body . In the request message, the start line is the request line, and the structure of the RTSP request message is shown in Figure 2.

Figure 2 Structure of the RTSP request message

The methods of the RTSP request message includeoptions(Obtain the available methods provided by the server),DESCRIBE(Get Session description information),Setup(the client reminds the server to establish a session, and determine the transfer mode), TEARDOWN(client initiates a shutdown request),announce(update session description),play(client sends a play request),PAUSE ( temporarily stops the stream without releasing the server resource ),get_parameter ( get flow control parameters, may not be supported by some servers ) and set_parameter ( set flow control parameters, some servers may not support ). The start line of the response message is the status line, and the structure of the RTSP response message is shown in Figure 3. Figure 3 Structure of the RTSP response message

1.3. RTSP interactive process  
C represents the RTSP client, S represents the RTSP server  
①c->s:    OPTION Request//Ask S what methods are available for  
    s->c:    OPTION Response//s response information includes all available methods provided  
②c->s:    DESCRIBE request//requires that the media initialization description information provided by S be  
    s->c:     DESCRIBE Response//s responds to media initialization description information, mainly sdp 
③c->s:    SETUP Request// Set session properties, as well as transfer mode, to alert S to establish session  
    s->c:    Setup Response//s Session, return session identifier and session-related information  
④c->s:    play request//c requests to play  
    s->c:    PLAY Response//s Response request Information  
    s->c:    send streaming media data  
⑤c->s:     TEARDOWN Request//c shutdown session  
    s->c:    TEARDOWN Response// s response request  
The above procedure is the standard RTSP process, where steps 3rd and 4th are required.  

Refer to http: where there is similar overlap in functionality with RTSP, RTSP uses most of the http/1.1 status codes and adds RTSP-specific status codes.
The HTTP protocol defines 8 possible request methods:
————————————
GET retrieves a simple request that identifies a resource in the URI
Head is the same as Get method, the server returns only the status row and header, and does not return the requested document
The POST server accepts requests that are written to data in the client output stream
The PUT server holds the request data as a request for the new content of the specified URI
Delete server deletes a request for a named resource in the URI
OPTIONS request for information about request methods supported by the server
The TRACE Web server feeds back requests for HTTP requests and their headers
CONNECT is a documented but not currently implemented method that is reserved for tunnel processing
————————————
The protocol specifications for RTSP and HTTP are described in detail in RFC2326 and RFC2616, respectively.
The MMS protocol is for Microsoft's private agreement, which is not publicly agreed. Using a private custom control structure to send commands, rather than using the Send Text command as HTTP,RTSP Protocol control