6. RTP Control Protocol -- RTCP

The RTP control protocol (RTCP) is based on the periodic transmission of control packets to all participants in the session, using the same distribution mechanism as the data packets. The underlying protocol MUST provide multiplexing of the data and control packets, for example using separate port numbers with UDP.

RTCP performs four functions:

1. The primary function is to provide feedback on the quality of the data distribution. This is an integral part of the RTP's role as a transport protocol and is related to the flow and congestion control functions of other transport protocols.

2. RTCP carries a persistent transport-level identifier for an RTP source called the canonical name or CNAME. Since the SSRC identifier may change if a conflict is discovered or a program is restarted, receivers require the CNAME to keep track of each participant.

3. The first two functions require that all participants send RTCP packets, therefore the rate must be controlled in order for RTP to scale up to a large number of participants. By having each participant send its control packets to all the others, each can independently observe the number of participants. This number is used to calculate the rate at which the packets are sent.

4. A fourth, OPTIONAL function is to convey minimal session control information, for example participant identification to be displayed in the user interface. This is most likely to be useful in "loosely controlled" sessions where participants enter and leave without membership control or parameter negotiation.

Functions 1-3 SHOULD be used in all environments, but particularly in the IP multicast environment. RTP application designers SHOULD avoid mechanisms that can only work in unicast mode and will not scale to larger numbers.

6.1 RTCP Packet Format

This specification defines several RTCP packet types to carry a variety of control information:

• SR (Sender Report): for transmission and reception statistics from participants that are active senders
• RR (Receiver Report): for reception statistics from participants that are not active senders
• SDES (Source Description): for items including CNAME
• BYE: indicates end of participation
• APP: application-specific functions

Each RTCP packet begins with a fixed part similar to that of RTP data packets, followed by structured elements that may be of variable length according to the packet type but always end on a 32-bit boundary.

6.2 RTCP Transmission Interval

RTP is designed to allow an application to scale automatically over session sizes ranging from a few participants to thousands. The RTP session bandwidth is divided between the data and control portions, with RTCP typically allocated 5% of the session bandwidth.

6.3 RTCP Packet Send and Receive Rules

The rules for how to send and receive RTCP packets are carefully designed to achieve proper operation for sessions of all sizes.

6.4 Sender and Receiver Reports

RTP receivers provide reception quality feedback using RTCP report packets which may take one of two forms depending upon whether or not the receiver is also a sender.

6.5 SDES: Source Description RTCP Packet

The SDES packet is a three-level structure composed of a header and zero or more chunks, each of which is composed of items describing the source identified in that chunk.

6.6 BYE: Goodbye RTCP Packet

The BYE packet indicates that one or more sources are no longer active.

6.7 APP: Application-Defined RTCP Packet

The APP packet is intended for experimental use as new applications and new features are developed.

---