idnits 2.17.1 draft-ietf-straw-b2bua-rtcp-00.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 19, 2013) is 3779 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) == Unused Reference: 'RFC3264' is defined on line 384, but no explicit reference was found in the text == Unused Reference: 'RFC5576' is defined on line 414, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 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 22, 2014 Medooze 6 V. Pascual 7 Quobis 8 December 19, 2013 10 Guidelines to support RTCP end-to-end in Back-to-Back User Agents 11 (B2BUAs) 12 draft-ietf-straw-b2bua-rtcp-00 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 media legs that the B2BUA 21 correlates and bridges together. If not disciplined, though, this 22 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 June 22, 2014. 47 Copyright Notice 48 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.2. Media-aware Relay . . . . . . . . . . . . . . . . . . . . 5 68 3.3. Media-terminator . . . . . . . . . . . . . . . . . . . . 8 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 7.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 Session Initiation Protocol [RFC3261] Back-to-Back User Agents 80 (B2BUAs) are SIP entities that can act as a logical combination of 81 both a User Agent Server (UAS) and a User Agent Client (UAC). As 82 such, their behaviour is not always completelely adherent to the 83 standards, and can lead to unexpected situations the IETF is trying 84 to address. [I-D.ietf-straw-b2bua-taxonomy] presents a taxonomy of 85 the most deployed B2BUA implementations, describing how they differ 86 in terms of the functionality and features they provide. 88 Such components often do not only act on the signalling plane, that 89 is intercepting and possibly modifying SIP messages, but also on the 90 media plane. This means that, when on the signalling path between 91 two parties willing to communicate, such components also manipulate 92 the session description [RFC4566] in order to have all RTP and RTCP 93 [RFC3550] pass through it as well. The reasons for such a behaviour 94 can be different: the B2BUA may want, for instance, to provide 95 transcoding functionality for peers with incompatible codecs, or it 96 may need the traffic to be directly handled for different reasons 97 like billing, lawful interception, session recording and so on. 99 Whatever the reason, such a behaviour does not come without a cost. 100 In fact, whenever a media-aware component is placed on the path 101 between two peers that want to communicate by means of RTP/RTCP, the 102 end-to-end nature of such protocols is broken, and their 103 effectiveness may be affected as a consequence. While this may not 104 be a problem for RTP packets, which from a protocol point of view 105 just contain opaque media packets and as such can be quite easily 106 relayed, it definitely can cause serious issue for RTCP packets, 107 which carry important information and feedback on the communication 108 quality the peers are experiencing. In fact, RTCP packets make use 109 of specific ways to address the media they are referring to. 110 Consider, for instance, the scenario depicted in Figure 1: 112 +--------+ +---------+ +---------+ 113 | |=== SSRC1 ===>| |=== SSRC3 ===>| | 114 | Alice | | B2BUA | | Bob | 115 | |<=== SSRC2 ===| |<=== SSRC4 ===| | 116 +--------+ +---------+ +---------+ 118 Figure 1: B2BUA modifying RTP headers 120 In this common scenario, a party (Alice) is communicating with a peer 121 (Bob) as a result of a signalling session managed by a B2BUA: this 122 B2BUA is also on the media path between the two, and is acting as a 123 media relay. It is also, though, rewriting some of the RTP header 124 information on the way, for instance because that's how its RTP 125 relaying stack works: in this example, just the audio SSRC is 126 changed, but more information may be changed as well (e.g., sequence 127 numbers, timestamps, etc.). In particular, whenever Alice sends an 128 audio RTP packet, she adds her SSRC (SSRC1) to the RTP header; the 129 B2BUA rewrites the SSRC (SSRC3) before relaying the packet to Bob. At 130 the same time, RTP packets sent by Bob (SSRC4) get their SSRC 131 rewritten as well (SSRC2) before being relayed to Alice. 133 Assuming now that Alice needs to inform Bob she has lost several 134 audio packets in the last few seconds, maybe because of a network 135 congestion, she would of course place the related peer audio SSRC she 136 is aware of (SSRC2), together with her own (SSRC1), in RTCP Reports 137 and/or NACKS to do so, hoping for a retransmission or for Bob to slow 138 down. Since the B2BUA is making use of different SSRCs for the RTP 139 communication with the party and the peer, a blind relaying of the 140 RTCP packets to Bob would in this case result, from his perspective, 141 in unknown SSRCs being addressed, thus resulting in the precious 142 information being dropped. In fact, Bob is only aware of SSRCs SSRC4 143 (the one he's originating) and SSRC3 (the one he's receiving from the 144 B2BUA), and knows nothing about SSRCs SSRC1 and SSRC2 in the RTCP 145 packets he receives. As a consequence of the feedback being dropped, 146 unaware of the issue Bob may continue to flood the party with even 147 more media packets and/or not send Alice the packets she misses, 148 which may easily lead to a very bad communication experience, if not 149 eventually to an unwanted termination of the communication itself. 151 This is just a simple example that, together with additional 152 scenarios, will be addressed in the following sections. 153 Nevertheless, it is a valid example of how such a trivial mishandling 154 of precious information may lead to serious consequences. 155 Considering how common B2BUA deployments are, it is very important 156 for them to properly address such feedback, in order to be sure that 157 their activities on the media plane do not break anything they're not 158 supposed to. 160 2. Terminology 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in [RFC2119]. 166 3. Signalling/Media Plane B2BUAs 168 As anticipated in the introductory section, it's very common for 169 B2BUA deployments to also act on the media plane, rather than just 170 signalling alone. In particular, [I-D.ietf-straw-b2bua-taxonomy] 171 describes three different categories of such B2BUAs, according to the 172 level of activities performed on the media plane: a B2BUA, in fact, 173 may act as a simple media relay (1), effectively unaware of anything 174 that is transported; it may be a media-aware relay (2), also 175 inspecting and/or modifying RTP and RTCP packets as they flow by; or 176 it may be a full-fledged media-termination entity, terminating and 177 generating RTP and RTCP packets as needed. 179 The following subsections will describe the proper behaviour B2BUAs, 180 whatever above category they fall in, should follow in order to 181 avoid, or at least minimize, any impact on end-to-end RTCP 182 effectiveness. 184 3.1. Media Relay 186 A media relay as identified in [I-D.ietf-straw-b2bua-taxonomy] 187 basically just forwards, from an application level point of view, all 188 RTP and RTP packets it receives, without either inspecting or 189 modifying them. As such, B2BUA acting as media relays are not aware 190 of what traffic they're handling, meaning that not only the packet 191 payloads are opaque to them, but headers as well. Many Session 192 Border Controllers (SBC) implement this kind of behaviour, e.g., when 193 acting as a bridge between an inner and outer network. 195 Considering all headers and identifiers in both RTP and RTCP are left 196 untouched, issues like the SSRC mismatch described in the previous 197 section would not occur. Similar problems could occur, though, 198 should the session description end up providing incorrect information 199 about the media flowing (e.g., if the SDP on either side contain 200 'ssrc' attributes that don't match the actual SSRC being advertized 201 on the media plane) or about the supported RTCP mechanisms (e.g., in 202 case the B2BUA advertized support for NACK because it implements it, 203 but the original INVITE didn't). Such an issue might occur, for 204 instance, in case the B2BUA acting as a media relay is generating a 205 new session description when bridging an incoming call, rather than 206 taking into account the original session description in the first 207 place. This may cause the peers to find a mismatch between the SSRCs 208 advertized in SDP and the ones actually observed in RTP and RTCP 209 packets, or having them either ignore or generate RTCP feedback 210 packets that were not explicitly advertized as supported. 212 In order to prevent such an issue, a media-relay B2BUA SHOULD forward 213 all the SSRC- and RTCP-related SDP attributes when handling a session 214 setup between interested parties: this includes attributes like 215 'ssrc' [RFC3261] and 'rtcp-fb' [RFC4585]. It SHOULD NOT, though, 216 blindly forward all SDP attributes, as some of them (e.g., 217 candidates, fingerprints, crypto, etc.) may lead to call failures for 218 different reasons out of scope to this document. 220 Besides, it is worth mentioning that, leaving RTCP packets untouched, 221 a media relay may also let through information that, according to 222 policies, may be best left hidden or masqueraded, e.g., domain names 223 in CNAME items. Nevertheless, that information cannot break the end- 224 to-end RTCP behaviour. 226 3.2. Media-aware Relay 228 A Media-aware relay, unlike the the Media Relay addressed in the 229 previous section, is actually aware of the media traffic it is 230 handling. As such, it is able to inspect RTP and RTCP packets 231 flowing by, and may even be able to modify the headers in any of them 232 before forwarding them. A B2BUA implementing this role would not, 233 though, inspect the RTP payloads as well, which would be opaque to 234 them. 236 This makes them quite different from the Media Relay previously 237 discussed, especially in terms of the potential issues that may occur 238 at the RTCP level. In fact, being able to modify the RTP and RTCP 239 headers, such B2BUAs may end up modifying RTP related information 240 like SSRC, sequence numbers, timestamps and the like before 241 forwarding packets from one peer to another. This means that, if not 242 properly disciplined, such a behaviour may easily lead to issues like 243 the one described in the introductory section. 245 As such, it is very important for a B2BUA modifying RTP-related 246 information to also modify the same information in RTCP packets as 247 well, and in a coherent way, so that not to confuse any of the peers 248 involved in a communication. Besides the behaviour already mandated 249 for RTCP translators in Section 7.2 of [RFC3550], a media-aware B2BUA 250 MUST also handle incoming RTCP messages to forward following this 251 guideline: 253 SR: [RFC3550] 254 If the B2BUA has changed the SSRC of any direction, it MUST update 255 the SSRC-related information in the incoming SR packet before 256 forwarding it. This includes the sender SSRC, which MUST be 257 replaced by the one the B2BUA uses to send RTP packets to the 258 sender peer, and the SSRC information in all the blocks, which 259 MUST be replaced using the related sender peer(s) SSRC. If the 260 B2BUA has also changed the base RTP sequence number when 261 forwarding RTP packets, then this change needs to be properly 262 addressed in the 'extended highest sequence number received' field 263 in the Report Blocks. 265 RR: [RFC3550] 266 The same guidelines given for SR apply for RR as well. 268 SDES: [RFC3550] 269 If the B2BUA has changed the SSRC of any direction, it MUST update 270 the SSRC-related information in all the chunks in the incoming 271 SDES packet before forwarding it. 273 BYE: [RFC3550] 274 If the B2BUA has changed the SSRC of any direction, it MUST update 275 the SSRC in the BYE message. 277 APP: [RFC3550] 278 If the B2BUA has changed the SSRC of any direction, it MUST update 279 the SSRC in the BYE message. Should the B2BUA be aware of any 280 specific APP message format that contains additional information 281 related to SSRCs, it SHOULD update them as well. 283 Feedback messages: [RFC4585] 284 All Feedback messages have a common packet format, which includes 285 the SSRC of the packet sender and the one of the media source the 286 feedack is related to. Just as described for the previous 287 messages, these SSRC identifiers MUST be updated if the B2BUA has 288 changed the SSRC of any direction. It MUST NOT, though, change a 289 media source SSRC that was originally set to zero. Besides, 290 considering that many feedback messages also include additional 291 data as part of their specific Feedback Control Information (FCI), 292 a media-aware B2BUA MUST take care of them accordingly, if it can 293 parse and regenerate them, according to the following guidelines. 295 NACK: [RFC4585] 296 Besides the common packet format management for feedback messages, 297 a media-aware B2BUA MUST also properly replace the Packet ID (PID) 298 of all addressed lost packets in the NACK FCI if it changed the 299 RTP sequence numbers before forwarding a packet. 301 TMMBR/TMMBN/FIR/TSTR/TSTN/VBCM: [RFC5104] 302 Besides the common packet format management for feedback messages, 303 a media-aware B2BUA MUST also properly replace the additional SSRC 304 identifier all those messages envisage as part of their specific 305 FCI if it changed the related RTP SSRC of the media sender. 307 REMB: [I-D.alvestrand-rmcat-remb] 308 Besides the common packet format management for feedback messages, 309 a media-aware B2BUA MUST also properly replace the additional SSRC 310 identifier(s) REMB packets envisage as part of their specific FCI 311 if it changed the related RTP SSRC of the media sender. 313 Apart from the generic guidelines related to Feedback messages, no 314 additional modifications are needed for PLI, SLI and RPSI feedback 315 messages instead. 317 Of course, the same considerations about the need for SDP and RTP/ 318 RTCP information to be coherent also applies to media-aware B2BUAs. 319 This means that, if a B2BUA is going to change any SSRC, it SHOULD 320 update the related 'ssrc' attributes if they were present in the 321 original description before sending it to the recipient. At the same 322 time, the ability for a media-aware B2BUA to inspect/modify RTCP 323 packets may also mean such a B2BUA may choose to drop RTCP packets it 324 can't parse: in that case, a media-aware B2BUA SHOULD also advertize 325 its RTCP level of support in the SDP in a coherent way, in order to 326 prevent, for instance, a UAC to make use of NACK messages that would 327 never reach the intended recipients. 329 3.3. Media-terminator 331 A media-terminator B2BUA, unlike simple relays and media-aware ones, 332 is also able to terminate media itself, that is taking care of RTP 333 payloads as well and not only headers. This means that such 334 components, for instance, can act as media transcoders and/or 335 originate specific RTP media. Such a capability makes them quite 336 different from the previously introduced B2BUA typologies, as this 337 means they most likely are going to terminate RTCP as well: in fact, 338 since the media is terminated by themselves, the related statistics 339 and feedback functionality can be taken care directly by the B2BUA, 340 and does not need to be relayed to the logical peer in the multimedia 341 communication. 343 For this reason, no specific guideline is needed to ensure a proper 344 end-to-end RTCP behaviour in such scenarios, mostly because most of 345 the times there would be no end-to-end RTCP interaction among the 346 involved peers at all, as the B2BUA would terminate them all and take 347 care of them accordingly. Nevertheless, should any RTCP packet 348 actually need to be delivered to the actual peer, the same guidelines 349 provided for the media-aware B2BUA case apply. 351 4. IANA Considerations 353 This document makes no request of IANA. 355 5. Security Considerations 357 TBD. Not any additional consideration to what the standards already 358 give? Probably this section will need a few words about how NOT 359 following the guidelines can lead to security issues: e.g., not 360 properly translating REMB messages can cause an increasing flow of 361 media packets, that may be seen as attacks to devices that can't 362 handle the amount of data. 364 6. Acknowledgements 366 TBD. 368 7. References 370 7.1. Normative References 372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, March 1997. 375 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 376 A., Peterson, J., Sparks, R., Handley, M., and E. 378 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 379 June 2002. 381 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 382 Description Protocol", RFC 4566, July 2006. 384 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 385 with Session Description Protocol (SDP)", RFC 3264, June 386 2002. 388 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 389 Jacobson, "RTP: A Transport Protocol for Real-Time 390 Applications", STD 64, RFC 3550, July 2003. 392 7.2. Informative References 394 [I-D.ietf-straw-b2bua-taxonomy] 395 Kaplan, H. and V. Pascual, "A Taxonomy of Session 396 Initiation Protocol (SIP) Back-to-Back User Agents", 397 draft-ietf-straw-b2bua-taxonomy-03 (work in progress), 398 October 2013. 400 [I-D.alvestrand-rmcat-remb] 401 Alvestrand, H., "RTCP message for Receiver Estimated 402 Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in 403 progress), October 2013. 405 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 406 "Extended RTP Profile for Real-time Transport Control 407 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 408 2006. 410 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 411 "Codec Control Messages in the RTP Audio-Visual Profile 412 with Feedback (AVPF)", RFC 5104, February 2008. 414 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 415 Media Attributes in the Session Description Protocol 416 (SDP)", RFC 5576, June 2009. 418 Authors' Addresses 420 Lorenzo Miniero 421 Meetecho 423 Email: lorenzo@meetecho.com 424 Sergio Garcia Murillo 425 Medooze 427 Email: sergio.garcia.murillo@gmail.com 429 Victor Pascual 430 Quobis 432 Email: victor.pascual@quobis.com