idnits 2.17.1 draft-ietf-insipid-session-id-23.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 23, 2016) is 2835 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '0-9a-f' is mentioned on line 304, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1647, but not defined -- Obsolete informational reference (is this intentional?): RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Obsolete informational reference (is this intentional?): RFC 7329 (Obsoleted by RFC 7989) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Jones 3 Internet-Draft G. Salgueiro 4 Obsoletes: 7329 (if approved) C. Pearce 5 Intended status: Standards Track P. Giralt 6 Expires: December 25, 2016 Cisco Systems, Inc. 7 June 23, 2016 9 End-to-End Session Identification in IP-Based Multimedia Communication 10 Networks 11 draft-ietf-insipid-session-id-23 13 Abstract 15 This document describes an end-to-end Session Identifier for use in 16 IP-based multimedia communication systems that enables endpoints, 17 intermediary devices, and management systems to identify a session 18 end-to-end, associate multiple endpoints with a given multipoint 19 conference, track communication sessions when they are redirected, 20 and associate one or more media flows with a given communication 21 session. While the identifier is intended to work across multiple 22 protocols, this document describes its usage in SIP. 24 This document also describes a backwards compatibility mechanism for 25 an existing session identifier implementation (RFC 7329) that is 26 sufficiently different from the procedures defined in this document. 28 This document obsoletes RFC 7329. 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 25, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions used in this document . . . . . . . . . . . . . . 3 66 3. Session Identifier Requirements and Use Cases . . . . . . . . 4 67 4. Constructing and Conveying the Session Identifier . . . . . . 4 68 4.1. Constructing the Session Identifier . . . . . . . . . . . 4 69 4.2. Conveying the Session Identifier . . . . . . . . . . . . 5 70 5. The Session-ID Header Field . . . . . . . . . . . . . . . . . 7 71 6. Endpoint Behavior . . . . . . . . . . . . . . . . . . . . . . 8 72 7. Processing by Intermediaries . . . . . . . . . . . . . . . . 10 73 8. Handling of Remote UUID Changes . . . . . . . . . . . . . . . 13 74 9. Associating Endpoints in a Multipoint Conference . . . . . . 14 75 10. Examples of Various Call Flow Operations . . . . . . . . . . 15 76 10.1. Basic Call with 2 UUIDs . . . . . . . . . . . . . . . . 16 77 10.2. Basic Call Transfer using REFER . . . . . . . . . . . . 19 78 10.3. Basic Call Transfer using re-INVITE . . . . . . . . . . 21 79 10.4. Single Focus Conferencing . . . . . . . . . . . . . . . 23 80 10.5. Single Focus Conferencing using a web-based conference 81 service . . . . . . . . . . . . . . . . . . . . . . . . 25 82 10.6. Cascading Conference Bridges . . . . . . . . . . . . . . 27 83 10.6.1. Establishing a Cascaded Conference . . . . . . . . . 27 84 10.6.2. Calling into Cascaded Conference Bridges . . . . . . 28 85 10.7. Basic 3PCC for two UAs . . . . . . . . . . . . . . . . . 29 86 10.8. Handling in 100 Trying SIP Response and CANCEL Request . 30 87 10.8.1. Handling in a 100 Trying SIP Response . . . . . . . 30 88 10.8.2. Handling a CANCEL SIP Request . . . . . . . . . . . 32 89 10.9. Out-of-dialog REFER Transaction . . . . . . . . . . . . 33 90 11. Compatibility with a Previous Implementation . . . . . . . . 34 91 12. Security and Privacy Considerations . . . . . . . . . . . . . 35 92 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 93 13.1. Registration of the "Session-ID" Header Field . . . . . 36 94 13.2. Registration of the "remote" Parameter . . . . . . . . . 36 96 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 97 15. Dedication . . . . . . . . . . . . . . . . . . . . . . . . . 37 98 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 99 16.1. Normative References . . . . . . . . . . . . . . . . . . 37 100 16.2. Informative References . . . . . . . . . . . . . . . . . 38 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 103 1. Introduction 105 IP-based multimedia communication systems like Session Initiation 106 Protocol (SIP) [RFC3261] and [H.323] have the concept of a "call 107 identifier" that is globally unique. The identifier is intended to 108 represent an end-to-end communication session from the originating 109 device to the terminating device. Such an identifier is useful for 110 troubleshooting, session tracking, and so forth. 112 For several reasons, however, the current call identifiers defined in 113 SIP and H.323 are not suitable for end-to-end session identification. 114 A fundamental issue in protocol interworking is the fact that the 115 syntax for the call identifier in SIP and H.323 is different. Thus, 116 if both protocols are used in a call, it is impossible to exchange 117 the call identifier end-to-end. 119 Another reason why the current call identifiers are not suitable to 120 identify a session end-to-end is that, in real-world deployments, 121 devices like session border controllers [RFC7092] often change the 122 session signaling, including the value of the call identifier, as it 123 passes through the device. While this is deliberate and useful, it 124 makes it very difficult to track a session end-to-end. 126 This document defines a new identifier for SIP referred to as the 127 Session Identifier that is intended to overcome the issues that exist 128 with the currently defined call identifiers used in SIP. The 129 procedures specified in this document attempt to comply with the 130 requirements specified in [RFC7206]. The procedures also specify 131 capabilities not mentioned in [RFC7206], shown in call flows in 132 section 10. Additionally, the specification attempts to account for 133 a previous, pre-standard version of a SIP Session Identifier header 134 [RFC7329], specifying a backwards compatibility approach in section 135 11. 137 2. Conventions used in this document 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119] when they 142 appear in ALL CAPS. These words may also appear in this document in 143 lower case as plain English words, absent their normative meanings. 145 The term "Session Identifier" refers to the value of the identifier, 146 whereas "Session-ID" refers to the header field used to convey the 147 identifier. The Session Identifier is a set of two Universally 148 Unique Identifiers (UUIDs) and each element of that set is simply 149 referred to herein as a UUID. 151 Throughout this document, the term "endpoint" refers to a SIP User 152 Agent (UA) that either initiates or terminates a SIP session, such as 153 a user's mobile phone or a conference server, but excludes entities 154 like B2BUAs that are generally located along the call signaling path 155 between endpoints. The term "intermediary" refers to any SIP entity 156 along the call signaling path between the aforementioned endpoints, 157 including Back-to-Back User Agents (B2BUAs) and SIP proxies. In 158 certain scenarios, intermediaries are allowed to originate and 159 terminate SIP messages without an endpoint being part of the session 160 or transaction. 162 3. Session Identifier Requirements and Use Cases 164 Requirements and use cases for the end-to-end Session Identifier, 165 along with a definition of "session identifier" and "communication 166 session", can be found in [RFC7206]. 168 As mentioned in section 6.1 of [RFC7206], the ITU-T undertook a 169 parallel effort to define compatible procedures for an H.323 Session 170 Identifier. They are documented in [H.460.27]. 172 4. Constructing and Conveying the Session Identifier 174 4.1. Constructing the Session Identifier 176 The Session Identifier comprises two UUIDs [RFC4122], with each UUID 177 representing one of the endpoints participating in the session. 179 The version number in the UUID indicates the manner in which the UUID 180 is generated, such as using random values or using the MAC address of 181 the endpoint. To satisfy the requirement that no user or device 182 information be conveyed, endpoints MUST generate version 4 (random) 183 or version 5 (SHA-1) UUIDs to address privacy concerns related to use 184 of MAC addresses in UUIDs. 186 When generating a version 5 UUID, endpoints or intermediaries MUST 187 utilize the procedures defined in Section 4.3 of [RFC4122] and employ 188 the following "name space ID": 190 uuid_t NameSpace_SessionID = { 191 /* a58587da-c93d-11e2-ae90-f4ea67801e29 */ 192 0xa58587da, 193 0xc93d, 194 0x11e2, 195 0xae, 0x90, 0xf4, 0xea, 0x67, 0x80, 0x1e, 0x29 196 } 198 Further, the "name" to utilize for version 5 UUIDs is the 199 concatenation of the Call-ID header-value and the "tag" parameter 200 that appears on the "From" or "To" line associated with the device 201 for which the UUID is created. Once an endpoint generates a UUID for 202 a session, the UUID never changes, even if values originally used as 203 input into its construction change over time. 205 Stateless intermediaries that insert a Session-ID header field into a 206 SIP message on behalf of an endpoint MUST utilize version 5 UUIDs to 207 ensure that UUIDs for the communication session are consistently 208 generated. If a stateless intermediary does not know the tag value 209 for the endpoint (e.g., a new INVITE without a To: tag value or an 210 older SIP implementation [RFC2543] that did not include a tag 211 parameter), the intermediary MUST NOT attempt to generate a UUID for 212 that endpoint. Note that if an intermediary is stateless and the 213 endpoint on one end of the call is replaced with another endpoint due 214 to some service interaction, the values used to create the UUID 215 should change and, if so, the intermediary will compute a different 216 UUID. 218 4.2. Conveying the Session Identifier 220 The SIP User Agent (UA) initially transmitting the SIP request 221 ("Alice"), i.e., a User Agent Client (UAC), will create a new, 222 previously unused, UUID and transmit that to the ultimate destination 223 UA ("Bob"). Likewise, the destination UA ("Bob"), i.e., a User Agent 224 Server (UAS), will create a UUID and transmit that to the first UA 225 ("Alice"). These two distinct UUIDs form what is referred to as the 226 Session Identifier and is represented in this document in set 227 notation of the form {A,B}, where "A" is UUID value created by UA 228 "Alice" and "B" is the UUID value created by UA "Bob". The Session 229 Identifier {A,B} is equal to the Session Identifier {B,A}. 231 In the case where only one UUID is known, such as when a UA first 232 initiates a potentially dialog-initiating SIP request, the Session 233 Identifier would be {A,N}, where "A" represents the UUID value 234 transmitted by the UA "Alice" and "N" is what is referred to as the 235 null UUID (see section 5). 237 Since SIP sessions are subject to any number of service interactions, 238 SIP INVITE messages might be forked as sessions are established, and 239 since conferences might be established or expanded with endpoints 240 calling in or the conference focus calling out, the construction of 241 the Session Identifier as a set of UUIDs is important. 243 To understand this better, consider that an endpoint participating in 244 a communication session might be replaced with another, such as the 245 case where two "legs" of a call are joined together by a Private 246 Branch Exchange (PBX). Suppose "Alice" and "Bob" both call UA C 247 ("Carol"). There would be two distinctly identifiable Session 248 Identifiers, namely {A,C} and {B,C}. Then suppose that "Carol" uses 249 a local PBX function to join the call between herself and "Alice" 250 with the call between herself and "Bob", resulting in a single 251 remaining call between "Alice" and "Bob". This merged call can be 252 identified using two UUID values assigned by each entity in the 253 communication session, namely {A,B} in this example. 255 In the case of forking, "Alice" might send an INVITE that gets forked 256 to several different endpoints. A means of identifying each of these 257 separate communication sessions is needed and, since each of the 258 destination UAs will create its own UUID, each communication session 259 would be uniquely identified by the values {A, B1}, {A, B2}, {A, B3}, 260 and so on, where each of the Bn values refers to the UUID created by 261 the different UAs to which the SIP session is forked. 263 For conferencing scenarios, it is also useful to have a two-part 264 Session Identifier where the conference focus specifies the same UUID 265 for each conference participant. This allows for correlation among 266 the participants in a single conference. For example, in a 267 conference with three participants, the Session Identifiers might be 268 {A,M}, {B,M}, and {C,M}, where "M" is assigned by the conference 269 focus. Only a conference focus will purposely utilize the same UUID 270 for more than one SIP session and, even then, such reuse MUST be 271 restricted to the participants in the same conference. 273 How a device acting on Session Identifiers processes or utilizes the 274 Session Identifier is outside the scope of this document, however 275 devices storing a Session Identifier in a log file SHOULD follow the 276 security considerations outlined in [RFC6872]. Note that the primary 277 intent of a Session Identifier is for troubleshooting and should 278 therefore be included in logs at rest that will be used for 279 troubleshooting purposes. 281 5. The Session-ID Header Field 283 The syntax specified here replaces the Session-ID header field syntax 284 defined in [RFC7329]. 286 Each endpoint participating in a communication session has a 287 distinct, preferably locally-generated, UUID associated with it. The 288 endpoint's UUID value remains unchanged throughout the duration of 289 the communication session. An intermediary MAY generate a UUID on 290 behalf of an endpoint that did not include a UUID of its own. 292 The UUID values for each endpoint are inserted into the "Session-ID" 293 header field of all transmitted SIP messages. The Session-ID header 294 field has the following ABNF [RFC5234] syntax: 296 session-id = "Session-ID" HCOLON session-id-value 298 session-id-value = local-uuid *(SEMI sess-id-param) 300 local-uuid = sess-uuid / null 302 remote-uuid = sess-uuid / null 304 sess-uuid = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] 306 sess-id-param = remote-param / generic-param 308 remote-param = "remote" EQUAL remote-uuid 310 null = 32("0") 312 The productions "SEMI", "EQUAL", and "generic-param" are defined in 313 [RFC3261]. The production DIGIT is defined in [RFC5234]. 315 The Session-ID header field MUST NOT have more than one "remote" 316 parameter. In the case where an entity compliant with this 317 specification is interworking with an entity that implemented 318 [RFC7329], the "remote" parameter may be absent, but otherwise the 319 remote parameter MUST be present. The details under which those 320 conditions apply are described in Section 11. Except for backwards 321 compatibility with [RFC7329], the "remote" parameter MUST be present. 323 A special null UUID value composed of 32 zeros is required in certain 324 situations. A null UUID is expected as the "remote-uuid" of every 325 initial standard SIP request since the initiating endpoint would not 326 initially know the UUID value of the remote endpoint. This null 327 value will get replaced by the ultimate destination UAS when that UAS 328 generates a response message. One caveat is explained in Section 11 329 for a possible backwards compatibility case. A null UUID value is 330 also returned by some intermediary devices that send provisional or 331 other responses as the "local-uuid" component of the Session-ID 332 header field value, as described in Section 7. 334 The "local-uuid" in the Session-ID header field represents the UUID 335 value of the endpoint transmitting a message and the "remote-uuid" in 336 the Session-ID header field represents the UUID of the endpoint's 337 peer. For example, a Session-ID header field might appear like this: 339 Session-ID: ab30317f1a784dc48ff824d0d3715d86; 340 remote=47755a9de7794ba387653f2099600ef2 342 While this is the general form of the Session-ID header field, 343 exceptions to syntax and procedures are detailed in subsequent 344 sections. 346 The UUID values are presented as strings of lower-case hexadecimal 347 characters, with the most significant octet of the UUID appearing 348 first. 350 The Session-ID header field value is technically case-INSENSITIVE, 351 but only lowercase characters are allowed in the sess-uuid 352 components. Receiving entities MUST treat sess-uuid components as 353 case-insensitive and not produce an error if an uppercase hexadecimal 354 character is received. 356 6. Endpoint Behavior 358 To comply with this specification, endpoints (non-intermediaries) 359 MUST include a Session-ID header field value in all SIP messages 360 transmitted as a part of a communication session. The locally- 361 generated UUID of the transmitter of the message MUST appear in the 362 "local-uuid" portion of the Session-ID header field value. The UUID 363 of the peer device, if known, MUST appear as the "remote" parameter 364 following the transmitter's UUID. The null UUID value MUST be used 365 if the peer device's UUID is not known. 367 Once an endpoint allocates a UUID value for a communication session, 368 the endpoint originating the request MUST NOT change that UUID value 369 for the duration of the session, including when 371 o communication attempts are retried due to receipt of 4xx messages 372 or request timeouts; 374 o the session is redirected in response to a 3xx message; 376 o a session is transferred via a REFER message [RFC3515]; or 377 o a SIP dialog is replaced via an INVITE with Replaces [RFC3891]. 379 An endpoint that receives a Session-ID header field MUST take note of 380 any non-null "local-uuid" value that it receives and assume that is 381 the UUID of the peer endpoint within that communications session. 382 Endpoints MUST include this received UUID value as the "remote" 383 parameter when transmitting subsequent messages, making sure not to 384 change this UUID value in the process of moving the value internally 385 from the "local-uuid" field to the "remote-uuid" field. 387 If an endpoint receives a 3xx message, receives a REFER that directs 388 the endpoint to a different peer, or receives an INVITE with Replaces 389 that also potentially results in communicating with a new peer, the 390 endpoint MUST complete any message exchanges with its current peer 391 using the existing Session Identifier, but MUST NOT use the current 392 peer's UUID value when sending the first message to what it believes 393 may be a new peer endpoint (even if the exchange results in 394 communicating with the same physical or logical entity). The 395 endpoint MUST retain its own UUID value, however, as described above. 397 It should be noted that messages received by an endpoint might 398 contain a "local-uuid" value that does not match what the endpoint 399 expected its peer's UUID to be. It is also possible for an endpoint 400 to receive a "remote-uuid" value that does not match its generated 401 UUID for the session. Either might happen as a result of service 402 interactions by intermediaries and MUST NOT affect the communication 403 session. However, the endpoint may log this event for the purposes 404 of troubleshooting. 406 An endpoint MUST assume that the UUID value of the peer endpoint may 407 change at any time due to service interactions. Section 8 discusses 408 how endpoints must handle remote UUID changes. 410 It is also important to note that if an intermediary in the network 411 forks a session, the endpoint initiating a session may receive 412 multiple responses back from different endpoints, each of which 413 contains a different UUID ("local-uuid") value. Endpoints MUST 414 ensure that the correct UUID value is returned in the "remote" 415 parameter when interacting with each endpoint. The one exception is 416 when the endpoint sends a CANCEL message, in which case the Session- 417 ID header field value MUST be identical to the Session-ID header 418 field value sent in the original request. 420 If an endpoint receives a message that does not contain a Session-ID 421 header field, that message must have no effect on what the endpoint 422 believes is the UUID value of the remote endpoint. That is, the 423 endpoint MUST NOT change the internally maintained "remote-uuid" 424 value for the peer. 426 If an endpoint receives a SIP response with a non-null "local-uuid" 427 that is not 32 octets long, this response comes from a misbehaving 428 implementation, and its Session-ID header field MUST be discarded. 429 That said, the response might still be valid according to the rules 430 within SIP [RFC3261], and SHOULD be checked further. 432 A Multipoint Control Unit (MCU) is a special type of conferencing 433 endpoint and is discussed in Section 9. 435 7. Processing by Intermediaries 437 The following applies only to an intermediary that wishes to comply 438 with this specification and does not impose a conformance requirement 439 on intermediaries that elect to not provide any special treatment for 440 the Session-ID header field. Intermediaries that do not comply with 441 this specification might pass the header unchanged or drop it 442 entirely. 444 The Call-ID often reveals personal, device, domain or other sensitive 445 information associated with a user, which is one reason why 446 intermediaries, such as session border controllers, sometimes alter 447 the Call-ID. In order to ensure the integrity of the end-to-end 448 Session Identifier, it is constructed in a way which does not reveal 449 such information, removing the need for intermediaries to alter it. 451 When an intermediary receives messages from one endpoint in a 452 communication session that causes the transmission of one or more 453 messages toward the second endpoint in a communication session, the 454 intermediary MUST include the Session-ID header field in the 455 transmitted messages with the same UUID values found in the received 456 message, except as outlined in this section and in section 8. 458 If the intermediary aggregates several responses from different 459 endpoints, as described in Section 16.7 of [RFC3261], the 460 intermediary MUST set the local-uuid field to the null UUID value 461 when forwarding the aggregated response to the endpoint since the 462 true UUID value of the peer is undetermined at that point. Note that 463 an intermediary that does not implement this specification might 464 forward a non-null value, resulting in the originating endpoint 465 receiving different UUID values in the responses. It is possible for 466 this to result in the endpoint temporarily using the wrong remote 467 UUID. Subsequent messages in the dialog should resolve the temporary 468 mismatch as long as the endpoint follows the rules outlined in 469 Section 8 dealing with the handling of remote UUID changes. 471 Intermediary devices that transfer a call, such as by joining 472 together two different "call legs", MUST properly construct a 473 Session-ID header field that contains the UUID values associated with 474 the endpoints involved in the joined session and correct placement of 475 those values. As described in Section 6, the endpoint receiving a 476 message transmitted by the intermediary will assume that the first 477 UUID value belongs to its peer endpoint. 479 If an intermediary receives a SIP message without a Session-ID header 480 field or valid header field value from an endpoint for which the 481 intermediary is not storing a "remote-uuid" value, the intermediary 482 MAY assign a "local-uuid" value to represent that endpoint and, 483 having done so, MUST insert that assigned value into all signaling 484 messages on behalf of the endpoint for that dialog. In effect, the 485 intermediary becomes dialog stateful and it MUST follow the endpoint 486 procedures in Section 6 with respect to Session-ID header field value 487 treatment with itself acting as the endpoint (for the purposes of the 488 Session-ID header field) for which it inserted a component into the 489 Session-ID header field value. If the intermediary is aware of the 490 UUID value that identifies the endpoint to which a message is 491 directed, it MUST insert that UUID value into the Session-ID header 492 field value as the "remote-uuid" value. If the intermediary is 493 unaware of the UUID value that identifies the receiving endpoint, it 494 MUST use the null UUID value as the "remote-uuid" value. 496 If an intermediary receives a SIP message without a Session-ID header 497 field or valid Session-ID header field value from an endpoint for 498 which the intermediary has previously received a Session-ID and is 499 storing a "remote-uuid" value for that endpoint, the lack of a 500 Session-ID must have no effect on what the intermediary believes is 501 the UUID value of the endpoint. That is, the intermediary MUST NOT 502 change the internally maintained "remote-uuid" value for the peer. 504 When an intermediary originates a response, such as a provisional 505 response or a response to a CANCEL request, the "remote-uuid" field 506 will contain the UUID value of the receiving endpoint. When the UUID 507 of the peer endpoint is known, the intermediary MUST insert the UUID 508 of the peer endpoint in the "local-uuid" field of the header value. 509 Otherwise, the intermediary MAY set the "local-uuid" field of the 510 header value to the "null" UUID value. 512 When an intermediary originates a request message without first 513 having received a SIP message that triggered the transmission of the 514 message (e.g., sending a BYE message to terminate a call for policy 515 reasons), the intermediary MUST, if it has knowledge of the UUID 516 values for the two communicating endpoints, insert a Session-ID 517 header field with the "remote-uuid" field of the header value set to 518 the UUID value of the receiving endpoint and the "local-uuid" field 519 of the header value set to the UUID value of the other endpoint. 520 When the intermediary does not have knowledge of the UUID value of an 521 endpoint in the communication session, the intermediary SHOULD set 522 the unknown UUID value(s) to the "null" UUID value. (If both are 523 unknown, the Session-ID header value SHOULD NOT be included at all, 524 since it would have no practical value.) 526 With respect to the previous two paragraphs, note that if an 527 intermediary transmits a "null" UUID value, the receiving endpoint 528 might use that value in subsequent messages it sends. This 529 effectively violates the requirement of maintaining an end-to-end 530 Session Identifier value for the communication session if a UUID for 531 the peer endpoint had been previously conveyed. Therefore, an 532 intermediary MUST only send the "null" UUID when the intermediary has 533 not communicated with the peer endpoint to learn its UUID. This 534 means that intermediaries SHOULD maintain state related to the UUID 535 values for both ends of a communication session if it intends to 536 originate messages (versus merely conveying messages). An 537 intermediary that does not maintain this state and that originates a 538 message as described in the previous two paragraphs MUST NOT insert a 539 Session-ID header field in order to avoid unintended, incorrect 540 reassignment of a UUID value. 542 The Session-ID header field value included in a CANCEL request MUST 543 be identical to the Session-ID header field value included in the 544 corresponding request. 546 If a SIP intermediary initiates a dialog between two endpoints in a 547 3PCC [RFC3725] scenario, the SIP request in the initial INVITE will 548 have a non-null, locally-frabricated "local-uuid" value; call this 549 temporary UUID X. The request will still have a null "remote-uuid" 550 value; call this value N. The SIP server MUST be transaction 551 stateful. The UUID pair in the INVITE will be {X,N}. A 1xx or 2xx 552 response will have a UUID pair {A,X}. This transaction stateful, 553 dialog initiating SIP server MUST replace its own UUID, i.e., X, with 554 a null UUID (i.e., {A,N}) in the INVITE sent towards the other UAS as 555 expected (see Section 10.7 for an example). 557 Intermediaries that manipulate messages containing a Session-ID 558 header field SHOULD be aware of what UUID values it last sent towards 559 an endpoint and, following any kind of service interaction initiated 560 or affected by the intermediary, of what UUID values the receiving 561 endpoint should have knowledge to ensure that both endpoints in the 562 session have the correct and same UUID values. If an intermediary 563 can determine that an endpoint might not have received a current, 564 correct Session-ID field, the intermediary SHOULD attempt to provide 565 the correct Session-ID header field to the endpoint such as by 566 sending a re-INVITE message. Failure to take such measures may make 567 troubleshooting more difficult because of the mismatched identifiers, 568 therefore it is strongly advised that intermediaries attempt to 569 provide the correct Session Identifier if it able to do so. 571 If an intermediary receives a SIP response with a non-null "local- 572 uuid" that is not 32 octets long, this response comes from a 573 misbehaving implementation, and its Session-ID header field MUST be 574 discarded. That said, the response might still be valid according to 575 the rules within SIP [RFC3261], and SHOULD be checked further. 577 An intermediary MUST assume that the UUID value of session peers may 578 change at any time due to service interactions and MAY itself change 579 UUID values for sessions under its control to ensure end to end 580 session identifiers are consistent for all participants in a session. 581 Section 8 discusses how intermediaries must handle remote UUID 582 changes if they maintain state of the session identifier. 584 8. Handling of Remote UUID Changes 586 It is desirable to have all endpoints and intermediaries involved in 587 a session agree upon the current session identifier when these 588 changes occur. Due to race conditions or certain interworking 589 scenarios, it is not always possible to guarantee session identifier 590 consistency; however, in an attempt to ensure the highest likelihood 591 of consistency, all endpoints and intermediaries involved in a 592 session MUST accept a peer's new UUID under the following conditions: 594 o When an endpoint or intermediary receives a mid-dialog request 595 containing a new UUID from a peer, all responses to that request 596 MUST contain the new UUID value as the "remote" parameter unless a 597 subsequent successful transaction (for example, an UPDATE) 598 contains a different UUID, in which case the newest UUID MUST be 599 used. 601 o If an endpoint or intermediary sends a successful (2xx) or 602 redirection (3xx) response to the request containing the new UUID 603 value, the endpoint or intermediary MUST accept the peer's UUID 604 and include this new UUID as the "remote" parameter for any 605 subsequent messages unless the UUID from a subsequent transaction 606 has already been accepted. The one exception is a CANCEL request 607 as outlined below. 609 o If the endpoint or intermediary sends a failure (4xx, 5xx, 6xx) 610 response, it MUST NOT accept the new UUID value and any subsequent 611 messages MUST contain the previously stored UUID value in the 612 "remote" parameter for any subsequent message. Note that the 613 failure response itself will contain the new UUID value from the 614 request in the "remote" parameter. 616 o The ACK method is a special case as there is no response. When an 617 endpoint or intermediary receives an ACK for a successful (2xx) or 618 redirection (3xx) response with a new UUID value, it MUST accept 619 the peer's new UUID value and include this new UUID as the 620 "remote" parameter for any subsequent messages. If the ACK is for 621 a failure (4xx, 5xx, 6xx) response, the new value MUST NOT be 622 used. 624 o As stated in Section 6 and Section 7, the Session-ID header field 625 value included in a CANCEL request MUST be identical to the 626 Session-ID header field value included in the corresponding 627 INVITE. Upon receiving a CANCEL request, an endpoint or 628 intermediary would normally send a 487 response which, by the 629 rules outlined above, would result in the endpoint or intermediary 630 not storing any UUID value contained in the CANCEL. Section 3.8 631 of [RFC6141] specifies conditions where a CANCEL can result in 2xx 632 response. Because CANCEL is not passed end-to-end and will always 633 contain the UUID from the original INVITE, retaining a new UUID 634 value received in a CANCEL may result in inconsistency with the 635 Session-ID value stored on the endpoints and intermediaries 636 involved in the session. To avoid this situation, an endpoint or 637 intermediary MUST NOT accept the new UUID value received in a 638 CANCEL and any subsequent messages MUST contain the previously 639 stored UUID value in the "remote" parameter". Note that the 640 response to the CANCEL will contain the UUID value from the CANCEL 641 request in the "remote" parameter. 643 o When an endpoint or intermediary receives a response containing a 644 new UUID from a peer, the endpoint or intermediary MUST accept the 645 new UUID as the peer's UUID and include this new UUID as the 646 "remote" parameter for any subsequent messages. 648 When an intermediary accepts a new UUID from a peer, the intermediary 649 SHOULD attempt to provide the correct Session-ID header field to 650 other endpoints involved in the session, for example, by sending a 651 re-INVITE message. If an intermediary receives a message with a 652 "remote" parameter in the session identifier that does not match the 653 updated UUID, the intermediary MUST update the "remote" parameter 654 with the latest stored UUID. 656 9. Associating Endpoints in a Multipoint Conference 658 Multipoint Control Units (MCUs) group two or more sessions into a 659 single multipoint conference and have a conference Focus responsible 660 for maintaining the dialogs connected to it [RFC4353]. MCUs, 661 including cascaded MCUs, MUST utilize the same UUID value ("local- 662 uuid" portion of the Session-ID header field value) with all 663 participants in the conference. In so doing, each individual session 664 in the conference will have a unique Session Identifier (since each 665 endpoint will create a unique UUID of its own), but will also have 666 one UUID in common with all other participants in the conference. 668 When creating a cascaded conference, an MCU MUST convey the UUID 669 value to utilize for a conference via the "local-uuid" portion of the 670 Session-ID header field value in an INVITE to a second MCU when using 671 SIP to establish the cascaded conference. A conference bridge, or 672 MCU, needs a way to identify itself when contacting another MCU. 673 [RFC4579] defines the "isfocus" Contact header field value parameter 674 just for this purpose. The initial MCU MUST include the UUID of that 675 particular conference in the "local-uuid" of an INVITE to the other 676 MCU(s) participating in that conference. Also included in this 677 INVITE is an "isfocus" Contact header field value parameter 678 identifying that this INVITE is coming from an MCU and that this UUID 679 is to be given out in all responses from endpoints into those MCUs 680 participating in this same conference. This ensures a single UUID is 681 common across all participating MCUs of the same conference, but is 682 unique between different conferences. 684 In the case where two existing conferences are joined, there should 685 be a session between the two MCUs where the Session Identifier is 686 comprised of the UUID values of the two conferences. This Session 687 Identifier can be used to correlate the sessions between participants 688 in the joined conference. This specification does not impose any 689 additional requirements when two existing conferences are joined. 691 Intermediary devices or network diagnostics equipment might assume 692 that when they see two or more sessions with different Session 693 Identifiers, but with one UUID in common, that the sessions are part 694 of the same conference. However, the assumption that two sessions 695 having one common UUID being part of the same conference is not 696 always correct. In a SIP forking scenario, for example, there might 697 also be what appears to be multiple sessions with a shared UUID 698 value; this is intended. The desire is to allow for the association 699 of related sessions, regardless of whether a session is forked or 700 part of a conference. 702 10. Examples of Various Call Flow Operations 704 Seeing something frequently makes understanding easier. With that in 705 mind, this section includes several call flow examples with the 706 initial UUID and the complete Session Identifier indicated per 707 message, as well as when the Session Identifier changes according to 708 the rules within this document during certain operations/functions. 710 This section is for illustrative purposes only and is non-normative. 711 In the following flows, RTP refers to the Real-time Transport 712 Protocol [RFC3550]. 714 In the examples in this section, "N" represents a null UUID and other 715 letters represents the unique UUID values corresponding to endpoints 716 or MCUs. 718 10.1. Basic Call with 2 UUIDs 720 Session-ID 721 --- Alice B2BUA Bob Carol 722 {A,N} |---INVITE F1--->| | 723 {A,N} | |---INVITE F2--->| 724 {B,A} | |<---200 OK F3---| 725 {B,A} |<---200 OK F4---| | 726 {A,B} |-----ACK F5---->| | 727 {A,B} | |-----ACK F6---->| 728 |<==============RTP==============>| 730 Figure 1: Session-ID Creation when Alice calls Bob 732 General operation of this example: 734 o UA-Alice populates the "local-uuid" portion of the Session-ID 735 header field value. 737 o UA-Alice sends its UUID in the SIP INVITE, and populates the 738 "remote" parameter with a null value (32 zeros). 740 o B2BUA receives an INVITE with both a "local-uuid" portion of the 741 Session-ID header field value from UA-Alice as well as the null 742 "remote-uuid" value, and transmits the INVITE towards UA-Bob with 743 an unchanged Session-ID header field value. 745 o UA-Bob receives Session-ID and generates its "local-uuid" portion 746 of the Session-ID header field value UUID to construct the whole/ 747 complete Session-ID header field value, at the same time 748 transferring Alice's UUID unchanged to the "remote-uuid" portion 749 of the Session-ID header field value in the 200 OK SIP response. 751 o B2BUA receives the 200 OK response with a complete Session-ID 752 header field value from UA-Bob, and transmits 200 OK towards UA- 753 Alice with an unchanged Session-ID header field value. 755 o UA-Alice, upon reception of the 200 OK from the B2BUA, transmits 756 the ACK towards the B2BUA. The construction of the Session-ID 757 header field in this ACK is that of Alice's UUID is the "local- 758 uuid", and Bob's UUID populates the "remote-uuid" portion of the 759 header-value. 761 o B2BUA receives the ACK with a complete Session-ID header field 762 from UA-Alice, and transmits ACK towards UA-Bob with an unchanged 763 Session-ID header field value. 765 Below is a SIP message exchange illustrating proper use of the 766 Session-ID header field. For the sake of brevity, non-essential 767 headers and message bodies are omitted. 769 F1 INVITE Alice -> B2BUA 771 INVITE sip:bob@biloxi.com SIP/2.0 772 Via: SIP/2.0/UDP pc33.atlanta.example.com 773 ;branch=z9hG4bK776asdhds 774 Max-Forwards: 70 775 To: Bob 776 From: Alice ;tag=1928301774 777 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 778 Session-ID: ab30317f1a784dc48ff824d0d3715d86 779 ;remote=00000000000000000000000000000000 780 CSeq: 314159 INVITE 781 Contact: 782 Content-Type: application/sdp 783 Content-Length: 142 785 (Alice's SDP not shown) 787 F2 INVITE B2BUA -> Bob 789 INVITE sip:bob@192.168.10.20 SIP/2.0 790 Via: SIP/2.0/UDP server10.biloxi.example.com 791 ;branch=z9hG4bK4b43c2ff8.1 792 Via: SIP/2.0/UDP pc33.atlanta.example.com 793 ;branch=z9hG4bK776asdhds;received=10.1.3.33 794 Max-Forwards: 69 795 To: Bob 796 From: Alice ;tag=1928301774 797 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 798 Session-ID: ab30317f1a784dc48ff824d0d3715d86 799 ;remote=00000000000000000000000000000000 800 CSeq: 314159 INVITE 801 Contact: 802 Record-Route: 803 Content-Type: application/sdp 804 Content-Length: 142 806 (Alice's SDP not shown) 807 F3 200 OK Bob -> B2BUA 809 SIP/2.0 200 OK 810 Via: SIP/2.0/UDP server10.biloxi.example.com 811 ;branch=z9hG4bK4b43c2ff8.1;received=192.168.10.1 812 Via: SIP/2.0/UDP pc33.atlanta.example.com 813 ;branch=z9hG4bK776asdhds;received=10.1.3.33 814 To: Bob ;tag=a6c85cf 815 From: Alice ;tag=1928301774 816 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 817 Session-ID: 47755a9de7794ba387653f2099600ef2 818 ;remote=ab30317f1a784dc48ff824d0d3715d86 819 CSeq: 314159 INVITE 820 Contact: 821 Record-Route: 822 Content-Type: application/sdp 823 Content-Length: 131 825 (Bob's SDP not shown) 827 F4 200 OK B2BUA -> Alice 829 SIP/2.0 200 OK 830 Via: SIP/2.0/UDP pc33.atlanta.example.com 831 ;branch=z9hG4bK776asdhds;received=10.1.3.33 832 To: Bob ;tag=a6c85cf 833 From: Alice ;tag=1928301774 834 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 835 Session-ID: 47755a9de7794ba387653f2099600ef2 836 ;remote=ab30317f1a784dc48ff824d0d3715d86 837 CSeq: 314159 INVITE 838 Contact: 839 Record-Route: 840 Content-Type: application/sdp 841 Content-Length: 131 843 (Bob's SDP not shown) 845 F5 ACK Alice -> B2BUA 847 ACK sip:bob@192.168.10.20 SIP/2.0 848 Via: SIP/2.0/UDP pc33.atlanta.example.com 849 ;branch=z9hG4bKnashds8 850 Route: 851 Max-Forwards: 70 852 To: Bob ;tag=a6c85cf 853 From: Alice ;tag=1928301774 854 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 855 Session-ID: ab30317f1a784dc48ff824d0d3715d86 856 ;remote=47755a9de7794ba387653f2099600ef2 857 CSeq: 314159 ACK 858 Content-Length: 0 860 F6 ACK B2BUA -> Bob 862 ACK sip:bob@192.168.10.20 SIP/2.0 863 Via: SIP/2.0/UDP server10.biloxi.example.com 864 ;branch=z9hG4bK4b43c2ff8.2 865 Via: SIP/2.0/UDP pc33.atlanta.example.com 866 ;branch=z9hG4bKnashds8;received=10.1.3.33 867 Max-Forwards: 70 868 To: Bob ;tag=a6c85cf 869 From: Alice ;tag=1928301774 870 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 871 Session-ID: ab30317f1a784dc48ff824d0d3715d86 872 ;remote=47755a9de7794ba387653f2099600ef2 873 CSeq: 314159 ACK 874 Content-Length: 0 876 The remaining examples in this Section do not display the complete 877 SIP message exchange. Instead, they simply use the set notation 878 described in Section 4.2 to show the Session Identifier exchange 879 throughout the particular call flow being illustrated. 881 10.2. Basic Call Transfer using REFER 883 From the example built within Section 10.1, we proceed to this 'Basic 884 Call Transfer using REFER' example. Note that this is a mid-dialog 885 REFER in contrast with the out-of-dialog REFER in Section 10.9. 887 Session-ID 888 --- Alice B2BUA Bob Carol 889 | | | | 890 |<==============RTP==============>| | 891 {B,A} | |<---re-INVITE---| | 892 {B,A} |<---re-INVITE---| (puts Alice on Hold) | 893 {A,B} |-----200 OK---->| | | 894 {A,B} | |-----200 OK---->| | 895 {B,A} | |<-----ACK-------| | 896 {B,A} |<-----ACK-------| | | 897 | | | | 898 {B,A} | |<----REFER------| | 899 {B,A} |<----REFER------| | | 900 {A,B} |-----200 OK---->| | | 901 {A,B} | |-----200 OK---->| | 902 {A,B} |-----NOTIFY---->| | | 903 {A,B} | |-----NOTIFY---->| | 904 {B,A} | |<----200 OK-----| | 905 {B,A} |<----200 OK-----| | | 906 | | | | 907 {A,N} |-----INVITE---->| | 908 {A,N} | |-----INVITE-------------------->| 909 {C,A} | |<----200 OK---------------------| 910 {C,A} |<----200 OK-----| | 911 {A,C} |------ACK------>| | 912 {A,C} | |------ACK---------------------->| 913 | | | | 914 |<======================RTP======================>| 915 | | | | 916 {A,B} |-----NOTIFY---->| | | 917 {A,B} | |-----NOTIFY---->| | 918 {B,A} | |<----200 OK-----| | 919 {B,A} |<----200 OK-----| | | 920 {B,A} | |<-----BYE-------| | 921 {B,A} |<-----BYE-------| | | 922 {A,B} |-----200 OK---->| | | 923 {A,B} | |-----200 OK---->| | 924 | | | | 926 Figure 2: Call Transfer using REFER 928 General operation of this example: 930 Starting from the existing Alice/Bob call described in Figure 1 of 931 this document, which established an existing Session-ID header field 932 value: 934 o UA-Bob requests Alice to call Carol, using a REFER transaction, as 935 described in [RFC3515]. UA-Alice is initially put on hold, then 936 told in the REFER who to contact with a new INVITE, in this case 937 UA-Carol. This Alice-to-Carol dialog will have a new Call-ID, 938 therefore it requires a new Session-ID header field value. The 939 wrinkle here is we can, and will, use Alice's UUID from her 940 existing dialog with Bob in the new INVITE to Carol. 942 o UA-Alice retains her UUID from the Alice-to-Bob call {A} when 943 requesting a call with UA-Carol. This is placed in the "local- 944 uuid" portion of the Session-ID header field value, at the same 945 time inserting a null "remote-uuid" value (because Carol's UA has 946 not yet received the UUID value). This same UUID traverses the 947 B2BUA unchanged. 949 o UA-Carol receives the INVITE with a Session Identifier UUID {A,N}, 950 replaces the A UUID value into the "remote-uuid" portion of the 951 Session-ID header field value and creates its own UUID {C} and 952 places this value in the "local-uuid" portion of the Session-ID 953 header field value, thereby removing the N (null) value 954 altogether. This combination forms a full Session Identifier 955 {C,A} in the 200 OK to the INVITE. This Session-ID header field 956 traverses the B2BUA unchanged towards UA-Alice. 958 o UA-Alice receives the 200 OK with the Session Identifier {C,A} and 959 responds to UA-Carol with an ACK (just as in Figure 1 - switches 960 places of the two UUID fields), and generates a NOTIFY to Bob with 961 a Session Identifier {A,B} indicating the call transfer was 962 successful. 964 o It does not matter which UA terminates the Alice-to-Bob call; 965 Figure 2 shows UA-Bob doing this transaction. 967 10.3. Basic Call Transfer using re-INVITE 969 From the example built within Section 10.1, we proceed to this 'Basic 970 Call Transfer using re-INVITE' example. 972 Alice is talking to Bob. Bob pushes a button on his phone to transfer 973 Alice to Carol via the B2BUA (using re-INVITE). 975 Session-ID 976 --- Alice B2BUA Bob Carol 977 | | | | 978 |<==============RTP==============>| | 979 | | | | 980 | | <--- (non-standard signaling) | 981 {A,B} | |---re-INVITE--->| | 982 {B,A} | |<-----200 OK----| | 983 {A,B} | |-----ACK------->| | 984 | | | | 985 {A,N} | |-----INVITE-------------------->| 986 {C,A} | |<----200 OK---------------------| 987 {A,C} | |------ACK---------------------->| 988 | | | | 989 |<======================RTP======================>| 990 | | | | 991 {A,B} | |------BYE------>| | 992 {B,A} | |<----200 OK-----| | 993 | | | | 994 {C,A} |<--re-INVITE----| | | 995 {A,C} |----200 OK----->| | | 996 {C,A} |<-----ACK-------| | | 997 | (Suppose Alice modifies the session) | 998 {A,C} |---re-INVITE--->| | | 999 {A,C} | |---re-INVITE------------------->| 1000 {C,A} | |<---200 OK----------------------| 1001 {C,A} |<---200 OK------| | | 1002 {A,C} |------ACK------>| | | 1003 {A,C} | |------ACK---------------------->| 1004 | | | | 1006 Figure 3: Call transfer using re-INVITE 1008 General operation of this example: 1010 o We assume the call between Alice and Bob from Section 10.1 is 1011 operational with Session Identifier {A,B}. 1013 o Bob uses non-standard signaling to the B2BUA to initiate a call 1014 transfer from Alice to Carol. This could also be initiated via a 1015 REFER message from Bob, but the signaling that follows might still 1016 be similar to the above flow. In either case, Alice is completely 1017 unaware of the call transfer until a future point in time when 1018 Alice receives a message from Carol. 1020 o The B2BUA sends a re-INVITE with the Session Identifier {"local- 1021 uuid" = "A", "remote-uuid" = "B"} to re-negotiate the session with 1022 Bob. 1024 o The B2BUA sends a new INVITE with Alice's UUID {"local-uuid" = 1025 "A"} to Carol. 1027 o Carol receives the INVITE and accepts the request and adds her 1028 UUID {C} to the Session Identifier for this session {"local-uuid" 1029 = "C", "remote-uuid" = "A"}. 1031 o The B2BUA then terminates the call to Bob with a BYE using the 1032 Session Identifier {"local-uuid" = "A", "remote-uuid" = "B"}. 1034 o The B2BUA sends a re-INVITE to Alice to update Alice's view of the 1035 Session Identifier. 1037 o When Alice later attempts to modify the session with a re-INVITE, 1038 Alice will send "remote-uuid" = "C" toward Carol because it had 1039 previously received the updated UUID in the re-INVITE from the 1040 B2BUA. The B2BUA maintains the Session Identifier {"local-uuid" = 1041 "A", "remote-uuid" = "C"}. Carol replies with the "local-uuid" = 1042 "C", "remote-uuid" = "A" to reflect what was received in the 1043 INVITE (which Carol already knew from previous exchanges with the 1044 B2BUA). Alice then includes "remote-uuid" = "C" in the subsequent 1045 ACK message. 1047 10.4. Single Focus Conferencing 1049 Multiple users call into a conference server (say, an MCU) to attend 1050 one of many conferences hosted on or managed by that server. Each 1051 user has to identify which conference they want to join, but this 1052 information is not necessarily in the SIP messaging. It might be 1053 done by having a dedicated address for the conference or via an IVR, 1054 as assumed in this example and depicted with the use of M1, M2, and 1055 M3. Each user in this example goes through a two-step process of 1056 signaling to gain entry onto their conference call, which the 1057 conference focus identifies as M'. 1059 Session-ID Conference 1060 --- Alice Focus Bob Carol 1061 | | | | 1062 | | | | 1063 {A,N} |----INVITE----->| | | 1064 {M1,A} |<---200 OK------| | | 1065 {A,M1} |-----ACK------->| | | 1066 |<====RTP=======>| | | 1067 {M',A} |<---re-INVITE---| | | 1068 {A,M'} |-----200 OK---->| | | 1069 {M',A} |<-----ACK-------| | | 1070 | | | | 1071 | | | | 1072 {B,N} | |<----INVITE-----| | 1073 {M2,B} | |-----200 OK---->| | 1074 {B,M2} | |<-----ACK-------| | 1075 | |<=====RTP======>| | 1076 {M',B} | |---re-INVITE--->| | 1077 {B,M'} | |<----200 OK-----| | 1078 {M',B} | |------ACK------>| | 1079 | | | | 1080 | | | | 1081 {C,N} | |<--------------------INVITE-----| 1082 {M3,C} | |---------------------200 OK---->| 1083 {C,M3} | |<---------------------ACK-------| 1084 | |<=====================RTP======>| 1085 {M',C} | |-------------------re-INVITE--->| 1086 {C,M'} | |<--------------------200 OK-----| 1087 {M',C} | |----------------------ACK------>| 1089 Figure 4: Single Focus Conference Bridge 1091 General operation of this example: 1093 Alice calls into a conference server to attend a certain conference. 1094 This is a two-step operation since Alice cannot include the 1095 conference ID at this time and/or any passcode in the INVITE request. 1096 The first step is Alice's UA calling another UA to participate in a 1097 session. This will appear to be similar as the call-flow in Figure 1 1098 (in section 10.1). What is unique about this call is the second 1099 step: the conference server sends a re-INVITE request with its second 1100 UUID, but maintaining the UUID Alice sent in the first INVITE. This 1101 subsequent UUID from the conference server will be the same for each 1102 UA that calls into this conference server participating in this same 1103 conference bridge/call, which is generated once Alice typically 1104 authenticates and identifies which bridge she wants to participate 1105 on. 1107 o Alice sends an INVITE to the conference server with her UUID {A} 1108 and a "remote-uuid" = N. 1110 o The conference server responds with a 200 OK response which 1111 replaces the N UUID with a temporary UUID ("M1") as the "local- 1112 uuid" and a "remote-uuid" = "A". 1114 NOTE: this 'temporary' UUID is a real UUID; it is only temporary to 1115 the conference server because it knows that it is going to generate 1116 another UUID to replace the one just send in the 200 OK. 1118 o Once Alice, the user, gains access to the IVR for this conference 1119 server, she enters a specific conference ID and whatever passcode 1120 (if needed) to enter a specific conference call. 1122 o Once the conference server is satisfied Alice has identified which 1123 conference she wants to attend (including any passcode 1124 verification), the conference server re-INVITEs Alice to the 1125 specific conference and includes the Session-ID header field value 1126 component "local-uuid" = "M'" (and "remote-uuid" = "A") for that 1127 conference. All valid participants in the same conference will 1128 receive this same UUID for identification purposes and to better 1129 enable monitoring, and tracking functions. 1131 o Bob goes through this two-step process of an INVITE transaction, 1132 followed by a re-INVITE transaction to get this same UUID ("M'") 1133 for that conference. 1135 o In this example, Carol (and each additional user) goes through the 1136 same procedures and steps as Alice and Bob to get on this same 1137 conference. 1139 10.5. Single Focus Conferencing using a web-based conference service 1141 Alice, Bob and Carol call into same web-based conference. Note this 1142 this is one of many ways of implementing this functionality and 1143 should not be construed as the preferred way of establishing a web- 1144 based conference. 1146 Session-ID Conference 1147 --- Alice Focus Bob Carol 1148 | | | | 1149 |<** HTTPS *****>| | | 1150 | Transaction | | | 1151 | | | | 1152 {M,N} |<----INVITE-----| | | 1153 {A,M} |-----200 OK---->| | | 1154 {M,A} |<-----ACK-------| | | 1155 |<=====RTP======>| | | 1156 | | | | 1157 | |<** HTTPS *****>| | 1158 | | Transaction | | 1159 | | | | 1160 {M,N} | |-----INVITE---->| | 1161 {B,M} | |<----200 OK-----| | 1162 {M,B} | |------ACK------>| | 1163 | |<=====RTP======>| | 1164 | | | | 1165 | |<****************** HTTPS *****>| 1166 | | Transaction | 1167 | | | | 1168 {M,N} | |--------------------INVITE----->| 1169 {C,M} | |<-------------------200 OK------| 1170 {M,C} | |---------------------ACK------->| 1171 | |<====================RTP=======>| 1173 Figure 5: Single Focus Web-based Conference 1175 General operation of this example: 1177 o Alice communicates with web server with desire to join a certain 1178 meeting, by meeting number; also includes UA-Alice's contact 1179 information (phone number, URI and/or IP address, etc.) for each 1180 device she wants for this conference call. For example, the audio 1181 and video play-out devices could be separate units. 1183 o Conference Focus server sends INVITE (Session-ID header field 1184 value components "local-uuid" = M and a remote UUID of N, where M 1185 equals the "local-uuid" for each participant on this conference 1186 bridge) to UA-Alice to start session with that server for this A/V 1187 conference call. 1189 o Upon receiving the INVITE request from the conference focus 1190 server, Alice responds with a 200 OK. Her UA moves the "local- 1191 uuid" unchanged into the "remote-uuid" field, and generates her 1192 own UUID and places that into the "local-uuid" field to complete 1193 the Session-ID construction. 1195 o Bob and Carol perform same function to join this same A/V 1196 conference call as Alice. 1198 10.6. Cascading Conference Bridges 1200 10.6.1. Establishing a Cascaded Conference 1202 To expand conferencing capabilities requires cascading conference 1203 bridges. A conference bridge, or MCU, needs a way to identify itself 1204 when contacting another MCU. [RFC4579] defines the 'isfocus' 1205 Contact: header parameter just for this purpose. 1207 Session-ID 1208 --- MCU-1 MCU-2 MCU-3 MCU-4 1209 | | | | 1210 {M',N} |----INVITE----->| | | 1211 {J,M'} |<---200 OK------| | | 1212 {M',J} |-----ACK------->| | | 1214 Figure 6: MCUs Communicating Session Identifier UUID for Bridge 1216 Regardless of which MCU (1 or 2) a UA contacts for this conference, 1217 once the above exchange has been received and acknowledged, the UA 1218 will get the same {M',N} UUID pair from the MCU for the complete 1219 Session Identifier. 1221 A more complex form would be a series of MCUs all being informed of 1222 the same UUID to use for a specific conference. This series of MCUs 1223 can either be informed 1225 o All by one MCU (that initially generates the UUID for the 1226 conference). 1228 o The MCU that generates the UUID informs one or several MCUs of 1229 this common UUID, and they inform downstream MCUs of this common 1230 UUID that each will be using for this one conference. 1232 Session-ID 1233 --- MCU-1 MCU-2 MCU-3 MCU-4 1234 | | | | 1235 {M',N} |----INVITE----->| | | 1236 {J,M'} |<---200 OK------| | | 1237 {M',J} |-----ACK------->| | | 1238 | | | | 1239 {M',N} |---------------------INVITE----->| | 1240 {K,M'} |<--------------------200 OK------| | 1241 {M',K} |----------------------ACK------->| | 1242 | | | | 1243 {M',N} |-------------------------------------INVITE----->| 1244 {L,M'} |<------------------------------------200 OK------| 1245 {M',L} |--------------------------------------ACK------->| 1247 Figure 7: MCU Communicating Session Identifier UUID to More than One 1248 MCU 1250 General operation of this example: 1252 o The MCU generating the Session Identifier UUID communicates this 1253 in a separate INVITE, having a Contact header with the 'isfocus' 1254 header parameter. This will identify the MCU as what [RFC4579] 1255 calls a conference-aware SIP entity. 1257 o An MCU that receives this {M',N} UUID pair in an inter-MCU 1258 transaction can communicate the M' UUID in a manner in which it 1259 was received to construct a hierarchical cascade (though this time 1260 this second MCU would be the UAC MCU). 1262 o Once the conference is terminated, the cascaded MCUs will receive 1263 a BYE message to terminate the cascade. 1265 10.6.2. Calling into Cascaded Conference Bridges 1267 Here is an example of how a UA, say Robert, calls into a cascaded 1268 conference focus. Because MCU-1 has already contacted MCU-3, the MCU 1269 where Robert is going to join the conference, MCU-3 already has the 1270 Session-ID (M') for this particular conference call. 1272 Session-ID 1273 --- MCU-1 MCU-2 MCU-3 Robert 1274 | | | | 1275 {M',N} |----INVITE----->| | | 1276 {J,M'} |<---200 OK------| | | 1277 {M',J} |-----ACK------->| | | 1278 | | | | 1279 {M',N} |---------------------INVITE----->| | 1280 {K,M'} |<--------------------200 OK------| | 1281 {M',K} |----------------------ACK------->| | 1282 | | | | 1283 {R,N} | | |<---INVITE-----| 1284 (M',R} | | |----200 OK---->| 1285 {R,M'} | | |<----ACK-------| 1287 Figure 8: A UA Calling into a Cascaded MCU UUID 1289 General operation of this example: 1291 o The UA, Robert in this case, INVITEs the MCU to join a particular 1292 conference call. Robert's UA does not know anything about whether 1293 this is the main MCU of the conference call, or a cascaded MCU. 1294 Robert likely does not know MCUs can be cascaded, he just wants to 1295 join a particular call. Like as with any standard implementation, 1296 he includes a null "remote-uuid". 1298 o The cascaded MCU, upon receiving this INVITE from Robert, replaces 1299 the null UUID with the UUID value communicated from MCU-1 for this 1300 conference call as the "local-uuid" in the SIP response. Thus, 1301 moving Robert's UUID "R" to the "remote-uuid" value. 1303 o The ACK has the Session-ID {R,M'}, completing the 3-way handshake 1304 for this call establishment. Robert has now joined the conference 1305 call originated from MCU-1. 1307 o Once the conference is terminated, the cascaded MCUs will receive 1308 a BYE message to terminate the cascade. 1310 10.7. Basic 3PCC for two UAs 1312 An external entity sets up calls to both Alice and Bob for them to 1313 talk to each other. 1315 Session-ID 1316 --- Alice B2BUA Bob Carol 1317 | | | 1318 {X,N} |<----INVITE-----| | 1319 {A,X} |-----200 OK---->| | 1320 {A,N} | |----INVITE----->| 1321 {B,A} | |<---200 OK------| 1322 {B,A} |<-----ACK-------| | 1323 {A,B} | |------ACK------>| 1324 |<==============RTP==============>| 1326 Figure 9: 3PCC initiated call between Alice and Bob 1328 General operation of this example: 1330 o Some out of band procedure directs a B2BUA (or other SIP server) 1331 to have Alice and Bob talk to each other. In this case, the SIP 1332 server has to be transaction stateful, if not dialog stateful. 1334 o The SIP server INVITEs Alice to a session and uses a temporary 1335 UUID {X} and a null UUID pairing. 1337 o Alice receives and accepts this call set-up and replaces the null 1338 UUID with her UUID {A} in the Session Identifier, now {A,X}. 1340 o The transaction stateful SIP server receives Alice's UUID {A} in 1341 the local UUID portion and keeps it there, and discards its own 1342 UUID {X}, replacing this with a null UUID value in the INVITE to 1343 Bob as if this came from Alice originally. 1345 o Bob receives and accepts this INVITE and adds his own UUID {B} to 1346 the Session Identifier, now {B,A} for the response. 1348 o The session is established. 1350 10.8. Handling in 100 Trying SIP Response and CANCEL Request 1352 The following two subsections show examples of the Session Identifier 1353 for a 100 Trying response and a CANCEL request in a single call-flow. 1355 10.8.1. Handling in a 100 Trying SIP Response 1357 The following 100 Trying response is taken from an existing RFC, from 1358 [RFC5359] Section 2.9 ("Call Forwarding - No Answer"). 1360 Session-ID Alice SIP Server Bob-1 Bob-2 1361 | | | | 1362 {A,N} |----INVITE----->| | | 1363 {A,N} | |---INVITE---->| | 1364 {N,A} |<--100 Trying---| | | 1365 {B1,A} | |<-180 Ringing-| | 1366 {B1,A} |<--180 Ringing--| | | 1367 | | | | 1368 | *Request Timeout* | 1369 | | | | 1370 {A,N} | |---CANCEL---->| | 1371 {B1,A} | |<--200 OK-----| | 1372 {B1,A} | |<---487-------| | 1373 {A,B1} | |---- ACK ---->| | 1374 | | | | 1375 {N,A} |<-181 Call Fwd--| | | 1376 | | | | 1377 {A,N} | |------------------INVITE------>| 1378 {B2,A} | |<----------------180 Ringing---| 1379 {B2,A} |<-180 Ringing---| | | 1380 {B2,A} | |<-----------------200 OK ------| 1381 {B2,A} |<--200 OK-------| | | 1382 {A,B2} |----ACK-------->| | | 1383 {A,B2} | |------------------ACK--------->| 1384 | | | | 1385 |<=========== Both way RTP Established =========>| 1386 | | | | 1387 {A,B2} |----BYE-------->| | | 1388 {A,B2} | |--------------------BYE------->| 1389 {B2,A} | |<------------------200 OK------| 1390 {B2,A} |<--200 OK-------| | | 1391 | | | | 1393 Figure 10: Session Identifier in the 100 Trying and CANCEL Messaging 1395 Below is the explanatory text from RFC 5359 Section 2.9 detailing 1396 what the desired behavior is in the above call flow (i.e., what the 1397 call-flow is attempting to achieve). 1399 "Bob wants calls to B1 forwarded to B2 if B1 is not answered 1400 (information is known to the SIP server). Alice calls B1 and no one 1401 answers. The SIP server then places the call to B2." 1403 General operation of this example: 1405 o Alice generates an INVITE request because she wants to invite Bob 1406 to join her session. She creates a UUID as described in section 1407 10.1, and places that value in the "local-uuid" field of the 1408 Session-ID header field value. Alice also generates a "remote- 1409 uuid" of null and sends this along with the "local-uuid". 1411 o The SIP server (imagine this is a B2BUA), upon receiving Alice's 1412 INVITE, generates the optional provisional response 100 Trying. 1413 Since the SIP server has no knowledge Bob's UUID for his part of 1414 the Session Identifier value, it cannot include his "local-uuid". 1415 Rather, any 100 Trying response includes Alice's UUID in the 1416 "remote-uuid" portion of the Session-ID header-value with a null 1417 "local-uuid" value in the response. This is consistent with what 1418 Alice's UA expects to receive in any SIP response containing this 1419 UUID. 1421 10.8.2. Handling a CANCEL SIP Request 1423 In the same call-flow example as the 100 Trying response is a CANCEL 1424 request. Please refer to Figure 10 for the CANCEL request example. 1426 General operation of this example: 1428 o In Figure 10 above, Alice generates an INVITE with her UUID value 1429 in the Session-ID header field. 1431 o Bob-1 responds to this INVITE with a 180 Ringing. In that 1432 response, he includes his UUID in the Session-ID header field 1433 value (i.e., {B1,A}); thus completing the Session-ID header field 1434 for this session, even though no final response has been generated 1435 by any of Bob's UAs. 1437 o While this means that if the SIP server were to generate a SIP 1438 request within this session it could include the complete 1439 SessionID, the server sends a CANCEL and a CANCEL always uses the 1440 same Session-ID header field as the original INVITE. Thus, the 1441 CANCEL would have a Session Identifier with the "local-uuid" = 1442 "A", and the "remote-uuid" = "N". 1444 o As it happens with this CANCEL, the SIP server intends to invite 1445 another UA of Bob (i.e., B2) for Alice to communicate with. 1447 o In this example call-flow, taken from RFC 5359, Section 2.9, a 181 1448 (Call is being Forwarded) response is sent to Alice. Since the 1449 SIP server generated this SIP request, and has no knowledge of 1450 Bob-2's UUID value, it cannot include that value in this 181. 1451 Thus, and for the exact reasons the 100 Trying including the 1452 Session Identifier value, only Alice's UUID is included in the 1453 remote-uuid component of the Session-ID header field value, with a 1454 null UUID present in the "local-uuid" component. 1456 10.9. Out-of-dialog REFER Transaction 1458 The following call-flow was extracted from Section 6.1 of [RFC5589] 1459 ("Successful Transfer"), with the only changes being the names of the 1460 UAs to maintain consistency within this document. 1462 Alice is the transferee 1463 Bob is the transferer 1464 and Carol is the transfer-target 1466 Session-ID Bob Alice Carol 1467 | | | 1468 {A,N} |<-----INVITE--------| | 1469 {B,A} |------200 OK------->| | 1470 {A,B} |<------ACK----------| | 1471 | | | 1472 {B,A} |--INVITE {hold}---->| | 1473 {A,B} |<-200 OK------------| | 1474 {B,A} |--- ACK ----------->| | 1475 | | | 1476 {B,A} |--REFER------------>|(Refer-To:Carol) | 1477 {A,B} |<-202 Accepted------| | 1478 | | | 1479 {A,B} || | 1481 | | | 1482 {A,N} | |--INVITE------------>| 1483 {C,A} | |<-200 OK-------------| 1484 {A,C} | |---ACK-------------->| 1485 | | | 1486 {A,B} |<--NOTIFY {200 OK}--| | 1487 {B,A} |---200 OK---------->| | 1488 | | | 1489 {B,A} |--BYE-------------->| | 1490 {A,B} |<-200 OK------------| | 1491 {C,A} | |<------------BYE-----| 1492 {A,C} | |-------------200 OK->| 1494 Figure 11: Out-Of-Dialog Call Transfer 1496 General operation of this example: 1498 o Just as in Section 10.2, Figure 2, Alice invites Bob to a session, 1499 and Bob eventually transfers Alice to communicate with Carol. 1501 o What is different about the call-flow in Figure 11 is that Bob's 1502 REFER is not in-dialog. Even so, this is treated as part of the 1503 same communication session and, thus, the Session Identifier in 1504 those messages is {A,B}. 1506 o Alice will use her existing UUID and the null UUID ({A,N}) in the 1507 INVITE towards Carol (who generates UUID "C" for this session), 1508 thus maintaining the common UUID within the Session Identifier for 1509 this new Alice-to-Carol session. 1511 11. Compatibility with a Previous Implementation 1513 There is a much earlier document that specifies the use of a Session- 1514 ID header field (namely, [RFC7329]) that we will herewith attempt to 1515 achieve backwards compatibility. Neither Session-ID header field has 1516 any versioning information, so merely adding that this document 1517 describes "version 2" is insufficient. Here are the set of rules for 1518 compatibility between the two specifications. Although the previous 1519 version was never standardized, it has been heavily implemented and 1520 adopted by other standards development organizations. For the 1521 purposes of this discussion, we will label the pre-standard 1522 specification of the Session-ID as the "old" version and this 1523 specification as the "new" version of the Session-ID. 1525 The previous (i.e., "old") version only has a single UUID value as a 1526 Session-ID header field value, but has a generic-parameter value that 1527 can be of use. 1529 In order to have an "old" version talk to an "old" version 1530 implementation, nothing needs to be done as far as the IETF is 1531 concerned. 1533 In order to have a "new" version talk to a "new" version 1534 implementation, both implementations need to follow this document (to 1535 the letter) and everything should be just fine. 1537 For this "new" implementation to work with the "old" implementation 1538 and an "old" implementation to work with "new" implementations, there 1539 needs to be a set of rules that all "new" implementations MUST follow 1540 if the "new" implementation will be communicating with devices that 1541 have implemented the "old" implementation. 1543 o Since no option tags or feature tags are to be used for 1544 distinguishing versions, the presence and order of any "remote- 1545 uuid" value within the Session-ID header field value is to be used 1546 to distinguish implementation versions. 1548 o If a SIP request has a "remote-uuid" value, this comes from a 1549 standard implementation, and not a pre-standard one. 1551 o If a SIP request has no "remote-uuid" value, this comes from a 1552 pre-standard implementation, and not a standard one. In this 1553 case, one UUID is used to identify this dialog, even if the 1554 responder is a standard implementation of this specification. 1556 o If a SIP response has a non-null "local-uuid" that is 32 octets 1557 long and differs from the endpoint's own UUID value, this response 1558 comes from a standard implementation. 1560 o If a SIP response arrives that has the same value of Session-ID 1561 UUIDs in the same order as was sent, this comes from a pre- 1562 standard implementation, and MUST NOT be discarded for not 1563 altering the null "remote-uuid". In this case, any new 1564 transaction within this dialog MUST preserve the order of the two 1565 UUIDs within all Session-ID header field, including the ACK, until 1566 this dialog is terminated. 1568 o If a SIP response only contains the "local-uuid" that was sent 1569 originally, this comes from a pre-standard implementation and MUST 1570 NOT be discarded for removing the null "remote-uuid". In this 1571 case, all future transactions within this dialog MUST contain only 1572 the UUID received in the first SIP response. Any new transaction 1573 starting a new dialog from the standard Session-ID implementation 1574 MUST include a "local-uuid" and a null "remote-uuid", even if that 1575 new dialog is between the same two UAs. 1577 o Standard implementations SHOULD NOT expect pre-standard 1578 implementations to be consistent in their implementation, even 1579 within the same dialog. For example, perhaps the first, third and 1580 tenth responses contain a "remote-uuid", but all the others do 1581 not. This behavior MUST be allowed by implementations of this 1582 specification. 1584 o The foregoing does not apply to other, presently unknown 1585 parameters that might be defined in the future. They are ignored 1586 for the purposes of interoperability with previous 1587 implementations. 1589 12. Security and Privacy Considerations 1591 The Session Identifier MUST be constructed in such a way that does 1592 not conveyed any user or device information as outlined in 1593 Section 4.1. This ensures that the data contained in the Session 1594 Identifier itself does not require any additional privacy 1595 protections. 1597 Because of the inherit property that Session Identifiers are conveyed 1598 end-to-end and remain unchanged by a UA for the duration of the 1599 session, the Session Identifier could be misused to discover 1600 relationships between two or more parties. For example, suppose that 1601 Alice calls Bob and Bob, via his PBX, forwards or transfers the call 1602 to Carol. Without use of the Session Identifier, an unauthorized 1603 third party that is observing the communications between Alice and 1604 Bob might not know that Alice is actually communicating with Carol. 1605 If Alice, Bob, and Carol include the Session Identifier as a part of 1606 the signaling messages, it is possible for the third party to observe 1607 that the UA associated with Bob changed to some other UA. If the 1608 third party also has access to signaling messages between Bob and 1609 Carol, the third party can then discover that Alice is communicating 1610 with Carol. This would be true even if all other information 1611 relating to the session is changed by the PBX, including both 1612 signaling information and media address information. 1614 The Session Identifier might be utilized for logging or 1615 troubleshooting, but MUST NOT be used for billing purposes. 1617 13. IANA Considerations 1619 13.1. Registration of the "Session-ID" Header Field 1621 The following is the registration for the 'Session-ID' header field 1622 to the "Header Name" registry at 1624 http://www.iana.org/assignments/sip-parameters: 1626 RFC number: RFC XXXX 1628 Header name: 'Session-ID' 1630 Compact form: none 1632 Note: This document replaces the "Session-ID" header originally 1633 registered via [RFC7329]. 1635 [RFC Editor: Please replace XXXX in this section and the next with 1636 the this RFC number of this document.] 1638 13.2. Registration of the "remote" Parameter 1640 The following parameter is to be added to the "Header Field 1641 Parameters and Parameter Values" section of the SIP parameter 1642 registry: 1644 +--------------+----------------+-------------------+-----------+ 1645 | Header Field | Parameter Name | Predefined Values | Reference | 1646 +--------------+----------------+-------------------+-----------+ 1647 | Session-ID | remote | No | [RFCXXXX] | 1648 +--------------+----------------+-------------------+-----------+ 1650 14. Acknowledgements 1652 The authors would like to thank Robert Sparks, Hadriel Kaplan, 1653 Christer Holmberg, Paul Kyzivat, Brett Tate, Keith Drage, Mary 1654 Barnes, Charles Eckel, Peter Dawes, Andrew Hutton, Arun Arunachalam, 1655 Adam Gensler, Roland Jesske, and Faisal Siyavudeen for their 1656 invaluable comments during the development of this document. 1658 15. Dedication 1660 This document is dedicated to the memory of James Polk, a long-time 1661 friend and colleague. James made important contributions to this 1662 specification, including being one of its primary editors. The IETF 1663 global community mourns his loss and he will be missed dearly. 1665 16. References 1667 16.1. Normative References 1669 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1670 Requirement Levels", BCP 14, RFC 2119, 1671 DOI 10.17487/RFC2119, March 1997, 1672 . 1674 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1675 A., Peterson, J., Sparks, R., Handley, M., and E. 1676 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1677 DOI 10.17487/RFC3261, June 2002, 1678 . 1680 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1681 Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, 1682 . 1684 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 1685 Protocol (SIP) "Replaces" Header", RFC 3891, 1686 DOI 10.17487/RFC3891, September 2004, 1687 . 1689 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1690 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1691 DOI 10.17487/RFC4122, July 2005, 1692 . 1694 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 1695 (SIP) Call Control - Conferencing for User Agents", 1696 BCP 119, RFC 4579, DOI 10.17487/RFC4579, August 2006, 1697 . 1699 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1700 Specifications: ABNF", STD 68, RFC 5234, 1701 DOI 10.17487/RFC5234, January 2008, 1702 . 1704 16.2. Informative References 1706 [H.323] International Telecommunications Union, "Recommendation 1707 ITU-T H.323, Packet-based multimedia communications 1708 systems", December 2009. 1710 [H.460.27] 1711 International Telecommunications Union, "Recommendation 1712 ITU-T H.460.27, End-to-End Session Identifier for H.323 1713 Systems", November 2015. 1715 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1716 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1717 DOI 10.17487/RFC2543, March 1999, 1718 . 1720 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1721 Jacobson, "RTP: A Transport Protocol for Real-Time 1722 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1723 July 2003, . 1725 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 1726 Camarillo, "Best Current Practices for Third Party Call 1727 Control (3pcc) in the Session Initiation Protocol (SIP)", 1728 BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, 1729 . 1731 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1732 Session Initiation Protocol (SIP)", RFC 4353, 1733 DOI 10.17487/RFC4353, February 2006, 1734 . 1736 [RFC5359] Johnston, A., Ed., Sparks, R., Cunningham, C., Donovan, 1737 S., and K. Summers, "Session Initiation Protocol Service 1738 Examples", BCP 144, RFC 5359, DOI 10.17487/RFC5359, 1739 October 2008, . 1741 [RFC5589] Sparks, R., Johnston, A., Ed., and D. Petrie, "Session 1742 Initiation Protocol (SIP) Call Control - Transfer", 1743 BCP 149, RFC 5589, DOI 10.17487/RFC5589, June 2009, 1744 . 1746 [RFC6141] Camarillo, G., Ed., Holmberg, C., and Y. Gao, "Re-INVITE 1747 and Target-Refresh Request Handling in the Session 1748 Initiation Protocol (SIP)", RFC 6141, 1749 DOI 10.17487/RFC6141, March 2011, 1750 . 1752 [RFC6872] Gurbani, V., Ed., Burger, E., Ed., Anjali, T., Abdelnur, 1753 H., and O. Festor, "The Common Log Format (CLF) for the 1754 Session Initiation Protocol (SIP): Framework and 1755 Information Model", RFC 6872, DOI 10.17487/RFC6872, 1756 February 2013, . 1758 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 1759 Initiation Protocol (SIP) Back-to-Back User Agents", 1760 RFC 7092, DOI 10.17487/RFC7092, December 2013, 1761 . 1763 [RFC7206] Jones, P., Salgueiro, G., Polk, J., Liess, L., and H. 1764 Kaplan, "Requirements for an End-to-End Session 1765 Identification in IP-Based Multimedia Communication 1766 Networks", RFC 7206, DOI 10.17487/RFC7206, May 2014, 1767 . 1769 [RFC7329] Kaplan, H., "A Session Identifier for the Session 1770 Initiation Protocol (SIP)", RFC 7329, 1771 DOI 10.17487/RFC7329, August 2014, 1772 . 1774 Authors' Addresses 1776 Paul E. Jones 1777 Cisco Systems, Inc. 1778 7025 Kit Creek Rd. 1779 Research Triangle Park, NC 27709 1780 USA 1782 Phone: +1 919 476 2048 1783 Email: paulej@packetizer.com 1784 Gonzalo Salgueiro 1785 Cisco Systems, Inc. 1786 7025 Kit Creek Rd. 1787 Research Triangle Park, NC 27709 1788 USA 1790 Phone: +1 919 392 3266 1791 Email: gsalguei@cisco.com 1793 Chris Pearce 1794 Cisco Systems, Inc. 1795 2300 East President George Bush Highway 1796 Richardson, TX 75082 1797 USA 1799 Phone: +1 972 813 5123 1800 Email: chrep@cisco.com 1802 Paul Giralt 1803 Cisco Systems, Inc. 1804 7025 Kit Creek Rd. 1805 Research Triangle Park, NC 27709 1806 USA 1808 Phone: +1 919 991 5644 1809 Email: pgiralt@cisco.com