Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 1 Aug 2013 05:08:54 -0400

This isn't about Enterprise vs. Service-Provider, or Cisco vs. another vendor.  This is just about a Working Group document, and whether the mechanism defined in it should change the Session-ID header value vs. parameter based on direction of messages, or not.  I totally get the need to have a distinguishing Session-ID identifier for party-A vs. party-B.  What I don't get is why they need to change the encoding of the Session-ID header value vs. parameter, on a message direction basis.

In other words, today the draft has this:
1) Alice sends INVITE with     "Session-ID: foo"
2) Bob   sends 18x/200 with    "Session-ID: bar;remote=foo"
3) Alice sends ACK with        "Session-ID: foo;remote=bar"
4) Bob   sends BYE with        "Session-ID: bar;remote=foo"
5) Alice sends 200 with        "Session-ID: foo;remote=bar"

But we could instead do this:
1) Alice sends INVITE with     "Session-ID: foo"
2) Bob   sends 18x/200 with    "Session-ID: foo;remote=bar"
3) Alice sends ACK with        "Session-ID: foo;remote=bar"
4) Bob   sends BYE with        "Session-ID: foo;remote=bar"
5) Alice sends 200 with        "Session-ID: foo;remote=bar"

This second model keeps the Session-ID header value as "foo" the whole time, while adding a parameter of "bar" for Bob that remains a parameter the whole time.
Neither Alice nor Bob are confused about which one is "their" UUID value.
And it's backward-compatible with the previous kaplan-draft.
And it's arguably easier to implement, for the common cases.

I *think* there was a reason someone came up with at one time as to why it had to be swapped, but I don't remember what it is and I don't see it in the draft.  So I'm trying to find out why we need to do it the way the draft currently has it.

The other topic of whether SBCs will change things is completely orthogonal to the ordering or backwards compatibility issues, and really shouldn't be conflated with it at all.  It has nothing to do with the solutions document, or the direction stuff, etc.

-hadriel

On Aug 1, 2013, at 12:38 AM, Paul E. Jones <[email-masked]> wrote:

> 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
> 
> 
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---

From: Andrew Allen <[email-masked]>
Date: Thu, 1 Aug 2013 09:21:56 +0000

I also think the order of local and remote should remain the same regardless of the direction unless there is a really really good reason otherwise, (I previously made a comment to this effect at the mic at a previous IETF).

----- Original Message -----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Thursday, August 01, 2013 04:08 AM Central Standard Time
To: Paul E. Jones <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility

-hadriel

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Aug 2013 14:23:01 +0200

I find the currenly agreed upon scheme "odd", primarily just because it 
is different from the way from/to tags are used. But from/to tags are 
weird in their own way.

The important thing is that how they are arragned be entirely clear in 
all cases. At least the current scheme has the benefit of having a 
simple rule:
- keep track of "mine" and "yours"
- always send "mine" first
- always receive "yours" first.

I can live with this.

A scheme that uses a single ordering for the two halves in all messages 
of a dialog, including requests in both directions and responses in 
either direction, would IMO be a little bit harder, in that it requires 
a bit more state: I must remember "mine", "yours", and which goes first. 
I think this is what Hadriel is suggesting below.

An alternative would be to use "mine";"yours" in requests, and keep the 
same ordering in responses to the requests. That is very analogous to 
how to/from tags are handled.

	Thanks,
	Paul

---

From: Laura Liess <[email-masked]>
Date: Thu, 1 Aug 2013 15:13:14 +0200

Hadriel's proposal works for us.

Thank you
Laura

2013/8/1 Hadriel Kaplan <[email-masked]>

>
> This isn't about Enterprise vs. Service-Provider, or Cisco vs. another
> vendor.  This is just about a Working Group document, and whether the
> mechanism defined in it should change the Session-ID header value vs.
> parameter based on direction of messages, or not.  I totally get the need
> to have a distinguishing Session-ID identifier for party-A vs. party-B.
>  What I don't get is why they need to change the encoding of the Session-ID
> header value vs. parameter, on a message direction basis.
>
> This second model keeps the Session-ID header value as "foo" the whole
> time, while adding a parameter of "bar" for Bob that remains a parameter
> the whole time.
> I *think* there was a reason someone came up with at one time as to why it
> had to be swapped, but I don't remember what it is and I don't see it in
> the draft.  So I'm trying to find out why we need to do it the way the
> draft currently has it.
>
> The other topic of whether SBCs will change things is completely
> orthogonal to the ordering or backwards compatibility issues, and really
> shouldn't be conflated with it at all.  It has nothing to do with the
> solutions document, or the direction stuff, etc.
>
> -hadriel
>
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 1 Aug 2013 09:26:13 -0400

Hadriel,

As I explained down below, I think there is still an issue with the latter
approach for such things as call transfer.  For example,

1) Alice calls Bob {A,B}
2) Bob puts Alice on hold (perhaps {A,B}, or {A,P} if there is a parking
server)
3) Bob calls Carol {B,C}
4) Bob transfers the call from Alice to Carol {A,C}

With the current solution, the order is only significant so that the
receiving endpoint can clearly identify the UUID of the sender.

If we utilized the former proposal, what would these UUID values be?
1) Alice calls Bob {A,B}
2) Bob puts Alice on hold (perhaps {A,B}, or {A,P} if there is a parking
server?)
3) Bob calls Carol {B,C}
4) Bob transfers the call from Alice to Carol {?,?}

Perhaps that last one might be {A,C}, which might work for Bob.  But if
Carol was an older endpoint, what would she do seeing this "A" value as the
first value?

I think that's one example of where the former solution will break in
real-world calls.

Paul

> -----Original Message-----
> Sent: Thursday, August 01, 2013 5:09 AM
> To: Paul E. Jones
> Cc: [email-masked]

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 1 Aug 2013 10:09:59 -0400

Hadriel,

1) Alice calls Bob {A,B}

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 1 Aug 2013 10:59:30 -0400

Laura,

I assert that old draft will not work for some "real-world" calls.  Calls do
get manipulated in enterprise environments and call centers for billing
purposes, privacy reasons, etc.

Consider a common case: if you call into a call center and the agent puts
you on hold while they transfer you to a specialist (transfer out of
consultation), for example, your SIP UA does not receive a REFER to initiate
a new call directly to the specialist.  This is handled at the call center.

So rather specifically, how would this be handled (with the old draft)?

1) Alice calls Bob (Session-ID: A)

2) Bob puts Alice on hold and calls Carol (Session-ID: B)

3) Bob transfers the call from Alice to Carol using a local transfer
function on the PBX (Session-ID: ??)

The PBX could send different values to Alice and Carol, but we totally lose
the end-to-end identification of the call.

Alice could not send "A" to Carol, since Carol is expecting B.  Likewise,
Carol cannot send "B" to Alice, since Alice is expecting "A".  Well, they
could, and it would be no worse than our current proposal in terms of
backward-compatibility.

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Laura Liess
Sent: Thursday, August 01, 2013 9:13 AM
To: [email-masked]
Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility

Thank you
Laura

This isn't about Enterprise vs. Service-Provider, or Cisco vs. another
vendor.  This is just about a Working Group document, and whether the
mechanism defined in it should change the Session-ID header value vs.
parameter based on direction of messages, or not.  I totally get the need to
have a distinguishing Session-ID identifier for party-A vs. party-B.  What I
don't get is why they need to change the encoding of the Session-ID header
value vs. parameter, on a message direction basis.

This second model keeps the Session-ID header value as "foo" the whole time,
while adding a parameter of "bar" for Bob that remains a parameter the whole
time.
Neither Alice nor Bob are confused about which one is "their" UUID value.
And it's backward-compatible with the previous kaplan-draft.
And it's arguably easier to implement, for the common cases.

I *think* there was a reason someone came up with at one time as to why it
had to be swapped, but I don't remember what it is and I don't see it in the
draft.  So I'm trying to find out why we need to do it the way the draft
currently has it.

The other topic of whether SBCs will change things is completely orthogonal
to the ordering or backwards compatibility issues, and really shouldn't be
conflated with it at all.  It has nothing to do with the solutions document,
or the direction stuff, etc.

-hadriel

---

From: Laura Liess <[email-masked]>
Date: Thu, 1 Aug 2013 17:51:26 +0200

Paul,
We use the old Session-ID only accross SBCs, to correlate both legs of the
same dialog. And it works fine for this use case. We never tried, intend
or were required to do more with it.
 We are not against the new mechanism, we just want it to interwork with
the old one which we have in thousands of customer end devices. If it does,
we can add new end devices and application servers which support the new
Session-ID. Otherwise we can't.

Let's see if it works when we keep the UUID order unchanged, as Hadriel
proposed.

Thank you
Laura

2013/8/1 Paul E. Jones <[email-masked]>

> Laura,****
>
> ** **
>
> I assert that old draft will not work for some “real-world” calls.  Calls
> do get manipulated in enterprise environments and call centers for billing
> purposes, privacy reasons, etc.****
>
> ** **
>
> consultation), for example, your SIP UA does *not* receive a REFER to
> initiate a new call directly to the specialist.  This is handled at the
> call center.****
>
> ** **
>
> So rather specifically, how would this be handled (with the old draft)?***
> *
>
> ** **
>
> 1) Alice calls Bob (Session-ID: A)****
>
> 2) Bob puts Alice on hold and calls Carol (Session-ID: B)****
>
> function on the PBX (Session-ID: ??)****
>
> ** **
>
> The PBX could send different values to Alice and Carol, but we totally
> lose the end-to-end identification of the call.****
>
> ** **
>
> Alice could not send “A” to Carol, since Carol is expecting B.  Likewise,
> Carol cannot send “B” to Alice, since Alice is expecting “A”.  Well, they
> backward-compatibility.****
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Laura Liess
> *Sent:* Thursday, August 01, 2013 9:13 AM
> *To:* [email-masked]
>
> *Subject:* Re: [Insipid] Proposed INSIPID solution and backward
> compatibility****
>
> ** **
>
>
> Laura****
> ** **
> 2013/8/1 Hadriel Kaplan <[email-masked]>****
>
>
> -hadriel****
> https://www.ietf.org/mailman/listinfo/insipid****
>
> ** **
>
> ** **
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 01 Aug 2013 11:59:20 -0400

Laura,

The example I show below is a real call center example. I show use of the old session ID. Tell me how that works. Forget about the new solution for the moment.

If you say it will not work, then I'm not sure how we can make something work with something that does not work. If there is a way to make this work, then we can try to figure out how to interwork with it.

Paul

-------- Original Message --------
From: Laura Liess <[email-masked]>
Sent: Thu Aug 01 11:51:26 EDT 2013
To: "Paul E. Jones" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility

Paul,

Thank you
Laura

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 1 Aug 2013 12:19:17 -0400

