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