Multimedia over IP - 04

RTCP -- Real-Time Control Protocol

The future Integrated Services Internet will provide means to transmit real-time multimedia data across networks. RSVP, RTP, RTCP and RTSP are the foundation of real-time services. RTCP is the control part of RTP that helps with quality of service and membership management. RTCP is the control protocol designed to work in conjunction with RTP. It is standardized in RFC 1889 and 1890. In an RTP session, participants periodically send RTCP packets to convey feedback on quality of data delivery and information of membership.

1. Protocol functions -
   

RTCP provides three basic functions expected to be implemented in all RTP sessions:

• The primary function of RTCP is to gather statistics on quality aspects of the media distribution during a session and transmit this data to the session media source and other session participants. Such information may be used by the source for adaptive media encoding (codec) and detection of transmission faults. If the session is carried over a multicast network, this permits non-intrusive session quality monitoring.
  
• RTCP provides canonical end-point identifiers (CNAME) to all session participants. Although a source identifier (SSRC) of an RTP stream is expected to be unique, the instantaneous binding of source identifiers to end-points may change during a session. The CNAME establishes unique identification of end-points across an application instance (multiple use of media tools) and for third-party monitoring.
  
• RTCP reports are expected to be sent by all participants, even in a multicast session which may involve thousands of recipients. Such traffic will increase proportionally with the number of participants. Thus, to avoid network congestion, the protocol must include session bandwidth management. This is achieved by dynamically controlling the frequency of report transmissions. RTCP bandwidth usage should generally not exceed 5% of total session bandwidth. Furthermore, 25% of the RTCP bandwidth should be reserved to media sources at all times, so that in large conferences new participants can receive the CNAME identifiers of the senders without excessive delay.
  
• A fourth, optional feature, is the provisioning of session control functions, because RTCP is a convenient means to reach all session participants, whereas RTP itself is not. RTP is only transmitted by a media source.
  

1. Message types
   

RTCP distinguishes several types of packets: sender report, receiver report, source description, and bye. In addition, the protocol is extensible and allows application-specific RTCP packets. A standards-based extension of RTCP is the Extended Report packet type introduced by RFC 3611 RFC 1889 defines five RTCP packet types to carry control information. These five types are:

1. RR: Receiver Report
   

Receiver reports are generated by participants that are not active senders. They contain reception quality feedback about data delivery, including the highest packets number received, the number of packets lost, inter-arrival jitter, and timestamps to calculate the round-trip delay between the sender and the receiver.

1. SR: Sender Report
   

Sender reports are generated by active senders. In addition to the reception quality feedback as in RR, they contain a sender information section, providing information on inter-media synchronization, cumulative packet counters, and number of bytes sent.

1. SDES: Source Description
   

The Source Description message is used to send the CNAME item to session participants. It may also be used to provide additional information such as the name, e-mail address, telephone number, and address of the owner or controller of the source. They contain information to describe the sources.

1. BYE: End of participation
   

A source sends a BYE message to shut down a stream. It allows an end-point to announce that it is leaving the conference. Although other sources can detect the absence of a source, this message is a direct announcement. It is also useful to a media mixer. It indicates end of participation.

1. APP: Application Specific Functions
   

The application-specific message provides a mechanism to design application-specific extensions to the RTCP protocol. It is now intended for experimental use as new applications and new features are developed.

1. Services
   

Through these control information packets, RTCP provides the following services:

1. QoS Monitoring And Congestion Control
   

This is the primary function of RTCP. RTCP provides feedback to an application about the quality of data distribution. The control information is useful to the senders, the receivers and third-party monitors. The sender can adjust its transmission based on the receiver report feedback. The receivers can determine whether congestion is local, regional or global. Network managers can evaluate the network performance for multicast distribution.

1. Source Identification
   

In RTP data packets, sources are identified by randomly generated 32-bit identifiers. These identifiers are not convenient for human users. RTCP SDES (source description) packets contain textual information called canonical names as globally unique identifiers of the session participants. It may include user's name, telephone number, email address and other information.

1. 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.

1. Control Information Scaling
   

RTCP packets are sent periodically among participants. When the number of participants increases, it is necessary to balance between getting up-to-date control information and limiting the control traffic. 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.

Multimedia over IP - 01

Multimedia over IP - Introduction

Internet will provide means to transmit real-time multimedia data across networks. RSVP, RTP, RTCP and RTSP are the foundation of real-time services.

Figure 1: Multimedia Communication Demand

Multimedia Networking: Goals and Challenges

Computer networks were designed to connect computers on different locations so that they can share data and communicate. In the old days, most of the data carried on networks was textual data. Today, with the rise of multimedia and network technologies, multimedia has become an indispensable feature on the Internet. Animation, voice and video clips become more and more popular on the Internet. Multimedia networking products like Internet telephony, Internet TV, video conferencing have appeared on the market. In the future, people would enjoy other multimedia products in distance learning, distributed simulation, distributed work groups and other areas.

For networkers, multimedia networking is to build the hardware and software infrastructure and application tools to support multimedia transport on networks so that users can communicate in multimedia. Multimedia networking will greatly boost the use of computer as a communication tool. We believe someday multimedia networks will replace telephone, television and other inventions that had dramatically changed our life.

1. The Real-time Challenge

However, multimedia networking is not a trivial task.

Figure 2: Mission Critical Applications

We can expect at least three difficulties.

