1.4. Delivery of Streaming Media Over Internet

Due to its ubiquitous existence, the Internet has become the platform of most networking activities including SM applications, where users require the integration of multimedia services. However, as a shared datagram network, the Internet is not naturally suitable for real-time traffic, such as SM. Dedicated links are not practical in many ways for transmitting SM data over the Internet. Moreover, because of the store-and-forwarding in routers and internetworking devices, Internet Protocol (IP) has some fundamental problems in transmitting real-time data. Thus, delivery of SM over the Internet requires special installation and new software development so that packets experience as little delay as possible. ATM is promising in transmitting real-time data because it supports high bandwidth connection-oriented transmission and various quality of service (QoS) for different applications. However, it is expensive and not widely available at user sites.

In general, the following issues must be resolved to stream multimedia data over the Internet.

• High Bandwidth

  The underlying hardware has to provide enough bandwidth to handle large size of multimedia data.

• Multicast

  Applications need to take into account multicast in order to reduce the traffic.

• Guaranteed Bandwidth

  There should be some mechanisms for real-time applications to reserve resources along the transmission path in order to guarantee QoS.

• Out of Order Delivery

  Applications need to take care of the timing issues so that audio and video data can be played back continuously with correct timing and synchronization. Applications also need to define standard operations for applications to manage the delivery and present the multimedia data.

This section explains several network protocols needed to support QoS over the Internet for many SM applications. Figure 1.8 shows their relations with other well-known protocols.

1.4.1. RTP

Media transport in many streaming applications is mainly implemented with RTP (Real-time Transport Protocol, RFC 1889) [148], which is an IP-based transport protocol for audio and video conferences and other multi-participant real-time applications. It is a lightweight protocol without error correction or flow control functionality. Thus, it guarantees neither QoS nor resource reservation along the network path. RTP is also designed to work in conjunction with the auxiliary control protocol, RTCP, to get feedback on quality of data transmission and information about participants in the ongoing session. RTP is primarily designed for multicast of real-time data, but it can be also used in unicast. It can be used for one-way transport such as video-on-demand as well as interactive services such as Internet telephony.

Multimedia applications require appropriate timing in data transmission and playing back. To support real-time SM data transmission, RTP provides timestamping, sequence numbering, and other mechanisms. Through these mechanisms, RTP provides end-to-end transport for real-time data over the datagram network.

• Timestamping is the most important information for real-time applications. The sender sets the timestamp when the packet was sampled. The receiver uses the timestamp to reconstruct the original timing. It can be also used to synchronize different streams with timing properties, such as audio and video data in MPEG. However, RTP itself is not responsible for the synchronization. This has to be done at the application level.

• Sequence numbers are used to determine the correct order because UDP does not deliver packets in timely order. It is also used for packet loss detection. Notice that in some video formats, when a video frame is split into several RTP packets, all of them can have the same timestamp. So timestamp alone is not enough to put the packets in order.

• The payload type identifier specifies the payload format as well as the encoding/compression schemes. Using this identifier, receiving application knows how to interpret and play out the payload data. Example specifications include PCM, MPEG1/MPEG2 audio and video, et al. More payload types can be added by providing a profile and pay-load format specification. At any given time of transmission, an RTP sender can only send one type of payload, although the payload type may change during transmission, for example, to adjust to network congestion.

• Source identification allows the receiving application to know where the data is coming from. For example, in an audio conference, from the source identifier a user could tell who is talking.

RTP is typically run on top of UDP. RTP is primarily designed for multicast, the connection-oriented TCP does not scale well and therefore is not suitable. For real-time data, reliability is not as important as timely delivery. Even more, reliable transmission provided by retransmission as in TCP is not desirable. RTP and RTCP packets are usually transmitted using UDP/IP service.

1.4.2. RTCP

RTCP (RTP Control Protocol) is the control protocol designed to work in conjunction with RTP. In an RTP session, participants periodically send RTCP packets to convey feedback on quality of data delivery and information of membership:

• RR (receiver report): Receiver reports reception quality feedback about data delivery, including the highest packet number received, the number of packets lost, inter-arrival jitter, and timestamps to calculate the round-trip delay between the sender and the receiver.

