Real-time Transport Protocol
The Real-time Transport Protocol (RTP) defines a standardized protocol in the TCP/IP protocol suite intended to support the transport of information that has a real-time nature, such as interactive voice and video, across a packet network. RTP is standardized by the IETF as an RFC. Specifically, it is standardized in RFC 3550 (2003) which obsoleted RFC 1889 (1996).
RTP And the OSI Reference Model
RTP is a layer of protocol corresponding roughly to the Session Layer of the OSI Reference Model. Data from the Application Services Layer is passed to RTP which sequences and timestamps it prior to passage to the User Datagram Protocol (UDP). Although technically RTP can be mapped to either TCP or UDP, most real-time applications can tolerate some amount of data loss and cannot tolerate the significant delay associated with recovery from data loss. As a consequence, TCP is typically a bad choice for transporting such information and UDP is more commonly used. RTP does not have well-known UDP or TCP port number, but it is always allocated an even port number in the range 16384-32766 and RTCP (see below) is allocated the next odd-numbered port number.
RTP's association with the Session Layer comes from it's ability to multiplex multiple sessions into a single stream and differentiate between these streams at the remote end. It is also due to the fact that RTP is built on top of another Transport Layer protocol: UDP. However, the TCP/IP Reference Model does not include a Session Layer. So when this model is depicted, RTP is typically depicted as an extension of the Transport Layer, or as an Applications Services Layer function. A good argument can be made that the former is more appropriate.
The timing information in the RTP header permits receivers to synchronize real-time session flows from real-time applications. A Sequence Number field permits receivers to recognize lost data units, as well as to reorder any data units that arrive out of sequence. Finally, a field in the RTP header indicates the characteristics of the enclosed payload. Senders and receivers can use this indicator to support multiple data types and compression algorithms simultaneously. Although RTP can recognize lost data units, it makes no attempt to recover them. This makes sense because RTP only applies to time-sensitive information; recovery of lost data units is not an issue.
A related protocol, the Real-time Transport Control Protocol (RTCP), supports mechanisms through which network nodes can pass quality of service (QoS) status information both to users and to their peers. In this fashion, RTCP can control the rate at which a real-time application sends data. RTCP is also useful as a mechanism through which network managers can monitor QoS and perform remote diagnostics in the event of a QoS problem. It is important to note that neither RTP nor RTCP ensure QoS from the underlying network. This is a common philosophy in TCP/IP: the operational characteristics of the underlying network are separate from the applications trying to use them. RTP and RTCP can be used over any underlying IP-based network. But if the underlying network cannot or does not provide QoS for the real-time traffic, RTP can do nothing about it.
RTP Header Structure
The RTP header structure is depicted to the right. The fields include:
- Version (2 bits): This field indicates the RTP version number being implemented.
- Padding (1 bit): Some encryption systems operate on blocks of information that have a fixed length, which may require the use of a pad field to extend the information to an exact multiple of this length. This bit indicates when such a pad is present at the end of the data field. Is a pad is present, the last byte of the pad indicates the length of the pad in bytes.
- Extension (1 bit): RTP defines a number of extensions to the protocol that require additional fields. This bit indicates whether or not these fields are present in the form of an extension header at the end of the RTP header proper.
- Contributing Source Count(4 bits): The RTP payload can carry information from multiple Contributing Sources (CSRC). This makes it possible, for example, to carry both video and voice in a single message for a video session with accompanying audio. This field indicates the number of contributing sources for the current message, and there will be a corresponding number of contributing source identifiers at the end of the header proper.
- Marker (1 bit): This bit is reserved for use by the upper layers (e.g., the Applications Services Layer) which defines its meaning. It is intended for indicating special events in the payload, such as the end of a video frame, or the start of a new video frame.
- Payload Type (7 bits): Identifies the type of information being carried in the payload field of this RTP message
- Sequence number (16 bits): This field is essentially a simple counter that starts at a random value when a session begins and increments by one with each RTP message sent in that session. It provides a mechanism for the receiver to re-sequence packets that arrive out of order and to detect missing elements.
- Timestamp (32 bits): This field carries the time index for the first sample of the RTP message. The frequency of the clock is payload dependent. The receiver can use this field to reassemble the information stream with the appropriate timing, allowing for such things as compression, silence suppression, and lost messages.
- Synchronization source (SSRC) Identifier (32 bits): A random number that uniquely identifies this media stream (timestamp and sequence number combination). This is used to distinguish between multiple RTP streams arriving at the same system.
If the CSRC Count (CC) field is non-zero, the header proper will be followed by the indicated number of 32-bit CSRC identifiers. If the Extension field is set, the header proper (and any CSRC identifiers) will be followed by a single header extension field. The first 32-bit field will indicate the header extension length, followed by the header extension. This makes RTP very flexible and extensible.
|<mp3>http://podcast.hill-vt.com/podsnacks/2007q4/rtp.mp3%7Cdownload</mp3> | Real-time Transport Protocol|