idnits 2.17.1 draft-ietf-insipid-session-id-01.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 (July 8, 2013) is 3945 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 253, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 913, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-insipid-session-id-reqts-07 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Jones 3 Internet Draft C. Pearce 4 Intended status: Standards Track J. Polk 5 Expires: January 8, 2014 G. Salgueiro 6 Cisco Systems 7 July 8, 2013 9 End-to-End Session Identification in IP-Based Multimedia 10 Communication Networks 11 draft-ietf-insipid-session-id-01 13 Abstract 15 This document describes an end-to-end Session Identifier for use in 16 IP-based Multimedia Communication systems that enables endpoints, 17 intermediate devices, and management systems to identify a session 18 end-to-end, associate multiple endpoints with a given multipoint 19 conference, track communication sessions when they are redirected, 20 and associate one or more media flows with a given communication 21 session. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on January 8, 2014. 46 Copyright Notice 48 Copyright (c) 2013 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...................................................2 64 2. Conventions used in this document..............................3 65 3. Session Identifier Requirements and Use Cases..................3 66 4. Constructing and Conveying the Session Identifier..............3 67 4.1. Constructing the Session Identifier.......................3 68 4.2. Conveying the Session Identifier..........................4 69 5. Transmitting the Session Identifier in SIP.....................5 70 6. Endpoint Behavior..............................................6 71 7. Processing by Intermediaries...................................7 72 8. Associating Endpoints in a Multipoint Conference...............8 73 9. Various Call Flow Operations Utilizing the Session ID..........8 74 9.1. Basic Session-ID Construction with 2 UUIDs................8 75 9.2. Basic Call Transfer using REFER...........................9 76 9.3. Basic Call Transfer using reINVITE.......................11 77 9.4. Single Focus Conferencing................................12 78 9.5. Single Focus Conferencing using WebEx....................13 79 9.6. Cascading Conference Bridge Support for the Session-ID...14 80 9.7. Basic 3PCC for two UAs...................................16 81 10. Compatibility with a Previous Implementation.................16 82 11. Security Considerations......................................18 83 12. IANA Considerations..........................................18 84 12.1. Registration of the "Session-ID" Header Field...........18 85 12.2. Registration of the "remote" Parameter..................18 86 13. Acknowledgments..............................................19 87 14. References...................................................19 88 14.1. Normative References....................................19 89 14.2. Informative References..................................19 90 Author's Addresses...............................................20 92 1. Introduction 94 IP-based multimedia communication systems like SIP [RFC3261] and 95 H.323 [H.323] have the concept of a "call identifier" that is 96 globally unique. The identifier is intended to represent an end-to- 97 end communication session from the originating device to the 98 terminating device. Such an identifier is useful for 99 troubleshooting, session tracking, and so forth. 101 Unfortunately, there are a number of factors that contribute to the 102 fact that the current call identifiers defined in SIP and H.323 are 103 not suitable for end-to-end session identification. A fundamental 104 issue in protocol interworking is the fact that the syntax for the 105 call identifier in SIP and H.323 is different between the two 106 protocols. This important fact makes it impossible for call 107 identifiers to be exchanged end-to-end when a network utilizes one or 108 more session protocols. 110 Another reason why the current call identifiers are not suitable to 111 identify the session end-to-end is that in real-world deployments 112 devices like session border controllers often change the session 113 signaling as it passes through the device, including the value of the 114 call identifier. While this is deliberate and useful, it makes it 115 very difficult to track sessions end-to-end. 117 This draft presents a new identifier, referred to as the Session 118 Identifier, or "Session ID", and associated syntax intended to 119 overcome the issues that exist with the currently defined call 120 identifiers. The proposal in this document attempts to comply with 121 the requirements specified in [I-D.ietf-insipid-session-id-reqts]. 122 This proposal also has capabilities not mentioned in [RFC5234], shown 123 in call flows in section 10. Additionally, this proposal attempts to 124 account for a previous, proprietary version of a SIP Session ID 125 header, proposing a backwards compatibility of sorts, described in 126 section 11. 128 2. Conventions used in this document 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [RFC2119] 133 when they appear in ALL CAPS. These words may also appear in this 134 document in lower case as plain English words, absent their normative 135 meanings. 137 3. Session Identifier Requirements and Use Cases 139 Requirements and Use Cases for the end-to-end Session Identifier can 140 be found in a separate memo titled "Requirements for an End-to-End 141 Session Identification in IP-Based Multimedia Communication Networks" 142 [I-D.ietf-insipid-session-id-reqts]. 144 4. Constructing and Conveying the Session Identifier 146 4.1. Constructing the Session Identifier 148 The Session Identifier is comprised of two RFC 4122 defined UUIDs 149 [RFC4122], with each UUID representing one of the endpoints 150 participating in the session. 152 The version number in the UUID indicates the manner in which the UUID 153 is generated, such as using random values or using the MAC address of 154 the endpoint. To satisfy the requirement that no user or device 155 information be conveyed, endpoints SHOULD generate version 4 (random) 156 or version 5 (SHA-1) UUIDs. 158 When generating a version 5 UUID, endpoints or intermediaries MUST 159 utilize the following "name space ID" (see Section 4.3 of RFC4122): 161 uuid_t NameSpace_SessionID = { 162 /* a58587da-c93d-11e2-ae90-f4ea67801e29 */ 163 0xa58587da, 164 0xc93d, 165 0x11e2, 166 0xae, 0x90, 0xf4, 0xea, 0x67, 0x80, 0x1e, 0x29 167 } 169 Further, the "name" to utilize for version 5 UUIDs is the 170 concatenation of the Call-ID header value and the "tag" parameter 171 that appears on the "From" or "To" line associated with the device 172 for which the UUID is created. Once an endpoint generates a UUID for 173 a session, the UUID never changes, even if values originally used as 174 input into its construction change over time. 176 Intermediaries that insert a Session-ID header into a SIP message on 177 behalf of a sending User Agent MUST utilize version 5 UUIDs to ensure 178 that UUIDs for the communication session are always generated with 179 the same values. If an intermediary does not know the tag value for 180 an endpoint, the intermediary MUST NOT attempt to generate a UUID for 181 that endpoint. Note that if an intermediary is stateless and the 182 endpoint on one end of the call is replaced with another endpoint due 183 to some service interaction, the values used to create the UUID might 184 change and, if so, the intermediary will compute a different UUID. 186 4.2. Conveying the Session Identifier 188 The SIP user agent (UA) initially transmitting the SIP request will 189 create a UUID and transmit that to the ultimate destination UA. 190 Likewise, the responding UA will create a UUID and transmit that to 191 the first UA. These two distinct UUIDs form what is referred to as 192 the Session Identifier and is represented in this document in set 193 notation of the form {A,B}, where A is UUID value from the UA 194 transmitting a message and B is the UUID value from the intended 195 recipient of the message, i.e., not an intermediary server along the 196 signaling path. The set {A,B} is equal to the set {B,A}, and thus 197 both represent the same Session Identifier. 199 In the case where only one UUID is known, such as when a UA first 200 initiates a SIP request, the Session ID would be {A}, where "A" 201 represents the single UUID value transmitted. 203 Since SIP sessions are subject to any number of service interactions, 204 SIP INVITE messages might be forked as sessions are established, and 205 since conferences might be established or expanded with endpoints 206 calling in or the conference focus calling out, the construction of 207 the Session Identifier from a set of UUIDs is important. 209 To understand this better, consider that a UA participating in a 210 communication session might be replaced with another, such as the 211 case where two "legs" of a call are joined together by a PBX. 212 Suppose that UA A and UA B both call UA C. Further suppose that UA C 213 uses a local PBX function to join the call between itself and UA A 214 with the call between itself and UA B. This merged call needs to be 215 identified and identification of such sessions is natural and easily 216 traceable when utilizing UUID values assigned by each entity in the 217 communication session. 219 In the case of forking, UA A might send an INVITE that gets forked to 220 five different UAs, as an example. A means of identifying each of 221 these separate communication sessions is needed and allowing the set 222 of {A, B1}, {A, B2}, {A, B3}, {A, B4}, and {A, B5} makes this 223 possible. 225 For conferencing scenarios, it is also useful to have a two-part 226 Session-ID where the conference focus specifies one UUID. This might 227 allow for correlation among the participants in a single conference, 228 for example. 230 How a device acting on Session Identifiers stores, processes, or 231 utilizes the Session Identifier is outside the scope of this 232 document. 234 5. Transmitting the Session Identifier in SIP 236 Each session initiated or accepted MUST have a local UA-generated 237 UUID associated with the session. This value MUST remain unchanged 238 throughout the duration of that session. 240 A SIP UA MUST convey its Session Identifier UUID in all transmitted 241 messages within the same session. To do this, each transmitted 242 message MUST include the "Session-ID" header. The Session-ID header 243 has the following ABNF [RFC5234] syntax: 245 session-id = "Session-ID" HCOLON local-uuid 247 *(SEMI sess-id-param) 249 local-uuid = sess-uuid 251 remote-uuid = sess-uuid 253 sess-uuid = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] 254 sess-id-param = remote-param / generic-param 256 remote-param = "remote" EQUAL remote-uuid 258 The productions "SEMI", "EQUAL", and "generic-param" are defined in 259 RFC 3261. The production DIGIT is defined in RFC 5234. 261 The Session-ID header MUST NOT have more than one "remote" parameter. 263 The "local-uuid" in the Session-ID header represents the UUID value 264 of the UA transmitting the message. If the UA transmitting the 265 message previously received a UUID value from its peer endpoint, it 266 MUST include that UUID as the "remote" parameter in each message it 267 transmits. For example, using the UUID values from the previous 268 section, a Session-ID header might appear like this: 270 Session-ID: aeffa652b22911dfa81f12313a006823; 271 remote=be11afc8b22911df86c412313a006823 273 The UUID values are presented as strings of lower-case hexadecimal 274 characters, with the most significant byte of the UUID appearing 275 first. 277 6. Endpoint Behavior 279 To comply with this specification, SIP UAs MUST include a Session-ID 280 header-value in all SIP messages transmitted as a part of a 281 communication session. The UUID of the sender of the message MUST 282 appear first in the Session-ID header and the UUID of the peer 283 device, if known, must appear as the "remote" parameter following the 284 sender's UUID. Note that the "sender" of the message is not the user 285 agent that initiates a transaction. Rather, the "sender" is the user 286 agent that transmits a message, regardless of whether this is a new 287 transaction or a response to a message received. 289 Once a UA allocates a UUID value for a communication session, the UA 290 MUST NOT change that UUID value for the duration of the session, 291 including when 293 - communication attempts are retried due to receipt of 4xx 294 messages or request timeouts; 295 - the session is redirected in response to a 3xx message; or 296 - a session is transferred via a REFER message [RFC3515], or when 297 a SIP dialog is replaced via an INVITE with Replaces [RFC3891]. 299 A non-intermediary UA that receives a Session-ID header MUST take 300 note of the first UUID value (i.e., the "local-UUID") that it 301 receives in the Session-ID header and assume that that is the UUID of 302 the peer endpoint within that communications session. UAs MUST 303 include this received UUID value as the "remote" parameter when 304 transmitting subsequent messages. 306 It should be noted that messages received by a UA might contain a 307 "remote" parameter that does not match the UAs UUID. This might 308 happen as a result of service interactions by intermediaries and MUST 309 NOT negatively affect the communication session. However, the UA may 310 log this event for the purposes of troubleshooting. 312 For any purpose the UA has for the Session-ID, it MUST assume that 313 the Session-ID is {A,B} where "A" is the UUID value of this endpoint 314 and "B" is the UUID value of the peer endpoint, taken from the most 315 recently received message within this session. 317 An endpoint MUST assume that the UUID value of the peer UA MAY change 318 at any time due to service interactions. If the UUID value of the 319 peer UA changes, the UA MUST include this new UUID as the "remote" 320 parameter in any subsequent messages. 322 It is also important to note that if a session is forked by an 323 intermediary in the network, the initiating UA may receive multiple 324 responses back from different endpoints, each of which will contain a 325 different UUID value. UAs MUST take care to ensure that the correct 326 UUID value is returned in the "remote" parameter when responding to 327 those endpoints. 329 7. Processing by Intermediaries 331 Intermediaries MUST NOT alter the UUID values found in the Session-ID 332 header, except as described in this section. 334 Intermediary devices that transfer a call, such as by joining 335 together two different "call legs", MUST properly construct a 336 Session-ID header that contains the correct UUID values and correct 337 placement of those values. As described above, the recipient of any 338 message initiated by the intermediary will assume that the first UUID 339 value belongs to the peer endpoint. 341 If a SIP message having no Session-ID header is received by an 342 intermediary, the intermediary MAY assign a "local-uuid" value to 343 represent the sending endpoint and insert that value into all 344 signaling messages on behalf of the sending endpoint. If the 345 intermediary is aware of a "remote" value that identifies the 346 receiving UA, it MUST insert that value if also inserting the "local- 347 uuid" value. 349 Devices that initiate communication sessions following the procedures 350 for third party call control MUST fabricate a UUID value that will be 351 utilized only temporarily. Once the responding endpoint provides a 352 UUID value in a response message, the temporary value MUST be 353 discarded and replaced with the endpoint-provided UUID value. Refer 354 to the third-party call control example for an illustration. 356 Whenever there is a UA that does not implement this specification 357 communicating through a B2BUA, the B2BUA MAY become dialog stateful 358 and insert a UUID value into the Session-ID header on behalf of the 359 UA according to the rules stated in Section 6. 361 8. Associating Endpoints in a Multipoint Conference 363 Multipoint Control Units (MCUs) group two or more sessions into a 364 single multipoint conference. The MCU should utilize the same UUID 365 value for each session that is grouped into the same conference. In 366 so doing, each individual session in the conference will have a 367 unique Session Identifier (since each endpoint will create a unique 368 UUID of its own), but will also have one UUID in common with all 369 other participants in the conference. 371 Intermediary devices, such as proxies or session border controllers, 372 or network diagnostics equipment might assume that when they see two 373 or more sessions with different Session Identifiers, but with one 374 UUID in common, that the sessions are part of the same conference. 376 Note, however, that this assumption of being part of the same 377 conference is not always true. For example, in a SIP forking 378 scenario, there might also be what appears to be multiple sessions 379 with a shared UUID value. This is actually desirable. What is 380 desired is to allow for the association of related sessions. Whether 381 sessions are related because of forking or because endpoints are 382 communicating as a part of a conference does not matter. They are 383 nonetheless related. 385 9. Various Call Flow Operations Utilizing the Session ID 387 Seeing something frequently makes understanding easier. With that in 388 mind, we include several call flows with the initial UUID and the 389 complete Session-ID indicated per message, as well as when the 390 Session-ID changes according to the rules within this document during 391 certain operations/functions. 393 This section is for illustrative purposes only and is non-normative. 394 In the following flows, RTP refers to the Real-time Transport 395 Protocol [RFC3550]. 397 [TODO: Section 9 needs to be recast explicitly as examples. It is 398 very confusing to have things in examples labeled "Rules" or appear 399 to be defining operation.] 401 [TODO: Need call flows using 100 Trying and CANCEL.] 403 9.1. Basic Session-ID Construction with 2 UUIDs 405 Session-ID 406 --- Alice B2BUA Bob Carol 407 {A} |----INVITE----->| | 408 {A} | |----INVITE----->| 409 {B,A} | |<---200 OK------| 410 {B,A} |<---200 OK------| | 411 {A,B} |------ACK------>| | 412 {A,B} | |------ACK------>| 413 |<==============RTP==============>| 415 Figure 1 - Session-ID Creation when Alice calls Bob 417 Operation/Rules: 419 o Transmitter of SIP message places its Session-ID UUID first in 420 order. 422 o UA-Alice sends its UUID in INVITE. 424 o B2BUA receives an INVITE with a Session-ID header-value from UA- 425 Alice, and transmits INVITE towards UA-Bob with an unchanged 426 Session-ID header-value. 428 o UA-Bob receives Session-ID and adds its UUID to construct the 429 whole/complete Session-ID header-value in the 200 OK. 431 o UA-Bob orders the UUIDs such that its UUID is first when UA-Bob 432 is transmitting the SIP message. 434 o B2BUA receives the 200 OK response with a complete Session-ID 435 header-value from UA-Bob, and transmits 200 OK towards UA-Alice 436 with an unchanged Session-ID header-value; while maintaining the 437 order of UUIDs in the Session-ID header-value. 439 o UA-Alice, upon reception of the 200 OK from the B2BUA, transmits 440 the ACK towards the B2BUA with its UUID positioned first, and 441 the UUID from UA-Bob positioned second in the Session-ID header- 442 value. 444 o B2BUA receives the ACK with a complete Session-ID header-value 445 from UA-Alice, and transmits ACK towards UA-Bob with an 446 unchanged Session-ID header-value; while maintaining the order 447 of UUIDs in the Session-ID header-value. 449 9.2. Basic Call Transfer using REFER 451 [TODO: Need an OOD REFER example.] 453 From the example built within Section 9.1 (the basic session-ID 454 establishment), we proceed to this 'Basic Call Transfer using REFER' 455 example. 457 Session-ID 458 --- Alice B2BUA Bob Carol 459 | | | | 460 |<==============RTP==============>| | 461 {B,A} | |<---reINVITE----| | 462 {B,A} |<---reINVITE----| (puts Alice on Hold) | 463 {A,B} |-----200 OK---->| | | 464 {A,B} | |-----200 OK---->| | 465 {B,A} | |<-----ACK-------| | 466 {B,A} |<-----ACK-------| | | 467 | | | | 468 {B,A} | |<----REFER------| | 469 {B,A} |<----REFER------| | | 470 {A,B} |-----200 OK---->| | | 471 {A,B} | |-----200 OK---->| | 472 {A,B} |-----NOTIFY---->| | | 473 {A,B} | |-----NOTIFY---->| | 474 {B,A} | |<----200 OK-----| | 475 {B,A} |<----200 OK-----| | | 476 | | | | 477 {A} |-----INVITE---->| | 478 {A} | |-----INVITE-------------------->| 479 {C,A} | |<----200 OK---------------------| 480 {C,A} |<----200 OK-----| | 481 {A,C} |------ACK------>| | 482 {A,C} | |------ACK---------------------->| 483 | | | | 484 |<======================RTP======================>| 485 | | | | 486 {A,B} |-----NOTIFY---->| | | 487 {A,B} | |-----NOTIFY---->| | 488 {B,A} | |<----200 OK-----| | 489 {B,A} |<----200 OK-----| | | 490 {B,A} | |<-----BYE-------| | 491 {B,A} |<-----BYE-------| | | 492 {A,B} |-----200 OK---->| | | 493 {A,B} | |-----200 OK---->| | 494 | | | | 496 Figure 2 - Call Transfer using REFER 498 Operation/Rules: 500 Starting from the existing Alice/Bob call described in Figure 1, 501 which established an existing Session-ID header-value... 503 o UA-Bob reINVITEs Alice to call Carol, using a REFER transaction, 504 as described in [RFC3515]. UA-Alice is initially put on hold, 505 then told in the REFER who to contact with a new INVITE, in this 506 case UA-Carol. 508 o UA-Alice retains her UUID from the Alice-to-Bob call {A} when 509 requesting a call with UA-Carol. This same UUID traverses the 510 B2BUA unchanged. 512 o UA-Carol receives the INVITE with a Session-ID UUID {A}, creates 513 its own UUID {C}, and combines them to form a full Session-ID 514 {C,A} in the 200 OK to the INVITE. This Session-ID header-value 515 traverses the B2BUA unchanged towards UA-Alice. 517 o UA-Alice receives the 200 OK with the Session-ID {C,A} and both 518 responses to UA-Carol with an ACK, generates a NOTIFY to Bob 519 with a Session-ID {A,B} indicating the call transfer was 520 successful. 522 o It does not matter which UA terminates the Alice-to-Bob call; 523 Figure 2 shows UA-Bob doing this transaction. 525 9.3. Basic Call Transfer using reINVITE 527 From the example built within Section 9.1 (the basic session-ID 528 establishment), we proceed to this 'Basic Call Transfer using 529 reINVITE' example. 531 Alice is talking to Bob. Bob pushes a button on his phone to transfer 532 Alice to Carol via the B2BUA (using reINVITE). 534 Session-ID 535 --- Alice B2BUA Bob Carol 536 | | | | 537 |<==============RTP==============>| | 538 | | | | 539 {B,A} | |<---reINVITE----| | 540 {A,B} | |-----200 OK---->| | 541 {B,A} | |<-----ACK-------| | 542 | | | | 543 {A} | |-----INVITE-------------------->| 544 {C,A} | |<----200 OK---------------------| 545 {A,C} | |------ACK---------------------->| 546 | | | | 547 |<======================RTP======================>| 548 | | | | 549 {B,A} | |<-----BYE-------| | 550 {A,B} | |-----200 OK---->| | 551 | | | | 553 Figure 3 - Call transfer using reINVITE 555 Operation/Rules: 557 o We assume the call between Alice and Bob from Section 9.1 is 558 operational with Session-ID {A,B}. 560 o Bob sends a reINVITE to Alice to transfer her to Carol. 562 o The B2BUA intercepts this reINVITE and sends a new INVITE with 563 Alice's UUID {A} to Carol. 565 o Carol receives the INVITE and accepts the request and adds her 566 UUID {C} to the Session-ID for this session {C,A}. 568 o Bob terminates the call with a BYE using the Session-ID {B,A}. 569 The B2BUA responds to Bob since Alice and Carol are now in a new 570 call. 572 9.4. Single Focus Conferencing 574 Multiple users call into a conference server (say, an MCU) to attend 575 one of many conferences hosted on or managed by that server. Each 576 user has to identify which conference they want to join, but this 577 information is not necessarily in the SIP messaging. It might be 578 done by having a dedicated address for the conference or via an IVR, 579 as assumed in this example. Each user in this example goes through a 580 two-step process of signaling to gain entry onto their conference 581 call. 583 Session-ID Conference 584 --- Alice Focus Bob Carol 585 | | | | 586 | | | | 587 {A} |----INVITE----->| | | 588 {M1,A} |<---200 OK------| | | 589 {A,M1} |-----ACK------->| | | 590 |<====RTP=======>| | | 591 {M',A} |<---reINVITE----| (to change the | | 592 {A||M'} |-----200 OK---->| UUID to M') | | 593 {M',A} |<-----ACK-------| | | 594 | | | | 595 | | | | 596 {B} | |<----INVITE-----| | 597 {M2,B} | |-----200 OK---->| | 598 {B,M2} | |<-----ACK-------| | 599 | |<=====RTP======>| | 600 {M'||B} | (to change the |----reINVITE--->| | 601 {B||M'} | UUID to M') |<----200 OK-----| | 602 {M'||B} | |------ACK------>| | 603 | | | | 604 | | | | 605 {C} | |<--------------------INVITE-----| 606 {M3,C} | |---------------------200 OK---->| 607 {C,M3} | |<---------------------ACK-------| 608 | |<=====================RTP======>| 609 {M'||C} | (to change the |--------------------reINVITE--->| 610 {C||M'} | UUID to M') |<--------------------200 OK-----| 611 {M'||C} | |----------------------ACK------>| 613 Figure 4 - Single Focus Conference Bridge 615 Operation/Rules: 617 Alice calls into a conference server to attend a certain conference. 618 This is a two-step operation since Alice cannot include the 619 conference ID and any passcode in the INVITE. 621 o Alice sends an INVITE to the conference server with her UUID 622 {A}. 624 o The conference server accepts using a generic, temporary UUID 625 {M1}. 627 o Once Alice, the user, gains access to the IVR for this 628 conference server, she enters a specific conference ID and 629 whatever passcode (if needed) to enter a specific conference 630 call. 632 o Once the conference server is satisfied Alice has identified 633 which conference she wants to attend (including any passcode 634 verification), the conference server reINVITEs Alice to the 635 specific conference and includes the UUID {M'} for that 636 conference. All valid participants in the same conference will 637 receive this same UUID for identification purposes and to better 638 enable monitoring, and tracking functions. 640 o Bob goes through this two-step process of an INVITE transaction, 641 followed by a reINVITE transaction to get this same UUID for 642 that conference. 644 o In this example, Carol (and each additional user) goes through 645 the same procedures and steps as Alice to get on this same 646 conference. 648 9.5. Single Focus Conferencing using WebEx 650 Alice, Bob and Carol call into same Webex conference. 652 Session-ID Conference 653 --- Alice Focus Bob Carol 654 | | | | 655 |<** HTTPS *****>| | | 656 | Transaction | | | 657 | | | | 658 {M} |<----INVITE-----| | | 659 {A||M} |-----200 OK---->| | | 660 {M||A} |<-----ACK-------| | | 661 |<=====RTP======>| | | 662 | | | | 663 | |<** HTTPS *****>| | 664 | | Transaction | | 665 | | | | 666 {M} | |-----INVITE---->| | 667 {B||M} | |<----200 OK-----| | 668 {M||B} | |------ACK------>| | 669 | |<=====RTP======>| | 670 | | | | 671 | |<****************** HTTPS *****>| 672 | | Transaction | 673 | | | | 674 {M} | |--------------------INVITE----->| 675 {C||M} | |<-------------------200 OK------| 676 {M||C} | |---------------------ACK------->| 677 | |<====================RTP=======>| 679 Figure 5 - Single Focus Webex Conference 681 Operation/Rules: 683 o Alice communicates with Webex server with desire to join a 684 certain meeting, by meeting number; also includes UA-Alice's 685 contact information (phone number or URI). 687 o Conference Focus server sends INVITE to UA-Alice to start 688 session with the Session-ID of that server for this A/V 689 conference call. 691 o Bob and Carol perform same function to join this same A/V 692 conference call as Alice. 694 9.6. Cascading Conference Bridge Support for the Session-ID 696 {Editor's note: this section describes some unique behavior. 697 Motivating text needs to be added following working group 698 discussion.} 700 To expand conferencing capabilities requires cascading conference 701 bridges. A conference bridge, or MCU, needs a way to identify itself 702 when contacting another MCU. RFC 4579 [RFC4579] defines the 'isfocus' 703 Contact: header parameter just for this purpose. 705 Cascading MCUs for the purpose of having each use the same UUID (aka 706 half the Session-ID), in its simplest form, is one MCU informing 707 another which UUID to use for joining UAs. 709 Session-ID 710 --- MCU-1 MCU-2 MCU-3 MCU-4 711 | | | | 713 {M'} |----INVITE----->| | | 714 {M'} |<---200 OK------| | | 715 {M'} |-----ACK------->| | | 717 Figure 6 - MCUs Communicating Session-ID UUID for Bridge 719 Regardless of which MCU (1 or 2) a UA contacts for this conference, 720 once the above exchange has been received and acknowledged, the UA 721 will get the same M' UUID from the MCU for the complete Session-ID. 723 A more complex form would be a series of MCUs all being informed of 724 the same UUID to use for a specific conference. This series of MCUs 725 can either be informed 727 o All by one MCU (that initially generates the UUID for the 728 conference), 730 o The one MCU that generates the UUID informs one or several MCUs 731 of this common UUID, and they inform downstream MCUs of this 732 common UUID each will be using for this one conference, or 734 Session-ID 735 --- MCU-1 MCU-2 MCU-3 MCU-4 736 | | | | 737 {M'} |----INVITE----->| | | 738 {M'} |<---200 OK------| | | 739 {M'} |-----ACK------->| | | 740 | | | | 741 {M'} |---------------------INVITE----->| | 742 {M'} |<--------------------200 OK------| | 743 {M'} |----------------------ACK------->| | 744 | | | | 745 {M'} |-------------------------------------INVITE----->| 746 {M'} |<------------------------------------200 OK------| 747 {M'} |--------------------------------------ACK------->| 749 Figure 7 - MCU Communicating Session-ID UUID to More than One 751 Operation/Rules: 753 o The MCU generating the Session-ID UUID communicates this in a 754 separate INVITE, having a Contact header with the 'isfocus' 755 header parameter. This will identify the MCU as what RFC 4579 756 conference-aware SIP entity. 758 o The MCU that is contacted, i.e., the UAS MCU, does not populate 759 or complete the Session-ID header value. The UAS MCU transmits a 760 200 OK response acknowledging it is to respond with this M' UUID 761 to all requests for the designated conference. 763 o An MCU that receives this M' UUID in an inter-MCU transaction, 764 can communicate the M' UUID in a manner in which it was received 765 (though this time this second MCU would be the UAC MCU), unless 766 local policy dictates otherwise. 768 9.7. Basic 3PCC for two UAs 770 External entity sets up call to both Alice and Bob for them to talk 771 to each other. 773 Session-ID 774 --- Alice B2BUA Bob Carol 775 | | | 776 {X} |<----INVITE-----| | 777 {A,X} |-----200 OK---->| | 778 {A} | |----INVITE----->| 779 {B,A} | |<---200 OK------| 780 {A,B} |<-----ACK-------| | 781 {A,B} | |------ACK------>| 782 |<==============RTP==============>| 784 Figure 8 - 3PCC initiated call between Alice and Bob 786 Operation/Rules: 788 o Some out of band procedure directs a B2BUA (or other SIP server) 789 to have Alice and Bob talk to each other. 791 o The SIP server INVITEs Alice to a session and uses a temporary 792 UUID {X}. 794 o Alice receives and accepts this call set-up and includes her 795 UUID {A} in the Session-ID, now {A,X}. 797 o The SIP server uses Alice's UUID {A}, and discards its own {X} 798 to INVITE Bob to the session as if this came from Alice 799 originally. 801 o Bob receives and accepts this INVITE and adds his own UUID {B} 802 to the Session-ID, now {B,A} for the response. 804 o And the session is established. 806 10. Compatibility with a Previous Implementation 808 There is a much earlier and proprietary document that specifies the 809 use of a Session-ID header that we will herewith attempt to achieve 810 backwards compatibility. Neither Session-ID has any versioning 811 information, so merely adding that this document describes "version 812 2" is insufficient. Here are the set of rules for compatibility 813 between the two specifications. For the purposes of this discussion, 814 we will label the proprietary specification of the Session-ID as the 815 "old" version and this specification as the "new" version of the 816 Session-ID. 818 The previous (i.e., "old") version only has a single value as a 819 Session-ID, but has a generic-parameter value that can be of use. 821 In order to have an "old" version talk to an "old" version 822 implementation, nothing needs to be done as far as the IETF is 823 concerned. 825 In order to have a "new" version talk to a "new" version 826 implementation, both implementations need to following this document 827 (to the letter) and everything should be just fine. 829 In order to have an "old" version talk to a "new" version 830 implementation, several aspects need to be looked at. They are: 832 o The "old" version UA will include a single UUID as its Session- 833 ID. 835 o The "new" version UA will respond by including a complete 836 Session-ID with two UUIDs, with the "new" version's UUID listed 837 first (because it cannot know it is talking with an "old" 838 version implementation at this point). 840 o The "old" version UA will have to ignore the first UUID, and 841 consider its singular "old" UUID as valid, as long as the value 842 does not change.. 844 o During subsequent transactions within this session, the "new" 845 version may receive SIP requests without its UUID, but with the 846 "old" version's UUID. The "new" version UA MUST add its UUID to 847 the received Session-ID. The "old" version implementation will 848 merely disregard it each time it receives this "new" version 849 UUID (if it was not the first UUID). 851 In order to have a "new" version talk to an "old" Version 852 implementation, several aspects need to be looked at. They are: 854 o The "new" version UA will include a single UUID as its initial 855 Session-ID header always, not knowing which version of UA it is 856 communicating with. 858 o The "old" version UA will respond by seeing the UUID as a valid 859 and complete Session-ID and not include another UUID or generic- 860 param. Thus, the 200 OK will not include any Session-ID part of 861 its own from the "old" version implementation. 863 Rule: implementation supporting a "new" version of the Session-ID 864 MUST NOT error or otherwise reject receiving only its own UUID 865 back in any transaction. It MUST interpret this response to mean 866 that it is communicating with an "old" Session-ID 867 implementation. 869 o Open question - how do we want all intermediaries and/or 870 monitoring systems to interpret this single UUID complete 871 Session-ID? 873 11. Security Considerations 875 When creating a UUID value, endpoints SHOULD ensure that there is no 876 user or device-identifying information contained within the UUID. In 877 some environments, though, use of a MAC address, which is one option 878 when constructing a UUID, may be desirable, especially in some 879 enterprise environments. When communicating over the Internet, 880 though, the UUID value MUST utilize random values. 882 The Session-ID might be utilized for logging or troubleshooting, but 883 MUST NOT be used for billing purposes. { Why does this matter? } 885 Other considerations??? 887 12. IANA Considerations 889 12.1. Registration of the "Session-ID" Header Field 891 The following is the registration for the 'Session-ID' header field 892 to the "Header Name" registry at http://www.iana.org/assignments/sip- 893 parameters: 895 RFC number: RFC XXXX 897 Header name: 'Session-ID' 899 Compact form: none 901 [RFC Editor: Please replace XXXX in this section and the next with 902 the this RFC number of this document.] 904 12.2. Registration of the "remote" Parameter 906 The following parameter is to be added to the "Header Field 907 Parameters and Parameter Values" section of the SIP parameter 908 registry: 910 +------------------+----------------+-------------------+-----------+ 911 | Header Field | Parameter Name | Predefined Values | Reference | 912 +------------------+----------------+-------------------+-----------+ 913 | Session-ID | remote | No | [RFCXXXX] | 914 +------------------+----------------+-------------------+-----------+ 916 13. Acknowledgments 918 The authors would like to than Robert Sparks, Hadriel Kaplan, 919 Christer Holmberg, and Paul Kyzivat for their invaluable comments 920 during the development of this document. 922 14. References 924 14.1. Normative References 926 [RFC3261] Rosenberg, J., et al., "SIP: Session Initiation 927 Protocol", RFC 3261, June 2002. 929 [H.323] Recommendation ITU-T H.323, "Packet-based multimedia 930 communications systems", December 2009. 932 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 933 Requirement Levels", BCP 14, RFC 2119, March 1997. 935 [RFC4122] Leach, P., Mealling, M., Salz, R., "A Universally Unique 936 IDentifier (UUID) URN Namespace", RFC 4122, July 2005. 938 [RFC5234] Crocker, D., Overell, P, "Augmented BNF for Syntax 939 Specifications: ABNF", RFC 5234, January 2008. 941 [RFC4579] Johnston, A., Levin, O., "Session Initiation Protocol 942 (SIP) Call Control - Conferencing for User Agents", RFC 943 4579, August 2006. 945 [RFC3891] Mahy, R., Biggs, B., Dean, R., 'The Session Initiation 946 Protocol (SIP) "Replaces" Header', RFC 3891, September 947 2004. 949 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 950 Method", RFC 3515, April 2003. 952 14.2. Informative References 954 [RFC3550] Schulzrinne, H., et al., "RTP: A Transport Protocol for 955 Real-Time Applications", RFC 3550, July 2003. 957 [I-D.ietf-insipid-session-id-reqts] 958 Jones, et al., "Requirements for an End-to-End Session 959 Identification in IP-Based Multimedia Communication 960 Networks", draft-ietf-insipid-session-id-reqts-07, June 961 2013. 963 Author's Addresses 965 Paul E. Jones 966 Cisco Systems, Inc. 967 7025 Kit Creek Rd. 968 Research Triangle Park, NC 27709 969 USA 971 Phone: +1 919 476 2048 972 Email: paulej@packetizer.com 973 IM: xmpp:paulej@packetizer.com 975 Chris Pearce 976 Cisco Systems, Inc. 977 2300 East President George Bush Highway 978 Richardson, TX 75082 979 USA 981 Phone: +1 972 813 5123 982 Email: chrep@cisco.com 983 IM: xmpp:chrep@cisco.com 985 James Polk 986 Cisco Systems, Inc. 987 3913 Treemont Circle 988 Colleyville, Texas 989 USA 991 Phone: +1 817 271 3552 992 Email: jmpolk@cisco.com 993 IM: xmpp:jmpolk@cisco.com 995 Gonzalo Salgueiro 996 Cisco Systems, Inc. 997 7025 Kit Creek Rd. 998 Research Triangle Park, NC 27709 999 USA 1001 Phone: +1 919 392 3266 1002 Email: gsalguei@cisco.com 1003 IM: xmpp:gsalguei@cisco.com