RTCP Report Interval — VoIP Quality Metric
Time between RTCP SR/RR reports in ms — deviations from the RFC 3550 5-second default reveal path issues that degrade VoIP quality feedback loops.
RTCP Report Interval
| Property | Value |
|---|---|
| Key | rtcp_sr_rr_interval_ms |
| Unit | ms |
| Type | Gauge |
| Direction | Both |
| RFC | RFC 3550 Section 6.2 (RTCP Transmission Interval) |
What It Measures
RTCP Report Interval measures the time between consecutive RTCP Sender Report (SR) or Receiver Report (RR) packets. Under RFC 3550, the default RTCP interval is approximately 5,000ms (5 seconds), dynamically adjusted based on session participant count and RTCP bandwidth allocation.
Deviations from the expected interval — whether too long, too short, or irregular — indicate that the RTCP control path is experiencing issues distinct from the RTP media path. RTCP and RTP share the same network path, but RTCP can be dropped or delayed while RTP continues flowing, masking quality feedback that the sender depends on for adaptive control.
Why It Matters
RTCP is the feedback channel that keeps a VoIP call self-aware. Without timely RTCP reports, the sender is flying blind:
- Loss feedback stops. The sender cannot detect packet loss and cannot trigger codec adaptation or retransmission.
- Jitter reports stop. Adaptive codecs like Opus use RTCP jitter reports to adjust bitrate and packet size.
- Round-trip time estimation fails. RTT calculation depends on the SR/RR timestamp exchange. Without RTCP, RTT-dependent features (echo cancellation tuning, jitter buffer sizing) degrade.
- RTCP-XR reports stop. Extended reports — burst density, gap density, MOS estimates — are only delivered via RTCP. Silent RTCP intervals mean no RTCP-XR data.
For SBC and SIP proxy testing, RTCP interval is a diagnostic metric that reveals whether RTCP is being blocked or rate-limited by an intermediate device. Many firewalls handle RTP and RTCP differently. A firewall that passes RTP but silently drops RTCP causes call quality to degrade gradually as adaptive mechanisms lose their feedback source.
An irregular RTCP interval — where some reports arrive on time but others are delayed by seconds — is often the first observable symptom of a network path that is about to fail.
Thresholds
| Level | Value | Meaning |
|---|---|---|
| Good | 4,000ms – 6,000ms | Normal RFC 3550 interval |
| Warning | 2,000ms – 4,000ms or 6,000ms – 15,000ms | Interval deviation, check RTCP path |
| Critical | Below 2,000ms or above 15,000ms | Significant deviation, RTCP path likely impaired |
How to Fix It
- Verify RTCP is not blocked. RTCP uses the port directly above the RTP port (by convention). Confirm firewall rules permit both RTP port and RTP+1 for the full duration of the call.
- Check SBC RTCP pass-through settings. Some SBCs terminate RTCP locally and do not relay it end-to-end. In this case, the measured interval reflects SBC behavior, not end-to-end delivery.
- Review RTCP bandwidth allocation. If RTCP is configured at an unusually low bandwidth fraction (below 5% of RTP bandwidth), the computed interval will be much longer than 5 seconds.
- Look for NAT keepalive interference. Some NAT traversal implementations send RTCP keepalives that can distort interval measurements.
- Correlate with quality metrics. If RTCP interval spikes coincide with MOS drops or jitter increases, the adaptive control loop has lost its feedback and cannot compensate — fix the RTCP path before tuning the media path.
Related Metrics
- Round Trip Time — Calculated from RTCP SR/RR timestamp exchange; inaccurate when RTCP interval is irregular
- Packet Loss Rate — Reported via RTCP Receiver Reports; stale when interval is too long
- Jitter — Reported via RTCP; adaptive codecs lose feedback when RTCP is delayed
- Burst Density — Delivered via RTCP-XR; requires RTCP path to function