Register now or log in to join your professional community.
The primary function of RTCP is to provide [transmitting hosts] feedback on the quality of the data distribution to receiving hosts. These reports serve to help network operators troubleshoot RTP connectivity/quality issues by determining if problems are local to the receiver, along the transport stream or global.
The designers of RTP chose not to use typical TCP sockets to uniquely identify the transmitter of RTP session. Instead, RTP sessions are identified by a 32 bit number called the SSRC (synchronized source). This allows RTP senders to be flexible in their deployment scenarios (load balanced transmissions, redundancy, collision recovery). But it can also cause problems on the sending and receiving end, so the designers added a layer of identification on top of the SSRC by utilizing the CNAME record of the source. RCTP informs RTP receivers of the CNAME linkage, and RTP transmitters of the CNAMES of RTP clients, as there is no room in the RTP header for this information.
As all RTP recipients send their CNAME information to each other, as RTP sessions grow larger, the rate at which this information exchange happens needs to be controlled (so that 1000 hosts don't send 999 packets to each other every second, for example). As RTP sessions scale up, RCTP is used to communicate an agreed upon interval for sending of CNAME information to the RTP group.
RTCP can also act as a lightweight session manager amongst clients. An example of this might be "presence" in a chatroom or a video conference. The green icon stating that a participant is live on a call/chat could be handled by RTCP, while the actual audio/text data will be transmitted by RTP.
RTCP works hand in hand with RTP. RTP does the delivery of the actual data, where as RTCP is used to send control packets to participants in a call.
