Re: [Insipid] Proposed INSIPID solution and backward compatibility

[Hadriel Kaplan <[e-mail]>]

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 <[e-mail]> wrote:

> "> 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:[e-mail]]
> Sent: 14 August 2013 23:45
> To: 'Hadriel Kaplan'; [e-mail]
> Cc: [e-mail]
> Subject: RE: [Insipid] Proposed INSIPID solution and backward
> compatibility
> 
> 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
> 
> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Hadriel Kaplan
>> Sent: Wednesday, August 14, 2013 10:15 PM
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: Re: [Insipid] Proposed INSIPID solution and backward
>> compatibility
>> 
>> 
>> 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
>> 
>> 
>> On Aug 14, 2013, at 10:54 AM, Iain McIlwaine
>> <[e-mail]> wrote:
>> 
>>> 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:[e-mail]]
>>> Sent: 14 August 2013 15:22
>>> To: [e-mail]
>>> Cc: [e-mail]
>>> 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 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
>>> 
>>> 
>>> On Aug 14, 2013, at 5:20 AM, Iain McIlwaine
>> <[e-mail]>
>>> 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.
>>>> 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: [e-mail] [mailto:[e-mail]] On
>>>> Behalf Of Paul E. Jones
>>>> Sent: 13 August 2013 23:34
>>>> To: 'Hadriel Kaplan'
>>>> Cc: [e-mail]; '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 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
>>>> 
>>>>> -hadriel
>>>>> 
>>>>> 
>>>>> On Aug 2, 2013, at 11:48 AM, Paul E. Jones <[e-mail]>
>>>> 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
>>>>>> 
>>>>>> From: Laura Liess [mailto:[e-mail]]
>>>>>> Sent: Friday, August 02, 2013 4:47 AM
>>>>>> To: Paul E. Jones
>>>>>> Cc: [e-mail]
>>>>>> Subject: Re: [Insipid] Proposed INSIPID solution and backward
>>>>> compatibility
>>>>>> 
>>>>>> 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
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 2013/8/1 Paul E. Jones <[e-mail]> 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 <[e-mail]>
>>>>>> Sent: Thu Aug 01 11:51:26 EDT 2013
>>>>>> 
>>>>>> To: "Paul E. Jones" <[e-mail]>
>>>>>> Cc: [e-mail]
>>>>>> 
>>>>>> Subject: Re: [Insipid] Proposed INSIPID solution and backward
>>>>> compatibility
>>>>>> 
>>>>>> 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 <[e-mail]> 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: [e-mail] [mailto:[e-mail]]
>> On
>>>>> Behalf Of Laura Liess
>>>>>> Sent: Thursday, August 01, 2013 9:13 AM
>>>>>> To: [e-mail]
>>>>>> 
>>>>>> Subject: Re: [Insipid] Proposed INSIPID solution and backward
>>>>> compatibility
>>>>>> 
>>>>>> 
>>>>>> Hadriel's proposal works for us.
>>>>>> 
>>>>>> Thank you
>>>>>> Laura
>>>>>> 
>>>>>> 
>>>>>> 2013/8/1 Hadriel Kaplan <[e-mail]>
>>>>>> 
>>>>>> 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
>>>>>> <[e-mail]>
>>>> 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
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/insipid
>>>>>> 
>>>>>> _______________________________________________
>>>>>> insipid mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/insipid
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> insipid mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/insipid
>>>> 
>>>> 
>>>> _______________________________________________
>>>> insipid mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/insipid
>>>> _______________________________________________
>>>> insipid mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/insipid
>>> _______________________________________________
>>> insipid mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/insipid
>> 
>> _______________________________________________
>> insipid mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/insipid
> _______________________________________________
> insipid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/insipid