> 2) Bob puts Alice on hold (perhaps {A,B}, or {A,P} if there is a parking

I'm not sure what "if there is a parking server" means - I mean I know what parking servers are, but I don't know how it's involved here from a SIP protocol layer between Alice and Bob, in your example.  Is Bob sending a REFER to Alice to have her move to the parking server, or is Bob sending a REFER to the parking server to have it send Alice an INVITE with replaces, or is Bob making a separate call to the parking server and sending Alice a re-INVITE/UPDATE just to move the media to the parking server?

> 4) Bob transfers the call from Alice to Carol {?,?}

Same question as above - how is it doing it?
I ask these questions because the old draft-kaplan session-id had rules about what to do for REFERs and INVITE with replaces, so I'm trying to see where it breaks.

> Carol was an older endpoint, what would she do seeing this "A" value as the

Carol sees it when?  She see's it in a new INVITE?  In a REFER?  In a re-INVITE?

I think we've talked about this before, but in case we hadn't: the Session-ID value in the legacy draft didn't really identify a human or user or even User Agent device - it's not "A" for "Alice" and "B" for "Bob" - it's just a randomish number identifying a session.  Since it doesn't identify a particular device, it can move around/migrate, and doesn't "belong" to Alice or Bob.  I'm not saying that's a *good* property, but since it had that property we can probably play games with parameters to get what needs to be done for the new Session-ID uses.

-hadriel

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 1 Aug 2013 15:47:27 -0400

Hadriel,

Thus sayest Hadriel Kaplan:
> I'm not sure what "if there is a parking server" means - I mean I know
> what parking servers are, but I don't know how it's involved here from a
> SIP protocol layer between Alice and Bob, in your example.  Is Bob sending
> a REFER to Alice to have her move to the parking server, or is Bob sending
> a REFER to the parking server to have it send Alice an INVITE with
> replaces, or is Bob making a separate call to the parking server and
> sending Alice a re-INVITE/UPDATE just to move the media to the parking
> server?

The parking server was optional, but basically Bob is putting Alice on hold.
This might just be a local hold or it might mean Bob moves Alice to a
parking server.  In the latter case, there would be no REFER to Alice since
we would not want those messages going outside the enterprise and resulting
in what appears to be a new phone call established.  (Introduces billing
issues and also introduces internal infrastructure details.)
 
> I ask these questions because the old draft-kaplan session-id had rules
> about what to do for REFERs and INVITE with replaces, so I'm trying to see
> where it breaks.

Here, it would be a transfer managed on the PBX.  Again, no REFER to Alice,
but perhaps this:
1) PBX puts Carol on hold
2) PBX sends INVITE without SDP to take Carol off hold and to get SDP
3) PBX sends that SDP in an INVITE to Alice
4) Reply send to Carol
Etc.

Again, a REFER would not be wanted since Carol might be in a high-toll area
and Bob should be handling the billing charges.  Also, this is a call center
type environment and Alice should never have direct contact information for
Carol.  So, the PBX wants to keep this local.
 
> Carol sees it when?  She see's it in a new INVITE?  In a REFER?  In a re-

I meant to say {A,C} might work for Alice.  If the PBX sends an INVITE to
Carol with the Session-ID {A,C}, what will Carol do (assuming Carol is an
old endpoint).  See also my note to Laura.  I removed the two UUID values
and focus only on the one.  When the PBX sends an INVITE to Carol following
the transfer, it has only one of two values it could send: either A or C.
Which does it choose?  And if it sends C to Carol and sends A to Alice, then
we do not have an end-to-end ID.  We have an end-to-PBX ID.
 
> I think we've talked about this before, but in case we hadn't: the
> Session-ID value in the legacy draft didn't really identify a human or
> user or even User Agent device - it's not "A" for "Alice" and "B" for
> "Bob" - it's just a randomish number identifying a session.  Since it
> doesn't identify a particular device, it can move around/migrate, and
> doesn't "belong" to Alice or Bob.  I'm not saying that's a *good*
property,
> but since it had that property we can probably play games with parameters
> to get what needs to be done for the new Session-ID uses.

In our draft, these are also random values.  However, when I use the
notation 'A' or 'B', I'm referring to the random UUID generated by that
respective endpoint.

So, where I get confused with the previous draft is how it will deal with
things like these PBX-managed call transfers (especially transfer out of
consultation or joining two calls or conferencing calls legs together and
one leg dropping out), IVR interactions in call centers (that are like
transfers), etc.  These are all real things we have to deal with and not
because we did something strange in our systems.  As a practical matter, we
cannot send a REFER outside the enterprise in many cases.

Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 1 Aug 2013 16:16:24 -0400

> issues and also introduces internal infrastructure details.)

Right, so why do you need the Session-ID to change on the call leg between Alice and Bob, if nothing changes in SIP between Alice and Bob?  I mean you got {A} from Alice, and Bob made it into {A,B} on that leg, and then you sent an INVITE to the park server to park this call, so send {A} to the park server, and let that call leg be {A,P}.  The SEssion-ID value "A" ties them together.  Or heck, even send {A,B} to the parking server.

Regardless, if we need it to change we can - just the header value (the part not including the parameters) doesn't change.  The parameters can change all day long and it would still be compatible with the legacy draft.

> Carol.  So, the PBX wants to keep this local.

Right, as I would expect - so again same answer as I had above.

> we do not have an end-to-end ID.  We have an end-to-PBX ID.

Well it feels like you want to hide the changes from Alice, but at the same time you want Alice to know things changed because you want to send her a new/updated UUID pairing.  Isn't that revealing things changed to Alice?  This seems like a contradiction.

But anyway... if you send a new INVITE to Carol, you can put the same "A" in the Session-ID, or you could even put "A;C" in the Session-id.  The header value is "A", and its generated by the PBX to Carol, so per the legacy draft Carol reflects it in her responses/requests back to the PBX for that dialog.  The legacy draft only had rules around the header value, and allowed arbitrary parameters but had no rules around them.

> cannot send a REFER outside the enterprise in many cases.

Yup, understood.  But all we have to do for legacy compatibility is have the sender of an out-of-dialog request send a UUID as the header value, and that value cannot change for the duration of the dialog.  We can create new parameters, and they can change during a dialog if need be.  And there's nothing to prevent you from using the same "A" UUID you got from Alice in a new INVITE to Carol 10 minutes later, so long as it's the same session, which you're saying it is.

So all we have to figure out is what to put in parameters, how they get used (e.g., replaced if need be), etc., to support the same scenarios/use-cases/requirements that the current solutions draft supports.  In the worst case, we could literally take the "local-uuid" and "remote-uuid" fields of your draft and put them as two separate *parameters* and do the send/receive swapping there, if that's what we have to do.  I'm hoping we don't have to go that far, but instead can figure out how to do it with just the main header value and one parameter.

-hadriel

---

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

Hadriel,

> Right, so why do you need the Session-ID to change on the call leg between
> Alice and Bob, if nothing changes in SIP between Alice and Bob?  I mean
> you got {A} from Alice, and Bob made it into {A,B} on that leg, and then
> you sent an INVITE to the park server to park this call, so send {A} to
> the park server, and let that call leg be {A,P}.  The SEssion-ID value "A"
> ties them together.  Or heck, even send {A,B} to the parking server.

I didn't suggest anything is problematic to this point.  Alice could have
transferred the call with Bob to the parking lot and used "A" or "B" or
whatever "the" value was.  Let's not focus here... let's go to the end.
It's the transfer out of consultation case that's the issue.

> Regardless, if we need it to change we can - just the header value (the
> part not including the parameters) doesn't change.  The parameters can
> change all day long and it would still be compatible with the legacy
draft.

And I'm not sure how we can avoid not changing the value before the
parameter in the transfer case.
 
> Right, as I would expect - so again same answer as I had above.

This one is really different.  Let's consider the old draft.

Bob calls Carol, so the Session-ID is some value we'll call 'B'.
Bob was on a call with Alice with some value Alice assigned 'A'.

Now, we want to join these two calls together so that Alice is talking with
Carol (no REFER ... all local stuff).  What is the Session-ID value in this
case?  

What does the PBX send to Alice and Carol?  You said the value cannot
change, but I argue that *something* has to change on one leg of that call,
else we do not have an E2E ID anymore.

> Well it feels like you want to hide the changes from Alice, but at the
> same time you want Alice to know things changed because you want to send
> her a new/updated UUID pairing.  Isn't that revealing things changed to
> Alice?  This seems like a contradiction.

No, Alice knows the call transferred.  That's not a problem.  But, we would
not want to reveal Carol's phone number or URI to Alice, and likely might
want to hide other signaling elements.  You know B2BUAs do strange things.

But, we would like these random numbers to go end-to-end.  Nothing is
revealed in the random number.
 
> But anyway... if you send a new INVITE to Carol, you can put the same "A"
> in the Session-ID, or you could even put "A;C" in the Session-id.  The
> header value is "A", and its generated by the PBX to Carol, so per the
> legacy draft Carol reflects it in her responses/requests back to the PBX
> for that dialog.  The legacy draft only had rules around the header value,
> and allowed arbitrary parameters but had no rules around them.

So it is legal, then, to change the header value between initially
established between Bob and Carol (value 'B') to some new value 'A' at any
time?
 
> Yup, understood.  But all we have to do for legacy compatibility is have
> the sender of an out-of-dialog request send a UUID as the header value,
> and that value cannot change for the duration of the dialog.  We can
> create new parameters, and they can change during a dialog if need be.
> And there's nothing to prevent you from using the same "A" UUID you got
> from Alice in a new INVITE to Carol 10 minutes later, so long as it's the
> same session, which you're saying it is.

There's no OOD messaging here.  Bob puts Carol on hold and then the PBX
sends a new INVITE to Carol with a new Session-ID header value that must
replace the previous one.  That's legal?
 
> So all we have to figure out is what to put in parameters, how they get
> used (e.g., replaced if need be), etc., to support the same scenarios/use-
> cases/requirements that the current solutions draft supports.  In the
> worst case, we could literally take the "local-uuid" and "remote-uuid"
> fields of your draft and put them as two separate *parameters* and do the
> send/receive swapping there, if that's what we have to do.  I'm hoping we
> don't have to go that far, but instead can figure out how to do it with
> just the main header value and one parameter.

Yeah, once I understand exactly what is legal and can be changed, then
working out the details in the current solution spec is not so difficult.
I'm still not clear on this.  It seems like there is a statement that the
Session-ID established with Carol can never change, but now it seems like it
can.  But, I don't think that's your meaning.  I just need to understand
clearly.

Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 1 Aug 2013 18:15:41 -0400

As a side note: none of this discussion seems to have anything to do with swapping directionality of value+parameter based on sender of messages.  This is really more about whether you can change the Session-ID header value mid-dialog or not.

