idnits 2.17.1 draft-ietf-straw-b2bua-rtcp-01.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 (June 20, 2014) is 3597 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 7092 -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) == Outdated reference: A later version (-10) exists of draft-ietf-avtcore-rtp-topologies-update-02 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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: December 22, 2014 Medooze 6 V. Pascual 7 Quobis 8 June 20, 2014 10 Guidelines to support RTCP end-to-end in Back-to-Back User Agents 11 (B2BUAs) 12 draft-ietf-straw-b2bua-rtcp-01 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 December 22, 2014. 47 Copyright Notice 49 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . 4 67 3.1. Media Relay . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.2. Media-aware Relay . . . . . . . . . . . . . . . . . . . . 6 69 3.3. Media Terminator . . . . . . . . . . . . . . . . . . . . 9 70 4. Media Path Security . . . . . . . . . . . . . . . . . . . . . 9 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 7. Change Summary . . . . . . . . . . . . . . . . . . . . . . . 10 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 9.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 parties 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 peers with incompatible codecs, or it may need the 100 traffic to be directly handled for different reasons like billing, 101 lawful interception, session recording and so on. This can lead to 102 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 [I-D.ietf-avtcore-rtp-topologies-update]. 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 peers that want to communicate by means of RTP/RTCP, the 110 end-to-end nature of such protocols is broken, and their 111 effectiveness may be affected as a consequence. While this may not 112 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 peers are experiencing. In fact, RTCP packets make use 117 of specific ways to address the media they are referring to. 118 Consider, for instance, the simple scenario only involving two 119 parties and a single media flow 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 party (Alice) is communicating with a peer 130 (Bob) as a result of a signalling session managed by a B2BUA: this 131 B2BUA is also on the media path between the two, and is acting as a 132 media relay. It is also, though, rewriting some of the RTP header 133 information on the way, for instance because that's how its RTP 134 relaying stack works: in this example, just the audio SSRC is 135 changed, but more information may be changed as well (e.g., sequence 136 numbers, timestamps, etc.). In particular, whenever Alice sends an 137 audio RTP packet, she adds her SSRC (SSRC1) to the RTP header; the 138 B2BUA rewrites the SSRC (SSRC3) before relaying the packet to Bob. At 139 the same time, RTP packets sent by Bob (SSRC4) get their SSRC 140 rewritten as well (SSRC2) before being relayed to Alice. 142 Assuming now that Alice needs to inform Bob she has lost several 143 audio packets in the last few seconds, maybe because of a network 144 congestion, she would of course place the related peer audio SSRC she 145 is aware of (SSRC2), together with her own (SSRC1), in RTCP Reports 146 and/or NACKS to do so, hoping for a retransmission or for Bob to slow 147 down. Since the B2BUA is making use of different SSRCs for the RTP 148 communication with the party and the peer, a blind relaying of the 149 RTCP packets to Bob would in this case result, from his perspective, 150 in unknown SSRCs being addressed, thus resulting in the precious 151 information being dropped. In fact, Bob is only aware of SSRCs SSRC4 152 (the one he's originating) and SSRC3 (the one he's receiving from the 153 B2BUA), and knows nothing about SSRCs SSRC1 and SSRC2 in the RTCP 154 packets he receives. As a consequence of the feedback being dropped, 155 unaware of the issue Bob may continue to flood the party with even 156 more media packets and/or not send Alice the packets she misses, 157 which may easily lead to a very bad communication experience, if not 158 eventually to an unwanted termination of the communication itself. 160 This is just a trivial example that, together with additional 161 scenarios, will be addressed in the following sections. 162 Nevertheless, it is a valid example of how such a trivial mishandling 163 of precious information may lead to serious consequences, especially 164 considering that more complex scenarios may involve several parties 165 at the same time and multiple media flows rather than a single one. 166 Considering how common B2BUA deployments are, it is very important 167 for them to properly address such feedback, in order to be sure that 168 their activities on the media plane do not break anything they're not 169 supposed to. 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 3. Signalling/Media Plane B2BUAs 179 As anticipated in the introductory section, it's very common for 180 B2BUA deployments to also act on the media plane, rather than just 181 signalling alone. In particular, [RFC7092] describes three different 182 categories of such B2BUAs, according to the level of activities 183 performed on the media plane: a B2BUA, in fact, may act as a simple 184 media relay (1), effectively unaware of anything that is transported; 185 it may be a media-aware relay (2), also inspecting and/or modifying 186 RTP and RTCP packets as they flow by; or it may be a full-fledged 187 media termination entity, terminating and generating RTP and RTCP 188 packets as needed. 190 While [RFC3550] and [RFC5117] already mandate some specific 191 behaviours when specific topologies are deployed, not all deployments 192 strictly adhere to the specifications and as such it's not rare to 193 encounter issues that may be avoided with a more disciplined 194 behaviour in that regard. For this reason, the following subsections 195 will describe the proper behaviour B2BUAs, whatever above category 196 they fall in, should follow in order to avoid, or at least minimize, 197 any impact on end-to-end RTCP effectiveness. 199 3.1. Media Relay 201 A media relay as identified in [RFC7092] basically just forwards, 202 from an application level point of view, all RTP and RTP packets it 203 receives, without either inspecting or modifying them. Using the RTP 204 Topologies terminology, this can be seen as a RTP Transport 205 Translator. As such, B2BUA acting as media relays are not aware of 206 what traffic they're handling, meaning that not only the packet 207 payloads are opaque to them, but headers as well. Many Session 208 Border Controllers (SBC) implement this kind of behaviour, e.g., when 209 acting as a bridge between an inner and outer network. 211 Considering all headers and identifiers in both RTP and RTCP are left 212 untouched, issues like the SSRC mismatch described in the previous 213 section would not occur. Similar problems could occur, though, 214 should the session description end up providing incorrect information 215 about the media flowing (e.g., if the SDP on either side contain 216 'ssrc' [RFC5576] attributes that don't match the actual SSRC being 217 advertized on the media plane) or about the supported RTCP mechanisms 218 (e.g., in case the B2BUA advertized support for NACK because it 219 implements it, but the original INVITE didn't). Such an issue might 220 occur, for instance, in case the B2BUA acting as a media relay is 221 generating a new session description when bridging an incoming call, 222 rather than taking into account the original session description in 223 the first place. This may cause the peers to find a mismatch between 224 the SSRCs advertized in SDP and the ones actually observed in RTP and 225 RTCP packets (which may indeed change during a session anyway, but 226 having them synced during setup would help nonetheless), or having 227 them either ignore or generate RTCP feedback packets that were not 228 explicitly advertized as supported. 230 In order to prevent such an issue, a media-relay B2BUA SHOULD forward 231 all the SSRC- and RTCP-related SDP attributes when handling a session 232 setup between interested parties: this includes attributes like 233 'ssrc' [RFC3261], 'rtcp-fb' [RFC4585], 'rtcp-xr-attrib' [RFC3611] and 234 others. It SHOULD NOT, though, blindly forward all SDP attributes, 235 as some of them (e.g., candidates, fingerprints, crypto, etc.) may 236 lead to call failures for different reasons out of scope to this 237 document. One notable example is the 'rtcp' [RFC3605] attribute that 238 UAC may make use of to explicitly state the port they're willing to 239 use for RTCP: considering the B2BUA would relay RTCP packets, the 240 port as seen by the other UAC involved in the communication would 241 differ from the one negotiated originally, and as such it MUST be 242 rewritten accordingly. 244 Besides, it is worth mentioning that, leaving RTCP packets untouched, 245 a media relay may also let through information that, according to 246 policies, may be best left hidden or masqueraded, e.g., domain names 247 in CNAME items. Nevertheless, that information cannot break the end- 248 to-end RTCP behaviour. 250 3.2. Media-aware Relay 252 A Media-aware relay, unlike the the Media Relay addressed in the 253 previous section, is actually aware of the media traffic it is 254 handling. As such, it is able to inspect RTP and RTCP packets 255 flowing by, and may even be able to modify the headers in any of them 256 before forwarding them. Using the RFC3550 terminology, this can be 257 seen as a RTP Translator. A B2BUA implementing this role would 258 typically not, though, inspect the RTP payloads as well, which would 259 be opaque to them: this means that the actual media would not be 260 manipulated (e.g, transcoded). 262 This makes them quite different from the Media Relay previously 263 discussed, especially in terms of the potential issues that may occur 264 at the RTCP level. In fact, being able to modify the RTP and RTCP 265 headers, such B2BUAs may end up modifying RTP related information 266 like SSRC (and hence CSRC lists, that must of course be updated 267 accordingly), sequence numbers, timestamps and the like before 268 forwarding packets from one peer to another. This means that, if not 269 properly disciplined, such a behaviour may easily lead to issues like 270 the one described in the introductory section. As such, it is very 271 important for a B2BUA modifying RTP-related information to also 272 modify the same information in RTCP packets as well, and in a 273 coherent way, so that not to confuse any of the peers involved in a 274 communication. 276 It is worthwile to point out that such a B2BUA would not necessarily 277 forward all the packets it is receiving, though: Selective Forwarding 278 Units (SFU) [I-D.ietf-avtcore-rtp-topologies-update], for instance, 279 could aggregate or drop incoming RTCP messages, while at the same 280 time originating new ones on their own. For the messages that are 281 forwarded and/or aggregated, though, it's important to make sure the 282 information is coherent. 284 Besides the behaviour already mandated for RTCP translators in 285 Section 7.2 of [RFC3550], a media-aware B2BUA MUST also handle 286 incoming RTCP messages to forward following this guideline: 288 SR: [RFC3550] 289 If the B2BUA has changed any SSRC in any direction, it MUST update 290 the SSRC-related information in the incoming SR packet before 291 forwarding it. This includes the sender SSRC, which MUST be 292 rewritten with the one the B2BUA uses to send RTP packets to the 293 sender peer, and the SSRC information in all the blocks, which 294 MUST be rewritten using the related sender peer(s) SSRC. If the 295 B2BUA has also changed the base RTP sequence number when 296 forwarding RTP packets, then this change needs to be properly 297 addressed in the 'extended highest sequence number received' field 298 in the Report Blocks. 300 RR: [RFC3550] 301 The same guidelines given for SR apply for RR as well. 303 SDES: [RFC3550] 304 If the B2BUA has changed any SSRC in any direction, it MUST update 305 the SSRC-related information in all the chunks in the incoming 306 SDES packet before forwarding it. 308 BYE: [RFC3550] 309 If the B2BUA has changed any SSRC in any direction, it MUST update 310 the SSRC in the BYE message. 312 APP: [RFC3550] 313 If the B2BUA has changed any SSRC in any direction, it MUST update 314 the SSRC in the BYE message. Should the B2BUA be aware of any 315 specific APP message format that contains additional information 316 related to SSRCs, it SHOULD update them as well. 318 Extended Reports (XR): [RFC3611] 319 If the B2BUA has changed any SSRC in any direction, it MUST update 320 the SSRC-related information in the incoming XR message header 321 before forwarding it. This includes the source SSRC, which MUST 322 be rewritten with the one the B2BUA uses to send RTP packets to 323 the sender peer, and the SSRC information in all the block types 324 that include it, which MUST be rewritten using the related sender 325 peer(s) SSRC. If the B2BUA has also changed the base RTP sequence 326 number when forwarding RTP packets, then this change needs to be 327 properly addressed in the 'begin_seq' and 'end_seq' fields that 328 are available in most of the Report Block types that are part of 329 the XR specification. 331 Receiver Summary Information (RSI): [RFC5760] 332 If the B2BUA has changed any SSRC in any direction, it MUST update 333 the SSRC-related information in the incoming RSI message header 334 before forwarding it. This includes the distribution source SSRC, 335 which MUST be rewritten with the one the B2BUA uses to send RTP 336 packets to the sender peer, the summarized SSRC and, in case a 337 Collision Sub-Report Block is available, the SSRCs in the related 338 list. 340 Port Mapping (TOKEN): [RFC6284] 341 If the B2BUA has changed any SSRC in any direction, it MUST update 342 the SSRC-related information in the incoming TOKEN message before 343 forwarding it. This includes the Packet Sender SSRC, which MUST 344 be rewritten with the one the B2BUA uses to send RTP packets to 345 the sender peer, and the Requesting Client SSRC in case the 346 message is a response, which MUST be rewritten using the related 347 sender peer(s) SSRC. 349 Feedback messages: [RFC4585] 350 All Feedback messages have a common packet format, which includes 351 the SSRC of the packet sender and the one of the media source the 352 feedack is related to. Just as described for the previous 353 messages, these SSRC identifiers MUST be updated if the B2BUA has 354 changed any SSRC in any direction. It MUST NOT, though, change a 355 media source SSRC that was originally set to zero. Besides, 356 considering that many feedback messages also include additional 357 data as part of their specific Feedback Control Information (FCI), 358 a media-aware B2BUA MUST take care of them accordingly, if it can 359 parse and regenerate them, according to the following guidelines. 361 NACK: [RFC4585] 362 Besides the common packet format management for feedback messages, 363 a media-aware B2BUA MUST also properly rewrite the Packet ID (PID) 364 of all addressed lost packets in the NACK FCI if it changed the 365 RTP sequence numbers before forwarding a packet. 367 TMMBR/TMMBN/FIR/TSTR/TSTN/VBCM: [RFC5104] 368 Besides the common packet format management for feedback messages, 369 a media-aware B2BUA MUST also properly rewrite the additional SSRC 370 identifier all those messages envisage as part of their specific 371 FCI if it changed the related RTP SSRC of the media sender. 373 REMB: [I-D.alvestrand-rmcat-remb] 374 Besides the common packet format management for feedback messages, 375 a media-aware B2BUA MUST also properly rewrite the additional SSRC 376 identifier(s) REMB packets envisage as part of their specific FCI 377 if it changed the related RTP SSRC of the media sender. 379 Apart from the generic guidelines related to Feedback messages, no 380 additional modifications are needed for PLI, SLI and RPSI feedback 381 messages instead. 383 Of course, the same considerations about the need for SDP and RTP/ 384 RTCP information to be coherent also applies to media-aware B2BUAs. 385 This means that, if a B2BUA is going to change any SSRC, it SHOULD 386 update the related 'ssrc' attributes if they were present in the 387 original description before sending it to the recipient, just as it 388 MUST rewrite the 'rtcp' attribute if provided. At the same time, the 389 ability for a media-aware B2BUA to inspect/modify RTCP packets may 390 also mean such a B2BUA may choose to drop RTCP packets it can't 391 parse: in that case, a media-aware B2BUA SHOULD also advertize its 392 RTCP level of support in the SDP in a coherent way, in order to 393 prevent, for instance, a UAC to make use of NACK messages that would 394 never reach the intended recipients. 396 3.3. Media Terminator 398 A Media Terminator B2BUA, unlike simple relays and media-aware ones, 399 is also able to terminate media itself, that is taking care of RTP 400 payloads as well and not only headers. This means that such 401 components, for instance, can act as media transcoders and/or 402 originate specific RTP media. Using the RTP Topologies terminology, 403 this can be seen as a RTP Media Translator. Such a capability makes 404 them quite different from the previously introduced B2BUA typologies, 405 as this means they are going to terminate RTCP as well: in fact, 406 since the media is terminated by themselves, the related statistics 407 and feedback functionality can be taken care directly by the B2BUA, 408 and does not need to be relayed to the logical peer in the multimedia 409 communication. 411 For this reason, no specific guideline is needed to ensure a proper 412 end-to-end RTCP behaviour in such scenarios, mostly because most of 413 the times there would be no end-to-end RTCP interaction among the 414 involved peers at all, as the B2BUA would terminate them all and take 415 care of them accordingly. Nevertheless, should any RTCP packet 416 actually need to be delivered to the actual peer, the same guidelines 417 provided for the media-aware B2BUA case apply. 419 4. Media Path Security 421 The discussion made in the previous sections on the management of 422 RTCP messages by a B2BUA has so far mostly worked under the 423 assumption that the B2BUA has actually access to the RTP/RTCP 424 information itself. This is indeed true if we assume that plain RTP 425 and RTCP is being handled, but this may not be true once any security 426 is enforced on RTP packets and RTCP messages by means of SRTP 428 [RFC3711], whether the keying is done using Secure Descriptions 429 [RFC4568] or DTLS-SRTP [RFC5764]. 431 While typically not an issue in the Media Relay case, where RTP and 432 RTCP packets are forwarded without any modification no matter whether 433 security is involved or not, this could definitely have an impact on 434 Media-aware Relays and Media Terminator B2BUAs. To make a simple 435 example, if we think of a SRTP/SRTCP session across a B2BUA where the 436 B2BUA itself has no access to the keys used to secure the session, 437 there would be no way to manipulate SRTP headers without violating 438 the hashing on the packet; at the same time, there would be no way to 439 rewrite the RTCP information accordingly either, as most of the 440 packet (especially when RTCP compound packets are involved) would be 441 encrypted. 443 For this reason, it is important to point out that the operations 444 described in the previous sections are only possible if the B2BUA has 445 a way to effectively manipulate the packets and messages flowing by. 446 This means that, in case media security is involved, the B2BUA 447 willing to act as either a Media-aware Relay or a Media Terminator 448 must act as an intermediary with respect to the secure sessions. As 449 such, different secure sessions need to be negotiated (either via 450 SDES or DTLS-SRTP) with the involved parties, in order to be able to 451 have access to the unencrypted packets and, if needed, modify them 452 before encrypting them again and forwarding them. It is important to 453 point out that this breaks any end-to-end security mechanism that may 454 be in place, though, as all the involved parties would have a secure 455 communication up to the B2BUA and would have to rely on the B2BUA 456 actually encrypting the communication on the other end as well. 458 5. IANA Considerations 460 This document makes no request of IANA. 462 6. Security Considerations 464 TBD. Not any additional consideration to what the standards already 465 give? Probably this section will need a few words about how NOT 466 following the guidelines can lead to security issues: e.g., not 467 properly translating REMB messages can cause an increasing flow of 468 media packets, that may be seen as attacks to devices that can't 469 handle the amount of data. 471 7. Change Summary 473 Note to RFC Editor: Please remove this whole section. 475 The following are the major changes between the 00 and the 01 476 versions of the draft: 478 o Updated references and mapping per taxonomy RFC (7092). 480 o Added a reference to RTP topologies, and tried a mapping as per- 481 discussion in London. 483 o Added more RTCP packet types to the Media-Aware section. 485 o Clarified that fixing the 'rtcp' SDP attribute is important. 487 o Added a new section on the impact of media security. 489 8. Acknowledgements 491 TBD. 493 9. References 495 9.1. Normative References 497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 498 Requirement Levels", BCP 14, RFC 2119, March 1997. 500 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 501 A., Peterson, J., Sparks, R., Handley, M., and E. 502 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 503 June 2002. 505 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 506 Description Protocol", RFC 4566, July 2006. 508 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 509 with Session Description Protocol (SDP)", RFC 3264, June 510 2002. 512 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 513 Jacobson, "RTP: A Transport Protocol for Real-Time 514 Applications", STD 64, RFC 3550, July 2003. 516 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 517 Initiation Protocol (SIP) Back-to-Back User Agents", RFC 518 7092, December 2013. 520 9.2. Informative References 522 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, 523 January 2008. 525 [I-D.ietf-avtcore-rtp-topologies-update] 526 Westerlund, M. and S. Wenger, "RTP Topologies", draft- 527 ietf-avtcore-rtp-topologies-update-02 (work in progress), 528 May 2014. 530 [I-D.alvestrand-rmcat-remb] 531 Alvestrand, H., "RTCP message for Receiver Estimated 532 Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in 533 progress), October 2013. 535 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 536 "Extended RTP Profile for Real-time Transport Control 537 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 538 2006. 540 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 541 "Codec Control Messages in the RTP Audio-Visual Profile 542 with Feedback (AVPF)", RFC 5104, February 2008. 544 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 545 Media Attributes in the Session Description Protocol 546 (SDP)", RFC 5576, June 2009. 548 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 549 in Session Description Protocol (SDP)", RFC 3605, October 550 2003. 552 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 553 Protocol Extended Reports (RTCP XR)", RFC 3611, November 554 2003. 556 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 557 Protocol (RTCP) Extensions for Single-Source Multicast 558 Sessions with Unicast Feedback", RFC 5760, February 2010. 560 [RFC6284] Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping 561 between Unicast and Multicast RTP Sessions", RFC 6284, 562 June 2011. 564 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 565 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 566 RFC 3711, March 2004. 568 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 569 Description Protocol (SDP) Security Descriptions for Media 570 Streams", RFC 4568, July 2006. 572 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 573 Security (DTLS) Extension to Establish Keys for the Secure 574 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 576 Authors' Addresses 578 Lorenzo Miniero 579 Meetecho 581 Email: lorenzo@meetecho.com 583 Sergio Garcia Murillo 584 Medooze 586 Email: sergio.garcia.murillo@gmail.com 588 Victor Pascual 589 Quobis 591 Email: victor.pascual@quobis.com