RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers.
RTP itself does not provide any mechanism to ensure timely delivery or provide other quality-of-service guarantees, but relies on lower-layer services to do so. It does not guarantee delivery or prevent out-of-order delivery, nor does it assume that the underlying network is reliable and delivers packets in sequence. The sequence numbers included in RTP allow the receiver to reconstruct the sender’s packet sequence, but sequence numbers might also be used to determine the proper location of a packet, for example in video decoding, without necessarily decoding packets in sequence.
While RTP is primarily designed to satisfy the needs of multi-participant multimedia conferences, it is not limited to that particular application. Storage of continuous data, interactive distributed simulation, active badge, and control and measurement applications may also find RTP applicable.
The RTP header has the following format:
The first twelve octets are present in every RTP packet, while the list of CSRC identifiers is present only when inserted by a mixer.
RTP Control Protocol — RTCP
The RTP control protocol (RTCP) is based on the periodic transmission of control packets to all participants in the session, using the same distribution mechanism as the data packets. The underlying protocol must provide multiplexing of the data and control packets, for example using separate port numbers with UDP. RTCP performs four functions:
• The primary function is to provide feedback on the quality of the data distribution. This is an integral part of the RTP’s role as a transport protocol and is related to the flow and congestion control functions of other transport protocols.
• RTCP carries a persistent transport-level identifier for an RTP source called the canonical name or CNAME. Since the SSRC identifier may change if a conflict is discovered or a program is restarted, receivers require the CNAME to keep track of each participant.
• The first two functions require that all participants send RTCP packets, therefore the rate must be controlled in order for RTP to scale up to a large number of participants. By having each participant send its control packets to all the others, each can independently observe the number of participants. This number is used to calculate the rate at which the packets are sent.
• A fourth, optional function is to convey minimal session control information, for example participant identification to be displayed in the user interface.
The RTP protocol seems to suite the delivery of the real time traffic pretty well. The RTP protocol provides timing information and the identification of the source and the payload type for the multimedia applications. The accompanying control protocol, RTCP, provides information about the perceived quality of service. However, there are some limitations in the scalability of the RTP scheme. Header overhead may become a problem on low-speed links or on large trunk lines. Thus, a header compression scheme and a user multiplexing scheme are presented. Also the amount of the control traffic may need to be limited. Large multicast groups may utilize timer reconsideration and enhanced group membership sampling to avoid congestion and memory problems.