I don't think that is actually required in the requirement document - the relevant requirement is REQ2, but my impression is we don't need the header value in particular to be updated and changed end-to-end... it just required us to be able to correlate the two sessions transferred/joined by a PBX *somehow*.  I.e., as long as one UUID in either a header value or param is the same on both sides, we'd be ok.  Would that be ok?  [I'm not trying to be nit-picky and a stickler to the requirements doc, but more asking if that's sufficient for your needs.]

Other comments inline…

> Carol (no REFER ... all local stuff).  What is the Session-ID value in this

The *header value* would remain "A" on the Alice<->PBX call leg, and "B" on the Carol<->Carol call leg.
The header *parameter* can change, so we can tie it together there.

So it would be:
1) Alice <-PBX-> Bob call: A;B
2) Bob <-PBX-> Carol call: B;C
3) Bob pushes some button to make PBX join Alice and Carol
4) Alice <-PBX is now A;C and PBX->Carol call is now B;A (or B;C if we want it to be that instead)

> revealed in the random number.

OK I understand.  I would point out though, that this is one case where I bet people would have SBCs block this change from propagating out.  Some people don't like re-INVITEs/UPDATEs propagating out, for changes that occur inside an Enterprise... whatsoever.  I.e., if Alice is calling into an Enterprise from a SIP Trunk, my guess is there'll be some cases where the SBCs are configured to locally answer re-INVITES/UPDATEs coming from the Enterprise side.  We've been told to do this both in cases when we get deployed as Service Provider-side and cases where we're Enterprise-side SBCs, of SIP Trunks.[1]

> established between Bob and Carol (value 'B') to some new value 'A' at any

No - I just meant the header parameter(s) can change anytime.

-hadriel
[1] We tried to argue against doing that for years, but eventually relented when our competitors were willing to do it, and when we found re-INVITE/UPDATE storms causing overloads.  It turned out some relatively popular Enterprise PBXs generate re-INVITEs numerous times in the first several seconds, for every single received call, with nothing significant changing.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 1 Aug 2013 19:57:08 -0400

Other comments inline…

So it would be:

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 1 Aug 2013 20:28:37 -0400

> The example I show below is a real call center example. I show use of the old session ID. Tell me how that works. Forget about the new solution for the moment.

Forgetting about the new solution... the old solution worked because it never claimed or attempted to solve the problem you're trying to solve. It was just to help with troubleshooting; and because it was just to help with troubleshooting it was kept as simple as possible in order to make it easy to implement, and so as not to cause a need to troubleshoot the troubleshooting tool.  Due to that, it does support call transfers being tracked by a Session-ID when REFERs and INVITE w/replaces were used for the transfer; but not when SIP itself didn't change at all, and instead a media-bridge switches around what media is going to whom.  Session-ID wasn't really meant to be a media-flow tracking mechanism originally.

When this was in DISPATCH, we talked about sending re-INVITEs/UPDATEs to modify the Session-ID in case of hidden transfers and such - but the general consensus at that time was not to bother.  It would be insane to expect things to send re-INVITEs/UPDATEs all over the place to update/change Session-ID values just to help troubleshooting - who would want a troubleshooting-aid thing to do that really?  So we basically decided not to do that, and instead keep it simple and lightweight.

That's why I argued so much originally against adding the extra requirements to track hidden transfers and conference servers and such.  It requires sending re-INVITEs/UPDATEs to all parties, and I had a hard time believing folks would really want that to happen in practice.  But the WG decided it was worth it, and to have the requirement; but meanwhile to not break backwards compatibility.  So I think there're two ways to go about it: either (1) work around the limitations of the legacy individual draft, or (2) pick a new header name "Media-ID" or some such and not be constrained by the old draft.

-hadriel
p.s. personally I'd be ok with either option-1 or option-2, fwiw.

---

From: Andrew Allen <[email-masked]>
Date: Fri, 2 Aug 2013 06:55:02 +0000

+1

----- Original Message -----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: Thursday, August 01, 2013 03:16 PM Central Standard Time
To: Paul E. Jones <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility

-hadriel

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 2 Aug 2013 07:43:27 +0000

Let us get this clear.

The Kaplan draft is not expected to meet all the requirements. If it did, we would probably be progressing it as the solution document.

What the previous decision of the working group effectively required, when it desired compatibility, was that sensible things should happen as far as possible when the two solutions interoperated. There is also no implication that when Kaplan draft meets WG solution that all the requirements are met.

The desire for compatibility is based on the fact that the previous solution is out there in the field. One solution will meet the other. One solution should not bomb the other one out. Implementors of the Kaplan solution will migrate to the real solution at some point and that intent has been expressed in the meeting several times. But that migration will not happen overnight as soon as the WG RFCs are published.

Regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul E. Jones
Sent: 01 August 2013 16:00
To: 'Laura Liess'; [email-masked]
Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility

Laura,

I assert that old draft will not work for some "real-world" calls.  Calls do get manipulated in enterprise environments and call centers for billing purposes, privacy reasons, etc.

Consider a common case: if you call into a call center and the agent puts you on hold while they transfer you to a specialist (transfer out of consultation), for example, your SIP UA does not receive a REFER to initiate a new call directly to the specialist.  This is handled at the call center.

1) Alice calls Bob (Session-ID: A)
2) Bob puts Alice on hold and calls Carol (Session-ID: B)
3) Bob transfers the call from Alice to Carol using a local transfer function on the PBX (Session-ID: ??)

The PBX could send different values to Alice and Carol, but we totally lose the end-to-end identification of the call.

Alice could not send "A" to Carol, since Carol is expecting B.  Likewise, Carol cannot send "B" to Alice, since Alice is expecting "A".  Well, they could, and it would be no worse than our current proposal in terms of backward-compatibility.

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Laura Liess
Sent: Thursday, August 01, 2013 9:13 AM
To: [email-masked]
Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility

Thank you
Laura

2013/8/1 Hadriel Kaplan <[email-masked]<mailto:[email-masked]>>

-hadriel

On Aug 1, 2013, at 12:38 AM, Paul E. Jones <[email-masked]<mailto:[email-masked]>> wrote:

> [email-masked]<mailto:[email-masked]>

_______________________________________________
insipid mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/insipid

---

From: Andrew Allen <[email-masked]>
Date: Fri, 2 Aug 2013 07:56:18 +0000

Putting it another way:

Things that work with the kaplan draft should continue to work when a kaplan compliant implementation interworks with the WG solution compliant implementations.

Things that don't work with the kaplan draft are not expected to work when a kaplan compliant implementation interworks with the WG solution compliant implementations however the degraded behavior should be no worse than between kaplan compliant implementations.

Andrew

From: DRAGE, Keith (Keith) [mailto:[email-masked]]
Sent: Friday, August 02, 2013 02:43 AM Central Standard Time
To: Paul E. Jones <[email-masked]>; 'Laura Liess' <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility

Let us get this clear.

Regards

Keith

Laura,

I assert that old draft will not work for some “real-world” calls.  Calls do get manipulated in enterprise environments and call centers for billing purposes, privacy reasons, etc.

Alice could not send “A” to Carol, since Carol is expecting B.  Likewise, Carol cannot send “B” to Alice, since Alice is expecting “A”.  Well, they could, and it would be no worse than our current proposal in terms of backward-compatibility.

Paul

Thank you
Laura

-hadriel

---

From: Laura Liess <[email-masked]>
Date: Fri, 2 Aug 2013 10:46:53 +0200

Paul,

As I said, we never used the old Session-ID to do more than correlate bothe
legs of the same dialog.  So in your example we have:
- Alice to Bob: Session-ID A
- Bob to Carol: Session-ID B
- Alice to Carol: Session-ID C

There is no correlation between them. We just correlate both legs of the
same dialog  across the SBC between Alice and Bob.

Thank you
Laura

> Laura,
>
> The example I show below is a real call center example. I show use of the
> old session ID. Tell me how that works. Forget about the new solution for
> the moment.
>
> If you say it will not work, then I'm not sure how we can make something
> work with something that does not work. If there is a way to make this
> work, then we can try to figure out how to interwork with it.
>
> Paul
>
>
> ------------------------------
> *From:* Laura Liess <[email-masked]>
> *Sent:* Thu Aug 01 11:51:26 EDT 2013
>
> *To:* "Paul E. Jones" <[email-masked]>
> *Cc:* [email-masked]
>
> compatibility
>> So rather specifically, how would this be handled (with the old draft)?**
>> **
>>
>> ** **
>>
>> I *think* there was a reason someone came up with at one time as to why
>> it had to be swapped, but I don't remember what it is and I don't see it in

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 2 Aug 2013 10:23:08 +0000

As WG chair

That corresponds to my understanding, with one caveat

If the compatibility prevents the solution document meeting a requirement in the requirements draft, then that probably overrides the compatibility agreement to the extent that we need to meet the requirement.

Regards

Keith

________________________________
From: Andrew Allen [mailto:[email-masked]]
Sent: 02 August 2013 08:56
To: DRAGE, Keith (Keith); [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility

Putting it another way:

Andrew

Let us get this clear.

Regards

Keith

Laura,

Paul

Thank you
Laura

-hadriel

---

From: Andrew Allen <[email-masked]>
Date: Fri, 2 Aug 2013 10:52:18 +0000

I don't see that we ever need to get into that situation.

As we discussed yesterday we have two parts. The header field part and the header parameter part(s).

In order to be compatible with the kaplan draft the header field part is inserted by the party that first includes the session ID and this value MUST NOT be modified. The header parameter part or parts can be changed as much as you like and still be backward compatible with kaplan.

If we need to reverse orders or otherwise modify session IDs let's defined additional header parameters that can be changed under certain situations during a session while leaving the header field value unchanged. That way we can have our cake and eat it.

Andrew

From: DRAGE, Keith (Keith) [mailto:[email-masked]]
Sent: Friday, August 02, 2013 05:23 AM Central Standard Time
To: Andrew Allen; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: [Insipid] Proposed INSIPID solution and backward compatibility

As WG chair

Regards

Keith

Putting it another way:

Andrew

Let us get this clear.

Regards

Keith

Laura,

Paul

Thank you
Laura

-hadriel

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 2 Aug 2013 11:08:48 -0400

Hadriel,

> As a side note: none of this discussion seems to have anything to do with
> swapping directionality of value+parameter based on sender of messages.
> This is really more about whether you can change the Session-ID header
> value mid-dialog or not.

Right.  I'm trying to understand the constraints that limit interoperability
with the former draft.
 
> I don't think that is actually required in the requirement document - the
> relevant requirement is REQ2, but my impression is we don't need the
> header value in particular to be updated and changed end-to-end... it just
> required us to be able to correlate the two sessions transferred/joined by
> a PBX *somehow*.  I.e., as long as one UUID in either a header value or
> param is the same on both sides, we'd be ok.  Would that be ok?  [I'm not
> trying to be nit-picky and a stickler to the requirements doc, but more
> asking if that's sufficient for your needs.]

Yeah, for the solution we proposed, we can correlate the two calls by
looking at the individual UUIDs after a transfer.  What I'm interested in
understanding in this thread is how the Session-ID header value can change
(if at all) when a call is "joined" at a PBX under the old scheme.

> want it to be that instead)

