idnits 2.17.1 draft-ietf-straw-b2bua-rtcp-17.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 (December 22, 2016) is 2682 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Downref: Normative reference to an Informational RFC: RFC 7656 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 STRAW Working Group L. Miniero 3 Internet-Draft Meetecho 4 Intended status: Standards Track S. Garcia Murillo 5 Expires: June 25, 2017 Medooze 6 V. Pascual 7 Oracle 8 December 22, 2016 10 Guidelines to support RTCP end-to-end in Back-to-Back User Agents 11 (B2BUAs) 12 draft-ietf-straw-b2bua-rtcp-17 14 Abstract 16 SIP Back-to-Back User Agents (B2BUAs) are often designed to also be 17 on the media path, rather than just intercepting signalling. This 18 means that B2BUAs often implement an RTP/RTCP stack as well, thus 19 leading to separate multimedia sessions that the B2BUA correlates and 20 bridges together. If not disciplined, though, this behaviour can 21 severely impact the communication experience, especially when 22 statistics and feedback information contained in RTCP messages get 23 lost because of mismatches in the reported data. 25 This document defines the proper behaviour B2BUAs should follow when 26 also acting on the signalling/media plane in order to preserve the 27 end-to-end functionality of RTCP. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on June 25, 2017. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Signalling/Media Plane B2BUAs . . . . . . . . . . . . . . . . 4 66 3.1. Media Relay . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Media-aware Relay . . . . . . . . . . . . . . . . . . . . 6 68 3.3. Media Terminator . . . . . . . . . . . . . . . . . . . . 11 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 7. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 13 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 76 9.2. Informative References . . . . . . . . . . . . . . . . . 18 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 79 1. Introduction 81 Session Initiation Protocol [RFC3261] Back-to-Back User Agents 82 (B2BUAs) are SIP entities that can act as a logical combination of 83 both a User Agent Server (UAS) and a User Agent Client (UAC). As 84 such, their behaviour is not always completely adherent to the 85 standards, and can lead to unexpected situations. [RFC7092] presents 86 a taxonomy of the most commonly deployed B2BUA implementations, 87 describing how they differ in terms of the functionality and features 88 they provide. 90 Such components often do not only act on the signalling plane, that 91 is intercepting and possibly modifying SIP messages, but also on the 92 media plane. This means that, in order to receive and manage all RTP 93 and RTCP [RFC3550] packets in a session, these components also 94 manipulate the session descriptions [RFC4566] in the related offer/ 95 answer exchanges [RFC3264]. The reasons for such a behaviour can be 96 different. The B2BUA may want, for instance, to provide transcoding 97 functionality for participants with incompatible codecs, or it may 98 need the traffic to be directly handled for different reasons. This 99 can lead to several different topologies for RTP-based communication, 100 as documented in [RFC7667]. 102 Whatever the reason, such a behaviour does not come without a cost. 103 In fact, whenever a media-aware component is placed on the path 104 between two or more participants that want to communicate by means of 105 RTP/RTCP, the end-to-end nature of such protocols is broken. While 106 this may not be a problem for RTP packets, which can be quite easily 107 relayed, it definitely can cause serious issue for RTCP messages, 108 which carry important information and feedback on the communication 109 quality the participants are experiencing. Consider, for instance, 110 the simple scenario only involving two participants and a single RTP 111 session depicted in Figure 1: 113 +--------+ +---------+ +---------+ 114 | |=== SSRC1 ===>| |=== SSRC3 ===>| | 115 | Alice | | B2BUA | | Bob | 116 | |<=== SSRC2 ===| |<=== SSRC4 ===| | 117 +--------+ +---------+ +---------+ 119 Figure 1: B2BUA modifying RTP headers 121 In this common scenario, a participant (Alice) is communicating with 122 another participant (Bob) as a result of a signalling session managed 123 by a B2BUA: this B2BUA is also on the media path between the two, and 124 is acting as a media relay. This means that two separate RTP 125 sessions are involved (one per side), each carrying two RTP streams 126 (one per media direction). As part of this process, though, the 127 B2BUA is also rewriting some of the RTP header information on the 128 way. In this example, just the SSRC of the incoming RTP streams is 129 changed, but more information may be modified as well (e.g., sequence 130 numbers, timestamps, etc.). In particular, whenever Alice sends an 131 RTP packet, she sets her SSRC (SSRC1) in the RTP header of her RTP 132 source stream. The B2BUA rewrites the SSRC (SSRC3) before relaying 133 the packet to Bob. At the same time, RTP packets sent by Bob (SSRC4) 134 get their SSRC rewritten as well (SSRC2) before being relayed to 135 Alice. 137 Assuming now that Alice needs to inform Bob she has lost several 138 packets in the last few seconds, she will place the related received 139 RTP stream SSRC she is aware of (SSRC2), together with her own 140 (SSRC1), in RTCP Reports and/or NACKs. Since the B2BUA is making use 141 of different SSRCs for the RTP streams in the RTP session it 142 established with each participant, blindly relaying Alice's incoming 143 RTCP messages to Bob would cause issues. These RTCP messages would 144 reference SSRCs Bob doesn't know about, which would result in 145 precious feedback being dropped. In fact, Bob is only aware of SSRCs 146 SSRC4 (the one his source RTP stream uses) and SSRC3 (the one he's 147 receiving from the B2BUA in the received RTP stream), and knows 148 nothing about SSRCs SSRC1 and SSRC2 in the messages he received 149 instead. Considering the feedback being dropped because of this may 150 contain precious information, e.g., related to packet loss, 151 congestion, and other network issues or considerations, the inability 152 to take them into account may lead to severe issues. For instance, 153 Bob may flood Alice with more media packets she can handle, and/or 154 not retransmit Alice the packets she missed and asked for. This may 155 easily lead to a very bad communication experience, if not eventually 156 to an unwanted termination of the communication itself. 158 This is just a trivial example that, together with additional 159 scenarios, will be addressed in the following sections. 160 Nevertheless, it is a valid example of how such a simple mishandling 161 of precious information may lead to serious consequences. This is 162 especially true if we picture more complex scenarios involving 163 several participants at the same time, multiple RTP sessions (e.g., a 164 video stream along audio) rather than a single one, redundancy RTP 165 streams, SSRC multiplexing and so on. Considering how common B2BUA 166 deployments are, it is very important for them to properly address 167 RTCP messages, in order to be sure that their activities on the media 168 plane do not break or interfere with anything relevant to the 169 session. 171 2. Terminology 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in [RFC2119]. 177 Besides, this document addresses, where relevant, the RTP-related 178 terminology as disciplined in [RFC7656]. 180 3. Signalling/Media Plane B2BUAs 182 As described in the introductory section, it's very common for B2BUA 183 deployments to also act on the media plane, rather than just 184 signalling alone. In particular, [RFC7092] describes three different 185 categories of such B2BUAs: a B2BUA, in fact, may act as a simple 186 media relay (1), effectively unaware of anything that is transported; 187 it may be a media-aware relay (2), also inspecting and/or modifying 188 RTP and RTCP messages as they flow by; or it may be a full-fledged 189 media termination entity (3), terminating and generating RTP and RTCP 190 messages as needed. 192 [RFC3550] and [RFC7667] already mandate some specific behaviours in 193 the presence of certain topologies. Anyway, due to their mixed 194 nature B2BUAs sometimes can't or won't implement all relevant 195 specifications. This means that it's not rare to encounter issues 196 that may be avoided with a more disciplined behaviour in that regard, 197 that is if the B2BUAs followed at least a set of guidelines to ensure 198 no known problems occur. For this reason, the following subsections 199 will describe the proper behaviour B2BUAs, whatever above category 200 they fall in, should follow in order not to impact any end-to-end 201 RTCP effectiveness. 203 3.1. Media Relay 205 A media relay, as identified in [RFC7092], simply forwards all RTP 206 and RTCP messages it receives, without either inspecting or modifying 207 them. Using the RTP Topologies terminology, this can be seen as a 208 RTP Transport Translator. As such, B2BUA acting as media relays are 209 not aware of what traffic they're handling. This means that both 210 packet payloads and packet headers are opaque to them. Many Session 211 Border Controllers (SBC) implement this kind of behaviour, e.g., when 212 acting as a bridge between an inner and outer network. 214 Considering all headers and identifiers in both RTP and RTCP are left 215 untouched, issues like the SSRC mismatch described in the previous 216 section would not occur. Similar problems could still happen, 217 though, for different reasons, as for instance if the session 218 description prepared by the B2BUA, whether it has been modified or 219 not, ends up providing incorrect information. This may happen, for 220 example, if the SDP on either side contains 'ssrc' [RFC5576] 221 attributes that don't match the actual SSRC being advertized on the 222 media plane, or when the B2BUA advertized support for NACK because it 223 implements it, while the original INVITE didn't. Such issues might 224 occur, for instance, when the B2BUA acting as a media relay is 225 generating a new session description when bridging an incoming call, 226 rather than using the original session description. This may cause 227 participants to find a mismatch between the SSRCs advertized in the 228 SDP and the ones actually observed in RTP and RTCP messages, or to 229 have them either ignore or generate RTCP feedback packets that were 230 not explicitly advertized as supported. 232 In order to prevent such an issue, a media-relay B2BUA SHOULD forward 233 all the SSRC- and RTCP-related SDP attributes when handling a 234 multimedia session setup between participants: this includes 235 attributes like 'ssrc' [RFC3261], 'rtcp-fb' [RFC4585], 'rtcp-xr- 236 attrib' [RFC3611] and others. However, certain SDP attributes may 237 lead to call failures when forwarded by a media relay, as they have 238 an implied assumption that the attribute describes the immediate 239 peer. A clear example of this is the 'rtcp' [RFC3605] attribute, 240 which describes the expected RTCP peer port. Other attributes might 241 include the immediate peer's IP address, preferred transport, etc. 242 In general, the guideline is to require rewriting of attributes that 243 are implicitly describing the immediate peer. B2BUAs SHOULD forward 244 all other SDP attributes in order to avoid breaking additional 245 functionality endpoints may be relying on. If implementors have 246 doubts about whether this guidance applies to a specific attribute, 247 they should test to determine if call failures occur. 249 The cited 'rtcp' example is also relevant whenever RTP/RTCP 250 multiplexing [RFC5761] support is being negotiated. If the B2BUA 251 acting as a Media Relay is unaware of the specifics of the traffic it 252 is handling, and as such may not have RTP/RTCP parsing capabilities, 253 it SHOULD reject RTP/RTCP multiplexing by removing the 'rtcp-mux' SDP 254 attribute. If instead the Media Relay is able to parse RTP/RTCP, and 255 can verify that demultiplexing can be performed without any RTP 256 Payload Type rewrites (i.e., no overlap between any RTP Payload Types 257 and the RTCP Payload Type space has been detected), then the B2BUA 258 SHOULD negotiate RTP/RTCP multiplexing support if advertized. 260 It is worth mentioning that, leaving RTCP messages untouched, a media 261 relay may also leak information that, according to policies, may need 262 to be hidden or masqueraded, e.g., domain names in CNAME items. 263 Besides, these CNAME items may actually contain IP addresses: this 264 means that, should a NAT be involved in the communication, this may 265 actually result in CNAME collisions, which could indeed break the 266 end-to-end RTCP behaviour. While [RFC7022] can prevent this from 267 happening, there may be implementations that don't make use of it. 268 As such, a B2BUA MAY rewrite CNAME items if any potential collision 269 is detected, even in the Media Relay case. If a B2BUA does indeed 270 decide to rewrite CNAME items, though, then it MUST generate new 271 CNAMEs following [RFC7022]. The same SHOULD be done in case RTP 272 extensions involving CNAMEs are involved (e.g., "urn:ietf:params:rtp- 273 hdrext:sdes:cname", [RFC7941]). If that is not possible, e.g., 274 because the Media Relay does not have RTP header editing capabilities 275 or does not support these extensions, then the B2BUA MUST reject the 276 negotiation of such extensions when negotiating the session. 278 3.2. Media-aware Relay 280 A Media-aware relay, unlike the the Media Relay addressed in the 281 previous section, is aware of the media traffic it is handling. This 282 means it inspects RTP and RTCP messages flowing by, and may even 283 modify their headers. Using the RFC3550 terminology, this can be 284 seen as a RTP Translator. A B2BUA implementing this role, though, 285 typically does not inspect the RTP payloads, which would be opaque to 286 them: this means that the actual media would not be manipulated (e.g, 287 transcoded). 289 This makes them quite different from the Media Relay previously 290 discussed, especially in terms of the potential issues that may occur 291 at the RTCP level. In fact, being able to modify the RTP and RTCP 292 headers, such B2BUAs may end up modifying RTP related information 293 like SSRC/CSRC, sequence numbers, timestamps and others in an RTP 294 stream, before forwarding the modified packets to the other 295 interested participants. This means that, if not properly 296 disciplined, such a behaviour may easily lead to issues like the one 297 described in the introductory section. For this reason, it is very 298 important for a B2BUA modifying RTP-related information across two 299 related RTP streams to also modify, in a coherent way, the same 300 information in RTCP messages. 302 It is worthwile to point out that such a B2BUA may not necessarily 303 forward all the packets it receives, though. Selective Forwarding 304 Units (SFU) [RFC7667], for instance, may be implemented to aggregate 305 or drop incoming RTCP messages, while at the same time originating 306 new ones on their own. It is important to clarify that a B2BUA 307 SHOULD NOT randomly drop or forward RTCP feedback of the same type 308 (e.g., a specific XR block type, or specific Feedback messages) 309 within the context of the same session, as that may lead to 310 confusing, if not broken, feedback to the recipients of the message 311 due to gaps in the communication. As to the messages that are 312 forwarded and/or aggregated, though, it's important to make sure the 313 information is coherent. 315 Besides the behaviour already mandated for RTCP translators in 316 Section 7.2 of [RFC3550], a media-aware B2BUA MUST handle incoming 317 RTCP messages to forward following this guideline: 319 SR: [RFC3550] 320 If the B2BUA has changed the SSRC of the sender RTP stream a 321 Sender Report refers to, it MUST update the SSRC in the SR packet 322 header as well. If the B2BUA has changed the SSRCs of other RTP 323 streams too, and any of these streams are addressed in any of the 324 SR report blocks, it MUST update the related values in the SR 325 report blocks as well. If the B2BUA has also changed the base RTP 326 sequence number when forwarding RTP packets, then this change MUST 327 be reflected in the 'extended highest sequence number received' 328 field in the Report Blocks. In case the B2BUA is acting as a 329 Selective Forwarding Units (SFU) [RFC7667], it needs to track in 330 the outgoing SR the relevant number of packets sent and total 331 amount of bytes sent to the receiver. 333 RR: [RFC3550] 334 The same guidelines given for SR apply for RR as well. 336 SDES: [RFC3550] 337 If the B2BUA has changed the SSRC of any RTP stream addressed in 338 any of the chunks of an incoming SDES message, it MUST update the 339 related SSRCs in all the chunks. The same considerations made 340 with respect to CNAME collisions at the end of Section 3.1 apply 341 here as well. 343 BYE: [RFC3550] 344 If the B2BUA has changed the SSRC of any RTP stream addressed in 345 the SSRC/CSRC identifiers included in a BYE packet, it MUST update 346 them in the message. 348 APP: [RFC3550] 349 If the B2BUA has changed the SSRC of any RTP stream addressed in 350 the header of an APP packet, it MUST update the identifier in the 351 message. Should the B2BUA be aware of any specific APP message 352 format that contains additional information related to SSRCs, it 353 SHOULD update them as well accordingly. 355 Extended Reports (XR): [RFC3611] 356 If the B2BUA has changed the SSRC of the RTP stream associated 357 with the originator of an XR packet, it MUST update the SSRC in 358 the XR message header. The same guidelines given for SR/RR, with 359 respect to SSRC identifiers in report blocks, apply for all the 360 Report Block types in the XR message as well. If the B2BUA has 361 also changed the base RTP sequence number when forwarding RTP 362 packets, then this change MUST be reflected in the 'begin_seq' and 363 'end_seq' fields that are available in most of the Report Block 364 types that are part of the XR specification. 366 Receiver Summary Information (RSI): [RFC5760] 367 If the B2BUA has changed any SSRC of RTP streams addressed in a 368 RSI packet, it MUST update the SSRC identifiers in the message. 369 This includes the distribution source SSRC, which MUST be 370 rewritten with the one the B2BUA uses to send RTP packets to each 371 sender participant, the summarized SSRC and, when a Collision Sub- 372 Report Block is available, the SSRCs in the related list. 374 Port Mapping (TOKEN): [RFC6284] 375 If the B2BUA has changed any SSRC of RTP streams addressed in a 376 TOKEN packet, it MUST update the SSRC identifiers in the message. 377 This includes the Packet Sender SSRC, which MUST be rewritten with 378 the one the B2BUA uses to send RTP packets to each sender 379 participant, and the Requesting Client SSRC when the message is a 380 response, which MUST be rewritten using the related sender 381 participant(s) SSRC. 383 Feedback messages: [RFC4585] 384 All Feedback messages have a common packet format, which includes 385 the SSRC identifier of the packet sender and the SSRC identifier 386 of the media source the feedack is related to. Just as described 387 for the previous messages, these SSRC identifiers MUST be updated 388 in the message if the B2BUA has changed the SSRC of the RTP 389 streams addressed there. It MUST NOT, though, change a media 390 source SSRC that was originally set to zero, unless zero is 391 actually the SSRC that was chosen by one of the involved 392 endpoints, in which case the above mentioned rules as to SSRC 393 rewriting apply. Considering that many feedback messages also 394 include additional data as part of their specific Feedback Control 395 Information (FCI), a media-aware B2BUA MUST take care of them 396 accordingly, if it can parse and regenerate them, according to the 397 following guidelines: 399 NACK: [RFC4585] 400 A media-aware B2BUA MUST properly rewrite the Packet ID (PID) 401 of all addressed lost packets in the NACK FCI if it changed the 402 RTP sequence numbers. 404 TMMBR/TMMBN/FIR/TSTR/TSTN/VBCM: [RFC5104] 405 A media-aware B2BUA MUST properly rewrite the additional SSRC 406 identifier in the specific FCI, if it changed the related RTP 407 SSRC of the media sender. 409 REMB: [I-D.alvestrand-rmcat-remb] 410 This draft describes an RTCP Payload-Specific feedback message 411 that reports the receiver's available bandwidth to the the 412 sender. As of the time of this writing, REMB has been widely 413 deployed, but has not been standardized. The REMB mechanism 414 will not function correctly across a media-aware B2BUA that 415 changes the SSRC of the media sender unless it also changes the 416 SSRC values in the REMB packet. 418 Explicit Congestion Notification (ECN): [RFC6679] 419 The same guidelines given for SR/RR management apply, 420 considering the presence of sequence numbers in the ECN 421 Feedback Report format. For what concerns the management of 422 RTCP XR ECN Summary Report messages, the same guidelines given 423 for generic XR messages apply. 425 Apart from the generic guidelines related to Feedback messages, no 426 additional modifications are needed for PLI, SLI and RPSI feedback 427 messages. 429 Of course, the same considerations about the need for SDP and RTP/ 430 RTCP information to be coherent applies to media-aware B2BUAs. This 431 means that, if a B2BUA changes any SSRC, it MUST update the related 432 'ssrc' attributes, if present, before sending it to the recipient. 433 Besides, it MUST rewrite the 'rtcp' attribute if provided. At the 434 same time, while a media-aware B2BUA is typically able to inspect/ 435 modify RTCP messages, it may not support all RTCP messages. This 436 means that a B2BUA may choose to drop RTCP messages it can't parse. 437 In that case, a media-aware B2BUA MUST advertize its RTCP level of 438 support in the SDP in a coherent way, in order to prevent, for 439 instance, a UAC to from sending NACK messages that would never reach 440 the intended recipients. It's important to point out that, in case a 441 compound RTCP packet was received and any RTCP message in it needs to 442 be dropped, then the B2BUA SHOULD NOT drop the whole compound RTCP 443 packet, but only the selected messages. 445 The same considerations on CNAMEs made when talking of Media Relays 446 apply for Media-aware Relays as well. Specifically, if RTP 447 extensions involving CNAMEs are involved (e.g., "urn:ietf:params:rtp- 448 hdrext:sdes:cname", [RFC7941]) and negotiated because the B2BUA 449 supports them, then the B2BUA MUST update the CNAME value in there as 450 well, if it was changed. It is worth pointing out that, if the new 451 CNAME is larger than the old one, this would result in a larger RTP 452 packet than originally received. If the length of the updated packet 453 exceeds the MTU of any of the networks the packet will traverse, this 454 can result in the packet being dropped and lost by the recipient. 456 A different set of considerations is worthwhile for what concerns 457 RTP/RTCP multiplexing [RFC5761] and Reduced-Size RTCP [RFC5506]. 458 While the former allows for a better management of network resources 459 by multiplexing RTP packets and RTCP messages over the same 460 transport, the latter allows for a compression of RTCP messages, thus 461 leading to less network traffic. For what concerns RTP/RTCP 462 multiplexing, a B2BUA acting as a Media Relay may use it on either 463 RTP session independently. This means that, for instance, a Media 464 Relay B2BUA may use RTP/RTCP multiplexing on one side of the 465 communication, and not use it on the other side, if the endpoint does 466 not support it. This allows for a better management of network 467 resources on the side that does support it. In case any of the 468 parties in the communications supports it and the B2BUA does too, the 469 related 'rtcp-mux' SDP attribute MUST be forwarded on the other 470 side(s). If the B2BUA detects that any of the parties in the 471 communication do not support the feature, it may decide to either 472 disable it entirely or still advertize it for the RTP sessions with 473 parties that do support it. In case the B2BUA decides to involve 474 RTP/RTCP multiplexing, it MUST ensure that there are no conflicting 475 RTP payload type numbers on either side. When there are, it MUST 476 rewrite RTP payload type numbers to prevent conflicts in the session 477 where the RTP/RTCP multiplexing is applied. Should RTP payload types 478 be rewritten, the related information in the SDP MUST be updated 479 accordingly. 481 For what concerns Reduced-Size RTCP, instead, the considerations are 482 a bit different. In fact, while a Media Relay B2BUA may choose to 483 use it on the side that supports it and not on the side that doesn't, 484 there are several reasons for discouraging such a behaviour. While 485 Reduced-Size allows indeed for less network traffic related to RTCP 486 messaging in general, this gain may lead a Reduced-Size RTCP 487 implementation to also issue a higher rate of RTCP feedback messages. 488 This would result in an increased RTCP traffic on the side that does 489 not support Reduced-Size, and could as a consequence be actually 490 counterproductive if the available bandwidth is different on the two 491 sides. Negotiating a session with both sides would allow the B2BUA 492 to discover which one supports Reduced-Size and which doesn't, and in 493 case decide whether to allow the sides to independently use Reduced- 494 Size or not. Should the B2BUA decide to disable the feature on all 495 sides, which is suggested in case Reduced-Size is not supported by 496 all parties involved, it MUST NOT advertize support for the Reduced- 497 Size RTCP functionality on either side, by removing the 'rtcp-rsize' 498 attribute from the SDP. 500 3.3. Media Terminator 502 A Media Terminator B2BUA, unlike simple relays and media-aware ones, 503 is also able to terminate media itself. As such, it can inspect and/ 504 or modify RTP payloads as well. This means that such components, for 505 instance, can act as media transcoders and/or originate specific RTP 506 media. Using the RTP Topologies terminology, this can be seen as a 507 RTP Media Translator. Such a topology can also be seen as a Back-to- 508 back RTP sessions through a Middlebox, as described in Section 3.2.2 509 of [RFC7667]. Such a capability makes them quite different from the 510 previously introduced B2BUA typologies. Since such a B2BUA would 511 terminate RTP itself, it can take care of the related statistics and 512 feedback functionality directly, with no need to simply relay any 513 message between the participants in the multimedia session. 515 For this reason, no specific guideline is needed to ensure a proper 516 end-to-end RTCP behaviour in such scenarios, mostly because most of 517 the times there would be no end-to-end RTCP interaction among the 518 involved participants in the first place. Nevertheless, should any 519 RTCP message actually need to be forwarded to another participant in 520 the multimedia session, the same guidelines provided for the media- 521 aware B2BUA case apply. 523 For what concerns RTP/RTCP multiplexing support, the same 524 considerations already given for the Media Relay management also 525 apply for a Media Terminator. Some different considerations might be 526 given as to the Reduced-Size RTCP functionality, instead. In fact, 527 in the Media Terminator case it is safe to use the feature 528 independently on each side, as the B2BUA would terminate RTCP. In 529 that case, the B2BUA SHOULD advertize and negotiate support for 530 Reduced-Size if available, and MUST NOT otherwise. 532 4. IANA Considerations 534 This document makes no request of IANA. 536 5. Security Considerations 538 The discussion made in the previous sections on the management of 539 RTCP messages by a B2BUA worked under the assumption that the B2BUA 540 has actually access to the RTP/RTCP information itself. This is 541 indeed true if we assume that plain RTP and RTCP is being handled, 542 but may not be once any security is enforced on RTP packets and RTCP 543 messages by means of SRTP [RFC3711]. 545 While typically not an issue in the Media Relay case, where RTP and 546 RTCP packets are forwarded without any modification no matter whether 547 security is involved or not, this could definitely have an impact on 548 Media-aware Relays and Media Terminator B2BUAs. To make a simple 549 example, if we envisage a SRTP/SRTCP session across a B2BUA, where 550 the B2BUA itself has no access to the keys used to secure the 551 session, there would be no way to manipulate SRTP headers without 552 violating the hashing on the packet. At the same time, there would 553 be no way to rewrite the RTCP information accordingly either. 555 For this reason, it is important to point out that the operations 556 described in the previous sections are only possible if the B2BUA has 557 a way to effectively manipulate the packets and messages flowing by. 558 This means that, when media security is involved, only the Media- 559 unaware Relay scenario can be properly addressed. Attempting to 560 cover Media-aware Relay and Media Termination scenarios when 561 involving secure sessions will inevitably lead to the B2BUA acting as 562 a man-in-the-middle, and consequently its behaviour is unspecified 563 and discouraged. More considerations on this are provided in 564 [RFC7879]. 566 It is also worth pointing out that there are scenarios where an 567 improper management of RTCP messaging across a B2BUA may lead, 568 willingly or not, to situations not unlike an attack. To make a 569 simple example, an improper management of a REMB feedback message 570 containing, e.g., information on the limited bandwidth availability 571 for a user, may lead to missing or misleading information to its 572 peer. This may cause the peer to increase the encoder bitrate, maybe 573 up to a point where a user with poor connectivity will inevitably be 574 choked by an amount of data it cannot process. This scenario may 575 thus result in what looks like a Denial of Service (DOS) attack 576 towards the user. 578 6. IANA Considerations 580 This document has no IANA actions. 582 7. Change Summary 584 Note to RFC Editor: Please remove this whole section. 586 The following are the major changes between the 16 and the 17 587 versions of the draft: 589 o Clarified the meaning of a sentence. 591 The following are the major changes between the 14 and the 15 592 versions of the draft: 594 o Several changes addressing the IESG review (list follows). 596 o Addressed 'rtcp-mux' in 3.1 as well, and not only 3.2. 598 o Clarified that, if CNAMEs are rewritten, RTP extensions 599 referencing them (e.g., [RFC7941]) should be updated too. 600 Clarified that MTU issues can occur if the rewriting results in a 601 larger RTP packet. 603 o Clarified that when handling SR packets, the an SFU B2BUA must 604 track packets/bytes sent. 606 o Removed references to billing, lawful interception, etc. from the 607 intro. 609 o Moved some references (especially those affected by MUSTs in 3.2) 610 to Normative. 612 o Rewritten the "Such attributes SHOULD NOT be forwarded" section to 613 clarify the context of the attributes that may lead to a failure 614 if not taken care of. 616 o Clarified that randomly dropping RTCP packets can lead to 617 confusion on the recipient. 619 o Updated text related to REMB. 621 o Smaller fixes here and there. 623 The following are the major changes between the 13 and the 14 624 versions of the draft: 626 o Removed first paragraph of Security Considerations which was 627 unclear. 629 o Added an IANA Considerations section to clarify there are no 630 actions. 632 The following are the major changes between the 12 and the 13 633 versions of the draft: 635 o Updated authors' affiliations and mail addresses. 637 The following are the major changes between the 11 and the 12 638 versions of the draft: 640 o Addressed remaining points in Ben's second review. 642 o Updated reference of STRAW's DTLS-SRTP draft to new [RFC7879]. 644 The following are the major changes between the 10 and the 11 645 versions of the draft: 647 o Addressed Ben's second review. 649 The following are the major changes between the 09 and the 10 650 versions of the draft: 652 o Replaced references to obsoleted RFC 5117 with [RFC7667]. 654 o Made reference to [RFC7656] normative. 656 o Clarified text across the whole document to address Ben's review. 658 The following are the major changes between the 08 and the 09 659 versions of the draft: 661 o Updated references to documents which have become RFC in the 662 meanwhile, [RFC7667] and [RFC7656]. 664 The following are the major changes between the 06 and the 07 665 versions of the draft: 667 o Clarified the suggested changed by Colin Perkins on the management 668 of CNAME items in SDES, and added reference to [RFC7022]. 670 o Addressed comment by Simon Perreault on CNAME collisions 671 management. 673 The following are the major changes between the 05 and the 06 674 versions of the draft: 676 o Addressed comment by Colin Perkins on the management of CNAME 677 items in SDES. 679 The following are the major changes between the 04 and the 05 680 versions of the draft: 682 o Clarified behaviour when SSRC is zero. 684 o Fixed a couple of nits found by the Idnits tool. 686 The following are the major changes between the 03 and the 04 687 versions of the draft: 689 o Addressed review by Magnus Westerlund. 691 o Added guidelines for ECN RTCP messages. 693 o Clarified that if an RTCP message is dropped because unsupported, 694 only the unsupported packet is dropped and not the compound packet 695 that contains it. 697 o Added reference to Section 3.2.2 of [RFC7667] to Section 3.3. 699 o Added considerations on RTP/RTCP multiplexing and Reduced-Size 700 RTCP. 702 The following are the major changes between the 02 and the 03 703 versions of the draft: 705 o Rephrased the Media Path Security section to take into account the 706 MITM-related discussion in Honolulu. 708 o Added some Security Considerations. 710 The following are the major changes between the 01 and the 02 711 versions of the draft: 713 o Updated terminology to better adhere to [RFC7656]. 715 o Rephrased the Media Path Security section to take into account the 716 MITM-related discussion in Toronto. 718 o Clarified that NACK management might be trickier when SRTP is 719 involved. 721 The following are the major changes between the 00 and the 01 722 versions of the draft: 724 o Updated references and mapping per taxonomy RFC (7092). 726 o Added a reference to RTP topologies, and tried a mapping as per- 727 discussion in London. 729 o Added more RTCP message types to the Media-Aware section. 731 o Clarified that fixing the 'rtcp' SDP attribute is important. 733 o Added a new section on the impact of media security. 735 8. Acknowledgements 737 The authors would like to thank Flavio Battimo and Pierluigi Palma 738 for their invaluable feedback in the early stages of the document. 739 The authors would also like to thank Colin Perkins, Bernard Aboba, 740 Albrecht Schwarz, Hadriel Kaplan, Keith Drage, Jonathan Lennox, 741 Stephen Farrell, Magnus Westerlund, Simon Perreault and Ben Campbell 742 for their constructive comments, suggestions, and reviews that were 743 critical to the formulation and refinement of this document. 745 9. References 747 9.1. Normative References 749 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 750 Requirement Levels", BCP 14, RFC 2119, 751 DOI 10.17487/RFC2119, March 1997, 752 . 754 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 755 A., Peterson, J., Sparks, R., Handley, M., and E. 756 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 757 DOI 10.17487/RFC3261, June 2002, 758 . 760 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 761 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 762 July 2006, . 764 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 765 with Session Description Protocol (SDP)", RFC 3264, 766 DOI 10.17487/RFC3264, June 2002, 767 . 769 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 770 Jacobson, "RTP: A Transport Protocol for Real-Time 771 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 772 July 2003, . 774 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 775 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 776 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 777 DOI 10.17487/RFC7656, November 2015, 778 . 780 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 781 "Extended RTP Profile for Real-time Transport Control 782 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 783 DOI 10.17487/RFC4585, July 2006, 784 . 786 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 787 "RTP Control Protocol Extended Reports (RTCP XR)", 788 RFC 3611, DOI 10.17487/RFC3611, November 2003, 789 . 791 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 792 Protocol (RTCP) Extensions for Single-Source Multicast 793 Sessions with Unicast Feedback", RFC 5760, 794 DOI 10.17487/RFC5760, February 2010, 795 . 797 [RFC6284] Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping 798 between Unicast and Multicast RTP Sessions", RFC 6284, 799 DOI 10.17487/RFC6284, June 2011, 800 . 802 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 803 "Codec Control Messages in the RTP Audio-Visual Profile 804 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 805 February 2008, . 807 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 808 and K. Carlberg, "Explicit Congestion Notification (ECN) 809 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 810 2012, . 812 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 813 Control Packets on a Single Port", RFC 5761, 814 DOI 10.17487/RFC5761, April 2010, 815 . 817 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 818 Real-Time Transport Control Protocol (RTCP): Opportunities 819 and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 820 2009, . 822 [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, 823 "Guidelines for Choosing RTP Control Protocol (RTCP) 824 Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, 825 September 2013, . 827 [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 828 Header Extension for the RTP Control Protocol (RTCP) 829 Source Description Items", RFC 7941, DOI 10.17487/RFC7941, 830 August 2016, . 832 9.2. Informative References 834 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 835 Initiation Protocol (SIP) Back-to-Back User Agents", 836 RFC 7092, DOI 10.17487/RFC7092, December 2013, 837 . 839 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, 840 DOI 10.17487/RFC7667, November 2015, 841 . 843 [I-D.alvestrand-rmcat-remb] 844 Alvestrand, H., "RTCP message for Receiver Estimated 845 Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in 846 progress), October 2013. 848 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 849 Media Attributes in the Session Description Protocol 850 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 851 . 853 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 854 in Session Description Protocol (SDP)", RFC 3605, 855 DOI 10.17487/RFC3605, October 2003, 856 . 858 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 859 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 860 RFC 3711, DOI 10.17487/RFC3711, March 2004, 861 . 863 [RFC7879] Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V., 864 and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back 865 User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016, 866 . 868 Authors' Addresses 870 Lorenzo Miniero 871 Meetecho 873 Email: lorenzo@meetecho.com 875 Sergio Garcia Murillo 876 Medooze 878 Email: sergio.garcia.murillo@gmail.com 880 Victor Pascual 881 Oracle 883 Email: victor.pascual.avila@oracle.com