diff options
Diffstat (limited to 'doc/rfc/rfc8861.txt')
| -rw-r--r-- | doc/rfc/rfc8861.txt | 856 |
1 files changed, 856 insertions, 0 deletions
diff --git a/doc/rfc/rfc8861.txt b/doc/rfc/rfc8861.txt new file mode 100644 index 0000000..e3c2d61 --- /dev/null +++ b/doc/rfc/rfc8861.txt @@ -0,0 +1,856 @@ + + + + +Internet Engineering Task Force (IETF) J. Lennox +Request for Comments: 8861 8x8 / Jitsi +Category: Standards Track M. Westerlund +ISSN: 2070-1721 Ericsson + Q. Wu + Huawei + C. Perkins + University of Glasgow + January 2021 + + + Sending Multiple RTP Streams in a Single RTP Session: Grouping RTP + Control Protocol (RTCP) Reception Statistics and Other Feedback + +Abstract + + RTP allows multiple RTP streams to be sent in a single session but + requires each Synchronization Source (SSRC) to send RTP Control + Protocol (RTCP) reception quality reports for every other SSRC + visible in the session. This causes the number of RTCP reception + reports to grow with the number of SSRCs, rather than the number of + endpoints. In many cases, most of these RTCP reception reports are + unnecessary, since all SSRCs of an endpoint are normally co-located + and see the same reception quality. This memo defines a Reporting + Group extension to RTCP to reduce the reporting overhead in such + scenarios. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8861. + +Copyright Notice + + Copyright (c) 2021 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Terminology + 3. RTCP Reporting Groups + 3.1. Semantics and Behavior of RTCP Reporting Groups + 3.2. Identifying Members of an RTCP Reporting Group + 3.2.1. Definition and Use of the RTCP RGRP SDES Item + 3.2.2. Definition and Use of the RTCP RGRS Packet + 3.3. Interactions with the RTP/AVPF Feedback Profile + 3.4. Interactions with RTCP Extended Report (XR) Packets + 3.5. Middlebox Considerations + 3.6. SDP Signaling for Reporting Groups + 4. Properties of RTCP Reporting Groups + 4.1. Bandwidth Benefits of RTCP Reporting Groups + 4.2. Compatibility of RTCP Reporting Groups + 5. Security Considerations + 6. IANA Considerations + 7. References + 7.1. Normative References + 7.2. Informative References + Authors' Addresses + +1. Introduction + + The Real-time Transport Protocol (RTP) [RFC3550] is a protocol for + group communication, supporting multiparty multimedia sessions. A + single RTP session can support multiple participants sending data at + once and can also support participants sending multiple simultaneous + RTP streams. Examples of the latter might include a participant with + multiple cameras who chooses to send multiple views of a scene, or a + participant that sends audio and video flows multiplexed in a single + RTP session. Rules for handling RTP sessions containing multiple RTP + streams are described in [RFC3550], with some clarifications in + [RFC8108]. + + An RTP endpoint will have one or more Synchronization Sources + (SSRCs). It will have at least one RTP stream, and thus at least one + SSRC, for each media source it sends, and it might use multiple SSRCs + per media source when using media scalability features [RFC6190], + forward error correction, RTP retransmission [RFC4588], or similar + mechanisms. An endpoint that is not sending any RTP streams will + have at least one SSRC to use for reporting and any feedback + messages. Each SSRC has to send RTP Control Protocol (RTCP) Sender + Reports (SRs) corresponding to the RTP packets it sends and Receiver + Reports (RRs) for traffic it receives. (SRs and RRs are described in + [RFC3550].) That is, every SSRC will send RTCP packets to report on + every other SSRC. This rule is simple, but it can be quite + inefficient for endpoints that send large numbers of RTP streams in a + single RTP session. Consider a session comprising ten participants, + each sending three media sources, each media source associated with + its own RTP stream. There will be 30 SSRCs in such an RTP session, + and each of those 30 SSRCs will send an RTCP SR/RR packet (containing + several report blocks) per reporting interval as each SSRC reports on + all the others. However, the three SSRCs comprising each participant + are commonly co-located such that they see identical reception + quality. If there was a way to indicate that several SSRCs are co- + located and see the same reception quality, then two-thirds of those + RTCP reports could be suppressed. This would allow the remaining + RTCP reports to be sent more often, while keeping within the same + RTCP bandwidth fraction. + + This memo defines such an RTCP extension: RTCP Reporting Groups. + This extension is used to indicate the SSRCs that originate from the + same endpoint and therefore have identical reception quality, hence + allowing the endpoints to suppress unnecessary RTCP reception quality + reports. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. RTCP Reporting Groups + + An RTCP Reporting Group is a set of SSRCs that are co-located at a + single endpoint (which could be an end host or a middlebox) in an RTP + session. Since they are co-located, every SSRC in the RTCP Reporting + Group will have an identical view of the network conditions and will + see the same lost packets, jitter, etc. This allows a single + representative to send RTCP reception quality reports on behalf of + the rest of the Reporting Group, reducing the number of RTCP packets + that need to be sent without loss of information. + +3.1. Semantics and Behavior of RTCP Reporting Groups + + A group of co-located SSRCs that see identical network conditions can + form an RTCP Reporting Group. If Reporting Groups are in use, an RTP + endpoint with multiple SSRCs MAY put those SSRCs into a Reporting + Group if their view of the network is identical, i.e., if they report + on traffic received at the same interface of an RTP endpoint. SSRCs + with different views of the network MUST NOT be put into the same + Reporting Group. + + An endpoint that has combined its SSRCs into an RTCP Reporting Group + will choose one (or a subset) of those SSRCs to act as "reporting + source(s)" for that RTCP Reporting Group. A reporting source will + send RTCP SR/RR reception quality reports on behalf of the other + members of the RTCP Reporting Group. 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. The other members + (non-reporting sources) of the RTCP Reporting Group will suppress + their RTCP reception quality reports and will instead send an RTCP + Reporting Group Reporting Sources (RGRS) packet (see Section 3.2.2) + to indicate that they are part of an RTCP Reporting Group and give + the SSRCs of the reporting sources. + + If there are large numbers of remote SSRCs in the RTP session, then + the reception quality reports generated by the reporting source might + grow too large to fit into a single compound RTCP packet, forcing the + reporting source to use a round-robin policy to determine what remote + SSRCs it includes in each compound RTCP packet, and so reducing the + frequency of reports on each SSRC. To avoid this, in sessions with + large numbers of remote SSRCs, an RTCP Reporting Group MAY use more + than one reporting source. If several SSRCs are acting as reporting + sources for an RTCP Reporting Group, then each reporting source MUST + have non-overlapping sets of remote SSRCs it reports on. + + An endpoint MUST NOT create an RTCP Reporting Group that comprises + only a single local SSRC (i.e., an RTCP Reporting Group where the + reporting source is the only member of the group), unless it is + anticipated that the group might have additional SSRCs added to it in + the future. + + If a reporting source leaves the RTP session (i.e., if it sends an + RTCP BYE packet or it leaves the session without sending a BYE + according to the rules of [RFC3550], Section 6.3.7), the remaining + members of the RTCP Reporting Group MUST (a) have another reporting + source -- if one exists -- report on the remote SSRCs that the + leaving SSRC had reported on, (b) choose a new reporting source, or + (c) disband the RTCP Reporting Group and begin sending reception + quality reports per [RFC3550] and [RFC8108]. + + The RTCP timing rules assign different bandwidth fractions to senders + and receivers. This lets senders transmit RTCP reception quality + reports more often than receivers. If a reporting source in an RTCP + Reporting Group is a receiver but one or more non-reporting SSRCs in + the RTCP Reporting Group are senders, then the endpoint MAY treat the + reporting source as a sender for the purpose of RTCP bandwidth + allocation, increasing its RTCP bandwidth allocation, provided it + also treats one of the senders as if it were a receiver and makes the + corresponding reduction in RTCP bandwidth for that SSRC. However, + the application needs to consider the impact on the frequency of + transmitting of the synchronization information included in RTCP SRs. + +3.2. Identifying Members of an RTCP Reporting Group + + When RTCP Reporting Groups are in use, the other SSRCs in the RTP + session need to be able to identify which SSRCs are members of an + RTCP Reporting Group. Two RTCP extensions are defined to support + this: the RTCP Reporting Group (RGRP) Source Description (SDES) item + is used by the reporting source(s) to identify an RTCP Reporting + Group, and the RTCP RGRS packet is used by other members of an RTCP + Reporting Group to identify the reporting source(s). + +3.2.1. Definition and Use of the RTCP RGRP SDES Item + + This document defines a new RTCP RGRP SDES item to identify an RTCP + Reporting Group. The motivation for giving a Reporting Group an + identifier is to ensure that (1) the RTCP Reporting Group and its + member SSRCs can be correctly associated when there are multiple + reporting sources and (2) a reporting SSRC can be associated with the + correct Reporting Group if an SSRC collision occurs. + + This document defines the RTCP RGRP SDES item. The RTCP RGRP SDES + item MUST be sent by the reporting sources in a Reporting Group and + MUST NOT be sent by other members of the Reporting Group or by SSRCs + that are not members of any RTCP Reporting Group. Specifically, + every reporting source in an RTCP Reporting Group MUST include an + RTCP SDES packet containing an RGRP item in every compound RTCP + packet in which it sends an RR or SR packet (i.e., in every RTCP + packet it sends, unless Reduced-Size RTCP [RFC5506] is in use). + + Syntactically, the format of the RTCP RGRP SDES item is identical to + that of the RTCP SDES CNAME item [RFC7022], except that the SDES item + type field MUST have value RGRP=11 instead of CNAME=1. The value of + the RTCP RGRP SDES item MUST be chosen with the same concerns about + global uniqueness and the same privacy considerations as the RTCP + SDES CNAME. The value of the RTCP RGRP SDES item MUST be stable + throughout the lifetime of the Reporting Group, even if some or all + of the reporting sources change their SSRC due to collisions or if + the set of reporting sources changes. + + An RTP mixer or translator that forwards RTCP SR or RR packets from + members of a Reporting Group MUST forward the corresponding RTCP RGRP + SDES items as well, even if it otherwise strips SDES items other than + the CNAME item. + +3.2.2. Definition and Use of the RTCP RGRS Packet + + A new RTCP packet type is defined to allow the members of an RTCP + Reporting Group to identify the reporting sources for that group. + This allows participants in an RTP session to distinguish an SSRC + that is sending empty RTCP reception reports because it is a member + of an RTCP Reporting Group from an SSRC that is sending empty RTCP + reception reports because it is not receiving any traffic. It also + explicitly identifies the reporting sources, allowing other members + of the RTP session to (1) know which SSRCs are acting as the + reporting sources for an RTCP Reporting Group and (2) detect if RTCP + packets from any of the reporting sources are being lost. + + The format of the RTCP RGRS packet is defined below. It comprises + the fixed RTCP header that indicates the packet type and length, the + SSRC of the packet sender, and a list of reporting sources for the + RTCP Reporting Group of which the packet sender is a member. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |V=2|P| SC | PT=RGRS(212) | length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SSRC of packet sender | + +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ + : List of SSRC(s) for the Reporting Source(s) : + : ... : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The fields in the RTCP RGRS packet have the following definitions: + + version (V): 2-bit unsigned integer. This field identifies the RTP + version. The current RTP version is 2. + + padding (P): 1 bit. If set, the padding bit indicates that the RTCP + packet contains additional padding octets at the end that are not + part of the control information but are included in the length + field. See [RFC3550]. + + Source Count (SC): 5-bit unsigned integer. Indicates the number of + reporting source SSRCs that are included in this RTCP packet. As + the RTCP RGRS packet MUST NOT be sent by reporting sources, all + the SSRCs in the list of reporting sources will be different from + the SSRC of the packet sender. Every RTCP RGRS packet MUST + contain at least one reporting source SSRC. + + Payload type (PT): 8-bit unsigned integer. The RTCP packet type + number that identifies the packet as being an RTCP RGRS packet. + The RGRS RTCP packet has the value 212. + + Length: 16-bit unsigned integer. The length of this packet in + 32-bit words minus one, including the header and any padding. + This is in line with the definition of the length field used in + RTCP SRs and RRs [RFC3550]. Since all RTCP RGRS packets include + at least one reporting source SSRC, the length will always be 2 or + greater. + + SSRC of packet sender: 32 bits. The SSRC of the sender of this + packet. + + List of SSRCs for the Reporting Source(s): A variable number (as + indicated by the SC header field) of 32-bit SSRC values of the + reporting sources for the RTCP Reporting Group of which the packet + sender is a member. + + Every source that belongs to an RTCP Reporting Group but is not a + reporting source MUST include an RTCP RGRS packet in every compound + RTCP packet in which it sends an RR or SR packet (i.e., in every RTCP + packet it sends, unless Reduced-Size RTCP [RFC5506] is in use). Each + RTCP RGRS packet MUST contain the SSRC identifier of at least one + reporting source. If there are more reporting sources in an RTCP + Reporting Group than can fit into an RTCP RGRS packet, the members of + that Reporting Group MUST send the SSRCs of the reporting sources in + a round-robin fashion in consecutive RTCP RGRS packets, such that all + the SSRCs of the reporting sources are included over the course of + several RTCP reporting intervals. + + An RTP mixer or translator that forwards RTCP SR or RR packets from + members of a Reporting Group MUST also forward the corresponding RGRS + RTCP packets. If the RTP mixer or translator rewrites SSRC values of + the packets it forwards, it MUST make the corresponding changes to + the RTCP RGRS packets. + +3.3. Interactions with the RTP/AVPF Feedback Profile + + The use of the RTP/AVPF Feedback Profile [RFC4585] allows SSRCs to + send rapid RTCP feedback requests and codec control messages. If the + use of the RTP/AVPF profile has been negotiated in an RTP session, + members of an RTCP Reporting Group can send rapid RTCP feedback and + codec control messages per [RFC5104], per [RFC4585] as updated by + Section 5.4 of [RFC8108], and by the following considerations. + + The members of an RTCP Reporting Group will all see identical network + conditions. Accordingly, one might therefore think that it doesn't + matter which SSRC in the Reporting Group sends the RTP/AVPF feedback + or codec control messages. There might be, however, cases where the + sender of the feedback/codec control message has semantic importance, + or when only a subset of the members of an RTCP Reporting Group might + want to send RTP/AVPF feedback or a codec control message in response + to a particular event. For example, an RTP video sender might choose + to treat packet loss feedback received from SSRCs known to be audio + receivers with less urgency than feedback that it receives from video + receivers when deciding what packets to retransmit, and a multimedia + receiver using Reporting Groups might want to choose the outgoing + SSRC for feedback packets to reflect this. + + Each member of an RTCP Reporting Group SHOULD therefore send RTP/AVPF + feedback/codec control messages independently of the other members of + the Reporting Group, to respect the semantic meaning of the message + sender. The suppression rules of [RFC4585] will ensure that only a + single copy of each feedback packet is (typically) generated, even if + several members of a Reporting Group send the same feedback. When an + endpoint knows that several members of its RTCP Reporting Group will + be sending identical feedback and that the sender of the feedback is + not semantically important, that endpoint MAY choose to send all its + feedback from the reporting source and deterministically suppress + feedback packets generated by the other sources in the Reporting + Group. + + It is important to note that the RTP/AVPF timing rules operate on a + per-SSRC basis. Using a single reporting source to send all feedback + for a Reporting Group will hence limit the amount of feedback that + can be sent to that which can be sent by one SSRC. If this limit is + a problem, then the Reporting Group can allow each of its members to + send its own feedback, using its own SSRC. + + If the RTP/AVPF feedback messages or codec control requests are sent + as compound RTCP packets, then those compound RTCP packets MUST + include either an RTCP RGRS packet or an RTCP RGRP SDES item, + depending on whether they are sent by the reporting source or a + non-reporting source in the RTCP Reporting Group, respectively. The + contents of noncompound RTCP feedback or codec control messages are + not affected by the use of RTCP Reporting Groups. + +3.4. Interactions with RTCP Extended Report (XR) Packets + + When using RTCP Extended Report (XR) packets [RFC3611] with RTCP + Reporting Groups, it is RECOMMENDED that the reporting source be used + to send the RTCP XR packets. If multiple reporting sources are in + use, the reporting source that sends the SR/RR packets that relate to + a particular remote SSRC SHOULD send the RTCP XR reports about that + SSRC. This is motivated as one commonly combine the RTCP XR metrics + with the regular report block to more fully understand the situation. + Receiving these blocks in different compound packets reduces their + value, as the measuring intervals are not synchronized in those + cases. + + Some RTCP XR report blocks are specific to particular types of media + and might be relevant to only some members of a Reporting Group. For + example, it would make no sense for an SSRC that is receiving video + to send a Voice over IP (VoIP) metric RTCP XR report block. Such + media-specific RTCP XR report blocks 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. This might mean that some SSRCs send + RTCP XR packets in compound RTCP packets that contain an empty RTCP + SR/RR packet and that the time period covered by the RTCP XR packet + is different from that covered by the RTCP SR/RR packet. If it is + important that the RTCP XR packet and RTCP SR/RR packet cover the + same time period, then that source SHOULD be removed from the RTCP + Reporting Group, and standard RTCP packets be sent instead. + +3.5. Middlebox Considerations + + Many different types of middleboxes are used with RTP. RTCP + Reporting Groups are potentially relevant to those types of RTP + middleboxes that have their own SSRCs and generate RTCP reports for + the traffic they receive. RTP middleboxes that do not have their own + SSRC and that do not send RTCP reports on the traffic they receive + cannot use the RTCP Reporting Group extension, since they generate no + RTCP reports to that group. + + An RTP middlebox that has several SSRCs of its own can use the RTCP + Reporting Group extension to group the RTCP reports it generates. + This can occur, for example, if a middlebox is acting as an RTP mixer + for both audio and video flows that are multiplexed onto a single RTP + session, where the middlebox has one SSRC for the audio mixer and one + for the video mixer part, and when the middlebox wants to avoid + cross-reporting between audio and video. + + A middlebox cannot use the RTCP Reporting Group extension to group + RTCP packets from the SSRCs that it is forwarding. It can, however, + group the RTCP packets from the SSRCs it is forwarding into compound + RTCP packets, following the rules in Section 6.1 of [RFC3550] and + Section 5.3 of [RFC8108]. If the middlebox is using RTCP Reporting + Groups for its own SSRCs, it MAY include RTCP packets from the SSRCs + that it is forwarding as part of the compound RTCP packets its + reporting source generates. + + A middlebox that forwards RTCP SR or RR packets sent by members of a + Reporting Group MUST forward the corresponding RTCP RGRP SDES items, + as described in Section 3.2.1. A middlebox that forwards RTCP SR or + RR packets sent by members of a Reporting Group MUST also forward the + corresponding RTCP RGRS packets, as described in Section 3.2.2. + Failure to forward these packets can cause compatibility problems, as + described in Section 4.2. + + If a middlebox rewrites SSRC values in the RTP and RTCP packets that + it is forwarding, then it MUST make the corresponding changes in RTCP + SDES packets containing RGRP items and in RTCP RGRS packets, to allow + them to be associated with the rewritten SSRCs. + +3.6. SDP Signaling for Reporting Groups + + This document defines the "a=rtcp-rgrp" Session Description Protocol + (SDP) [RFC4566] attribute to indicate if the session participant is + capable of supporting RTCP Reporting Groups for applications that use + SDP for configuration of RTP sessions. It is a property attribute + and hence takes no value. The multiplexing category [RFC8859] is + IDENTICAL, as the functionality applies at the RTP session level. A + participant that proposes the use of RTCP Reporting Groups SHALL + itself support the reception of RTCP Reporting Groups. The formal + definition of this attribute is as follows: + + Name: rtcp-rgrp + Value: None + Usage Level: session, media + Charset Dependent: no + Example: a=rtcp-rgrp + + When using SDP Offer/Answer [RFC3264], the following procedures are + to be used: + + Generating the initial SDP offer: + If the offerer supports the RTCP Reporting Group extensions and is + willing to accept RTCP packets containing those extensions, then + it MUST include an "a=rtcp-rgrp" attribute in the initial offer. + If the offerer does not support RTCP Reporting Group extensions or + is not willing to accept RTCP packets containing those extensions, + then it MUST NOT include the "a=rtcp-rgrp" attribute in the offer. + + Generating the SDP answer: + If the SDP offer contains an "a=rtcp-rgrp" attribute, and if the + answerer supports RTCP Reporting Groups and is willing to receive + RTCP packets using the RTCP Reporting Group extensions, then the + answerer MAY include an "a=rtcp-rgrp" attribute in the answer and + MAY send RTCP packets containing the RTCP Reporting Group + extensions. If the offer does not contain an "a=rtcp-rgrp" + attribute, or if the offer does contain such an attribute but the + answerer does not wish to accept RTCP packets using the RTCP + Reporting Group extensions, then the answer MUST NOT include an + "a=rtcp-rgrp" attribute. + + Offerer processing of the SDP answer: + If the SDP answer contains an "a=rtcp-rgrp" attribute and the + corresponding offer also contained an "a=rtcp-rgrp" attribute, + then the offerer MUST be prepared to accept and process RTCP + packets that contain the Reporting Group extensions and MAY send + RTCP packets that contain the Reporting Group extensions. If the + SDP answer contains an "a=rtcp-rgrp" attribute but the + corresponding offer did not contain the "a=rtcp-rgrp" attribute, + then the offerer MUST reject the call. If the SDP answer does not + contain an "a=rtcp-rgrp" attribute, then the offerer MUST NOT send + packets containing the RTCP Reporting Group extensions and does + not need to process packets containing the RTCP Reporting Group + extensions. + + In declarative usage of SDP, such as the Real-Time Streaming Protocol + (RTSP) [RFC7826] and the Session Announcement Protocol (SAP) + [RFC2974], the presence of the attribute indicates that the session + participant MAY use RTCP Reporting Groups in its RTCP transmissions. + An implementation that doesn't explicitly support RTCP Reporting + Groups MAY join an RTP session as long as it has been verified that + the implementation doesn't suffer from the problems discussed in + Section 4.2. + +4. Properties of RTCP Reporting Groups + + This section provides additional information on what the resulting + properties are (i.e., resulting effects or impacts) as related to the + design specified in Section 3. The content of this section is non- + normative. + +4.1. Bandwidth Benefits of RTCP Reporting Groups + + To understand the benefits of RTCP Reporting Groups, consider a + scenario in which the two endpoints in a session each have a hundred + sources, of which eight each are sending within any given reporting + interval. + + For ease of analysis, we can make the simplifying approximation that + the duration of the RTCP reporting interval is equal to the total + size of the RTCP packets sent during an RTCP interval, divided by the + RTCP bandwidth. (This will be approximately true in scenarios where + the bandwidth is not so high that the minimum RTCP interval is + reached.) To further simplify, we can assume that RTCP senders are + following the recommendations regarding compound RTCP packets in + [RFC8108]; thus, the per-packet transport-layer overhead will be + small relative to the RTCP data. Thus, only the actual RTCP data + itself need be considered. + + In a report interval in this scenario, there will, as a baseline, be + 200 SDES packets, 184 RR packets, and 16 SR packets. This amounts to + approximately 6.5 KB of RTCP packets per report interval, assuming + 16-byte CNAMEs and no other SDES information. + + Using the original "everyone reports on every sender" feedback rules + [RFC3550], each of the 184 receivers will send 16 report blocks, and + each of the 16 senders will send 15. This amounts to approximately + 76 KB of report block traffic per interval; 92% of RTCP traffic + consists of report blocks. + + If Reporting Groups are used, however, there is only 0.4 KB of + reports per interval, with no loss of useful information. + Additionally, there will be (assuming 16-byte RGRPs and a single + reporting source per Reporting Group) an additional 2.4 KB per cycle + of RTCP RGRP SDES items and RGRS packets. Put another way, the + unmodified reporting interval per [RFC3550] is approximately 9 times + longer than if Reporting Groups are in use. + +4.2. Compatibility of RTCP Reporting Groups + + The RTCP traffic generated by receivers using RTCP Reporting Groups + might appear, to observers unaware of these semantics, to be + generated by receivers who are experiencing a network disconnection, + as the non-reporting sources appear not to be receiving a given + sender at all. + + This could be a potentially critical problem for such a sender using + RTCP for congestion control, as such a sender might think that it is + sending so much traffic that it is causing complete congestion + collapse. + + However, such an interpretation of the session statistics would + require a fairly sophisticated RTCP analysis. Any receiver of RTCP + statistics that is just interested in information about itself needs + to be prepared for the possibility that any given reception report + might not contain information about a specific media source, because + reception reports in large conferences can be round-robined. + + Thus, the extent to which such backward-compatibility issues would + actually cause trouble in practice is unclear. + +5. Security Considerations + + The security considerations of [RFC3550] and [RFC8108] apply. If the + RTP/AVPF profile is in use, then the security considerations of + [RFC4585] (and [RFC5104], if used) also apply. If RTCP XR is used, + the security considerations of [RFC3611], including security + considerations regarding any XR report blocks used, also apply. + + The RTCP RGRP SDES item is vulnerable to malicious modifications + unless integrity protection is used. A modification of this item's + length field causes the parsing of the RTCP packet in which it is + contained to fail. Depending on the implementation, parsing of the + full compound RTCP packet can also fail, causing the whole packet to + be discarded. A modification of the value of this SDES item would + make the receiver of the report think that the sender of the report + was a member of a different RTCP Reporting Group. This will + potentially create an inconsistency, when the RGRS reports the source + as being in the same Reporting Group as another source with another + Reporting Group identifier. The impacts on a receiver implementation + that such inconsistencies could cause are difficult to fully predict. + One case is that when congestion control or other adaptation + mechanisms are used, an inconsistent report can result in a media + sender reducing its bitrate. However, a direct modification of the + RR or a feedback message itself would be a more efficient attack and + would be equally costly to perform. + + The new RGRS RTCP packet type is very simple. The common RTCP packet + type header shares the same security risks as those that affect + previous RTCP packet types. Errors or modification of the length + field can cause the full compound packet to fail header validation + (see Appendix A.2 of [RFC3550]), resulting in the whole compound RTCP + packet being discarded. Modification of the SC field or the P field + would cause an inconsistency when processing the RTCP packet, likely + resulting in the packet being classified as invalid. A modification + of the PT field would cause the packet to be interpreted according to + some other packet type's rules. In such a case, the result might be + more or less predictable but would be specific to the packet type. + Modification of the "SSRC of packet sender" field would attribute + this packet to another sender, resulting in a receiver believing that + the Reporting Group also applies for this SSRC, if it exists. If it + doesn't exist, unless corresponding modifications are also done on an + SR/RR packet and an SDES packet, the RTCP packet SHOULD be discarded. + If consistent changes are done, such a scenario could be part of a + resource exhaustion attack on a receiver implementation. + Modification of the "List of SSRCs for the Reporting Source(s)" field + would change the SSRC the receiver expects to report on behalf of + this SSRC. If that SSRC exists, this situation could potentially + change the Reporting Group used for this SSRC. A change to another + Reporting Group belonging to another endpoint is likely detectable, + as there would be a mismatch between the SSRC of the packet sender's + endpoint information, transport addresses, SDES CNAME, etc., and the + corresponding information from the Reporting Group indicated. + + In general, the Reporting Group is providing limited-impact attacks + on the endpoints. The most significant result from a deliberate + attack would be to cause the information to be discarded or be + inconsistent, including the discarding of all RTCP packets that are + modified. This causes a lack of information at any receiver entity, + possibly disregarding the endpoint's participation in the session. + + To protect against such attacks from external non-trusted entities, + integrity and source authentication SHOULD be applied. This can be + done, for example, by using the Secure Real-time Transport Protocol + (SRTP) [RFC3711] with appropriate key management; other options + exist, as discussed in "Options for Securing RTP Sessions" [RFC7201]. + + The Reporting Group Identifier has properties that could potentially + impact privacy. If this identifier were to be generated by an + implementation in a way that makes it long-term stable or + predictable, it could be used for tracking a particular endpoint. + Therefore, it is RECOMMENDED that it be generated as a short-term + persistent RGRP, following the rules for short-term persistent CNAMEs + in [RFC7022]. The rest of the information revealed, i.e., the SSRCs, + the size of the Reporting Group, and the number of reporting sources + in a Reporting Group, is of a less sensitive nature, considering that + the SSRCs and the communication would be revealed without this + extension anyway. By encrypting the Reporting Group extensions, the + confidentiality of the SSRC values would be preserved, but the values + can still be revealed if SRTP [RFC3711] is used. The size of the + Reporting Groups and the number of reporting sources are likely + determinable from analysis of the packet pattern and sizes. However, + this information appears to have limited value. + +6. IANA Considerations + + IANA has registered a new RTCP RGRP SDES item in the "RTP SDES Item + Types" registry, as follows: + + +=======+========+============================+===========+ + | Value | Abbrev | Name | Reference | + +=======+========+============================+===========+ + | 11 | RGRP | Reporting Group Identifier | RFC 8861 | + +-------+--------+----------------------------+-----------+ + + Table 1: New RTCP RGRP SDES Item: Reporting Group + Identifier + + The definition of the RTCP RGRP SDES item is given in Section 3.2.1 + of this memo. + + IANA has registered a new RTCP packet type in the "RTCP Control + Packet Types (PT)" registry, as follows: + + +=======+========+===================================+===========+ + | Value | Abbrev | Name | Reference | + +=======+========+===================================+===========+ + | 212 | RGRS | Reporting Group Reporting Sources | RFC 8861 | + +-------+--------+-----------------------------------+-----------+ + + Table 2: New RTCP Packet Type: Reporting Group Reporting Sources + + The definition of the RTCP RGRS packet type is given in Section 3.2.2 + of this memo. + + IANA has also registered a new SDP attribute. + + SDP Attribute ("att-field"): + + Contact Name: IESG + + Contact Email: iesg@ietf.org + + Attribute name: rtcp-rgrp + + Long form: RTCP Reporting Groups + + Type of name: att-field + + Type of attribute: Media or session level + + Subject to charset: No + + Purpose: To negotiate or configure the use of the + RTCP Reporting Group extension + + Reference: RFC 8861 + + Value: None + + Mux Category: IDENTICAL + + The definition of the "a=rtcp-rgrp" SDES attribute is given in + Section 3.6 of this memo. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model + with Session Description Protocol (SDP)", RFC 3264, + DOI 10.17487/RFC3264, June 2002, + <https://www.rfc-editor.org/info/rfc3264>. + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, + July 2003, <https://www.rfc-editor.org/info/rfc3550>. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, DOI 10.17487/RFC4566, + July 2006, <https://www.rfc-editor.org/info/rfc4566>. + + [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, + "Guidelines for Choosing RTP Control Protocol (RTCP) + Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, + September 2013, <https://www.rfc-editor.org/info/rfc7022>. + + [RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, + "Sending Multiple RTP Streams in a Single RTP Session", + RFC 8108, DOI 10.17487/RFC8108, March 2017, + <https://www.rfc-editor.org/info/rfc8108>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8859] Nandakumar, S., "A Framework for Session Description + Protocol (SDP) Attributes When Multiplexing", RFC 8859, + DOI 10.17487/RFC8859, January 2021, + <https://www.rfc-editor.org/info/rfc8859>. + +7.2. Informative References + + [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session + Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, + October 2000, <https://www.rfc-editor.org/info/rfc2974>. + + [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., + "RTP Control Protocol Extended Reports (RTCP XR)", + RFC 3611, DOI 10.17487/RFC3611, November 2003, + <https://www.rfc-editor.org/info/rfc3611>. + + [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. + Norrman, "The Secure Real-time Transport Protocol (SRTP)", + RFC 3711, DOI 10.17487/RFC3711, March 2004, + <https://www.rfc-editor.org/info/rfc3711>. + + [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, + "Extended RTP Profile for Real-time Transport Control + Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, + DOI 10.17487/RFC4585, July 2006, + <https://www.rfc-editor.org/info/rfc4585>. + + [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. + Hakenberg, "RTP Retransmission Payload Format", RFC 4588, + DOI 10.17487/RFC4588, July 2006, + <https://www.rfc-editor.org/info/rfc4588>. + + [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, + "Codec Control Messages in the RTP Audio-Visual Profile + with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, + February 2008, <https://www.rfc-editor.org/info/rfc5104>. + + [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size + Real-Time Transport Control Protocol (RTCP): Opportunities + and Consequences", RFC 5506, DOI 10.17487/RFC5506, April + 2009, <https://www.rfc-editor.org/info/rfc5506>. + + [RFC6190] Wenger, S., Wang, Y.-K., Schierl, T., and A. + Eleftheriadis, "RTP Payload Format for Scalable Video + Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011, + <https://www.rfc-editor.org/info/rfc6190>. + + [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP + Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, + <https://www.rfc-editor.org/info/rfc7201>. + + [RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., + and M. Stiemerling, Ed., "Real-Time Streaming Protocol + Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December + 2016, <https://www.rfc-editor.org/info/rfc7826>. + +Authors' Addresses + + Jonathan Lennox + 8x8, Inc. / Jitsi + Jersey City, NJ 07302 + United States of America + + Email: jonathan.lennox@8x8.com + + + Magnus Westerlund + Ericsson + Torshamnsgatan 23 + SE-164 80 Kista + Sweden + + Email: magnus.westerlund@ericsson.com + + + Qin Wu + Huawei + 101 Software Avenue, Yuhua District + Nanjing, Jiangsu 210012 + China + + Email: bill.wu@huawei.com + + + Colin Perkins + University of Glasgow + School of Computing Science + Glasgow + G12 8QQ + United Kingdom + + Email: csp@csperkins.org |