RTCP is a protocol that only deals with answers, syncing data, and the user interface but does not carry data at all, and is closely related to RTP.
RTP delivers the actual data, while RTCP is used to send control packets to participants in a call. The primary function is to provide reports on the quality of the services provided by RTP.
The first feature provides feedback to sources about delays, bandwidth, congestion, and other network properties.
The information provided by this service can be used by the encoding process to increase data rate (and to increase quality) when the network works very well, or to reduce it when there are network problems. By receiving continuous responses, coding algorithms can always be adapted to provide the best possible quality within the current network performance.
Example: If bandwidth increases (or decreases) during transmission, MP3 coding, 8-bit PCM or Delta encoding can be used. The “load type” field is used to indicate to the destination machine which encoding algorithm has been used for the current packet (that is why encoding may change during transmission).
One issue of the feedback mechanism is that the reports are sent to all participants in the communication. For a multicast application with a large number of computers, the bandwidth used by RTCP increases strongly. In order to prevent the reporting bandwidth being filled with reports, they are shrunk, somewhat below 10% of the media bandwidth.
Each participant needs to know the bandwidth size, which he can calculate with the transmitter and the number of participants, which he can determine by listening to the RTCP ports.
RTCP also deals with stream synchronization.
Different streams can use different tact sources (different clocks) with different granularities and derivations. RTCP can synchronize them, despite these impediments.
Several types of packages are specified to carry various control information:
1.SR (Sender Report): contains transmission and reception statistics by actively emitting participants.
2.RR (Receiver Report): Contains statistics from non-active participants.
3.SDES: Describes source objects, including CNAME.
4.BY: indicates the end of a car’s participation.
5.APP: for application-specific functions.
Each RTCP packet begins with a fixed section, similar to the RTP data packets.
There are structured elements, which can have a variable length, a function of the package type, but must be limited to a 32-bit boundary.
This alignment requirement and the “Length” field on the fixed side of the package are required to be able to “stack” the packages.
Several RTCP packages can be concatenated, without the need for separators, to form a compound package that can be sent into a single lower protocol packet (like UDP).
Do not count the individual RTCP packets in the compound package for the lower level protocols to account for the total length, and they determine the end of the compound packet.
Each individual package in the compound package can be processed independently without requiring a particular order.
An RTP participant must send only one RTCP compound packet over the reporting interval, so the band estimates for each participant are correct.