Media Data Streaming - Scalable Continuous Media Streaming Systems - page 115

media streams, such as the encoding format, to enable the client to select and prepare for
playback of the media. Each controllable media stream is identified by a separate RTSP URL,
which is similar to HTTP UTL in that it identifies the server hosting the media stream and the
logical path identifying the media stream. Note that the media streams in a presentation may
come from multiple servers and each stream is controlled via a separate RTSP session. The
interested readers are referred to RFC 2326 for the specification of the protocol.

6.2.2 Real-Time Transport Protocol (RTP)
RTP is designed for transporting data in real-time applications such as audio and video confer-
encing. The protocol has been designed to be independent from the lower-layer protocol which
ultimately carries the RTP packets. In the Internet RTP packets are often carried over UDP
datagrams, which provides multiplexing of RTP flows within the same host (using different
UDP port numbers for different flows). RTP also supports data delivery over both unicast and
multicast network transports (e.g., IP multicast). A control protocol - RTP Control Protocol
(RTCP) - is defined as part of the standard to provide control functions such as synchronization,
reception statistics reporting (e.g., loss and delay jitter), participants monitoring, etc.
It is worth noting that RTP/RTCP on their own do not provide quality-of-service control/
guarantee or perform network resource reservations. The protocols are designed to provide the
necessary framework, such as header fields (sequence number, payload identification, etc.) in
RTP and quality feedbacks (loss and delay jitter) in RTCP, for developers to implement their
own quality-of-service mechanisms which are likely to be network- and application-specific.
Thus, the RTP/RTCP protocols are often extended and integrated into the application instead
of existing as standalone general purpose transport protocols like UDP and TCP.
Another point worth noting is that the standard RFC 3550 does not define how the media
data is to be stored inside the RTP payload. This is specified in a profile specification in separate
RFCs, such as RFC 3551 (a profile for audio and video data) [9].
Figure 6.4 depicts the header format for RTP packets. The header is divided into a 12-byte
fixed header that exists in all RTP packets, and a variable part containing optional headers such

8 bits 8 bits 8 bits 8 bits

V P X CC M PT Sequence Number

Timestamp

Synchronization Source (SSRC) Identifier

. . .

Fixed part of 12 bytes, variable optional headers.
• V is the version number (V=2 in current RTP version)
• P is padding bit, set if there are padding bytes in the payload.
• X set if there is one header extension after the fixed header.
• CC counts the number of contributing source identifiers
following the fixed header.
• M used as a marker (e.g., for frame boundary), defined by a profile.
• PT is the payload type as defined in the profile.

Figure 6.4 Format of the RTP packet header