Realtime Transport Protocol (RTP)

Several solutions have appeared for the problem of timely, reliable delivery, but perhaps the most important solution to the Internet streaming puzzle is Realtime Transport Protocol (RTP). RTP defines a packet format and a standard method for transmitting audio and video streams over TCP/IP. The name announces RTP as a transport protocol, but the reality is a bit more complex. RTP does not replace the primary transport protocols but is, instead, built on top of UDP (see Figure 19.1) and uses UDP ports to reach the Internet.

You might be wondering how RTP gets away with using UDP, considering the reliability issues related to UDP transmission. As you learned in Hour 6, developers can write their own reliability mechanisms to go along with UDP. In the case of RTP, an accompanying protocol called Realtime Control Protocol (RTCP) monitors the quality of service for an RTP session. This allows the application to make adjustments to the stream—by varying the flow rate or perhaps switching to a less resourceintensive format or resolution. This approach doesn’t completely eliminate the problem, but it does provide additional options for monitoring the flow of packets.

RTP was originally described in RFC 1889, which has since been superseded by RFC 3550. The RTP header is shown in Figure 19.2. The fields in the header are

• Version— The version of RTP.

• Padding— Signals whether the packet contains one or more padding octets.

• Extension— Signals the existence of a header extension.

• CSRC count— Number of CSRC identifiers that follow the fixed header.

• Marker— Marks frame boundaries and other significant points in the packet stream.

• Payload type— Format of the payload.

• Sequence number— A number representing the place in the session that increments by one with each packet. This parameter can be used to detect lost packets.

• Timestamp— The sampling instant of the first octet in the payload.

• SSRC— Identifies a synchronization source.

• CSRC— Identifies contributing sources for the packet payload.

An optional RTP extension header allows individual application developers to experiment with modifications to improve performance and quality of service. Some vendors have rolled out their own versions of RTP—with varying degrees of compatibility.

The audio applications using RTP (or any other streaming protocol for that matter) must provide some form of buffering to ensure a steady stream of audio or video output. A buffer is a block of memory used for temporarily storing data as it is received. Buffering allows the application to process input at a steady rate even though the arrival rate might vary. As long as the buffer is never totally empty or totally full, the application receiving the data can process input at a constant rate.

The RT family also provides another protocol called Realtime Streaming Protocol (RTSP). RTSP sends commands that let the remote user control the stream. You can think of RTSP as something like a television remote. RTSP does not participate in the actual streaming, but it lets the user send commands like pause, play, and record to the server application.

A typical streaming scenario is shown in Figure 19.3. In this case, audio input is received through an audio interface and transmitted to a computer application, where it is converted to a digital format. Streaming software breaks the stream into discrete packets that are transmitted through RTP and the TCP/IP protocol stack to a streaming client, where data is received into a buffer and then read continuously from the buffer by a music player application that outputs sound to a pair of stereo speakers. Meanwhile, the RTCP protocol provides quality of service information to the applications participating in the session, and, if this were a prerecorded video or audio file instead of a real singer, the user on the client end could select options in the client application that send start or stop commands to the server through RTSP.