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]