Network WG James Polk Internet-Draft Paul Jones Intended status: PS Cisco Systems Expires: March 16, 2014 Sept 16, 2013 A Proposal for Backwards Compatibility of the INSIPID Session-ID draft-polk-insipid-bkwds-compatibility-proposal-02.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 March 16, 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 March 16, 2014 [Page 1] Internet-Draft Session-ID Backwards Compatibility Sept 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 (of 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,null} |-----INVITE---->| | {B,A} |<----200 OK-----| | {A,B} |------ACK------>| | Figure 1. Basic Call Flow Without Proposed Session-ID Modification Polk & Jones Expires March 16, 2014 [Page 2] Internet-Draft Session-ID Backwards Compatibility Sept 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 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, but if she gets back just her UUID in Bob's 200 OK response, she knows that Bob is a kaplan implementation - because kaplan implementations will reflect the initial UUID as the complete Session-ID and remove any other values in the header. 200 OK from Bob to Alice Session-ID: aeffa652b22911dfa81f12313a006823 Polk & Jones Expires March 16, 2014 [Page 3] Internet-Draft Session-ID Backwards Compatibility Sept 2013 Session ID --- Alice Bob Carol {A,null} |-----INVITE---->| | {A} |<----200 OK-----| | {A} |------ACK------>| | Figure 2. 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. 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 Polk & Jones Expires March 16, 2014 [Page 4] Internet-Draft Session-ID Backwards Compatibility Sept 2013 because, first, the UA will ignore the second UUID, and second, it will not include this second UUID in any response. 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: 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 Polk & Jones Expires March 16, 2014 [Page 5] Internet-Draft Session-ID Backwards Compatibility Sept 2013 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. 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 Polk & Jones Expires March 16, 2014 [Page 6] Internet-Draft Session-ID Backwards Compatibility Sept 2013 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 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 Polk & Jones Expires March 16, 2014 [Page 7] Internet-Draft Session-ID Backwards Compatibility Sept 2013 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 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. 6. 7. Acknowledgements null (for now) Polk & Jones Expires March 16, 2014 [Page 8] Internet-Draft Session-ID Backwards Compatibility Sept 2013 8. IANA Considerations null 9. Security Considerations null 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 March 16, 2014 [Page 9]