idnits 2.17.1 draft-ietf-insipid-session-id-15.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 (September 25, 2015) is 3129 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 297, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1524, 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 3 Internet Draft G. Salgueiro 4 Intended status: Standards Track C. Pearce 5 Expires: March 25, 2016 Cisco Systems 6 September 25, 2015 8 End-to-End Session Identification in IP-Based Multimedia 9 Communication Networks 10 draft-ietf-insipid-session-id-15 12 Abstract 14 This document describes an end-to-end Session Identifier for use in 15 IP-based multimedia communication systems that enables endpoints, 16 intermediary devices, and management systems to identify a session 17 end-to-end, associate multiple endpoints with a given multipoint 18 conference, track communication sessions when they are redirected, 19 and associate one or more media flows with a given communication 20 session. 22 This document also describes a backwards compatibility mechanism for 23 an existing (RFC 7329) session identifier implementation that is 24 sufficiently different from the procedures defined in this document. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 This Internet-Draft will expire on March 25, 2016. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction...................................................3 67 2. Conventions used in this document..............................3 68 3. Session Identifier Requirements and Use Cases..................4 69 4. Constructing and Conveying the Session Identifier..............4 70 4.1. Constructing the Session Identifier.......................4 71 4.2. Conveying the Session Identifier..........................5 72 5. The Session-ID Header Field....................................6 73 6. Endpoint Behavior..............................................7 74 7. Processing by Intermediaries...................................9 75 8. Associating Endpoints in a Multipoint Conference..............11 76 9. Examples of Various Call Flow Operations......................12 77 9.1. Basic Call with 2 UUIDs..................................12 78 9.2. Basic Call Transfer using REFER..........................16 79 9.3. Basic Call Transfer using re-INVITE......................18 80 9.4. Single Focus Conferencing................................19 81 9.5. Single Focus Conferencing using WebEx....................21 82 9.6. Cascading Conference Bridges.............................22 83 9.6.1. Establishing a Cascaded Conference..................22 84 9.6.2. Calling into Cascaded Conference Bridges............23 85 9.7. Basic 3PCC for two UAs...................................24 86 9.8. Handling in 100 Trying SIP Response and CANCEL Request...25 87 9.8.1. Handling in a 100 Trying SIP Response...............25 88 9.8.2. Handling a CANCEL SIP Request.......................27 89 9.9. Out-of-dialog REFER Transaction..........................27 90 10. Compatibility with a Previous Implementation.................28 91 11. Security Considerations......................................30 92 12. IANA Considerations..........................................31 93 12.1. Registration of the "Session-ID" Header Field...........31 94 12.2. Registration of the "remote" Parameter..................31 95 13. Acknowledgments..............................................31 96 14. Dedication...................................................31 97 15. References...................................................32 98 15.1. Normative References....................................32 99 15.2. Informative References..................................32 101 Authors' Addresses...............................................34 103 1. Introduction 105 IP-based multimedia communication systems like SIP [RFC3261] and 106 H.323 [H.323] have the concept of a "call identifier" that is 107 globally unique. The identifier is intended to represent an end-to- 108 end communication session from the originating device to the 109 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 as it passes through the device, including the 123 value of the call identifier. While this is deliberate and useful, 124 it 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 9. Additionally, the specification attempts to account for a 133 previous, proprietary version of a SIP Session Identifier header 134 [RFC7329], specifying a backwards compatibility approach in section 135 10. 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 RFC 2119 [RFC2119] 142 when they appear in ALL CAPS. These words may also appear in this 143 document in lower case as plain English words, absent their normative 144 meanings. 146 The term "Session Identifier" refers to the value of the identifier, 147 whereas "Session-ID" refers to the header field used to convey the 148 identifier. The Session Identifier is a set of two Universally 149 Unique Identifiers (UUIDs) and each element of that set is simply 150 referred to herein as a UUID. 152 Throughout this document, the term "endpoint" refers to a SIP User 153 Agent (UA) that either initiates or terminates a SIP session, such as 154 a user's mobile phone or a conference server, but excludes entities 155 like B2BUAs that are generally located along the call signaling path 156 between endpoints. The term "intermediary" refers to any SIP entity 157 along the call signaling path between the aforementioned endpoints, 158 including Back-to-Back User Agents (B2BUAs) and SIP proxies. 160 3. Session Identifier Requirements and Use Cases 162 Requirements and use cases for the end-to-end Session Identifier, 163 along with a definition of "session identifier" and "communication 164 session", can be found in [RFC7206]. 166 As mentioned in section 6.1 of RFC 7206, the ITU-T undertook a 167 parallel effort to define compatible procedures for an H.323 Session 168 Identifier. They are documented in [H.460.27]. 170 4. Constructing and Conveying the Session Identifier 172 4.1. Constructing the Session Identifier 174 The Session Identifier comprises two UUIDs [RFC4122], with each UUID 175 representing one of the endpoints participating in the session. 177 The version number in the UUID indicates the manner in which the UUID 178 is generated, such as using random values or using the MAC address of 179 the endpoint. To satisfy the requirement that no user or device 180 information be conveyed, endpoints SHOULD generate version 4 (random) 181 or version 5 (SHA-1) UUIDs to address privacy concerns related to use 182 of MAC addresses in UUIDs. 184 When generating a version 5 UUID, endpoints or intermediaries MUST 185 utilize the procedures defined in Section 4.3 of [RFC4122] and employ 186 the following "name space ID": 188 uuid_t NameSpace_SessionID = { 189 /* a58587da-c93d-11e2-ae90-f4ea67801e29 */ 190 0xa58587da, 191 0xc93d, 192 0x11e2, 193 0xae, 0x90, 0xf4, 0xea, 0x67, 0x80, 0x1e, 0x29 194 } 196 Further, the "name" to utilize for version 5 UUIDs is the 197 concatenation of the Call-ID header-value and the "tag" parameter 198 that appears on the "From" or "To" line associated with the device 199 for which the UUID is created. Once an endpoint generates a UUID for 200 a session, the UUID never changes, even if values originally used as 201 input into its construction change over time. 203 Stateless intermediaries that insert a Session-ID header field into a 204 SIP message on behalf of an endpoint MUST utilize version 5 UUIDs to 205 ensure that UUIDs for the communication session are consistently 206 generated. If a stateless intermediary does not know the tag value 207 for the endpoint (e.g., a new INVITE without a To: tag value or an 208 older SIP [RFC2543] implementation that did not include a tag 209 parameter), the intermediary MUST NOT attempt to generate a UUID for 210 that endpoint. Note that if an intermediary is stateless and the 211 endpoint on one end of the call is replaced with another endpoint due 212 to some service interaction, the values used to create the UUID 213 should change and, if so, the intermediary will compute a different 214 UUID. 216 4.2. Conveying the Session Identifier 218 The SIP User Agent (UA) initially transmitting the SIP request 219 ("Alice"), i.e., a User Agent Client (UAC), will create a UUID and 220 transmit that to the ultimate destination UA ("Bob"). Likewise, the 221 destination UA ("Bob"), i.e., a User Agent Server (UAS), will create 222 a UUID and transmit that to the first UA ("Alice"). These two 223 distinct UUIDs form what is referred to as the Session Identifier and 224 is represented in this document in set notation of the form {A,B}, 225 where "A" is UUID value created by UA "Alice" and "B" is the UUID 226 value created by UA "Bob". The Session Identifier {A,B} is equal to 227 the Session Identifier {B,A}. 229 In the case where only one UUID is known, such as when a UA first 230 initiates a SIP request, the Session Identifier would be {A,N}, where 231 "A" represents the UUID value transmitted by the UA "Alice" and "N" 232 is what is referred to as the null UUID (see section 5). 234 Since SIP sessions are subject to any number of service interactions, 235 SIP INVITE messages might be forked as sessions are established, and 236 since conferences might be established or expanded with endpoints 237 calling in or the conference focus calling out, the construction of 238 the Session Identifier as a set of UUIDs is important. 240 To understand this better, consider that an endpoint participating in 241 a communication session might be replaced with another, such as the 242 case where two "legs" of a call are joined together by a PBX. 243 Suppose "Alice" and "Bob" both call UA C ("Carol"). There would be 244 two distinctly identifiable Session Identifiers, namely {A,C} and 245 {B,C}. Then suppose that "Carol" uses a local PBX function to join 246 the call between herself and "Alice" with the call between herself 247 and "Bob", resulting in a single remaining call between "Alice" and 248 "Bob". This merged call can be identified using two UUID values 249 assigned by each entity in the communication session, namely {A,B} in 250 this example. 252 In the case of forking, "Alice" might send an INVITE that gets forked 253 to several different endpoints. A means of identifying each of these 254 separate communication sessions is needed and, since each of the 255 destination UAs will create its own UUID, each communication session 256 would be uniquely identified by the values {A, B1}, {A, B2}, {A, B3}, 257 and so on, where each of the Bn values refers to the UUID created by 258 the different UAs to which the SIP session is forked. 260 For conferencing scenarios, it is also useful to have a two-part 261 Session Identifier where the conference focus specifies the same UUID 262 for each conference participant. This allows for correlation among 263 the participants in a single conference. For example, in a 264 conference with three participants, the Session Identifiers might be 265 {A,M}, {B,M}, and {C,M}, where "M" is assigned by the conference 266 focus. Only a conference focus will purposely utilize the same UUID 267 for more than one SIP session and, even then, such reuse MUST be 268 restricted to the participants in the same conference. 270 How a device acting on Session Identifiers stores, processes, or 271 utilizes the Session Identifier is outside the scope of this 272 document. 274 5. The Session-ID Header Field 276 The syntax specified here replaces the Session-ID header field syntax 277 defined in RFC 7329 [RFC7329]. 279 Each endpoint participating in a communication session has a 280 distinct, preferably locally-generated, UUID associated with it. The 281 endpoint's UUID value remains unchanged throughout the duration of 282 the communication session. An intermediary MAY generate a UUID on 283 behalf of an endpoint that did not include a UUID of its own. 285 The UUID values for each endpoint are inserted into the "Session-ID" 286 header field of all transmitted SIP messages. The Session-ID header 287 field has the following ABNF [RFC5234] syntax: 289 session-id = "Session-ID" HCOLON session-id-value 291 session-id-value = local-uuid *(SEMI sess-id-param) 293 local-uuid = sess-uuid / null 295 remote-uuid = sess-uuid / null 297 sess-uuid = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] 299 sess-id-param = remote-param / generic-param 301 remote-param = "remote" EQUAL remote-uuid 303 null = 32("0") 305 The productions "SEMI", "EQUAL", and "generic-param" are defined in 306 [RFC3261]. The production DIGIT is defined in [RFC5234]. 308 The Session-ID header field MUST NOT have more than one "remote" 309 parameter. In the case where an entity compliant with this 310 specification is interworking with an entity that implemented 311 [RFC7329], the "remote" parameter may be absent, but otherwise the 312 remote parameter MUST be present. The details under which those 313 conditions apply are described in Section 10. Except for backwards 314 compatibility with [RFC7329], the "remote" parameter MUST be present. 316 A special null UUID value composed of 32 zeros is required in certain 317 situations. A null UUID is expected as the "remote-uuid" of every 318 initial standard SIP request since the initiating endpoint would not 319 initially know the UUID value of the remote endpoint. This null 320 value will get replaced by the ultimate destination UAS when that UAS 321 generates response message. One caveat is explained in Section 10 322 for a possible backwards compatibility case. A null UUID value is 323 also returned by some intermediary devices that send provisional 324 responses as the "local-uuid" component of the Session-ID header 325 field value, as described in Section 7. 327 The "local-uuid" in the Session-ID header field represents the UUID 328 value of the endpoint transmitting a message and the "remote-uuid" in 329 the Session-ID header field represents the UUID of the endpoint's 330 peer. For example, a Session-ID header field might appear like this: 332 Session-ID: ab30317f1a784dc48ff824d0d3715d86; 333 remote=47755a9de7794ba387653f2099600ef2 335 While this is the general form of the Session-ID header field, 336 exceptions to syntax and procedures are detailed in subsequent 337 sections. 339 The UUID values are presented as strings of lower-case hexadecimal 340 characters, with the most significant octet of the UUID appearing 341 first. 343 The Session-ID header field value is technically case-INSENSITIVE, 344 but only lowercase characters are allowed in the sess-uuid 345 components. Receiving entities MUST treat sess-uuid components as 346 case-insensitive and not produce an error if an uppercase hexadecimal 347 character is received. 349 6. Endpoint Behavior 351 To comply with this specification, endpoints (non-intermediaries) 352 MUST include a Session-ID header field value in all SIP messages 353 transmitted as a part of a communication session. The locally- 354 generated UUID of the transmitter of the message MUST appear in the 355 "local-uuid" portion of the Session-ID header field value. The UUID 356 of the peer device, if known, MUST appear as the "remote" parameter 357 following the transmitter's UUID. The null UUID value MUST be used 358 if the peer device's UUID is not known. 360 Once an endpoint allocates a UUID value for a communication session, 361 the endpoint MUST NOT change that UUID value for the duration of the 362 session, including when 364 - communication attempts are retried due to receipt of 4xx 365 messages or request timeouts; 367 - the session is redirected in response to a 3xx message; or 369 - a session is transferred via a REFER message [RFC3515]; or 371 - a SIP dialog is replaced via an INVITE with Replaces [RFC3891]. 373 An endpoint that receives a Session-ID header field MUST take note of 374 any non-null "local-uuid" value that it receives and assume that is 375 the UUID of the peer endpoint within that communications session. 376 Endpoints MUST include this received UUID value as the "remote" 377 parameter when transmitting subsequent messages, making sure not to 378 change this UUID value in the process of moving the value internally 379 from the "local-uuid" field to the "remote-uuid" field. 381 If an endpoint receives a 3xx or 4xx message, receives a REFER that 382 directs the endpoint to a different peer, or receives an INVITE with 383 Replaces that also potentially results in communicating with a new 384 peer, the endpoint MUST complete any message exchanges with its 385 current peer using the existing Session Identifier, but MUST NOT use 386 the current peer's UUID value when sending the first message to what 387 it believes may be a new peer endpoint (even if the exchange results 388 in communicating with the same physical or logical entity). The 389 endpoint MUST retain its own UUID value, however, as described above. 391 It should be noted that messages received by an endpoint might 392 contain a "local-uuid" value that does not match what the endpoint 393 expected its peer's UUID to be. It is also possible for an endpoint 394 to receive a "remote-uuid" value that does not match its generated 395 UUID for the session. Either might happen as a result of service 396 interactions by intermediaries and MUST NOT negatively affect the 397 communication session. However, the endpoint may log this event for 398 the purposes of troubleshooting. 400 An endpoint MUST assume that the UUID value of the peer endpoint MAY 401 change at any time due to service interactions. If the UUID value of 402 the peer changes, the endpoint MUST accept the new UUID as the peer's 403 UUID and include this new UUID as the "remote" parameter in any 404 subsequent messages. 406 It is also important to note that if an intermediary in the network 407 forks a session, the endpoint initiating a session may receive 408 multiple responses back from different endpoints, each of which 409 contains a different UUID ("local-uuid") value. Endpoints MUST take 410 care to ensure that the correct UUID value is returned in the 411 "remote" parameter when interacting with each endpoint. The one 412 exception is when the endpoint sends a CANCEL message, in which case 413 the Session-ID header field value MUST be identical to the Session-ID 414 header field value sent in the original INVITE. 416 If an endpoint receives a message that does not contain a Session-ID 417 header field, that message MUST have no effect on what the endpoint 418 believes is the UUID value of the remote endpoint. That is, the 419 endpoint MUST NOT change the internally maintained "remote-uuid" 420 value for the peer. 422 A Multipoint Control Unit (MCU) is a special type of conferencing 423 endpoint and is discussed in Section 8. 425 7. Processing by Intermediaries 427 The following applies only to an intermediary that wishes to comply 428 with this specification and does not impose a conformance requirement 429 on intermediaries that elect to not provide any special treatment for 430 the Session-ID header field. 432 The Call-ID often reveals personal, device, domain or other sensitive 433 information associated with a user, which is why intermediaries, such 434 as session border controllers, sometimes alter the Call-ID. In order 435 to ensure the integrity of the end-to-end Session Identifier, it is 436 constructed in a way which does not reveal such information, removing 437 the need for intermediaries to alter it. 439 When an intermediary receives messages from one endpoint in a 440 communication session that causes the transmission of one or more 441 messages toward the second endpoint in a communication session, the 442 intermediary MUST include the Session-ID header field in the 443 transmitted messages with the same UUID values found in the received 444 message, except as outlined in this section. 446 If the intermediary aggregates several responses from different 447 endpoints, as described in Section 16.7 of [RFC3261], the 448 intermediary MUST set the local-uuid field to the null UUID value 449 when forwarding the aggregated response to the endpoint since the 450 true UUID value of the peer is undetermined at that point. 452 Intermediary devices that transfer a call, such as by joining 453 together two different "call legs", MUST properly construct a 454 Session-ID header field that contains the correct UUID values and 455 correct placement of those values. As described in Section 6, the 456 endpoint receiving a message transmitted by the intermediary will 457 assume that the first UUID value belongs to its peer endpoint. 459 If an intermediary receives a SIP message from an endpoint without a 460 Session-ID header field or valid header field value, the intermediary 461 MAY assign a "local-uuid" value to represent that endpoint and, 462 having done so, MUST insert that assigned value into all signaling 463 messages on behalf of the endpoint for that dialog. If the 464 intermediary is aware of the UUID value that identifies the endpoint 465 to which a message is directed, it MUST insert that UUID value into 466 the Session-ID header field value as the "remote-uuid" value. If the 467 intermediary is unaware of the UUID value that identifies the 468 receiving endpoint, it MUST use the null UUID value as the "remote- 469 uuid" value. 471 Whenever there is an endpoint communicating through a B2BUA that does 472 not implement this specification, the B2BUA MAY become dialog 473 stateful and insert a UUID value into the Session-ID header field 474 value on behalf of the endpoint, at which point it MUST follow the 475 endpoint procedures in Section 6 with respect to Session-ID header 476 field value treatment with itself acting as the endpoint (for the 477 purposes of the Session-ID header field) for which it inserted a 478 component into the Session-ID header field value. 480 When an intermediary originates a response, such as a provisional 481 response or a response to a CANCEL request, the "remote-uuid" field 482 will contain the UUID value of the receiving endpoint. When the UUID 483 of the peer endpoint is known, the intermediary MUST insert the UUID 484 of the peer endpoint in the "local-uuid" field of the header value. 485 Otherwise, the intermediary MAY set the "local-uuid" field of the 486 header value to the "null" UUID value. 488 When an intermediary originates a request message without first 489 having received a SIP message that triggered the transmission of the 490 message (e.g., sending a BYE message to terminate a call for policy 491 reasons), the intermediary MUST, if it has knowledge of the UUID 492 values for the two communicating endpoints, insert a Session-ID 493 header field with the "remote-uuid" field of the header value set to 494 the UUID value of the receiving endpoint and the "local-uuid" field 495 of the header value set to the UUID value of the other endpoint. 496 When the intermediary does not have knowledge of the UUID value of am 497 endpoint in the communication session, the intermediary SHOULD set 498 the unknown UUID value(s) to the "null" UUID value. (If both are 499 unknown, the Session-ID header value SHOULD NOT be included at all, 500 since it would have no practical value.) 502 With respect to the previous two paragraphs, note that if an 503 intermediary transmits a "null" UUID value, the receiving endpoint 504 might use that value in subsequent messages it sends. This 505 effectively violates the requirement of maintaining an end-to-end 506 Session Identifier value for the communication session if a UUID for 507 the peer endpoint had been previously conveyed. Therefore, an 508 intermediary MUST only send the "null" UUID when the intermediary has 509 not communicated with the peer endpoint to learn its UUID. This 510 means that intermediaries SHOULD maintain state related to the UUID 511 values for both ends of a communication session if it intends to 512 originate messages (versus merely conveying messages). An 513 intermediary that does not maintain this state and that originates a 514 message as described in the previous two paragraph MUST NOT insert a 515 Session-ID header field in order to avoid unintended, incorrect 516 reassignment of a UUID value. 518 The Session-ID header field value included in a CANCEL request MUST 519 be identical to the Session-ID header field value included in the 520 corresponding INVITE. 522 If a SIP intermediary initiates a dialog between two endpoints in a 523 3PCC [RFC3725] scenario, the SIP request in the initial INVITE will 524 have a non-null, locally-frabricated "local-uuid" value; call this 525 temporary UUID X. The request will still have a null "remote-uuid" 526 value; call this value N. The SIP server MUST be transaction 527 stateful. The UUID pair in the INVITE will be {X,N}. A non- 528 redirected or rejected response will have a UUID pair {A,X}. This 529 transaction stateful, dialog initiating SIP server MUST replace its 530 own UUID, i.e., X, with a null UUID (i.e., {A,N}) as expected by 531 other UAS (see Section 9.7 for an example). 533 Intermediaries that manipulate messages containing a Session-ID 534 header field SHOULD be aware of what UUID values it last sent towards 535 an endpoint and, following any kind of service interaction initiated 536 or affected by the intermediary, of what UUID values the receiving 537 endpoint should have knowledge to ensure that both endpoints in the 538 session have the correct and same UUID values. If an intermediary 539 can determine that an endpoint might not have received a current, 540 correct Session-ID field, the Intermediary SHOULD attempt to provide 541 the correct Session-ID header field to the endpoint such as by 542 sending a re-INVITE message. 544 8. Associating Endpoints in a Multipoint Conference 546 Multipoint Control Units (MCUs) group two or more sessions into a 547 single multipoint conference and have a conference Focus responsible 548 for maintaining the dialogs connected to it [RFC4353]. MCUs, 549 including cascaded MCUs, MUST utilize the same UUID value ("local- 550 uuid" portion of the Session-ID header field value) with all 551 participants in the conference. In so doing, each individual session 552 in the conference will have a unique Session Identifier (since each 553 endpoint will create a unique UUID of its own), but will also have 554 one UUID in common with all other participants in the conference. 556 When creating a cascaded conference, an MCU MUST convey the UUID 557 value to utilize for a conference via the "local-uuid" portion of the 558 Session-ID header field value in an INVITE to a second MCU when using 559 SIP to establish the cascaded conference. A conference bridge, or 560 MCU, needs a way to identify itself when contacting another MCU. 561 [RFC4579] defines the "isfocus" Contact header field value parameter 562 just for this purpose. The initial MCU MUST include the UUID of that 563 particular conference in the "local-uuid" of an INVITE to the other 564 MCU(s) participating in that conference. Also included in this 565 INVITE is an "isfocus" Contact header field value parameter 566 identifying that this INVITE is coming from an MCU and that this UUID 567 is to be given out in all responses from endpoints into those MCUs 568 participating in this same conference. This ensures a single UUID is 569 common across all participating MCUs of the same conference, but is 570 unique between different conferences. 572 Intermediary devices or network diagnostics equipment might assume 573 that when they see two or more sessions with different Session 574 Identifiers, but with one UUID in common, that the sessions are part 575 of the same conference. However, the assumption that two sessions 576 having one common UUID being part of the same conference is not 577 always correct. In a SIP forking scenario, for example, there might 578 also be what appears to be multiple sessions with a shared UUID 579 value; this is intended. The desire is to allow for the association 580 of related sessions, regardless of whether a session is forked or 581 part of a conference. 583 9. Examples of Various Call Flow Operations 585 Seeing something frequently makes understanding easier. With that in 586 mind, this section includes several call flow examples with the 587 initial UUID and the complete Session Identifier indicated per 588 message, as well as when the Session Identifier changes according to 589 the rules within this document during certain operations/functions. 591 This section is for illustrative purposes only and is non-normative. 592 In the following flows, RTP refers to the Real-time Transport 593 Protocol [RFC3550]. 595 In the examples in this section, "N" represents a null UUID and other 596 letters represents the unique UUID values corresponding to endpoints 597 or MCUs. 599 9.1. Basic Call with 2 UUIDs 601 Session-ID 602 --- Alice B2BUA Bob Carol 603 {A,N} |---INVITE F1--->| | 604 {A,N} | |---INVITE F2--->| 605 {B,A} | |<---200 OK F3---| 606 {B,A} |<---200 OK F4---| | 607 {A,B} |-----ACK F5---->| | 608 {A,B} | |-----ACK F6---->| 609 |<==============RTP==============>| 611 Figure 1 - Session-ID Creation when Alice calls Bob 613 General operation of this example: 615 o UA-Alice populates the "local-uuid" portion of the Session-ID 616 header field value. 618 o UA-Alice sends its UUID in the SIP INVITE, and populates the 619 "remote" parameter with a null value (32 zeros). 621 o B2BUA receives an INVITE with both a "local-uuid" portion of 622 the Session-ID header field value from UA-Alice as well as the 623 null "remote-uuid" value, and transmits the INVITE towards UA- 624 Bob with an unchanged Session-ID header field value. 626 o UA-Bob receives Session-ID and generates its "local-uuid" 627 portion of the Session-ID header field value UUID to construct 628 the whole/complete Session-ID header field value, at the same 629 time transferring Alice's UUID unchanged to the "remote-uuid" 630 portion of the Session-ID header field value in the 200 OK SIP 631 response. 633 o B2BUA receives the 200 OK response with a complete Session-ID 634 header field value from UA-Bob, and transmits 200 OK towards 635 UA-Alice with an unchanged Session-ID header field value. 637 o UA-Alice, upon reception of the 200 OK from the B2BUA, 638 transmits the ACK towards the B2BUA. The construction of the 639 Session-ID header field in this ACK is that of Alice's UUID is 640 the "local-uuid", and Bob's UUID populates the "remote-uuid" 641 portion of the header-value. 643 o B2BUA receives the ACK with a complete Session-ID header field 644 from UA-Alice, and transmits ACK towards UA-Bob with an 645 unchanged Session-ID header field value. 647 Below is a complete SIP message exchange illustrating proper use of 648 the Session-ID header field. For the sake of brevity, non-essential 649 headers and message bodies are omitted. 651 F1 INVITE Alice -> B2BUA 653 INVITE sip:bob@biloxi.com SIP/2.0 654 Via: SIP/2.0/UDP pc33.atlanta.example.com 655 ;branch=z9hG4bK776asdhds 656 Max-Forwards: 70 657 To: Bob 658 From: Alice ;tag=1928301774 659 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 660 Session-ID: ab30317f1a784dc48ff824d0d3715d86 661 ;remote=00000000000000000000000000000000 662 CSeq: 314159 INVITE 663 Contact: 664 Content-Type: application/sdp 665 Content-Length: 142 667 (Alice's SDP not shown) 669 F2 INVITE B2BUA -> Bob 671 INVITE sip:bob@192.168.10.20 SIP/2.0 672 Via: SIP/2.0/UDP server10.biloxi.example.com 673 ;branch=z9hG4bK4b43c2ff8.1 674 Via: SIP/2.0/UDP pc33.atlanta.example.com 675 ;branch=z9hG4bK776asdhds;received=10.1.3.33 676 Max-Forwards: 69 677 To: Bob 678 From: Alice ;tag=1928301774 679 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 680 Session-ID: ab30317f1a784dc48ff824d0d3715d86 681 ;remote=00000000000000000000000000000000 682 CSeq: 314159 INVITE 683 Contact: 684 Record-Route: 685 Content-Type: application/sdp 686 Content-Length: 142 688 (Alice's SDP not shown) 690 F3 200 OK Bob -> B2BUA 692 SIP/2.0 200 OK 693 Via: SIP/2.0/UDP server10.biloxi.example.com 694 ;branch=z9hG4bK4b43c2ff8.1;received=192.168.10.1 695 Via: SIP/2.0/UDP pc33.atlanta.example.com 696 ;branch=z9hG4bK776asdhds;received=10.1.3.33 697 To: Bob ;tag=a6c85cf 698 From: Alice ;tag=1928301774 699 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 700 Session-ID: 47755a9de7794ba387653f2099600ef2 701 ;remote=ab30317f1a784dc48ff824d0d3715d86 702 CSeq: 314159 INVITE 703 Contact: 704 Record-Route: 705 Content-Type: application/sdp 706 Content-Length: 131 708 (Bob's SDP not shown) 710 F4 200 OK B2BUA -> Alice 712 SIP/2.0 200 OK 713 Via: SIP/2.0/UDP pc33.atlanta.example.com 714 ;branch=z9hG4bK776asdhds;received=10.1.3.33 715 To: Bob ;tag=a6c85cf 716 From: Alice ;tag=1928301774 717 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 718 Session-ID: 47755a9de7794ba387653f2099600ef2 719 ;remote=ab30317f1a784dc48ff824d0d3715d86 720 CSeq: 314159 INVITE 721 Contact: 722 Record-Route: 723 Content-Type: application/sdp 724 Content-Length: 131 726 (Bob's SDP not shown) 728 F5 ACK Alice -> B2BUA 730 ACK sip:bob@192.168.10.20 SIP/2.0 731 Via: SIP/2.0/UDP pc33.atlanta.example.com 732 ;branch=z9hG4bKnashds8 733 Route: 734 Max-Forwards: 70 735 To: Bob ;tag=a6c85cf 736 From: Alice ;tag=1928301774 737 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 738 Session-ID: ab30317f1a784dc48ff824d0d3715d86 739 ;remote=47755a9de7794ba387653f2099600ef2 740 CSeq: 314159 ACK 741 Content-Length: 0 743 F6 ACK B2BUA -> Bob 745 ACK sip:bob@192.168.10.20 SIP/2.0 746 Via: SIP/2.0/UDP server10.biloxi.example.com 747 ;branch=z9hG4bK4b43c2ff8.2 748 Via: SIP/2.0/UDP pc33.atlanta.example.com 749 ;branch=z9hG4bKnashds8;received=10.1.3.33 750 Max-Forwards: 70 751 To: Bob ;tag=a6c85cf 752 From: Alice ;tag=1928301774 753 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 754 Session-ID: ab30317f1a784dc48ff824d0d3715d86 755 ;remote=47755a9de7794ba387653f2099600ef2 756 CSeq: 314159 ACK 757 Content-Length: 0 759 The remaining examples in this Section do not display the complete 760 SIP message exchange. Instead, they simply use the set notation 761 described in Section 4.2 to show the Session Identifier exchange 762 throughout the particular call flow being illustrated. 764 9.2. Basic Call Transfer using REFER 766 From the example built within Section 9.1, we proceed to this 'Basic 767 Call Transfer using REFER' example. Note that this is a mid-dialog 768 REFER in contrast with the out-of-dialog REFER in Section 9.9. 770 Session-ID 771 --- Alice B2BUA Bob Carol 772 | | | | 773 |<==============RTP==============>| | 774 {B,A} | |<---re-INVITE---| | 775 {B,A} |<---re-INVITE---| (puts Alice on Hold) | 776 {A,B} |-----200 OK---->| | | 777 {A,B} | |-----200 OK---->| | 778 {B,A} | |<-----ACK-------| | 779 {B,A} |<-----ACK-------| | | 780 | | | | 781 {B,A} | |<----REFER------| | 782 {B,A} |<----REFER------| | | 783 {A,B} |-----200 OK---->| | | 784 {A,B} | |-----200 OK---->| | 785 {A,B} |-----NOTIFY---->| | | 786 {A,B} | |-----NOTIFY---->| | 787 {B,A} | |<----200 OK-----| | 788 {B,A} |<----200 OK-----| | | 789 | | | | 790 {A,N} |-----INVITE---->| | 791 {A,N} | |-----INVITE-------------------->| 792 {C,A} | |<----200 OK---------------------| 793 {C,A} |<----200 OK-----| | 794 {A,C} |------ACK------>| | 795 {A,C} | |------ACK---------------------->| 796 | | | | 797 |<======================RTP======================>| 798 | | | | 799 {A,B} |-----NOTIFY---->| | | 800 {A,B} | |-----NOTIFY---->| | 801 {B,A} | |<----200 OK-----| | 802 {B,A} |<----200 OK-----| | | 803 {B,A} | |<-----BYE-------| | 804 {B,A} |<-----BYE-------| | | 805 {A,B} |-----200 OK---->| | | 806 {A,B} | |-----200 OK---->| | 807 | | | | 809 Figure 2 - Call Transfer using REFER 811 General operation of this example: 813 Starting from the existing Alice/Bob call described in Figure 1 of 814 this document, which established an existing Session-ID header field 815 value: 817 o UA-Bob requests Alice to call Carol, using a REFER transaction, 818 as described in [RFC3515]. UA-Alice is initially put on hold, 819 then told in the REFER who to contact with a new INVITE, in 820 this case UA-Carol. This Alice-to-Carol dialog will have a new 821 Call-ID, therefore it requires a new Session-ID header field 822 value. The wrinkle here is we can, and will, use Alice's UUID 823 from her existing dialog with Bob in the new INVITE to Carol. 825 o UA-Alice retains her UUID from the Alice-to-Bob call {A} when 826 requesting a call with UA-Carol. This is placed in the "local- 827 uuid" portion of the Session-ID header field value, at the same 828 time inserting a null "remote-uuid" value (because Carol's UA 829 has not yet received the UUID value). This same UUID traverses 830 the B2BUA unchanged. 832 o UA-Carol receives the INVITE with a Session Identifier UUID 833 {A,N}, replaces the A UUID value into the "remote-uuid" portion 834 of the Session-ID header field value and creates its own UUID 835 {C} and places this value in the "local-uuid" portion of the 836 Session-ID header field value, thereby removing the N (null) 837 value altogether. This combination forms a full Session 838 Identifier {C,A} in the 200 OK to the INVITE. This Session-ID 839 header field traverses the B2BUA unchanged towards UA-Alice. 841 o UA-Alice receives the 200 OK with the Session Identifier {C,A} 842 and responds to UA-Carol with an ACK (just as in Figure 1 - 843 switches places of the two UUID fields), and generates a NOTIFY 844 to Bob with a Session Identifier {A,B} indicating the call 845 transfer was successful. 847 o It does not matter which UA terminates the Alice-to-Bob call; 848 Figure 2 shows UA-Bob doing this transaction. 850 9.3. Basic Call Transfer using re-INVITE 852 From the example built within Section 9.1, we proceed to this 'Basic 853 Call Transfer using re-INVITE' example. 855 Alice is talking to Bob. Bob pushes a button on his phone to transfer 856 Alice to Carol via the B2BUA (using re-INVITE). 858 Session-ID 859 --- Alice B2BUA Bob Carol 860 | | | | 861 |<==============RTP==============>| | 862 | | | | 863 | | <--- (non-standard signaling) | 864 {A,B} | |---re-INVITE--->| | 865 {B,A} | |<-----200 OK----| | 866 {B,A} | |-----ACK------->| | 867 | | | | 868 {A,N} | |-----INVITE-------------------->| 869 {C,A} | |<----200 OK---------------------| 870 {A,C} | |------ACK---------------------->| 871 | | | | 872 |<======================RTP======================>| 873 | | | | 874 {A,B} | |------BYE------>| | 875 {B,A} | |<----200 OK-----| | 876 | | | | 877 | (Suppose Alice modifies the session) | 878 {A,B} |---re-INVITE--->| | | 879 {A,B} | |---re-INVITE------------------->| 880 {C,A} | |<---200 OK----------------------| 881 {C,A} |<---200 OK------| | | 882 {A,C} |------ACK------>| | | 883 {A,C} | |------ACK---------------------->| 884 | | | | 886 Figure 3 - Call transfer using re-INVITE 888 General operation of this example: 890 o We assume the call between Alice and Bob from Section 9.1 is 891 operational with Session Identifier {A,B}. 893 o Bob uses non-standard signaling to the B2BUA to initiate a call 894 transfer from Alice to Carol. This could also be initiated via 895 a REFER message from Bob, but the signaling that follows might 896 still be similar to the above flow. In either case, Alice is 897 completely unaware of the call transfer until a future point in 898 time when Alice receives a message from Carol. 900 o The B2BUA sends a new INVITE with Alice's UUID {"local-uuid" = 901 "A"} to Carol. 903 o Carol receives the INVITE and accepts the request and adds her 904 UUID {C} to the Session Identifier for this session {"local- 905 uuid" = "C", "remote-uuid" = "A"}. 907 o The B2BUA then terminates the call to Bob with a BYE using the 908 Session Identifier {"local-uuid" = "A", "remote-uuid" = "B"}. 910 o Since Alice never received Carol's UUID from the B2BUA, when 911 Alice later attempts to modify the session with a re-INVITE, 912 Alice would send the "remote-uuid" = "B" toward Carol. Carol 913 replies with the "local-uuid" = "A", "remote-uuid" = "A" to 914 reflect what was received in the INVITE (which Carol already 915 knew from previous exchanges with the B2BUA). Alice then 916 includes "remote-uuid" = "C" in the following ACK message. 918 9.4. Single Focus Conferencing 920 Multiple users call into a conference server (say, an MCU) to attend 921 one of many conferences hosted on or managed by that server. Each 922 user has to identify which conference they want to join, but this 923 information is not necessarily in the SIP messaging. It might be 924 done by having a dedicated address for the conference or via an IVR, 925 as assumed in this example and depicted with the use of M1, M2, and 926 M3. Each user in this example goes through a two-step process of 927 signaling to gain entry onto their conference call, which the 928 conference focus identifies as M'. 930 Session-ID Conference 931 --- Alice Focus Bob Carol 932 | | | | 933 | | | | 934 {A,N} |----INVITE----->| | | 935 {M1,A} |<---200 OK------| | | 936 {A,M1} |-----ACK------->| | | 937 |<====RTP=======>| | | 938 {M',A} |<---re-INVITE---| | | 939 {A,M'} |-----200 OK---->| | | 940 {M',A} |<-----ACK-------| | | 941 | | | | 942 | | | | 943 {B,N} | |<----INVITE-----| | 944 {M2,B} | |-----200 OK---->| | 945 {B,M2} | |<-----ACK-------| | 946 | |<=====RTP======>| | 947 {M',B} | |---re-INVITE--->| | 948 {B,M'} | |<----200 OK-----| | 949 {M',B} | |------ACK------>| | 950 | | | | 951 | | | | 952 {C,N} | |<--------------------INVITE-----| 953 {M3,C} | |---------------------200 OK---->| 954 {C,M3} | |<---------------------ACK-------| 955 | |<=====================RTP======>| 956 {M',C} | |-------------------re-INVITE--->| 957 {C,M'} | |<--------------------200 OK-----| 958 {M',C} | |----------------------ACK------>| 960 Figure 4 - Single Focus Conference Bridge 962 General operation of this example: 964 Alice calls into a conference server to attend a certain conference. 965 This is a two-step operation since Alice cannot include the 966 conference ID at this time and/or any passcode in the INVITE request. 967 The first step is Alice's UA calling another UA to participate in a 968 session. This will appear to be similar as the call-flow in Figure 1 969 (in section 9.1). What is unique about this call is the second step: 970 the conference server sends a re-INVITE request with its second UUID, 971 but maintaining the UUID Alice sent in the first INVITE. This 972 subsequent UUID from the conference server will be the same for each 973 UA that calls into this conference server participating in this same 974 conference bridge/call, which is generated once Alice typically 975 authenticates and identifies which bridge she wants to participate 976 on. 978 o Alice sends an INVITE to the conference server with her UUID 979 {A} and a "remote-uuid" = N. 981 o The conference server responds with a 200 OK response which 982 replaces the N UUID with a temporary UUID ("M1") as the "local- 983 uuid" and a "remote-uuid" = "A". 985 NOTE: this 'temporary' UUID is a real UUID; it is only temporary 986 to the conference server because it knows that it is going to 987 generate another UUID to replace the one just send in the 200 OK. 989 o Once Alice, the user, gains access to the IVR for this 990 conference server, she enters a specific conference ID and 991 whatever passcode (if needed) to enter a specific conference 992 call. 994 o Once the conference server is satisfied Alice has identified 995 which conference she wants to attend (including any passcode 996 verification), the conference server re-INVITEs Alice to the 997 specific conference and includes the Session-ID header field 998 value component "local-uuid" = "M'" (and "remote-uuid" = "A") 999 for that conference. All valid participants in the same 1000 conference will receive this same UUID for identification 1001 purposes and to better enable monitoring, and tracking 1002 functions. 1004 o Bob goes through this two-step process of an INVITE 1005 transaction, followed by a re-INVITE transaction to get this 1006 same UUID ("M'") for that conference. 1008 o In this example, Carol (and each additional user) goes through 1009 the same procedures and steps as Alice and Bob to get on this 1010 same conference. 1012 9.5. Single Focus Conferencing using WebEx 1014 Alice, Bob and Carol call into same WebEx conference. 1016 Session-ID Conference 1017 --- Alice Focus Bob Carol 1018 | | | | 1019 |<** HTTPS *****>| | | 1020 | Transaction | | | 1021 | | | | 1022 {M,N} |<----INVITE-----| | | 1023 {A,M} |-----200 OK---->| | | 1024 {M,A} |<-----ACK-------| | | 1025 |<=====RTP======>| | | 1026 | | | | 1027 | |<** HTTPS *****>| | 1028 | | Transaction | | 1029 | | | | 1030 {M,N} | |-----INVITE---->| | 1031 {B,M} | |<----200 OK-----| | 1032 {M,B} | |------ACK------>| | 1033 | |<=====RTP======>| | 1034 | | | | 1035 | |<****************** HTTPS *****>| 1036 | | Transaction | 1037 | | | | 1038 {M,N} | |--------------------INVITE----->| 1039 {C,M} | |<-------------------200 OK------| 1040 {M,C} | |---------------------ACK------->| 1041 | |<====================RTP=======>| 1043 Figure 5 - Single Focus WebEx Conference 1045 General operation of this example: 1047 o Alice communicates with WebEx server with desire to join a 1048 certain meeting, by meeting number; also includes UA-Alice's 1049 contact information (phone number, URI and/or IP address, etc.) 1050 for each device she wants for this conference call. For 1051 example, the audio and video play-out devices could be separate 1052 units. 1054 o Conference Focus server sends INVITE (Session-ID header field 1055 value components "local-uuid" = M and a remote UUID of N, where 1056 M equals the "local-uuid" for each participant on this 1057 conference bridge) to UA-Alice to start session with that 1058 server for this A/V conference call. 1060 o Upon receiving the INVITE request from the conference focus 1061 server, Alice responds with a 200 OK. Her UA moves the "local- 1062 uuid" unchanged into the "remote-uuid" field, and generates her 1063 own UUID and places that into the "local-uuid" field to 1064 complete the Session-ID construction. 1066 o Bob and Carol perform same function to join this same A/V 1067 conference call as Alice. 1069 9.6. Cascading Conference Bridges 1071 9.6.1. Establishing a Cascaded Conference 1073 To expand conferencing capabilities requires cascading conference 1074 bridges. A conference bridge, or MCU, needs a way to identify itself 1075 when contacting another MCU. RFC 4579 [RFC4579] defines the 'isfocus' 1076 Contact: header parameter just for this purpose. 1078 Session-ID 1079 --- MCU-1 MCU-2 MCU-3 MCU-4 1080 | | | | 1081 {M',N} |----INVITE----->| | | 1082 {J,M'} |<---200 OK------| | | 1083 {M',J} |-----ACK------->| | | 1085 Figure 6 - MCUs Communicating Session Identifier UUID for Bridge 1087 Regardless of which MCU (1 or 2) a UA contacts for this conference, 1088 once the above exchange has been received and acknowledged, the UA 1089 will get the same {M',N} UUID pair from the MCU for the complete 1090 Session Identifier. 1092 A more complex form would be a series of MCUs all being informed of 1093 the same UUID to use for a specific conference. This series of MCUs 1094 can either be informed 1096 o All by one MCU (that initially generates the UUID for the 1097 conference). 1099 o The MCU that generates the UUID informs one or several MCUs of 1100 this common UUID, and they inform downstream MCUs of this 1101 common UUID that each will be using for this one conference. 1103 Session-ID 1104 --- MCU-1 MCU-2 MCU-3 MCU-4 1105 | | | | 1106 {M',N} |----INVITE----->| | | 1107 {J,M'} |<---200 OK------| | | 1108 {M',J} |-----ACK------->| | | 1109 | | | | 1110 {M',N} |---------------------INVITE----->| | 1111 {K,M'} |<--------------------200 OK------| | 1112 {M',K} |----------------------ACK------->| | 1113 | | | | 1114 {M',N} |-------------------------------------INVITE----->| 1115 {L,M'} |<------------------------------------200 OK------| 1116 {M',L} |--------------------------------------ACK------->| 1118 Figure 7 - MCU Communicating Session Identifier UUID to More than 1119 One MCU 1121 General operation of this example: 1123 o The MCU generating the Session Identifier UUID communicates 1124 this in a separate INVITE, having a Contact header with the 1125 'isfocus' header parameter. This will identify the MCU as what 1126 RFC 4579 calls a conference-aware SIP entity. 1128 o An MCU that receives this {M',N} UUID pair in an inter-MCU 1129 transaction can communicate the M' UUID in a manner in which it 1130 was received to construct a hierarchical cascade (though this 1131 time this second MCU would be the UAC MCU). 1133 o Once the conference is terminated, the cascaded MCUs will 1134 receive a BYE message to terminate the cascade. 1136 9.6.2. Calling into Cascaded Conference Bridges 1138 Here is an example of how a UA, say Robert, calls into a cascaded 1139 conference focus. Because MCU-1 has already contacted MCU-3, the MCU 1140 where Robert is going to join the conference, MCU-3 already has the 1141 Session-ID (M') for this particular conference call. 1143 Session-ID 1144 --- MCU-1 MCU-2 MCU-3 Robert 1145 | | | | 1146 {M',N} |----INVITE----->| | | 1147 {J,M'} |<---200 OK------| | | 1148 {M',J} |-----ACK------->| | | 1149 | | | | 1150 {M',N} |---------------------INVITE----->| | 1151 {K,M'} |<--------------------200 OK------| | 1152 {M',K} |----------------------ACK------->| | 1153 | | | | 1154 {R,N} | | |<---INVITE-----| 1155 (M',R} | | |----200 OK---->| 1156 {R,M'} | | |<----ACK-------| 1158 Figure 8 - A UA Calling into a Cascaded MCU UUID 1160 General operation of this example: 1162 o The UA, Robert in this case, INVITEs the MCU to join a 1163 particular conference call. Robert's UA does not know anything 1164 about whether this is the main MCU of the conference call, or a 1165 cascaded MCU. Robert likely does not know MCUs can be cascaded, 1166 he just wants to join a particular call. Like as with any 1167 standard implementation, he includes a null "remote-uuid". 1169 o The cascaded MCU, upon receiving this INVITE from Robert, 1170 replaces the null UUID with the UUID value communicated from 1171 MCU-1 for this conference call as the "local-uuid" in the SIP 1172 response. Thus, moving Robert's UUID "R" to the "remote-uuid" 1173 value. 1175 o The ACK has the Session-ID {R,M'}, completing the 3-way 1176 handshake for this call establishment. Robert has now joined 1177 the conference call originated from MCU-1. 1179 o Once the conference is terminated, the cascaded MCUs will 1180 receive a BYE message to terminate the cascade. 1182 9.7. Basic 3PCC for two UAs 1184 External entity sets up call to both Alice and Bob for them to talk 1185 to each other. 1187 Session-ID 1188 --- Alice B2BUA Bob Carol 1189 | | | 1190 {X,N} |<----INVITE-----| | 1191 {A,X} |-----200 OK---->| | 1192 {A,N} | |----INVITE----->| 1193 {B,A} | |<---200 OK------| 1194 {B,A} |<-----ACK-------| | 1195 {A,B} | |------ACK------>| 1196 |<==============RTP==============>| 1198 Figure 9 - 3PCC initiated call between Alice and Bob 1200 General operation of this example: 1202 o Some out of band procedure directs a B2BUA (or other SIP 1203 server) to have Alice and Bob talk to each other. In this case, 1204 the SIP server has to be transaction stateful, if not dialog 1205 stateful. 1207 o The SIP server INVITEs Alice to a session and uses a temporary 1208 UUID {X} and a null UUID pairing. 1210 o Alice receives and accepts this call set-up and replaces the 1211 null UUID with her UUID {A} in the Session Identifier, now 1212 {A,X}. 1214 o The transaction stateful SIP server receives Alice's UUID {A} 1215 in the local UUID portion and keeps it there, and discards its 1216 own UUID {X}, replacing this with a null UUID value in the 1217 INVITE to Bob as if this came from Alice originally. 1219 o Bob receives and accepts this INVITE and adds his own UUID {B} 1220 to the Session Identifier, now {B,A} for the response. 1222 o And the session is established. 1224 9.8. Handling in 100 Trying SIP Response and CANCEL Request 1226 The following two subsections show examples of the Session Identifier 1227 for a 100 Trying response and a CANCEL request in a single call-flow. 1229 9.8.1. Handling in a 100 Trying SIP Response 1231 The following 100 Trying response is taken from an existing RFC, from 1232 [RFC5359] Section 2.9 ("Call Forwarding - No Answer"). 1234 Session-ID Alice SIP Server Bob-1 Bob-2 1235 | | | | 1236 {A,N} |----INVITE----->| | | 1237 {A,N} | |---INVITE---->| | 1238 {N,A} |<--100 Trying---| | | 1239 {B1,A} | |<-180 Ringing-| | 1240 {B1,A} |<--180 Ringing--| | | 1241 | | | | 1242 | *Request Timeout* | 1243 | | | | 1244 {A,N} | |---CANCEL---->| | 1245 {B1,A} | |<--200 OK-----| | 1246 {B1,A} | |<---487-------| | 1247 {A,B1} | |---- ACK ---->| | 1248 | | | | 1249 {N,A} |<-181 Call Fwd--| | | 1250 | | | | 1251 {A,N} | |------------------INVITE------>| 1252 {B2,A} | |<----------------180 Ringing---| 1253 {B2,A} |<-180 Ringing---| | | 1254 {B2,A} | |<-----------------200 OK ------| 1255 {B2,A} |<--200 OK-------| | | 1256 {A,B2} |----ACK-------->| | | 1257 {A,B2} | |------------------ACK--------->| 1258 | | | | 1259 |<=========== Both way RTP Established =========>| 1260 | | | | 1261 {A,B2} |----BYE-------->| | | 1262 {A,B2} | |--------------------BYE------->| 1263 {B2,A} | |<------------------200 OK------| 1264 {B2,A} |<--200 OK-------| | | 1265 | | | | 1267 Figure 10 - Session Identifier in the 100 Trying and CANCEL Messaging 1269 Below is the explanatory text from RFC 5359 Section 2.9 detailing 1270 what the desired behavior is in the above call flow (i.e., what the 1271 call-flow is attempting to achieve). 1273 "Bob wants calls to B1 forwarded to B2 if B1 is not answered 1274 (information is known to the SIP server). Alice calls B1 and no 1275 one answers. The SIP server then places the call to B2." 1277 General operation of this example: 1279 o Alice generates an INVITE request because she wants to invite 1280 Bob to join her session. She creates a UUID as described in 1281 section 9.1, and places that value in the "local-uuid" field of 1282 the Session-ID header field value. Alice also generates a 1283 "remote-uuid" of null and sends this along with the "local- 1284 uuid". 1286 o The SIP server (imagine this is a B2BUA), upon receiving 1287 Alice's INVITE, generates the optional provisional response 100 1288 Trying. Since the SIP server has no knowledge Bob's UUID for 1289 his part of the Session Identifier value, it cannot include his 1290 "local-uuid". Rather, any 100 Trying response includes Alice's 1291 UUID in the "remote-uuid" portion of the Session-ID header- 1292 value with a null "local-uuid" value in the response. This is 1293 consistent with what Alice's UA expects to receive in any SIP 1294 response containing this UUID. 1296 9.8.2. Handling a CANCEL SIP Request 1298 In the same call-flow example as the 100 Trying response is a CANCEL 1299 request. Please refer to Figure 10 for the CANCEL request example. 1301 General operation of this example: 1303 o In Figure 10 above, Alice generates an INVITE with her UUID 1304 value in the Session-ID header field. 1306 o Bob-1 responds to this INVITE with a 180 Ringing. In that 1307 response, he includes his UUID in the Session-ID header field 1308 value (i.e., {B1,A}); thus completing the Session-ID header 1309 field for this session, even though no final response has been 1310 generated by any of Bob's UAs. 1312 o While this means that if the SIP server were to generate a SIP 1313 request within this session it could include the complete 1314 SessionID, the server sends a CANCEL and a CANCEL always uses 1315 the same Session-ID header field as the original INVITE. Thus, 1316 the CANCEL would have a Session Identifier with the "local- 1317 uuid" = "A", and the "remote-uuid" = "N". 1319 o As it happens with this CANCEL, the SIP server intends to 1320 invite another UA of Bob (i.e., B2) for Alice to communicate 1321 with. 1323 o In this example call-flow, taken from RFC 5359, Section 2.9, a 1324 181 (Call is being Forwarded) response is sent to Alice. Since 1325 the SIP server generated this SIP request, and has no knowledge 1326 of Bob-2's UUID value, it cannot include that value in this 1327 181. Thus, and for the exact reasons the 100 Trying including 1328 the Session Identifier value, only Alice's UUID is included in 1329 the remote-uuid component of the Session-ID header field value, 1330 with a null UUID present in the "local-uuid" component. 1332 9.9. Out-of-dialog REFER Transaction 1334 The following call-flow was extracted from Section 6.1 of [RFC5589] 1335 ("Successful Transfer"), with the only changes being the names of the 1336 UAs to maintain consistency within this document. 1338 Alice is the transferee 1339 Bob is the transferer 1340 and Carol is the transfer-target 1342 Session-ID Bob Alice Carol 1343 | | | 1344 {A,N} |<-----INVITE--------| | 1345 {B,A} |------200 OK------->| | 1346 {A,B} |<------ACK----------| | 1347 | | | 1348 {B,A} |--INVITE {hold}---->| | 1349 {A,B} |<-200 OK------------| | 1350 {B,A} |--- ACK ----------->| | 1351 | | | 1352 {B,A} |--REFER------------>|(Refer-To:Carol) | 1353 {A,B} |<-202 Accepted------| | 1354 | | | 1355 {A,B} || | 1357 | | | 1358 {A,N} | |--INVITE------------>| 1359 {C,A} | |<-200 OK-------------| 1360 {A,C} | |---ACK-------------->| 1361 | | | 1362 {A,B} |<--NOTIFY {200 OK}--| | 1363 {B,A} |---200 OK---------->| | 1364 | | | 1365 {B,A} |--BYE-------------->| | 1366 {A,B} |<-200 OK------------| | 1367 {C,A} | |<------------BYE-----| 1368 {A,C} | |-------------200 OK->| 1370 Figure 11: Out-Of-Dialog Call Transfer 1372 General operation of this example: 1374 o Just as in Section 9.2, Figure 2, Alice invites Bob to a 1375 session, and Bob eventually transfers Alice to communicate with 1376 Carol. 1378 o What is different about the call-flow in Figure 11 is that 1379 Bob's REFER is not in-dialog. Even so, this is treated as part 1380 of the same communication session and, thus, the Session 1381 Identifier in those messages is {A,B}. 1383 o Alice will use her existing UUID and the null UUID ({A,N}) in 1384 the INVITE towards Carol (who generates UUID "C" for this 1385 session), thus maintaining the common UUID within the Session 1386 Identifier for this new Alice-to-Carol session. 1388 10. Compatibility with a Previous Implementation 1390 There is a much earlier and proprietary document that specifies the 1391 use of a Session-ID header field (namely, [RFC7329]) that we will 1392 herewith attempt to achieve backwards compatibility. Neither 1393 Session-ID header field has any versioning information, so merely 1394 adding that this document describes "version 2" is insufficient. 1395 Here are the set of rules for compatibility between the two 1396 specifications. For the purposes of this discussion, we will label 1397 the proprietary specification of the Session-ID as the "old" version 1398 and this specification as the "new" version of the Session-ID. 1400 The previous (i.e., "old") version only has a single UUID value as a 1401 Session-ID header field value, but has a generic-parameter value that 1402 can be of use. 1404 In order to have an "old" version talk to an "old" version 1405 implementation, nothing needs to be done as far as the IETF is 1406 concerned. 1408 In order to have a "new" version talk to a "new" version 1409 implementation, both implementations need to follow this document (to 1410 the letter) and everything should be just fine. 1412 But that is where compatibility is not ensured, given the unknowns 1413 related to the behavior of entities implementing the pre-standard 1414 implementation. For this "new" implementation to work with the "old" 1415 implementation and an "old" implementation to work with "new" 1416 implementations, there needs to be a set of rules that all "new" 1417 implementations MUST follow. 1419 - Since no option tags or feature tags are to be used for 1420 distinguishing versions, the presence and order of any "remote- 1421 uuid" value within the Session-ID header field value is to be used 1422 to distinguish implementation versions. 1424 - If a SIP request has a "remote-uuid" value, this comes from a 1425 standard implementation, and not a pre-standard one. 1427 - If a SIP request has no "remote-uuid" value, this comes from a pre- 1428 standard implementation, and not a standard one. In this case, one 1429 UUID is used to identify this dialog, even if the responder is a 1430 standard implementation of this specification. 1432 - If a SIP response has a non-null "local-uuid" that is 32 octets 1433 long and differs from the endpoint's own UUID value, this response 1434 comes from a standard implementation. 1436 - If a SIP response has a non-null "local-uuid" that is not 32 octets 1437 long, this response comes from a misbehaving implementation, and 1438 its Session-ID header field MUST be discarded. That said, the 1439 response might still be valid according to the rules within SIP 1440 [RFC3261], and SHOULD be checked further. 1442 - If a SIP response arrives that has the same value of Session-ID 1443 UUIDs in the same order as was sent, this comes from a pre-standard 1444 implementation, and MUST NOT be discarded for not altering the null 1445 "remote-uuid". In this case, any new transaction within this 1446 dialog MUST preserve the order of the two UUIDs within all Session- 1447 ID header field, including the ACK, until this dialog is 1448 terminated. 1450 - If a SIP response only contains the "local-uuid" that was sent 1451 originally, this comes from a pre-standard implementation and MUST 1452 NOT be discarded for removing the null "remote-uuid". In this 1453 case, all future transactions within this dialog MUST contain only 1454 the UUID received in the first SIP response. Any new transaction 1455 starting a new dialog from the standard Session-ID implementation 1456 MUST include a "local-uuid" and a null "remote-uuid", even if that 1457 new dialog is between the same two UAs. 1459 - Standard implementations SHOULD NOT expect pre-standard 1460 implementations to be consistent in their implementation, even 1461 within the same dialog. For example, perhaps the first, third and 1462 tenth responses contain a "remote-uuid", but all the others do not. 1463 This behavior MUST be allowed by implementations of this 1464 specification. 1466 - The foregoing does not apply to other, presently unknown parameters 1467 that might be defined in the future. They are ignored for the 1468 purposes of interoperability with previous implementations. 1470 11. Security Considerations 1472 When creating a UUID value, UAs MUST ensure that there is no user or 1473 device-identifying information contained within the UUID. In 1474 particular, this means that a UUID MUST NOT be constructed using a 1475 MAC address on the host. 1477 The Session Identifier might be utilized for logging or 1478 troubleshooting, but MUST NOT be used for billing purposes. 1480 The Session Identifier could be misused to discover relationships 1481 between two or more parties. For example, suppose that Alice calls 1482 Bob and Bob, via his PBX, forwards or transfers the call to Carol. 1483 Without use of the Session Identifier, an unauthorized third party 1484 that is observing the communications between Alice and Bob might not 1485 know that Alice is actually communicating with Carol. If Alice, Bob, 1486 and Carol include the Session Identifier as a part of the signaling 1487 messages, it is possible for the third party to observe that the UA 1488 associated with Bob changed to some other UA. If the third party 1489 also has access to signaling messages between Bob and Carol, the 1490 third party can then discover that Alice is communicating with Carol. 1491 This would be true even if all other information relating to the 1492 session is changed by the PBX, including both signaling information 1493 and media address information. 1495 12. IANA Considerations 1497 12.1. Registration of the "Session-ID" Header Field 1499 The following is the registration for the 'Session-ID' header field 1500 to the "Header Name" registry at 1501 http://www.iana.org/assignments/sip-parameters: 1503 RFC number: RFC XXXX 1505 Header name: 'Session-ID' 1507 Compact form: none 1509 Note: This document replaces the "Session-ID" header originally 1510 registered via [RFC7329]. 1512 [RFC Editor: Please replace XXXX in this section and the next with 1513 the this RFC number of this document.] 1515 12.2. Registration of the "remote" Parameter 1517 The following parameter is to be added to the "Header Field 1518 Parameters and Parameter Values" section of the SIP parameter 1519 registry: 1521 +------------------+----------------+-------------------+-----------+ 1522 | Header Field | Parameter Name | Predefined Values | Reference | 1523 +------------------+----------------+-------------------+-----------+ 1524 | Session-ID | remote | No | [RFCXXXX] | 1525 +------------------+----------------+-------------------+-----------+ 1527 13. Acknowledgments 1529 The authors would like to thank Robert Sparks, Hadriel Kaplan, 1530 Christer Holmberg, Paul Kyzivat, Brett Tate, Keith Drage, Mary 1531 Barnes, Charles Eckel, Peter Dawes, Andrew Hutton, Arun Arunachalam, 1532 Adam Gensler, Roland Jesske, and Faisal Siyavudeen for their 1533 invaluable comments during the development of this document. 1535 14. Dedication 1537 This document is dedicated to the memory of James Polk, a long-time 1538 friend and colleague. James made important contributions to this 1539 specification, including being one of its primary editors. The IETF 1540 global community mourns his loss and he will be missed dearly. 1542 15. References 1544 15.1. Normative References 1546 [RFC3261] Rosenberg, J., et al., "SIP: Session Initiation 1547 Protocol", RFC 3261, June 2002. 1549 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1550 Requirement Levels", BCP 14, RFC 2119, March 1997. 1552 [RFC4122] Leach, P., Mealling, M., Salz, R., "A Universally Unique 1553 IDentifier (UUID) URN Namespace", RFC 4122, July 2005. 1555 [RFC5234] Crocker, D., Overell, P, "Augmented BNF for Syntax 1556 Specifications: ABNF", RFC 5234, January 2008. 1558 [RFC4579] Johnston, A., Levin, O., "Session Initiation Protocol 1559 (SIP) Call Control - Conferencing for User Agents", RFC 1560 4579, August 2006. 1562 [RFC3891] Mahy, R., Biggs, B., Dean, R., 'The Session Initiation 1563 Protocol (SIP) "Replaces" Header', RFC 3891, September 1564 2004. 1566 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1567 Method", RFC 3515, April 2003. 1569 [RFC7329] Kaplan, H., "A Session Identifier for the Session 1570 Initiation Protocol (SIP)", RFC 7329, August 2014. 1572 15.2. Informative References 1574 [H.323] Recommendation ITU-T H.323, "Packet-based multimedia 1575 communications systems", December 2009. 1577 [RFC3550] Schulzrinne, H., et al., "RTP: A Transport Protocol for 1578 Real-Time Applications", RFC 3550, July 2003. 1580 [RFC7206] Jones, et al., "Requirements for an End-to-End Session 1581 Identification in IP-Based Multimedia Communication 1582 Networks", RFC 7206, May 2014. 1584 [RFC5359] Johnston, A., et al., "Session Initiation Protocol 1585 Service Examples", RFC 5359, October 2008. 1587 [RFC5589] Sparks, R., Johnston, A., and D. Petrie, "Session 1588 Initiation Protocol (SIP) Call Control - Transfer", RFC 1589 5589, June 2009. 1591 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E. and J. 1592 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1593 March 1999. 1595 [H.460.27] Recommendation ITU-T H.460.27, "End-to-End Session 1596 Identifier in for H.323 Systems", Work in Progress {RFC 1597 Editor: A month and year should be available when the RFC 1598 is published}. 1600 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 1601 Camarillo, "Best Current Practices for Third Party Call 1602 Control (3pcc) in the Session Initiation Protocol (SIP)", 1603 RFC 3725, April 2004. 1605 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1606 Session Initiation Protocol (SIP)", RFC 4353, February 1607 2006. 1609 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 1610 Initiation Protocol (SIP) Back-to-Back User Agents", RFC 1611 7092, December 2013. 1613 Authors' Addresses 1615 Paul E. Jones 1616 Cisco Systems, Inc. 1617 7025 Kit Creek Rd. 1618 Research Triangle Park, NC 27709 1619 USA 1621 Phone: +1 919 476 2048 1622 Email: paulej@packetizer.com 1623 IM: xmpp:paulej@packetizer.com 1625 Gonzalo Salgueiro 1626 Cisco Systems, Inc. 1627 7025 Kit Creek Rd. 1628 Research Triangle Park, NC 27709 1629 USA 1631 Phone: +1 919 392 3266 1632 Email: gsalguei@cisco.com 1633 IM: xmpp:gsalguei@cisco.com 1635 Chris Pearce 1636 Cisco Systems, Inc. 1637 2300 East President George Bush Highway 1638 Richardson, TX 75082 1639 USA 1641 Phone: +1 972 813 5123 1642 Email: chrep@cisco.com 1643 IM: xmpp:chrep@cisco.com