1) First, compared with traditional textual applications, multimedia applications usually require much higher bandwidth. A typical piece of 25 second 320x240 QuickTime movie could take 2.3MB, which is equivalent to about 1000 screens of textual data.

2) Second, most multimedia applications require the real-time traffic. Audio and video data must be played back continuously at the rate they are sampled. If the data does not arrive in time, the playing back process will stop and human ears and eyes can easily pick up the artifact. In Internet telephony, human beings can tolerate a latency of about 250 milliseconds. If the latency exceeds this limit, the voice will sound like a call routed over a long satellite circuit and users will complain about the quality of the call. In addition to the delay, network congestion also has more serious effects on real-time traffic. If the network is congested, the only effect on non-real-time traffic is that the transfer takes longer to complete, but real-time data becomes obsolete and will be dropped if it doesn't arrive in time. If proper reaction is not taken, the retransmission of lost packets would aggravate the situation and jam the network.

3) Third, multimedia data stream is usually bursty. Just increasing the bandwidth will not solve the burstiness problem. For most multimedia applications, the receiver has a limited buffer. If no measure is taken to smooth the data stream, it may overflow or underflow the application buffer. When data arrives too fast, the buffer will overflow and the some data packets will be lost, resulting in poor quality. When data arrives too slowly, the buffer will underflow and the application will starve.

Contrary to the high bandwidth, real-time and bursty traffic of multimedia data, in real life, networks are shared by thousands and millions of users, and have limited bandwidth, unpredictable delay and availability. How to solve these conflicts is a challenge multimedia networking must face.

The possibility of answering this challenge comes from the existing network software architecture and fast developing hardware. The basis of Internet, TCP/IP and UDP/IP, provides a range of services that multimedia applications can use. Fast networks like Gigabit Ethernet, FDDI, and ATM provide high bandwidth required by digital audio and video.

So the design of real-time protocols for multimedia networking becomes imperative before the multimedia age comes.

1. Multimedia Over Internet

There are other ways to transmit multimedia data, like dedicated links, cables and ATM. However, the idea of running multimedia over Internet is extremely attractive.

Dedicated links and cables are not practical because they require special installation and new software. Without an existing technology like LAN, WAN, the software development will be extremely expensive. ATM was said to be the ultimate solution for multimedia because it supports very high bandwidth, is connection-oriented and can tailor different level of quality of service to different type of applications. But at this moment, very few users have ATM networks reaching their organization; even fewer have ATM connections to their desktops.

Figure 3: Media over ATM Access

On the other hand, the Internet is growing exponentially. The well established LAN and WAN technologies based on IP protocol suite connect bigger and bigger networks all over the world to the Internet. In fact, Internet has become the platform of most networking activities. This is the primary reason to develop multimedia protocols over Internet. Another benefit of running multimedia over IP is that users can have integrated data and multimedia service over one single network, without investing on network hardware and building the interface between two networks.

At current time, IP and Ethernet seem to be more favored in the desktops and LANs, with ATM in wide area networks. As a shared datagram network, Internet is not naturally suitable for real-time traffic. To run multimedia over Internet, several issues must be solved.

1) First, multimedia means extremely dense data and heavy traffic. The hardware has to provide enough bandwidth.

2) Second, multimedia applications are usually related to multicast, i.e., the same data stream, not multiple copies, is sent a group of receivers. For example, in video conference, the video data need to be sent to all participants at the same time. Live video can be sent to thousands of recipients. The protocols designed for multimedia applications must take into account multicast in order to reduce the traffic.

3) Third, the price tag attached shared network resources is unpredictable availability. But real-time applications require guaranteed bandwidth when the transmission takes place. So there must be some mechanisms for real-time applications to reserve resources along the transmission path.

4) Fourth, Internet is a packet-switching datagram network where packets are routed independently across shared networks. The current technologies cannot guarantee that real-time data will reach the destination without being jumbled and jerky. Some new transport protocols must be used to take care of the timing issues so that audio and video data can be played back continuously with correct timing and synchronization.

5) Fifth, there should be some standard operations for applications to manage the delivery and present the multimedia data.

1. The Solution

The Internet carries all types of traffic; each type has different characteristics and requirements. For example, a file transfer application requires that some quantity of data is transferred in an acceptable amount of time, while Internet telephony requires that most packets get to the receiver in less than 0.3 seconds. If enough bandwidth is available, best-effort service fulfills all of these requirements. When resources are scarce, however, real-time traffic will suffer from the congestion.

The solution for multimedia over IP is to classify all traffic, allocate priority for different applications and make reservations. The Integrated Services working group in the IETF (Internet Engineering Task Force) developed an enhanced Internet service model called Integrated Services that includes best-effort service and real-time service, see RFC 1633. The real-time service will enable IP networks to provide quality of service to multimedia applications. Resource ReServation Protocol (RSVP), together with Real-time Transport Protocol (RTP), Real-Time Control Protocol (RTCP), Real-Time Streaming Protocol (RTSP), provides a working foundation for real-time services. Integrated Services allows applications to configure and manage a single infrastructure for multimedia applications and traditional applications. It is a comprehensive approach to provide applications with the type of service they need and in the quality they choose.

Figure 4: Streaming Architecture

Figure 4 depicts a typical streaming session, in which a piece of media content is delivered from a server to a client on-demand. The client requests the media using RTSP, and receives a description of how to access and decode the media flows for this session. The media are transported using RTP/UDP, and RTCP may be used to feed reception statistics back to the server.

Let us see in depth details of these internet protocols in future articles.