idnits 2.17.1 draft-ietf-straw-b2bua-rtcp-09.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 (April 11, 2016) is 2927 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) -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: October 13, 2016 Medooze 6 V. Pascual 7 Quobis 8 April 11, 2016 10 Guidelines to support RTCP end-to-end in Back-to-Back User Agents 11 (B2BUAs) 12 draft-ietf-straw-b2bua-rtcp-09 14 Abstract 16 SIP Back-to-Back User Agents (B2BUAs) are often envisaged 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, whether 19 to act as media transcoders or to just passthrough the media 20 themselves, thus leading to separate multimedia sessions that the 21 B2BUA correlates and bridges together. If not disciplined, though, 22 this behaviour can severely impact the communication experience, 23 especially when statistics and feedback information contained in RTCP 24 packets get lost because of mismatches in the reported data. 26 This document defines the proper behaviour B2BUAs should follow when 27 also acting on the signalling/media plane in order to preserve the 28 end-to-end functionality of RTCP. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on October 13, 2016. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Signalling/Media Plane B2BUAs . . . . . . . . . . . . . . . . 5 67 3.1. Media Relay . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.2. Media-aware Relay . . . . . . . . . . . . . . . . . . . . 6 69 3.3. Media Terminator . . . . . . . . . . . . . . . . . . . . 11 70 4. Media Path Security . . . . . . . . . . . . . . . . . . . . . 11 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 7. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 12 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 77 9.2. Informative References . . . . . . . . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 80 1. Introduction 82 Session Initiation Protocol [RFC3261] Back-to-Back User Agents 83 (B2BUAs) are SIP entities that can act as a logical combination of 84 both a User Agent Server (UAS) and a User Agent Client (UAC). As 85 such, their behaviour is not always completelely adherent to the 86 standards, and can lead to unexpected situations the IETF is trying 87 to address. [RFC7092] presents a taxonomy of the most deployed B2BUA 88 implementations, describing how they differ in terms of the 89 functionality and features they provide. 91 Such components often do not only act on the signalling plane, that 92 is intercepting and possibly modifying SIP messages, but also on the 93 media plane. This means that, when on the signalling path between 94 two or more participants willing to communicate, such components also 95 manipulate the session description [RFC4566] in order to have all RTP 96 and RTCP [RFC3550] pass through it as well within the context of an 97 SDP offer/answer [RFC3264]. The reasons for such a behaviour can be 98 different: the B2BUA may want, for instance, to provide transcoding 99 functionality for participants with incompatible codecs, or it may 100 need the traffic to be directly handled for different reasons like 101 billing, lawful interception, session recording and so on. This can 102 lead to several different topologies for RTP-based communication, as 103 documented in [RFC5117]. These topologies are currently being 104 updated to address new commonly encountered scenarios as well 105 [RFC7667]. 107 Whatever the reason, such a behaviour does not come without a cost. 108 In fact, whenever a media-aware component is placed on the path 109 between two or more participants that want to communicate by means of 110 RTP/RTCP, the end-to-end nature of such protocols is broken, and 111 their effectiveness may be affected as a consequence. While this may 112 not be a problem for RTP packets, which from a protocol point of view 113 just contain opaque media packets and as such can be quite easily 114 relayed, it definitely can cause serious issue for RTCP packets, 115 which carry important information and feedback on the communication 116 quality the participants are experiencing. In fact, RTCP packets 117 make use of specific ways to address the media they are referring to. 118 Consider, for instance, the simple scenario only involving two 119 participants and a single RTP session depicted in Figure 1: 121 +--------+ +---------+ +---------+ 122 | |=== SSRC1 ===>| |=== SSRC3 ===>| | 123 | Alice | | B2BUA | | Bob | 124 | |<=== SSRC2 ===| |<=== SSRC4 ===| | 125 +--------+ +---------+ +---------+ 127 Figure 1: B2BUA modifying RTP headers 129 In this common scenario, a participant (Alice) is communicating with 130 another participant (Bob) as a result of a signalling session managed 131 by a B2BUA: this B2BUA is also on the media path between the two, and 132 is acting as a media relay. This means that two separate RTP 133 sessions are involved (one per side), each carrying two RTP streams 134 (one per media direction). As part of this process, though, it is 135 also rewriting some of the RTP header information on the way, for 136 instance because that's how its RTP relaying stack works: in this 137 example, just the SSRC of the incoming RTP audio streams is changed, 138 but more information may be changed as well (e.g., sequence numbers, 139 timestamps, etc.). In particular, whenever Alice sends an audio RTP 140 packet, she sets her SSRC (SSRC1) to the RTP header of her RTP source 141 stream; the B2BUA rewrites the SSRC (SSRC3) before relaying the 142 packet to Bob. At the same time, RTP packets sent by Bob (SSRC4) get 143 their SSRC rewritten as well (SSRC2) before being relayed to Alice. 145 Assuming now that Alice needs to inform Bob she has lost several 146 audio packets in the last few seconds, maybe because of a network 147 congestion, she would of course place the related received RTP stream 148 SSRC she is aware of (SSRC2), together with her own (SSRC1), in RTCP 149 Reports and/or NACKS to do so, hoping for a retransmission [RFC4588] 150 or for Bob to slow down. Since the B2BUA is making use of different 151 SSRCs for the RTP streams in the RTP session it established with each 152 participant, a blind relaying of the RTCP packets to Bob would in 153 this case result, from Bob's perspective, in unknown SSRCs being 154 addressed, thus resulting in the precious information being dropped. 155 In fact, Bob is only aware of SSRCs SSRC4 (the one his source RTP 156 stream uses) and SSRC3 (the one he's receiving from the B2BUA in the 157 received RTP stream), and knows nothing about SSRCs SSRC1 and SSRC2 158 in the RTCP packets he would receive instead. As a consequence of 159 the feedback being dropped, unaware of the issue Bob may continue to 160 flood Alice with even more media packets and/or not retransmit Alice 161 the packets she missed, which may easily lead to a very bad 162 communication experience, if not eventually to an unwanted 163 termination of the communication itself. 165 This is just a trivial example that, together with additional 166 scenarios, will be addressed in the following sections. 167 Nevertheless, it is a valid example of how such a trivial mishandling 168 of precious information may lead to serious consequences, especially 169 considering that more complex scenarios may involve several 170 participants at the same time, multiple RTP sessions (e.g., a video 171 stream along audio) rather than a single one, redundancy RTP streams, 172 SSRC multiplexing and so on. Considering how common B2BUA 173 deployments are, it is very important for them to properly address 174 such feedback, in order to be sure that their activities on the media 175 plane do not break anything they're not supposed to. 177 2. Terminology 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in [RFC2119]. 183 Besides, this document addresses, where relevant, the RTP-related 184 terminology as disciplined in [RFC7656]. 186 3. Signalling/Media Plane B2BUAs 188 As anticipated in the introductory section, it's very common for 189 B2BUA deployments to also act on the media plane, rather than just 190 signalling alone. In particular, [RFC7092] describes three different 191 categories of such B2BUAs, according to the level of activities 192 performed on the media plane: a B2BUA, in fact, may act as a simple 193 media relay (1), effectively unaware of anything that is transported; 194 it may be a media-aware relay (2), also inspecting and/or modifying 195 RTP and RTCP packets as they flow by; or it may be a full-fledged 196 media termination entity, terminating and generating RTP and RTCP 197 packets as needed. 199 While [RFC3550] and [RFC5117] already mandate some specific 200 behaviours when specific topologies are deployed, not all deployments 201 strictly adhere to the specifications and as such it's not rare to 202 encounter issues that may be avoided with a more disciplined 203 behaviour in that regard. For this reason, the following subsections 204 will describe the proper behaviour B2BUAs, whatever above category 205 they fall in, should follow in order to avoid, or at least minimize, 206 any impact on end-to-end RTCP effectiveness. 208 3.1. Media Relay 210 A media relay as identified in [RFC7092] basically just forwards, 211 from an application level point of view, all RTP and RTP packets it 212 receives, without either inspecting or modifying them. Using the RTP 213 Topologies terminology, this can be seen as a RTP Transport 214 Translator. As such, B2BUA acting as media relays are not aware of 215 what traffic they're handling, meaning that not only the packet 216 payloads are opaque to them, but headers as well. Many Session 217 Border Controllers (SBC) implement this kind of behaviour, e.g., when 218 acting as a bridge between an inner and outer network. 220 Considering all headers and identifiers in both RTP and RTCP are left 221 untouched, issues like the SSRC mismatch described in the previous 222 section would not occur. Similar problems could occur, though, 223 should the session description end up providing incorrect information 224 about the media flowing (e.g., if the SDP on either side contain 225 'ssrc' [RFC5576] attributes that don't match the actual SSRC being 226 advertized on the media plane) or about the supported RTCP mechanisms 227 (e.g., in case the B2BUA advertized support for NACK because it 228 implements it, but the original INVITE didn't). Such an issue might 229 occur, for instance, in case the B2BUA acting as a media relay is 230 generating a new session description when bridging an incoming call, 231 rather than taking into account the original session description in 232 the first place. This may cause the participants to find a mismatch 233 between the SSRCs advertized in SDP and the ones actually observed in 234 RTP and RTCP packets (which may indeed change during a multimedia 235 session anyway, but having them synced during setup would help 236 nonetheless), or having them either ignore or generate RTCP feedback 237 packets that were not explicitly advertized as supported. 239 In order to prevent such an issue, a media-relay B2BUA SHOULD forward 240 all the SSRC- and RTCP-related SDP attributes when handling a 241 multimedia session setup between interested participants: this 242 includes attributes like 'ssrc' [RFC3261], 'rtcp-fb' [RFC4585], 243 'rtcp-xr-attrib' [RFC3611] and others. It SHOULD NOT, though, 244 blindly forward all SDP attributes, as some of them (e.g., 245 candidates, fingerprints, crypto, etc.) may lead to call failures for 246 different reasons out of scope to this document. One notable example 247 is the 'rtcp' [RFC3605] attribute that UAC may make use of to 248 explicitly state the port they're willing to use for RTCP: 249 considering the B2BUA would relay RTCP packets, the port as seen by 250 the other UAC involved in the communication would differ from the one 251 negotiated originally, and as such it MUST be rewritten accordingly. 253 It is worth mentioning that, leaving RTCP packets untouched, a media 254 relay may also let through information that, according to policies, 255 may be best left hidden or masqueraded, e.g., domain names in CNAME 256 items. Besides, these CNAME items may actually contain IP addresses 257 instead: this means that, should a NAT be involved in the 258 communication, this may actually result in CNAME collisions, which 259 could indeed break the end-to-end RTCP behaviour. While [RFC7022] 260 can prevent this from happening, there may be implementations that 261 don't make use of it. As such, a B2BUA MAY rewrite CNAME items if 262 any potential collision is detected, even in the Media Relay case. 263 If a B2BUA does indeed decide to rewrite CNAME items, though, then it 264 MUST generate new CNAMEs following [RFC7022]. 266 3.2. Media-aware Relay 268 A Media-aware relay, unlike the the Media Relay addressed in the 269 previous section, is actually aware of the media traffic it is 270 handling. As such, it is able to inspect RTP and RTCP packets 271 flowing by, and may even be able to modify the headers in any of them 272 before forwarding them. Using the RFC3550 terminology, this can be 273 seen as a RTP Translator. A B2BUA implementing this role would 274 typically not, though, inspect the RTP payloads as well, which would 275 be opaque to them: this means that the actual media would not be 276 manipulated (e.g, transcoded). 278 This makes them quite different from the Media Relay previously 279 discussed, especially in terms of the potential issues that may occur 280 at the RTCP level. In fact, being able to modify the RTP and RTCP 281 headers, such B2BUAs may end up modifying RTP related information 282 like SSRC (and hence CSRC lists, that must of course be updated 283 accordingly), sequence numbers, timestamps and the like in an RTP 284 stream, before forwarding the modified packets to the other 285 interested participants in the multimedia sessions on the RTP streams 286 they're using to receive the media. This means that, if not properly 287 disciplined, such a behaviour may easily lead to issues like the one 288 described in the introductory section. As such, it is very important 289 for a B2BUA modifying RTP-related information across two related RTP 290 streams to also modify the same information in RTCP packets as well, 291 and in a coherent way, so that not to confuse any of the participants 292 involved in a communication. 294 It is worthwile to point out that such a B2BUA would not necessarily 295 forward all the packets it is receiving, though: Selective Forwarding 296 Units (SFU) [RFC7667], for instance, could aggregate or drop incoming 297 RTCP messages, while at the same time originating new ones on their 298 own. For the messages that are forwarded and/or aggregated, though, 299 it's important to make sure the information is coherent. 301 Besides the behaviour already mandated for RTCP translators in 302 Section 7.2 of [RFC3550], a media-aware B2BUA MUST also handle 303 incoming RTCP messages to forward following this guideline: 305 SR: [RFC3550] 306 If the B2BUA has changed any SSRC in any RTP streams relation, it 307 MUST update the SSRC-related information in the incoming SR packet 308 before forwarding it. This includes the sender SSRC, which MUST 309 be rewritten with the one the B2BUA uses in the RTP stream used to 310 receive RTP packets from each participant, and the SSRC 311 information in all the blocks, which MUST be rewritten using the 312 related sender participant(s) SSRC. If the B2BUA has also changed 313 the base RTP sequence number when forwarding RTP packets, then 314 this change needs to be properly addressed in the 'extended 315 highest sequence number received' field in the Report Blocks. 317 RR: [RFC3550] 318 The same guidelines given for SR apply for RR as well. 320 SDES: [RFC3550] 321 If the B2BUA has changed any SSRC in any direction, it MUST update 322 the SSRC-related information in all the chunks in the incoming 323 SDES packet before forwarding it. The same considerations made 324 with respect to CNAME collisions at the end of Section 3.1 apply 325 here as well. 327 BYE: [RFC3550] 328 If the B2BUA has changed any SSRC in any direction, it MUST update 329 the SSRC in the BYE message. 331 APP: [RFC3550] 332 If the B2BUA has changed any SSRC in any direction, it MUST update 333 the SSRC in the APP message. Should the B2BUA be aware of any 334 specific APP message format that contains additional information 335 related to SSRCs, it SHOULD update them as well. 337 Extended Reports (XR): [RFC3611] 338 If the B2BUA has changed any SSRC in any direction, it MUST update 339 the SSRC-related information in the incoming XR message header 340 before forwarding it. This includes the source SSRC, which MUST 341 be rewritten with the one the B2BUA uses to send RTP packets to 342 each sender participant, and the SSRC information in all the block 343 types that include it, which MUST be rewritten using the related 344 sender participant(s) SSRC. If the B2BUA has also changed the 345 base RTP sequence number when forwarding RTP packets, then this 346 change needs to be properly addressed in the 'begin_seq' and 347 'end_seq' fields that are available in most of the Report Block 348 types that are part of the XR specification. 350 Receiver Summary Information (RSI): [RFC5760] 351 If the B2BUA has changed any SSRC in any direction, it MUST update 352 the SSRC-related information in the incoming RSI message header 353 before forwarding it. This includes the distribution source SSRC, 354 which MUST be rewritten with the one the B2BUA uses to send RTP 355 packets to each sender participant, the summarized SSRC and, in 356 case a Collision Sub-Report Block is available, the SSRCs in the 357 related list. 359 Port Mapping (TOKEN): [RFC6284] 360 If the B2BUA has changed any SSRC in any direction, it MUST update 361 the SSRC-related information in the incoming TOKEN message before 362 forwarding it. This includes the Packet Sender SSRC, which MUST 363 be rewritten with the one the B2BUA uses to send RTP packets to 364 each sender participant, and the Requesting Client SSRC in case 365 the message is a response, which MUST be rewritten using the 366 related sender participant(s) SSRC. 368 Feedback messages: [RFC4585] 369 All Feedback messages have a common packet format, which includes 370 the SSRC of the packet sender and the one of the media source the 371 feedack is related to. Just as described for the previous 372 messages, these SSRC identifiers MUST be updated if the B2BUA has 373 changed any SSRC in any direction. It MUST NOT, though, change a 374 media source SSRC that was originally set to zero, unless zero is 375 actually the SSRC that was chosen by one of the involved 376 endpoints, in which case the above mentioned rules as to SSRC 377 rewriting apply. Besides, considering that many feedback messages 378 also include additional data as part of their specific Feedback 379 Control Information (FCI), a media-aware B2BUA MUST take care of 380 them accordingly, if it can parse and regenerate them, according 381 to the following guidelines. 383 NACK: [RFC4585] 384 Besides the common packet format management for feedback messages, 385 a media-aware B2BUA MUST also properly rewrite the Packet ID (PID) 386 of all addressed lost packets in the NACK FCI if it changed the 387 RTP sequence numbers before forwarding a packet. 389 TMMBR/TMMBN/FIR/TSTR/TSTN/VBCM: [RFC5104] 390 Besides the common packet format management for feedback messages, 391 a media-aware B2BUA MUST also properly rewrite the additional SSRC 392 identifier all those messages envisage as part of their specific 393 FCI if it changed the related RTP SSRC of the media sender. 395 REMB: [I-D.alvestrand-rmcat-remb] 396 Besides the common packet format management for feedback messages, 397 a media-aware B2BUA MUST also properly rewrite the additional SSRC 398 identifier(s) REMB packets envisage as part of their specific FCI 399 if it changed the related RTP SSRC of the media sender. 401 Explicit Congestion Notification (ECN): [RFC6679] 402 Besides the common packet format management for feedback messages, 403 the same guidelines given for SR/RR management apply as well, 404 considering the presence of sequence numbers in the ECN Feedback 405 Report format. For what concerns the management of RTCP XR ECN 406 Summary Report messages, the same guidelines given for generic XR 407 messages apply. 409 Apart from the generic guidelines related to Feedback messages, no 410 additional modifications are needed for PLI, SLI and RPSI feedback 411 messages instead. 413 Of course, the same considerations about the need for SDP and RTP/ 414 RTCP information to be coherent also applies to media-aware B2BUAs. 415 This means that, if a B2BUA is going to change any SSRC, it SHOULD 416 update the related 'ssrc' attributes if they were present in the 417 original description before sending it to the recipient, just as it 418 MUST rewrite the 'rtcp' attribute if provided. At the same time, the 419 ability for a media-aware B2BUA to inspect/modify RTCP packets may 420 also mean such a B2BUA may choose to drop RTCP packets it can't 421 parse: in that case, a media-aware B2BUA MUST also advertize its RTCP 422 level of support in the SDP in a coherent way, in order to prevent, 423 for instance, a UAC to make use of NACK messages that would never 424 reach the intended recipients. It's important to point out that, in 425 case any RTCP packet needs to be dropped, then only the offending 426 RTCP packet needs to be dropped, and not the whole compound RTCP 427 packet it may belong to. 429 A different set of considerations, instead, is worthwhile for what 430 concerns RTP/RTCP multiplexing [RFC5761] and Reduced-Size RTCP 431 [RFC5506]. While the former allows for a better management of 432 network resources by multiplexing RTP packets and RTCP messages over 433 the same transport, the latter allows for a compression of RTCP 434 messages, thus leading to less network traffic. For what concerns 435 RTP/RTCP multiplexing, a B2BUA acting as a Media Relay can use it on 436 either RTP session independently: this means that, for instance, a 437 Media Relay B2BUA may use RTP/RTCP multiplexing on one side of the 438 communication, and not use it on the other side, if it's not 439 supported. This allows for a better management of network resources 440 on the side that does support it. In case any of the parties in the 441 communications supports it and the B2BUA does too, the related 'rtcp- 442 mux' SDP attribute MUST be forwarded on the other side(s); if the 443 B2BUA detects that any of the parties in the communication does not 444 support the feature, it may decide to either disable it entirely or 445 still advertize it for the RTP sessions with parties that do support 446 it. In case the B2BUA decides to involve RTP/RTCP multiplexing, it 447 MUST ensure that there are no conflicting RTP payload type numbers on 448 both sides, and in case there are, it MUST rewrite RTP payload type 449 numbers to ensure no conflict in the domain where the RTP/RTCP 450 multiplexing is applied. Should RTP payload types be rewritten, the 451 related information in the SDP MUST be updated accordingly. 453 For what concerns Reduced-Size RTCP, instead, the considerations are 454 a bit different. In fact, while a Media Relay B2BUA may choose to 455 use it on the side that supports it and not on the side that doesn't, 456 there are other aspects to take into account before doing so. While 457 Reduced-Size allows indeed for less network traffic related to RTCP 458 messaging in general, this gain may lead a Reduced-Size RTCP 459 implementation to also issue a higher rate of RTCP feedback messages. 460 This would result in an increased RTCP traffic on the side that does 461 not support Reduced-Size, and could as a consequence be actually 462 counterproductive if the bandwidth is different on each side. That 463 said, the B2BUA can choose whether or not to advertize support for 464 Reduced-Size RTCP on either side by means of the 'rtcp-rsize' SDP 465 attribute. Should a B2BUA decide to allow the sides to independently 466 use or not Reduced-Size, then the B2BUA MUST advertize support for 467 the feature on the sides that support it, and MUST NOT advertize it 468 on the sides that don't, by removing the related attribute from the 469 SDP before forwarding it. Should the B2BUA decide to disable the 470 feature on all sides, instead, it MUST NOT advertize support for the 471 Reduced-Size RTCP functionality on any side, by removing the 'rtcp- 472 rsize' attribute from the SDP. 474 3.3. Media Terminator 476 A Media Terminator B2BUA, unlike simple relays and media-aware ones, 477 is also able to terminate media itself, that is taking care of RTP 478 payloads as well and not only headers. This means that such 479 components, for instance, can act as media transcoders and/or 480 originate specific RTP media. Using the RTP Topologies terminology, 481 this can be seen as a RTP Media Translator. Such a topology can also 482 be seen as a Back-to-back RTP sessions through a Middlebox, as 483 described in Section 3.2.2 of [RFC7667]. Such a capability makes 484 them quite different from the previously introduced B2BUA typologies, 485 as this means they are going to terminate RTCP as well: in fact, 486 since the media is terminated by themselves, the related statistics 487 and feedback functionality can be taken care directly by the B2BUA, 488 and does not need to be relayed to the other participants in the 489 multimedia session. 491 For this reason, no specific guideline is needed to ensure a proper 492 end-to-end RTCP behaviour in such scenarios, mostly because most of 493 the times there would be no end-to-end RTCP interaction among the 494 involved participants at all, as the B2BUA would terminate them all 495 and take care of them accordingly. Nevertheless, should any RTCP 496 packet actually need to be forwarded to another participant in the 497 multimedia session, the same guidelines provided for the media-aware 498 B2BUA case apply. 500 For what concerns RTP/RTCP multiplexing support, the same 501 considerations already given for the Media Relay management basically 502 apply for a Media Terminator as well. Some different considerations 503 might be given as to the Reduced-Size RTCP functionality, instead: in 504 fact, in the Media Terminator case it is safe to use the feature 505 independently on each leg. In that case, the same considerations 506 about advertizing the support, or lack of support, of the feature on 507 either side as described for the Media Relay case apply here as well. 509 4. Media Path Security 511 The discussion made in the previous sections on the management of 512 RTCP messages by a B2BUA has so far mostly worked under the 513 assumption that the B2BUA has actually access to the RTP/RTCP 514 information itself. This is indeed true if we assume that plain RTP 515 and RTCP is being handled, but this may not be true once any security 516 is enforced on RTP packets and RTCP messages by means of SRTP 517 [RFC3711], whether the keying is done using Secure Descriptions 518 [RFC4568] or DTLS-SRTP [RFC5764]. 520 While typically not an issue in the Media Relay case, where RTP and 521 RTCP packets are forwarded without any modification no matter whether 522 security is involved or not, this could definitely have an impact on 523 Media-aware Relays and Media Terminator B2BUAs. To make a simple 524 example, if we think of a SRTP/SRTCP session across a B2BUA where the 525 B2BUA itself has no access to the keys used to secure the session, 526 there would be no way to manipulate SRTP headers without violating 527 the hashing on the packet; at the same time, there would be no way to 528 rewrite the RTCP information accordingly either, as most of the 529 packet (especially when RTCP compound packets are involved) would be 530 encrypted. 532 For this reason, it is important to point out that the operations 533 described in the previous sections are only possible if the B2BUA has 534 a way to effectively manipulate the packets and messages flowing by. 535 This means that, in case media security is involved, only the Media- 536 unaware Relay scenario can be properly addressed. Attempting to 537 cover Media-aware Relay and Media Terminarion scenarios when 538 involving secure sessions will inevitably lead to the B2BUA acting as 539 a man-in-the-middle, and as such its behaviour is unspecified and 540 discouraged. 542 5. IANA Considerations 544 This document makes no request of IANA. 546 6. Security Considerations 548 This document, being a summary and vest common practice overview that 549 covers different standards, does not introduce any additional 550 consideration to those described by the aforementioned standard 551 documents themselves. 553 It is worth pointing out, though, that there are scenarios where an 554 improper management of RTCP messaging across a B2BUA may lead, 555 willingly or not, to situations not unlike an attack. To make a 556 simple example, an improper management of a REMB feedback message 557 containing, e.g., information on the limited bandwidth availability 558 for a user, may lead to missing information to its peer, who may end 559 up increasing the encoder bitrate up to a point where the user with 560 poor connectivity will inevitably be choked by an amount of data it 561 cannot process. This scenario may as such result in what looks like 562 a Denial of Service (DOS) attack towards the user. 564 7. Change Summary 566 Note to RFC Editor: Please remove this whole section. 568 The following are the major changes between the 08 and the 09 569 versions of the draft: 571 o Updated references to documents which have become RFC in the 572 meanwhile, [RFC7667] and [RFC7656]. 574 The following are the major changes between the 06 and the 07 575 versions of the draft: 577 o Clarified the suggested changed by Colin Perkins on the management 578 of CNAME items in SDES, and added reference to [RFC7022]. 580 o Addressed comment by Simon Perreault on CNAME collisions 581 management. 583 The following are the major changes between the 05 and the 06 584 versions of the draft: 586 o Addressed comment by Colin Perkins on the management of CNAME 587 items in SDES. 589 The following are the major changes between the 04 and the 05 590 versions of the draft: 592 o Clarified behaviour when SSRC is zero. 594 o Fixed a couple of nits found by the Idnits tool. 596 The following are the major changes between the 03 and the 04 597 versions of the draft: 599 o Addressed review by Magnus Westerlund. 601 o Added guidelines for ECN RTCP messages. 603 o Clarified that if an RTCP packet is dropped because unsupported, 604 only the unsupported packet is dropped and not the compound packet 605 that contains it. 607 o Added reference to Section 3.2.2 of [RFC7667] to Section 3.3. 609 o Added considerations on RTP/RTCP multiplexing and Reduced-Size 610 RTCP. 612 The following are the major changes between the 02 and the 03 613 versions of the draft: 615 o Rephrased the Media Path Security section to take into account the 616 MITM-related discussion in Honolulu. 618 o Added some Security Considerations. 620 The following are the major changes between the 01 and the 02 621 versions of the draft: 623 o Updated terminology to better adhere to [RFC7656]. 625 o Rephrased the Media Path Security section to take into account the 626 MITM-related discussion in Toronto. 628 o Clarified that NACK management might be trickier when SRTP is 629 involved. 631 The following are the major changes between the 00 and the 01 632 versions of the draft: 634 o Updated references and mapping per taxonomy RFC (7092). 636 o Added a reference to RTP topologies, and tried a mapping as per- 637 discussion in London. 639 o Added more RTCP packet types to the Media-Aware section. 641 o Clarified that fixing the 'rtcp' SDP attribute is important. 643 o Added a new section on the impact of media security. 645 8. Acknowledgements 647 The authors would like to thank Flavio Battimo and Pierluigi Palma 648 for their invaluable feedback in the early stages of the document. 649 The authors would also like to thank Colin Perkins, Bernard Aboba, 650 Albrecht Schwarz, Hadriel Kaplan, Keith Drage, Jonathan Lennox, 651 Stephen Farrell, Magnus Westerlund and Simon Perreault for their 652 constructive comments, suggestions, and reviews that were critical to 653 the formulation and refinement of this document. 655 9. References 657 9.1. Normative References 659 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 660 Requirement Levels", BCP 14, RFC 2119, 661 DOI 10.17487/RFC2119, March 1997, 662 . 664 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 665 A., Peterson, J., Sparks, R., Handley, M., and E. 666 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 667 DOI 10.17487/RFC3261, June 2002, 668 . 670 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 671 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 672 July 2006, . 674 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 675 with Session Description Protocol (SDP)", RFC 3264, 676 DOI 10.17487/RFC3264, June 2002, 677 . 679 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 680 Jacobson, "RTP: A Transport Protocol for Real-Time 681 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 682 July 2003, . 684 9.2. Informative References 686 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 687 Initiation Protocol (SIP) Back-to-Back User Agents", 688 RFC 7092, DOI 10.17487/RFC7092, December 2013, 689 . 691 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 692 DOI 10.17487/RFC5117, January 2008, 693 . 695 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, 696 DOI 10.17487/RFC7667, November 2015, 697 . 699 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 700 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 701 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 702 DOI 10.17487/RFC7656, November 2015, 703 . 705 [I-D.alvestrand-rmcat-remb] 706 Alvestrand, H., "RTCP message for Receiver Estimated 707 Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in 708 progress), October 2013. 710 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 711 "Extended RTP Profile for Real-time Transport Control 712 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 713 DOI 10.17487/RFC4585, July 2006, 714 . 716 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 717 "Codec Control Messages in the RTP Audio-Visual Profile 718 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 719 February 2008, . 721 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 722 Media Attributes in the Session Description Protocol 723 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 724 . 726 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 727 in Session Description Protocol (SDP)", RFC 3605, 728 DOI 10.17487/RFC3605, October 2003, 729 . 731 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 732 "RTP Control Protocol Extended Reports (RTCP XR)", 733 RFC 3611, DOI 10.17487/RFC3611, November 2003, 734 . 736 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 737 Protocol (RTCP) Extensions for Single-Source Multicast 738 Sessions with Unicast Feedback", RFC 5760, 739 DOI 10.17487/RFC5760, February 2010, 740 . 742 [RFC6284] Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping 743 between Unicast and Multicast RTP Sessions", RFC 6284, 744 DOI 10.17487/RFC6284, June 2011, 745 . 747 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 748 and K. Carlberg, "Explicit Congestion Notification (ECN) 749 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 750 2012, . 752 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 753 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 754 RFC 3711, DOI 10.17487/RFC3711, March 2004, 755 . 757 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 758 Description Protocol (SDP) Security Descriptions for Media 759 Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, 760 . 762 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 763 Control Packets on a Single Port", RFC 5761, 764 DOI 10.17487/RFC5761, April 2010, 765 . 767 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 768 Real-Time Transport Control Protocol (RTCP): Opportunities 769 and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 770 2009, . 772 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 773 Security (DTLS) Extension to Establish Keys for the Secure 774 Real-time Transport Protocol (SRTP)", RFC 5764, 775 DOI 10.17487/RFC5764, May 2010, 776 . 778 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 779 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 780 DOI 10.17487/RFC4588, July 2006, 781 . 783 [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, 784 "Guidelines for Choosing RTP Control Protocol (RTCP) 785 Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, 786 September 2013, . 788 Authors' Addresses 790 Lorenzo Miniero 791 Meetecho 793 Email: lorenzo@meetecho.com 795 Sergio Garcia Murillo 796 Medooze 798 Email: sergio.garcia.murillo@gmail.com 799 Victor Pascual 800 Quobis 802 Email: victor.pascual@quobis.com