Re: [Insipid] Proposed INSIPID solution and backward compatibility
Iain McIlwaine <iain.mcilwaine@opencloud.com> Thu, 15 August 2013 15:20 UTC
Return-Path: <imcilwaine@opencloud.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAE521E8163 for <insipid@ietfa.amsl.com>; Thu, 15 Aug 2013 08:20:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.529
X-Spam-Level:
X-Spam-Status: No, score=-4.529 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_56=0.6, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TNgYFym4Adg for <insipid@ietfa.amsl.com>; Thu, 15 Aug 2013 08:20:38 -0700 (PDT)
Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with SMTP id 87F1521F99EC for <insipid@ietf.org>; Thu, 15 Aug 2013 08:19:58 -0700 (PDT)
Received: from mail-vb0-f43.google.com ([209.85.212.43]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKUgzxmdnCckp+/UxrNyq/v0McO5dTTWe5@postini.com; Thu, 15 Aug 2013 08:19:58 PDT
Received: by mail-vb0-f43.google.com with SMTP id h11so679443vbh.30 for <insipid@ietf.org>; Thu, 15 Aug 2013 08:19:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:reply-to:from:references:in-reply-to :mime-version:thread-index:date:message-id:subject:to:cc :content-type; bh=lUOtjYGsr8U3xwp0Nuv+nMM7Un8t1yzSBRvyQm/bX+Q=; b=NlQrsaZvvy/kzXcY0Kapp1xEE1EFtCHUR2dPcvpEOs5mjfknznkXxqE8f71zyH2/ov ZVkQSUWk3GN/ochglF1CjdCdmZXdn3tQKC0tFbj3WiDT5p46SLEo2gg+j01WEY5WSmQ2 L2PGxM1sm9WGgQRanmEHl5z6xblBNPETCZIWrWDsuDPuUpyaaqShvIbSc2r1dlhaKsvQ ZUVmAQe+JeA2FEstWkzyF+GVKbaOPHpyrGtFPnJ/1EDbT1jSaY+CTDvu1MCImh0r3kPV nuVCwfWO8R3IevS83RbpptXG0w4IrVzQZHYpa/gw5ihh4+lEBb9K6jYxlvAwHOLCeOil n2xg==
X-Gm-Message-State: ALoCoQmsh3KRCroOgB0P8N5rVoSHgIaJpzbAhXnda319S8L2dqUhWxad8umieLhkjUWZwAlM3ESY5QVAxraOR7VluN0qf3p+EOVUtpD3F+B5apvsCGiz6eIIzR1hvHWhe9AKcOYVYZ34xlAnuBp5R/lOXzMSCXYdIw==
X-Received: by 10.58.219.68 with SMTP id pm4mr498863vec.49.1376579993075; Thu, 15 Aug 2013 08:19:53 -0700 (PDT)
X-Received: by 10.58.219.68 with SMTP id pm4mr498856vec.49.1376579992906; Thu, 15 Aug 2013 08:19:52 -0700 (PDT)
From: Iain McIlwaine <iain.mcilwaine@opencloud.com>
References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <CACWXZj1UKUypTrm65_41TAXWCFounEH8KjrHe+zLd4ui9_t6NA@mail.gmail.com> <CACWXZj3zH2tYCrXGt7eO4qf0XmJtveW1RmyDObph=2Ep-UirfA@mail.gmail.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> <CACWXZj3dyhZ4KPYavuinzCpfsGNhyUg-pKxAPxF1bgdaQ=8Sqg@mail.gmail.com> <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> <CACWXZj2TA=05j48EYEJrTbAGmSWDKRRWz38fBjrmrdgDOF6=rw@mail.gmail.com> <01e101ce8f97$ad597dc0$080c7940$@packetizer.com> <1FCC9EF2-11C9-4720-B7CD-2D9ECBCAFD62@oracle.com> <035201ce9875$3c94e6b0$b5beb410$@packetizer.com> <942d8175ef27dbb82e58f70faead1038@mail.gmail.com> <BBD2BDFC-1BF1-4E58-9E07-55ED2A9E088C@oracle.com> <5acd5207a04d040a0569fbb581b932c1@mail.gmail.com> <888D13B0-84DF-419C-8979-9563ACE18FB7@oracle.com> <001601ce993f$e8ae00b0$ba0a0210$@co.in> <d52caaf23601eaac8ed32ac7918cb1cc@mail.gmail.com> <50E3B10B-4D80-44E4-B104-5D934CF25E7F@oracle.com>
In-Reply-To: <50E3B10B-4D80-44E4-B104-5D934CF25E7F@oracle.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQKz7rH6at3CfOd36gKULeT/c9opXwFpbrGEArQAdNoCZGOF7QESgoClAbrwr+cBsgX+YwFp44IVAeURpWICV7apKQJk1zw7AyhdJqEBmNnemgICOl9WAocGH+sBuC/YTAFBubF6ATyubeyWx0d9AA==
Date: Thu, 15 Aug 2013 16:19:51 +0100
Message-ID: <58394fb8162dae76ece155d4fa95cc6f@mail.gmail.com>
To: Hadriel Kaplan <hadriel.kaplan@oracle.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: insipid@ietf.org, Parthasarathi R <partha@parthasarathi.co.in>
Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: iain.mcilwaine@opencloud.com
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/insipid>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Aug 2013 15:20:43 -0000
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:hadriel.kaplan@oracle.com] Sent: 15 August 2013 15:19 To: iain.mcilwaine@opencloud.com Cc: Parthasarathi R; insipid@ietf.org 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 <iain.mcilwaine@opencloud.com> 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:partha@parthasarathi.co.in] > Sent: 14 August 2013 23:45 > To: 'Hadriel Kaplan'; iain.mcilwaine@opencloud.com > Cc: insipid@ietf.org > 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: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >> Behalf Of Hadriel Kaplan >> Sent: Wednesday, August 14, 2013 10:15 PM >> To: iain.mcilwaine@opencloud.com >> Cc: insipid@ietf.org >> 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 >> <iain.mcilwaine@opencloud.com> 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:hadriel.kaplan@oracle.com] >>> Sent: 14 August 2013 15:22 >>> To: iain.mcilwaine@opencloud.com >>> Cc: insipid@ietf.org >>> 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 >> <iain.mcilwaine@opencloud.com> >>> 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: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>>> Behalf Of Paul E. Jones >>>> Sent: 13 August 2013 23:34 >>>> To: 'Hadriel Kaplan' >>>> Cc: insipid@ietf.org; '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 <paulej@packetizer.com> >>>> 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:laura.liess.dt@googlemail.com] >>>>>> Sent: Friday, August 02, 2013 4:47 AM >>>>>> To: Paul E. Jones >>>>>> Cc: insipid@ietf.org >>>>>> 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 <paulej@packetizer.com> 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 <laura.liess.dt@googlemail.com> >>>>>> Sent: Thu Aug 01 11:51:26 EDT 2013 >>>>>> >>>>>> To: "Paul E. Jones" <paulej@packetizer.com> >>>>>> Cc: insipid@ietf.org >>>>>> >>>>>> 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 <paulej@packetizer.com> 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: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] >> On >>>>> Behalf Of Laura Liess >>>>>> Sent: Thursday, August 01, 2013 9:13 AM >>>>>> To: insipid@ietf.org >>>>>> >>>>>> Subject: Re: [Insipid] Proposed INSIPID solution and backward >>>>> compatibility >>>>>> >>>>>> >>>>>> Hadriel's proposal works for us. >>>>>> >>>>>> Thank you >>>>>> Laura >>>>>> >>>>>> >>>>>> 2013/8/1 Hadriel Kaplan <hadriel.kaplan@oracle.com> >>>>>> >>>>>> 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 >>>>>> <paulej@packetizer.com> >>>> 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 >>>>>>> insipid@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/insipid >>>>>> >>>>>> _______________________________________________ >>>>>> insipid mailing list >>>>>> insipid@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/insipid >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> insipid mailing list >>>>>> insipid@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/insipid >>>> >>>> >>>> _______________________________________________ >>>> insipid mailing list >>>> insipid@ietf.org >>>> https://www.ietf.org/mailman/listinfo/insipid >>>> _______________________________________________ >>>> insipid mailing list >>>> insipid@ietf.org >>>> https://www.ietf.org/mailman/listinfo/insipid >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >> >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid
- [Insipid] Proposed INSIPID solution and backward … Paul E. Jones
- Re: [Insipid] Proposed INSIPID solution and backw… Hadriel Kaplan
- Re: [Insipid] Proposed INSIPID solution and backw… Andrew Allen
- Re: [Insipid] Proposed INSIPID solution and backw… Paul Kyzivat
- Re: [Insipid] Proposed INSIPID solution and backw… Laura Liess
- Re: [Insipid] Proposed INSIPID solution and backw… Paul E. Jones
- Re: [Insipid] Proposed INSIPID solution and backw… Paul E. Jones
- Re: [Insipid] Proposed INSIPID solution and backw… Paul E. Jones
- Re: [Insipid] Proposed INSIPID solution and backw… Laura Liess
- Re: [Insipid] Proposed INSIPID solution and backw… Paul E. Jones
- Re: [Insipid] Proposed INSIPID solution and backw… Hadriel Kaplan
- Re: [Insipid] Proposed INSIPID solution and backw… Paul E. Jones
- Re: [Insipid] Proposed INSIPID solution and backw… Hadriel Kaplan
- Re: [Insipid] Proposed INSIPID solution and backw… Paul E. Jones
- Re: [Insipid] Proposed INSIPID solution and backw… Hadriel Kaplan
- Re: [Insipid] Proposed INSIPID solution and backw… Hadriel Kaplan
- Re: [Insipid] Proposed INSIPID solution and backw… Hadriel Kaplan
- Re: [Insipid] Proposed INSIPID solution and backw… Andrew Allen
- Re: [Insipid] Proposed INSIPID solution and backw… DRAGE, Keith (Keith)
- Re: [Insipid] Proposed INSIPID solution and backw… Andrew Allen
- Re: [Insipid] Proposed INSIPID solution and backw… Laura Liess
- Re: [Insipid] Proposed INSIPID solution and backw… DRAGE, Keith (Keith)
- Re: [Insipid] Proposed INSIPID solution and backw… Andrew Allen
- Re: [Insipid] Proposed INSIPID solution and backw… Paul E. Jones
- Re: [Insipid] Proposed INSIPID solution and backw… Paul E. Jones
- Re: [Insipid] Proposed INSIPID solution and backw… Paul E. Jones
- Re: [Insipid] Proposed INSIPID solution and backw… Paul E. Jones
- Re: [Insipid] Proposed INSIPID solution and backw… Hadriel Kaplan
- Re: [Insipid] Proposed INSIPID solution and backw… Hadriel Kaplan
- Re: [Insipid] Proposed INSIPID solution and backw… Hadriel Kaplan
- Re: [Insipid] Proposed INSIPID solution and backw… Hadriel Kaplan
- Re: [Insipid] Proposed INSIPID solution and backw… Paul E. Jones
- Re: [Insipid] Proposed INSIPID solution and backw… Paul E. Jones
- Re: [Insipid] Proposed INSIPID solution and backw… Iain McIlwaine
- Re: [Insipid] Proposed INSIPID solution and backw… DRAGE, Keith (Keith)
- Re: [Insipid] Proposed INSIPID solution and backw… DRAGE, Keith (Keith)
- Re: [Insipid] Proposed INSIPID solution and backw… Hadriel Kaplan
- Re: [Insipid] Proposed INSIPID solution and backw… Iain McIlwaine
- Re: [Insipid] Proposed INSIPID solution and backw… Hadriel Kaplan
- Re: [Insipid] Proposed INSIPID solution and backw… Parthasarathi R
- Re: [Insipid] Proposed INSIPID solution and backw… Iain McIlwaine
- Re: [Insipid] Proposed INSIPID solution and backw… Hadriel Kaplan
- Re: [Insipid] Proposed INSIPID solution and backw… Iain McIlwaine
- Re: [Insipid] Proposed INSIPID solution and backw… Hadriel Kaplan
- Re: [Insipid] Proposed INSIPID solution and backw… Paul E. Jones