Media Transport

network. However, RTP allows for the detection of some of the impairments introduced by an IP network, such as:

•Packet loss;

•Variable transport delay;

•Out of sequence packet arrival;

•Asymmetric routing.

Here is how RTP fits into the common media processing steps.

1.Coding. The coding step involves analog to digital conversion (A/D), which is implemented by low pass filtering, followed by sampling. The determination of how many bits per sample is specific to a particular codec (coder/decoder) algorithm. The particular codec used is transported by RTP in the payload type field. The sampling rate is carried in the offer/answer exchange in SDP, which negotiates the media session.

2.Packetization. The packetization step involves breaking the codec sample data into individual datagrams for transport. The determination of packet size is based on a tradeoff between packetization delay (how many sampling intervals must pass before enough data is ready for the datagram) and transport efficiency (each datagram has the fixed overhead of the RTP header and lower layer headers). Typically, packet sizes are chosen to be small so that packetization time is around 20 ms to 30 ms. Packetization involves adding the RTP header to the codec payload.

3.Tranport. RTP, as the name suggests, has a real-time nature, which requires a minimum latency (delay) across the Internet. There is never time to detect a missing packet, signal the loss, and wait for a retransmission. This might be possible for nonreal-time streaming media, but not real-time media. As a result, RTP does not usually use TCP transport but instead uses UDP transport. As a result, datagrams may be lost or may arrive out of sequence. Various fields in the RTP header field allow the detection of this.

4.Depacketization. The depacketization step involves removing the RTP header from the codec payload.

5.Buffering. The buffering step involves storing or buffering the codec samples before beginning playback. The choice of the buffer size for this step is critical for media quality. Too short a buffer will result in the buffer emptying and gaps in the media playback, while too long a buffer will introduce unpleasant latency. Adapting the size of the play-

back buffer when jitter or delay variation is occurring is best for media quality.

6.Decoding. The decoding step involves sending the codec packets to the codec algorithm. The right codec is chosen based on the received payload type in the RTP header.

7.Playback. The playback step involves rendering the media to the user as audio, video, or perhaps text (as we shall see in real-time text or text over IP, ToIP).

In terms of media quality, the two most important factors are the packet loss rate and the end-to-end latency. Lost packets mean gaps in the playback stream that the codec algorithm must try to compensate for. Different codecs use different techniques for packet loss concealment (PLC). For example, interpolation can be used to try to predict the missing samples based on received samples either side of the lost ones. A simple replay algorithm can be useful for some media types. Silence or comfort noise insertion can be used to prevent users noticing the dead air of lost samples. Some codecs employ forward error correction (FEC), which allows partial reconstruction of missing packets under low loss conditions. Note that packets aren’t really “lost” on the Internet, instead they are discarded by routers in the Internet due to congestion, or discarded by the RTP stack due to out of order arrival or late arrival resulting in missing their playback interval.

The end-to-end latency of real-time communications in general must be kept less than 150 ms. Longer latency than this affects the perceived quality of the call, resulting in users interrupting each other and starting and stopping when both parties speak at the same time. There are many sources of delay in the media path. The codec itself introduces delay as it gathers at least one sample or frame before beginning coding and decoding. The packetization step introduces a delay of around 20 ms, the time it takes to gather a full packet’s worth of data before sending it over the Internet. Transport delays are added by the routers and switches that forward and process the IP packets across the Internet. And finally, the buffering delay of the receiver to deal with jitter or delay variation also introduces latency. Some of these sources are shown in Figure 12.1.

Real-Time Transport Protocol (RTP) is an application layer protocol that uses UDP for transport over IP. RTP is not text encoded, but uses a bit-oriented header similar to UDP and IP. RTP version 0 is only used by the vat audio tool for MBONE broadcasts. Version 1 was a pre-RFC implementation and is not in use. The current RTP version 2 packet header has 12 octets. RTP was designed to be very general; most of the headers are only loosely defined in the standard; the details are left to profile documents. The header contains:

• Version (V): This 2-bit field is set to 2, the current version of RTP.

Figure 12.1 Sources of latency and packet loss on the Internet.

•Padding (P): If this bit is set, there are padding octets added to the end of the packet to make the packet a fixed length. This is most commonly used if the media stream is encrypted.

•Extension (X): If this bit is set, there is one additional extension following the header (giving a total header length of 14 octets). Extensions are defined by certain payload types.

•CSRC count (CC): This 4-bit field contains the number of content source identifiers (CSRC) that are present following the header. This field is only used by mixers that take multiple RTP streams and output a single RTP stream.

•Marker (M): This single bit is used to indicate the end of a complete frame in video, or the start of a talk-spurt in silence-suppressed speech.

•Payload type (PT): This 7-bit field defines the codec in use. The value of this field matches the profile number listed in the SDP.

•Sequence Number: This 16-bit field is incremented for each RTP packet sent and is used to detect missing/out of sequence packets.

•Timestamp: This 32-bit field indicates in relative terms the time when the payload was sampled. This field allows the receiver to remove jitter and to play back the packets at the right interval assuming sufficient buffering.

•Synchronization source identifier (SSRCI): This 32-bit field identifies the sender of the RTP packet. At the start of a session, each participant chooses an SSRC number randomly. Should two participants choose the same number, they each choose again until each party is unique.

• Contributing source identifier (CSRC): There can be none or up to 15 instances of this 32-bit field in the header. The number is set by the CSRC count (CC) header field. This field is only present if the RTP packet is being sent by a mixer, which has received RTP packets from a number of sources and sends out combined packets. A nonmulticast conference bridge would utilize this header.

RTP allows detection of a lost packet by a gap in the Sequence Number. Packets received out of sequence can be detected by out-of-sequence Sequence Numbers. Note that RTP allows detection of these transport-related problems but leaves it up to the codec to deal with the problem. For example, a video codec may compensate for the loss of a packet by repeating the last video frame, while an audio codec may play background noise for the interval. Variable delay or jitter can be detected by the Timestamp field. A continuous bit rate codec such as PCM will have a linearly increasing Timestamp. A variable bit rate codec, however, which sends packets at irregular intervals, will have an irregularly increasing Timestamp, which can be used to play back the packets at the correct interval.

RTP media sessions are unidirectional—they define how media is sent from the media source to the media sink. As such, a normal bidirectional media session is actually two RTP sessions, one in each direction.

In a multimedia session established with SIP, the information needed to select codecs and send the RTP packets to the right location is carried in the SDP message body. Under some scenarios, it can be desirable to change codecs during an RTP session. An example of this relates to the transport of dual tone multiple frequency (DTMF) digits. A low bit rate codec that is optimized for transmitting vocal sounds will not transport the superimposed sine waves of a DTMF signal without introducing significant noise, which may cause the DTMF digit receiver to fail to detect the digit. As a result, it is useful to switch to another codec when the sender detects a DTMF tone. Because an RTP packet contains the payload type, it is possible to change codecs on the fly without any signaling information being exchanged between the UAs. On the other hand, switching codecs in general should probably not be done without a SIP signaling exchange (re-INVITE) because the call could fail if one side switches to a codec that the other does not support. The SIP re-INVITE message exchange allows this change in media session parameters to fail without causing the established session to fail.

The use of random numbers for SSRC provides a minimal amount of security against “media spamming” where a literally uninvited third party tries to break into a media session by sending RTP packets during an established call. Unless the third party can guess the SSRC of the intended sender, the receiver will detect a change in SSRC number and either ignore the packets or inform the user that something is going on. This behavior for RTP clients, however, is not