| RTP Control Protocol | |
| Is Stack: | No |
| Abbreviation: | RTCP |
| Purpose: | Provide feedback on the quality of service |
| Developer: | Columbia University |
RTP Control Protocol should not be confused with Real Time Streaming Protocol.
The RTP Control Protocol (RTCP) is a binary-encoded out-of-band signaling protocol that functions alongside the Real-time Transport Protocol (RTP). Its basic functionality and packet structure is defined in RFC 3550. RTCP provides statistics and control information for an RTP session. It partners with RTP in the delivery and packaging of multimedia data but does not transport any media data itself.
The primary function of RTCP is to provide feedback on the quality of service (QoS) in media distribution by periodically sending statistics information such as transmitted octet and packet counts, packet loss, packet delay variation, and round-trip delay time to participants in a streaming multimedia session. An application may use this information to control quality of service parameters, perhaps by limiting flow, or using a different codec.
Typically RTP will be sent on an even-numbered UDP port, with RTCP messages being sent over the next higher odd-numbered port.[1]
RTCP itself does not provide any flow encryption or authentication methods. Such mechanisms may be implemented, for example, with the Secure Real-time Transport Protocol (SRTP) defined in RFC 3711.
RTCP provides basic functions expected to be implemented in all RTP sessions:
RTCP reports are expected to be sent by all participants, even in a multicast session which may involve thousands of recipients. Such traffic will increase proportionally with the number of participants. Thus, to avoid network congestion, the protocol must include session bandwidth management. This is achieved by dynamically controlling the frequency of report transmissions. RTCP bandwidth usage should generally not exceed 5% of the total session bandwidth. Furthermore, 25% of the RTCP bandwidth should be reserved to media sources at all times, so that in large conferences new participants can receive the CNAME identifiers of the senders without excessive delay.
The RTCP reporting interval is randomized to prevent unintended synchronization of reporting. The recommended minimum RTCP report interval per station is 5 seconds. Stations should not transmit RTCP reports more often than once every 5 seconds.
| 1 | 2 | 3 | |||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octet | Bit | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | Version | P | RC | PT | length | ||||||||||||||||||||||||||||
| 32 | SSRC identifier | ||||||||||||||||||||||||||||||||
Note that multiple reports can be concatenated into a single compound RTCP packet, each with its own packet header.
RTCP distinguishes several types of packets: sender report, receiver report, source description, and goodbye. In addition, the protocol is extensible and allows application-specific RTCP packets. A standards-based extension of RTCP is the extended report packet type introduced by RFC 3611.[2]
In large-scale applications, such as in Internet Protocol television (IPTV), very long delays (minutes to hours) between RTCP reports may occur, because of the RTCP bandwidth control mechanism required to control congestion (see Protocol functions). Acceptable frequencies are usually less than one per minute. This affords the potential of inappropriate reporting of the relevant statistics by the receiver or causes evaluation by the media sender to be inaccurate relative to the current state of the session. Methods have been introduced to alleviate the problems:[4] RTCP filtering, RTCP biasing and hierarchical aggregation.[5]
The Hierarchical Aggregation (or also known as RTCP feedback hierarchy) is an optimization of the RTCP feedback model and its aim is to shift the maximum number of users limit further together with quality of service (QoS) measurement. The RTCP bandwidth is constant and takes just 5% of session bandwidth. Therefore, the reporting interval about QoS depends, among others, on a number of session members and for very large sessions it can become very high (minutes or even hours).[3] However, the acceptable interval is about 10 seconds of reporting. Bigger values would cause time-shifted and very inaccurate reported status about the current session status and any optimization made by the sender could even have a negative effect on network or QoS conditions.
The Hierarchical Aggregation is used with Source-Specific Multicast where only a single source is allowed, i.e. IPTV. Another type of multicast could be Any-Source Multicast but it is not so suitable for large-scale applications with huge number of users.
, only the most modern IPTV systems use Hierarchical aggregation.
Feedback Target is a new type of member that has been firstly introduced by the Internet Draft draft-ietf-avt-rtcpssm-13. The Hierarchical Aggregation method has extended its functionality. The function of this member is to receive Receiver Reports (RR) (see RTCP) and retransmit summarized RR packets, so-called Receiver Summary Information (RSI) to a sender (in case of single-level hierarchy).