idnits 2.17.1 draft-jones-insipid-session-id-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 20, 2013) is 4080 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0-9a-f' on line 204 -- Looks like a reference, but probably isn't: 'RFC3515' on line 438 == Unused Reference: '7' is defined on line 863, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 866, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-03) exists of draft-jones-insipid-session-id-reqts-02 Summary: 0 errors (**), 0 flaws (~~), 4 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 C. Pearce 4 Intended status: Standards Track J. Polk 5 Expires: August 20, 2013 G. Salgueiro 6 Cisco Systems 7 February 20, 2013 9 End-to-End Session Identification in IP-Based Multimedia 10 Communication Networks 11 draft-jones-insipid-session-id-02.txt 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 August 20, 2013. 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. 58 Table of Contents 60 1. Introduction...................................................2 61 2. Conventions used in this document..............................3 62 3. Session Identifier Requirements and Use Cases..................3 63 4. Constructing the Session Identifier............................3 64 5. Transmitting the Session Identifier in SIP.....................4 65 6. Endpoint Behavior..............................................5 66 7. Processing by Intermediaries...................................6 67 8. Associating Endpoints in a Multipoint Conference...............7 68 9. Various Call Flow Operations Utilizing the Session ID..........7 69 9.1. Basic Session-ID Construction with 2 UUIDs................8 70 9.2. Basic Call Transfer using REFER...........................9 71 9.3. Basic Call Transfer using reINVITE.......................10 72 9.4. Single Focus Conferencing................................11 73 9.5. Single Focus Conferencing using WebEx....................13 74 9.6. Cascading Conference Bridge Support for the Session-ID...14 75 9.7. Basic 3PCC for two UAs...................................15 76 10. Compatibility with a Previous Implementation.................16 77 11. Security Considerations......................................17 78 12. IANA Considerations..........................................17 79 13. Acknowledgments..............................................18 80 14. References...................................................18 81 14.1. Normative References....................................18 82 Author's Addresses...............................................19 84 1. Introduction 86 IP-based multimedia communication systems like SIP [1] and H.323 [2] 87 have the concept of a "call identifier" that is globally unique. The 88 identifier is intended to represent an end-to-end communication 89 session from the originating device to the terminating device. Such 90 an identifier is useful for troubleshooting, session tracking, and so 91 forth. 93 Unfortunately, there are a number of factors that contribute to the 94 fact that the current call identifiers defined in SIP and H.323 are 95 not suitable for end-to-end session identification. A fundamental 96 issue in protocol interworking is the fact that the syntax for the 97 call identifier in SIP and H.323 is different between the two 98 protocols. This important fact makes it impossible for call 99 identifiers to be exchanged end-to-end when a network utilizes one or 100 more session protocols. 102 Another reason why the current call identifiers are not suitable to 103 identify the session end-to-end is that in real-world deployments 104 devices like session border controllers often change the session 105 signaling as it passes through the device, including the value of the 106 call identifier. While this is deliberate and useful, it makes it 107 very difficult to track sessions end-to-end. 109 This draft presents a new identifier, referred to as the Session 110 Identifier, or "Session ID", and associated syntax intended to 111 overcome the issues that exist with the currently defined call 112 identifiers. The proposal in this document attempts to comply with 113 the requirements specified in Error! Reference source not found.. 114 This proposal also has capabilities not mentioned in [5], shown in 115 call flows in section 10. Additionally, this proposal attempts to 116 account for a previous, proprietary version of a SIP Session ID 117 header, proposing a backwards compatibility of sorts, described in 118 section 11. 120 2. Conventions used in this document 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [3] when they 125 appear in ALL CAPS. These words may also appear in this document in 126 lower case as plain English words, absent their normative meanings. 128 3. Session Identifier Requirements and Use Cases 130 Requirements and Use Cases for the end-to-end Session Identifier can 131 be found in a separate memo titled "Requirements for an End-to-End 132 Session Identification in IP-Based Multimedia Communication Networks" 133 Error! Reference source not found.. 135 4. Constructing the Session Identifier 137 The Session Identifier is comprised of two RFC 4122 defined UUIDs 138 [4], with each UUID representing one of the endpoints participating 139 in the session. The SIP user agent (UA) initially transmitting the 140 SIP request will create a UUID and transmit that to the ultimate 141 destination UA. Likewise, the responding UA will create a UUID and 142 transmit that to the first UA. These two distinct UUIDs form what is 143 referred to as the Session Identifier and is represented in this 144 document in set notation of the form {A,B}, where A is UUID value 145 from the UA transmitting a message and B is the UUID value from the 146 intended recipient of the message, i.e., not an intermediary server 147 along the signaling path. The set {A,B} is equal to the set {B,A}, 148 and thus both represent the same Session Identifier. 150 In the case where only one UUID is known, such as when a UA first 151 initiates a SIP request, the Session ID would be {A}, where "A" 152 represents the single UUID value transmitted. 154 Since SIP sessions are subject to any number of service interactions, 155 SIP INVITE messages might be forked as sessions are established, and 156 since conferences might be established or expanded with endpoints 157 calling in or the conference focus calling out, the construction of 158 the Session Identifier from a set of UUIDs is important. 160 To understand this better, consider that a UA participating in a 161 communication session might be replaced with another, such as the 162 case where two "legs" of a call are joined together by a PBX. 163 Suppose that UA A and UA B both call UA C. Further suppose that UA C 164 uses a local PBX function to join the call between itself and UA A 165 with the call between itself and UA B. This merged call needs to be 166 identified and identification of such sessions is natural and easily 167 traceable when utilizing UUID values assigned by each entity in the 168 communication session. 170 In the case of forking, UA A might send an INVITE that gets forked to 171 five different UAs, as an example. Until one UA returns a 200 OK to 172 the initial INVITE, a means of identifying each of these separate 173 communication sessions is needed and allowing the set of {A, B1}, {A, 174 B2}, {A, B3}, {A, B4}, and {A, B5} makes this possible. 176 For conferencing scenarios, it is also useful to have a two-part 177 Session-ID where the conference focus specifies one UUID. This might 178 allow for correlation among the participants in a single conference, 179 for example. 181 How a device acting on Session Identifiers stores, processes, or 182 utilizes the Session Identifier is outside the scope of this 183 document. 185 5. Transmitting the Session Identifier in SIP 187 Each session initiated or accepted MUST have a local UA-generated 188 UUID associated with the session. This value MUST remain unchanged 189 throughout the duration of that session. 191 A SIP UA MUST convey its Session Identifier UUID in all transmitted 192 messages within the same session. To do this, each transmitted 193 message MUST include the "Session-ID" header. The Session-ID header 194 has the following ABNF [5] syntax: 196 session-id = "Session-ID" HCOLON local-uuid 198 *(SEMI sess-id-param) 200 local-uuid = sess-uuid 202 remote-uuid = sess-uuid 204 sess-uuid = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] 206 sess-id-param = remote-param / generic-param 208 remote-param = "remote" EQUAL remote-uuid 210 The productions "SEMI", "EQUAL", and "generic-param" production is 211 defined in RFC 3261. The production DIGIT is defined in RFC 5234. 213 The Session-ID header MUST NOT have more than one "remote" parameter. 215 The "local-uuid" in the Session-ID header represents the UUID value 216 of the UA transmitting the message. If the UA transmitting the 217 message previously received a UUID value from its peer endpoint, it 218 MUST include that UUID as the "remote" parameter. For example, using 219 the UUID values from the previous section, a Session-ID header might 220 appear like this: 222 Session-ID: aeffa652b22911dfa81f12313a006823; 223 remote=be11afc8b22911df86c412313a006823 225 The UUID values are presented as strings of lower-case hexadecimal 226 characters, with the most significant byte of the UUID appearing 227 first. 229 6. Endpoint Behavior 231 To comply with this specification, SIP UAs MUST include a Session-ID 232 header-value in all messages transmitted as a part of a communication 233 session. 235 A non-intermediary UAS that receives a Session-ID header MUST take 236 note of the first UUID value that it receives in the Session-ID 237 header and assume that that is the UUID of the peer endpoint within 238 that communications session. UAs MUST include this received UUID 239 value as the "remote" parameter when transmitting subsequent 240 messages. 242 It should be noted that messages received by a UA might contain a 243 "remote" parameter that does match the UAs UUID. This might happen 244 as a result of service interactions by intermediaries and MUST NOT be 245 regarded as an error. 247 For any purpose the UA has for the Session-ID, it MUST assume that 248 the Session-ID is {A,B} where "A" is the UUID value of this endpoint 249 and "B" is the UUID value of the peer endpoint, taken from the most 250 recently received message within this session. 252 An endpoint MUST assume that the UUID value of the peer UA MAY change 253 at any time due to service interactions. However, once an UA 254 allocates a UUID value for a communication session, the UA MUST NOT 255 change that UUID value for the duration of the session, including 256 when communication attempts are retried due to receipt of 4xx 257 messages, when the session is redirected in response to a 3xx 258 message, or when a session is transferred via a REFER message [6]. 260 It is also important to note that if a session is forked by an 261 intermediary in the network, the initiating UA may receive multiple 262 responses back from different endpoints, each of which will contain a 263 different UUID value. UAs MUST take care to ensure that the correct 264 UUID value is returned in the "remote" parameter when responding to 265 those endpoints. 267 7. Processing by Intermediaries 269 Intermediaries that wish to utilize the Session-ID MAY extract the 270 UUID header-values from any SIP message. Alternatively, 271 intermediaries MAY observe the first UUID value in the Session-ID 272 header for messages sent in each direction and use those values to 273 locally construct the Session Identifier. 275 Intermediaries MUST NOT alter the UUID values found in the Session-ID 276 header, except as described in this section. 278 Intermediary devices that transfer a call, such as by joining 279 together two different "call legs", MUST properly construct a 280 Session-ID header that contains the correct UUID values and correct 281 placement of those values. As described above, the recipient of any 282 message initiated by the intermediary will assume that the first UUID 283 value belongs to the peer endpoint. 285 If a SIP message having no Session-ID header is received by an 286 intermediary, the intermediary MAY assign a "local-uuid" value to 287 represent the sending endpoint and insert that value into all 288 signaling messages on behalf of the sending endpoint. If the 289 intermediary is aware of a "remote" value that identifies the 290 receiving UA, it MUST insert that value if also inserting the "local- 291 uuid" value. 293 Devices that initiate communication sessions following the procedures 294 for third party call control MUST fabricate a UUID value that will be 295 utilized only temporarily. Once the responding endpoint provides a 296 UUID value in a response message, the temporary value MUST be 297 discarded and replaced with the endpoint-provided UUID value. Refer 298 to the third-party call control example for an illustration. 300 Whenever there is a UA that does not implement this specification 301 communicating through a B2BUA, the B2BUA MAY become dialog stateful 302 and insert a UUID value into the Session-ID header on behalf of the 303 UA according to the rules stated in Section 6. 305 8. Associating Endpoints in a Multipoint Conference 307 Multipoint Control Units (MCUs) group two or more sessions into a 308 single multipoint conference. The MCU should utilize the same UUID 309 value for each session that is grouped into the same conference. In 310 so doing, each individual session in the conference will have a 311 unique Session Identifier (since each endpoint will create a unique 312 UUID of its own), but will also have one UUID in common with all 313 other participants in the conference. 315 Intermediary devices, such as proxies or session border controllers, 316 or network diagnostics equipment might assume that when they see two 317 or more sessions with different Session Identifiers, but with one 318 UUID in common, that the sessions are part of the same conference. 320 Note, however, that this assumption of being part of the same 321 conference is not always true. For example, in a SIP forking 322 scenario, there might also be what appears to be multiple sessions 323 with a shared UUID value. This is actually desirable. What is 324 desired is to allow for the association of related sessions. Whether 325 sessions are related because of forking or because endpoints are 326 communicating as a part of a conference does not matter. They are 327 nonetheless related. 329 9. Various Call Flow Operations Utilizing the Session ID 331 Seeing something frequently makes understanding easier. With that in 332 mind, we include several call flows with the initial UUID and the 333 complete Session-ID indicated per message, as well as when the 334 Session-ID changes according to the rules within this document during 335 certain operations/functions. 337 9.1. Basic Session-ID Construction with 2 UUIDs 339 Session-ID 340 --- Alice B2BUA Bob Carol 341 {A} |----INVITE----->| | 342 {A} | |----INVITE----->| 343 {B,A} | |<---200 OK------| 344 {B,A} |<---200 OK------| | 345 {A,B} |------ACK------>| | 346 {A,B} | |------ACK------>| 347 |<==============RTP==============>| 349 Figure 1 - Session-ID Creation when Alice calls Bob 351 Operation/Rules: 353 o Transmitter of SIP message places its Session-ID UUID first in 354 order; 356 o UA-Alice sends its UUID in INVITE; 358 o B2BUA receives an INVITE with a Session-ID header-value from UA- 359 Alice, and transmits INVITE towards UA-Bob with an unchanged 360 Session-ID header-value; 362 o UA-Bob receives Session-ID and adds its UUID to construct the 363 whole/complete Session-ID header-value in the 200 OK; 365 o UA-Bob orders the UUIDs such that its UUID is first when UA-Bob 366 is transmitting the SIP message; 368 o B2BUA receives the 200 OK response with a complete Session-ID 369 header-value from UA-Bob, and transmits 200 OK towards UA-Alice 370 with an unchanged Session-ID header-value; while maintaining the 371 order of UUIDs in the Session-ID header-value; 373 o UA-Alice, upon reception of the 200 OK from the B2BUA, transmits 374 the ACK towards the B2BUA with its UUID positioned first, and 375 the UUID from UA-Bob positioned second in the Session-ID header- 376 value. 378 o B2BUA receives the ACK with a complete Session-ID header-value 379 from UA-Alice, and transmits ACK towards UA-Bob with an 380 unchanged Session-ID header-value; while maintaining the order 381 of UUIDs in the Session-ID header-value; 383 9.2. Basic Call Transfer using REFER 385 From the example built within Section 9.1 (the basic session-ID 386 establishment), we proceed to this 'Basic Call Transfer using REFER' 387 example. 389 Session-ID 390 --- Alice B2BUA Bob Carol 391 | | | | 392 |<==============RTP==============>| | 393 {B,A} | |<---reINVITE----| | 394 {B,A} |<---reINVITE----| (puts Alice on Hold) | 395 {A,B} |-----200 OK---->| | | 396 {A,B} | |-----200 OK---->| | 397 {B,A} | |<-----ACK-------| | 398 {B,A} |<-----ACK-------| | | 399 | | | | 400 {B,A} | |<----REFER------| | 401 {B,A} |<----REFER------| | | 402 {A,B} |-----200 OK---->| | | 403 {A,B} | |-----200 OK---->| | 404 {B,A} | |<-----ACK-------| | 405 {B,A} |<-----ACK-------| | | 406 {A,B} |-----NOTIFY---->| | | 407 {A,B} | |-----NOTIFY---->| | 408 {B,A} | |<----200 OK-----| | 409 {B,A} |<----200 OK-----| | | 410 | | | | 411 {A} |-----INVITE---->| | 412 {A} | |-----INVITE-------------------->| 413 {C,A} | |<----200 OK---------------------| 414 {C,A} |<----200 OK-----| | 415 {A,C} |------ACK------>| | 416 {A,C} | |------ACK---------------------->| 417 | | | | 418 |<======================RTP======================>| 419 | | | | 420 {A,B} |-----NOTIFY---->| | | 421 {A,B} | |-----NOTIFY---->| | 422 {B,A} | |<----200 OK-----| | 423 {B,A} |<----200 OK-----| | | 424 {B,A} | |<-----BYE-------| | 425 {B,A} |<-----BYE-------| | | 426 {A,B} |-----200 OK---->| | | 427 {A,B} | |-----200 OK---->| | 428 | | | | 430 Figure 2 - Call Transfer using REFER 432 Operation/Rules: 434 Starting from the existing Alice/Bob call described in Figure 1, 435 which established an existing Session-ID header-value... 437 o UA-Bob reINVITEs Alice to call Carol, using a REFER transaction, 438 as described in [RFC3515]. UA-Alice is initially put on hold, 439 then told in the REFER who to contact with a new INVITE, in this 440 case UA-Carol. 442 o UA-Alice retains her UUID from the Alice-to-Bob call {A} when 443 requesting a call with UA-Carol. This same UUID traverses the 444 B2BUA unchanged. 446 o UA-Carol receives the INVITE with a Session-ID UUID {A}, creates 447 its own UUID {C}, and combines them to form a full Session-ID 448 {C,A} in the 200 OK to the INVITE. This Session-ID header-value 449 traverses the B2BUA unchanged towards UA-Alice. 451 o UA-Alice receives the 200 OK with the Session-ID {C,A} and both 452 responses to UA-Carol with an ACK, generates a NOTIFY to Bob 453 with a Session-ID {A,B} indicating the call transfer was 454 successful. 456 o It does not matter which UA terminates the Alice-to-Bob call; 457 Figure 2 shows UA-Bob doing this transaction. 459 9.3. Basic Call Transfer using reINVITE 461 From the example built within Section 9.1 (the basic session-ID 462 establishment), we proceed to this 'Basic Call Transfer using 463 reINVITE' example. 465 Alice is talking to Bob. Bob pushes a button on his phone to transfer 466 Alice to Carol via the B2BUA (using reINVITE). 468 Session-ID 469 --- Alice B2BUA Bob Carol 470 | | | | 471 |<==============RTP==============>| | 472 | | | | 473 {B,A} | |<---reINVITE----| | 474 {A,B} | |-----200 OK---->| | 475 {B,A} | |<-----ACK-------| | 476 | | | | 477 {A} | |-----INVITE-------------------->| 478 {C,A} | |<----200 OK---------------------| 479 {A,C} | |------ACK---------------------->| 480 | | | | 481 |<======================RTP======================>| 482 | | | | 483 {B,A} | |<-----BYE-------| | 484 {B,A} |<-----BYE-------| | | 485 {A,B} |-----200 OK---->| | | 486 {A,B} | |-----200 OK---->| | 487 | | | | 489 Figure 3 - Call transfer using reINVITE 491 Operation/Rules: 493 o We assume the call between Alice and Bob from Section 9.1 is 494 operational with Session-ID {A,B}. 496 o Bob sends a reINVITE to Alice to transfer her to Carol. 498 o The B2BUA intercepts this reINVITE and sends a new INVITE with 499 Alice's UUID {A} to Carol. 501 o Carol receives the INVITE and accepts the request and adds her 502 UUID {C} to the Session-ID for this session {C,A}. 504 o Bob terminates the call (which Alice could too) with a BYE using 505 their Session-ID {B,A}. 507 9.4. Single Focus Conferencing 509 Multiple users call into a conference server (say, an MCU) to attend 510 one of many conferences hosted on or managed by that server. Each 511 user has to identify which conference they want to join, but this 512 information is not necessarily in the SIP messaging. It might be 513 done by having a dedicated address for the conference or via an IVR, 514 as assumed in this example. Each user in this example goes through a 515 two-step process of signaling to gain entry onto their conference 516 call. 518 Session-ID Conference 519 --- Alice Focus Bob Carol 520 | | | | 521 | | | | 522 {A} |----INVITE----->| | | 523 {M1,A} |<---200 OK------| | | 524 {A,M1} |-----ACK------->| | | 525 |<====RTP=======>| | | 526 {M',A} |<---reINVITE----| (to change the | | 527 {A||M'} |-----200 OK---->| UUID to M') | | 528 {M',A} |<-----ACK-------| | | 529 | | | | 530 | | | | 531 {B} | |<----INVITE-----| | 532 {M2,B} | |-----200 OK---->| | 533 {B,M2} | |<-----ACK-------| | 534 | |<=====RTP======>| | 535 {M'||B} | (to change the |----reINVITE--->| | 536 {B||M'} | UUID to M') |<----200 OK-----| | 537 {M'||B} | |------ACK------>| | 538 | | | | 539 | | | | 540 {C} | |<--------------------INVITE-----| 541 {M3,C} | |---------------------200 OK---->| 542 {C,M3} | |<---------------------ACK-------| 543 | |<=====================RTP======>| 544 {M'||C} | (to change the |--------------------reINVITE--->| 545 {C||M'} | UUID to M') |<--------------------200 OK-----| 546 {M'||C} | |----------------------ACK------>| 548 Figure 4 - Single Focus Conference Bridge 550 Operation/Rules: 552 Alice calls into a conference server to attend a certain conference. 553 This is a two-step operation since Alice cannot include the 554 conference ID and any passcode in the INVITE. 556 o Alice sends an INVITE to the conference server with her UUID 557 {A}. 559 o The conference server accepts using a generic, temporary UUID 560 {M1}. 562 o Once Alice, the user, gains access to the IVR for this 563 conference server, she enters a specific conference ID and 564 whatever passcode (if needed) to enter a specific conference 565 call. 567 o Once the conference server is satisfied Alice has identified 568 which conference she wants to attend (including any passcode 569 verification), the conference server reINVITEs Alice to the 570 specific conference and includes the UUID {M'} for that 571 conference. All valid participants in the same conference will 572 receive this same UUID for identification purposes and to better 573 enable monitoring, and tracking functions. 575 o Bob goes through this two-step process of an INVITE transaction, 576 followed by a reINVITE transaction to get this same UUID for 577 that conference. 579 o In this example, Carol (and each additional user) goes through 580 the same procedures and steps as Alice to get on this same 581 conference. 583 9.5. Single Focus Conferencing using WebEx 585 Alice, Bob and Carol call into same Webex conference. 587 Session-ID Conference 588 --- Alice Focus Bob Carol 589 | | | | 590 |<*** HTTPS ****>| | | 591 | Transaction | | | 592 | | | | 593 {M} |<----INVITE-----| | | 594 {A||M} |-----200 OK---->| | | 595 {M||A} |<-----ACK-------| | | 596 |<=====RTP======>| | | 597 | | | | 598 | |<** HTTPS *****>| | 599 | | Transaction | | 600 | | | | 601 {M} | |-----INVITE---->| | 602 {B||M} | |<----200 OK-----| | 603 {M||B} | |------ACK------>| | 604 | |<=====RTP======>| | 605 | | | | 606 | |<******************** HTTPS ***>| 607 | | Transaction | 608 | | | | 609 {M} | |--------------------INVITE----->| 610 {C||M} | |<-------------------200 OK------| 611 {M||C} | |---------------------ACK------->| 612 | |<====================RTP=======>| 614 Figure 5 - Single Focus Webex Conference 616 Operation/Rules: 618 o Alice communicates with Webex server with desire to join a 619 certain meeting, by meeting number; also includes UA-Alice's 620 contact information (phone number or URI). 622 o Conference Focus server sends INVITE to UA-Alice to start 623 session with the Session-ID of that server for this A/V 624 conference call. 626 o Bob and Carol perform same function to join this same A/V 627 conference call as Alice. 629 9.6. Cascading Conference Bridge Support for the Session-ID 631 To expand conferencing capabilities requires cascading conference 632 bridges. A conference bridge, or MCU, needs a way to identify itself 633 when contacting another MCU. RFC 4579 [6] defines the 'isfocus' 634 Contact: header parameter just for this purpose. 636 Cascading MCUs for the purpose of having each use the same UUID (aka 637 half the Session-ID), in its simplest form, is one MCU informing 638 another which UUID to use for joining UAs. 640 Session-ID 641 --- MCU-1 MCU-2 MCU-3 MCU-4 642 | | | | 643 {M'} |----INVITE----->| | | 644 {M'} |<---200 OK------| | | 645 {M'} |-----ACK------->| | | 647 Figure 6 - MCUs Communicating Session-ID UUID for Bridge 649 Regardless of which MCU (1 or 2) a UA contacts for this conference, 650 once the above exchange has been received and acknowledged, the UA 651 will get the same M' UUID from the MCU for the complete Session-ID. 653 A more complex form would be a series of MCUs all being informed of 654 the same UUID to use for a specific conference. This series of MCUs 655 can either be informed 657 o All by one MCU (that initially generates the UUID for the 658 conference), 660 o The one MCU that generates the UUID informs one or several MCUs 661 of this common UUID, and they inform downstream MCUs of this 662 common UUID each will be using for this one conference, or 664 Session-ID 665 --- MCU-1 MCU-2 MCU-3 MCU-4 666 | | | | 667 {M'} |----INVITE----->| | | 668 {M'} |<---200 OK------| | | 669 {M'} |-----ACK------->| | | 670 | | | | 671 {M'} |---------------------INVITE----->| | 672 {M'} |<--------------------200 OK------| | 673 {M'} |----------------------ACK------->| | 674 | | | | 675 {M'} |-------------------------------------INVITE----->| 676 {M'} |<------------------------------------200 OK------| 677 {M'} |--------------------------------------ACK------->| 679 Figure 7 - MCU Communicating Session-ID UUID to More than One 681 Operation/Rules: 683 o The MCU generating the Session-ID UUID communicates this in a 684 separate INVITE, having a Contact header with the 'isfocus' 685 header parameter. This will identify the MCU as what RFC 4579 686 conference-aware SIP entity. 688 o The MCU that is contacted, i.e., the UAS MCU, does not populate 689 or complete the Session-ID header value. The UAS MCU transmits a 690 200 OK response acknowledging it is to respond with this M' UUID 691 to all requests for the designated conference. 693 o An MCU that receives this M' UUID in an inter-MCU transaction, 694 can communicate the M' UUID in a manner in which it was received 695 (though this time this second MCU would be the UAC MCU), unless 696 local policy dictates otherwise. 698 9.7. Basic 3PCC for two UAs 700 External entity sets up call to both Alice and Bob for them to talk 701 to each other. 703 Session-ID 704 --- Alice B2BUA Bob Carol 705 | | | 706 {X} |<----INVITE-----| | 707 {A,X} |-----200 OK---->| | 708 {A} | |----INVITE----->| 709 {B,A} | |<---200 OK------| 710 {A,B} |<-----ACK-------| | 711 {A,B} | |------ACK------>| 712 |<==============RTP==============>| 714 Figure 8 - 3PCC initiated call between Alice and Bob 716 Operation/Rules: 718 o Some out of band procedure directs a B2BUA (or other SIP server) 719 to have Alice and Bob talk to each other. 721 o The SIP server INVITEs Alice to a session and uses a temporary 722 UUID {X}. 724 o Alice receives and accepts this call set-up and includes her 725 UUID {A} in the Session-ID, now {A,X}. 727 o The SIP server uses Alice's UUID {A}, and discards its own {X} 728 to INVITE Bob to the session as if this came from Alice 729 originally. 731 o Bob receives and accepts this INVITE and adds his own UUID {B} 732 to the Session-ID, now {B,A} for the response. 734 o And the session is established. 736 10. Compatibility with a Previous Implementation 738 There is a much earlier and proprietary document that specifies the 739 use of a Session-ID header that we will herewith attempt to achieve 740 backwards compatibility. Neither Session-ID has any versioning 741 information, so merely adding that this document describes "version 742 2" is insufficient. Here are the set of rules for compatibility 743 between the two specifications. For the purposes of this discussion, 744 we will label the proprietary specification of the Session-ID as the 745 "old" version and this specification as the "new" version of the 746 Session-ID. 748 The previous (i.e., "old") version only has a single value as a 749 Session-ID, but has a generic-parameter value that can be of use. 751 In order to have an "old" version talk to an "old" version 752 implementation, nothing needs to be done as far as the IETF is 753 concerned. 755 In order to have a "new" version talk to a "new" version 756 implementation, both implementations need to following this document 757 (to the letter) and everything should be just fine. 759 In order to have an "old" version talk to a "new" version 760 implementation, several aspects need to be looked at. They are: 762 o The "old" version UA will include a single UUID as its Session- 763 ID. 765 o The "new" version UA will respond by including a complete 766 Session-ID with two UUIDs, with the "new" version's UUID listed 767 first (because it cannot know it is talking with an "old" 768 version implementation at this point). 770 o The "old" version UA will have to ignore the first UUID, and 771 consider its singular "old" UUID as valid, as long as the value 772 does not change.. 774 o During subsequent transactions within this session, the "new" 775 version may receive SIP requests without its UUID, but with the 776 "old" version's UUID. The "new" version UA MUST add its UUID to 777 the received Session-ID. The "old" version implementation will 778 merely disregard it each time it receives this "new" version 779 UUID (if it was not the first UUID). 781 In order to have a "new" version talk to an "old" Version 782 implementation, several aspects need to be looked at. They are: 784 o The "new" version UA will include a single UUID as its initial 785 Session-ID header always, not knowing which version of UA it is 786 communicating with. 788 o The "old" version UA will respond by seeing the UUID as a valid 789 and complete Session-ID and not include another UUID or generic- 790 param. Thus, the 200 OK will not include any Session-ID part of 791 its own from the "old" version implementation. 793 Rule: implementation supporting a "new" version of the Session-ID 794 MUST NOT error or otherwise reject receiving only its own UUID 795 back in any transaction. It MUST interpret this response to mean 796 that it is communicating with an "old" Session-ID 797 implementation. 799 o Open question - how do we want all intermediaries and/or 800 monitoring systems to interpret this single UUID complete 801 Session-ID? 803 11. Security Considerations 805 When creating a UUID value, endpoints SHOULD ensure that there is no 806 user or device-identifying information contained within the UUID. In 807 some environments, though, use of a MAC address, which is one option 808 when constructing a UUID, may be desirable, especially in some 809 enterprise environments. When communicating over the Internet, 810 though, the UUID value MUST utilize random values. 812 The Session-ID might be utilized for logging or troubleshooting, but 813 MUST NOT be used for billing purposes. { Why does this matter? } 815 Other considerations??? 817 12. IANA Considerations 819 The following is the registration for the 'Session-ID' header field 820 to the "Header Name" registry at http://www.iana.org/assignments/sip- 821 parameters: 823 RFC number: [this document] 824 Header name: 'Session-ID' 826 Compact form: none 828 13. Acknowledgments 830 The authors would like to than Hadriel Kaplan, Christer Holmberg, and 831 Paul Kyzivat for their invaluable comments during the development of 832 this document. 834 This document was prepared using 2-Word-v2.0.template.dot. 836 14. References 838 14.1. Normative References 840 [1] Rosenberg, J., et al., "SIP: Session Initiation Protocol", RFC 841 3261, June 2002. 843 [2] Recommendation ITU-T H.323, "Packet-based multimedia 844 communications systems", December 2009. 846 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 847 Levels", BCP 14, RFC 2119, March 1997. 849 [4] Leach, P., Mealling, M., Salz, R., "A Universally Unique 850 IDentifier (UUID) URN Namespace", RFC 4122, July 2005. 852 [5] Crocker, D., Overell, P, "Augmented BNF for Syntax 853 Specifications: ABNF", RFC 5234, January 2008. 855 [6] A. Johnston, O. Levin, "Session Initiation Protocol (SIP) Call 856 Control - Conferencing for User Agents", RFC 4579, August 2006 858 Informative References 860 [6] Sparks, R., "The Session Initiation Protocol (SIP) Refer 861 Method", RFC 3515, April 2003. 863 [7] Schulzrinne, H., et al., "RTP: A Transport Protocol for Real- 864 Time Applications", RFC 3550, July 2003. 866 [8] Jones, et al., "Requirements for an End-to-End Session 867 Identification in IP-Based Multimedia Communication Networks", 868 draft-jones-insipid-session-id-reqts-02.txt, October 2012. 870 Author's Addresses 872 Paul E. Jones 873 Cisco Systems, Inc. 874 7025 Kit Creek Rd. 875 Research Triangle Park, NC 27709 876 USA 878 Phone: +1 919 476 2048 879 Email: paulej@packetizer.com 880 IM: xmpp:paulej@packetizer.com 882 Chris Pearce 883 Cisco Systems, Inc. 884 2300 East President George Bush Highway 885 Richardson, TX 75082 886 USA 888 Phone: +1 972 813 5123 889 Email: chrep@cisco.com 890 IM: xmpp:chrep@cisco.com 892 James Polk 893 Cisco Systems, Inc. 894 3913 Treemont Circle 895 Colleyville, Texas 896 USA 898 Phone: +1 817 271 3552 899 Email: jmpolk@cisco.com 900 IM: xmpp:jmpolk@cisco.com 902 Gonzalo Salgueiro 903 Cisco Systems, Inc. 904 7025 Kit Creek Rd. 905 Research Triangle Park, NC 27709 906 USA 908 Phone: +1 919 392 3266 909 Email: gsalguei@cisco.com 910 IM: xmpp:gsalguei@cisco.com