Guidelines for End-to-End Support of the RTP Control Protocol (RTCP) in Back-to-Back User Agents (B2BUAs)
Extracted elements (22)
Media Terminator B2BUAs require no specific RTCP forwarding guidelines because they terminate RTP/RTCP themselves and handle statistics and feedback directly. End-to-end RTCP interaction between participants does not exist in such topologies; the B2BUA is the RTCP endpoint on each side.
When a B2BUA rewrites SSRC values in RTP streams, blindly relaying RTCP messages without updating the referenced SSRCs causes recipients to receive feedback referencing unknown SSRCs, which they discard. This breaks congestion control, NACK retransmission, and other feedback mechanisms, potentially degrading or terminating the session.
RTP/RTCP multiplexing (RFC 5761) and Reduced-Size RTCP (RFC 5506) may be used independently on each side of a Media Relay or Media Terminator B2BUA, allowing the B2BUA to use the feature on the side that supports it. However, increased RTCP Feedback rates from Reduced-Size may be counterproductive when the non-supporting side has limited bandwidth.
The REMB feedback message (draft-alvestrand-rmcat-remb) had been widely deployed but not standardized at publication time. A media-aware B2BUA that changes the SSRC of the media sender must also update the SSRC values in REMB packets, or the REMB bandwidth estimation mechanism will not function correctly across the B2BUA.
A B2BUA MAY rewrite CNAME items if any potential SSRC collision is detected. If it does rewrite CNAMEs, it MUST generate new CNAMEs following RFC 7022. If RTP extensions involving CNAMEs are used and the B2BUA cannot support them, it MUST reject negotiation of such extensions.
A B2BUA SHOULD NOT randomly drop or forward RTCP feedback of the same type within the context of the same session, as gaps in feedback can cause confusing or broken behavior for recipients.
A media-aware B2BUA MUST update SSRCs in SDES chunks, BYE packets, APP packets, and XR messages if it changed the SSRC of any addressed RTP stream. For XR messages, 'begin_seq' and 'end_seq' fields MUST also be updated if the base RTP sequence number was changed.
A media-aware B2BUA MUST update the SSRC in SR/RR packet headers and all Report Blocks if it changed the SSRC of any referenced RTP stream. If it changed the base RTP sequence number, that change MUST be reflected in the 'extended highest sequence number received' field in Report Blocks.
A Media Relay B2BUA SHOULD forward all SSRC- and RTCP-related SDP attributes (such as 'ssrc', 'rtcp-fb', 'rtcp-xr-attrib') when handling a multimedia session setup, except for attributes that implicitly describe the immediate peer (such as the 'rtcp' port attribute), which MUST be rewritten.
A Media Relay B2BUA that is unable to parse RTP/RTCP SHOULD reject RTP/RTCP multiplexing by removing the 'rtcp-mux' SDP attribute. If it can parse RTP/RTCP and verify no Payload Type overlap with RTCP space exists, it SHOULD negotiate RTP/RTCP multiplexing if advertised.
For a Media Terminator B2BUA, it SHOULD advertise and negotiate Reduced-Size RTCP support on each side independently if available, and MUST NOT otherwise, since the B2BUA terminates RTCP and the two sides are decoupled.
For Feedback messages, a media-aware B2BUA MUST update the Packet Sender SSRC and media source SSRC if changed, but MUST NOT change a media source SSRC that was originally set to zero (unless zero is actually an endpoint's chosen SSRC). For NACK, it MUST rewrite Packet IDs if sequence numbers were changed.
For RSI (RFC 5760) and TOKEN/Port Mapping (RFC 6284) packets, a media-aware B2BUA MUST update all SSRC identifiers in the message, including the distribution source SSRC and Packet Sender SSRC, rewriting them with the SSRC the B2BUA uses when sending RTP to each participant.
For TMMBR/TMMBN/FIR/TSTR/TSTN/VBCM feedback messages (RFC 5104), a media-aware B2BUA MUST rewrite the additional SSRC identifier in the specific FCI if it changed the related RTP SSRC of the media sender.
If a compound RTCP packet is received and any individual RTCP message within it needs to be dropped, the B2BUA SHOULD NOT drop the whole compound RTCP packet but only the selected messages.
If a media-aware B2BUA changes any SSRC, it MUST update the related 'ssrc' SDP attributes before sending to the recipient, and MUST rewrite the 'rtcp' SDP attribute if provided. It MUST advertise its RTCP support level coherently in SDP to prevent sending unsupported feedback types.
If a media-aware B2BUA decides to disable Reduced-Size RTCP on all sides (suggested when not all parties support it), it MUST NOT advertise support for Reduced-Size RTCP on either side, removing the 'rtcp-rsize' SDP attribute.
When a media-aware B2BUA involves RTP/RTCP multiplexing, it MUST ensure there are no conflicting RTP Payload Type numbers. When conflicts exist, it MUST rewrite RTP Payload Type numbers, and the related SDP information MUST be updated accordingly.
B2BUAs on the media path are classified into three categories: (1) Media Relay, which forwards RTP/RTCP without inspection or modification; (2) Media-aware Relay, which inspects and/or modifies RTP/RTCP headers; and (3) Media Terminator, which fully terminates and regenerates RTP/RTCP.
A Media Relay passing RTCP messages untouched may leak internal topology information such as domain names or IP addresses embedded in CNAME items. If a NAT is involved, unmodified CNAME values containing internal IP addresses may cause CNAME collisions that break end-to-end RTCP behavior.
Improper management of RTCP Feedback messages (e.g., REMB) can produce attack-like effects: a B2BUA that drops or corrupts bandwidth availability feedback may cause the sender to flood a bandwidth-constrained receiver with data it cannot process, resulting in a de facto Denial-of-Service condition.
When SRTP/SRTCP is in use and the B2BUA lacks access to the session keys, it cannot modify packet headers without violating the SRTP authentication tag. Only the Media Relay scenario can be properly addressed with SRTP; Media-aware Relay and Media Terminator scenarios require the B2BUA to act as a man-in-the-middle, which is unspecified and discouraged.