Subject: [Insipid] Backward compatibility with the Kaplan draft

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 14 Sep 2013 01:52:45 -0400

Folks,

I wrote an email earlier proposing what we might want to put into the
INSIPID draft to allow for backward-compatibility.  It's a bit long, so
perhaps it was glossed over? :-)  Below is the text and James is working on
a separate draft to try to make this clearer.

Here's the idea...

Alice places a call using {A, null}.  The "remote" parameter would be
present and set to all zeros to indicate the Alice is compliant with the
INSIPID spec.  If the parameter is not present in a received message, then
Bob knows that Alice is a Kaplan device and would operate accordingly.

So considering the case where both Alice and Bob are both INSIPID compliant,
we have the usual flow:

      Session ID
         ---     Alice             Bob             Carol
        {A,null}   |-----INVITE---->|                |
        {B,A}      |<-----200 OK----|                |
        {B,A}      |------ACK------>|                |

If Bob does not see the remote parameter in the received INVITE (i.e., Alice
is a Kaplan device), Bob just echoes the value back and inserts "null" as
the "remote" parameter (which is useful for any subsequent transfers like we
described above). 

Consider this case where A = Kaplan and B = INSIPID:

      Session ID
         ---     Alice             Bob             Carol
        {A}        |-----INVITE---->|                |
        {A,null}   |<-----200 OK----|                |
        {A}        |------ACK------>|                |

And consider the reverse where A = INSIPID and B = Kaplan:

      Session ID
         ---     Alice             Bob             Carol
        {A,null}   |-----INVITE---->|                |
        {A}        |<-----200 OK----|                |
        {A,null}   |------ACK------>|                |

Now let's extend the above example with one where Carol is also
INSIPID-compliant and we work through the call transfer scenario from the
beginning:

      Session ID
         ---     Alice             Bob             Carol
        {A,null}   |-----INVITE---->|                |
        {A}        |<-----200 OK----|                |
        {A,null}   |------ACK------>|                |
        {C,null}   |                |<----INVITE-----|
                   (Put Alice on hold to answer Carol)               
        {C}        |                |------200 OK--->|          
        {C,null}   |                |<-----ACK-------|
                   (Put Carol on hold to transfer call)               

At this point, we assume Bob's PBX just blindly passes the Session-ID
header.  No complex interworking.  So, what came in from Alice gets
forwarded by Bob's PBX to Carol and vice versa.  That is, Bob's PBX sends
{A,NULL} to Carol.  Carol replies with {C,A}.  {C,A} is sent to Alice.  Had
Bob's PBX sent the first message to Alice, it might have sent {C,null},
which is odd, but Alice would reply back with {A,null} and then Carol would
reply with {C,A} when it saw the presence of the "remote" parameter.  In the
end, we have both ends with the right Session-ID and the PBX remained
ignorant of the contents of the Session-ID header.

I think that greatly reduces the complexity of the intermediary devices, as
they just forward headers.  Also, it means all devices through the set of
intermediaries will be using a consistent set of values when the call is
stable.

It does mean endpoints have to operate in one of two modes depending on what
is received from the remote side.  Basically, when an endpoint replies, it
puts on the wire either the {A,null} reply (for Kaplan devices) or the {A,B}
reply (for INSIPID devices), depending on whether the remote parameter
exists in the most recently received message.  That seems far simpler to us.

Of course, the simplest solution would be to have a single logic flow and
not have to deal with the interworking issues.  I'm still open to using a
different header, personally.  And, it seems reasonable given the previous
statements that the objective of the current users of the Kaplan draft was
not to have an end-to-end identifier, but one that went SBC to SBC across a
single administrative domain.

Comments?

Paul