But, now we no longer have an end-to-end identifier.  Now we have two
entirely different identifiers: one from Alice to PBX and one from the PBX
to Carol.

> OK I understand.  I would point out though, that this is one case where I
> bet people would have SBCs block this change from propagating out.  Some
> people don't like re-INVITEs/UPDATEs propagating out, for changes that
> occur inside an Enterprise... whatsoever.  I.e., if Alice is calling into
> an Enterprise from a SIP Trunk, my guess is there'll be some cases where
> the SBCs are configured to locally answer re-INVITES/UPDATEs coming from
> the Enterprise side.  We've been told to do this both in cases when we get
> deployed as Service Provider-side and cases where we're Enterprise-side
> SBCs, of SIP Trunks.[1]

You might be right, but then those folks lose the benefits of having an
end-to-end identifier.  I can't force people not to do something, even if
the standard says not to do it :-(

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 2 Aug 2013 11:22:18 -0400

Hadriel,

The new solution is not focused on media flow tracking.  Let me be clear.
We just need a Session-ID.  Once we have one, then we can do other
interesting things with it.  We did want to solve then end-to-end problem,
appreciating the fact that the ends do move around sometimes.  So, while
Alice might start out talking to Bob, she might get switched over to Carol.
This is extremely common, especially in call centers (but also if you call
my desk and I transfer you somewhere else).

Re-INVITE for transfers is often needed, because audio/video capabilities
change.  Media ports might change, too.  In most transfer cases, calls are
put on hold and sometimes media is halted entirely, at least in one
direction.

I'm certainly OK with trying to figure out how to interwork with the
previous draft, but it looks like it might be too constraining by not
supporting transfers and such.  In effect, it's not always end-to-end.

I'm certainly OK, too, with a new header value, though "Media-ID" is not
quite right.  This is intended to identify the session.  Perhaps just
"Sess-ID"?

Paul

> Forgetting about the new solution... the old solution worked because it
> never claimed or attempted to solve the problem you're trying to solve. It
> was just to help with troubleshooting; and because it was just to help
> with troubleshooting it was kept as simple as possible in order to make it
> easy to implement, and so as not to cause a need to troubleshoot the
> troubleshooting tool.  Due to that, it does support call transfers being
> tracked by a Session-ID when REFERs and INVITE w/replaces were used for
> the transfer; but not when SIP itself didn't change at all, and instead a
> media-bridge switches around what media is going to whom.  Session-ID
> wasn't really meant to be a media-flow tracking mechanism originally.
> 
> When this was in DISPATCH, we talked about sending re-INVITEs/UPDATEs to
> modify the Session-ID in case of hidden transfers and such - but the
> general consensus at that time was not to bother.  It would be insane to
> expect things to send re-INVITEs/UPDATEs all over the place to
> update/change Session-ID values just to help troubleshooting - who would
> want a troubleshooting-aid thing to do that really?  So we basically
> decided not to do that, and instead keep it simple and lightweight.
> 
> That's why I argued so much originally against adding the extra
> requirements to track hidden transfers and conference servers and such.
> It requires sending re-INVITEs/UPDATEs to all parties, and I had a hard
> time believing folks would really want that to happen in practice.  But
> the WG decided it was worth it, and to have the requirement; but meanwhile
> to not break backwards compatibility.  So I think there're two ways to go
> about it: either (1) work around the limitations of the legacy individual
> draft, or (2) pick a new header name "Media-ID" or some such and not be
> constrained by the old draft.
> 
> -hadriel

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 2 Aug 2013 11:44:55 -0400

Andrew,

Given what Hadriel explained in the email earlier (if I understood it correctly), the old draft would likely be broken by any PBX that merrily passed the Session-ID header through end-to-end.

Review that flow I presented before:

2)      Bob puts Alice on hold

3)      Bob calls Carol (Session-ID: B)

4)      Bob “transfers” (local join) Alice to Carol

At step 4, Alice would send Session-ID “A” to Carol and Carol would send Session-ID “B” to Alice.  Basically, the two endpoints have a different concept of what the end-to-end value is.

We could try to order the UUIDs in the current solution draft so that we “do not make it worse” or we could just pick a different header value to use, as Hadriel suggested.  But, it appears the end-to-end value will get lost with the old draft due to the way call interactions are handled in enterprise and call center environments.

Paul

From: Andrew Allen [mailto:[email-masked]] 
Sent: Friday, August 02, 2013 3:56 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility

Putting it another way:

Andrew

Let us get this clear.

Regards

Keith

  _____  

Laura,

Paul

Thank you
Laura

-hadriel

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 2 Aug 2013 11:48:04 -0400

Larua,

So in effect, the current deployments are not end-to-end, but edge-to-edge
somewhere.  I can appreciate that, but it does make it more challenging to
try to work with when we go all the way end-to-end.

Paul

From: Laura Liess [mailto:[email-masked]] 
Sent: Friday, August 02, 2013 4:47 AM
To: Paul E. Jones
Cc: [email-masked]
Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility

Paul,

Thank you
Laura

Laura,

If you say it will not work, then I'm not sure how we can make something
work with something that does not work. If there is a way to make this work,
then we can try to figure out how to interwork with it.

Paul

  _____  

Cc: [email-masked]

Paul,
We use the old Session-ID only accross SBCs, to correlate both legs of the
same dialog. And it works fine for this use case. We never tried, intend  or
were required to do more with it.
 We are not against the new mechanism, we just want it to interwork with the
old one which we have in thousands of customer end devices. If it does, we
can add new end devices and application servers which support the new
Session-ID. Otherwise we can't.  

Thank you
Laura

Laura,

Paul

 

Thank you
Laura

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 2 Aug 2013 14:04:06 -0400

> the standard says not to do it :-(

Right, but the basic premise of the old Session-ID was that the mechanism was "benign", and thus did not have a reason for the admins of middleboxes to muck with it.  Having devices send re-INVITEs/UPDATEs to change the session-id value, or using it for call success/failure impacting purposes, makes it no longer benign.  In the former case it generates more message traffic, and in the latter it impacts call control.

I'm not saying we can't do it - I'm just saying we need to be aware of what we're doing by no longer keeping it a benign mechanism.  In particular, that we can't argue middleboxes shouldn't muck with it, and any belief it will truly be end-to-end someday across domains can no longer be assumed.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 2 Aug 2013 16:49:53 -0400

Ummm... in what way is it *not* about tracking the media?  The scenario you'd like to cover is one where there are two separate SIP sessions through a PBX, and the PBX "joins" them at a media layer but doesn't change things at a SIP layer other than to send a re-INVITE/UPDATE to change the Session-ID value.

I totally get that PBXs do that - I know they frequently do it that way. (heck, some SBCs do too these days)  But all that is really being tracked/correlated is the media.  We went through multiple rounds of discussion in DISPATCH about Session-ID, where I tried to describe what the "thing" was that it correlated.  At one point I even tried to describe it as correlating things that shared fate (ie, if Alice hangs up, the other SIP dialogs would too), but conference bridge dialogs didn't exhibit that behavior, and neither did PBX dialogs in some cases.  We also talked about it correlating media sessions instead, but we knew that required the re-INVITE/UPDATEs and at the time the consensus was not to do it. (That changed in the INSIPID WG, obviously)

Ultimately the thing we agreed on was that the legacy Session-ID correlated things as the Call-ID would have done, had B2BUAs not changed the Call-ID.   So the original "call" from Alice through the PBX to Bob would be the same Session-ID, but the Bob-Carol one was a different one, and if the PBX joined Alice and Carol at a media layer without really doing REFER/IWR, then it's still two separate Session-IDs because in that case the PBX is truly acting as two separate User Agent "ends" and there is no real *SIP* relationship between Alice and Carol.

I get why you want to do it, but my point was it's not what the legacy draft was trying to accomplish.  

Other comments inline...

> my desk and I transfer you somewhere else).

Yup, I know it's common in call-centers.

> put on hold and sometimes media is halted entirely, at least in one

Yup, but in the cases where the SBC on the SIP trunk locally answers the re-INVITE, it hides those media changes from the Service Provider.  The rest of the world doesn't need to know that the media address/ports changed, or that it got put on hold. (some PBXs do that too, instead of the SBC - the PBX doesn't send re-INVITEs up the SIP trunk, but just locally moves stuff around and plays music on hold and so on)

> supporting transfers and such.  In effect, it's not always end-to-end.

The legacy draft supports "transfers" - it supports them when they're truly SIP transfers.  It doesn't support identifying media switching.

This new draft won't be end-to-end either in the real world.  It might well be end-to-end within a domain, but across domains I'm pretty sure it won't be. 

> quite right.  This is intended to identify the session.  

What does the word "session" mean to you in this context?

> Perhaps just

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 2 Aug 2013 17:07:29 -0400

I can't tell if you seriously believe the new mechanism is going to work end-to-end across all domains, or if you just mean end-to-end within a domain (like within the call-center).  I don't mean that in a negative way - I just mean I don't understand how you mean the words "end-to-end".

I seriously doubt this thing is going to achieve any more than the legacy draft did in terms of true end-to-end across-the-world type thing.  In fact it may even do less.

When I make a call from my cell phone through my mobile provider, through N number of carriers, to an Enterprise call-center somewhere in Timbuktu, I have a hard time believing all the carriers and mobile providers want to get back and process a re-INVITE each and every time the call gets moved around inside the call-center's internal PBX infrastructure.  They rarely get that today, and I don't see them changing in the future to do so... for what benefit?  What use is it to update all the SIP systems along the path, as well as my cell phone, with a new Session-ID value just because the call got parked/unparked or internally transferred inside PBX/ACD/etc. systems in a call-center somewhere?

Some call centers move the media around almost a dozen times per call.  You really think the rest of the world wants to get a dozen re-INVITEs, for no benefit?  The SBCs aren't answering the re-INVITEs locally today to hide the identity of who/what it gets moved around to - that we already do even when we forward the re-INVITEs - we're answering them locally because the service providers don't want nor need those re-INVITEs.  It's just extra processing load, log entries, and things that can go wrong; with no added benefit.

-hadriel

On Aug 2, 2013, at 11:48 AM, Paul E. Jones <[email-masked]> wrote:

