Network WG James Polk Internet-Draft Paul Jones Intended status: PS Cisco Systems Expires: April 21, 2014 Oct 21, 2013 A Proposal for Backwards Compatibility of the INSIPID Session-ID draft-polk-insipid-bkwds-compatibility-proposal-03.txt Abstract This is a proposal for backwards compatibility for the INSIPID Session-ID SIP header. This draft is never intended to reach RFC status, and is written merely to make a concrete proposal that everyone can view - and if agreed upon, it will be woven into the INSIPID solution draft. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 21, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Polk & Jones Expires April 21, 2014 [Page 1] Internet-Draft Session-ID Backwards Compatibility Oct 2013 1. Introduction This is a proposal for backwards compatibility for the INSIPID Session-ID SIP header. We, in INSIPID, have the 'kaplan draft' specifying a legacy solution [kaplan]. We have the 'jones draft' proposing the current solution [Insipid], which addresses a wider set of requirements than the kaplan draft. Let us call this the 'polk proposal' for backwards compatibility, given that this topic has become such an issue - let's give it a name. The current way in which the jones draft specifies the Session-ID message (or call) flow is articulated here: Alice invites Bob to a call. She includes her UUID, but not his, into the Session-ID header-value. Bob's UUID is inserted by his UA (or call server acting on behalf of his UA). INVITE from Alice to Bob Session-ID: aeffa652b22911dfa81f12313a006823; Bob receives Alice's INVITE and responses (in a perfect world right away because everything in Alice's INVITE is perfectly acceptable to Bob) with a 200 OK response. This response contains Bob's UUID. Alice's UUID has been copied and moved to the 'remote=' portion of the Session-ID header-value. 200 OK from Bob to Alice Session-ID: be11afc8b22911df86c412313a006823; remote=aeffa652b22911dfa81f12313a006823 Once Alice receives this 200 OK from Bob, she transmits the appropriate ACK. The only difference in this Session-ID is the order of the UUIDs. ACK from Alice to Bob Session-ID: aeffa652b22911dfa81f12313a006823; remote=be11afc8b22911df86c412313a006823 Session ID --- Alice Bob Carol {A} |-----INVITE---->| | {B,A} |<----200 OK-----| | {A,B} |------ACK------>| | Figure 1. Basic Call Flow Without Proposed Session-ID Modification Polk & Jones Expires April 21, 2014 [Page 2] Internet-Draft Session-ID Backwards Compatibility Oct 2013 This is all fine and good when conversing between jones draft implementations. In fact, all is fine and good between kaplan draft implementations (that all have a single UUID in the Session-ID header-value. However, problems start happening if either Alice or Bob is a jones implementation and the other UA is a kaplan implementation, and it does not matter which is which. This draft proposes how we can make a single-UUID implementation interoperate with a two-UUID implementation with the single-UUID implementation requiring zero new code. This version includes a couple of suggested alternative means for indicating which implementation an endpoint is compatible with. These suggestions are each outside of the Session-ID header, and each have their own failings. This draft is never intended to reach RFC status, and is written merely to make a concrete proposal that everyone can view and reference in discussions. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. These words may also appear in this document in lower case as plain English words, absent their normative meanings. 3. Session-ID Backwards Compatibility Proposal This proposal involves having all jones implementations send two UUIDs in all their messages, including the initial INVITE. Alice will generate her UUID value the same as she does in the current jones draft. However, she will include a second temporary 'null' UUID in the remote= part of the Session-ID header-value, just as the following example shows: INVITE from Alice to Bob Session-ID: aeffa652b22911dfa81f12313a006823; remote=00000000000000000000000000000000 A 'null' UUID is 32 zeros, and MUST NOT be anything other than 32 zeros in length, i.e., not 'remote=' or 'remote=0'. This has huge benefits for 2 different implementations (a jones and a kaplan implementation). Not only is Alice indicating that she is a jones compatible version to all entities along the signaling path, but if she gets back just her UUID in Bob's 200 OK response or her UUID plus the temporary null value in the 'remote=' in the same order she sent it in, she knows that Bob is a kaplan implementation - because kaplan implementations will reflect the initial UUID as the complete Polk & Jones Expires April 21, 2014 [Page 3] Internet-Draft Session-ID Backwards Compatibility Oct 2013 Session-ID and remove any other values in the header. 200 OK from Bob to Alice Session-ID: aeffa652b22911dfa81f12313a006823 Or 200 OK from Bob to Alice Session-ID: aeffa652b22911dfa81f12313a006823; remote=00000000000000000000000000000000 Session ID --- Alice Bob Carol {A,null} |-----INVITE---->| | {A} |<----200 OK-----| | {A} |------ACK------>| | Figure 2a. Basic Call Flow With Proposed Session-ID Modification Or Session ID --- Alice Bob Carol {A,null} |-----INVITE---->| | {A,null} |<----200 OK-----| | {A,null} |------ACK------>| | Figure 2a. Basic Call Flow With Proposed Session-ID Modification If Alice receives two UUIDs back in Bob's response, such as this 200 OK from Bob to Alice Session-ID: be11afc8b22911df86c412313a006823; remote=aeffa652b22911dfa81f12313a006823 Alice knows Bob has a jones implementation. Session ID --- Alice Bob Carol {A,null} |-----INVITE---->| | {B,A} |<----200 OK-----| | {A,B} |------ACK------>| | Figure 3. Basic Call Flow With Proposed Session-ID Modification In either case, she sends two UUIDs back in her response, to ensure she is always broadcasting which implementation she is compatible with. Polk & Jones Expires April 21, 2014 [Page 4] Internet-Draft Session-ID Backwards Compatibility Oct 2013 Either this when Bob is a kaplan implementation - learned by Bob not sending a second UUID in his response. ACK from Alice to Bob Session-ID: aeffa652b22911dfa81f12313a006823 or this, when Bob included his UUID in the response. ACK from Alice to Bob Session-ID: aeffa652b22911dfa81f12313a006823; remote=be11afc8b22911df86c412313a006823 Alternatively, we could modify this proposal to have Alice (a jones implementation), and the (any) initiator of the SIP request, always send Session-ID: aeffa652b22911dfa81f12313a006823; remote=00000000000000000000000000000000 because this appears to do no harm to a kaplan implementation because, first, the UA will ignore the second UUID, and second, it will not include this second UUID in any response. It is just a question of how closely kaplan implementations follow the kaplan draft, which states that all values in the Session-ID header-value are merely copied into the response. We have heard about inconsistencies as to how this is in fact implemented. Session ID --- Alice Bob Carol {A,null} |-----INVITE---->| | {A} |<----200 OK-----| | {A,null} |------ACK------>| | Figure 4. Basic Call Flow With Mod. to Proposed Session-ID Modification This will affect all subsequent call flows, and I'm not opposed to doing this if the WG wants to go in this direction instead. 3.1 When Alice is the kaplan implementation and she initiates If Alice is the kaplan implementation and she contacts a jones implementation, the same will be true as above, but let me walk through that example. Let us say Alice (a kaplan) invites Bob (a jones) to a session. It would look like this: Polk & Jones Expires April 21, 2014 [Page 5] Internet-Draft Session-ID Backwards Compatibility Oct 2013 INVITE from Alice to Bob Session-ID: aeffa652b22911dfa81f12313a006823 Alice would generate 'the' UUID for this session with Bob. Bob's response (in a perfect world) would be this: 200 OK from Bob to Alice Session-ID: aeffa652b22911dfa81f12313a006823 Bob has learned Alice is a kaplan implementation, so he merely reflects Alice's UUID back to her in his response. Below is Alice's ACK ACK from Alice to Bob Session-ID: aeffa652b22911dfa81f12313a006823 Session ID --- Alice Bob Carol {A} |-----INVITE---->| | {A} |<----200 OK-----| | {A} |------ACK------>| | Figure 5. Basic Call Flow With Alice being a Kaplan Implementation And Bob being a Jones Implementation 3.2 Call Transfer For the case where both Alice and Bob are jones implementations, the initial INVITE would have the sender's UUID and the 'remote=null' (32 zeros) Session-ID. The same is true for the INVITE request as a result of the REFER message - to Carol in most examples, including in the INSIPID solution draft []. In the next two sub-sections, Alice is a kaplan implementation, and Bob is a jones implementation. 3.2.1 Transferee is a kaplan implementation In this case, Alice and Bob are in a session, and Bob transfers Alice to Carol (a jones implementation) using a REFER. Alice is the kaplan implementation and Bob is the jones implementation in this scenario. Since Alice only provides a single UUID in the initial INVITE, she is indicating to all signaling entities in the signaling path that she is a kaplan implementation. Polk & Jones Expires April 21, 2014 [Page 6] Internet-Draft Session-ID Backwards Compatibility Oct 2013 Therefore there is only every one UUID, regardless of whether Carol is a kaplan implementation or a jones implementation. Session ID --- Alice Bob Carol {A} |-----INVITE---->| | {A} |<----200 OK-----| | {A} |------ACK------>| | | | | {A} |<---reINVITE----| Bob puts Alice on Hold {A} |-----200 OK---->| | {A} |<------ACK------| | | | | {A} |<----REFER------| Bob asks Alice to call Carol {A} |-----200 OK---->| | {A} |<------ACK------| | | | | {A} |-----NOTIFY---->| | {A} |<----200 OK-----| | | | | {A} |----------------------INVITE---->| {A} |<---------------------200 OK-----| {A} |-----------------------ACK------>| | | | {A} |-----NOTIFY---->| | {A} |<----200 OK-----| | Figure 6. Call Transfer where Transferee is a kaplan implementation 3.2.2 Transferee is a jones implementation In this case, Alice and Bob are in a session, and Alice transfers Bob to Carol (a jones implementation) using a REFER. Alice is the kaplan implementation and Bob is the jones implementation in this scenario. Since Alice only provides a single UUID in the initial INVITE, she is indicating to all signaling entities in the signaling path that she is a kaplan implementation. Therefore there is only every one UUID, *except* when Bob, a jones implementation, initiates a new SIP request to any entity other than Alice. We want any jones implementation to constantly be looking for other jones implementations so we have the exact same message flow *until* Bob sends his INVITE to Carol. Bob, a jones implementation, told to contact Carol - who he wants to determine if she is another jones implementation , includes a 'remote=null' value as the second UUID in the Session-ID header-value. INVITE from Bob to Carol Polk & Jones Expires April 21, 2014 [Page 7] Internet-Draft Session-ID Backwards Compatibility Oct 2013 Session-ID: aeffa652b22911dfa81f12313a006823; remote=00000000000000000000000000000000 Carol sees this INVITE with 2 UUIDs where the second is a null value (in the Session-ID header-value), therefore she understands Bob to be a jones implementation, so she responses with this 200 OK, indicating that she, too, is a jones implementation. Bob's UUID has been copied and moved to the 'remote=' portion of the Session-ID header-value. 200 OK from Carol to Bob Session-ID: cf26afc8b22911df86c412313a006823; remote=aeffa652b22911dfa81f12313a006823 Once Bob receives this 200 OK from Carol, he transmits the appropriate ACK. The only difference in this Session-ID is the order of the UUIDs. ACK from Bob to Carol Session-ID: aeffa652b22911dfa81f12313a006823; remote=cf26afc8b22911df86c412313a006823 Session ID --- Alice Bob Carol {A} |-----INVITE---->| | {A} |<----200 OK-----| | {A} |------ACK------>| | | | | {A} |---reINVITE---->| Alice puts Bob on Hold {A} |<-----200 OK----| | {A} |------ACK------>| | | | | {A} |------REFER---->| Alice asks Bob to call Carol {A} |<-----200 OK----| | {A} |------ACK------>| | | | | {A} |<---NOTIFY------| | {A} |----200 OK----->| | | | | {A,null} | |-----INVITE---->| {C,A} | |<----200 OK-----| {A,C} | |------ACK------>| | | | {A} |<---NOTIFY------| | {A} |----200 OK----->| | Figure 7. Call Transfer where Transferee is a jones implementation Polk & Jones Expires April 21, 2014 [Page 8] Internet-Draft Session-ID Backwards Compatibility Oct 2013 4. Any More Call Flows Necessary? I hope readers familiar with the INSIPID work understand this proposal by now, but I will do more call flows if needed. 5. Flags Outside of the Session-ID to Indicate Compliance with a Particular Implementation There have been to date two alternatives discussed on the mailing list regarding a flag to identify which implementation an endpoint is; namely a new option tag and a Contact header feature tag. Both of these will not work IMO for the following reasons: A new Option tag - Option tags are indications of support (or not) for one or more particular SIP extensions. Kaplan draft endpoints support the Session-ID extension. Jones implementations will support the Session-ID extension. However, what could be a proper indication for 'which' Session-ID implementation an endpoint is compliant with that does not involve writing new code in kaplan endpoints, which is not a desired outcome (to force all kaplan implementations to write new code)? What does an endpoint indicate if it supports both kaplan and jones implementations? A Contact header feature tag - the Contact header is not part of a SIP MESSAGE method request, and I find no reason to limit this particular new capability to "not to be used with MESSAGE requests" (ever). 6. 7. Acknowledgements To Christer Holmberg, Keith Drage, Paul Kyzivat and Hadriel Kaplan for the helpful comments. 8. IANA Considerations null 9. Security Considerations null Polk & Jones Expires April 21, 2014 [Page 9] Internet-Draft Session-ID Backwards Compatibility Oct 2013 10. References 10.1 Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 [Insipid] P. Jones, C. Pearce, J. Polk, G. Salgueiro, "End-to-End Session Identification in IP-Based Multimedia Communication Networks", "work in progress", 10.2 Informative References [kaplan] H. Kaplan "A Session Identifier for the Session Initiation Protocol (SIP)", "work in progress", August 2013 Author's Addresses James Polk Cisco Systems, Inc. 8017 Hallmark Dr. North Richland Hills, TX 76182 USA Phone: +1 817 271 3552 Email: jmpolk@cisco.com Paul E. Jones 7025 Kit Creek Rd. Research Triangle Park, NC, USA +1 919 476 2048 mailto: paulej@packetizer.com Polk & Jones Expires April 21, 2014 [Page 10]