Sending Multiple RTP Streams in a Single RTP Session: Grouping RTP Control Protocol (RTCP) Reception Statistics and Other Feedback
Extracted elements (30)
A separate RGRS packet type (rather than relying solely on the RGRP SDES item) allows observers to distinguish a non-reporting source that is legitimately suppressing reports from an SSRC that is not receiving any traffic, and also allows detection of lost reporting source RTCP packets.
The RGRP SDES item is given a stable identifier (rather than derived from SSRCs) to ensure that the Reporting Group and its members can be correctly associated when multiple reporting sources exist, and so that the reporting SSRC can be matched to the correct group after an SSRC collision.
When multiple SSRCs originate from the same endpoint and are co-located, they see identical network conditions (same lost packets, jitter, etc.). This allows a single representative SSRC to send RTCP reception quality reports on behalf of all others, dramatically reducing RTCP overhead without loss of useful information.
Middleboxes cannot use the Reporting Group extension to group RTCP packets from SSRCs they are forwarding; the extension only applies to the middlebox's own SSRCs. Middleboxes MUST forward RGRP SDES items and RGRS packets from Reporting Group members they relay, or compatibility problems arise.
RTCP traffic generated by non-reporting sources using Reporting Groups may appear to observers unaware of these semantics as though those sources are experiencing a network disconnection. A congestion-control sender relying on RTCP might incorrectly infer complete congestion collapse, though this requires fairly sophisticated RTCP analysis.
A reporting source MUST suppress the RTCP SR/RR reports that relate to other members of the Reporting Group and only report on remote SSRCs. Non-reporting sources MUST suppress their reception quality reports entirely.
An endpoint MUST NOT create an RTCP Reporting Group comprising only a single local SSRC (i.e., where the reporting source is the only member), unless it is anticipated that additional SSRCs will be added in the future.
An RTP mixer or translator that forwards RTCP SR or RR packets from Reporting Group members MUST forward the corresponding RTCP RGRS packets. If it rewrites SSRC values, it MUST make corresponding changes to both RGRP SDES items and RGRS packets.
Each member of an RTCP Reporting Group SHOULD send RTP/AVPF feedback and codec control messages independently (using its own SSRC) to preserve the semantic meaning of the message sender. An endpoint MAY consolidate feedback through the reporting source when the sender identity is not semantically significant.
Every non-reporting source in an RTCP Reporting Group MUST include an RTCP RGRS packet in every compound RTCP packet in which it sends an RR or SR (unless Reduced-Size RTCP is in use). Each RGRS packet MUST contain at least one reporting source SSRC.
If a reporting source leaves the RTP session (via RTCP BYE or timeout), the remaining group members MUST either have another existing reporting source take over, choose a new reporting source, or disband the Reporting Group and resume per-RFC-3550 reporting.
If multiple SSRCs act as reporting sources for a Reporting Group, each reporting source MUST have non-overlapping sets of remote SSRCs it reports on, to avoid duplicating report blocks.
If there are more reporting sources than can fit in a single RTCP RGRS packet, group members MUST send the reporting source SSRCs in round-robin fashion across consecutive RTCP RGRS packets so that all reporting source SSRCs are included over several reporting intervals.
In SDP Offer/Answer: an offerer that supports RTCP Reporting Groups MUST include 'a=rtcp-rgrp' in the initial offer. If the SDP answer contains 'a=rtcp-rgrp' but the offer did not, the offerer MUST reject the call.
SSRCs with different views of the network MUST NOT be put into the same Reporting Group. An endpoint MAY put co-located SSRCs that see identical network conditions into a Reporting Group.
The RTCP RGRP SDES item MUST be sent by reporting sources in every compound RTCP packet in which they send an RR or SR (unless Reduced-Size RTCP is in use), and MUST NOT be sent by non-reporting members or SSRCs outside any Reporting Group.
The value of the RTCP RGRP SDES item MUST be stable throughout the lifetime of the Reporting Group, even if reporting sources change their SSRC due to collisions or the set of reporting sources changes.
When RTCP XR is used, media-specific XR report blocks that are relevant to only certain media types (e.g., VoIP metrics for audio SSRCs) MUST be sent by the SSRC to which they are relevant and MUST NOT be included in the common report sent by the reporting source.
When RTP/AVPF feedback or codec control messages are sent as compound RTCP packets by Reporting Group members, those compound packets MUST include either an RTCP RGRS packet (for non-reporting sources) or an RTCP RGRP SDES item (for reporting sources).
The Reporting Group Identifier (RGRP SDES item value) could enable endpoint tracking if generated in a long-term stable or predictable manner. It is RECOMMENDED to generate it as a short-term persistent identifier following the rules for short-term persistent CNAMEs in RFC 7022.
An RTCP Reporting Group is a set of co-located SSRCs at a single endpoint in an RTP session. One or more SSRCs act as 'reporting sources' and send RTCP SR/RR packets on behalf of the group; the other members suppress their reception quality reports and send RTCP RGRS packets instead.
The 'a=rtcp-rgrp' SDP attribute is a property attribute (no value) used at session or media level to indicate that the participant supports and is willing to receive RTCP Reporting Group extensions. Its multiplexing category is IDENTICAL, meaning it applies at the RTP session level.
The RTCP RGRP SDES item (type value 11) is sent exclusively by reporting sources to identify which Reporting Group they belong to. Its format is identical to the CNAME SDES item but with SDES item type RGRP=11. Its value must be globally unique and stable for the lifetime of the Reporting Group.
IANA registered RTCP packet type value 212 with abbreviation 'RGRS' and name 'Reporting Group Reporting Sources' in the 'RTCP Control Packet Types (PT)' registry, as defined in Section 3.2.2.
IANA registered RTCP SDES item type value 11 with abbreviation 'RGRP' and name 'Reporting Group Identifier' in the 'RTP SDES Item Types' registry, as defined in Section 3.2.1.
IANA registered the SDP attribute 'rtcp-rgrp' (att-field) for use at media or session level, with no value, mux category IDENTICAL, for negotiating or configuring the use of the RTCP Reporting Group extension, as defined in Section 3.6.
The RGRS packet fields are vulnerable to modification: the SC or P fields cause invalid packet classification, modification of the PT field causes misinterpretation, modifying the 'SSRC of packet sender' field could enable resource exhaustion attacks by creating phantom Reporting Group associations.
The RTCP RGRP SDES item is vulnerable to malicious modification. Modifying its length field causes RTCP packet parsing to fail; modifying its value causes the receiver to associate the sender with an incorrect Reporting Group, potentially creating inconsistencies that could trigger bitrate reductions in congestion-controlled sessions.
To protect against attacks from external entities, integrity and source authentication SHOULD be applied to RTCP Reporting Group packets, for example using SRTP with appropriate key management.
The RTCP RGRS packet (PT=212) contains: a 2-bit version (V=2), 1-bit padding (P), 5-bit source count (SC), 8-bit payload type (PT=212), 16-bit length, 32-bit SSRC of packet sender, and a variable-length list of 32-bit SSRCs identifying the reporting sources. The length field is always 2 or greater since at least one reporting source SSRC must be present.