> Larua,
>  
> So in effect, the current deployments are not end-to-end, but edge-to-edge somewhere.  I can appreciate that, but it does make it more challenging to try to work with when we go all the way end-to-end.
>  
> Paul
>  
> As I said, we never used the old Session-ID to do more than correlate bothe legs of the same dialog.  So in your example we have: 
> There is no correlation between them. We just correlate both legs of the same dialog  across the SBC between Alice and Bob.  
> 
> Thank you
> Laura
> 
> 
> 
> We use the old Session-ID only accross SBCs, to correlate both legs of the same dialog. And it works fine for this use case. We never tried, intend  or were required to do more with it.
>  We are not against the new mechanism, we just want it to interwork with the old one which we have in thousands of customer end devices. If it does, we can add new end devices and application servers which support the new Session-ID. Otherwise we can't.  
> 
> Let's see if it works when we keep the UUID order unchanged, as Hadriel proposed. 
> 
> Thank you
> Laura
> 
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 2 Aug 2013 17:34:33 -0400

> So in effect, the current deployments are not end-to-end, but edge-to-edge somewhere.  I can appreciate that, but it does make it more challenging to try to work with when we go all the way end-to-…

Actually I know of one current deployment where it is end-to-end, within the domain of the provider. 

But regardless, of course it's not world-wide end-to-end yet.  It will take a very long time for that to happen, assuming it ever does.  There's no "flag day" to switch over all systems in the World, let alone even all systems within a service provider's domain.  This isn't like a typical medium-sized Enterprise, with all equipment from one or two vendors in a couple of data rooms.  Carriers have hundreds of SIP systems, from dozens of vendors, doing all kinds of different things.  Even an "IMS-compliant" network doesn't upgrade everything all at once to a new release.  They typically upgrade one cluster of core components at a time, like the P/I/S-CSCF for a region for example.  The Application Servers appear to upgrade less frequently - the carriers add new app-servers for new features introduced by a new IMS release, but they often don't need to upgrade the ones that do features from a previous release.  If it ain't broke, they don't usually fix it.

I think any solution we come up with had better not expect all systems everywhere to change overnight.  Even ignoring the legacy kaplan draft completely - whatever we come up with in INSIPID is going to be deployed edge-to-edge for a long time.

-hadriel

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 13 Aug 2013 18:14:11 -0400

Hadriel,

> Ummm... in what way is it *not* about tracking the media?  The scenario
> you'd like to cover is one where there are two separate SIP sessions
> through a PBX, and the PBX "joins" them at a media layer but doesn't
> change things at a SIP layer other than to send a re-INVITE/UPDATE to
> change the Session-ID value.

This has nothing to do with the media.  The PBX "joins" on the signaling
plane; media handled by the endpoints.

> I totally get that PBXs do that - I know they frequently do it that way.
> (heck, some SBCs do too these days)  But all that is really being
> tracked/correlated is the media.  We went through multiple rounds of
> discussion in DISPATCH about Session-ID, where I tried to describe what
> the "thing" was that it correlated.  At one point I even tried to describe
> it as correlating things that shared fate (ie, if Alice hangs up, the
> other SIP dialogs would too), but conference bridge dialogs didn't exhibit
> that behavior, and neither did PBX dialogs in some cases.  We also talked
> about it correlating media sessions instead, but we knew that required the
> re-INVITE/UPDATEs and at the time the consensus was not to do it. (That
> changed in the INSIPID WG, obviously)

Re-INVITES are very common in PBXes as calls are put on hold, parked, taken
off hold, and "joined" to another call.  But, the PBX does not necessarily
touch media.

> Ultimately the thing we agreed on was that the legacy Session-ID
> correlated things as the Call-ID would have done, had B2BUAs not changed
> the Call-ID.   So the original "call" from Alice through the PBX to Bob
> would be the same Session-ID, but the Bob-Carol one was a different one,
> and if the PBX joined Alice and Carol at a media layer without really
> doing REFER/IWR, then it's still two separate Session-IDs because in that
> case the PBX is truly acting as two separate User Agent "ends" and there
> is no real *SIP* relationship between Alice and Carol.

Except for the media part, yes.  We want something end-to end between Alice
and Carol, in your example.  We cannot rely on Call-ID since each endpoint
has a different idea about what the Call-ID is.  The Session-ID would allow
the two to agree on the two-part value {A,C}.
 
> draft was trying to accomplish.

Yeah, I understand that.  They're both trying to address an end-to-end ID,
but the real-world signaling scenarios (manipulation in call centers,
manipulation in PBXes, and interworking with H.323 devices) necessitate
something different to truly have an end-to-end value.  Also, we appreciate
the fact the end-to-end value might change (e.g., call transfer to Carol).
 
> Yup, but in the cases where the SBC on the SIP trunk locally answers the
> re-INVITE, it hides those media changes from the Service Provider.  The
> rest of the world doesn't need to know that the media address/ports
> changed, or that it got put on hold. (some PBXs do that too, instead of
> the SBC - the PBX doesn't send re-INVITEs up the SIP trunk, but just
> locally moves stuff around and plays music on hold and so on)

Yeah, some might and I can appreciate not wanting to forward INVITES to the
remote UAs too frequently.  However, the Session-ID changes would
necessitate that.
 
> The legacy draft supports "transfers" - it supports them when they're
> truly SIP transfers.  It doesn't support identifying media switching.

Right, but I could not begin to count the number of places where I see
"transfers" just done locally.  People do the same with H.323, too. Few use
H.450.2 to transfer.  Rather, they just send a TCS=0 and then a new TCS.
Same logic.

> This new draft won't be end-to-end either in the real world.  It might
> well be end-to-end within a domain, but across domains I'm pretty sure it
> won't be.

Well, that would be rather unfortunate.  At least it should be across the
public Internet.  If service providers want to play with the signaling,
there is really nothing I can do about that.

> What does the word "session" mean to you in this context?

I'm hesitant to answer that question.  Robert spent a lot of time
articulating what a "session" is in the requirements document :-)  I don't
want to get it wrong by paraphrasing.

BTW, James will throw out an idea for maintaining backward compatibility
soon.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 13 Aug 2013 18:34:13 -0400

Hadriel,

> I can't tell if you seriously believe the new mechanism is going to work
> end-to-end across all domains, or if you just mean end-to-end within a
> domain (like within the call-center).  I don't mean that in a negative way
> - I just mean I don't understand how you mean the words "end-to-end".

I seriously mean end-to-end.  Assuming service providers did not block
passage of an INVITE containing a new UUID value, then we can always have an
end-to-end value.  As an "end" changes, so does the end-to-end value.
That's OK.
 
> I seriously doubt this thing is going to achieve any more than the legacy
> draft did in terms of true end-to-end across-the-world type thing.  In
> fact it may even do less.

The only reason it would not is if:
1) One endpoint does not support the procedures (can't help that)
2) Something prevents a new INVITE from going to one endpoint (like an SBC)

Otherwise, it would work.
 
> When I make a call from my cell phone through my mobile provider, through
> N number of carriers, to an Enterprise call-center somewhere in Timbuktu,
> I have a hard time believing all the carriers and mobile providers want to
> get back and process a re-INVITE each and every time the call gets moved
> around inside the call-center's internal PBX infrastructure.  They rarely
> get that today, and I don't see them changing in the future to do so...
> for what benefit?  What use is it to update all the SIP systems along the
> path, as well as my cell phone, with a new Session-ID value just because
> the call got parked/unparked or internally transferred inside PBX/ACD/etc.
> systems in a call-center somewhere?
>
> Some call centers move the media around almost a dozen times per call.
> You really think the rest of the world wants to get a dozen re-INVITEs,
> for no benefit?  The SBCs aren't answering the re-INVITEs locally today to
> hide the identity of who/what it gets moved around to - that we already do
> even when we forward the re-INVITEs - we're answering them locally because
> the service providers don't want nor need those re-INVITEs.  It's just
> extra processing load, log entries, and things that can go wrong; with no
> added benefit.

I really cannot do anything about these "noise" issues. I recognize that in
practice,  much of the use of SIP has been absolutely nothing more than a
PSTN replacement.  It has been merely a means of moving from TDM to IP.  I'm
glad it happened, but it's more than unfortunate if that's all we
accomplish.

As I look to doing more interesting things where I have different
applications running in various devices connected to different networks and
associated to my "phone" where I can utilize all of them as a part of a
"call", I see value in having this end-to-end identifier for even this more
complex arrangement.  However, I can understand if service providers do not
take an active interest in this.  From a research perspective, these more
advanced communication systems are interesting.  From a business
perspective, there is a question about ROI for carriers.  I get that:
there's no money in doing much more than providing the most basic voice
service, and even that service has a very small profit margin.  However,
progress, capabilities, functionality, and improvements in the way we work
and communicate should go forward, and they are.  Already, we see a number
of alternatives like Skype, Facetime, Google Hangouts, etc. and I expect
functionality will become much more interesting, with a wider mix of
multimedia applications in use at once.

Bottom line is that we should not constrain a system, but try to make it as
flexible as possible.  It might not work everywhere, but don't constrain
ourselves to the most basic voice call flow.

Paul
 
> > So in effect, the current deployments are not end-to-end, but edge-to-
> edge somewhere.  I can appreciate that, but it does make it more
> challenging to try to work with when we go all the way end-to-end.
> >
> > Paul
> >
> > As I said, we never used the old Session-ID to do more than correlate
> bothe legs of the same dialog.  So in your example we have:
> > The example I show below is a real call center example. I show use of
> the old session ID. Tell me how that works. Forget about the new solution
> for the moment.
> >
> > We use the old Session-ID only accross SBCs, to correlate both legs of
> the same dialog. And it works fine for this use case. We never tried,
> intend  or were required to do more with it.
> > I assert that old draft will not work for some "real-world" calls.
> Calls do get manipulated in enterprise environments and call centers for
> billing purposes, privacy reasons, etc.
> >
> > Consider a common case: if you call into a call center and the agent
> puts you on hold while they transfer you to a specialist (transfer out of
> consultation), for example, your SIP UA does not receive a REFER to
> call center.
> lose the end-to-end identification of the call.
> >
> it had to be swapped, but I don't remember what it is and I don't see it
> in the draft.  So I'm trying to find out why we need to do it the way the
> draft currently has it.
> >

---

From: Iain McIlwaine <[email-masked]>
Date: Wed, 14 Aug 2013 10:20:03 +0100

Folks,

I see a lot of discussion for enterprise transfer scenarios but I would
like to highlight a problematic use case to gauge your opinions.

Using Hadriel's method which designates local:remote of the UUID according
to the issuer of the INVITE I can see a potential problem for Access
Transfer when the party being transferred is in the "proceeding" state.
So:

Alice INVITE - "Transfer AS" - Bob: "Session-ID:foo"
Bob 1XX - "Transfer AS" - Alice  "Session-ID:foo;remote=bar"
Bob' INVITE - "Transfer AS" Session-ID:foo'

