Standard Elements of RTP
The primary standard for audio/video transport in IP networks is the Real-time Transport Protocol (RTP), along with associated profiles and payload formats. RTP was developed by the Audio/Video Transport working
RTP provides a framework for the transport of real-time media and needs to be profiled for particular uses before it is complete. The RTP profile for audio and video conferences with minimal control was standardized along with RTP, and several more profiles are under development. Each profile is accompanied by several payload format specifications, each of which describes the transport of a particular media format.
The RTP Specification
RTP was published as an IETF proposed standard (RFC 1889) in January 1996, 6 and its revision for draft standard status is almost complete. 50 The first revision of ITU recommendation H.323 included a verbatim copy of the RTP specification; later revisions reference the current IETF standard.
RTP typically sits on top of UDP/IP transport, enhancing that transport with loss detection and
There are two
The RTP control protocol (RTCP) provides reception quality feedback, participant identification, and synchronization between media streams. RTCP runs
RTP supports the notion of
, middle boxes that can
It is hard to place RTP in the OSI reference model. It performs many of the
It is important to be aware of the limits of the RTP protocol specification because it is deliberately incomplete in two ways. First, the standard does not specify algorithms for media playout and timing regeneration, synchronization between media streams, error
Second, some details of the transport are left
At the time of this writing, there is a single RTP profile: the RTP profile for audio and video conferences with minimal control. This profile was published as a proposed standard (RFC 1890) along with the RTP specification in January 1996, 7 and its revision for draft standard status is almost complete. 49 Several new profiles are under development. Those likely to be available soon include profiles specifying additional security, 55 as well as feedback and repair mechanisms. 44
RTP Payload Formats
The final piece of the RTP framework is the payload formats, defining how particular media types are transported within RTP. Payload formats are referenced by RTP profiles, and they may also define certain properties of the RTP data transfer protocol.
The relation between an RTP payload format and profile is primarily one of namespace, although the profile may also specify some general behavior for payload formats. The namespace
The relation between a payload format and the RTP data transfer protocol is twofold: A payload format will specify the use of certain RTP header fields, and it may define an additional payload header. The output produced by a media codec is translated into a series of RTP data packets ”some parts mapping onto the RTP header, some into a payload header, and most into the payload data. The complexity of this mapping process depends on the design of the codec and on the degree of error resilience required. In some cases the mapping is simple; in others it is more complex.
At its simplest, a payload format defines only the mapping between media clock and RTP timestamp, and
Many payload formats have been defined, matching the diversity of codecs that are in use today, and many more are under development. At the time of this writing, the following audio payload formats are in common use, although this is by no means an exhaustive list: G.711, G.723.1, G.726, G.728, G.729, GSM, QCELP, MP3, and DTMF. 30 , 34 , 38 , 49 The commonly used video payload formats include H.261, H.263, and MPEG. 9 , 12 , 22
There are also payload formats that specify error correction schemes. For example, RFC 2198 defines an audio redundancy encoding scheme,
and RFC 2733 defines a generic forward error correction scheme based on parity coding.
In these payload formats there is an additional layer of indirection, the codec output is mapped onto RTP packets, and those packets
Two optional pieces of the RTP framework are worth mentioning at this stage: header compression and multiplexing.
Header compression is a means by which the overhead of the RTP and UDP/IP headers can be reduced on a per-link basis. It is used on bandwidth-constrained links ”for example, cellular and dial-up links ”and can reduce the 40-byte combination of RTP/UDP/IP headers to 2 bytes, at the expense of additional processing by the systems on the ends of the compressed link. Header compression is discussed further in Chapter 11.
is the means by which multiple
Both header compression and multiplexing can be considered to be part of the RTP framework. Unlike the profiles and payload formats, they are clearly special-purpose, optional parts of the system, and many implementations don't use either feature.
Video Over IP, Second Edition: IPTV, Internet Video, H.264, P2P, Web TV, and Streaming: A Complete Guide to Understanding the Technology (Focal Press Media Technology Professional Series)
The H.264 Advanced Video Compression Standard
Internet Communications Using SIP: Delivering VoIP and Multimedia Services with Session Initiation Protocol (Networking Council)
SIP: Understanding the Session Initiation Protocol (Artech House Telecommunications)