estimate actual voice call quality and exchange this information. Deriving this information from existing receiver reports is not possible. As a result, the definition of RTCP extended reports has driven additional implementation of RTCP.

12.3 Compression

RTP does not provide very efficient transport of media. For example, consider the iLBC codec used in the 12.2 kb/s mode with 20 ms packetization time (ptime) transported over RTP, UDP, IPv4, and Ethernet. The size in octets of each frame of codec data can be calculated using the formula:

= bw * ptime

frame

8

where frame is the frame size in octets (8 bits, or a byte), bw is the codec bandwidth, and ptime is the packetization time. For this example, each frame would contain 38 octets of codec data. RTP has a 12 octet header, UDP adds a 16 octet header, while IPv4 with no options adds 20 octets. Ethernet (IEEE 802.3) adds a 13-octet header and a 3-octet footer. As a result, the header overhead for this example is 60 octets! Overhead makes up over 60% of the total packet size. For normal Internet communications, this is how RTP is utilized. However, for some applications where RTP is to be used over low bit rate or wireless links, compression is performed. Note that saving bandwidth is only one reason to do compression. Compression can also reduce serialization delays when sending packets over very low speed links.

One method of compression is compressed RTP (CRTP) [5]. This method only compresses the RTP header fields, using the fact that many parts of the header are identical in every packet. For example, V, P, X, CC, PT, and SSRC typically do not change once a session has been setup, so they do not need to be sent every packet. Other parts of the header such as sequence numbers and timestamps can be sent as deltas, resulting in saved bandwidth.

Another method that compresses the entire RTP/UDP/IP stack is robust header compression (ROHC) [6]. ROHC can compress 40 octets of overhead into 2 octets. To do this, codebooks are used to encode and decode common elements. Codebooks can be either static—predefined for a given protocol—or dynamic—constructed and used during a given session. ROHC can also be used to compress SIP and the stack below SIP.

Although UDP is normally used, it is possible to transport RTP over a stream transport such as TCP. To do this, a framing method is used, which is defined in [7]. If TCP is used, the retransmissions of TCP must be carefully managed or the latency of the session will increase with every retransmission, resulting in very poor performance. Also, when using TCP for media, the roles

of each endpoint must be negotiated. One endpoint will be active, and initiate opening the TCP connection, while the other endpoint will be passive, listening on a port for an open request.

12.4 RTP Audio Video Profiles

The use of profiles enables RTP to be an extremely general media transport protocol. The current audio video profiles defined by RFC 3551 [8] and others are listed in Table 12.3. Four are defined, although only the first one is widely implemented. As secure Internet communications are deployed, the use of the secure audio and video profile (SAVP) is increasing, as described in Chapter 14. The most common profile is the RTP profile for audio and video conferences with minimal control, also known as the RTP/AVP profile. RTP/AVP makes the following specifications for RTP:

•UDP is used for underlying transport.

•RTP port numbers are always even—the corresponding RTCP port number is the next highest port, which is always an odd number.

•No header extensions are used.

Some common audio and video codecs are listed in Tables 12.4 and 12.5. The codecs listed with a payload number in the tables use a static payload number. The RTP/AVP profile document lists details of these codecs, or a reference for the details is provided. Codecs shown with a payload number of dynamic must use a dynamic payload in the range 96–127. Dynamic payloads must be defined dynamically during a session. The minimum payload support is defined as 0 (PCMU) and 5 (DVI4) (although in practice, most only support PCM). The document recommends dynamically assigned UDP port numbers, although ports 5004 and 5005 have been registered for use of the profile and can be used instead. The standard also describes the process of registering new payload types with IANA.

Table 12.3

Defined RTP Profiles

12.4.1 Audio Codecs

There are two main types of audio codecs—PSTN codecs and Internet codecs. PSTN codecs were developed for the circuit-switched world of the PSTN. They have been designed to minimize bandwidth but were not designed to function over a packet switched network such as the Internet. In particular, their quality rapidly degrades under conditions of packet loss, delay variation (jitter), and other common Internet impairments. Typically, these codecs are only usable when packet loss is less than 1%. Some examples include G.711 (PCM), G.721, G.723, and G.729A. G.711 is also known as pulse coded modulation (PCM) which has two variants, μ-law companding used mainly in the United States and Japan or A-law companding used in the rest of the world. G.711 is uncompressed, with 8 bits samples at 8,000 samples per second resulting in a 64 kb/s data stream. The others implement compression or linear prediction to reduce the bandwidth requirement. However, this compression makes their performance more sensitive to packet loss. For example, a single RTP packet of G.711 lost only affects that sampling interval while a single packet of G.729A can affect

audio quality for a number of sampling intervals. These codecs typically require less than 1% packet loss. PSTN codecs are designed based on 8 kHz sampling due a design limitation of the PSTN network which is not present on the Internet. Many of these codecs also have significant intellectual property (IPR) fees and licensing associated with them. Some modern PSTN codecs overcome some of these problems. For example, the adaptive multirate codec (AMR) [9] was developed by the mobile phone industry with packet transport in mind. As a result, it has reasonable performance under packet loss. There is also a wideband version known as AMR-WB. However, AMR still has significant intellectual property and licensing costs.

In contrast, Internet audio codecs were designed with the Internet in mind. They are designed to give good performance even under conditions of packet loss and delay variation. Also, many provide better-than-PSTN quality by ignoring the 8 kHz sampling limitation. Internet codecs that provide this higher quality are often known as wideband codecs. Examples of Internet codecs include the Internet low bit rate codec (iLBC) [10] and SPEEX [11]. Both of these codecs have no intellectual property or licensing costs, and open source implementations can be found on the Internet. These codecs still have reasonable quality even under conditions of up to 10% packet loss.

12.4.2 Video Codecs

Many of the considerations that apply to audio media transport also apply to video transport. However, there are some key differences. For example, the large amount of information present in every video frame, and the frequency of frame updates means that video requires very high bandwidth. Sending uncompressed video is essentially impractical over the Internet. There are two main techniques in video compression. One is intraframe compression, where information in a single frame is compressed. These frames are called I-frames or key frames. For example, a lossy compression technique such as JPEG could be used. A frame will often be transported in multiple RTP packets. In this case, the marker (M) bit is set on the last packet of a frame to indicate to the codec that the frame is ready for processing and rendering. The other compression technique is interframe compression, where successive frames are compared and differences and predictions made. Predicted frames are known as P-frames and are made relative to a key frame or I-frame. Since often only a small amount of the entire screen changes between each frame, this can result in very compressed, relatively static images. For example, in a telepresence video conference, the I-frame would encode the background image and the face of the person while P-frames could carry their moving lips, blinking eyes, and waving hands. In addition bipredicted frames which are based on multiple P-frames can be used to increase compression. For moving objects in an image, motion vectors of macroblocks can be used