idnits 2.17.1 draft-ietf-insipid-session-id-13.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 (January 24, 2015) is 3380 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 279, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1412, but not defined ** Obsolete normative reference: RFC 7329 (Obsoleted by RFC 7989) -- Obsolete informational reference (is this intentional?): RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Jones (Ed.) 3 Internet Draft J. Polk (Ed.) 4 Intended status: Standards Track G. Salgueiro 5 Expires: July 24, 2015 C. Pearce 6 Cisco Systems 7 January 24, 2015 9 End-to-End Session Identification in IP-Based Multimedia 10 Communication Networks 11 draft-ietf-insipid-session-id-13 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 intermediate 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. 23 This document also describes a backwards compatibility mechanism for 24 an existing (RFC 7329) session identifier implementation that is 25 sufficiently different from the procedures defined in this document. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 This Internet-Draft will expire on July 24, 2015. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction...................................................3 68 2. Conventions used in this document..............................3 69 3. Session Identifier Requirements and Use Cases..................4 70 4. Constructing and Conveying the Session Identifier..............4 71 4.1. Constructing the Session Identifier.......................4 72 4.2. Conveying the Session Identifier..........................5 73 5. The Session-ID Header Field....................................6 74 6. Endpoint Behavior..............................................7 75 7. Processing by Intermediaries...................................8 76 8. Associating Endpoints in a Multipoint Conference...............9 77 9. Various Call Flow Operations..................................10 78 9.1. Basic Call with 2 UUIDs..................................11 79 9.2. Basic Call Transfer using REFER..........................14 80 9.3. Basic Call Transfer using re-INVITE......................16 81 9.4. Single Focus Conferencing................................17 82 9.5. Single Focus Conferencing using WebEx....................19 83 9.6. Cascading Conference Bridges.............................20 84 9.6.1. Establishing a Cascaded Conference..................20 85 9.6.2. Calling into Cascaded Conference Bridges............21 86 9.7. Basic 3PCC for two UAs...................................22 87 9.8. Handling in 100 Trying SIP Response and CANCEL Request...23 88 9.8.1. Handling in a 100 Trying SIP Response...............23 89 9.8.2. Handling a CANCEL SIP Request.......................24 90 9.9. Out-of-dialog REFER Transaction..........................25 91 10. Compatibility with a Previous Implementation.................26 92 11. Security Considerations......................................28 93 12. IANA Considerations..........................................28 94 12.1. Registration of the "Session-ID" Header Field...........28 95 12.2. Registration of the "remote" Parameter..................29 96 13. Acknowledgments..............................................29 97 14. References...................................................29 98 14.1. Normative References....................................29 99 14.2. Informative References..................................30 100 Authors' Addresses...............................................31 102 1. Introduction 104 IP-based multimedia communication systems like SIP [RFC3261] and 105 H.323 [H.323] have the concept of a "call identifier" that is 106 globally unique. The identifier is intended to represent an end-to- 107 end communication session from the originating device to the 108 terminating device. Such an identifier is useful for 109 troubleshooting, session tracking, and so forth. 111 For several reasons, however, the current call identifiers defined in 112 SIP and H.323 are not suitable for end-to-end session identification. 113 A fundamental issue in protocol interworking is the fact that the 114 syntax for the call identifier in SIP and H.323 is different. Thus, 115 if both protocols are used in a call, it is impossible to exchange 116 the call identifier end-to-end. 118 Another reason why the current call identifiers are not suitable to 119 identify a session end-to-end is that, in real-world deployments, 120 devices like session border controllers often change the session 121 signaling as it passes through the device, including the value of the 122 call identifier. While this is deliberate and useful, it makes it 123 very difficult to track a session end-to-end. 125 This draft presents a new identifier, referred to as the Session 126 Identifier, and associated syntax intended to overcome the issues 127 that exist with the currently defined call identifiers used in SIP. 128 The procedures specified in this document attempt to comply with the 129 requirements specified in [RFC7206]. The procedures also specify 130 capabilities not mentioned in [RFC7206], shown in call flows in 131 section 9. Additionally, the specification attempts to account for a 132 previous, proprietary version of a SIP Session Identifier header 133 [RFC7329], specifying a backwards compatibility approach in section 134 10. 136 2. Conventions used in this document 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [RFC2119] 141 when they appear in ALL CAPS. These words may also appear in this 142 document in lower case as plain English words, absent their normative 143 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. 149 3. Session Identifier Requirements and Use Cases 151 Requirements and use cases for the end-to-end Session Identifier, 152 along with a definition of "session identifier" and "communication 153 session", can be found in [RFC7206]. 155 As mentioned in section 6.1 of RFC 7206, the ITU-T undertook a 156 parallel effort to define compatible procedures for an H.323 Session 157 Identifier. They are documented in [H.460.27]. 159 4. Constructing and Conveying the Session Identifier 161 4.1. Constructing the Session Identifier 163 The Session Identifier comprises two UUIDs [RFC4122], with each UUID 164 representing one of the endpoints participating in the session. 166 The version number in the UUID indicates the manner in which the UUID 167 is generated, such as using random values or using the MAC address of 168 the endpoint. To satisfy the requirement that no user or device 169 information be conveyed, endpoints SHOULD generate version 4 (random) 170 or version 5 (SHA-1) UUIDs to address relevant privacy concerns. 172 When generating a version 5 UUID, endpoints or intermediaries MUST 173 utilize the procedures defined in Section 4.3 of [RFC4122] and employ 174 the following "name space ID": 176 uuid_t NameSpace_SessionID = { 177 /* a58587da-c93d-11e2-ae90-f4ea67801e29 */ 178 0xa58587da, 179 0xc93d, 180 0x11e2, 181 0xae, 0x90, 0xf4, 0xea, 0x67, 0x80, 0x1e, 0x29 182 } 184 Further, the "name" to utilize for version 5 UUIDs is the 185 concatenation of the Call-ID header value and the "tag" parameter 186 that appears on the "From" or "To" line associated with the device 187 for which the UUID is created. Once an endpoint generates a UUID for 188 a session, the UUID never changes, even if values originally used as 189 input into its construction change over time. 191 Stateless intermediaries that insert a Session-ID header into a SIP 192 message on behalf of a sending User Agent MUST utilize version 5 193 UUIDs to ensure that UUIDs for the communication session are 194 consistently generated. If a stateless intermediary does not know 195 the tag value for the endpoint (e.g., a new INVITE without a To: tag 196 value or an older SIP [RFC2543] implementation that did not include a 197 tag parameter), the intermediary MUST NOT attempt to generate a UUID 198 for that endpoint. Note that if an intermediary is stateless and the 199 endpoint on one end of the call is replaced with another endpoint due 200 to some service interaction, the values used to create the UUID 201 should change and, if so, the intermediary will compute a different 202 UUID. 204 4.2. Conveying the Session Identifier 206 The SIP user agent (UA) initially transmitting the SIP request, i.e., 207 a User Agent Client (UAC), will create a UUID and transmit that to 208 the ultimate destination UA. Likewise, the responding UA, i.e., a 209 User Agent Server (UAS), will create a UUID and transmit that to the 210 first UA. These two distinct UUIDs form what is referred to as the 211 Session Identifier and is represented in this document in set 212 notation of the form {A,B}, where A is UUID value from the UA 213 transmitting a message and B is the UUID value of the intended 214 recipient of the message, i.e., not an intermediary server along the 215 signaling path. The Session Identifier {A,B} is equal to the Session 216 Identifier {B,A}. 218 In the case where only one UUID is known, such as when a UA first 219 initiates a SIP request, the Session Identifier would be {A,N}, where 220 "A" represents the UUID value transmitted by the UA and "N" is what 221 is referred to as the null UUID (see section 5). 223 Since SIP sessions are subject to any number of service interactions, 224 SIP INVITE messages might be forked as sessions are established, and 225 since conferences might be established or expanded with endpoints 226 calling in or the conference focus calling out, the construction of 227 the Session Identifier as a set of UUIDs is important. 229 To understand this better, consider that a UA participating in a 230 communication session might be replaced with another, such as the 231 case where two "legs" of a call are joined together by a PBX. 232 Suppose that UA A and UA B both call UA C. Further suppose that UA C 233 uses a local PBX function to join the call between itself and UA A 234 with the call between itself and UA B, resulting in a single 235 remaining call between UA A and UA B. This merged call can be 236 identified using two UUID values assigned by each entity in the 237 communication session, namely {A,B} in this example. 239 In the case of forking, UA A might send an INVITE that gets forked to 240 five different UAs, as an example. A means of identifying each of 241 these separate communication sessions is needed and allowing the set 242 of {A, B1}, {A, B2}, {A, B3}, {A, B4}, and {A, B5} makes this 243 possible. 245 For conferencing scenarios, it is also useful to have a two-part 246 Session Identifier where the conference focus specifies the same UUID 247 for each conference participant. This will allow for correlation 248 among the participants in a single conference. For example, in a 249 conference with three participants, the Session Identifiers might be 250 {A,M}, {B,M}, and {C,M}, where "M" is assigned by the conference 251 focus. 253 How a device acting on Session Identifiers stores, processes, or 254 utilizes the Session Identifier is outside the scope of this 255 document. 257 5. The Session-ID Header Field 259 The syntax specified here replaces the Session-ID header field syntax 260 defined in RFC 7329 [RFC7329]. 262 Each session initiated or accepted MUST have a unique local UA- 263 generated UUID. This value MUST remain unchanged throughout the 264 duration of the session. 266 A SIP UA or proxy that generates a Session-ID header on behalf of a 267 UA MUST convey its Session Identifier UUID in all transmitted 268 messages by including the Session-ID header. The Session-ID header 269 has the following ABNF [RFC5234] syntax: 271 session-id = "Session-ID" HCOLON session-id-value 273 session-id-value = local-uuid *(SEMI sess-id-param) 275 local-uuid = sess-uuid / null 277 remote-uuid = sess-uuid / null 279 sess-uuid = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] 281 sess-id-param = remote-param / generic-param 283 remote-param = "remote" EQUAL remote-uuid 285 null = 32("0") 287 The productions "SEMI", "EQUAL", and "generic-param" are defined in 288 [RFC3261]. The production DIGIT is defined in [RFC5234]. 290 The Session-ID header MUST NOT have more than one "remote" parameter. 291 In the case where an entity compliant with this specification is 292 interworking with an entity that implemented [RFC7329], the "remote" 293 parameter may be absent, but otherwise the remote parameter MUST be 294 present. The details under which those conditions apply are 295 described in Section 10. Except for backwards compatibility with 296 [RFC7329], the "remote" parameter MUST be present. 298 A special null UUID value composed of 32 zeros is required in certain 299 situations. A null UUID is expected as the "remote-uuid" of every 300 initial standard SIP request since the initiating endpoint would not 301 initially know the UUID value of the remote endpoint. This null value 302 will get replaced by the ultimate destination UAS when that UA 303 generates a UUID in response. One caveat is explained in Section 10 304 for a possible backwards compatibility case. A null UUID value is 305 also returned by some intermediary devices that send provisional 306 replies as a "local-uuid", as described in Section 7. 308 The "local-uuid" in the Session-ID header represents the UUID value 309 of the UA transmitting the message. If the UA transmitting the 310 message previously received a UUID value from its peer endpoint, it 311 MUST include that UUID as the "remote" parameter in each message it 312 transmits. For example, a Session-ID header might appear like this: 314 Session-ID: ab30317f1a784dc48ff824d0d3715d86; 315 remote=47755a9de7794ba387653f2099600ef2 317 The UUID values are presented as strings of lower-case hexadecimal 318 characters, with the most significant octet of the UUID appearing 319 first. 321 The Session-ID header-value is technically case-INSENSITIVE, but only 322 lowercase characters are allowed in the sess-uuid components. 323 Receiving entities MUST treat sess-uuid components as case- 324 insensitive and not produce an error if an uppercase character is 325 received in a sess-uuid. 327 6. Endpoint Behavior 329 To comply with this specification, non-intermediary SIP UAs MUST 330 include a Session-ID header-value in all SIP messages transmitted as 331 a part of a communication session. The UUID of the transmitter of 332 the message MUST appear in the "local-uuid" portion of the Session-ID 333 header-value. The UUID of the peer device, if known, MUST appear as 334 the "remote" parameter following the transmitter's UUID. The null 335 UUID value MUST be used if the peer device's UUID is not known. 337 Once a UA allocates a UUID value for a communication session, the UA 338 MUST NOT change that UUID value for the duration of the session, 339 including when 341 - communication attempts are retried due to receipt of 4xx 342 messages or request timeouts; 344 - the session is redirected in response to a 3xx message; or 346 - a session is transferred via a REFER message [RFC3515]; or 348 - a SIP dialog is replaced via an INVITE with Replaces [RFC3891]. 350 A non-intermediary UA that receives a Session-ID header MUST take 351 note of the "local-uuid" value that it receives and assume that is 352 the UUID of the peer endpoint within that communications session. 353 UAs MUST include this received UUID value as the "remote" parameter 354 when transmitting subsequent messages, making sure not to change this 355 UUID value in the process of moving the value internally from the 356 "local-uuid" field to the "remote-uuid" field. 358 It should be noted that messages received by a UA might contain a 359 "local-uuid" value that does not match what the UA expected the far 360 end UA's UUID to be. It is also possible for the UA to receive a 361 "remote-uuid" value that does not match the UA's assigned UUID for 362 the session. Either might happen as a result of service interactions 363 by intermediaries and MUST NOT negatively affect the communication 364 session. However, the UA may log this event for the purposes of 365 troubleshooting. 367 A UA MUST assume that the UUID value of the peer UA MAY change at any 368 time due to service interactions. If the UUID value of the peer UA 369 changes, the UA MUST accept the new UUID as the peer's UUID and 370 include this new UUID as the "remote" parameter in any subsequent 371 messages. 373 It is also important to note that if an intermediary in the network 374 forks a session, the initiating UA may receive multiple responses 375 back from different endpoints, each of which contains a different 376 UUID ("local-uuid") value. UAs MUST take care to ensure that the 377 correct UUID value is returned in the "remote" parameter when 378 interacting with each endpoint. The one exception is when the UA 379 sends a CANCEL message, in which case the Session-ID header value 380 MUST be identical to the Session-ID header value sent in the original 381 INVITE. 383 A Multipoint Control Unit (MCU) is a special type of conferencing 384 endpoint and is discussed in Section 8. 386 7. Processing by Intermediaries 388 The Call-ID often reveals personal, device, domain or other sensitive 389 information associated with a user, which is why intermediaries, such 390 as session border controllers, sometimes alter the Call-ID. In order 391 to ensure the integrity of the end-to-end Session Identifier, it is 392 constructed in a way which does not reveal such information, removing 393 the need for intermediaries to alter it. As such, intermediaries 394 MUST NOT alter the UUID values found in the Session-ID header, except 395 as described in this section. 397 Intermediary devices that transfer a call, such as by joining 398 together two different "call legs", MUST properly construct a 399 Session-ID header that contains the correct UUID values and correct 400 placement of those values. As described above, the recipient of any 401 message initiated by the intermediary will assume that the first UUID 402 value belongs to the peer endpoint. 404 If an intermediary receives a SIP message without a Session-ID header 405 field or valid header value, the intermediary MAY assign a "local- 406 uuid" value to represent the sending endpoint and insert that value 407 into all signaling messages on behalf of the sending endpoint for 408 that dialog. If the intermediary is aware of a "remote-uuid" value 409 that identifies the receiving UA, it MUST insert that value if also 410 inserting the "local-uuid" value. 412 Whenever there is a UA that does not implement this specification 413 communicating through a B2BUA, the B2BUA MAY become dialog stateful 414 and insert a UUID value into the Session-ID header on behalf of the 415 UA according to the rules stated in Section 6. 417 When an intermediary transmits a provisional response, the "remote- 418 uuid" field will contain the UUID value of the UA that sent the 419 message that prompted the transmission of the provisional response. 420 When the UUID of the destination UA for the message that prompted the 421 transmission of the provisional response is known, the intermediary 422 MUST insert the UUID of the destination UA in the "local-uuid" field 423 of the provisional response. Otherwise, the intermediary MAY set the 424 "local-uuid" field of the provisional response to a locally generated 425 UUID value or the null UUID value. 427 The Session-ID included in a CANCEL request MUST be identical to the 428 Session-ID included in the corresponding INVITE. 430 Devices that initiate communication sessions following the procedures 431 for third party call control MUST fabricate a UUID value that will be 432 utilized only temporarily. Once the responding endpoint provides a 433 UUID value in a response message, the temporary value MUST be 434 discarded and replaced with the endpoint-provided UUID value. Refer 435 to the third-party call control example for an illustration. If the 436 third-party call controller sends a re-INVITE to obtain an offer for 437 connecting the endpoint to a different session, the Session-ID MAY 438 reflect the current session; the ACK's Session-ID would reflect the 439 newly connected session. 441 If a SIP intermediary initiates a dialog between two UAs in a 3PCC 442 scenario, the SIP request in the initial INVITE will have a non-null 443 "local-uuid" value; call this temporary UUID X. The request will 444 still have a null "remote-uuid" value; call this value N. The SIP 445 server MUST be transaction stateful. The UUID pair in the INVITE 446 will be {X,N}. A non-redirected or rejected response will have a 447 UUID pair {A,X}. This transaction stateful, dialog initiating SIP 448 server MUST replace its own UUID, i.e., X, with a null UUID (i.e., 449 {A,N}) as expected by other UAS (see Section 9.7 for an example). 451 8. Associating Endpoints in a Multipoint Conference 453 Multipoint Control Units (MCUs) group two or more sessions into a 454 single multipoint conference. MCUs, including cascaded MCUs, MUST 455 utilize the same UUID value ("local-uuid" portion of the Session-ID 456 header-value) with all participants in the conference. In so doing, 457 each individual session in the conference will have a unique Session 458 Identifier (since each endpoint will create a unique UUID of its 459 own), but will also have one UUID in common with all other 460 participants in the conference. 462 When creating a cascaded conferencing, an MCU MUST convey the UUID 463 value to utilize for a conference via the "local-uuid" portion of the 464 Session-ID header-value in an INVITE to a second MCU when using SIP 465 to establish the cascaded conference. A conference bridge, or MCU, 466 needs a way to identify itself when contacting another MCU. RFC 4579 467 [RFC4579] defines the "isfocus" Contact: header parameter just for 468 this purpose. The initial MCU MUST include the UUID of that 469 particular conference in the "local-uuid" of an INVITE to the other 470 MCU(s) participating in that conference. Also included in this 471 INVITE is an "isfocus" Contact header parameter identifying that this 472 INVITE is coming from an MCU and that this UUID is to be given out in 473 all responses from UAs into those MCUs participating in this same 474 conference. This ensures a single UUID is common across all 475 participating MCUs of the same conference, but is unique between 476 different conferences. 478 Intermediary devices or network diagnostics equipment might assume 479 that when they see two or more sessions with different Session 480 Identifiers, but with one UUID in common, that the sessions are part 481 of the same conference. However, the assumption that two sessions 482 having one common UUID being part of the same conference is not 483 always correct. In a SIP forking scenario, for example, there might 484 also be what appears to be multiple sessions with a shared UUID 485 value; this is intended. The desire is to allow for the association 486 of related sessions, regardless of whether a session is forked or 487 part of a conference. 489 9. Various Call Flow Operations 491 Seeing something frequently makes understanding easier. With that in 492 mind, we include several call flow examples with the initial UUID and 493 the complete Session Identifier indicated per message, as well as 494 when the Session Identifier changes according to the rules within 495 this document during certain operations/functions. 497 This section is for illustrative purposes only and is non-normative. 498 In the following flows, RTP refers to the Real-time Transport 499 Protocol [RFC3550]. 501 In the examples in this section, "N" represents a null UUID and other 502 letters represents the unique UUID values corresponding to endpoints 503 or MCUs. 505 9.1. Basic Call with 2 UUIDs 507 Session-ID 508 --- Alice B2BUA Bob Carol 509 {A,N} |---INVITE F1--->| | 510 {A,N} | |---INVITE F2--->| 511 {B,A} | |<---200 OK F3---| 512 {B,A} |<---200 OK F4---| | 513 {A,B} |-----ACK F5---->| | 514 {A,B} | |-----ACK F6---->| 515 |<==============RTP==============>| 517 Figure 1 - Session-ID Creation when Alice calls Bob 519 General operation of this example: 521 o UA-Alice populates the "local-uuid" portion of the Session-ID 522 header-value. 524 o UA-Alice sends its UUID in the SIP INVITE, and populates the 525 "remote" parameter with a null value (32 zeros). 527 o B2BUA receives an INVITE with both a "local-uuid" portion of 528 the Session-ID header-value from UA-Alice as well as the null 529 "remote-uuid" value, and transmits the INVITE towards UA-Bob 530 with an unchanged Session-ID header-value. 532 o UA-Bob receives Session-ID and generates its "local-uuid" 533 portion of the Session-ID header-value UUID to construct the 534 whole/complete Session-ID header-value, at the same time 535 transferring Alice's UUID unchanged to the "remote-uuid" 536 portion of the Session-ID header-value in the 200 OK SIP 537 response. 539 o B2BUA receives the 200 OK response with a complete Session-ID 540 header-value from UA-Bob, and transmits 200 OK towards UA-Alice 541 with an unchanged Session-ID header-value. 543 o UA-Alice, upon reception of the 200 OK from the B2BUA, 544 transmits the ACK towards the B2BUA. The construction of the 545 Session-ID header-value in this ACK is that of Alice's UUID is 546 the "local-uuid", and Bob's UUID populates the "remote-uuid" 547 portion of the header-value. 549 o B2BUA receives the ACK with a complete Session-ID header-value 550 from UA-Alice, and transmits ACK towards UA-Bob with an 551 unchanged Session-ID header-value. 553 Below is a complete SIP message exchange illustrating proper use of 554 the Session-ID header. For the sake of brevity, non-essential headers 555 and message bodies are omitted. 557 F1 INVITE Alice -> B2BUA 559 INVITE sip:bob@biloxi.com SIP/2.0 560 Via: SIP/2.0/UDP pc33.atlanta.example.com 561 ;branch=z9hG4bK776asdhds 562 Max-Forwards: 70 563 To: Bob 564 From: Alice ;tag=1928301774 565 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 566 Session-ID: ab30317f1a784dc48ff824d0d3715d86 567 ;remote=00000000000000000000000000000000 568 CSeq: 314159 INVITE 569 Contact: 570 Content-Type: application/sdp 571 Content-Length: 142 573 (Alice's SDP not shown) 575 F2 INVITE B2BUA -> Bob 577 INVITE sip:bob@192.168.10.20 SIP/2.0 578 Via: SIP/2.0/UDP server10.biloxi.example.com 579 ;branch=z9hG4bK4b43c2ff8.1 580 Via: SIP/2.0/UDP pc33.atlanta.example.com 581 ;branch=z9hG4bK776asdhds;received=10.1.3.33 582 Max-Forwards: 69 583 To: Bob 584 From: Alice ;tag=1928301774 585 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 586 Session-ID: ab30317f1a784dc48ff824d0d3715d86 587 ;remote=00000000000000000000000000000000 588 CSeq: 314159 INVITE 589 Contact: 590 Record-Route: 591 Content-Type: application/sdp 592 Content-Length: 142 594 (Alice's SDP not shown) 596 F3 200 OK Bob -> B2BUA 597 SIP/2.0 200 OK 598 Via: SIP/2.0/UDP server10.biloxi.example.com 599 ;branch=z9hG4bK4b43c2ff8.1;received=192.168.10.1 600 Via: SIP/2.0/UDP pc33.atlanta.example.com 601 ;branch=z9hG4bK776asdhds;received=10.1.3.33 602 To: Bob ;tag=a6c85cf 603 From: Alice ;tag=1928301774 604 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 605 Session-ID: 47755a9de7794ba387653f2099600ef2 606 ;remote=ab30317f1a784dc48ff824d0d3715d86 607 CSeq: 314159 INVITE 608 Contact: 609 Record-Route: 610 Content-Type: application/sdp 611 Content-Length: 131 613 (Bob's SDP not shown) 615 F4 200 OK B2BUA -> Alice 617 SIP/2.0 200 OK 618 Via: SIP/2.0/UDP pc33.atlanta.example.com 619 ;branch=z9hG4bK776asdhds;received=10.1.3.33 620 To: Bob ;tag=a6c85cf 621 From: Alice ;tag=1928301774 622 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 623 Session-ID: 47755a9de7794ba387653f2099600ef2 624 ;remote=ab30317f1a784dc48ff824d0d3715d86 625 CSeq: 314159 INVITE 626 Contact: 627 Record-Route: 628 Content-Type: application/sdp 629 Content-Length: 131 631 (Bob's SDP not shown) 633 F5 ACK Alice -> B2BUA 635 ACK sip:bob@192.168.10.20 SIP/2.0 636 Via: SIP/2.0/UDP pc33.atlanta.example.com 637 ;branch=z9hG4bKnashds8 639 Route: 640 Max-Forwards: 70 641 To: Bob ;tag=a6c85cf 642 From: Alice ;tag=1928301774 643 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 644 Session-ID: ab30317f1a784dc48ff824d0d3715d86 645 ;remote=47755a9de7794ba387653f2099600ef2 646 CSeq: 314159 ACK 647 Content-Length: 0 649 F6 ACK B2BUA -> Bob 651 ACK sip:bob@192.168.10.20 SIP/2.0 652 Via: SIP/2.0/UDP server10.biloxi.example.com 653 ;branch=z9hG4bK4b43c2ff8.2 654 Via: SIP/2.0/UDP pc33.atlanta.example.com 655 ;branch=z9hG4bKnashds8;received=10.1.3.33 656 Max-Forwards: 70 657 To: Bob ;tag=a6c85cf 658 From: Alice ;tag=1928301774 659 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 660 Session-ID: ab30317f1a784dc48ff824d0d3715d86 661 ;remote=47755a9de7794ba387653f2099600ef2 662 CSeq: 314159 ACK 663 Content-Length: 0 665 The remaining examples in this Section do not display the complete 666 SIP message exchange. Instead, they simply use the set notation 667 described in Section 4.2 to show the Session Identifier exchange 668 throughout the particular call flow being illustrated. 670 9.2. Basic Call Transfer using REFER 672 From the example built within Section 9.1, we proceed to this 'Basic 673 Call Transfer using REFER' example. Note that this is a mid-dialog 674 REFER in contrast with the out-of-dialog REFER in Section 9.9. 676 Session-ID 677 --- Alice B2BUA Bob Carol 678 | | | | 679 |<==============RTP==============>| | 680 {B,A} | |<---re-INVITE---| | 681 {B,A} |<---re-INVITE---| (puts Alice on Hold) | 682 {A,B} |-----200 OK---->| | | 683 {A,B} | |-----200 OK---->| | 684 {B,A} | |<-----ACK-------| | 685 {B,A} |<-----ACK-------| | | 686 | | | | 687 {B,A} | |<----REFER------| | 688 {B,A} |<----REFER------| | | 689 {A,B} |-----200 OK---->| | | 690 {A,B} | |-----200 OK---->| | 691 {A,B} |-----NOTIFY---->| | | 692 {A,B} | |-----NOTIFY---->| | 693 {B,A} | |<----200 OK-----| | 694 {B,A} |<----200 OK-----| | | 695 | | | | 696 {A,N} |-----INVITE---->| | 697 {A,N} | |-----INVITE-------------------->| 698 {C,A} | |<----200 OK---------------------| 699 {C,A} |<----200 OK-----| | 700 {A,C} |------ACK------>| | 701 {A,C} | |------ACK---------------------->| 702 | | | | 703 |<======================RTP======================>| 704 | | | | 705 {A,B} |-----NOTIFY---->| | | 706 {A,B} | |-----NOTIFY---->| | 707 {B,A} | |<----200 OK-----| | 708 {B,A} |<----200 OK-----| | | 709 {B,A} | |<-----BYE-------| | 710 {B,A} |<-----BYE-------| | | 711 {A,B} |-----200 OK---->| | | 712 {A,B} | |-----200 OK---->| | 713 | | | | 715 Figure 2 - Call Transfer using REFER 717 General operation of this example: 719 Starting from the existing Alice/Bob call described in Figure 1 of 720 this document, which established an existing Session-ID header- 721 value... 723 o UA-Bob requests Alice to call Carol, using a REFER transaction, 724 as described in [RFC3515]. UA-Alice is initially put on hold, 725 then told in the REFER who to contact with a new INVITE, in 726 this case UA-Carol. This Alice-to-Carol dialog will have a new 727 Call-ID, therefore it requires a new Session-ID header-value. 728 The wrinkle here is we can, and will, use Alice's UUID from her 729 existing dialog with Bob in the new INVITE to Carol. 731 o UA-Alice retains her UUID from the Alice-to-Bob call {A} when 732 requesting a call with UA-Carol. This is placed in the "local- 733 uuid" portion of the Session-ID header-value, at the same time 734 inserting a null "remote-uuid" value (because Carol's UA has 735 not yet received the UUID value). This same UUID traverses the 736 B2BUA unchanged. 738 o UA-Carol receives the INVITE with a Session Identifier UUID 739 {A,N}, replaces the A UUID value into the "remote-uuid" portion 740 of the Session-ID header-value and creates its own UUID {C} and 741 places this value in the "local-uuid" portion of the Session-ID 742 header-value - thereby removing the N (null) value altogether. 743 This combination forms a full Session Identifier {C,A} in the 744 200 OK to the INVITE. This Session-ID header-value traverses 745 the B2BUA unchanged towards UA-Alice. 747 o UA-Alice receives the 200 OK with the Session Identifier {C,A} 748 and responds to UA-Carol with an ACK (just as in Figure 1 - 749 switches places of the two UUID fields), and generates a NOTIFY 750 to Bob with a Session Identifier {A,B} indicating the call 751 transfer was successful. 753 o It does not matter which UA terminates the Alice-to-Bob call; 754 Figure 2 shows UA-Bob doing this transaction. 756 9.3. Basic Call Transfer using re-INVITE 758 From the example built within Section 9.1, we proceed to this 'Basic 759 Call Transfer using re-INVITE' example. 761 Alice is talking to Bob. Bob pushes a button on his phone to transfer 762 Alice to Carol via the B2BUA (using re-INVITE). 764 Session-ID 765 --- Alice B2BUA Bob Carol 766 | | | | 767 |<==============RTP==============>| | 768 | | | | 769 | | <--- (non-standard signaling) | 770 {A,B} | |---re-INVITE--->| | 771 {B,A} | |<-----200 OK----| | 772 {B,A} | |-----ACK------->| | 773 | | | | 774 {A,N} | |-----INVITE-------------------->| 775 {C,A} | |<----200 OK---------------------| 776 {A,C} | |------ACK---------------------->| 777 | | | | 778 |<======================RTP======================>| 779 | | | | 780 {A,B} | |------BYE------>| | 781 {B,A} | |<----200 OK-----| | 782 | | | | 784 Figure 3 - Call transfer using re-INVITE 786 General operation of this example: 788 o We assume the call between Alice and Bob from Section 9.1 is 789 operational with Session Identifier {A,B}. 791 o Bob uses non-standard signaling to the B2BUA to initiate a call 792 transfer from Alice to Carol. This could also be initiated via 793 a REFER message from Bob, but the signaling that follows might 794 still be similar to the above flow. In either case, Alice is 795 completely unaware of the call transfer until a future point in 796 time when Alice receives a message from Carol. 798 o The B2BUA sends a new INVITE with Alice's UUID {"local-uuid" = 799 "A"} to Carol. 801 o Carol receives the INVITE and accepts the request and adds her 802 UUID {C} to the Session Identifier for this session {"local- 803 uuid" = "C", "remote-uuid" = "A"}. 805 o The B2BUA then terminates the call to Bob with a BYE using the 806 Session Identifier {"local-uuid" = "A", "remote-uuid" = "B"}. 808 9.4. Single Focus Conferencing 810 Multiple users call into a conference server (say, an MCU) to attend 811 one of many conferences hosted on or managed by that server. Each 812 user has to identify which conference they want to join, but this 813 information is not necessarily in the SIP messaging. It might be 814 done by having a dedicated address for the conference or via an IVR, 815 as assumed in this example and depicted with the use of M1, M2, and 816 M3. Each user in this example goes through a two-step process of 817 signaling to gain entry onto their conference call, which the 818 conference focus identifies as M'. 820 Session-ID Conference 821 --- Alice Focus Bob Carol 822 | | | | 823 | | | | 824 {A,N} |----INVITE----->| | | 825 {M1,A} |<---200 OK------| | | 826 {A,M1} |-----ACK------->| | | 827 |<====RTP=======>| | | 828 {M',A} |<---re-INVITE---| | | 829 {A,M'} |-----200 OK---->| | | 830 {M',A} |<-----ACK-------| | | 831 | | | | 832 | | | | 833 {B,N} | |<----INVITE-----| | 834 {M2,B} | |-----200 OK---->| | 835 {B,M2} | |<-----ACK-------| | 836 | |<=====RTP======>| | 838 {M',B} | |---re-INVITE--->| | 839 {B,M'} | |<----200 OK-----| | 840 {M',B} | |------ACK------>| | 841 | | | | 842 | | | | 843 {C,N} | |<--------------------INVITE-----| 844 {M3,C} | |---------------------200 OK---->| 845 {C,M3} | |<---------------------ACK-------| 846 | |<=====================RTP======>| 847 {M',C} | |-------------------re-INVITE--->| 848 {C,M'} | |<--------------------200 OK-----| 849 {M',C} | |----------------------ACK------>| 851 Figure 4 - Single Focus Conference Bridge 853 General operation of this example: 855 Alice calls into a conference server to attend a certain conference. 856 This is a two-step operation since Alice cannot include the 857 conference ID at this time and/or any passcode in the INVITE request. 858 The first step is Alice's UA calling another UA to participate in a 859 session. This will appear to be similar as the call-flow in Figure 1 860 (in section 9.1). What is unique about this call is the second step: 861 the conference server sends a re-INVITE request with its second UUID, 862 but maintaining the UUID Alice sent in the first INVITE. This 863 subsequent UUID from the conference server will be the same for each 864 UA that calls into this conference server participating in this same 865 conference bridge/call, which is generated once Alice typically 866 authenticates and identifies which bridge she wants to participate 867 on. 869 o Alice sends an INVITE to the conference server with her UUID 870 {A} and a "remote-uuid" = N. 872 o The conference server responds with a 200 OK response which 873 replaces the N UUID with a temporary UUID ("M1") as the "local- 874 uuid" and a "remote-uuid" = "A". 876 NOTE: this 'temporary' UUID is a real UUID; it is only temporary 877 to the conference server because it knows that it is going to 878 generate another UUID to replace the one just send in the 200 OK. 880 o Once Alice, the user, gains access to the IVR for this 881 conference server, she enters a specific conference ID and 882 whatever passcode (if needed) to enter a specific conference 883 call. 885 o Once the conference server is satisfied Alice has identified 886 which conference she wants to attend (including any passcode 887 verification), the conference server re-INVITEs Alice to the 888 specific conference and includes the Session-ID header-value of 889 "local-uuid" = "M'" (and "remote-uuid" = "A") for that 890 conference. All valid participants in the same conference will 891 receive this same UUID for identification purposes and to 892 better enable monitoring, and tracking functions. 894 o Bob goes through this two-step process of an INVITE 895 transaction, followed by a re-INVITE transaction to get this 896 same UUID ("M'") for that conference. 898 o In this example, Carol (and each additional user) goes through 899 the same procedures and steps as Alice and Bob to get on this 900 same conference. 902 9.5. Single Focus Conferencing using WebEx 904 Alice, Bob and Carol call into same WebEx conference. 906 Session-ID Conference 907 --- Alice Focus Bob Carol 908 | | | | 909 |<** HTTPS *****>| | | 910 | Transaction | | | 911 | | | | 912 {M,N} |<----INVITE-----| | | 913 {A,M} |-----200 OK---->| | | 914 {M,A} |<-----ACK-------| | | 915 |<=====RTP======>| | | 916 | | | | 917 | |<** HTTPS *****>| | 918 | | Transaction | | 919 | | | | 920 {M,N} | |-----INVITE---->| | 921 {B,M} | |<----200 OK-----| | 922 {M,B} | |------ACK------>| | 923 | |<=====RTP======>| | 924 | | | | 925 | |<****************** HTTPS *****>| 926 | | Transaction | 927 | | | | 928 {M,N} | |--------------------INVITE----->| 929 {C,M} | |<-------------------200 OK------| 930 {M,C} | |---------------------ACK------->| 931 | |<====================RTP=======>| 933 Figure 5 - Single Focus WebEx Conference 935 General operation of this example: 937 o Alice communicates with WebEx server with desire to join a 938 certain meeting, by meeting number; also includes UA-Alice's 939 contact information (phone number, URI and/or IP address, etc.) 940 for each device she wants for this conference call. For 941 example, the audio and video play-out devices could be separate 942 units. 944 o Conference Focus server sends INVITE (Session-ID header-value 945 "local-uuid" = M and a remote UUID of N, where M equals the 946 "local-uuid" for each participant on this conference bridge) to 947 UA-Alice to start session with that server for this A/V 948 conference call. 950 o Upon receiving the INVITE request from the conference focus 951 server, Alice responds with a 200 OK. Her UA moves the "local- 952 uuid" unchanged into the "remote-uuid" field, and generates her 953 own UUID and places that into the "local-uuid" field to 954 complete the Session-ID construction. 956 o Bob and Carol perform same function to join this same A/V 957 conference call as Alice. 959 9.6. Cascading Conference Bridges 961 9.6.1. Establishing a Cascaded Conference 963 To expand conferencing capabilities requires cascading conference 964 bridges. A conference bridge, or MCU, needs a way to identify itself 965 when contacting another MCU. RFC 4579 [RFC4579] defines the 'isfocus' 966 Contact: header parameter just for this purpose. 968 Session-ID 969 --- MCU-1 MCU-2 MCU-3 MCU-4 970 | | | | 971 {M',N} |----INVITE----->| | | 972 {J,M'} |<---200 OK------| | | 973 {M',J} |-----ACK------->| | | 975 Figure 6 - MCUs Communicating Session Identifier UUID for Bridge 977 Regardless of which MCU (1 or 2) a UA contacts for this conference, 978 once the above exchange has been received and acknowledged, the UA 979 will get the same {M',N} UUID pair from the MCU for the complete 980 Session Identifier. 982 A more complex form would be a series of MCUs all being informed of 983 the same UUID to use for a specific conference. This series of MCUs 984 can either be informed 986 o All by one MCU (that initially generates the UUID for the 987 conference). 989 o The MCU that generates the UUID informs one or several MCUs of 990 this common UUID, and they inform downstream MCUs of this 991 common UUID that each will be using for this one conference. 993 Session-ID 994 --- MCU-1 MCU-2 MCU-3 MCU-4 995 | | | | 996 {M',N} |----INVITE----->| | | 997 {J,M'} |<---200 OK------| | | 998 {M',J} |-----ACK------->| | | 999 | | | | 1000 {M',N} |---------------------INVITE----->| | 1001 {K,M'} |<--------------------200 OK------| | 1002 {M',K} |----------------------ACK------->| | 1003 | | | | 1004 {M',N} |-------------------------------------INVITE----->| 1005 {L,M'} |<------------------------------------200 OK------| 1006 {M',L} |--------------------------------------ACK------->| 1008 Figure 7 - MCU Communicating Session Identifier UUID to More than 1009 One MCU 1011 General operation of this example: 1013 o The MCU generating the Session Identifier UUID communicates 1014 this in a separate INVITE, having a Contact header with the 1015 'isfocus' header parameter. This will identify the MCU as what 1016 RFC 4579 calls a conference-aware SIP entity. 1018 o An MCU that receives this {M',N} UUID pair in an inter-MCU 1019 transaction can communicate the M' UUID in a manner in which it 1020 was received to construct a hierarchical cascade (though this 1021 time this second MCU would be the UAC MCU). 1023 o Once the conference is terminated, the cascaded MCUs will 1024 receive a BYE message to terminate the cascade. 1026 9.6.2. Calling into Cascaded Conference Bridges 1028 Here is an example of how a UA, say Robert, calls into a cascaded 1029 conference focus. Because MCU-1 has already contacted MCU-3, the MCU 1030 where Robert is going to join the conference, MCU-3 already has the 1031 Session-ID (M') for this particular conference call. 1033 Session-ID 1034 --- MCU-1 MCU-2 MCU-3 Robert 1035 | | | | 1036 {M',N} |----INVITE----->| | | 1037 {J,M'} |<---200 OK------| | | 1038 {M',J} |-----ACK------->| | | 1039 | | | | 1041 {M',N} |---------------------INVITE----->| | 1042 {K,M'} |<--------------------200 OK------| | 1043 {M',K} |----------------------ACK------->| | 1044 | | | | 1045 {R,N} | | |<---INVITE-----| 1046 (M',R} | | |----200 OK---->| 1047 {R,M'} | | |<----ACK-------| 1049 Figure 8 - A UA Calling into a Cascaded MCU UUID 1051 General operation of this example: 1053 o The UA, Robert in this case, INVITEs the MCU to join a 1054 particular conference call. Robert's UA does not know anything 1055 about whether this is the main MCU of the conference call, or a 1056 cascaded MCU. Robert likely does not know MCUs can be cascaded, 1057 he just wants to join a particular call. Like as with any 1058 standard implementation, he includes a null "remote-uuid". 1060 o The cascaded MCU, upon receiving this INVITE from Robert, 1061 replaces the null UUID with the UUID value communicated from 1062 MCU-1 for this conference call as the "local-uuid" in the SIP 1063 response. Thus, moving Robert's UUID "R" to the "remote-uuid" 1064 value. 1066 o The ACK has the Session-ID {R,M'}, completing the 3-way 1067 handshake for this call establishment. Robert has now joined 1068 the conference call originated from MCU-1. 1070 o Once the conference is terminated, the cascaded MCUs will 1071 receive a BYE message to terminate the cascade. 1073 9.7. Basic 3PCC for two UAs 1075 External entity sets up call to both Alice and Bob for them to talk 1076 to each other. 1078 Session-ID 1079 --- Alice B2BUA Bob Carol 1080 | | | 1081 {X,N} |<----INVITE-----| | 1082 {A,X} |-----200 OK---->| | 1083 {A,N} | |----INVITE----->| 1084 {B,A} | |<---200 OK------| 1085 {B,A} |<-----ACK-------| | 1086 {A,B} | |------ACK------>| 1087 |<==============RTP==============>| 1089 Figure 9 - 3PCC initiated call between Alice and Bob 1091 General operation of this example: 1093 o Some out of band procedure directs a B2BUA (or other SIP 1094 server) to have Alice and Bob talk to each other. In this case, 1095 the SIP server MUST be transaction stateful, if not dialog 1096 stateful. 1098 o The SIP server INVITEs Alice to a session and uses a temporary 1099 UUID {X} and a null UUID pairing. 1101 o Alice receives and accepts this call set-up and replaces the 1102 null UUID with her UUID {A} in the Session Identifier, now 1103 {A,X}. 1105 o The transaction stateful SIP server receives Alice's UUID {A} 1106 in the local UUID portion and keeps it there, and discards its 1107 own UUID {X}, replacing this with a null UUID value in the 1108 INVITE to Bob as if this came from Alice originally. 1110 o Bob receives and accepts this INVITE and adds his own UUID {B} 1111 to the Session Identifier, now {B,A} for the response. 1113 o And the session is established. 1115 9.8. Handling in 100 Trying SIP Response and CANCEL Request 1117 The following two subsections show examples of the Session Identifier 1118 for a 100 Trying response and a CANCEL request in a single call-flow. 1120 9.8.1. Handling in a 100 Trying SIP Response 1122 The following 100 Trying response is taken from an existing RFC, from 1123 [RFC5359] Section 2.9 ("Call Forwarding - No Answer"). 1125 Session-ID Alice SIP Server Bob-1 Bob-2 1126 | | | | 1127 {A,N} |----INVITE----->| | | 1128 {A,N} | |---INVITE---->| | 1129 {N,A} |<--100 Trying---| | | 1130 {B1,A} | |<-180 Ringing-| | 1131 {B1,A} |<--180 Ringing--| | | 1132 | | | | 1133 | *Request Timeout* | 1134 | | | | 1135 {A,N} | |---CANCEL---->| | 1136 {B1,A} | |<--200 OK-----| | 1137 {B1,A} | |<---487-------| | 1138 {A,B1} | |---- ACK ---->| | 1139 | | | | 1140 {N,A} |<-181 Call Fwd--| | | 1141 | | | | 1142 {A,N} | |------------------INVITE------>| 1143 {B2,A} | |<----------------180 Ringing---| 1144 {B2,A} |<-180 Ringing---| | | 1145 {B2,A} | |<-----------------200 OK ------| 1146 {B2,A} |<--200 OK-------| | | 1147 {A,B2} |----ACK-------->| | | 1148 {A,B2} | |------------------ACK--------->| 1149 | | | | 1150 |<=========== Both way RTP Established =========>| 1151 | | | | 1152 {A,B2} |----BYE-------->| | | 1153 {A,B2} | |--------------------BYE------->| 1154 {B2,A} | |<------------------200 OK------| 1155 {B2,A} |<--200 OK-------| | | 1156 | | | | 1158 Figure 10 - Session Identifier in the 100 Trying and CANCEL Messaging 1160 Below is the explanatory text from RFC 5359 Section 2.9 detailing 1161 what the desired behavior is in the above call flow (i.e., what the 1162 call-flow is attempting to achieve). 1164 "Bob wants calls to B1 forwarded to B2 if B1 is not answered 1165 (information is known to the SIP server). Alice calls B1 and no 1166 one answers. The SIP server then places the call to B2." 1168 General operation of this example: 1170 o Alice generates an INVITE request because she wants to invite 1171 Bob to join her session. She creates a UUID as described in 1172 section 9.1, and places that value in the "local-uuid" field of 1173 the Session-ID header-value. Alice also generates a "remote- 1174 uuid" of null and sends this along with the "local-uuid". 1176 o The SIP server (imagine this is a B2BUA), upon receiving 1177 Alice's INVITE, generates the optional provisional response 100 1178 Trying. Since the SIP server has no knowledge Bob's UUID for 1179 his part of the Session Identifier value, it cannot include his 1180 "local-uuid". Rather, any 100 Trying response includes Alice's 1181 UUID in the "remote-uuid" portion of the Session-ID header- 1182 value with a null "local-uuid" value in the response. This is 1183 consistent with what Alice's UA expects to receive in any SIP 1184 response containing this UUID. 1186 9.8.2. Handling a CANCEL SIP Request 1188 In the same call-flow example as the 100 Trying response is a CANCEL 1189 request. Please refer to Figure 10 for the CANCEL request example. 1191 General operation of this example: 1193 o In Figure 10 above, Alice generates an INVITE with her UUID 1194 value in the Session-ID header-value. 1196 o Bob-1 responds to this INVITE with a 180 Ringing. In that 1197 response, he includes his UUID in the Session-ID header-value 1198 (i.e., {B1,A}); thus completing the Session-ID header-value for 1199 this session, even though no final response has been generated 1200 by any of Bob's UAs. 1202 o While this means that if the SIP server were to generate a SIP 1203 request within this session it could include the complete 1204 SessionID, the server sends a CANCEL and a CANCEL MUST always 1205 use the same Session-ID header value as the original INVITE. 1206 Thus, the CANCEL would have a Session Identifier with the 1207 "local-uuid" = "A", and the "remote-uuid" = "N". 1209 o As it happens with this CANCEL, the SIP server intends to 1210 invite another UA of Bob (i.e., B2) for Alice to communicate 1211 with. 1213 o In this example call-flow, taken from RFC 5359, Section 2.9, a 1214 181 (Call is being Forwarded) response is sent to Alice. Since 1215 the SIP server generated this SIP request, and has no knowledge 1216 of Bob-2's UUID value, it cannot include that value in this 1217 181. Thus, and for the exact reasons the 100 Trying including 1218 the Session Identifier value, only Alice's UUID is included in 1219 the remote-uuid field of the Session-ID header-value, with a 1220 null UUID present in the "local-uuid" field. 1222 9.9. Out-of-dialog REFER Transaction 1224 The following call-flow was extracted from Section 6.1 of [RFC5589] 1225 ("Successful Transfer"), with the only changes being the names of the 1226 UAs to maintain consistency within this document. 1228 Alice is the transferee 1229 Bob is the transferer 1230 and Carol is the transfer-target 1232 Session-ID Bob Alice Carol 1233 | | | 1234 {A,N} |<-----INVITE--------| | 1235 {B,A} |------200 OK------->| | 1236 {A,B} |<------ACK----------| | 1237 | | | 1238 {B,A} |--INVITE {hold}---->| | 1239 {A,B} |<-200 OK------------| | 1240 {B,A} |--- ACK ----------->| | 1241 | | | 1242 {B,A} |--REFER------------>|(Refer-To:Carol) | 1243 {A,B} |<-202 Accepted------| | 1244 | | | 1245 {A,B} || | 1247 | | | 1248 {A,N} | |--INVITE------------>| 1249 {C,A} | |<-200 OK-------------| 1250 {A,C} | |---ACK-------------->| 1251 | | | 1252 {A,B} |<--NOTIFY {200 OK}--| | 1253 {B,A} |---200 OK---------->| | 1254 | | | 1255 {B,A} |--BYE-------------->| | 1256 {A,B} |<-200 OK------------| | 1257 {C,A} | |<------------BYE-----| 1258 {A,C} | |-------------200 OK->| 1260 Figure 11: Out-Of-Dialog Call Transfer 1262 General operation of this example: 1264 o Just as in Section 9.2, Figure 2, Alice invites Bob to a 1265 session, and Bob eventually transfers Alice to communicate with 1266 Carol. 1268 o What is different about the call-flow in Figure 11 is that 1269 Bob's REFER is not in-dialog. Even so, this is treated as part 1270 of the same communication session and, thus, the Session 1271 Identifier in those messages is {A,B}. 1273 o Alice will use her existing UUID and the null UUID ({A,N}) in 1274 the INVITE towards Carol (who generates UUID "C" for this 1275 session), thus maintaining the common UUID within the Session 1276 Identifier for this new Alice-to-Carol session. 1278 10. Compatibility with a Previous Implementation 1280 There is a much earlier and proprietary document that specifies the 1281 use of a Session-ID header (namely, [RFC7329]) that we will herewith 1282 attempt to achieve backwards compatibility. Neither Session-ID 1283 header has any versioning information, so merely adding that this 1284 document describes "version 2" is insufficient. Here are the set of 1285 rules for compatibility between the two specifications. For the 1286 purposes of this discussion, we will label the proprietary 1287 specification of the Session-ID as the "old" version and this 1288 specification as the "new" version of the Session-ID. 1290 The previous (i.e., "old") version only has a single value as a 1291 Session-ID, but has a generic-parameter value that can be of use. 1293 In order to have an "old" version talk to an "old" version 1294 implementation, nothing needs to be done as far as the IETF is 1295 concerned. 1297 In order to have a "new" version talk to a "new" version 1298 implementation, both implementations need to follow this document (to 1299 the letter) and everything should be just fine. 1301 But that is where compatibility is not ensured, given the unknowns 1302 related to the behavior of entities implementing the pre-standard 1303 implementation. For this "new" implementation to work with the "old" 1304 implementation and an "old" implementation to work with "new" 1305 implementations, there needs to be a set of rules that all "new" 1306 implementations MUST follow. 1308 - Since no option tags or feature tags are to be used for 1309 distinguishing versions, the presence and order of any "remote- 1310 uuid" value within the Session-ID header value is to be used to 1311 distinguish implementation versions. 1313 - If a SIP request has a "remote-uuid" value, this comes from a 1314 standard implementation, and not a pre-standard one. 1316 - If a SIP request has no "remote-uuid" value, this comes from a pre- 1317 standard implementation, and not a standard one. In this case, one 1318 UUID is used to identify this dialog, even if the responder is a 1319 standard implementation of this specification. 1321 - If a SIP response has a non-null "local-uuid" that is 32 octets 1322 long and differs from the endpoint's own UUID value, this response 1323 comes from a standard implementation. 1325 - If a SIP response has a non-null "local-uuid" that is not 32 octets 1326 long, this response comes from a misbehaving implementation, and 1327 its Session-ID header value MUST be discarded. That said, the 1328 response might still be valid according to the rules within SIP 1329 [RFC3261], and SHOULD be checked further. 1331 - If a SIP response arrives that has the same value of Session-ID 1332 UUIDs in the same order as was sent, this comes from a pre-standard 1333 implementation, and MUST NOT be discarded for not altering the null 1334 "remote-uuid". In this case, any new transaction within this 1335 dialog MUST preserve the order of the two UUIDs within all Session- 1336 ID header-values, including the ACK, until this dialog is 1337 terminated. 1339 - If a SIP response only contains the "local-uuid" that was sent 1340 originally, this comes from a pre-standard implementation and MUST 1341 NOT be discarded for removing the null "remote-uuid". In this 1342 case, all future transactions within this dialog MUST contain only 1343 the UUID received in the first SIP response. Any new transaction 1344 starting a new dialog from the standard Session-ID implementation 1345 MUST include a "local-uuid" and a null "remote-uuid", even if that 1346 new dialog is between the same two UAs. 1348 - Standard implementations SHOULD NOT expect pre-standard 1349 implementations to be consistent in their implementation, even 1350 within the same dialog. For example, perhaps the first, third and 1351 tenth responses contain a "remote-uuid", but all the others do not. 1352 This behavior MUST be allowed by implementations of this 1353 specification. 1355 - The foregoing does not apply to other, presently unknown parameters 1356 that might be defined in the future. They are ignored for the 1357 purposes of interoperability with previous implementations. 1359 11. Security Considerations 1361 When creating a UUID value, endpoints MUST ensure that there is no 1362 user or device-identifying information contained within the UUID. In 1363 particular, this means that a UUID MUST NOT be constructed using a 1364 MAC address on the host. 1366 The Session Identifier might be utilized for logging or 1367 troubleshooting, but MUST NOT be used for billing purposes. 1369 The Session Identifier could be misused to discover relationships 1370 between two or more parties. For example, suppose that Alice calls 1371 Bob and Bob, via his PBX, forwards or transfers the call to Carol. 1372 Without use of the Session Identifier, an unauthorized third party 1373 that is observing the communications between Alice and Bob might not 1374 know that Alice is actually communicating with Carol. If Alice, Bob, 1375 and Carol include the Session Identifier as a part of the signaling 1376 messages, it is possible for the third party to observe that the 1377 endpoint associated with Bob changed to some other endpoint. If the 1378 third party also has access to signaling messages between Bob and 1379 Carol, the third party can then discover that Alice is communicating 1380 with Carol. This would be true even if all other information 1381 relating to the session is changed by the PBX, including both 1382 signaling information and media address information. 1384 12. IANA Considerations 1386 12.1. Registration of the "Session-ID" Header Field 1388 The following is the registration for the 'Session-ID' header field 1389 to the "Header Name" registry at 1390 http://www.iana.org/assignments/sip-parameters: 1392 RFC number: RFC XXXX 1394 Header name: 'Session-ID' 1396 Compact form: none 1397 Note: This document replaces the "Session-ID" header originally 1398 registered via [RFC7329]. 1400 [RFC Editor: Please replace XXXX in this section and the next with 1401 the this RFC number of this document.] 1403 12.2. Registration of the "remote" Parameter 1405 The following parameter is to be added to the "Header Field 1406 Parameters and Parameter Values" section of the SIP parameter 1407 registry: 1409 +------------------+----------------+-------------------+-----------+ 1410 | Header Field | Parameter Name | Predefined Values | Reference | 1411 +------------------+----------------+-------------------+-----------+ 1412 | Session-ID | remote | No | [RFCXXXX] | 1413 +------------------+----------------+-------------------+-----------+ 1415 13. Acknowledgments 1417 The authors would like to thank Robert Sparks, Hadriel Kaplan, 1418 Christer Holmberg, Paul Kyzivat, Brett Tate, Keith Drage, Mary 1419 Barnes, Charles Eckel, Peter Dawes, Andrew Hutton, Arun Arunachalam, 1420 Adam Gensler, Roland Jesske, and Faisal Siyavudeen for their 1421 invaluable comments during the development of this document. 1423 14. References 1425 14.1. Normative References 1427 [RFC3261] Rosenberg, J., et al., "SIP: Session Initiation 1428 Protocol", RFC 3261, June 2002. 1430 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1431 Requirement Levels", BCP 14, RFC 2119, March 1997. 1433 [RFC4122] Leach, P., Mealling, M., Salz, R., "A Universally Unique 1434 IDentifier (UUID) URN Namespace", RFC 4122, July 2005. 1436 [RFC5234] Crocker, D., Overell, P, "Augmented BNF for Syntax 1437 Specifications: ABNF", RFC 5234, January 2008. 1439 [RFC4579] Johnston, A., Levin, O., "Session Initiation Protocol 1440 (SIP) Call Control - Conferencing for User Agents", RFC 1441 4579, August 2006. 1443 [RFC3891] Mahy, R., Biggs, B., Dean, R., 'The Session Initiation 1444 Protocol (SIP) "Replaces" Header', RFC 3891, September 1445 2004. 1447 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1448 Method", RFC 3515, April 2003. 1450 [RFC7329] Kaplan, H., "A Session Identifier for the Session 1451 Initiation Protocol (SIP)", RFC 7329, August 2014. 1453 14.2. Informative References 1455 [H.323] Recommendation ITU-T H.323, "Packet-based multimedia 1456 communications systems", December 2009. 1458 [RFC3550] Schulzrinne, H., et al., "RTP: A Transport Protocol for 1459 Real-Time Applications", RFC 3550, July 2003. 1461 [RFC7206] Jones, et al., "Requirements for an End-to-End Session 1462 Identification in IP-Based Multimedia Communication 1463 Networks", RFC 7206, May 2014. 1465 [RFC5359] Johnston, A., et al., "Session Initiation Protocol 1466 Service Examples", RFC 5359, October 2008. 1468 [RFC5589] Sparks, R., Johnston, A., and D. Petrie, "Session 1469 Initiation Protocol (SIP) Call Control - Transfer", RFC 1470 5589, June 2009. 1472 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E. and J. 1473 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1474 March 1999. 1476 [H.460.27] Recommendation ITU-T H.460.27, "End-to-End Session 1477 Identification", Work In Progress. 1479 Authors' Addresses 1481 Paul E. Jones (Ed.) 1482 Cisco Systems, Inc. 1483 7025 Kit Creek Rd. 1484 Research Triangle Park, NC 27709 1485 USA 1487 Phone: +1 919 476 2048 1488 Email: paulej@packetizer.com 1489 IM: xmpp:paulej@packetizer.com 1491 Chris Pearce 1492 Cisco Systems, Inc. 1493 2300 East President George Bush Highway 1494 Richardson, TX 75082 1495 USA 1497 Phone: +1 972 813 5123 1498 Email: chrep@cisco.com 1499 IM: xmpp:chrep@cisco.com 1501 James Polk (Ed.) 1502 Cisco Systems, Inc. 1503 3913 Treemont Circle 1504 Colleyville, Texas 1505 USA 1507 Phone: +1 817 271 3552 1508 Email: jmpolk@cisco.com 1509 IM: xmpp:jmpolk@cisco.com 1511 Gonzalo Salgueiro 1512 Cisco Systems, Inc. 1513 7025 Kit Creek Rd. 1514 Research Triangle Park, NC 27709 1515 USA 1517 Phone: +1 919 392 3266 1518 Email: gsalguei@cisco.com 1519 IM: xmpp:gsalguei@cisco.com