Real-Time Transport | IP Telephony-Related Standards

Deals with the standards that are pertinent to the mechanisms of carrying voice and video over IP networks. These standards are essential to interworking with the PSTN because IP telephony gateways need to convert the IP voice and video payload into a form that is accepted by the PSTN and, conversely, translate the PSTN voice and video payload into a form that is accepted by IP networks. The gateways also need to reconstruct the original voice or video stream to be as close to the original as possible. Naturally, such reconstruction should retain the real-time properties of the original stream. In addition, an interactive application—such as a two-person voice call—also requires that the transport service itself be fast, reliable, and perceived as “free” of jitter (that is, high variation in delay) to maintain the perception of a real-time interaction.

These real-time transport requirements explain why the protocol suite, developed by the Audio/Video Transport (avt) IETF working group (see www.ietf.org/html.charters/avt-charter.html) has been called Real-Time Transport Protocol (RTP) in RFC 1889 (Schulzrinne et al., 1996). RTP has been designed for multicast, as well as point-to-point, transmission and is accompanied by its quality control component, Real-Time Control Protocol (RTCP). Both protocols are carried by the User Datagram Protocol (UDP).

RTP specifies the header of the packets that carry streams of encoded audio or video samples. This encoding is performed by a device (or software module) called a coder; the subsequent decoding is performed by a decoder, but for full-duplex communications, both are usually combined in a codec. RTP specifies the payload format, which, in turn, identifies a specific codec. (The avt working group has also developed a number of RFCs that deal with payload formats.) The codec header, which is appended to the RTP header, determines the format of the attached encoded data unit (called a frame).

Since UDP does not guarantee sequencing (that is, arrival of packets in the order they were sent), this function is assisted by RTP, which stipulates the inclusion of sequence numbers in packets. Sequence numbers are used at the receiver not only to reconstruct the original sequence, but also to keep count of lost packets (one of the quality of service statistics fed back to the sender via RTCP).

RTP deals with any jitter by time-stamping packets. At the receiving end, the play-out devices buffer the packets and then reconstruct the stream at the original rate. Another synchronization mechanism is the marker bit of the header, which, according to RFC 1889, “is intended to allow significant events such as frame boundaries to be marked in the packet stream.”

The RTCP packets are sent to exactly the same addresses as the RTP ones, but on different ports. The primary function of RTCP is to carry, from receivers to senders, the statistics on the number of lost packets, jitter, and round-trip delays. RTCP carries sender reports in the opposite direction. The statistics are used by senders to adjust encoding rates (and, possibly, the choice of codecs) in order to use less bandwidth. In addition, the statistics are useful for network management as the mechanism to detect the type and location of network problems (such as congestion). In addition to supporting quality control, RTCP performs the following functions:

·         Synchronization of video and audio streams

·         Identification of session participants (by their full names, telephone numbers, and e-mail addresses)

·         Session control (through indication that a user is leaving the session and user-to-user control messages)

Real-Time Streaming Protocol (RTSP), developed in the Multiparty Multimedia Session Control (mmusic) working group, is a network remote control for multimedia services, as defined in RFC 2326 (Schulzrinne et al., 1998). The main purpose of the protocol is to control a device for so-called stored media [for example, a compact disc (CD) player, tape recorder, and so on]. But the control here actually encompasses playing the device, which evolves the transfer of the stream across the network. The applicability of this protocol to the task of integrating the PSTN and the Internet can be found in the areas of voice and video messaging. Like SIP, RTSP is also a descendant of HTTP, but unlike SIP, RTSP maintains a virtual connection identifier by assigning a session identifier in the beginning of the session and then keeping it in all messages relevant to the session. RTSP defines its own URL in reference to the media servers. RTSP can also interwork with SIP, as explained in Schulzrinne and Rosenberg (1999).