• SR (sender report): Sender reports a sender information section, providing information on inter-media synchronization, cumulative packet counters, and number of bytes sent.

• SDES (source description items): Information to describe the sources.

• APP (application specific functions): It is now intended for experimental use as new applications and new features are developed.

Using the above messages, RTCP provides the following services to control data transmission with RTP:

• QoS monitoring and congestion control. RTCP provides feedback to an application about the quality of data distribution. Sender can adjust its transmission based on the receiver report feedback. Receivers can know whether a congestion is local, regional or global. Network managers can evaluate the network performance for multicast distribution.

• Source identification. RTCP SDES (source description) packets contain textual information called canonical names as globally unique identifiers of the session participants. They may include a user's name, telephone number, e-mail address and other information.

• Inter-media synchronization. RTCP sender reports contain an indication of real time and the corresponding RTP timestamp. This can be used in inter-media synchronization like lip synchronization in video.

• Control information scaling. RTCP packets are sent periodically among participants. In order to scale up to large multicast groups, RTCP has to prevent the control traffic from overwhelming network resources. RTP limits the control traffic to at most 5% of the overall session traffic. This is enforced by adjusting the RTCP generating rate according to the number of participants.

1.4.3. RTSP

RTSP (Real Time Streaming Protocol, RFC 2326) is a client-server multimedia presentation protocol to enable controlled delivery of streamed multimedia data over IP network. RTSP provides methods to realize commands (play, fast-forward, fast-rewind, pause, stop) similar to the functionality provided by CD players or VCRs. RTSP is an application-level protocol designed to work with lower-level protocols like RTP and RSVP to provide a complete streaming service over the Internet. It can act as a network remote control for multimedia servers and can run over TCP or UDP. RTSP can control either a single or several time-synchronized streams of continuous media.

RTSP provides the following operations:

• Retrieval of media from media server. The client can request a presentation description, and ask the server to setup a session to send the requested data.

• Invitation of a media server to a conference. The media server can be invited to the conference to play back media or to record a presentation.

• Adding media to an existing presentation. The server and the client can notify each other about any additional media becoming available.

In RTSP, each presentation and media stream is identified by an RTSP URL. The overall presentation and the properties of the media are defined in a presentation description file, which may include the encoding, language, RTSP URLs, destination address, port, and other parameters. The presentation description file can be obtained by the client using HTTP, e-mail or other means. RTSP aims to provide the same services for streamed audio and video just as HTTP does for text and graphics. But RTSP differs from HTTP in several aspects. First, while HTTP is a stateless protocol, an RTSP server has to maintain "session states" in order to correlate RTSP requests with a stream. Second, HTTP is basically an asymmetric protocol where the client issues requests and the server responds, but in RTSP both the media server and the client can issue requests. For example, the server can issue a request to set playback parameters of a stream.

1.4.4. RSVP

RSVP (Resource reSerVation Protocol) is the network control protocol that allows the data receiver to request a special end-to-end quality of service for its data flows. Thus, real-time applications can use RSVP to reserve necessary resources at routers along the transmission paths so that the requested bandwidth can be available when the transmission actually takes place. RSVP is a main component of the future Integrated Services Internet which can provide both best-effort and real-time service.

RSVP is used to set up reservations for network resources. When an application in a host (the data stream receiver) requests a specific quality of service (QoS) for its data stream, it uses RSVP to deliver its request to routers along the data stream paths. RSVP is responsible for the negotiation of connection parameters with these routers. If the reservation is set up, RSVP is also responsible for maintaining router and host states to provide the requested service. Each node capable of resource reservation has several local procedures for reservation setup and enforcement. Policy control determines whether the user has administrative permission to make the reservation (authentication, access control and accounting for reservation). Admission control keeps track of the system resources and determines whether the node has sufficient resources to supply the requested QoS.

RSVP is also designed to utilize the robustness of current Internet routing algorithms. RSVP does not perform its own routing; instead it uses underlying routing protocols to determine where it should carry reservation requests. As routing changes paths to adapt to topology changes, RSVP adapts its reservation to the new paths wherever reservations are in place.