idnits 2.17.1 draft-ietf-insipid-session-id-18.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 (February 22, 2016) is 2985 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 293, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 1555, 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 Obsoletes: 7329 (if approved) C. Pearce 5 Intended status: Standards Track P. Giralt 6 Expires: August 25, 2016 Cisco Systems, Inc. 7 February 22, 2016 9 End-to-End Session Identification in IP-Based Multimedia Communication 10 Networks 11 draft-ietf-insipid-session-id-18 13 Abstract 15 This document describes an end-to-end Session Identifier for use in 16 IP-based multimedia communication systems that enables endpoints, 17 intermediary devices, and management systems to identify a session 18 end-to-end, associate multiple endpoints with a given multipoint 19 conference, track communication sessions when they are redirected, 20 and associate one or more media flows with a given communication 21 session. 23 This document also describes a backwards compatibility mechanism for 24 an existing session identifier implementation (RFC 7329) that is 25 sufficiently different from the procedures defined in this document. 27 This document obsoletes RFC 7329. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 25, 2016. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions used in this document . . . . . . . . . . . . . . 3 65 3. Session Identifier Requirements and Use Cases . . . . . . . . 4 66 4. Constructing and Conveying the Session Identifier . . . . . . 4 67 4.1. Constructing the Session Identifier . . . . . . . . . . . 4 68 4.2. Conveying the Session Identifier . . . . . . . . . . . . 5 69 5. The Session-ID Header Field . . . . . . . . . . . . . . . . . 6 70 6. Endpoint Behavior . . . . . . . . . . . . . . . . . . . . . . 8 71 7. Processing by Intermediaries . . . . . . . . . . . . . . . . 9 72 8. Handling of Remote UUID Changes . . . . . . . . . . . . . . . 12 73 9. Associating Endpoints in a Multipoint Conference . . . . . . 13 74 10. Examples of Various Call Flow Operations . . . . . . . . . . 14 75 10.1. Basic Call with 2 UUIDs . . . . . . . . . . . . . . . . 14 76 10.2. Basic Call Transfer using REFER . . . . . . . . . . . . 18 77 10.3. Basic Call Transfer using re-INVITE . . . . . . . . . . 19 78 10.4. Single Focus Conferencing . . . . . . . . . . . . . . . 21 79 10.5. Single Focus Conferencing using WebEx . . . . . . . . . 23 80 10.6. Cascading Conference Bridges . . . . . . . . . . . . . . 25 81 10.6.1. Establishing a Cascaded Conference . . . . . . . . . 25 82 10.6.2. Calling into Cascaded Conference Bridges . . . . . . 26 83 10.7. Basic 3PCC for two UAs . . . . . . . . . . . . . . . . . 27 84 10.8. Handling in 100 Trying SIP Response and CANCEL Request . 28 85 10.8.1. Handling in a 100 Trying SIP Response . . . . . . . 28 86 10.8.2. Handling a CANCEL SIP Request . . . . . . . . . . . 30 87 10.9. Out-of-dialog REFER Transaction . . . . . . . . . . . . 31 88 11. Compatibility with a Previous Implementation . . . . . . . . 32 89 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34 90 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 91 13.1. Registration of the "Session-ID" Header Field . . . . . 34 92 13.2. Registration of the "remote" Parameter . . . . . . . . . 35 93 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 94 15. Dedication . . . . . . . . . . . . . . . . . . . . . . . . . 35 95 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 96 16.1. Normative References . . . . . . . . . . . . . . . . . . 35 97 16.2. Informative References . . . . . . . . . . . . . . . . . 36 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 100 1. Introduction 102 IP-based multimedia communication systems like SIP [RFC3261] and 103 [H.323] have the concept of a "call identifier" that is globally 104 unique. The identifier is intended to represent an end-to-end 105 communication session from the originating device to the terminating 106 device. Such an identifier is useful for troubleshooting, session 107 tracking, and so forth. 109 For several reasons, however, the current call identifiers defined in 110 SIP and H.323 are not suitable for end-to-end session identification. 111 A fundamental issue in protocol interworking is the fact that the 112 syntax for the call identifier in SIP and H.323 is different. Thus, 113 if both protocols are used in a call, it is impossible to exchange 114 the call identifier end-to-end. 116 Another reason why the current call identifiers are not suitable to 117 identify a session end-to-end is that, in real-world deployments, 118 devices like session border controllers [RFC7092] often change the 119 session signaling, including the value of the call identifier, as it 120 passes through the device. While this is deliberate and useful, it 121 makes it very difficult to track a session end-to-end. 123 This document defines a new identifier for SIP referred to as the 124 Session Identifier that is intended to overcome the issues that exist 125 with the currently defined call identifiers used in SIP. The 126 procedures specified in this document attempt to comply with the 127 requirements specified in [RFC7206]. The procedures also specify 128 capabilities not mentioned in [RFC7206], shown in call flows in 129 section 10. Additionally, the specification attempts to account for 130 a previous, proprietary version of a SIP Session Identifier header 131 [RFC7329], specifying a backwards compatibility approach in section 132 11. 134 2. Conventions used in this document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119] when they 139 appear in ALL CAPS. These words may also appear in this document in 140 lower case as plain English words, absent their normative meanings. 142 The term "Session Identifier" refers to the value of the identifier, 143 whereas "Session-ID" refers to the header field used to convey the 144 identifier. The Session Identifier is a set of two Universally 145 Unique Identifiers (UUIDs) and each element of that set is simply 146 referred to herein as a UUID. 148 Throughout this document, the term "endpoint" refers to a SIP User 149 Agent (UA) that either initiates or terminates a SIP session, such as 150 a user's mobile phone or a conference server, but excludes entities 151 like B2BUAs that are generally located along the call signaling path 152 between endpoints. The term "intermediary" refers to any SIP entity 153 along the call signaling path between the aforementioned endpoints, 154 including Back-to-Back User Agents (B2BUAs) and SIP proxies. 156 3. Session Identifier Requirements and Use Cases 158 Requirements and use cases for the end-to-end Session Identifier, 159 along with a definition of "session identifier" and "communication 160 session", can be found in [RFC7206]. 162 As mentioned in section 6.1 of [RFC7206], the ITU-T undertook a 163 parallel effort to define compatible procedures for an H.323 Session 164 Identifier. They are documented in [H.460.27]. 166 4. Constructing and Conveying the Session Identifier 168 4.1. Constructing the Session Identifier 170 The Session Identifier comprises two UUIDs [RFC4122], with each UUID 171 representing one of the endpoints participating in the session. 173 The version number in the UUID indicates the manner in which the UUID 174 is generated, such as using random values or using the MAC address of 175 the endpoint. To satisfy the requirement that no user or device 176 information be conveyed, endpoints SHOULD generate version 4 (random) 177 or version 5 (SHA-1) UUIDs to address privacy concerns related to use 178 of MAC addresses in UUIDs. 180 When generating a version 5 UUID, endpoints or intermediaries MUST 181 utilize the procedures defined in Section 4.3 of [RFC4122] and employ 182 the following "name space ID": 184 uuid_t NameSpace_SessionID = { 185 /* a58587da-c93d-11e2-ae90-f4ea67801e29 */ 186 0xa58587da, 187 0xc93d, 188 0x11e2, 189 0xae, 0x90, 0xf4, 0xea, 0x67, 0x80, 0x1e, 0x29 190 } 192 Further, the "name" to utilize for version 5 UUIDs is the 193 concatenation of the Call-ID header-value and the "tag" parameter 194 that appears on the "From" or "To" line associated with the device 195 for which the UUID is created. Once an endpoint generates a UUID for 196 a session, the UUID never changes, even if values originally used as 197 input into its construction change over time. 199 Stateless intermediaries that insert a Session-ID header field into a 200 SIP message on behalf of an endpoint MUST utilize version 5 UUIDs to 201 ensure that UUIDs for the communication session are consistently 202 generated. If a stateless intermediary does not know the tag value 203 for the endpoint (e.g., a new INVITE without a To: tag value or an 204 older SIP implementation [RFC2543] that did not include a tag 205 parameter), the intermediary MUST NOT attempt to generate a UUID for 206 that endpoint. Note that if an intermediary is stateless and the 207 endpoint on one end of the call is replaced with another endpoint due 208 to some service interaction, the values used to create the UUID 209 should change and, if so, the intermediary will compute a different 210 UUID. 212 4.2. Conveying the Session Identifier 214 The SIP User Agent (UA) initially transmitting the SIP request 215 ("Alice"), i.e., a User Agent Client (UAC), will create a UUID and 216 transmit that to the ultimate destination UA ("Bob"). Likewise, the 217 destination UA ("Bob"), i.e., a User Agent Server (UAS), will create 218 a UUID and transmit that to the first UA ("Alice"). These two 219 distinct UUIDs form what is referred to as the Session Identifier and 220 is represented in this document in set notation of the form {A,B}, 221 where "A" is UUID value created by UA "Alice" and "B" is the UUID 222 value created by UA "Bob". The Session Identifier {A,B} is equal to 223 the Session Identifier {B,A}. 225 In the case where only one UUID is known, such as when a UA first 226 initiates a SIP request, the Session Identifier would be {A,N}, where 227 "A" represents the UUID value transmitted by the UA "Alice" and "N" 228 is what is referred to as the null UUID (see section 5). 230 Since SIP sessions are subject to any number of service interactions, 231 SIP INVITE messages might be forked as sessions are established, and 232 since conferences might be established or expanded with endpoints 233 calling in or the conference focus calling out, the construction of 234 the Session Identifier as a set of UUIDs is important. 236 To understand this better, consider that an endpoint participating in 237 a communication session might be replaced with another, such as the 238 case where two "legs" of a call are joined together by a PBX. 239 Suppose "Alice" and "Bob" both call UA C ("Carol"). There would be 240 two distinctly identifiable Session Identifiers, namely {A,C} and 241 {B,C}. Then suppose that "Carol" uses a local PBX function to join 242 the call between herself and "Alice" with the call between herself 243 and "Bob", resulting in a single remaining call between "Alice" and 244 "Bob". This merged call can be identified using two UUID values 245 assigned by each entity in the communication session, namely {A,B} in 246 this example. 248 In the case of forking, "Alice" might send an INVITE that gets forked 249 to several different endpoints. A means of identifying each of these 250 separate communication sessions is needed and, since each of the 251 destination UAs will create its own UUID, each communication session 252 would be uniquely identified by the values {A, B1}, {A, B2}, {A, B3}, 253 and so on, where each of the Bn values refers to the UUID created by 254 the different UAs to which the SIP session is forked. 256 For conferencing scenarios, it is also useful to have a two-part 257 Session Identifier where the conference focus specifies the same UUID 258 for each conference participant. This allows for correlation among 259 the participants in a single conference. For example, in a 260 conference with three participants, the Session Identifiers might be 261 {A,M}, {B,M}, and {C,M}, where "M" is assigned by the conference 262 focus. Only a conference focus will purposely utilize the same UUID 263 for more than one SIP session and, even then, such reuse MUST be 264 restricted to the participants in the same conference. 266 How a device acting on Session Identifiers stores, processes, or 267 utilizes the Session Identifier is outside the scope of this 268 document. 270 5. The Session-ID Header Field 272 The syntax specified here replaces the Session-ID header field syntax 273 defined in [RFC7329]. 275 Each endpoint participating in a communication session has a 276 distinct, preferably locally-generated, UUID associated with it. The 277 endpoint's UUID value remains unchanged throughout the duration of 278 the communication session. An intermediary MAY generate a UUID on 279 behalf of an endpoint that did not include a UUID of its own. 281 The UUID values for each endpoint are inserted into the "Session-ID" 282 header field of all transmitted SIP messages. The Session-ID header 283 field has the following ABNF [RFC5234] syntax: 285 session-id = "Session-ID" HCOLON session-id-value 287 session-id-value = local-uuid *(SEMI sess-id-param) 289 local-uuid = sess-uuid / null 291 remote-uuid = sess-uuid / null 293 sess-uuid = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] 295 sess-id-param = remote-param / generic-param 297 remote-param = "remote" EQUAL remote-uuid 299 null = 32("0") 301 The productions "SEMI", "EQUAL", and "generic-param" are defined in 302 [RFC3261]. The production DIGIT is defined in [RFC5234]. 304 The Session-ID header field MUST NOT have more than one "remote" 305 parameter. In the case where an entity compliant with this 306 specification is interworking with an entity that implemented 307 [RFC7329], the "remote" parameter may be absent, but otherwise the 308 remote parameter MUST be present. The details under which those 309 conditions apply are described in Section 11. Except for backwards 310 compatibility with [RFC7329], the "remote" parameter MUST be present. 312 A special null UUID value composed of 32 zeros is required in certain 313 situations. A null UUID is expected as the "remote-uuid" of every 314 initial standard SIP request since the initiating endpoint would not 315 initially know the UUID value of the remote endpoint. This null 316 value will get replaced by the ultimate destination UAS when that UAS 317 generates a response message. One caveat is explained in Section 11 318 for a possible backwards compatibility case. A null UUID value is 319 also returned by some intermediary devices that send provisional or 320 other responses as the "local-uuid" component of the Session-ID 321 header field value, as described in Section 7. 323 The "local-uuid" in the Session-ID header field represents the UUID 324 value of the endpoint transmitting a message and the "remote-uuid" in 325 the Session-ID header field represents the UUID of the endpoint's 326 peer. For example, a Session-ID header field might appear like this: 328 Session-ID: ab30317f1a784dc48ff824d0d3715d86; 329 remote=47755a9de7794ba387653f2099600ef2 331 While this is the general form of the Session-ID header field, 332 exceptions to syntax and procedures are detailed in subsequent 333 sections. 335 The UUID values are presented as strings of lower-case hexadecimal 336 characters, with the most significant octet of the UUID appearing 337 first. 339 The Session-ID header field value is technically case-INSENSITIVE, 340 but only lowercase characters are allowed in the sess-uuid 341 components. Receiving entities MUST treat sess-uuid components as 342 case-insensitive and not produce an error if an uppercase hexadecimal 343 character is received. 345 6. Endpoint Behavior 347 To comply with this specification, endpoints (non-intermediaries) 348 MUST include a Session-ID header field value in all SIP messages 349 transmitted as a part of a communication session. The locally- 350 generated UUID of the transmitter of the message MUST appear in the 351 "local-uuid" portion of the Session-ID header field value. The UUID 352 of the peer device, if known, MUST appear as the "remote" parameter 353 following the transmitter's UUID. The null UUID value MUST be used 354 if the peer device's UUID is not known. 356 Once an endpoint allocates a UUID value for a communication session, 357 the endpoint MUST NOT change that UUID value for the duration of the 358 session, including when 360 o communication attempts are retried due to receipt of 4xx messages 361 or request timeouts; 363 o the session is redirected in response to a 3xx message; 365 o a session is transferred via a REFER message [RFC3515]; or 367 o a SIP dialog is replaced via an INVITE with Replaces [RFC3891]. 369 An endpoint that receives a Session-ID header field MUST take note of 370 any non-null "local-uuid" value that it receives and assume that is 371 the UUID of the peer endpoint within that communications session. 372 Endpoints MUST include this received UUID value as the "remote" 373 parameter when transmitting subsequent messages, making sure not to 374 change this UUID value in the process of moving the value internally 375 from the "local-uuid" field to the "remote-uuid" field. 377 If an endpoint receives a 3xx message, receives a REFER that directs 378 the endpoint to a different peer, or receives an INVITE with Replaces 379 that also potentially results in communicating with a new peer, the 380 endpoint MUST complete any message exchanges with its current peer 381 using the existing Session Identifier, but MUST NOT use the current 382 peer's UUID value when sending the first message to what it believes 383 may be a new peer endpoint (even if the exchange results in 384 communicating with the same physical or logical entity). The 385 endpoint MUST retain its own UUID value, however, as described above. 387 It should be noted that messages received by an endpoint might 388 contain a "local-uuid" value that does not match what the endpoint 389 expected its peer's UUID to be. It is also possible for an endpoint 390 to receive a "remote-uuid" value that does not match its generated 391 UUID for the session. Either might happen as a result of service 392 interactions by intermediaries and MUST NOT negatively affect the 393 communication session. However, the endpoint may log this event for 394 the purposes of troubleshooting. 396 An endpoint MUST assume that the UUID value of the peer endpoint MAY 397 change at any time due to service interactions. Section 8 discusses 398 how endpoints must handle remote UUID changes. 400 It is also important to note that if an intermediary in the network 401 forks a session, the endpoint initiating a session may receive 402 multiple responses back from different endpoints, each of which 403 contains a different UUID ("local-uuid") value. Endpoints MUST take 404 care to ensure that the correct UUID value is returned in the 405 "remote" parameter when interacting with each endpoint. The one 406 exception is when the endpoint sends a CANCEL message, in which case 407 the Session-ID header field value MUST be identical to the Session-ID 408 header field value sent in the original INVITE. 410 If an endpoint receives a message that does not contain a Session-ID 411 header field, that message MUST have no effect on what the endpoint 412 believes is the UUID value of the remote endpoint. That is, the 413 endpoint MUST NOT change the internally maintained "remote-uuid" 414 value for the peer. 416 A Multipoint Control Unit (MCU) is a special type of conferencing 417 endpoint and is discussed in Section 9. 419 7. Processing by Intermediaries 421 The following applies only to an intermediary that wishes to comply 422 with this specification and does not impose a conformance requirement 423 on intermediaries that elect to not provide any special treatment for 424 the Session-ID header field. 426 The Call-ID often reveals personal, device, domain or other sensitive 427 information associated with a user, which is why intermediaries, such 428 as session border controllers, sometimes alter the Call-ID. In order 429 to ensure the integrity of the end-to-end Session Identifier, it is 430 constructed in a way which does not reveal such information, removing 431 the need for intermediaries to alter it. 433 When an intermediary receives messages from one endpoint in a 434 communication session that causes the transmission of one or more 435 messages toward the second endpoint in a communication session, the 436 intermediary MUST include the Session-ID header field in the 437 transmitted messages with the same UUID values found in the received 438 message, except as outlined in this section. 440 If the intermediary aggregates several responses from different 441 endpoints, as described in Section 16.7 of [RFC3261], the 442 intermediary MUST set the local-uuid field to the null UUID value 443 when forwarding the aggregated response to the endpoint since the 444 true UUID value of the peer is undetermined at that point. 446 Intermediary devices that transfer a call, such as by joining 447 together two different "call legs", MUST properly construct a 448 Session-ID header field that contains the UUID values associated with 449 the endpoints involved in the joined session and correct placement of 450 those values. As described in Section 6, the endpoint receiving a 451 message transmitted by the intermediary will assume that the first 452 UUID value belongs to its peer endpoint. 454 If an intermediary receives a SIP message from an endpoint without a 455 Session-ID header field or valid header field value, the intermediary 456 MAY assign a "local-uuid" value to represent that endpoint and, 457 having done so, MUST insert that assigned value into all signaling 458 messages on behalf of the endpoint for that dialog. In effect, the 459 intermediary becomes dialog stateful and it MUST follow the endpoint 460 procedures in Section 6 with respect to Session-ID header field value 461 treatment with itself acting as the endpoint (for the purposes of the 462 Session-ID header field) for which it inserted a component into the 463 Session-ID header field value. If the intermediary is aware of the 464 UUID value that identifies the endpoint to which a message is 465 directed, it MUST insert that UUID value into the Session-ID header 466 field value as the "remote-uuid" value. If the intermediary is 467 unaware of the UUID value that identifies the receiving endpoint, it 468 MUST use the null UUID value as the "remote-uuid" value. 470 When an intermediary originates a response, such as a provisional 471 response or a response to a CANCEL request, the "remote-uuid" field 472 will contain the UUID value of the receiving endpoint. When the UUID 473 of the peer endpoint is known, the intermediary MUST insert the UUID 474 of the peer endpoint in the "local-uuid" field of the header value. 475 Otherwise, the intermediary MAY set the "local-uuid" field of the 476 header value to the "null" UUID value. 478 When an intermediary originates a request message without first 479 having received a SIP message that triggered the transmission of the 480 message (e.g., sending a BYE message to terminate a call for policy 481 reasons), the intermediary MUST, if it has knowledge of the UUID 482 values for the two communicating endpoints, insert a Session-ID 483 header field with the "remote-uuid" field of the header value set to 484 the UUID value of the receiving endpoint and the "local-uuid" field 485 of the header value set to the UUID value of the other endpoint. 486 When the intermediary does not have knowledge of the UUID value of an 487 endpoint in the communication session, the intermediary SHOULD set 488 the unknown UUID value(s) to the "null" UUID value. (If both are 489 unknown, the Session-ID header value SHOULD NOT be included at all, 490 since it would have no practical value.) 492 With respect to the previous two paragraphs, note that if an 493 intermediary transmits a "null" UUID value, the receiving endpoint 494 might use that value in subsequent messages it sends. This 495 effectively violates the requirement of maintaining an end-to-end 496 Session Identifier value for the communication session if a UUID for 497 the peer endpoint had been previously conveyed. Therefore, an 498 intermediary MUST only send the "null" UUID when the intermediary has 499 not communicated with the peer endpoint to learn its UUID. This 500 means that intermediaries SHOULD maintain state related to the UUID 501 values for both ends of a communication session if it intends to 502 originate messages (versus merely conveying messages). An 503 intermediary that does not maintain this state and that originates a 504 message as described in the previous two paragraphs MUST NOT insert a 505 Session-ID header field in order to avoid unintended, incorrect 506 reassignment of a UUID value. 508 The Session-ID header field value included in a CANCEL request MUST 509 be identical to the Session-ID header field value included in the 510 corresponding INVITE. 512 If a SIP intermediary initiates a dialog between two endpoints in a 513 3PCC [RFC3725] scenario, the SIP request in the initial INVITE will 514 have a non-null, locally-frabricated "local-uuid" value; call this 515 temporary UUID X. The request will still have a null "remote-uuid" 516 value; call this value N. The SIP server MUST be transaction 517 stateful. The UUID pair in the INVITE will be {X,N}. A non- 518 redirected or rejected response will have a UUID pair {A,X}. This 519 transaction stateful, dialog initiating SIP server MUST replace its 520 own UUID, i.e., X, with a null UUID (i.e., {A,N}) as expected by 521 other UAS (see Section 10.7 for an example). 523 Intermediaries that manipulate messages containing a Session-ID 524 header field SHOULD be aware of what UUID values it last sent towards 525 an endpoint and, following any kind of service interaction initiated 526 or affected by the intermediary, of what UUID values the receiving 527 endpoint should have knowledge to ensure that both endpoints in the 528 session have the correct and same UUID values. If an intermediary 529 can determine that an endpoint might not have received a current, 530 correct Session-ID field, the Intermediary SHOULD attempt to provide 531 the correct Session-ID header field to the endpoint such as by 532 sending a re-INVITE message. 534 An intermediary MUST assume that the UUID value of session peers MAY 535 change at any time due to service interactions and MAY itself change 536 UUID values for sessions under its control to ensure end to end 537 session identifiers are consistent for all participants in a session. 538 Section 8 discusses how intermediaries must handle remote UUID 539 changes. 541 8. Handling of Remote UUID Changes 543 Both endpoints and intermediaries MUST assume that the UUID value of 544 the session peer MAY change at any time due to service interactions. 545 To ensure that all endpoints and intermediaries involved in a session 546 agree upon the current session identifier, the new UUID MUST be 547 accepted as the peer's UUID under the following conditions: 549 o When an endpoint or intermediary receives a mid-dialog request 550 containing a new UUID from a peer, all responses to that request 551 MUST contain the new UUID value as the "remote" parameter unless a 552 subsequent successful transaction (for example, an UPDATE) 553 contains a different UUID, in which case the newest UUID MUST be 554 used. 556 o If an endpoint or intermediary sends a successful (2xx) or 557 redirection (3xx) response to the request containing the new UUID 558 value, the endpoint or intermediary MUST accept the peer's UUID 559 and include this new UUID as the "remote" parameter for any 560 subsequent messages unless the UUID from a subsequent transaction 561 has already been accepted. 563 o If the endpoint or intermediary sends a failure (4xx, 5xx, 6xx) 564 response, it MUST NOT accept the new UUID value and any subsequent 565 messages MUST contain the previously stored UUID value in the 566 "remote" parameter for any subsequent message. Note that the 567 failure response itself will contain the latest UUID value in the 568 "remote" parameter. 570 o The ACK method is a special case as there is no response. When an 571 endpoint or intermediary receives an ACK for a successful(2xx) or 572 redirection (3xx) response with a new UUID value, it MUST accept 573 the peer's new UUID value and include this new UUID as the 574 "remote" parameter for any subsequent messages. If the ACK is for 575 a failure (4xx, 5xx, 6xx) response, the new value MUST NOT be 576 used. 578 o When an endpoint or intermediary receives a response containing a 579 new UUID from a peer, the endpoint or intermediary MUST accept the 580 new UUID as the peer's UUID and include this new UUID as the 581 "remote" parameter for any subsequent messages. 583 9. Associating Endpoints in a Multipoint Conference 585 Multipoint Control Units (MCUs) group two or more sessions into a 586 single multipoint conference and have a conference Focus responsible 587 for maintaining the dialogs connected to it [RFC4353]. MCUs, 588 including cascaded MCUs, MUST utilize the same UUID value ("local- 589 uuid" portion of the Session-ID header field value) with all 590 participants in the conference. In so doing, each individual session 591 in the conference will have a unique Session Identifier (since each 592 endpoint will create a unique UUID of its own), but will also have 593 one UUID in common with all other participants in the conference. 595 When creating a cascaded conference, an MCU MUST convey the UUID 596 value to utilize for a conference via the "local-uuid" portion of the 597 Session-ID header field value in an INVITE to a second MCU when using 598 SIP to establish the cascaded conference. A conference bridge, or 599 MCU, needs a way to identify itself when contacting another MCU. 600 [RFC4579] defines the "isfocus" Contact header field value parameter 601 just for this purpose. The initial MCU MUST include the UUID of that 602 particular conference in the "local-uuid" of an INVITE to the other 603 MCU(s) participating in that conference. Also included in this 604 INVITE is an "isfocus" Contact header field value parameter 605 identifying that this INVITE is coming from an MCU and that this UUID 606 is to be given out in all responses from endpoints into those MCUs 607 participating in this same conference. This ensures a single UUID is 608 common across all participating MCUs of the same conference, but is 609 unique between different conferences. 611 Intermediary devices or network diagnostics equipment might assume 612 that when they see two or more sessions with different Session 613 Identifiers, but with one UUID in common, that the sessions are part 614 of the same conference. However, the assumption that two sessions 615 having one common UUID being part of the same conference is not 616 always correct. In a SIP forking scenario, for example, there might 617 also be what appears to be multiple sessions with a shared UUID 618 value; this is intended. The desire is to allow for the association 619 of related sessions, regardless of whether a session is forked or 620 part of a conference. 622 10. Examples of Various Call Flow Operations 624 Seeing something frequently makes understanding easier. With that in 625 mind, this section includes several call flow examples with the 626 initial UUID and the complete Session Identifier indicated per 627 message, as well as when the Session Identifier changes according to 628 the rules within this document during certain operations/functions. 630 This section is for illustrative purposes only and is non-normative. 631 In the following flows, RTP refers to the Real-time Transport 632 Protocol [RFC3550]. 634 In the examples in this section, "N" represents a null UUID and other 635 letters represents the unique UUID values corresponding to endpoints 636 or MCUs. 638 10.1. Basic Call with 2 UUIDs 640 Session-ID 641 --- Alice B2BUA Bob Carol 642 {A,N} |---INVITE F1--->| | 643 {A,N} | |---INVITE F2--->| 644 {B,A} | |<---200 OK F3---| 645 {B,A} |<---200 OK F4---| | 646 {A,B} |-----ACK F5---->| | 647 {A,B} | |-----ACK F6---->| 648 |<==============RTP==============>| 650 Figure 1: Session-ID Creation when Alice calls Bob 652 General operation of this example: 654 o UA-Alice populates the "local-uuid" portion of the Session-ID 655 header field value. 657 o UA-Alice sends its UUID in the SIP INVITE, and populates the 658 "remote" parameter with a null value (32 zeros). 660 o B2BUA receives an INVITE with both a "local-uuid" portion of the 661 Session-ID header field value from UA-Alice as well as the null 662 "remote-uuid" value, and transmits the INVITE towards UA-Bob with 663 an unchanged Session-ID header field value. 665 o UA-Bob receives Session-ID and generates its "local-uuid" portion 666 of the Session-ID header field value UUID to construct the whole/ 667 complete Session-ID header field value, at the same time 668 transferring Alice's UUID unchanged to the "remote-uuid" portion 669 of the Session-ID header field value in the 200 OK SIP response. 671 o B2BUA receives the 200 OK response with a complete Session-ID 672 header field value from UA-Bob, and transmits 200 OK towards UA- 673 Alice with an unchanged Session-ID header field value. 675 o UA-Alice, upon reception of the 200 OK from the B2BUA, transmits 676 the ACK towards the B2BUA. The construction of the Session-ID 677 header field in this ACK is that of Alice's UUID is the "local- 678 uuid", and Bob's UUID populates the "remote-uuid" portion of the 679 header-value. 681 o B2BUA receives the ACK with a complete Session-ID header field 682 from UA-Alice, and transmits ACK towards UA-Bob with an unchanged 683 Session-ID header field value. 685 Below is a complete SIP message exchange illustrating proper use of 686 the Session-ID header field. For the sake of brevity, non-essential 687 headers and message bodies are omitted. 689 F1 INVITE Alice -> B2BUA 691 INVITE sip:bob@biloxi.com SIP/2.0 692 Via: SIP/2.0/UDP pc33.atlanta.example.com 693 ;branch=z9hG4bK776asdhds 694 Max-Forwards: 70 695 To: Bob 696 From: Alice ;tag=1928301774 697 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 698 Session-ID: ab30317f1a784dc48ff824d0d3715d86 699 ;remote=00000000000000000000000000000000 700 CSeq: 314159 INVITE 701 Contact: 702 Content-Type: application/sdp 703 Content-Length: 142 705 (Alice's SDP not shown) 707 F2 INVITE B2BUA -> Bob 709 INVITE sip:bob@192.168.10.20 SIP/2.0 710 Via: SIP/2.0/UDP server10.biloxi.example.com 711 ;branch=z9hG4bK4b43c2ff8.1 712 Via: SIP/2.0/UDP pc33.atlanta.example.com 713 ;branch=z9hG4bK776asdhds;received=10.1.3.33 714 Max-Forwards: 69 715 To: Bob 716 From: Alice ;tag=1928301774 717 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 718 Session-ID: ab30317f1a784dc48ff824d0d3715d86 719 ;remote=00000000000000000000000000000000 720 CSeq: 314159 INVITE 721 Contact: 722 Record-Route: 723 Content-Type: application/sdp 724 Content-Length: 142 726 (Alice's SDP not shown) 728 F3 200 OK Bob -> B2BUA 730 SIP/2.0 200 OK 731 Via: SIP/2.0/UDP server10.biloxi.example.com 732 ;branch=z9hG4bK4b43c2ff8.1;received=192.168.10.1 733 Via: SIP/2.0/UDP pc33.atlanta.example.com 734 ;branch=z9hG4bK776asdhds;received=10.1.3.33 735 To: Bob ;tag=a6c85cf 736 From: Alice ;tag=1928301774 737 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 738 Session-ID: 47755a9de7794ba387653f2099600ef2 739 ;remote=ab30317f1a784dc48ff824d0d3715d86 740 CSeq: 314159 INVITE 741 Contact: 742 Record-Route: 743 Content-Type: application/sdp 744 Content-Length: 131 746 (Bob's SDP not shown) 748 F4 200 OK B2BUA -> Alice 750 SIP/2.0 200 OK 751 Via: SIP/2.0/UDP pc33.atlanta.example.com 752 ;branch=z9hG4bK776asdhds;received=10.1.3.33 753 To: Bob ;tag=a6c85cf 754 From: Alice ;tag=1928301774 755 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 756 Session-ID: 47755a9de7794ba387653f2099600ef2 757 ;remote=ab30317f1a784dc48ff824d0d3715d86 758 CSeq: 314159 INVITE 759 Contact: 760 Record-Route: 761 Content-Type: application/sdp 762 Content-Length: 131 764 (Bob's SDP not shown) 766 F5 ACK Alice -> B2BUA 768 ACK sip:bob@192.168.10.20 SIP/2.0 769 Via: SIP/2.0/UDP pc33.atlanta.example.com 770 ;branch=z9hG4bKnashds8 771 Route: 772 Max-Forwards: 70 773 To: Bob ;tag=a6c85cf 774 From: Alice ;tag=1928301774 775 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 776 Session-ID: ab30317f1a784dc48ff824d0d3715d86 777 ;remote=47755a9de7794ba387653f2099600ef2 778 CSeq: 314159 ACK 779 Content-Length: 0 781 F6 ACK B2BUA -> Bob 783 ACK sip:bob@192.168.10.20 SIP/2.0 784 Via: SIP/2.0/UDP server10.biloxi.example.com 785 ;branch=z9hG4bK4b43c2ff8.2 786 Via: SIP/2.0/UDP pc33.atlanta.example.com 787 ;branch=z9hG4bKnashds8;received=10.1.3.33 788 Max-Forwards: 70 789 To: Bob ;tag=a6c85cf 790 From: Alice ;tag=1928301774 791 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 792 Session-ID: ab30317f1a784dc48ff824d0d3715d86 793 ;remote=47755a9de7794ba387653f2099600ef2 794 CSeq: 314159 ACK 795 Content-Length: 0 797 The remaining examples in this Section do not display the complete 798 SIP message exchange. Instead, they simply use the set notation 799 described in Section 4.2 to show the Session Identifier exchange 800 throughout the particular call flow being illustrated. 802 10.2. Basic Call Transfer using REFER 804 From the example built within Section 10.1, we proceed to this 'Basic 805 Call Transfer using REFER' example. Note that this is a mid-dialog 806 REFER in contrast with the out-of-dialog REFER in Section 10.9. 808 Session-ID 809 --- Alice B2BUA Bob Carol 810 | | | | 811 |<==============RTP==============>| | 812 {B,A} | |<---re-INVITE---| | 813 {B,A} |<---re-INVITE---| (puts Alice on Hold) | 814 {A,B} |-----200 OK---->| | | 815 {A,B} | |-----200 OK---->| | 816 {B,A} | |<-----ACK-------| | 817 {B,A} |<-----ACK-------| | | 818 | | | | 819 {B,A} | |<----REFER------| | 820 {B,A} |<----REFER------| | | 821 {A,B} |-----200 OK---->| | | 822 {A,B} | |-----200 OK---->| | 823 {A,B} |-----NOTIFY---->| | | 824 {A,B} | |-----NOTIFY---->| | 825 {B,A} | |<----200 OK-----| | 826 {B,A} |<----200 OK-----| | | 827 | | | | 828 {A,N} |-----INVITE---->| | 829 {A,N} | |-----INVITE-------------------->| 830 {C,A} | |<----200 OK---------------------| 831 {C,A} |<----200 OK-----| | 832 {A,C} |------ACK------>| | 833 {A,C} | |------ACK---------------------->| 834 | | | | 835 |<======================RTP======================>| 836 | | | | 837 {A,B} |-----NOTIFY---->| | | 838 {A,B} | |-----NOTIFY---->| | 839 {B,A} | |<----200 OK-----| | 840 {B,A} |<----200 OK-----| | | 841 {B,A} | |<-----BYE-------| | 842 {B,A} |<-----BYE-------| | | 843 {A,B} |-----200 OK---->| | | 844 {A,B} | |-----200 OK---->| | 845 | | | | 847 Figure 2: Call Transfer using REFER 849 General operation of this example: 851 Starting from the existing Alice/Bob call described in Figure 1 of 852 this document, which established an existing Session-ID header field 853 value: 855 o UA-Bob requests Alice to call Carol, using a REFER transaction, as 856 described in [RFC3515]. UA-Alice is initially put on hold, then 857 told in the REFER who to contact with a new INVITE, in this case 858 UA-Carol. This Alice-to-Carol dialog will have a new Call-ID, 859 therefore it requires a new Session-ID header field value. The 860 wrinkle here is we can, and will, use Alice's UUID from her 861 existing dialog with Bob in the new INVITE to Carol. 863 o UA-Alice retains her UUID from the Alice-to-Bob call {A} when 864 requesting a call with UA-Carol. This is placed in the "local- 865 uuid" portion of the Session-ID header field value, at the same 866 time inserting a null "remote-uuid" value (because Carol's UA has 867 not yet received the UUID value). This same UUID traverses the 868 B2BUA unchanged. 870 o UA-Carol receives the INVITE with a Session Identifier UUID {A,N}, 871 replaces the A UUID value into the "remote-uuid" portion of the 872 Session-ID header field value and creates its own UUID {C} and 873 places this value in the "local-uuid" portion of the Session-ID 874 header field value, thereby removing the N (null) value 875 altogether. This combination forms a full Session Identifier 876 {C,A} in the 200 OK to the INVITE. This Session-ID header field 877 traverses the B2BUA unchanged towards UA-Alice. 879 o UA-Alice receives the 200 OK with the Session Identifier {C,A} and 880 responds to UA-Carol with an ACK (just as in Figure 1 - switches 881 places of the two UUID fields), and generates a NOTIFY to Bob with 882 a Session Identifier {A,B} indicating the call transfer was 883 successful. 885 o It does not matter which UA terminates the Alice-to-Bob call; 886 Figure 2 shows UA-Bob doing this transaction. 888 10.3. Basic Call Transfer using re-INVITE 890 From the example built within Section 10.1, we proceed to this 'Basic 891 Call Transfer using re-INVITE' example. 893 Alice is talking to Bob. Bob pushes a button on his phone to transfer 894 Alice to Carol via the B2BUA (using re-INVITE). 896 Session-ID 897 --- Alice B2BUA Bob Carol 898 | | | | 899 |<==============RTP==============>| | 900 | | | | 901 | | <--- (non-standard signaling) | 902 {A,B} | |---re-INVITE--->| | 903 {B,A} | |<-----200 OK----| | 904 {A,B} | |-----ACK------->| | 905 | | | | 906 {A,N} | |-----INVITE-------------------->| 907 {C,A} | |<----200 OK---------------------| 908 {A,C} | |------ACK---------------------->| 909 | | | | 910 |<======================RTP======================>| 911 | | | | 912 {A,B} | |------BYE------>| | 913 {B,A} | |<----200 OK-----| | 914 | | | | 915 | (Suppose Alice modifies the session) | 916 {A,B} |---re-INVITE--->| | | 917 {A,B} | |---re-INVITE------------------->| 918 {C,A} | |<---200 OK----------------------| 919 {C,A} |<---200 OK------| | | 920 {A,C} |------ACK------>| | | 921 {A,C} | |------ACK---------------------->| 922 | | | | 924 Figure 3: Call transfer using re-INVITE 926 General operation of this example: 928 o We assume the call between Alice and Bob from Section 10.1 is 929 operational with Session Identifier {A,B}. 931 o Bob uses non-standard signaling to the B2BUA to initiate a call 932 transfer from Alice to Carol. This could also be initiated via a 933 REFER message from Bob, but the signaling that follows might still 934 be similar to the above flow. In either case, Alice is completely 935 unaware of the call transfer until a future point in time when 936 Alice receives a message from Carol. 938 o The B2BUA sends a new INVITE with Alice's UUID {"local-uuid" = 939 "A"} to Carol. 941 o Carol receives the INVITE and accepts the request and adds her 942 UUID {C} to the Session Identifier for this session {"local-uuid" 943 = "C", "remote-uuid" = "A"}. 945 o The B2BUA then terminates the call to Bob with a BYE using the 946 Session Identifier {"local-uuid" = "A", "remote-uuid" = "B"}. 948 o Since Alice never received Carol's UUID from the B2BUA, when Alice 949 later attempts to modify the session with a re-INVITE, Alice would 950 send the "remote-uuid" = "B" toward Carol. Carol replies with the 951 "local-uuid" = "A", "remote-uuid" = "A" to reflect what was 952 received in the INVITE (which Carol already knew from previous 953 exchanges with the B2BUA). Alice then includes "remote-uuid" = 954 "C" in the following ACK message. 956 10.4. Single Focus Conferencing 958 Multiple users call into a conference server (say, an MCU) to attend 959 one of many conferences hosted on or managed by that server. Each 960 user has to identify which conference they want to join, but this 961 information is not necessarily in the SIP messaging. It might be 962 done by having a dedicated address for the conference or via an IVR, 963 as assumed in this example and depicted with the use of M1, M2, and 964 M3. Each user in this example goes through a two-step process of 965 signaling to gain entry onto their conference call, which the 966 conference focus identifies as M'. 968 Session-ID Conference 969 --- Alice Focus Bob Carol 970 | | | | 971 | | | | 972 {A,N} |----INVITE----->| | | 973 {M1,A} |<---200 OK------| | | 974 {A,M1} |-----ACK------->| | | 975 |<====RTP=======>| | | 976 {M',A} |<---re-INVITE---| | | 977 {A,M'} |-----200 OK---->| | | 978 {M',A} |<-----ACK-------| | | 979 | | | | 980 | | | | 981 {B,N} | |<----INVITE-----| | 982 {M2,B} | |-----200 OK---->| | 983 {B,M2} | |<-----ACK-------| | 984 | |<=====RTP======>| | 985 {M',B} | |---re-INVITE--->| | 986 {B,M'} | |<----200 OK-----| | 987 {M',B} | |------ACK------>| | 988 | | | | 989 | | | | 990 {C,N} | |<--------------------INVITE-----| 991 {M3,C} | |---------------------200 OK---->| 992 {C,M3} | |<---------------------ACK-------| 993 | |<=====================RTP======>| 994 {M',C} | |-------------------re-INVITE--->| 995 {C,M'} | |<--------------------200 OK-----| 996 {M',C} | |----------------------ACK------>| 998 Figure 4: Single Focus Conference Bridge 1000 General operation of this example: 1002 Alice calls into a conference server to attend a certain conference. 1003 This is a two-step operation since Alice cannot include the 1004 conference ID at this time and/or any passcode in the INVITE request. 1005 The first step is Alice's UA calling another UA to participate in a 1006 session. This will appear to be similar as the call-flow in Figure 1 1007 (in section 10.1). What is unique about this call is the second 1008 step: the conference server sends a re-INVITE request with its second 1009 UUID, but maintaining the UUID Alice sent in the first INVITE. This 1010 subsequent UUID from the conference server will be the same for each 1011 UA that calls into this conference server participating in this same 1012 conference bridge/call, which is generated once Alice typically 1013 authenticates and identifies which bridge she wants to participate 1014 on. 1016 o Alice sends an INVITE to the conference server with her UUID {A} 1017 and a "remote-uuid" = N. 1019 o The conference server responds with a 200 OK response which 1020 replaces the N UUID with a temporary UUID ("M1") as the "local- 1021 uuid" and a "remote-uuid" = "A". 1023 NOTE: this 'temporary' UUID is a real UUID; it is only temporary to 1024 the conference server because it knows that it is going to generate 1025 another UUID to replace the one just send in the 200 OK. 1027 o Once Alice, the user, gains access to the IVR for this conference 1028 server, she enters a specific conference ID and whatever passcode 1029 (if needed) to enter a specific conference call. 1031 o Once the conference server is satisfied Alice has identified which 1032 conference she wants to attend (including any passcode 1033 verification), the conference server re-INVITEs Alice to the 1034 specific conference and includes the Session-ID header field value 1035 component "local-uuid" = "M'" (and "remote-uuid" = "A") for that 1036 conference. All valid participants in the same conference will 1037 receive this same UUID for identification purposes and to better 1038 enable monitoring, and tracking functions. 1040 o Bob goes through this two-step process of an INVITE transaction, 1041 followed by a re-INVITE transaction to get this same UUID ("M'") 1042 for that conference. 1044 o In this example, Carol (and each additional user) goes through the 1045 same procedures and steps as Alice and Bob to get on this same 1046 conference. 1048 10.5. Single Focus Conferencing using WebEx 1050 Alice, Bob and Carol call into same WebEx conference. 1052 Session-ID Conference 1053 --- Alice Focus Bob Carol 1054 | | | | 1055 |<** HTTPS *****>| | | 1056 | Transaction | | | 1057 | | | | 1058 {M,N} |<----INVITE-----| | | 1059 {A,M} |-----200 OK---->| | | 1060 {M,A} |<-----ACK-------| | | 1061 |<=====RTP======>| | | 1062 | | | | 1063 | |<** HTTPS *****>| | 1064 | | Transaction | | 1065 | | | | 1066 {M,N} | |-----INVITE---->| | 1067 {B,M} | |<----200 OK-----| | 1068 {M,B} | |------ACK------>| | 1069 | |<=====RTP======>| | 1070 | | | | 1071 | |<****************** HTTPS *****>| 1072 | | Transaction | 1073 | | | | 1074 {M,N} | |--------------------INVITE----->| 1075 {C,M} | |<-------------------200 OK------| 1076 {M,C} | |---------------------ACK------->| 1077 | |<====================RTP=======>| 1079 Figure 5: Single Focus WebEx Conference 1081 General operation of this example: 1083 o Alice communicates with WebEx server with desire to join a certain 1084 meeting, by meeting number; also includes UA-Alice's contact 1085 information (phone number, URI and/or IP address, etc.) for each 1086 device she wants for this conference call. For example, the audio 1087 and video play-out devices could be separate units. 1089 o Conference Focus server sends INVITE (Session-ID header field 1090 value components "local-uuid" = M and a remote UUID of N, where M 1091 equals the "local-uuid" for each participant on this conference 1092 bridge) to UA-Alice to start session with that server for this A/V 1093 conference call. 1095 o Upon receiving the INVITE request from the conference focus 1096 server, Alice responds with a 200 OK. Her UA moves the "local- 1097 uuid" unchanged into the "remote-uuid" field, and generates her 1098 own UUID and places that into the "local-uuid" field to complete 1099 the Session-ID construction. 1101 o Bob and Carol perform same function to join this same A/V 1102 conference call as Alice. 1104 10.6. Cascading Conference Bridges 1106 10.6.1. Establishing a Cascaded Conference 1108 To expand conferencing capabilities requires cascading conference 1109 bridges. A conference bridge, or MCU, needs a way to identify itself 1110 when contacting another MCU. [RFC4579] defines the 'isfocus' 1111 Contact: header parameter just for this purpose. 1113 Session-ID 1114 --- MCU-1 MCU-2 MCU-3 MCU-4 1115 | | | | 1116 {M',N} |----INVITE----->| | | 1117 {J,M'} |<---200 OK------| | | 1118 {M',J} |-----ACK------->| | | 1120 Figure 6: MCUs Communicating Session Identifier UUID for Bridge 1122 Regardless of which MCU (1 or 2) a UA contacts for this conference, 1123 once the above exchange has been received and acknowledged, the UA 1124 will get the same {M',N} UUID pair from the MCU for the complete 1125 Session Identifier. 1127 A more complex form would be a series of MCUs all being informed of 1128 the same UUID to use for a specific conference. This series of MCUs 1129 can either be informed 1131 o All by one MCU (that initially generates the UUID for the 1132 conference). 1134 o The MCU that generates the UUID informs one or several MCUs of 1135 this common UUID, and they inform downstream MCUs of this common 1136 UUID that each will be using for this one conference. 1138 Session-ID 1139 --- MCU-1 MCU-2 MCU-3 MCU-4 1140 | | | | 1141 {M',N} |----INVITE----->| | | 1142 {J,M'} |<---200 OK------| | | 1143 {M',J} |-----ACK------->| | | 1144 | | | | 1145 {M',N} |---------------------INVITE----->| | 1146 {K,M'} |<--------------------200 OK------| | 1147 {M',K} |----------------------ACK------->| | 1148 | | | | 1149 {M',N} |-------------------------------------INVITE----->| 1150 {L,M'} |<------------------------------------200 OK------| 1151 {M',L} |--------------------------------------ACK------->| 1153 Figure 7: MCU Communicating Session Identifier UUID to More than One 1154 MCU 1156 General operation of this example: 1158 o The MCU generating the Session Identifier UUID communicates this 1159 in a separate INVITE, having a Contact header with the 'isfocus' 1160 header parameter. This will identify the MCU as what [RFC4579] 1161 calls a conference-aware SIP entity. 1163 o An MCU that receives this {M',N} UUID pair in an inter-MCU 1164 transaction can communicate the M' UUID in a manner in which it 1165 was received to construct a hierarchical cascade (though this time 1166 this second MCU would be the UAC MCU). 1168 o Once the conference is terminated, the cascaded MCUs will receive 1169 a BYE message to terminate the cascade. 1171 10.6.2. Calling into Cascaded Conference Bridges 1173 Here is an example of how a UA, say Robert, calls into a cascaded 1174 conference focus. Because MCU-1 has already contacted MCU-3, the MCU 1175 where Robert is going to join the conference, MCU-3 already has the 1176 Session-ID (M') for this particular conference call. 1178 Session-ID 1179 --- MCU-1 MCU-2 MCU-3 Robert 1180 | | | | 1181 {M',N} |----INVITE----->| | | 1182 {J,M'} |<---200 OK------| | | 1183 {M',J} |-----ACK------->| | | 1184 | | | | 1185 {M',N} |---------------------INVITE----->| | 1186 {K,M'} |<--------------------200 OK------| | 1187 {M',K} |----------------------ACK------->| | 1188 | | | | 1189 {R,N} | | |<---INVITE-----| 1190 (M',R} | | |----200 OK---->| 1191 {R,M'} | | |<----ACK-------| 1193 Figure 8: A UA Calling into a Cascaded MCU UUID 1195 General operation of this example: 1197 o The UA, Robert in this case, INVITEs the MCU to join a particular 1198 conference call. Robert's UA does not know anything about whether 1199 this is the main MCU of the conference call, or a cascaded MCU. 1200 Robert likely does not know MCUs can be cascaded, he just wants to 1201 join a particular call. Like as with any standard implementation, 1202 he includes a null "remote-uuid". 1204 o The cascaded MCU, upon receiving this INVITE from Robert, replaces 1205 the null UUID with the UUID value communicated from MCU-1 for this 1206 conference call as the "local-uuid" in the SIP response. Thus, 1207 moving Robert's UUID "R" to the "remote-uuid" value. 1209 o The ACK has the Session-ID {R,M'}, completing the 3-way handshake 1210 for this call establishment. Robert has now joined the conference 1211 call originated from MCU-1. 1213 o Once the conference is terminated, the cascaded MCUs will receive 1214 a BYE message to terminate the cascade. 1216 10.7. Basic 3PCC for two UAs 1218 An external entity sets up calls to both Alice and Bob for them to 1219 talk to each other. 1221 Session-ID 1222 --- Alice B2BUA Bob Carol 1223 | | | 1224 {X,N} |<----INVITE-----| | 1225 {A,X} |-----200 OK---->| | 1226 {A,N} | |----INVITE----->| 1227 {B,A} | |<---200 OK------| 1228 {B,A} |<-----ACK-------| | 1229 {A,B} | |------ACK------>| 1230 |<==============RTP==============>| 1232 Figure 9: 3PCC initiated call between Alice and Bob 1234 General operation of this example: 1236 o Some out of band procedure directs a B2BUA (or other SIP server) 1237 to have Alice and Bob talk to each other. In this case, the SIP 1238 server has to be transaction stateful, if not dialog stateful. 1240 o The SIP server INVITEs Alice to a session and uses a temporary 1241 UUID {X} and a null UUID pairing. 1243 o Alice receives and accepts this call set-up and replaces the null 1244 UUID with her UUID {A} in the Session Identifier, now {A,X}. 1246 o The transaction stateful SIP server receives Alice's UUID {A} in 1247 the local UUID portion and keeps it there, and discards its own 1248 UUID {X}, replacing this with a null UUID value in the INVITE to 1249 Bob as if this came from Alice originally. 1251 o Bob receives and accepts this INVITE and adds his own UUID {B} to 1252 the Session Identifier, now {B,A} for the response. 1254 o The session is established. 1256 10.8. Handling in 100 Trying SIP Response and CANCEL Request 1258 The following two subsections show examples of the Session Identifier 1259 for a 100 Trying response and a CANCEL request in a single call-flow. 1261 10.8.1. Handling in a 100 Trying SIP Response 1263 The following 100 Trying response is taken from an existing RFC, from 1264 [RFC5359] Section 2.9 ("Call Forwarding - No Answer"). 1266 Session-ID Alice SIP Server Bob-1 Bob-2 1267 | | | | 1268 {A,N} |----INVITE----->| | | 1269 {A,N} | |---INVITE---->| | 1270 {N,A} |<--100 Trying---| | | 1271 {B1,A} | |<-180 Ringing-| | 1272 {B1,A} |<--180 Ringing--| | | 1273 | | | | 1274 | *Request Timeout* | 1275 | | | | 1276 {A,N} | |---CANCEL---->| | 1277 {B1,A} | |<--200 OK-----| | 1278 {B1,A} | |<---487-------| | 1279 {A,B1} | |---- ACK ---->| | 1280 | | | | 1281 {N,A} |<-181 Call Fwd--| | | 1282 | | | | 1283 {A,N} | |------------------INVITE------>| 1284 {B2,A} | |<----------------180 Ringing---| 1285 {B2,A} |<-180 Ringing---| | | 1286 {B2,A} | |<-----------------200 OK ------| 1287 {B2,A} |<--200 OK-------| | | 1288 {A,B2} |----ACK-------->| | | 1289 {A,B2} | |------------------ACK--------->| 1290 | | | | 1291 |<=========== Both way RTP Established =========>| 1292 | | | | 1293 {A,B2} |----BYE-------->| | | 1294 {A,B2} | |--------------------BYE------->| 1295 {B2,A} | |<------------------200 OK------| 1296 {B2,A} |<--200 OK-------| | | 1297 | | | | 1299 Figure 10: Session Identifier in the 100 Trying and CANCEL Messaging 1301 Below is the explanatory text from RFC 5359 Section 2.9 detailing 1302 what the desired behavior is in the above call flow (i.e., what the 1303 call-flow is attempting to achieve). 1305 "Bob wants calls to B1 forwarded to B2 if B1 is not answered 1306 (information is known to the SIP server). Alice calls B1 and no one 1307 answers. The SIP server then places the call to B2." 1309 General operation of this example: 1311 o Alice generates an INVITE request because she wants to invite Bob 1312 to join her session. She creates a UUID as described in section 1313 10.1, and places that value in the "local-uuid" field of the 1314 Session-ID header field value. Alice also generates a "remote- 1315 uuid" of null and sends this along with the "local-uuid". 1317 o The SIP server (imagine this is a B2BUA), upon receiving Alice's 1318 INVITE, generates the optional provisional response 100 Trying. 1319 Since the SIP server has no knowledge Bob's UUID for his part of 1320 the Session Identifier value, it cannot include his "local-uuid". 1321 Rather, any 100 Trying response includes Alice's UUID in the 1322 "remote-uuid" portion of the Session-ID header-value with a null 1323 "local-uuid" value in the response. This is consistent with what 1324 Alice's UA expects to receive in any SIP response containing this 1325 UUID. 1327 10.8.2. Handling a CANCEL SIP Request 1329 In the same call-flow example as the 100 Trying response is a CANCEL 1330 request. Please refer to Figure 10 for the CANCEL request example. 1332 General operation of this example: 1334 o In Figure 10 above, Alice generates an INVITE with her UUID value 1335 in the Session-ID header field. 1337 o Bob-1 responds to this INVITE with a 180 Ringing. In that 1338 response, he includes his UUID in the Session-ID header field 1339 value (i.e., {B1,A}); thus completing the Session-ID header field 1340 for this session, even though no final response has been generated 1341 by any of Bob's UAs. 1343 o While this means that if the SIP server were to generate a SIP 1344 request within this session it could include the complete 1345 SessionID, the server sends a CANCEL and a CANCEL always uses the 1346 same Session-ID header field as the original INVITE. Thus, the 1347 CANCEL would have a Session Identifier with the "local-uuid" = 1348 "A", and the "remote-uuid" = "N". 1350 o As it happens with this CANCEL, the SIP server intends to invite 1351 another UA of Bob (i.e., B2) for Alice to communicate with. 1353 o In this example call-flow, taken from RFC 5359, Section 2.9, a 181 1354 (Call is being Forwarded) response is sent to Alice. Since the 1355 SIP server generated this SIP request, and has no knowledge of 1356 Bob-2's UUID value, it cannot include that value in this 181. 1357 Thus, and for the exact reasons the 100 Trying including the 1358 Session Identifier value, only Alice's UUID is included in the 1359 remote-uuid component of the Session-ID header field value, with a 1360 null UUID present in the "local-uuid" component. 1362 10.9. Out-of-dialog REFER Transaction 1364 The following call-flow was extracted from Section 6.1 of [RFC5589] 1365 ("Successful Transfer"), with the only changes being the names of the 1366 UAs to maintain consistency within this document. 1368 Alice is the transferee 1369 Bob is the transferer 1370 and Carol is the transfer-target 1372 Session-ID Bob Alice Carol 1373 | | | 1374 {A,N} |<-----INVITE--------| | 1375 {B,A} |------200 OK------->| | 1376 {A,B} |<------ACK----------| | 1377 | | | 1378 {B,A} |--INVITE {hold}---->| | 1379 {A,B} |<-200 OK------------| | 1380 {B,A} |--- ACK ----------->| | 1381 | | | 1382 {B,A} |--REFER------------>|(Refer-To:Carol) | 1383 {A,B} |<-202 Accepted------| | 1384 | | | 1385 {A,B} || | 1387 | | | 1388 {A,N} | |--INVITE------------>| 1389 {C,A} | |<-200 OK-------------| 1390 {A,C} | |---ACK-------------->| 1391 | | | 1392 {A,B} |<--NOTIFY {200 OK}--| | 1393 {B,A} |---200 OK---------->| | 1394 | | | 1395 {B,A} |--BYE-------------->| | 1396 {A,B} |<-200 OK------------| | 1397 {C,A} | |<------------BYE-----| 1398 {A,C} | |-------------200 OK->| 1400 Figure 11: Out-Of-Dialog Call Transfer 1402 General operation of this example: 1404 o Just as in Section 10.2, Figure 2, Alice invites Bob to a session, 1405 and Bob eventually transfers Alice to communicate with Carol. 1407 o What is different about the call-flow in Figure 11 is that Bob's 1408 REFER is not in-dialog. Even so, this is treated as part of the 1409 same communication session and, thus, the Session Identifier in 1410 those messages is {A,B}. 1412 o Alice will use her existing UUID and the null UUID ({A,N}) in the 1413 INVITE towards Carol (who generates UUID "C" for this session), 1414 thus maintaining the common UUID within the Session Identifier for 1415 this new Alice-to-Carol session. 1417 11. Compatibility with a Previous Implementation 1419 There is a much earlier and proprietary document that specifies the 1420 use of a Session-ID header field (namely, [RFC7329]) that we will 1421 herewith attempt to achieve backwards compatibility. Neither 1422 Session-ID header field has any versioning information, so merely 1423 adding that this document describes "version 2" is insufficient. 1424 Here are the set of rules for compatibility between the two 1425 specifications. For the purposes of this discussion, we will label 1426 the proprietary specification of the Session-ID as the "old" version 1427 and this specification as the "new" version of the Session-ID. 1429 The previous (i.e., "old") version only has a single UUID value as a 1430 Session-ID header field value, but has a generic-parameter value that 1431 can be of use. 1433 In order to have an "old" version talk to an "old" version 1434 implementation, nothing needs to be done as far as the IETF is 1435 concerned. 1437 In order to have a "new" version talk to a "new" version 1438 implementation, both implementations need to follow this document (to 1439 the letter) and everything should be just fine. 1441 But that is where compatibility is not ensured, given the unknowns 1442 related to the behavior of entities implementing the pre-standard 1443 implementation. For this "new" implementation to work with the "old" 1444 implementation and an "old" implementation to work with "new" 1445 implementations, there needs to be a set of rules that all "new" 1446 implementations MUST follow. 1448 o Since no option tags or feature tags are to be used for 1449 distinguishing versions, the presence and order of any "remote- 1450 uuid" value within the Session-ID header field value is to be used 1451 to distinguish implementation versions. 1453 o If a SIP request has a "remote-uuid" value, this comes from a 1454 standard implementation, and not a pre-standard one. 1456 o If a SIP request has no "remote-uuid" value, this comes from a 1457 pre-standard implementation, and not a standard one. In this 1458 case, one UUID is used to identify this dialog, even if the 1459 responder is a standard implementation of this specification. 1461 o If a SIP response has a non-null "local-uuid" that is 32 octets 1462 long and differs from the endpoint's own UUID value, this response 1463 comes from a standard implementation. 1465 o If a SIP response has a non-null "local-uuid" that is not 32 1466 octets long, this response comes from a misbehaving 1467 implementation, and its Session-ID header field MUST be discarded. 1468 That said, the response might still be valid according to the 1469 rules within SIP [RFC3261], and SHOULD be checked further. 1471 o If a SIP response arrives that has the same value of Session-ID 1472 UUIDs in the same order as was sent, this comes from a pre- 1473 standard implementation, and MUST NOT be discarded for not 1474 altering the null "remote-uuid". In this case, any new 1475 transaction within this dialog MUST preserve the order of the two 1476 UUIDs within all Session-ID header field, including the ACK, until 1477 this dialog is terminated. 1479 o If a SIP response only contains the "local-uuid" that was sent 1480 originally, this comes from a pre-standard implementation and MUST 1481 NOT be discarded for removing the null "remote-uuid". In this 1482 case, all future transactions within this dialog MUST contain only 1483 the UUID received in the first SIP response. Any new transaction 1484 starting a new dialog from the standard Session-ID implementation 1485 MUST include a "local-uuid" and a null "remote-uuid", even if that 1486 new dialog is between the same two UAs. 1488 o Standard implementations SHOULD NOT expect pre-standard 1489 implementations to be consistent in their implementation, even 1490 within the same dialog. For example, perhaps the first, third and 1491 tenth responses contain a "remote-uuid", but all the others do 1492 not. This behavior MUST be allowed by implementations of this 1493 specification. 1495 o The foregoing does not apply to other, presently unknown 1496 parameters that might be defined in the future. They are ignored 1497 for the purposes of interoperability with previous 1498 implementations. 1500 12. Security Considerations 1502 When creating a UUID value, UAs MUST ensure that there is no user or 1503 device-identifying information contained within the UUID. In 1504 particular, this means that a UUID MUST NOT be constructed using a 1505 MAC address on the host. 1507 The Session Identifier might be utilized for logging or 1508 troubleshooting, but MUST NOT be used for billing purposes. 1510 The Session Identifier could be misused to discover relationships 1511 between two or more parties. For example, suppose that Alice calls 1512 Bob and Bob, via his PBX, forwards or transfers the call to Carol. 1513 Without use of the Session Identifier, an unauthorized third party 1514 that is observing the communications between Alice and Bob might not 1515 know that Alice is actually communicating with Carol. If Alice, Bob, 1516 and Carol include the Session Identifier as a part of the signaling 1517 messages, it is possible for the third party to observe that the UA 1518 associated with Bob changed to some other UA. If the third party 1519 also has access to signaling messages between Bob and Carol, the 1520 third party can then discover that Alice is communicating with Carol. 1521 This would be true even if all other information relating to the 1522 session is changed by the PBX, including both signaling information 1523 and media address information. 1525 13. IANA Considerations 1527 13.1. Registration of the "Session-ID" Header Field 1529 The following is the registration for the 'Session-ID' header field 1530 to the "Header Name" registry at 1532 http://www.iana.org/assignments/sip-parameters: 1534 RFC number: RFC XXXX 1536 Header name: 'Session-ID' 1538 Compact form: none 1540 Note: This document replaces the "Session-ID" header originally 1541 registered via [RFC7329]. 1543 [RFC Editor: Please replace XXXX in this section and the next with 1544 the this RFC number of this document.] 1546 13.2. Registration of the "remote" Parameter 1548 The following parameter is to be added to the "Header Field 1549 Parameters and Parameter Values" section of the SIP parameter 1550 registry: 1552 +--------------+----------------+-------------------+-----------+ 1553 | Header Field | Parameter Name | Predefined Values | Reference | 1554 +--------------+----------------+-------------------+-----------+ 1555 | Session-ID | remote | No | [RFCXXXX] | 1556 +--------------+----------------+-------------------+-----------+ 1558 14. Acknowledgements 1560 The authors would like to thank Robert Sparks, Hadriel Kaplan, 1561 Christer Holmberg, Paul Kyzivat, Brett Tate, Keith Drage, Mary 1562 Barnes, Charles Eckel, Peter Dawes, Andrew Hutton, Arun Arunachalam, 1563 Adam Gensler, Roland Jesske, and Faisal Siyavudeen for their 1564 invaluable comments during the development of this document. 1566 15. Dedication 1568 This document is dedicated to the memory of James Polk, a long-time 1569 friend and colleague. James made important contributions to this 1570 specification, including being one of its primary editors. The IETF 1571 global community mourns his loss and he will be missed dearly. 1573 16. References 1575 16.1. Normative References 1577 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1578 Requirement Levels", BCP 14, RFC 2119, 1579 DOI 10.17487/RFC2119, March 1997, 1580 . 1582 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1583 A., Peterson, J., Sparks, R., Handley, M., and E. 1584 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1585 DOI 10.17487/RFC3261, June 2002, 1586 . 1588 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1589 Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, 1590 . 1592 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 1593 Protocol (SIP) "Replaces" Header", RFC 3891, 1594 DOI 10.17487/RFC3891, September 2004, 1595 . 1597 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1598 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1599 DOI 10.17487/RFC4122, July 2005, 1600 . 1602 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol 1603 (SIP) Call Control - Conferencing for User Agents", 1604 BCP 119, RFC 4579, DOI 10.17487/RFC4579, August 2006, 1605 . 1607 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1608 Specifications: ABNF", STD 68, RFC 5234, 1609 DOI 10.17487/RFC5234, January 2008, 1610 . 1612 [RFC7329] Kaplan, H., "A Session Identifier for the Session 1613 Initiation Protocol (SIP)", RFC 7329, 1614 DOI 10.17487/RFC7329, August 2014, 1615 . 1617 16.2. Informative References 1619 [H.323] International Telecommunications Union, "Recommendation 1620 ITU-T H.323, Packet-based multimedia communications 1621 systems", December 2009. 1623 [H.460.27] 1624 International Telecommunications Union, "Recommendation 1625 ITU-T H.460.27, End-to-End Session Identifier for H.323 1626 Systems", November 2015. 1628 [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. 1629 Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, 1630 DOI 10.17487/RFC2543, March 1999, 1631 . 1633 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1634 Jacobson, "RTP: A Transport Protocol for Real-Time 1635 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1636 July 2003, . 1638 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 1639 Camarillo, "Best Current Practices for Third Party Call 1640 Control (3pcc) in the Session Initiation Protocol (SIP)", 1641 BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, 1642 . 1644 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 1645 Session Initiation Protocol (SIP)", RFC 4353, 1646 DOI 10.17487/RFC4353, February 2006, 1647 . 1649 [RFC5359] Johnston, A., Ed., Sparks, R., Cunningham, C., Donovan, 1650 S., and K. Summers, "Session Initiation Protocol Service 1651 Examples", BCP 144, RFC 5359, DOI 10.17487/RFC5359, 1652 October 2008, . 1654 [RFC5589] Sparks, R., Johnston, A., Ed., and D. Petrie, "Session 1655 Initiation Protocol (SIP) Call Control - Transfer", 1656 BCP 149, RFC 5589, DOI 10.17487/RFC5589, June 2009, 1657 . 1659 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 1660 Initiation Protocol (SIP) Back-to-Back User Agents", 1661 RFC 7092, DOI 10.17487/RFC7092, December 2013, 1662 . 1664 [RFC7206] Jones, P., Salgueiro, G., Polk, J., Liess, L., and H. 1665 Kaplan, "Requirements for an End-to-End Session 1666 Identification in IP-Based Multimedia Communication 1667 Networks", RFC 7206, DOI 10.17487/RFC7206, May 2014, 1668 . 1670 Authors' Addresses 1672 Paul E. Jones 1673 Cisco Systems, Inc. 1674 7025 Kit Creek Rd. 1675 Research Triangle Park, NC 27709 1676 USA 1678 Phone: +1 919 476 2048 1679 Email: paulej@packetizer.com 1680 Gonzalo Salgueiro 1681 Cisco Systems, Inc. 1682 7025 Kit Creek Rd. 1683 Research Triangle Park, NC 27709 1684 USA 1686 Phone: +1 919 392 3266 1687 Email: gsalguei@cisco.com 1689 Chris Pearce 1690 Cisco Systems, Inc. 1691 2300 East President George Bush Highway 1692 Richardson, TX 75082 1693 USA 1695 Phone: +1 972 813 5123 1696 Email: chrep@cisco.com 1698 Paul Giralt 1699 Cisco Systems, Inc. 1700 7025 Kit Creek Rd. 1701 Research Triangle Park, NC 27709 1702 USA 1704 Phone: +1 919 991 5644 1705 Email: pgiralt@cisco.com