Note: the "Transfer AS" can be an ATCF or an SCC.

We can see in this case using Hadriel's syntax we now require the Transfer
AS to perform manipulation of the Session-ID header which runs contrary to
a stated objective of no intermediary meddling of the header.

If we revert to interpreting the local:remote syntax being within the
context of the receiver I believe we would avert this situation.

Of course it could be I've misunderstood something so happy to be shown
the light.

Kind regards,
Iain

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul E. Jones
Sent: 13 August 2013 23:34
To: 'Hadriel Kaplan'
Cc: [email-masked]; 'Laura Liess'
Subject: Re: [Insipid] Proposed INSIPID solution and backward
compatibility

Hadriel,

> I can't tell if you seriously believe the new mechanism is going to
> work end-to-end across all domains, or if you just mean end-to-end
> within a domain (like within the call-center).  I don't mean that in a
> negative way

I seriously mean end-to-end.  Assuming service providers did not block
passage of an INVITE containing a new UUID value, then we can always have
an end-to-end value.  As an "end" changes, so does the end-to-end value.
That's OK.

> I seriously doubt this thing is going to achieve any more than the
> legacy draft did in terms of true end-to-end across-the-world type
> thing.  In fact it may even do less.

The only reason it would not is if:
1) One endpoint does not support the procedures (can't help that)
2) Something prevents a new INVITE from going to one endpoint (like an
SBC)

> When I make a call from my cell phone through my mobile provider,
> through N number of carriers, to an Enterprise call-center somewhere
> in Timbuktu, I have a hard time believing all the carriers and mobile
> providers want to get back and process a re-INVITE each and every time
> the call gets moved around inside the call-center's internal PBX
> infrastructure.  They rarely get that today, and I don't see them
changing in the future to do so...
> for what benefit?  What use is it to update all the SIP systems along
> the path, as well as my cell phone, with a new Session-ID value just
> because the call got parked/unparked or internally transferred inside
PBX/ACD/etc.
> You really think the rest of the world wants to get a dozen
> re-INVITEs, for no benefit?  The SBCs aren't answering the re-INVITEs
> locally today to hide the identity of who/what it gets moved around to
> - that we already do even when we forward the re-INVITEs - we're
> answering them locally because the service providers don't want nor
> need those re-INVITEs.  It's just extra processing load, log entries,
> and things that can go wrong; with no added benefit.

I really cannot do anything about these "noise" issues. I recognize that
in practice,  much of the use of SIP has been absolutely nothing more than
a PSTN replacement.  It has been merely a means of moving from TDM to IP.
I'm glad it happened, but it's more than unfortunate if that's all we
accomplish.

As I look to doing more interesting things where I have different
applications running in various devices connected to different networks
and associated to my "phone" where I can utilize all of them as a part of
a "call", I see value in having this end-to-end identifier for even this
more complex arrangement.  However, I can understand if service providers
do not take an active interest in this.  From a research perspective,
these more advanced communication systems are interesting.  From a
business perspective, there is a question about ROI for carriers.  I get
that:
there's no money in doing much more than providing the most basic voice
service, and even that service has a very small profit margin.  However,
progress, capabilities, functionality, and improvements in the way we work
and communicate should go forward, and they are.  Already, we see a number
of alternatives like Skype, Facetime, Google Hangouts, etc. and I expect
functionality will become much more interesting, with a wider mix of
multimedia applications in use at once.

Bottom line is that we should not constrain a system, but try to make it
as flexible as possible.  It might not work everywhere, but don't
constrain ourselves to the most basic voice call flow.

Paul

> > 2013/8/1 Paul E. Jones <[email-masked]> Laura,
> >
> the old session ID. Tell me how that works. Forget about the new
> solution for the moment.
> >
> we can add new end devices and application servers which support the
> new Session-ID. Otherwise we can't.
> >
> > 2013/8/1 Paul E. Jones <[email-masked]> Laura,
> >
> Calls do get manipulated in enterprise environments and call centers
> for billing purposes, privacy reasons, etc.
> >
> puts you on hold while they transfer you to a specialist (transfer out
> of consultation), for example, your SIP UA does not receive a REFER to
> initiate a new call directly to the specialist.  This is handled at
> the call center.
> >
> Carol cannot send "B" to Alice, since Alice is expecting "A".  Well,
> they could, and it would be no worse than our current proposal in
> terms of backward-compatibility.
> >
> > Paul
> >
> parameter based on direction of messages, or not.  I totally get the
> need to have a distinguishing Session-ID identifier for party-A vs.
party-B.
> What I don't get is why they need to change the encoding of the
> Session-ID header value vs. parameter, on a message direction basis.
> >
> time, while adding a parameter of "bar" for Bob that remains a
> parameter the whole time.
> it had to be swapped, but I don't remember what it is and I don't see
> it in the draft.  So I'm trying to find out why we need to do it the
> way the draft currently has it.
> >
> orthogonal to the ordering or backwards compatibility issues, and
> really shouldn't be conflated with it at all.  It has nothing to do
> with the solutions document, or the direction stuff, etc.
> >
> > -hadriel
> >
> >
> > > 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
> > > 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
> > > maintains control over the call and Alice would pay the bill for
> > > the
> call
> > > Session-ID for that call.  If Bob is put in communication with
> > > Carol,
> what
> > > 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
> > > since previously they might see a call to Carol identified as
> > > {A,C},
> but
> > > This property extends quite naturally to other signaling
> > > scenarios, as
> it
> > > 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
> > > 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
> > > 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.
> > > when we have a two UUID solution interacting with a one-UUID
> > > solution,
> we
> > > 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?
> > >
> > > However, that does not work for similar reasons.  If we have a
> > > call
> transfer
> > > 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.)
> > >
> > > explicitly what the issues are.  Further, if there are such
> > > issues, we
> need
> > > 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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 14 Aug 2013 09:56:04 +0000

Hopefully Hadriel will soon solve lots of the confusion by performing the action he took at the INSIPID meeting, which was to post revisions of the call flows with the changes needed to ensure compatibility.

That will then provide a more secure basis for argument.

That action I believe expires on Friday/Saturday/Sunday.

Keith

> Of Iain McIlwaine
> Sent: 14 August 2013 10:20
> To: Paul E. Jones; Hadriel Kaplan; Laura Liess
> Cc: [email-masked]

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 14 Aug 2013 10:13:29 +0000

The bottom line is that we attempt to meet the agreed requirements.

Your statement at the bottom could be an invitation to feature creep, and we already excluded stuff in the requirements discussion.

Regards

Keith

> an
> legacy
> through
> in
> and
> they
> > > > This property extends quite naturally to other signaling scenarios,
> as
> > it
> > > > request of a customer, but I would hope said customer appreciates
> that
> > such
> > > > explicitly what the issues are.  Further, if there are such issues,
> we
> > need

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 14 Aug 2013 10:21:37 -0400

I think it depends on how the "Transfer AS" is going to work, and what you think "manipulation" means or why it matters.  How is it any different than a PBX call transfer scenario?  Is the problem you're describing a real transfer where Bob just didn't send a 200 yet, or do you really mean a call-forwarding scenario, with early media?

If you just mean the equivalent of call-forwarding type thing, where the forwarding app server sends a 18x to generate "please wait while we locate your party" media, then that's still ok (I think). Nothing ever said the header parameter value couldn't change between responses.  So it would be like this:

Alice INVITE through AS to Bob   = "Session-ID:foo"
Bob 18x through AS to Alice      = "Session-ID:foo;remote=bar"
Bob INVITE through AS to Carol   = "Session-ID:foo"
Carol 18x/2xx through AS to Bob  = "Session-ID:foo;remote=qux"
Bob 2xx through AS to Alice      = "Session-ID:foo;remote=qux"

If you mean a real call transfer, it's going to be uglier:

Alice INVITE through PBX to Bob  = "Session-ID:foo"
Bob 18x through PBX to Alice     = "Session-ID:foo;remote=bar"
Bob INVITE through PBX to Carol  = "Session-ID:zab"
Carol 18x/2xx through PBX to Bob = "Session-ID:zab;remote=qux"
[ Bob presses some transfer button thingy, PBX transfers the Alice-Bob/Bob-Carol calls to be Alice-Carol ]
PBX can now send 2xx to Alice of = "Session-ID:foo;remote=qux" 
Or PBX can send 2xx to Alice of "Session-ID:foo;remote=zab", and send re-INVITE/UPDATE to Carol of "Session-ID:zab;remote=foo".

I personally think sending re-INVITE/UPDATEs for this thing is going to cause headaches, but if that's what people want, they can do it.

Clearly the PBX has to keep track of these Session-IDs separately on each call leg for some of these scenarios, but that's hardly a big deal - it's *already* keeping track of these as separate call-legs with a bunch of SIP state, because by definition it's acting as a SIP B2BUA with two separate SIP dialogs.

-hadriel

---

From: Iain McIlwaine <[email-masked]>
Date: Wed, 14 Aug 2013 15:54:07 +0100

The scenario in question is for an IMS access network transfer during call
setup as described by 3GPP 24.237.  After receiving the INVITE and
replying with a 18x (and thus establishing an early dialog) Bob's access
network changes.

In the case of a PS-CS transfer an MSC-S/MGCF will perform the SIP
signalling on Bob's behalf and thus have no access to what the previous
Session-ID was.  The MSC-S/MGCF initiates a call for Bob which is
reconciled at the Transfer AS using 3PCC & Access Transfer mechanisms.

In this scenario and using the proposed syntax, both Alice and Bob (well,
Bob's MSC-S/MGCF) have an equal right to assert their UUID first as
they've both created the INVITE.

How this is handled in the Transfer AS (i.e. the ATCF or the SCC) doesn't
bother me so much as they're just 3PCC/B2BUAs, what it does do however is
invalidate the Session-ID as a meaningful end 2 end tag for any service
provider offering access transfer.

Again, could be I'm misinterpreting something so happy to be corrected.

Cheers,
Iain

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: 14 August 2013 15:22
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Insipid] Proposed INSIPID solution and backward
compatibility

I think it depends on how the "Transfer AS" is going to work, and what you
think "manipulation" means or why it matters.  How is it any different
than a PBX call transfer scenario?  Is the problem you're describing a
real transfer where Bob just didn't send a 200 yet, or do you really mean
a call-forwarding scenario, with early media?

If you just mean the equivalent of call-forwarding type thing, where the
forwarding app server sends a 18x to generate "please wait while we locate
your party" media, then that's still ok (I think). Nothing ever said the
header parameter value couldn't change between responses.  So it would be
like this:

