Multimedia Networking

7.4.2 RTP Control Protocol (RTCP)

Home
Introduction
7.1 Multimedia Networking Applications
7.1.1 Examples of Multimedia Applications
7.1.2 Hurdles for Multimedia in Today's Internet
7.1.3 How Should the Internet Evolve to Support Multimedia Better?
7.1.4 Audio and Video Compression
7.2 Streamimg Stored Audio and Video
7.2.1 Accessing Audio and Video Through a Web Server
7.2.2 Sending Multimedia from a Streaming Server to a Helper Application
7.2.3 Real-Time Streaming Protocol (RTSP)
7.3 Making the Best of the Best-Effort Service: An Internet Phone Example
7.3.1 The Limitations of a Best-Effort Service
7.3.2 Removing Jitter at the Receiver for Audio
7.3.3 Recovering from Packet Loss
7.4 Protocols for Real-Time Interactive Applications
7.4.1 RTP
7.4.2 RTP Control Protocol (RTCP)
7.4.3 SIP
7.4.4 H.323
7.5 Distributing Multimedia: Content Distribution Networks
7.6 Beyond Best Effort
7.6.1 Scenario 1: A 1 Mbps Audio Application and an FTP
7.6.2 Scenario 2: A 1 Mbps Audio Application and a High-Priority FTP Transfer
7.6.3 Scenario 3: A Misbehaving Audio Application and an FTP Transfer
7.6.4 Scenario 4: Two 1 Mbps Audio Applications over an Overload 1.5 Mbps Link
7.7 Scheduling and Policing Mechanisms
7.7.1 Scheduling Mechanisms
7.7.2 Policing: The Leaky Bucket
7.8 Intergrated Services and Differentiated Services
7.8.1 Intserv
7.8.2 Diffserv
7.9 RSVP
7.9.1 The Essence of RSVP
7.9.2 A Few Simple Examples
RTP Control Protocol (RTCP)

RFC 1889 also specifies RTCP, a protocol that a networked multimedia application can use in conjunction with RTP.  RTCP packets are transmitted by each participant in an RTP session to all other participants in the session using IP multicast.  There is aq single multicast address and all RTP and RTCP packets belonging to the session use the multicast address.  RTP and RTCP packets are distinguished from each other through the use of distinct port numbers.

kurose_320719_c07f11.gif

RTCP packets do not encapsulate chunks of audi or video.  Instead, RTCP packets are sent peridoically and contain sender and/or receiver reports that announce statistics that can be useful to the application.  These statistics include number of packets sent, number of packets lost, and interarrival jutter.  The RTP does not dictate what the application should do with this feedback information; this is up to the application developer.
 
RTCP Packet Types
For each RTP stream that a receiver receives as part of a session, the receiver generates a reception report.  The receiver aggregates its reception reports into a single RTCP packet.  The packet is then sent into the multicast tree that connects all the session's participants.  The reception reports includes several fields, the most important of which are listed below.
  • The SSRC of the RTP stream for which the reception report is being generated.
  • The fraction of packets lost within the RTP stream. THe last sequence number received in the stream of RTP packets.
  • The interarrival jitter, which is a smoothed estimate of the variation in the interarrival time between successive packets in the RTP stream.
For each RTP stream that a sender is transmitting, the sender creates and transmitts RTCP sender report packets.  These packets include information about the RTP stream, including:
  • The SSRC of the RTP stream
  • The timestamp and wall clock time of the most recently generated RTP packet in the stream.
  • The number of packets sent in the stream.
  • The number of bytes sent in the stream.
RTCP Bandwidth Scaling
The number amount of RTP traffic sent into the multicast tree does not change as the number of receivers increases, whereas the amount of RTCP traffic grows linearly with the number of receivers.  To solve this scaling problem.  RTCP modifies the rate at which a participane sends RTCP packets into the multicast tree as a function of the number of participants in the session.  Since each participant sends control packets to everyone else, each participant can setimate the total number of participants in teh session.  RTCP attempts to limit its traffic to 5 percent of the session bandwidth.