Description
The RTP Control Protocol (RTCP) is defined alongside RTP in IETF RFC 3550 and is profiled for use within 3GPP multimedia services. While RTP carries the actual media payload, RTCP operates on a separate port (typically the RTP port + 1) to periodically transmit control packets to all participants in a session. Its primary functions are QoS monitoring, media synchronization, and session membership management. RTCP packets do not carry media; instead, they carry sender reports (SR), receiver reports (RR), source description (SDES) items, and application-defined packets.
Sender Reports (SR) are generated by active senders and contain crucial information: an NTP timestamp indicating wall-clock time, an RTP timestamp corresponding to the same instant, and the sender's packet and byte counts. This allows receivers to synchronize the playback of different media streams (e.g., audio to video for lip-sync) and to compute the round-trip propagation delay. Receiver Reports (RR) are generated by non-sending participants and provide feedback to the senders about the quality of reception. An RR contains data such as the fraction of packets lost, cumulative number of packets lost, highest sequence number received, and interarrival jitter. This feedback is vital for the sender, or a middlebox, to potentially adapt transmission rates or codec parameters.
Source Description (SDES) packets convey participant identifiers and other descriptive information. The canonical name (CNAME) item is mandatory, providing a persistent, globally unique identifier for a source across multiple RTP sessions, which is necessary for synchronizing related streams (like separate audio and video channels from the same source). Other optional items can include the user's name, email, phone number, or application-specific data. RTCP also defines BYE packets to indicate a participant is leaving a session. The protocol is designed to scale by controlling the rate at which RTCP packets are sent; the total control traffic is limited to a small percentage (typically 5%) of the total session bandwidth.
In the 3GPP ecosystem, particularly for IMS-based services like VoLTE, RTCP plays a critical role in service quality monitoring and diagnostics. The feedback in RR packets about packet loss and jitter provides real-time metrics on the performance of the LTE or 5G radio bearer and the core network path. Network operators can monitor this data for troubleshooting and ensuring QoS compliance. Furthermore, RTCP is used in conjunction with the IMS Media Resource Function (MRF) for features like conferencing, where the MRF can mix RTCP reports. While RTCP provides valuable feedback, 3GPP also defines other mechanisms for more detailed QoS measurement and policy control, but RTCP remains the primary end-to-end, in-band monitoring tool for the media session itself.
Purpose & Motivation
RTCP was created to solve the problems inherent in managing a real-time multimedia session where participants have no direct visibility into the network's performance or the state of other participants. RTP alone delivers the media but offers no mechanism for senders to know if their packets are being received successfully, or for receivers to synchronize multiple related streams (like separate audio and video from one source). Without RTCP, applications would be "deaf" to network conditions and would struggle with synchronization issues.
Its purpose is threefold: 1) **QoS Monitoring and Feedback**: To provide senders and receivers with quantitative data on packet loss, jitter, and round-trip time. This allows for adaptive applications (e.g., switching to a lower bitrate codec during congestion) and provides network operators with valuable diagnostic information. 2) **Inter-media Synchronization**: To provide the necessary timing correlation (via NTP and RTP timestamps in SR packets) to synchronize the playback of separately encoded audio and video streams, ensuring lip-sync accuracy. 3) **Session Management**: To convey participant identity (via CNAME) and notify of membership changes (joining/leaving via BYE packets), which is essential for multi-party sessions and user interfaces.
In the context of 3GPP's transition to all-IP voice and video, RTCP became a critical component for service assurance. For VoLTE and ViLTE, maintaining high voice/video quality is paramount. RTCP feedback allows both the UE and the network to monitor the call quality in real-time. This data can be used by network management systems for proactive fault detection and by the IMS for potential session re-negotiation. While 3GPP defines other QoS measurement tools (like the Gx interface for policy control), RTCP provides a standardized, application-layer, end-to-end view of the media path's health, complementing the network-layer metrics.
Key Features
- Sender Reports (SR) for transmission statistics and timing synchronization
- Receiver Reports (RR) for feedback on packet loss, jitter, and round-trip delay
- Source Description (SDES) packets for participant identification (CNAME)
- BYE packets for graceful session departure notification
- Bandwidth-scalable operation (control traffic limited to ~5% of session BW)
- Provides canonical names (CNAME) for cross-stream synchronization
Evolution Across Releases
Adopted RTCP as an integral part of the media transport framework for Voice over LTE (VoLTE) and IMS-based multimedia services in LTE. Defined the use of RTCP Sender and Receiver Reports for QoS monitoring of the EPS bearer carrying RTP media. Established RTCP's role in providing end-to-end quality metrics for the operator's service assurance.
Defining Specifications
| Specification | Title |
|---|---|
| TS 26.236 | 3GPP TS 26.236 |