Alice INVITE through PBX to Bob  = "Session-ID:foo"
Bob 18x through PBX to Alice     = "Session-ID:foo;remote=bar"
Bob INVITE through PBX to Carol  = "Session-ID:zab"
Carol 18x/2xx through PBX to Bob = "Session-ID:zab;remote=qux"
[ Bob presses some transfer button thingy, PBX transfers the
Alice-Bob/Bob-Carol calls to be Alice-Carol ] PBX can now send 2xx to
Alice of = "Session-ID:foo;remote=qux"
Or PBX can send 2xx to Alice of "Session-ID:foo;remote=zab", and send
re-INVITE/UPDATE to Carol of "Session-ID:zab;remote=foo".

I personally think sending re-INVITE/UPDATEs for this thing is going to
cause headaches, but if that's what people want, they can do it.

Clearly the PBX has to keep track of these Session-IDs separately on each
call leg for some of these scenarios, but that's hardly a big deal - it's
*already* keeping track of these as separate call-legs with a bunch of SIP
state, because by definition it's acting as a SIP B2BUA with two separate
SIP dialogs.

-hadriel

On Aug 14, 2013, at 5:20 AM, Iain McIlwaine <[email-masked]>
wrote:

> Folks,
>
> I see a lot of discussion for enterprise transfer scenarios but I
> would like to highlight a problematic use case to gauge your opinions.
>
> Using Hadriel's method which designates local:remote of the UUID
> according to the issuer of the INVITE I can see a potential problem
> for Access Transfer when the party being transferred is in the
"proceeding" state.
> We can see in this case using Hadriel's syntax we now require the
> Transfer AS to perform manipulation of the Session-ID header which
> runs contrary to a stated objective of no intermediary meddling of the
header.
> Of course it could be I've misunderstood something so happy to be
> shown the light.
>
> Kind regards,
> Iain
>
>
>
>> within a domain (like within the call-center).  I don't mean that in
>> a negative way
> passage of an INVITE containing a new UUID value, then we can always
> have an end-to-end value.  As an "end" changes, so does the end-to-end
value.
>> providers want to get back and process a re-INVITE each and every
>> time the call gets moved around inside the call-center's internal PBX
> I really cannot do anything about these "noise" issues. I recognize
> that in practice,  much of the use of SIP has been absolutely nothing
> more than a PSTN replacement.  It has been merely a means of moving from
TDM to IP.
> applications running in various devices connected to different
> networks and associated to my "phone" where I can utilize all of them
> as a part of a "call", I see value in having this end-to-end
> identifier for even this more complex arrangement.  However, I can
> understand if service providers do not take an active interest in
> this.  From a research perspective, these more advanced communication
> systems are interesting.  From a business perspective, there is a
> question about ROI for carriers.  I get
> that:
> there's no money in doing much more than providing the most basic
> voice service, and even that service has a very small profit margin.
> However, progress, capabilities, functionality, and improvements in
> the way we work and communicate should go forward, and they are.
> Already, we see a number of alternatives like Skype, Facetime, Google
> Hangouts, etc. and I expect functionality will become much more
> interesting, with a wider mix of multimedia applications in use at once.
>
> Bottom line is that we should not constrain a system, but try to make
> it as flexible as possible.  It might not work everywhere, but don't
>> work with something that does not work. If there is a way to make
>> this work, then we can try to figure out how to interwork with it.
>>>
>>> Paul
>>>
>>>
>>>
>> puts you on hold while they transfer you to a specialist (transfer
>> out of consultation), for example, your SIP UA does not receive a
>> REFER to initiate a new call directly to the specialist.  This is
>> handled at the call center.
>>>
>>>> two-part Session Identifier.  The reason is that we have to be able
>>>> to
>> effectively
>>>> such things as mid-call transfers that happen on a PBX like the one
>>>> I described above?
>>>>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 14 Aug 2013 12:44:55 -0400

Ahh right - it's been a while since I read that spec, and it's painfully long and complicated.  :)

So in the case of the MSC performing a continuity transfer on behalf of Bob, I essentially think of it as a INVITE with Replaces model, except without the Replaces info.  The ATCF is like a PBX, and the scenario is almost like a PBX barge-in feature, from a 50k-foot view.  And just like a barge-in, if you really want all sides to get updated to have a consistent Session-ID param value, it might require a re-INVITE/UPDATE be sent everywhere.  

With the legacy way of doing Session-ID but with also a remote param, it could be like this:

Alice INVITE through ATCF to Bob  = "Session-ID:foo"
Bob 18x through ATCF to Alice     = "Session-ID:foo;remote=bar"

[ Bob loses PS and MSC triggers call continuity ]

MSC INVITE to ATCF                = "Session-ID:zab"
ATCF 200 to MSC                   = "Session-ID:zab;remote=foo"
ATCF 200 to Alice                 = "Session-ID:foo;remote=zab"

Or depending on state of call and also depending on logic of ATCF, ATCF could instead send back something else and eventually sends re-INVITE/UPDATE to both parties, to create a consistent parameter value.

I have a hard time believing an IMS provider would want to send SIP re-INVITEs across their peering connections to the other carriers the call came in from, just because their local UE switched from VoLTE to 3GPP or whatever.  Nor do I think the other carriers want to get such re-INVITEs from them.

With regards to "it invalidates the Session-ID as a meaningful e2e tag", yes it does - the parameter might be consistent (eventually), but the header value itself isn't.  But the real question is what would the Session-ID be *used for* - just having an e2e tag is not an end goal... there has to be some purpose to it.  With the original Session-ID draft, the purpose was troubleshooting, and when we debated whether to send re-INVITE/UPDATEs everywhere in order to handle the more complicated scenarios, the consensus was that no one wanted to do that (for obvious reasons).

I think what some people have in mind is simply a value that is consistent within their local domain.  But that's a horse of a different color, I think.

-hadriel

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 15 Aug 2013 04:14:53 +0530

Hadriel/Iain,

I agree with Iain that end-to-end session-id is not possible with eSRVCC
(3GPP 24.237) in IMS environment. My understanding is that ATCF is
introduced just to avoid the end-to-end signaling callflow.

The callflow is as follows:

1) Session is established between Alice & Bob with session id=foo;remote=bar

2) Alice moved from PS to CS. 
3) MSC starts new INVITE with session-id=zab
4) ATCF has to send 200 OK to MSC with session-id=zab;remote=bar
5) ATCF shall Re-INVITE with session-id=zab;remote=bar towards SCC-AS
6) SCC-AS sends 200 OK with session-id=zab;remote=bar

Please note that bob is not aware of session-id update of "foo" to "zab".
There is no end-to-end session-id in these callflows. 

Thanks
Partha

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hadriel Kaplan
> Sent: Wednesday, August 14, 2013 10:15 PM
> So in the case of the MSC performing a continuity transfer on behalf of
> Bob, I essentially think of it as a INVITE with Replaces model, except
> without the Replaces info.  The ATCF is like a PBX, and the scenario is
> almost like a PBX barge-in feature, from a 50k-foot view.  And just
> like a barge-in, if you really want all sides to get updated to have a
> consistent Session-ID param value, it might require a re-INVITE/UPDATE
> be sent everywhere.
> 
> Or depending on state of call and also depending on logic of ATCF, ATCF
> could instead send back something else and eventually sends re-
> INVITE/UPDATE to both parties, to create a consistent parameter value.
> 
> I have a hard time believing an IMS provider would want to send SIP re-
> INVITEs across their peering connections to the other carriers the call
> came in from, just because their local UE switched from VoLTE to 3GPP
> or whatever.  Nor do I think the other carriers want to get such re-
> INVITEs from them.
> 
> With regards to "it invalidates the Session-ID as a meaningful e2e
> tag", yes it does - the parameter might be consistent (eventually), but
> the header value itself isn't.  But the real question is what would the
> Session-ID be *used for* - just having an e2e tag is not an end goal...
> there has to be some purpose to it.  With the original Session-ID
> draft, the purpose was troubleshooting, and when we debated whether to
> send re-INVITE/UPDATEs everywhere in order to handle the more
> complicated scenarios, the consensus was that no one wanted to do that
> (for obvious reasons).
> 
> I think what some people have in mind is simply a value that is
> consistent within their local domain.  But that's a horse of a
> different color, I think.
> 
> -hadriel
> 
> 
> >>>> There is no correlation between them. We just correlate both legs
> of
> >>>> the
> >>>> We use the old Session-ID only accross SBCs, to correlate both
> legs
> >>>> of
> >>> the old one which we have in thousands of customer end devices. If
> it
> >> does,
> >>>> From: [email-masked] [mailto:[email-masked]]
> On
> >>> Behalf Of Laura Liess
> >>>> I *think* there was a reason someone came up with at one time as
> to
> >>>> why
> able
> >>>>> When initiating a call and using a single UUID value, that has
> the
> >>> potential
> >>>>> bill?  Well, to address that, we do call transfer locally on
> PBXes.
> >>> The PBX
> >>>>> is the Session-ID value?  Bob had one and Carol had a different
> one.
> >>> What
> >>>>> is the new ID?
> >>>>>
> scenarios,
> one
> >>>>> requirement.  Where it falls short, we do not know: we've not
> been
> >>> told
> issues,

---

From: Iain McIlwaine <[email-masked]>
Date: Thu, 15 Aug 2013 13:32:35 +0100

"> Ahh right - it's been a while since I read that spec, and it's
> painfully long and complicated.  :)"

Yes, yes it is indeed.....

So I guess this is one scenario where the syntax doesn't quite work
without additional logic of re-INVITE/UPDATE.  However, Hadriel does make
a good point in asking what this header  would be used for.

The predecessor Session-ID draft managed to sneak into 24.229 as a means
of assisting with the IR.92 approved ad-hoc multi party conference (big
thanks to GSMA for selecting the trickiest multi party implementation
method there).  Now I know this is way out of the scope of the current
discussions but if the cap fits folks will wear it. (In the interest of
full disclosure, this is actually the angle that got me interested in this
draft rather than the troubleshooting aspect).

Naturally this puts my concern a tad lower in the priority list.

Kind Regards,
Iain

-----Original Message-----
From: Parthasarathi R [mailto:[email-masked]]
Sent: 14 August 2013 23:45
To: 'Hadriel Kaplan'; [email-masked]
Cc: [email-masked]
Subject: RE: [Insipid] Proposed INSIPID solution and backward
compatibility

Hadriel/Iain,

1) Session is established between Alice & Bob with session
id=foo;remote=bar

Thanks
Partha

