idnits 2.17.1 draft-ietf-straw-b2bua-dtls-srtp-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 4, 2016) is 2944 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '4474bis' is mentioned on line 326, but not defined ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-16) exists of draft-ietf-stir-rfc4474bis-08 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 STRAW R. Ravindranath 3 Internet-Draft T. Reddy 4 Intended status: Standards Track G. Salgueiro 5 Expires: October 6, 2016 Cisco 6 V. Pascual 7 Oracle 8 Parthasarathi. Ravindran 9 Nokia Networks 10 April 4, 2016 12 DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back 13 User Agents (B2BUAs) 14 draft-ietf-straw-b2bua-dtls-srtp-12 16 Abstract 18 Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUA) 19 exist on the signaling and media paths between the endpoints. This 20 document describes the behavior of B2BUAs when Secure Real-time 21 Transport (SRTP) security context is set up with the Datagram 22 Transport Layer Security (DTLS) protocol. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 6, 2016. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.2. Goals and Scope of this Document . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. B2BUAs Procedures to Allow End-to-End DTLS-SRTP . . . . . . . 4 63 4. Signaling Plane B2BUA Handling of DTLS-SRTP . . . . . . . . . 5 64 4.1. Proxy-B2BUAs . . . . . . . . . . . . . . . . . . . . . . 5 65 4.2. Signaling-only and SDP-modifying Signaling-only B2BUAs . 5 66 5. Media Plane B2BUA Handling of DTLS-SRTP . . . . . . . . . . . 6 67 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5.1.1. Media Relay . . . . . . . . . . . . . . . . . . . . . 6 69 5.1.2. RTP/RTCP-Aware Media-Aware B2BUA . . . . . . . . . . 8 70 6. Forking Considerations . . . . . . . . . . . . . . . . . . . 9 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 74 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 11.2. Informative References . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 1.1. Overview 84 [RFC5763] describes how Session Initiation Protocol (SIP) [RFC3261] 85 can be used to establish a Secure Real-time Transport Protocol (SRTP) 86 [RFC3711] security context with the Datagram Transport Layer Security 87 (DTLS) [RFC6347] protocol. It describes a mechanism for transporting 88 a certificate fingerprint using Session Description Protocol (SDP) 89 [RFC4566]. The fingerprint identifies the certificate that will be 90 presented during the DTLS handshake. DTLS-SRTP is currently defined 91 for point-to-point media sessions, in which there are exactly two 92 participants. Each DTLS-SRTP session (described in Section 3 of 93 [RFC5764]) contains a single DTLS connection (if RTP and RTCP are 94 multiplexed) or two DTLS connections (if RTP and RTCP are not 95 multiplexed), and either two SRTP contexts (if media traffic is 96 flowing in both directions on the same 5-tuple) or one SRTP context 97 (if media traffic is only flowing in one direction). 99 In many SIP deployments, SIP Back-to-Back User Agents (B2BUA) 100 entities exist on the SIP signaling path between the endpoints. As 101 described in [RFC7092], these B2BUAs can modify SIP and SDP 102 information. For example, as described in Section 3.1.3 of 103 [RFC7092], SDP-modifying signaling-only B2BUAs can potentially modify 104 the SDP. B2BUAs can also be present on the media path, in which case 105 they modify parts of the SDP information (like IP address, port) and 106 subsequently modify the RTP headers as well. Such B2BUAs are 107 referred to as media plane B2BUAs. [RFC7092] describes two different 108 categories of media plane B2BUAs, according to the level of 109 activities performed on the media plane. 111 When B2BUAs are present in a call between two SIP User Agents (UAs) 112 they often make end-to-end DTLS-SRTP sessions impossible. End-to-end 113 DTLS-SRTP session means that man-in-middle devices cannot break the 114 DTLS-SRTP session between the endpoints. In other words, the man-in- 115 middle device cannot create a separate DTLS-SRTP session between the 116 client and the middle device, on one side, and the middle device and 117 the remote peer on the other side. B2BUAs may be deployed for 118 address hiding or media latching [RFC7362], although TURN (and ICE) 119 is expected to be used more often for this purpose as it provides 120 better security properties. Such B2BUAs are able to perform their 121 functions without requiring termination of DTLS-SRTP sessions i.e. 122 these B2BUAs need not act as DTLS proxy and decrypt the RTP payload. 124 1.2. Goals and Scope of this Document 126 A B2BUA could be deployed for address hiding or media latching, as 127 described in [RFC7362]. Such B2BUAs only terminate the media plane 128 at the IP and transport (UDP/TCP) layers and may inspect the RTP 129 headers or RTP Control Protocol (RTCP) packets. The goal of this 130 specification is to provide guidance on how such B2BUAs function 131 without breaking the end-to-end DTLS-SRTP session. A B2BUA could 132 also terminate the media or modify the RTP headers or RTP Control 133 Protocol (RTCP) packets. Such B2BUAs will not allow end-to-end DTLS- 134 SRTP. The recommendations made in this document are not expected to 135 be applied by B2BUAs terminating DTLS-SRTP sessions given deployment 136 reality. 138 This specification assumes that a B2BUA is not providing identity 139 assurance and is not authorized to terminate the DTLS-SRTP session. 140 A B2BUA that provides identity assurance on behalf of endpoints 141 behind it can modify any portion of SIP and SDP before it generates 142 the identity signature. As the B2BUA is generating the identity 143 signature it is not possible to detect if a B2BUA has terminated the 144 DTLS-SRTP session. B2BUAs providing identity assurance and 145 terminating DTLS-SRTP session are out of scope of this document. 147 The following sections describe the behavior B2BUAs can follow to 148 avoid breaking end-to-end DTLS-SRTP sessions. 150 2. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 Transport Address: The combination of an IP address and port number. 158 The following generalized terms are defined in [RFC3261], Section 6. 160 B2BUA: a SIP Back-to-Back User Agent, which is the logical 161 combination of a User Agent Server (UAS) and User Agent Client 162 (UAC). 164 UAS: a SIP User Agent Server. 166 UAC: a SIP User Agent Client. 168 All of the pertinent B2BUA terminology and taxonomy used in this 169 document is based on [RFC7092]. 171 It is assumed the reader is already familiar with the fundamental 172 concepts of the RTP protocol [RFC3550] and its taxonomy [RFC7656], as 173 well as those of SRTP [RFC3711], and DTLS [RFC6347]. 175 3. B2BUAs Procedures to Allow End-to-End DTLS-SRTP 177 A B2BUA MUST follow the rules mentioned below to allow end-to-end 178 DTLS-SRTP session. 180 1. B2BUAs MUST forward the certificate fingerprint and SDP setup 181 attribute it receives from one endpoint unmodified towards the 182 other endpoint and vice-versa. 184 2. [RFC4474] provides a means for signing portions of SIP requests 185 in order to provide identity assurance and certificate pinning by 186 providing an identity signature over the SDP that carries the 187 fingerprint of keying for DTLS-SRTP [RFC5763]. B2BUAs can 188 identify that [RFC4474] is used for identity assurance if the SIP 189 request contains both Identity and Identity-Info headers. In 190 cases where endpoints use [RFC4474], B2BUAs MUST ensure that it 191 does not modify any of the information used to construct the 192 identity signature. This includes the entire SDP body and 193 portions of SIP header as described in [RFC4474]. In this case, 194 a B2BUA cannot act as a media relay B2BUA. 196 3. [I-D.ietf-stir-rfc4474bis] is introduced to overcome the 197 limitations of [RFC4474] (discussed in Section 1 of 198 [I-D.ietf-stir-rfc4474bis]). Unlike [RFC4474], 199 [I-D.ietf-stir-rfc4474bis] does not generate identity signature 200 over material that intermediaries in the field commonly alter. 201 In this case, a B2BUA can act as a media relay B2BUA. B2BUAs can 202 identify that [I-D.ietf-stir-rfc4474bis] is used for identity 203 assurance if the SIP request contains an Identity header but does 204 not include an Identity-Info header. The Identity-Info header is 205 deprecated in [I-D.ietf-stir-rfc4474bis]. A B2BUA MUST ensure 206 that it does not modify any of the headers used to construct the 207 identity signature. 209 4. Both media relays and media-aware relays MUST NOT modify the 210 authenticated portion of RTP and RTCP packets, and MUST NOT 211 modify the authentication tag in the RTP and RTCP packets. 213 4. Signaling Plane B2BUA Handling of DTLS-SRTP 215 Section 3.1 of [RFC7092] describes different categories of signaling 216 plane B2BUAs. This section explains how these B2BUAs are expected to 217 comply with the recommendations in Section 3. 219 4.1. Proxy-B2BUAs 221 Proxy-B2BUAs, as defined in Section 3.1.1 of [RFC7092], modify only 222 the Via and Record-Route SIP headers. These B2BUAs can continue to 223 perform their function and still allow end-to-end DTLS-SRTP sessions 224 since it does not modify any of the headers used to construct the 225 identity signature. 227 4.2. Signaling-only and SDP-modifying Signaling-only B2BUAs 229 These categories of B2BUAs are likely to modify headers that are used 230 to construct the identity signature. For example, a signaling-only 231 B2BUA can modify the Contact URI. Such B2BUAs are likely to violate 232 rule 2 or rule 3 in Section 3. Depending upon the application 233 requirements, such a B2BUA may be able to limit modification of 234 header fields to those allowed to be modified by [RFC4474] or 235 [I-D.ietf-stir-rfc4474bis]. 237 5. Media Plane B2BUA Handling of DTLS-SRTP 239 5.1. General 241 This section describes how the different types of media plane B2BUAs 242 defined in [RFC7092] are expected to comply with the recommendations 243 in Section 3. 245 5.1.1. Media Relay 247 A media relay, as defined in Section 3.2.1 of [RFC7092], from an 248 application layer point-of-view, forwards all packets it receives on 249 a negotiated connection, without inspecting or modifying the packet 250 contents. A media relay only modifies the transport layer (UDP/TCP) 251 and IP headers. 253 A media relay B2BUA follows the rule 1 mentioned in Section 3 and 254 forwards the certificate fingerprint and SDP setup attribute it 255 receives from one endpoint unmodified towards the other endpoint and 256 vice-versa. The example below shows a SIP call establishment flow, 257 with both SIP endpoints (user agents) using DTLS-SRTP, and a media 258 relay B2BUA. 260 +-------+ +------------------+ +-----+ 261 | Alice | | MediaRelay B2BUA | | Bob | 262 +-------+ +------------------+ +-----+ 263 |(1) INVITE | (3)INVITE | 264 | a=setup:actpass | a=setup:actpass | 265 | a=fingerprint1 | a=fingerprint1 | 266 | (alice's IP/port) | (B2BUAs IP/port) | 267 |------------------------>|-------------------------->| 268 | | | 269 | (2) 100 trying | | 270 |<------------------------| | 271 | | (4) 100 trying | 272 | |<--------------------------| 273 | | | 274 | | (5)200 OK | 275 | | a=setup:active | 276 | | a=fingerprint2 | 277 | | (Bob's IP/port) | 278 |<------------------------|<--------------------------| 279 | (6) 200 OK | | 280 | a=setup:active | | 281 | a=fingerprint2 | | 282 | B2BUAs IP/port | | 283 | (7, 8)ClientHello + use_srtp | 284 |<----------------------------------------------------| 285 |(B2BUA changes transport(UDP/TCP) and IP header) | 286 | | | 287 | | | 288 | (9,10)ServerHello + use_srtp | 289 |---------------------------------------------------->| 290 |(B2BUA changes transport(UDP/TCP) and IP header) | 291 | | | 292 | | | 293 | (11) | | 294 | [Certificate exchange between Alice and Bob over | 295 | DTLS ] | | 296 | | | 297 | (12) | | 298 |<---------SRTP/SRTCP-----------SRTP/SRTCP----------->| 299 | [B2BUA changes transport(UDP/TCP) and IP headers] | 301 Figure 1: INVITE with SDP call-flow for Media Relay B2BUA 303 NOTE: For brevity the entire value of the SDP fingerprint attribute 304 is not shown. The example here shows only one DTLS connection for 305 the sake of simplicity. In reality depending on whether the RTP and 306 RTCP flows are multiplexed or demultiplexed there will be one or two 307 DTLS connections. 309 If RTP and RTCP traffic is multiplexed as described in [RFC5761] on a 310 single port then only a single DTLS connection is required between 311 the peers. If RTP and RTCP are not multiplexed, then the peers would 312 have to establish two DTLS connections. In this case, Bob, after he 313 receives an INVITE request, triggers the establishment of a DTLS 314 connection. Note that the DTLS handshake and the sending of INVITE 315 response can happen in parallel; thus, the B2BUA has to be prepared 316 to receive DTLS, STUN and media on the ports it advertised to Bob in 317 the SDP offer before it receives a SDP answer from Bob. Since a media 318 relay B2BUA does not differentiate between a DTLS message, RTP or any 319 packet it receives, it only changes the transport layer (UDP/TCP) and 320 IP headers and forwards the packet towards the other endpoint. The 321 B2BUA cannot decrypt the RTP payload as the payload is encrypted 322 using the SRTP keys derived from the DTLS connection setup between 323 Alice and Bob. 325 If the endpoints use [RFC4474], a B2BUA cannot function as a media- 326 relay without violating rule 2 in Section 3. If [4474bis] is used, a 327 B2BUA can modify the IP address in the c= line and the port in the m= 328 line, as shown in Figure 1, as long as it does not otherwise violate 329 rule 3 in Section 3. 331 5.1.2. RTP/RTCP-Aware Media-Aware B2BUA 333 Unlike the media relay discussed in Section 5.1.1, a media-aware 334 relay as defined in Section 3.2.2 of [RFC7092], is aware of the type 335 of media traffic it is receiving. There are two types of media-aware 336 relays, those that merely inspect the RTP headers and unencrypted 337 portions of RTCP packets, and those that inspect and modify the RTP 338 headers and unencrypted portions of RTCP packets. 340 5.1.2.1. RTP Header and RTCP Packets Inspection 342 A RTP/RTCP aware media relay does not modify the RTP headers and RTCP 343 packets but only inspects the packets. Such B2BUAs follow rule 4 in 344 Section 3 and can continue to do their function while allowing end- 345 to-end DTLS-SRTP. Inspection by the B2BUA will not reveal the clear- 346 text for encrypted parts of the SRTP/SRTCP packets. 348 5.1.2.2. RTP Header and RTCP Packet Modification 350 A B2BUA cannot modify RTP headers or RTCP packets, as to do so it 351 would need to act as a DTLS endpoint, terminate the DTLS-SRTP session 352 and decrypt/re-encrypt RTP packets. If a B2BUA modifies unencrypted 353 or encrypted portions of the RTP or RTCP packets then the integrity 354 check will fail and the packet will be dropped by the endpoint. The 355 unencrypted and encrypted portions of the RTP or RTCP packets are 356 integrity protected using the HMAC algorithm negotiated during DTLS 357 handshake (discussed in Section 4.1.2 of [RFC5764]). B2BUAs have to 358 follow the rules in Section 3 to avoid breaking integrity of SRTP/ 359 SRTCP streams. 361 6. Forking Considerations 363 Due to forking [RFC3261], a SIP request carrying an SDP offer sent by 364 an endpoint (offerer) can reach multiple remote endpoints. As a 365 result, multiple DTLS-SRTP sessions can be established, one between 366 the endpoint that sent the SIP request and each of the remote 367 endpoints that received the request. B2BUAs have to follow rule 1 in 368 Section 3 while handling offer/answer and forward the certificate 369 fingerprints and SDP setup attributes it received in the SDP answer 370 from each endpoint (answerer) unmodified towards the offerer. Since 371 each DTLS connection is setup on a unique 5-tuple, B2BUA replaces the 372 answerer's transport addresses in each answer with its unique 373 transport addresses so that the offerer can establish a DTLS 374 connection with each answerer. The B2BUA acting as a media relay 375 here follows rule 4 mentioned in Section 3. 377 Bob (192.0.2.1:6666) 378 / 379 / 380 / DTLS-SRTP=XXX 381 / 382 / 383 DTLS-SRTP=XXX v 384 <-----------> (192.0.2.3:7777) 385 Alice (192.0.2.0:5555) B2BUA 386 <-----------> (192.0.2.3:8888) 387 DTLS-SRTP=YYY ^ 388 \ 389 \ DTLS-SRTP=YYY 390 \ 391 \ 392 \ 393 Charlie (192.0.2.2:6666) 395 Figure 2: B2BUA handling multiple answers 397 For instance, as shown in Figure 2 Alice sends a request with an 398 offer, and the request is forked. Alice receives answers from both 399 Bob and Charlie. The B2BUA advertises different B2BUA transport 400 address in each answer, as shown in Figure2, where XXX and YYY 401 represent different DTLS-SRTP sessions. The B2BUA replaces Bob's 402 transport address (192.0.2.1:6666) in the answer with its transport 403 address (192.0.2.3:7777) and Charlie's transport address 404 (192.0.2.2:6666) in the answer with its transport address 405 (192.0.2.3:8888). The B2BUA tracks the remote sources (Bob and 406 Charlie) and associates them to the local sources that are used to 407 send packets to Alice. 409 7. Security Considerations 411 This document describes the behavior B2BUAs must follow to avoid 412 breaking end-to-end DTLS-SRTP. Media relays that modify RTP or RTCP, 413 or modify SIP header fields or SDP fields that are protected by the 414 identity signature, are incompatible with end-to-end DTLS-SRTP. Such 415 relays are out of scope for this document. Security considerations 416 discussed in [RFC5763] are also applicable to this document. In 417 addition, the B2BUA behaviors outlined in this document do not impact 418 the security and integrity of a DTLS-SRTP session or the data 419 exchanged over it. A malicious B2BUA can try to break into the DTLS 420 connection, but such an attack can be prevented using the identity 421 validation mechanism discussed in [RFC4474] or 422 [I-D.ietf-stir-rfc4474bis]. Either the endpoints or authentication 423 service proxies involved in the call can use the identity validation 424 mechanisms discussed in [RFC4474] or [I-D.ietf-stir-rfc4474bis] to 425 validate the identity of peers and detect malicious B2BUA's that can 426 attempt to terminate the DTLS connection to decrypt the RTP payload. 428 8. IANA Considerations 430 This document makes no request of IANA. 432 9. Acknowledgments 434 Special thanks to Lorenzo Miniero, Ranjit Avarsala, Hadriel Kaplan, 435 Muthu Arul Mozhi, Paul Kyzivat, Peter Dawes, Brett Tate, Dan Wing, 436 Charles Eckel, Simon Perreault, Albrecht Schwarz, Jens Guballa, 437 Christer Holmberg, Colin Perkins, Ben Campbell and Alissa Cooper for 438 their constructive comments, suggestions, and early reviews that were 439 critical to the formulation and refinement of this document. The 440 authors would also like to thank Dan Romascanu, Vijay K. Gurbani, 441 Francis Dupont, Paul Wouters and Stephen Farrell for their review and 442 feedback of this document. 444 10. Contributors 446 Rajeev Seth provided substantial contributions to this document. 448 11. References 449 11.1. Normative References 451 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 452 Requirement Levels", BCP 14, RFC 2119, 453 DOI 10.17487/RFC2119, March 1997, 454 . 456 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 457 Jacobson, "RTP: A Transport Protocol for Real-Time 458 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 459 July 2003, . 461 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 462 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 463 RFC 3711, DOI 10.17487/RFC3711, March 2004, 464 . 466 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 467 for Establishing a Secure Real-time Transport Protocol 468 (SRTP) Security Context Using Datagram Transport Layer 469 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 470 2010, . 472 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 473 Security (DTLS) Extension to Establish Keys for the Secure 474 Real-time Transport Protocol (SRTP)", RFC 5764, 475 DOI 10.17487/RFC5764, May 2010, 476 . 478 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 479 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 480 January 2012, . 482 11.2. Informative References 484 [I-D.ietf-stir-rfc4474bis] 485 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 486 "Authenticated Identity Management in the Session 487 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-08 488 (work in progress), March 2016. 490 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 491 A., Peterson, J., Sparks, R., Handley, M., and E. 492 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 493 DOI 10.17487/RFC3261, June 2002, 494 . 496 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 497 Authenticated Identity Management in the Session 498 Initiation Protocol (SIP)", RFC 4474, 499 DOI 10.17487/RFC4474, August 2006, 500 . 502 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 503 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 504 July 2006, . 506 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 507 Control Packets on a Single Port", RFC 5761, 508 DOI 10.17487/RFC5761, April 2010, 509 . 511 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 512 Initiation Protocol (SIP) Back-to-Back User Agents", 513 RFC 7092, DOI 10.17487/RFC7092, December 2013, 514 . 516 [RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT 517 Traversal (HNT) for Media in Real-Time Communication", 518 RFC 7362, DOI 10.17487/RFC7362, September 2014, 519 . 521 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 522 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 523 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 524 DOI 10.17487/RFC7656, November 2015, 525 . 527 Authors' Addresses 529 Ram Mohan Ravindranath 530 Cisco 531 Cessna Business Park 532 Sarjapur-Marathahalli Outer Ring Road 533 Bangalore, Karnataka 560103 534 India 536 Email: rmohanr@cisco.com 537 Tirumaleswar Reddy 538 Cisco 539 Cessna Business Park 540 Sarjapur Marathalli Outer Ring Road 541 Bangalore, Karnataka 560103 542 India 544 Email: tireddy@cisco.com 546 Gonzalo Salgueiro 547 Cisco Systems, Inc. 548 7200-12 Kit Creek Road 549 Research Triangle Park, NC 27709 550 US 552 Email: gsalguei@cisco.com 554 Victor Pascual 555 Oracle 556 Barcelona, Spain 558 Email: victor.pascual.avila@oracle.com 560 Parthasarathi Ravindran 561 Nokia Networks 562 Bangalore, Karnataka 563 India 565 Email: partha@parthasarathi.co.in