Subject: [Insipid] Proposed INSIPID solution and backward compatibility

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 1 Aug 2013 00:38:16 -0400

Folks,

I step away for a couple of days and the floodgate opens. :)

I think it's important to understand why we proposed using a two-part
Session Identifier.  The reason is that we have to be able to effectively
deal with things like forking, call transfer, park, bridging, conferencing,
etc.

When initiating a call and using a single UUID value, that has the potential
to go end-to-end. However, if a call is forked there are multiple "ends".
How do we track each of those?  For proper diagnostics and troubleshooting,
it would be ideal to be able to identify which devices have an issue.

Once a call has been placed, there is a Session-ID established between Alice
and Bob.  If Alice (in one country) transfers Bob (perhaps in the same or
different country) to a some location in a high-toll country, who pays the
bill?  Well, to address that, we do call transfer locally on PBXes.  The PBX
maintains control over the call and Alice would pay the bill for the call
transfer.  But if Alice was talking to Carol before the transfer, there is a
Session-ID for that call.  If Bob is put in communication with Carol, what
is the Session-ID value?  Bob had one and Carol had a different one.  What
is the new ID?

It's issues like this that led us to using a two-part value.  In this way,
we could see the call from Alice to Bob has a Session-ID {A,B}.  If Alice
transfers the call to Carol, each device understands that the Session-ID
changed to {B,C}.  Not only that, but intermediaries along the path that
were not privy to signaling that resulted in this change can take note of
the fact the value changed.  This can provide a useful historical record,
since previously they might see a call to Carol identified as {A,C}, but
then it changed to {B,C}.

This property extends quite naturally to other signaling scenarios, as it
allows one to identify a call end-to-end, but also establish some
relationship between other calls that shared at least one UUID value out of
the two.

Hadriel mentioned the desire to use the Session-ID to correlate media flows
and calls.  That's certainly something Cisco would like to do, but it is not
the driver behind the solution.  Having a valid end-to-end identifier (in
whatever form) allows us to do that.  We're not suggesting to fit the
solution to meet that business use case, but rather we just want a solution
that allows us to properly identify calls end-to-end and we recognize that,
due to various service interactions in the network, these UUID values can
change.

I would hope that UUID values will not change to the extent that SBCs change
them for business reasons.  It would certainly defeat the point.  Hadriel
might be right that an SBC vendor might manipulate those values at the
request of a customer, but I would hope said customer appreciates that such
a request effectively breaks the end-to-end model.  We can't do much about
that if they do go down that path.

As for backward-compatibility, the simplest approach (IMO) is to just use a
header value not already in use.  Originally, we had proposed Session-UUID.
That was changed at the request of the group to be Session-ID.  However,
when we have a two UUID solution interacting with a one-UUID solution, we
immediately face some challenges.

What happens if an older system sends this:
  Session-ID: X
But then receives this:
  Session-ID: Y; remote=X

Does this break things?  If so, how do current implementations deal with
such things as mid-call transfers that happen on a PBX like the one I
described above?

We could switch the order like this:
  Session-ID: X; remote=Y

However, that does not work for similar reasons.  If we have a call transfer
where Alice transfers a call with Bob to Carol, then each has a different
idea about what the proper value is for the first position.

Originally, the proposed solution did not indicate position information and
just had single UUID values going in each direction.  We then proposed a
concatenated string (X:Y). However, that presented the same issues for the
call transfer case, so we indicate values by position (sender's value
first), so it is clear what value the receive thinks the remote end has for
the local end.  It might be wrong, but that will be corrected in the
following response. (Intermediaries can take note of the change.)

So, that's why we are where we are.  There has been an effort to maintain
backward-compatibility, but there are challenges in meeting that
requirement.  Where it falls short, we do not know: we've not been told
explicitly what the issues are.  Further, if there are such issues, we need
to also understand how those would be handled in the face of call transfer
or "joining" a call locally on a PBX.  Those are real-world scenarios that
we must address.

Anyway, nothing is set in stone.  Anything can be changed, but I would hope
we can find a solution that works for the enterprise use cases as well as
the service provider networks.

Paul