> So in the case of the MSC performing a continuity transfer on behalf
> of Bob, I essentially think of it as a INVITE with Replaces model,
> except without the Replaces info.  The ATCF is like a PBX, and the
> scenario is almost like a PBX barge-in feature, from a 50k-foot view.
> And just like a barge-in, if you really want all sides to get updated
> to have a consistent Session-ID param value, it might require a
> re-INVITE/UPDATE be sent everywhere.
>
> Or depending on state of call and also depending on logic of ATCF,
> ATCF could instead send back something else and eventually sends re-
> I have a hard time believing an IMS provider would want to send SIP
> re- INVITEs across their peering connections to the other carriers the
> call came in from, just because their local UE switched from VoLTE to
> 3GPP or whatever.  Nor do I think the other carriers want to get such
> re- INVITEs from them.
>
> tag", yes it does - the parameter might be consistent (eventually),
> but the header value itself isn't.  But the real question is what
> would the Session-ID be *used for* - just having an e2e tag is not an
end goal...
> > The scenario in question is for an IMS access network transfer
> > during
> call
> > Alice-Bob/Bob-Carol calls to be Alice-Carol ] PBX can now send 2xx
> > to Alice of = "Session-ID:foo;remote=qux"
> > Or PBX can send 2xx to Alice of "Session-ID:foo;remote=zab", and
> > send re-INVITE/UPDATE to Carol of "Session-ID:zab;remote=foo".
> >
> >> Behalf Of Paul E. Jones
> >>> I can't tell if you seriously believe the new mechanism is going
> >>> to work end-to-end across all domains, or if you just mean
> >>> end-to-end within a domain (like within the call-center).  I don't
> >>> mean that
> in
> >>> a negative way
> >> passage of an INVITE containing a new UUID value, then we can
> >> always have an end-to-end value.  As an "end" changes, so does the
> >> end-to-
> end
> > value.
> >> That's OK.
> >>
> >>> answering them locally because the service providers don't want
> >>> nor need those re-INVITEs.  It's just extra processing load, log
> entries,
> >> it as flexible as possible.  It might not work everywhere, but
> >> don't constrain ourselves to the most basic voice call flow.
> >>
> >> Paul
> >>
> >>> -hadriel
> >>>
> >>>
> >>>> Neither Alice nor Bob are confused about which one is "their"
> >>>> UUID
> >> value.
> >>> really shouldn't be conflated with it at all.  It has nothing to
> >>> do with the solutions document, or the direction stuff, etc.
> >>>>
> >>>> -hadriel
> >>>>
> >>>>
> >>>> On Aug 1, 2013, at 12:38 AM, Paul E. Jones
> >>>> <[email-masked]>
> >> wrote:
> >>>>
> >>>>> Folks,
> >>>>>
> >>>>> to go end-to-end. However, if a call is forked there are
> >>>>> multiple
> >>> "ends".
> >>>>> 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
> >>>>> transfer.  But if Alice was talking to Carol before the
> >>>>> transfer,
> >>> there is a
> >>>>> 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,
> >>>>> 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.
> >>>>>
> >>>>> 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
> >>>>> to also understand how those would be handled in the face of
> >>>>> call
> >>> transfer
> >>>>> we can find a solution that works for the enterprise use cases
> >>>>> as well
> >>> as

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 15 Aug 2013 10:18:40 -0400

I haven't kept up with what 3GPP is planning to use this for, but if it's the resource-list thing from a couple years ago, I think that wasn't going to work right either.  In the old kaplan session-id draft it talked about such correlation in 3GPP and explains why session-id is not really a solution for that.

This was put in the end of the Appendix in old draft:
http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-03#appendix-A.1

Somehow that last page or two got cut off in the kaplan draft being submitted right now for Informational, which is super-annoying.
:(

-hadriel

---

From: Iain McIlwaine <[email-masked]>
Date: Thu, 15 Aug 2013 16:19:51 +0100

Yeah that Appendix seemed to miss a few people around me too, I only
spotted it by using the rather handy revision compare tool.

So the problem with the GSMA selected ad-hoc conf mechanism is that the
conferencing server is responsible for inviting Bob & Carol (who are
already in a session with Alice) to the conference and to replace the
existing session with Alice.  Trouble is, the Replaces-Header has the
to/from tags that Alice knows and these may only be relevant between Alice
and the first B2BUA. Chances are the tags Bob & Carol know will be
different.  Session-ID looked like a very tempting augmentation to the
Replaces-Header.

-iain.
-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]]
Sent: 15 August 2013 15:19
To: [email-masked]
Cc: Parthasarathi R; [email-masked]
Subject: Re: [Insipid] Proposed INSIPID solution and backward
compatibility

I haven't kept up with what 3GPP is planning to use this for, but if it's
the resource-list thing from a couple years ago, I think that wasn't going
to work right either.  In the old kaplan session-id draft it talked about
such correlation in 3GPP and explains why session-id is not really a
solution for that.

This was put in the end of the Appendix in old draft:
http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-03#appendix-A.
1

Somehow that last page or two got cut off in the kaplan draft being
submitted right now for Informational, which is super-annoying.
:(

-hadriel

On Aug 15, 2013, at 8:32 AM, Iain McIlwaine <[email-masked]>
wrote:

> without additional logic of re-INVITE/UPDATE.  However, Hadriel does
> make a good point in asking what this header  would be used for.
>
> The predecessor Session-ID draft managed to sneak into 24.229 as a
> means of assisting with the IR.92 approved ad-hoc multi party
> conference (big thanks to GSMA for selecting the trickiest multi party
> implementation method there).  Now I know this is way out of the scope
> of the current discussions but if the cap fits folks will wear it. (In
> the interest of full disclosure, this is actually the angle that got
> me interested in this draft rather than the troubleshooting aspect).
>
> I agree with Iain that end-to-end session-id is not possible with
> eSRVCC (3GPP 24.237) in IMS environment. My understanding is that ATCF
> is introduced just to avoid the end-to-end signaling callflow.
>
>> re- INVITEs across their peering connections to the other carriers
>> the call came in from, just because their local UE switched from
>> VoLTE to 3GPP or whatever.  Nor do I think the other carriers want to
>> get such
>> re- INVITEs from them.
>>
>> draft, the purpose was troubleshooting, and when we debated whether
>> to send re-INVITE/UPDATEs everywhere in order to handle the more
>> complicated scenarios, the consensus was that no one wanted to do
>> that (for obvious reasons).
>>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 17 Aug 2013 11:01:51 -0400

> end-to-end value.  As an "end" changes, so does the end-to-end value.

OK, but an end-to-end for what *purpose*.  Having a common UUID on all ends is not a goal in itself - it has to be useful for something.  Expecting a flurry of re-INVITEs to go across the world is a big deal, in practice.  Service providers won't want to deal with that just for sake of posterity.  The whole premise behind Session-ID was everyone would be ok with passing it through only so long as it was benign.  That's the "contract" we were making, to get B2BUAs to pass it through without worrying about negative consequences.

> glad it happened, but it's more than unfortunate if that's all we

I think Service Providers don't want just a PSTN replacement forever - some might, for sure - but a lot of them bought into SIP (and even IMS) with the goal of eventually being able to do a lot more than just PSTN-type phone calls.  So far they've been heavily constrained due to having to migrate their existing infrastructure because of course it's the near-term cost-savings goal.  The same is true in Enterprise - most of them bought into VoIP for its long-term potential for new things, but the short-term goal was cost-savings and replacing their existing PBXs and TDM/PRI trunks.  Service providers move slowly, because they have an existing highly-reliable system people pay money for and depend on 911 service for and so on, and because it's highly regulated by governments in weird ways... but the long-term vision continues to be to go beyond just PSTN phone calls.

> multimedia applications in use at once.

Actually in my experience Service Providers are quite willing to do new things so long as there's some benefit in it for them - same with Enterprises, for that matter.  If we can identify some actual *purpose* for having an end-to-end identifier across service providers beyond troubleshooting, then we can figure out what benefit or detriment that might have for Service Providers.  IF it just costs them more money without adding anything, it won't happen.

-hadriel

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 20 Aug 2013 14:40:04 -0400

Hadriel,

> have an
> OK, but an end-to-end for what *purpose*.  Having a common UUID on all
> ends is not a goal in itself - it has to be useful for something.

This actually has a variety of purposes.  One is troubleshooting, since we
can identify precisely through which elements a call passed, including cases
where a call started out as an H.323 call and terminated somewhere as a SIP
call.  We have some features where we can invoke recoding of media, media
tests, etc. that can be invoked even when a call is in progress.  Having
this identifier can be used for those things, plus post-call log inspection.

> Expecting a flurry of re-INVITEs to go across the world is a big deal, in
> practice.  Service providers won't want to deal with that just for sake of
> posterity.  The whole premise behind Session-ID was everyone would be ok
> with passing it through only so long as it was benign.  That's the
> "contract" we were making, to get B2BUAs to pass it through without
> worrying about negative consequences.

Right, but if we want to identify a call end-to-end, we must allow those
identifiers to pass through end-to-end.  Quite likely, it does not matter
too much if it does get "terminated", effectively, at the enterprise edge.
That's especially true if the call is essentially handed to the SP for
delivery.  The enterprise would not expect to have visibility into the SP
network, anyway.

That said, it is important that any over-the-top signaling is unaffected.
If there are two remote offices connected via the Internet, it should be
possible for a network admin to have visibility of the call legs inside each
remote office from the central office.

> I think Service Providers don't want just a PSTN replacement forever -
> some might, for sure - but a lot of them bought into SIP (and even IMS)
> with the goal of eventually being able to do a lot more than just PSTN-
> type phone calls.  So far they've been heavily constrained due to having
> to migrate their existing infrastructure because of course it's the near-
> term cost-savings goal.  The same is true in Enterprise - most of them
> bought into VoIP for its long-term potential for new things, but the
> short-term goal was cost-savings and replacing their existing PBXs and
> TDM/PRI trunks.  Service providers move slowly, because they have an
> existing highly-reliable system people pay money for and depend on 911
> service for and so on, and because it's highly regulated by governments in
> weird ways... but the long-term vision continues to be to go beyond just
> PSTN phone calls.

Perhaps, but I see business challenges to doing anything more than basic
voice, given all of the free alternatives popping up everywhere that have a
lot of rich multimedia capabilities.  This is really a side issue, though,
and I'd be fully supportive if the service providers can find a workable
business model where richer communications were made possible.  With that,
though, is definitely going to be a lot more signaling.  This notion of
reducing messages on the wire really needs a re-think ;-)
 
> Actually in my experience Service Providers are quite willing to do new
> things so long as there's some benefit in it for them - same with
> Enterprises, for that matter.  If we can identify some actual *purpose*
> for having an end-to-end identifier across service providers beyond
> troubleshooting, then we can figure out what benefit or detriment that
> might have for Service Providers.  IF it just costs them more money
> without adding anything, it won't happen.

Beyond troubleshooting is a challenge, unless I mention some of the media
things we intend to use it for.  However, right now we're just talking about
the signaling side of things.  The utility in signaling seems to relate only
to troubleshooting and signaling diagnostics.  There are more interesting
aspects on the media side of things, but we cannot even consider those
without support on the signaling side.

Paul