Purpose of RTCP Sender and Receiver Reports in WebRTC

This article explains the operational purposes of Real-Time Control Protocol (RTCP) Sender Reports (SR) and Receiver Reports (RR) within WebRTC applications. It covers how these control packets function to synchronize media streams, monitor network quality of service (QoS), calculate round-trip time (RTT), and facilitate congestion control to ensure smooth real-time communication.

In WebRTC, while the Real-time Transport Protocol (RTP) carries the actual audio and video data, its companion protocol, RTCP, manages the delivery quality and synchronization of these streams. The two most critical RTCP packet types used for this purpose are Sender Reports (SR) and Receiver Reports (RR).

RTCP Sender Reports (SR)

Sender Reports are generated and transmitted by active senders in a WebRTC session. Their primary operational purposes include:

• Media Synchronization (Lip-Sync): RTP timestamps are randomized at the start of a stream and tick at different rates for audio and video. An SR contains both an absolute wall-clock time (NTP timestamp) and the corresponding RTP timestamp. By mapping these two timelines together, the receiver can align separate audio and video tracks, preventing synchronization drift (lip-sync issues).
• Transmission Statistics: SRs contain cumulative counters for the total number of packets and bytes (octets) transmitted. This allows the receiver to estimate the sender’s average transmission bitrate and detect if substantial blocks of data are missing before processing.

RTCP Receiver Reports (RR)

Receiver Reports are sent by participants who receive media streams. Their primary operational purposes are:

• Feedback on Reception Quality: RRs provide feedback on the quality of the received stream. They contain critical metrics, including:
  • Fraction Lost: The percentage of packets lost since the last report.
  • Cumulative Number of Packets Lost: The total number of lost packets during the entire session.
  • Interarrival Jitter: An estimate of the statistical variance in packet arrival times, which indicates network congestion.
• Round-Trip Time (RTT) Calculation: RRs contain the “Last SR” (LSR) timestamp (the NTP timestamp from the last received Sender Report) and the “Delay Since Last SR” (DLSR). When the sender receives the RR, it subtracts the LSR and the DLSR from the current time to calculate the exact round-trip network latency between the peers.

Operational Synergy and Congestion Control

Together, SR and RR packets form a continuous feedback loop that WebRTC leverages for dynamic network adaptation.

The sender analyzes the packet loss and jitter reported in the RRs, combined with the calculated RTT. If the receiver reports high packet loss or rising jitter, the WebRTC congestion control algorithm (such as Google Congestion Control) instructs the media engine to lower the bitrate, reduce resolution, or adjust the frame rate. Conversely, if the RRs report zero packet loss and low latency, the sender can safely scale up the media quality to utilize the available bandwidth.