Real-time Transport Protocol (RTP)
RTP (version 2) is a real-time transport protocol that provides end-to-end delivery services to support applications transmitting real-time data, e.g.,
interactive audio and video, over unicast and multicast network services. RTP is defined in IETF RFC 1889, along with a profile for carrying audio and video over
RTP in RFC 1890. Both are IETF Proposed Standards, and are expected to be finalized in early 1997. RTP is used on the MBONE by vat, the video/audio tool. In addition
commercial implementations of RTP and applications that use RTP are currently available for a number of platforms.
RTP services include payload type identification, sequence numbering, and time stamping. Delivery is monitored by means of a closely integrated control protocol called
RTCP (see next section).
RTP provides end-to-end delivery services, but it does not provide all of the functionality that is typically provided by a transport protocol. In fact, RTP typically
runs on top of UDP to utilize its multiplexing and checksum services. Other transport protocols besides UDP can carry RTP as well.
The RTP header provides the timing information necessary to synchronize and display audio and video data and to determine whether packets have been lost or have arrived
out of order. In addition, the header specifies the payload type, thus allowing multiple data and compression types. RTP is tailored to a specific application via auxiliary
profile and payload format specifications. As an example, a payload format might specify what type of audio or video encoding is carried in the RTP packet. Encoded data can
be compressed before delivery.
To set up an RTP session, the application defines a particular pair of destination transport addresses (one network address plus a pair of ports for RTP and RTCP).
In a multimedia session, each medium is carried in a separate RTP session, with its own RTCP packets reporting the reception quality for that session. For example, audio
and video would travel on separate RTP sessions, enabling a recipient to select whether or not to receive a particular medium.
An audio-conferencing scenario presented in RFC 1889 illustrates the use of RTP. Suppose each participant sends audio data in segments of 20 ms duration. Each segment of
audio data is preceded by an RTP header, and then the resulting RTP message is placed in a UDP packet. The RTP header indicates the type of audio encoding that is used, e.g.,
PCM. Users can opt to change the encoding during a conference in reaction to network congestion or, for example, to accommodate low-bandwidth requirements of a new conference
participant. Timing information and a sequence number in the RTP header are used by the receivers to reconstruct the timing produced by the source, so that in this example,
audio segments are contiguously played out at the receiver every 20 ms.
RTP does not provide any mechanisms to ensure timely delivery or provide quality-of-service guarantees. It does not guarantee delivery or prevent out-of-order delivery,
nor does it assume that the underlying network is reliable. Some adaptive applications do not require such guarantees, but for those that do, RTP must be accompanied by other
mechanisms to support resource reservation and to provide reliable service.
Real-time Control Protocol (RTCP)
RTCP is the control protocol that works in conjunction with RTP. RTCP control packets are periodically transmitted by each participant in an RTP session to all other
participants. Feedback of information to the application can be used to control performance and for diagnostic purposes.
RTCP performs the following four functions.
1) Provide information to application:
The primary function is to provide information to an application regarding the quality of data distribution. Experiments with IP multicasting have established the
importance of user feedback from RTCP to diagnose distribution faults. Each RTCP packet contains sender and/or receiver reports that report statistics useful to the
application. These statistics include number of packets sent, number of packets lost, interarrival jitter, etc. This reception quality feedback will be useful for the
sender, receivers, and third-party monitors. For example, the sender may modify its transmissions based on the feedback; receivers can determine whether problems are local,
regional or global; network managers may use information in the RTCP packets to evaluate the performance of their networks for multicast distribution
2) Identify RTP source:
RTCP carries a transport-level identifier for an RTP source, called the canonical name (CNAME). This CNAME is used to keep track of the participants
in an RTP session. Receivers use the CNAME to associate multiple data streams from a given participant in a set of related RTP sessions, e.g., to synchronize audio and video.
3) Control RTCP transmission interval:
To prevent control traffic from overwhelming network resources and to allow RTP to scale up to a large number of session participants, control
traffic is limited to at most 5 percent of the overall session traffic. This limit is enforced by adjusting the rate at which RTCP packets are transmitted as a function of the
number of participants. Since each participant sends control packets to everyone else, each can keep track of the total number of participants and use this number to calculate
the rate at which to send RTCP packets.
4) Convey minimal session control information:
As an optional function, RTCP can be used as a convenient method for conveying a minimal amount of information to all session participants.
For example, RTCP might carry a personal name to identify a participant on the user's display. This function might be useful in loosely controlled sessions where participants
informally enter and leave the session.