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:
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. The feedback may be directly useful for control
of adaptive encodings [8,9], but experiments with IP
multicasting have shown that it is also critical to get
feedback from the receivers to diagnose faults in the
distribution. Sending reception feedback reports to all
participants allows one who is observing problems to
evaluate whether those problems are local or global. With a
distribution mechanism like IP multicast, it is also
possible for an entity such as a network service provider
who is not otherwise involved in the session to receive the
feedback information and act as a third-party monitor to
diagnose network problems. This feedback function is
performed by the RTCP sender and receiver reports,
described below in Section 6.3.
RTCP carries a persistent transport-level identifier for an
RTP source called the canonical name or CNAME, Section
6.4.1. 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. Receivers also
require the CNAME to associate multiple data streams from a
given participant in a set of related RTP sessions, for
example to synchronize audio and video.
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, as
explained in Section 6.2.
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. RTCP serves as a convenient channel
to reach all the participants, but it is not necessarily
expected to support all the control communication
requirements of an application. A higher-level session
control protocol, which is beyond the scope of this
document, may be needed.
Functions 1-3 are mandatory when RTP is used in the IP multicast
environment, and are recommended for all environments. RTP
application designers are advised to avoid mechanisms that can only
work in unicast mode and will not scale to larger numbers.