idnits 2.17.1 draft-ietf-avtcore-rtp-multi-stream-optimisation-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2, 2016) is 2970 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBA' is mentioned on line 302, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 702, but not defined == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-12 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTCORE WG J. Lennox 3 Internet-Draft Vidyo 4 Intended status: Standards Track M. Westerlund 5 Expires: September 3, 2016 Ericsson 6 Q. Wu 7 Huawei 8 C. Perkins 9 University of Glasgow 10 March 2, 2016 12 Sending Multiple RTP Streams in a Single RTP Session: Grouping RTCP 13 Reception Statistics and Other Feedback 14 draft-ietf-avtcore-rtp-multi-stream-optimisation-12 16 Abstract 18 RTP allows multiple RTP streams to be sent in a single session, but 19 requires each Synchronisation Source (SSRC) to send RTCP reception 20 quality reports for every other SSRC visible in the session. This 21 causes the number of RTCP reception reports to grow with the number 22 of SSRCs, rather than the number of endpoints. In many cases most of 23 these RTCP reception reports are unnecessary, since all SSRCs of an 24 endpoint are normally co-located and see the same reception quality. 25 This memo defines a Reporting Group extension to RTCP to reduce the 26 reporting overhead in such scenarios. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 3, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. RTCP Reporting Groups . . . . . . . . . . . . . . . . . . . . 3 65 3.1. Semantics and Behaviour of RTCP Reporting Groups . . . . 4 66 3.2. Identifying Members of an RTCP Reporting Group . . . . . 5 67 3.2.1. Definition and Use of the RTCP RGRP SDES Item . . . . 5 68 3.2.2. Definition and Use of the RTCP RGRS Packet . . . . . 6 69 3.3. Interactions with the RTP/AVPF Feedback Profile . . . . . 8 70 3.4. Interactions with RTCP Extended Report (XR) Packets . . . 9 71 3.5. Middlebox Considerations . . . . . . . . . . . . . . . . 9 72 3.6. SDP Signalling for Reporting Groups . . . . . . . . . . . 10 73 4. Properties of RTCP Reporting Groups . . . . . . . . . . . . . 12 74 4.1. Bandwidth Benefits of RTCP Reporting Groups . . . . . . . 12 75 4.2. Compatibility of RTCP Reporting Groups . . . . . . . . . 13 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 80 7.2. Informative References . . . . . . . . . . . . . . . . . 16 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 83 1. Introduction 85 The Real-time Transport Protocol (RTP) [RFC3550] is a protocol for 86 group communication, supporting multiparty multimedia sessions. A 87 single RTP session can support multiple participants sending at once, 88 and can also support participants sending multiple simultaneous RTP 89 streams. Examples of the latter might include a participant with 90 multiple cameras who chooses to send multiple views of a scene, or a 91 participant that sends audio and video flows multiplexed in a single 92 RTP session. Rules for handling RTP sessions containing multiple RTP 93 streams are described in [RFC3550] with some clarifications in 94 [I-D.ietf-avtcore-rtp-multi-stream]. 96 An RTP endpoint will have one or more synchronisation sources 97 (SSRCs). It will have at least one RTP Stream, and thus SSRC, for 98 each media source it sends, and might use multiple SSRCs per media 99 source when using media scalability features [RFC6190], forward error 100 correction, RTP retransmission [RFC4588], or similar mechanisms. An 101 endpoint that is not sending any RTP stream, will have at least one 102 SSRC to use for reporting and any feedback messages. Each SSRC has 103 to send RTCP sender reports corresponding to the RTP packets it 104 sends, and receiver reports for traffic it receives. That is, every 105 SSRC will send RTCP packets to report on every other SSRC. This rule 106 is simple, but can be quite inefficient for endpoints that send large 107 numbers of RTP streams in a single RTP session. Consider a session 108 comprising ten participants, each sending three media sources, each 109 with their own RTP stream. There will be 30 SSRCs in such an RTP 110 session, and each of those 30 SSRCs will send an RTCP Sender Report/ 111 Receiver Report packet (containing several report blocks) per 112 reporting interval as each SSRC reports on all the others. However, 113 the three SSRCs comprising each participant are commonly co-located 114 such that they see identical reception quality. If there was a way 115 to indicate that several SSRCs are co-located, and see the same 116 reception quality, then two-thirds of those RTCP reports could be 117 suppressed. This would allow the remaining RTCP reports to be sent 118 more often, while keeping within the same RTCP bandwidth fraction. 120 This memo defines such an RTCP extension, RTCP Reporting Groups. 121 This extension is used to indicate the SSRCs that originate from the 122 same endpoint, and therefore have identical reception quality, hence 123 allowing the endpoints to suppress unnecessary RTCP reception quality 124 reports. 126 2. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 3. RTCP Reporting Groups 134 An RTCP Reporting Group is a set of synchronization sources (SSRCs) 135 that are co-located at a single endpoint (which could be an end host 136 or a middlebox) in an RTP session. Since they are co-located, every 137 SSRC in the RTCP reporting group will have an identical view of the 138 network conditions, and see the same lost packets, jitter, etc. This 139 allows a single representative to send RTCP reception quality reports 140 on behalf of the rest of the reporting group, reducing the number of 141 RTCP packets that need to be sent without loss of information. 143 3.1. Semantics and Behaviour of RTCP Reporting Groups 145 A group of co-located SSRCs that see identical network conditions can 146 form an RTCP reporting group. If reporting groups are in use, an RTP 147 endpoint with multiple SSRCs MAY put those SSRCs into a reporting 148 group if their view of the network is identical; i.e., if they report 149 on traffic received at the same interface of an RTP endpoint. SSRCs 150 with different views of the network MUST NOT be put into the same 151 reporting group. 153 An endpoint that has combined its SSRCs into an RTCP reporting group 154 will choose one (or a subset) of those SSRCs to act as "reporting 155 source(s)" for that RTCP reporting group. A reporting source will 156 send RTCP SR/RR reception quality reports on behalf of the other 157 members of the RTCP reporting group. A reporting source MUST 158 suppress the RTCP SR/RR reports that relate to other members of the 159 reporting group, and only report on remote SSRCs. The other members 160 (non reporting sources) of the RTCP reporting group will suppress 161 their RTCP reception quality reports, and instead send an RTCP RGRS 162 packet (see Section 3.2.2) to indicate that they are part of an RTCP 163 reporting group and give the SSRCs of the reporting sources. 165 If there are large numbers of remote SSRCs in the RTP session, then 166 the reception quality reports generated by the reporting source might 167 grow too large to fit into a single compound RTCP packet, forcing the 168 reporting source to use a round-robin policy to determine what remote 169 SSRCs it includes in each compound RTCP packet, and so reducing the 170 frequency of reports on each SSRC. To avoid this, in sessions with 171 large numbers of remote SSRCs, an RTCP reporting group MAY use more 172 than one reporting source. If several SSRCs are acting as reporting 173 sources for an RTCP reporting group, then each reporting source MUST 174 have non-overlapping sets of remote SSRCs it reports on. 176 An endpoint MUST NOT create an RTCP reporting group that comprises 177 only a single local SSRC (i.e., an RTCP reporting group where the 178 reporting source is the only member of the group), unless it is 179 anticipated that the group might have additional SSRCs added to it in 180 the future. 182 If a reporting source leaves the RTP session (i.e., if it sends a 183 RTCP BYE packet, or leaves the session without sending BYE under the 184 rules of [RFC3550] section 6.3.7), the remaining members of the RTCP 185 reporting group MUST either (a) have another reporting source, if one 186 exists, report on the remote SSRCs the leaving SSRC reported on, (b) 187 choose a new reporting source, or (c) disband the RTCP reporting 188 group and begin sending reception quality reports following [RFC3550] 189 and [I-D.ietf-avtcore-rtp-multi-stream]. 191 The RTCP timing rules assign different bandwidth fractions to senders 192 and receivers. This lets senders transmit RTCP reception quality 193 reports more often than receivers. If a reporting source in an RTCP 194 reporting group is a receiver, but one or more non-reporting SSRCs in 195 the RTCP reporting group are senders, then the endpoint MAY treat the 196 reporting source as a sender for the purpose of RTCP bandwidth 197 allocation, increasing its RTCP bandwidth allocation, provided it 198 also treats one of the senders as if it were a receiver and makes the 199 corresponding reduction in RTCP bandwidth for that SSRC. However, 200 the application needs to consider the impact on the frequency of 201 transmitting of the synchronization information included in RTCP 202 Sender Reports. 204 3.2. Identifying Members of an RTCP Reporting Group 206 When RTCP Reporting Groups are in use, the other SSRCs in the RTP 207 session need to be able to identify which SSRCs are members of an 208 RTCP reporting group. Two RTCP extensions are defined to support 209 this: the RTCP RGRP SDES item is used by the reporting source(s) to 210 identify an RTCP reporting group, and the RTCP RGRS packet is used by 211 other members of an RTCP reporting group to identify the reporting 212 source(s). 214 3.2.1. Definition and Use of the RTCP RGRP SDES Item 216 This document defines a new RTCP SDES item to identify an RTCP 217 reporting group. The motivation for giving a reporting group an 218 identify is to ensure that the RTCP reporting group and its member 219 SSRCs can be correctly associated when there are multiple reporting 220 sources, and to ensure that a reporting SSRC can be associated with 221 the correct reporting group if an SSRC collision occurs. 223 This document defines the RTCP Source Description (SDES) RGRP item. 224 The RTCP SDES RGRP item MUST be sent by the reporting sources in a 225 reporting group, and MUST NOT be sent by other members of the 226 reporting group or by SSRCs that are not members of any RTCP 227 reporting group. Specifically, every reporting source in an RTCP 228 reporting group MUST include an RTCP SDES packet containing an RGRP 229 item in every compound RTCP packet in which it sends an RR or SR 230 packet (i.e., in every RTCP packet it sends, unless Reduced-Size RTCP 231 [RFC5506] is in use). 233 Syntactically, the format of the RTCP SDES RGRP item is identical to 234 that of the RTCP SDES CNAME item [RFC7022], except that the SDES item 235 type field MUST have value RGRP=(TBA) instead of CNAME=1. The value 236 of the RTCP SDES RGRP item MUST be chosen with the same concerns 237 about global uniqueness and the same privacy considerations as the 238 RTCP SDES CNAME. The value of the RTCP SDES RGRP item MUST be stable 239 throughout the lifetime of the reporting group, even if some or all 240 of the reporting sources change their SSRC due to collisions, or if 241 the set of reporting sources changes. 243 Note to RFC Editor: please replace (TBA) in the above paragraph 244 with the RTCP SDES item type number assigned to the RGRP item, 245 then delete this note. 247 An RTP mixer or translator that forwards RTCP SR or RR packets from 248 members of a reporting group MUST forward the corresponding RTCP SDES 249 RGRP items as well, even if it otherwise strips SDES items other than 250 the CNAME item. 252 3.2.2. Definition and Use of the RTCP RGRS Packet 254 A new RTCP packet type is defined to allow the members of an RTCP 255 reporting group to identify the reporting sources for that group. 256 This allows participants in an RTP session to distinguish an SSRC 257 that is sending empty RTCP reception reports because it is a member 258 of an RTCP reporting group, from an SSRC that is sending empty RTCP 259 reception reports because it is not receiving any traffic. It also 260 explicitly identifies the reporting sources, allowing other members 261 of the RTP session to know which SSRCs are acting as the reporting 262 sources for an RTCP reporting group, and allowing them to detect if 263 RTCP packets from any of the reporting sources are being lost. 265 The format of the RTCP RGRS packet is defined below. It comprises 266 the fixed RTCP header that indicates the packet type and length, the 267 SSRC of the packet sender, and a list of reporting sources for the 268 RTCP reporting group of which the packet sender is a member. 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 |V=2|P| SC | PT=RGRS(TBA) | length | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | SSRC of packet sender | 276 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 277 : List of SSRC(s) for the Reporting Source(s) : 278 : ... : 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 The fields in the RTCP RGRS packet have the following definition: 283 version (V): 2 bits unsigned integer. This field identifies the RTP 284 version. The current RTP version is 2. 286 padding (P): 1 bit. If set, the padding bit indicates that the RTCP 287 packet contains additional padding octets at the end that are not 288 part of the control information but are included in the length 289 field. See [RFC3550]. 291 Source Count (SC): 5 bits unsigned integer. Indicates the number of 292 reporting source SSRCs that are included in this RTCP packet. As 293 the RTCP RGRS packet MUST NOT be not sent by reporting sources, 294 all the SSRCs in the list of reporting sources will be different 295 from the SSRC of the packet sender. Every RTCP RGRS packet MUST 296 contain at least one reporting source SSRC. 298 Payload type (PT): 8 bits unsigned integer. The RTCP packet type 299 number that identifies the packet as being an RTCP RGRS packet. 300 The RGRS RTCP packet has the value [TBA]. 302 Note to RFC Editor: please replace [TBA] here, and in the 303 packet format diagram above, with the RTCP packet type that 304 IANA assigns to the RTCP RGRS packet. 306 Length: 16 bits unsigned integer. The length of this packet in 307 32-bit words minus one, including the header and any padding. 308 This is in line with the definition of the length field used in 309 RTCP sender and receiver reports [RFC3550]. Since all RTCP RGRS 310 packets include at least one reporting source SSRC, the length 311 will always be 2 or greater. 313 SSRC of packet sender: 32 bits. The SSRC of the sender of this 314 packet. 316 List of SSRCs for the Reporting Source(s): A variable length size 317 (as indicated by SC header field) of the 32 bit SSRC values of the 318 reporting sources for the RTCP Reporting Group of which the packet 319 sender is a member. 321 Every source that belongs to an RTCP reporting group but is not a 322 reporting source MUST include an RTCP RGRS packet in every compound 323 RTCP packet in which it sends an RR or SR packet (i.e., in every RTCP 324 packet it sends, unless Reduced-Size RTCP [RFC5506] is in use). Each 325 RTCP RGRS packet MUST contain the SSRC identifier of at least one 326 reporting source. If there are more reporting sources in an RTCP 327 reporting group than can fit into an RTCP RGRS packet, the members of 328 that reporting group MUST send the SSRCs of the reporting sources in 329 a round-robin fashion in consecutive RTCP RGRS packets, such that all 330 the SSRCs of the reporting sources are included over the course of 331 several RTCP reporting intervals. 333 An RTP mixer or translator that forwards RTCP SR or RR packets from 334 members of a reporting group MUST also forward the corresponding RGRS 335 RTCP packets. If the RTP mixer or translator rewrites SSRC values of 336 the packets it forwards, it MUST make the corresponding changes to 337 the RTCP RGRS packets. 339 3.3. Interactions with the RTP/AVPF Feedback Profile 341 Use of the RTP/AVPF Feedback Profile [RFC4585] allows SSRCs to send 342 rapid RTCP feedback requests and codec control messages. If use of 343 the RTP/AVPF profile has been negotiated in an RTP session, members 344 of an RTCP reporting group can send rapid RTCP feedback and codec 345 control messages following [RFC4585] and [RFC5104], as updated by 346 Section 5.4 of [I-D.ietf-avtcore-rtp-multi-stream], and by the 347 following considerations. 349 The members of an RTCP reporting group will all see identical network 350 conditions. Accordingly, one might therefore think that it doesn't 351 matter which SSRC in the reporting group sends the RTP/AVPF feedback 352 or codec control messages. There might be, however, cases where the 353 sender of the feedback/codec control message has semantic importance, 354 or when only a subset of the members of an RTCP reporting group might 355 want to send RTP/AVPF feedback or a codec control message in response 356 to a particular event. For example, an RTP video sender might choose 357 to treat packet loss feedback received from SSRCs known to be audio 358 receivers with less urgency than feedback that it receives from video 359 receivers when deciding what packets to retransmit, and a multimedia 360 receiver using reporting groups might want to choose the outgoing 361 SSRC for feedback packets to reflect this. 363 Each member of an RTCP reporting group SHOULD therefore send RTP/AVPF 364 feedback/codec control messages independently of the other members of 365 the reporting group, to respect the semantic meaning of the message 366 sender. The suppression rules of [RFC4585] will ensure that only a 367 single copy of each feedback packet is (typically) generated, even if 368 several members of a reporting group send the same feedback. When an 369 endpoint knows that several members of its RTCP reporting group will 370 be sending identical feedback, and that the sender of the feedback is 371 not semantically important, then that endpoint MAY choose to send all 372 its feedback from the reporting source and deterministically suppress 373 feedback packets generated by the other sources in the reporting 374 group. 376 It is important to note that the RTP/AVPF timing rules operate on a 377 per-SSRC basis. Using a single reporting source to send all feedback 378 for a reporting group will hence limit the amount of feedback that 379 can be sent to that which can be sent by one SSRC. If this limit is 380 a problem, then the reporting group can allow each of its members to 381 send its own feedback, using its own SSRC. 383 If the RTP/AVPF feedback messages or codec control requests are sent 384 as compound RTCP packets, then those compound RTCP packets MUST 385 include either an RTCP RGRS packet or an RTCP SDES RGRP item, 386 depending on whether they are sent by the reporting source or a non- 387 reporting source in the RTCP reporting group respectively. The 388 contents of non-compound RTCP feedback or codec control messages are 389 not affected by the use of RTCP reporting groups. 391 3.4. Interactions with RTCP Extended Report (XR) Packets 393 When using RTCP Extended Reports (XR) [RFC3611] with RTCP reporting 394 groups, it is RECOMMENDED that the reporting source is used to send 395 the RTCP XR packets. If multiple reporting sources are in use, the 396 reporting source that sends the SR/RR packets that relate to a 397 particular remote SSRC SHOULD send the RTCP XR reports about that 398 SSRC. This is motivated as one commonly combine the RTCP XR metrics 399 with the regular report block to more fully understand the situation. 400 Receiving these blocks in different compound packets reduces their 401 value as the measuring intervals are not synchronized in those cases. 403 Some RTCP XR report blocks are specific to particular types of media, 404 and might be relevant to only some members of a reporting group. For 405 example, it would make no sense for an SSRC that is receiving video 406 to send a VoIP metric RTCP XR report block. Such media specific RTCP 407 XR report blocks MUST be sent by the SSRC to which they are relevant, 408 and MUST NOT be included in the common report sent by the reporting 409 source. This might mean that some SSRCs send RTCP XR packets in 410 compound RTCP packets that contain an empty RTCP SR/RR packet, and 411 that the time period covered by the RTCP XR packet is different to 412 that covered by the RTCP SR/RR packet. If it is important that the 413 RTCP XR packet and RTCP SR/RR packet cover the same time period, then 414 that source SHOULD be removed from the RTCP reporting group, and send 415 standard RTCP packets instead. 417 3.5. Middlebox Considerations 419 Many different types of middlebox are used with RTP. RTCP reporting 420 groups are potentially relevant to those types of RTP middlebox that 421 have their own SSRCs and generate RTCP reports for the traffic they 422 receive. RTP middleboxes that do not have their own SSRC, and that 423 don't send RTCP reports on the traffic they receive, cannot use the 424 RTCP reporting groups extension, since they generate no RTCP reports 425 to group. 427 An RTP middlebox that has several SSRCs of its own can use the RTCP 428 reporting groups extension to group the RTCP reports it generates. 429 This can occur, for example, if a middlebox is acting as an RTP mixer 430 for both audio and video flows that are multiplexed onto a single RTP 431 session, where the middlebox has one SSRC for the audio mixer and one 432 for the video mixer part, and when the middlebox wants to avoid cross 433 reporting between audio and video. 435 A middlebox cannot use the RTCP reporting groups extension to group 436 RTCP packets from the SSRCs that it is forwarding. It can, however, 437 group the RTCP packets from the SSRCs it is forwarding into compound 438 RTCP packets following the rules in Section 6.1 of [RFC3550] and 439 Section 5.3 of [I-D.ietf-avtcore-rtp-multi-stream]. If the middlebox 440 is using RTCP reporting groups for its own SSRCs, it MAY include RTCP 441 packets from the SSRCs that it is forwarding as part of the compound 442 RTCP packets its reporting source generates. 444 A middlebox that forwards RTCP SR or RR packets sent by members of a 445 reporting group MUST forward the corresponding RTCP SDES RGRP items, 446 as described in Section 3.2.1. A middlebox that forwards RTCP SR or 447 RR packets sent by member of a reporting group MUST also forward the 448 corresponding RTCP RGRS packets, as described in Section 3.2.2. 449 Failure to forward these packets can cause compatibility problems, as 450 described in Section 4.2. 452 If a middlebox rewrites SSRC values in the RTP and RTCP packets that 453 it is forwarding, then it MUST make the corresponding changes in RTCP 454 SDES packets containing RGRP items and in RTCP RGRS packets, to allow 455 them to be associated with the rewritten SSRCs. 457 3.6. SDP Signalling for Reporting Groups 459 This document defines the "a=rtcp-rgrp" Session Description Protocol 460 (SDP) [RFC4566] attribute to indicate if the session participant is 461 capable of supporting RTCP Reporting Groups for applications that use 462 SDP for configuration of RTP sessions. It is a property attribute, 463 and hence takes no value. The multiplexing category 464 [I-D.ietf-mmusic-sdp-mux-attributes] is IDENTICAL, as the 465 functionality applies on RTP session level. A participant that 466 proposes the use of RTCP Reporting Groups SHALL itself support the 467 reception of RTCP Reporting Groups. The formal definition of this 468 attribute is: 470 Name: rtcp-rgrp 471 Value: 472 Usage Level: session, media 473 Charset Dependent: no 474 Example: 475 a=rtcp-rgrp 477 When using SDP Offer/Answer [RFC3264], the following procedures are 478 to be used: 480 o Generating the initial SDP offer: If the offerer supports the RTCP 481 reporting group extensions, and is willing to accept RTCP packets 482 containing those extensions, then it MUST include an "a=rtcp-rgrp" 483 attribute in the initial offer. If the offerer does not support 484 RTCP reporting groups extensions, or is not willing to accept RTCP 485 packets containing those extensions, then it MUST NOT include the 486 "a=rtcp-rgrp" attribute in the offer. 488 o Generating the SDP answer: If the SDP offer contains an "a=rtcp- 489 rgrp" attribute, and if the answerer supports RTCP reporting 490 groups and is willing to receive RTCP packets using the RTCP 491 reporting groups extensions, then the answerer MAY include an 492 "a=rtcp-rgrp" attribute in the answer and MAY send RTCP packets 493 containing the RTCP reporting groups extensions. If the offer 494 does not contain an "a=rtcp-rgrp" attribute, or if the offer does 495 contain such an attribute but the answerer does not wish to accept 496 RTCP packets using the RTCP reporting groups extensions, then the 497 answer MUST NOT include an "a=rtcp-rgrp" attribute. 499 o Offerer Processing of the SDP Answer: If the SDP answer contains 500 an "a=rtcp-rgrp" attribute, and the corresponding offer also 501 contained an "a=rtcp-rgrp" attribute, then the offerer MUST be 502 prepared to accept and process RTCP packets that contain the 503 reporting groups extension, and MAY send RTCP packets that contain 504 the reporting groups extension. If the SDP answer contains an 505 "a=rtcp-rgrp" attribute, but the corresponding offer did not 506 contain the "a=rtcp-rgrp" attribute, then the offerer MUST reject 507 the call. If the SDP answer does not contain an "a=rtcp-rgrp" 508 attribute, then the offerer MUST NOT send packets containing the 509 RTCP reporting groups extensions, and does not need to process 510 packet containing the RTCP reporting groups extensions. 512 In declarative usage of SDP, such as the Real Time Streaming Protocol 513 (RTSP) [RFC2326] and the Session Announcement Protocol (SAP) 514 [RFC2974], the presence of the attribute indicates that the session 515 participant MAY use RTCP Reporting Groups in its RTCP transmissions. 516 An implementation that doesn't explicitly support RTCP Reporting 517 Groups MAY join a RTP session as long as it has been verified that 518 the implementation doesn't suffer from the problems discussed in 519 Section 4.2. 521 4. Properties of RTCP Reporting Groups 523 This section provides additional information on what the resulting 524 properties are with the design specified in Section 3. The content 525 of this section is non-normative. 527 4.1. Bandwidth Benefits of RTCP Reporting Groups 529 To understand the benefits of RTCP reporting groups, consider a 530 scenario in which the two endpoints in a session each have a hundred 531 sources, of which eight each are sending within any given reporting 532 interval. 534 For ease of analysis, we can make the simplifying approximation that 535 the duration of the RTCP reporting interval is equal to the total 536 size of the RTCP packets sent during an RTCP interval, divided by the 537 RTCP bandwidth. (This will be approximately true in scenarios where 538 the bandwidth is not so high that the minimum RTCP interval is 539 reached.) For further simplification, we can assume RTCP senders are 540 following the recommendations regarding Compound RTCP Packets in 541 [I-D.ietf-avtcore-rtp-multi-stream]; thus, the per-packet transport- 542 layer overhead will be small relative to the RTCP data. Thus, only 543 the actual RTCP data itself need be considered. 545 In a report interval in this scenario, there will, as a baseline, be 546 200 SDES packets, 184 RR packets, and 16 SR packets. This amounts to 547 approximately 6.5 kB of RTCP per report interval, assuming 16-byte 548 CNAMEs and no other SDES information. 550 Using the original [RFC3550] everyone-reports-on-every-sender 551 feedback rules, each of the 184 receivers will send 16 report blocks, 552 and each of the 16 senders will send 15. This amounts to 553 approximately 76 kB of report block traffic per interval; 92% of RTCP 554 traffic consists of report blocks. 556 If reporting groups are used, however, there is only 0.4 kB of 557 reports per interval, with no loss of useful information. 558 Additionally, there will be (assuming 16-byte RGRPs, and a single 559 reporting source per reporting group) an additional 2.4 kB per cycle 560 of RGRP SDES items and RGRS packets. Put another way, the unmodified 561 [RFC3550] reporting interval is approximately 9 times longer than if 562 reporting groups are in use. 564 4.2. Compatibility of RTCP Reporting Groups 566 The RTCP traffic generated by receivers using RTCP Reporting Groups 567 might appear, to observers unaware of these semantics, to be 568 generated by receivers who are experiencing a network disconnection, 569 as the non-reporting sources appear not to be receiving a given 570 sender at all. 572 This could be a potentially critical problem for such a sender using 573 RTCP for congestion control, as such a sender might think that it is 574 sending so much traffic that it is causing complete congestion 575 collapse. 577 However, such an interpretation of the session statistics would 578 require a fairly sophisticated RTCP analysis. Any receiver of RTCP 579 statistics which is just interested in information about itself needs 580 to be prepared that any given reception report might not contain 581 information about a specific media source, because reception reports 582 in large conferences can be round-robined. 584 Thus, it is unclear to what extent such backward compatibility issues 585 would actually cause trouble in practice. 587 5. Security Considerations 589 The security considerations of [RFC3550] and 590 [I-D.ietf-avtcore-rtp-multi-stream] apply. If the RTP/AVPF profile 591 is in use, then the security considerations of [RFC4585] (and 592 [RFC5104], if used) also apply. If RTCP XR is used, the security 593 consideration of [RFC3611] and any XR report blocks used also apply. 595 The RTCP SDES RGRP item is vulnerable to malicious modifications 596 unless integrity protected is used. A modification of this item's 597 length field cause the parsing of the RTCP packet in which it is 598 contained to fail. Depending on the implementation, parsing of the 599 full compound RTCP packet can also fail causing the whole packet to 600 be discarded. A modification to the value of this SDES item would 601 make the receiver of the report think that the sender of the report 602 was a member of a different RTCP reporting group. This will 603 potentially create an inconsistency, when the RGRS reports the source 604 as being in the same reporting group as another source with another 605 reporting group identifier. What impact on a receiver implementation 606 such inconsistencies would have are difficult to fully predict. One 607 case is when congestion control or other adaptation mechanisms are 608 used, an inconsistent report can result in a media sender to reduce 609 its bit-rate. However, a direct modification of the receiver report 610 or a feedback message itself would be a more efficient attack, and 611 equally costly to perform. 613 The new RGRS RTCP Packet type is very simple. The common RTCP packet 614 type header shares the security risks with previous RTCP packet 615 types. Errors or modification of the length field can cause the full 616 compound packet to fail header validation (see Appendix A.2 in 617 [RFC3550]) resulting in the whole compound RTCP packet being 618 discarded. Modification of the SC or P fields would cause 619 inconsistency when processing the RTCP packet, likely resulting it 620 being classified as invalid. A modification of the PT field would 621 cause the packet being interpreted under some other packet type's 622 rules. In such case the result might be more or less predictable but 623 packet type specific. Modification of the SSRC of packet sender 624 would attribute this packet to another sender. Resulting in a 625 receiver believing the reporting group applies also for this SSRC, if 626 it exists. If it doesn't exist, unless also corresponding 627 modifications are done on a SR/RR packet and a SDES packet the RTCP 628 packet SHOULD be discarded. If consistent changes are done, that 629 could be part of a resource exhaustion attack on a receiver 630 implementation. Modification of the "List of SSRCs for the Reporting 631 Source(s)" would change the SSRC the receiver expect to report on 632 behalf of this SSRC. If that SSRC exist, that could potentially 633 change the report group used for this SSRC. A change to another 634 reporting group belonging to another endpoint is likely detectable as 635 there would be a mismatch between the SSRC of the packet sender's 636 endpoint information, transport addresses, SDES CNAME etc and the 637 corresponding information from the reporting group indicated. 639 In general the reporting group is providing limited impacts attacks. 640 The most significant result from an deliberate attack would be to 641 cause the information to be discarded or be inconsistent, including 642 discard of all RTCP packets that are modified. This causes a lack of 643 information at any receiver entity, possibly disregarding the 644 endpoints participation in the session. 646 To protect against this type of attacks from external non trusted 647 entities, integrity and source authentication SHOULD be applied. 648 This can be done, for example, by using SRTP [RFC3711] with 649 appropriate key-management, other options exist as discussed in RTP 650 Security Options [RFC7201]. 652 The Report Group Identifier has a potential privacy impacting 653 properties. If this would be generated by an implementation in such 654 a way that is long term stable or predictable, it could be used for 655 tracking a particular end-point. Therefore it is RECOMMENDED that it 656 be generated as a short-term persistent RGRP, following the rules for 657 short-term persistent CNAMEs in [RFC7022]. The rest of the 658 information revealed, i.e. the SSRCs, the size of reporting group and 659 the number of reporting sources in a reporting group is of less 660 sensitive nature, considering that the SSRCs and the communication 661 would anyway be revealed without this extension. By encrypting the 662 report group extensions the SSRC values would preserved confidential, 663 but can still be revealed if SRTP [RFC3711] is used. The size of the 664 reporting groups and number of reporting sources are likely 665 determinable from analysis of the packet pattern and sizes. However, 666 this information appears to have limited value. 668 6. IANA Considerations 670 (Note to the RFC-Editor: in the following, please replace "TBA" with 671 the IANA-assigned value, and "XXXX" with the number of this document, 672 then delete this note) 674 The IANA is requested to register one new RTCP SDES items in the 675 "RTCP SDES Item Types" registry, as follows: 677 Value Abbrev Name Reference 678 TBA RGRP Reporting Group Identifier [RFCXXXX] 680 The definition of the RTCP SDES RGRP item is given in Section 3.2.1 681 of this memo. 683 The IANA is also requested to register one new RTCP packet type in 684 the "RTCP Control Packet Types (PT)" Registry as follows: 686 Value Abbrev Name Reference 687 TBA RGRS Reporting Group Reporting Sources [RFCXXXX] 689 The definition of the RTCP RGRS packet type is given in Section 3.2.2 690 of this memo. 692 The IANA is also requested to register one new SDP attribute: 694 SDP Attribute ("att-field"): 695 Attribute name: rtcp-rgrp 696 Long form: RTCP Reporting Groups 697 Type of name: att-field 698 Type of attribute: Media or session level 699 Subject to charset: No 700 Purpose: Negotiate or configure the use of the RTCP 701 Reporting Group Extension. 702 Reference: [RFCXXXX] 703 Values: None 705 The definition of the "a=rtcp-rgrp" SDES attribute is given in 706 Section 3.6 of this memo. 708 7. References 710 7.1. Normative References 712 [I-D.ietf-avtcore-rtp-multi-stream] 713 Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, 714 "Sending Multiple RTP Streams in a Single RTP Session", 715 draft-ietf-avtcore-rtp-multi-stream-11 (work in progress), 716 December 2015. 718 [I-D.ietf-mmusic-sdp-mux-attributes] 719 Nandakumar, S., "A Framework for SDP Attributes when 720 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12 721 (work in progress), January 2016. 723 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 724 Requirement Levels", BCP 14, RFC 2119, 725 DOI 10.17487/RFC2119, March 1997, 726 . 728 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 729 with Session Description Protocol (SDP)", RFC 3264, 730 DOI 10.17487/RFC3264, June 2002, 731 . 733 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 734 Jacobson, "RTP: A Transport Protocol for Real-Time 735 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 736 July 2003, . 738 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 739 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 740 July 2006, . 742 [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, 743 "Guidelines for Choosing RTP Control Protocol (RTCP) 744 Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, 745 September 2013, . 747 7.2. Informative References 749 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 750 Streaming Protocol (RTSP)", RFC 2326, 751 DOI 10.17487/RFC2326, April 1998, 752 . 754 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 755 Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, 756 October 2000, . 758 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 759 "RTP Control Protocol Extended Reports (RTCP XR)", 760 RFC 3611, DOI 10.17487/RFC3611, November 2003, 761 . 763 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 764 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 765 RFC 3711, DOI 10.17487/RFC3711, March 2004, 766 . 768 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 769 "Extended RTP Profile for Real-time Transport Control 770 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 771 DOI 10.17487/RFC4585, July 2006, 772 . 774 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 775 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 776 DOI 10.17487/RFC4588, July 2006, 777 . 779 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 780 "Codec Control Messages in the RTP Audio-Visual Profile 781 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 782 February 2008, . 784 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 785 Real-Time Transport Control Protocol (RTCP): Opportunities 786 and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 787 2009, . 789 [RFC6190] Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 790 "RTP Payload Format for Scalable Video Coding", RFC 6190, 791 DOI 10.17487/RFC6190, May 2011, 792 . 794 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 795 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 796 . 798 Authors' Addresses 800 Jonathan Lennox 801 Vidyo, Inc. 802 433 Hackensack Avenue 803 Seventh Floor 804 Hackensack, NJ 07601 805 US 807 Email: jonathan@vidyo.com 809 Magnus Westerlund 810 Ericsson 811 Farogatan 2 812 SE-164 80 Kista 813 Sweden 815 Phone: +46 10 714 82 87 816 Email: magnus.westerlund@ericsson.com 818 Qin Wu 819 Huawei 820 101 Software Avenue, Yuhua District 821 Nanjing, Jiangsu 210012 822 China 824 Email: bill.wu@huawei.com 826 Colin Perkins 827 University of Glasgow 828 School of Computing Science 829 Glasgow G12 8QQ 830 United Kingdom 832 Email: csp@csperkins.org