skip to content

In plain RTCP, what do sender and receiver reports carry, and what can a forged RTCP packet do to a call?

level: middleimportance: should knowfreq 14%

answer

  1. statistics, not media
  2. wallclock paired with media clock
  3. loss, jitter, round-trip time
  4. BYE removes a member
  5. why SRTCP integrity is not optional

basics

~20 s

Sender reports carry an NTP and RTP timestamp pair plus packet and octet counts; both report types carry loss, jitter and round-trip fields. Forged RTCP can remove a participant (BYE), fake loss that drives adaptation, or break synchronisation.

solid answer

~40 s

RTCP (RFC 3550 §6) is RTP's control channel. A sender report (`PT=200`) carries a 20-byte sender-info block — an NTP-format wallclock timestamp, the matching RTP timestamp, and packet and octet counts — plus reception report blocks; a receiver report (`PT=201`) carries only the blocks: fraction lost, cumulative lost, extended highest sequence number, interarrival jitter, and `LSR`/`DLSR` for round-trip time. SDES carries the CNAME, BYE (`PT=203`) says a source is leaving. In plain RTCP none of this is authenticated, so a forger who knows an SSRC can send a BYE that makes receivers drop that source's state, receiver reports claiming heavy loss to a sender that adapts its encoding, or a sender report with a wrong timestamp pairing that breaks lip-sync. That is why RFC 3711 makes integrity mandatory for SRTCP.

go deeper

for a junior

Recall that RTCP is RTP's control channel: sender and receiver reports for quality, SDES for the CNAME, BYE for leaving.

for a middle

Explain the report contents — the NTP/RTP timestamp pair, loss, jitter, LSR and DLSR — and how each forged RTCP type harms a call without touching media.

for a senior

Check that RTCP is protected whenever media is, and read RTCP statistics critically when the channel is unauthenticated.

for a principal

Weigh exposing RTCP statistics to third-party monitors against keeping them confidential, knowing RFC 3711 makes SRTCP integrity non-negotiable.

## What RTCP is for RTP carries media; its companion **RTCP** (RFC 3550 §6) carries control. Each participant periodically sends RTCP packets — by default to the next odd port after RTP, or on the same port when both sides negotiate rtcp-mux (RFC 5761, which updates RFC 3550). RTCP's jobs are quality feedback, a persistent identifier for each source, synchronisation, and session membership. A compound RTCP packet MUST begin with an SR or an RR. ## The packet types | Type | `PT` | Carries | |---|---|---| | SR — sender report | 200 | Sender info plus reception report blocks | | RR — receiver report | 201 | Reception report blocks only | | SDES — source description | 202 | CNAME (required), optional NAME, EMAIL, PHONE and others | | BYE — goodbye | 203 | SSRC/CSRC identifiers leaving, optional reason text | | APP — application-defined | 204 | Experimental, application-specific data | An SR is sent by a participant that has sent data since its last report; otherwise it sends an RR. RFC 3550 recommends that RTCP add 5% to the session bandwidth, with a recommended fixed minimum interval of 5 seconds between reports, so on a two-party call each side reports roughly every five seconds, not per packet. ## Inside the reports The **sender info** block of an SR is 20 octets: - **NTP timestamp** (64 bits) — wallclock time when the report was sent; - **RTP timestamp** — the same instant in the stream's media clock; - **sender's packet count** and **sender's octet count**. Each **reception report block** (up to 31 per packet) describes one source heard: - **fraction lost** and **cumulative number of packets lost** (which can go negative when duplicates arrive); - **extended highest sequence number received**; - **interarrival jitter**; - **LSR** (last SR timestamp) and **DLSR** (delay since last SR). The sender computes round-trip time as arrival time `A` minus `LSR` minus `DLSR`. The NTP/RTP timestamp pair is what lets a receiver align audio and video, because RTP timestamps from different streams have random offsets. ## What plain RTCP exposes Plain RTCP has the same weakness as plain RTP: RFC 3550 defines no authentication at the RTP level. Two exposures follow. **Eavesdropping.** The SDES CNAME SHOULD take the form `user@host`, so a passive observer learns user and host names along with loss and jitter statistics for every stream. RFC 3550 §14 also notes that CNAME and NAME "may be used to impersonate another participant". **Forgery.** A forger needs the RTCP destination port and an SSRC from the session, both readable in clear. With them: 1. **Forged BYE.** RFC 3550 §6.3.4 tells the receiver to remove that SSRC from its member and sender tables. How the application then behaves is up to the implementation, but a receiver may stop treating the source as present. 2. **Forged receiver reports.** RFC 3550 notes that reception feedback "may be directly useful for control of adaptive encodings". A sender that lowers its bitrate on reported loss can be talked down by fake loss figures. 3. **Forged sender reports.** A wrong NTP/RTP pairing misleads the receiver's audio/video synchronisation, and false LSR or DLSR values distort round-trip measurements. None of this needs to touch a media packet: the control channel alone degrades the call. ## How SRTP treats RTCP RFC 3711 protects RTCP as **SRTCP**, and its security goals list one exception to "optional and independent": SRTCP integrity protection is mandatory, because "malicious or erroneous alteration of RTCP messages could otherwise disrupt the processing of the RTP stream". SRTCP leaves the first eight octets (RTCP header and sender SSRC) in clear, adds an E flag and an explicit index, and authenticates the whole compound packet; its index and deployment details are their own subject. ## For the operator - Treat unauthenticated RTCP as a control channel anyone on the path can speak on. - When SRTP is configured, confirm RTCP is protected too; a deployment that secures media and leaves RTCP plain keeps every forgery above. - RTCP statistics remain valuable for monitoring, and SRTCP still lets an endpoint read them once it has the keys. - RFC 3550 §9.1 already anticipated the tension: it allowed a compound RTCP packet to be split so SDES is encrypted while reception reports stay clear for third-party monitors.

  • Does an RTCP BYE end the SIP call?
    No. RTCP BYE and SIP BYE are different messages in different protocols. An RTCP BYE (`PT=203`) tells RTP participants that an SSRC is leaving the media session, and receivers drop its state; the SIP dialog is ended only by a SIP BYE on the signalling path. A forged RTCP BYE can still disrupt media handling without the signalling noticing anything.
  • How does a sender turn a receiver report into a round-trip time?
    The report block echoes `LSR` — the middle 32 bits of the NTP timestamp in the last SR the receiver got — and `DLSR`, how long the receiver held it. The sender subtracts both from the arrival time `A`: RTT = A - LSR - DLSR. Forged values give a false RTT.

saying these in an interview costs you the question

  • RTCP only carries statistics, so leaving it unauthenticated is harmless.
  • An RTCP BYE ends the SIP dialog.
  • Only the party that started the call sends sender reports.
  • The RTCP CNAME is a random value with no identifying information.
  • SRTCP authentication is optional, just as it is for SRTP.