From KENNETH.G.CARLBERG@saic.com Thu Dec 1 05:10:14 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832F921F8DE6 for ; Thu, 1 Dec 2011 05:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 zQz0xe3AP4gL for ; Thu, 1 Dec 2011 05:10:14 -0800 (PST) Received: from mclmx2.mail.saic.com (mclmx2.mail.saic.com [149.8.64.32]) by ietfa.amsl.com (Postfix) with ESMTP id D388B21F8DD0 for ; Thu, 1 Dec 2011 05:10:13 -0800 (PST) Received: from 0015-its-sbg01.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com with ESMTP id BT-MMP-10153188; Thu, 1 Dec 2011 08:10:10 -0500 X-AuditID: 9508401a-b7c12ae000001ea6-8d-4ed77cb2a512 Received: from 0015-ITS-EXBH01.us.saic.com (mcl-sixl-nat.saic.com [149.8.64.21]) by 0015-its-sbg01.saic.com (Symantec Brightmail Gateway) with SMTP id 54.11.07846.2BC77DE4; Thu, 1 Dec 2011 08:10:10 -0500 (EST) Received: from 0015-its-exmb11.us.saic.com ([10.43.229.22]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Dec 2011 08:10:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Dec 2011 08:10:10 -0500 Message-Id: In-Reply-To: <501C9ECF-0559-45A4-A547-EBD987D14F8B@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PSAP Callback indication: Resrouce-Priority instead ofeGRUU Thread-Index: AcyvySpPNzzk92pESDumIcPfHpVikwAYQSJg References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se><201111300226.pAU2QOeO016560@mtv-core-2.cisco.com><7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se><4ED646F5.30300@alum.mit.edu><7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se><4ED68923.4060808@alum.mit.edu><201111302100.pAUL0dBU010082@mtv-core-4.cisco.com><4ED6A114.1060504@alum.mit.edu><7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFB@ESESSCMS0356.eemea.ericsson.se> <501C9ECF-0559-45A4-A547-EBD987D14F8B@cs.columbia.edu> From: "Carlberg, Kenneth G." To: "Henning Schulzrinne" , "Christer Holmberg" X-OriginalArrivalTime: 01 Dec 2011 13:10:10.0513 (UTC) FILETIME=[8E0B6C10:01CCB02A] X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , ECRIT Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead ofeGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 13:10:14 -0000 Unless I missed something, there isn't anything in the approach that identifies the UAs as being associated with a PSAP, and so nothing to distinguish it from any other UA. As a result, while item 3 below points out that the approach does not promote abuse risk, its still subject to malicious DoS attacks. Correct? -ken > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Henning Schulzrinne > Sent: Wednesday, November 30, 2011 8:33 PM > To: Christer Holmberg > Cc: Adam Roach; ECRIT > Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead > ofeGRUU > =20 > Here's a slightly different model: > =20 > (1) The UA requests (or automatically gets) a special emergency (temp) > GRUU; we can request this in some way, probably using a Contact > parameter. sip.priority=3Demergency would probably work if we want to re- > use something. > =20 > (2) The UA uses that GRUU in the emergency call. There is no need to > mark it - the PSAP has no control over call handling at the emergency > caller anyway, so it does the same thing whether the UA knows about > special handling or not. > =20 > (3) The PSAP places a normal call-back. The proxy knows that this is a > special GRUU that will only be used for emergency calls, so it can do > all bypass actions it wants. Since the UA won't use this GRUU for > "normal" calls, there is no abuse risk. > =20 > Henning > =20 > On Nov 30, 2011, at 4:43 PM, Christer Holmberg wrote: > =20 > > > > Hi, > > > >>> I think you still need a GRUU (at least). > >> > >> Maybe gruu helps here, maybe not. It seems that gruu isn't sufficient > to bypass call barring policies. If something else is needed for that > then gruu may be irrelevant. > > > > The proposal was that the emergency gruu would contain a "psapcb" > token, which would have been used as an indicator for bypassing policies > etc. > > > > (But, yes, the verification of the sender still applies also to the > egruu) > > > > Regards, > > > =20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hgs@cs.columbia.edu Thu Dec 1 05:15:29 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627F811E80D5 for ; Thu, 1 Dec 2011 05:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 WPPwwkGepmNK for ; Thu, 1 Dec 2011 05:15:28 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC9F11E80C8 for ; Thu, 1 Dec 2011 05:15:28 -0800 (PST) Received: from upstairs-3.home (pool-96-242-116-37.nwrknj.fios.verizon.net [96.242.116.37]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id pB1DFN3G029075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 1 Dec 2011 08:15:24 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: Date: Thu, 1 Dec 2011 08:15:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7664C222-C454-40F5-A6B7-6F13785D6D7A@cs.columbia.edu> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se><201111300226.pAU2QOeO016560@mtv-core-2.cisco.com><7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se><4ED646F5.30300@alum.mit.edu><7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se><4ED68923.4060808@alum.mit.edu><201111302100.pAUL0dBU010082@mtv-core-4.cisco.com><4ED6A114.1060504@alum.mit.edu><7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFB@ESESSCMS0356.eemea.ericsson.se> <501C9ECF-0559-45A4-A547-EBD987D14F8B@cs.columbia.edu> To: "Carlberg, Kenneth G." X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: Adam Roach , ECRIT Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead ofeGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 13:15:29 -0000 Not really, at least not any more than any other URL that can be = contacted. (I'm leaving out resource-prioritization in intermediate = proxies here, since (a) I don't think that's all that important in = practice for call backs and (b) makes the problems even harder.) Henning On Dec 1, 2011, at 8:10 AM, Carlberg, Kenneth G. wrote: > Unless I missed something, there isn't anything in the approach that > identifies the UAs as being associated with a PSAP, and so nothing to > distinguish it from any other UA. As a result, while item 3 below > points out that the approach does not promote abuse risk, its still > subject to malicious DoS attacks. Correct? >=20 > -ken >=20 >=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf >> Of Henning Schulzrinne >> Sent: Wednesday, November 30, 2011 8:33 PM >> To: Christer Holmberg >> Cc: Adam Roach; ECRIT >> Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority > instead >> ofeGRUU >>=20 >> Here's a slightly different model: >>=20 >> (1) The UA requests (or automatically gets) a special emergency > (temp) >> GRUU; we can request this in some way, probably using a Contact >> parameter. sip.priority=3Demergency would probably work if we want to > re- >> use something. >>=20 >> (2) The UA uses that GRUU in the emergency call. There is no need to >> mark it - the PSAP has no control over call handling at the emergency >> caller anyway, so it does the same thing whether the UA knows about >> special handling or not. >>=20 >> (3) The PSAP places a normal call-back. The proxy knows that this is > a >> special GRUU that will only be used for emergency calls, so it can do >> all bypass actions it wants. Since the UA won't use this GRUU for >> "normal" calls, there is no abuse risk. >>=20 >> Henning >>=20 >> On Nov 30, 2011, at 4:43 PM, Christer Holmberg wrote: >>=20 >>>=20 >>> Hi, >>>=20 >>>>> I think you still need a GRUU (at least). >>>>=20 >>>> Maybe gruu helps here, maybe not. It seems that gruu isn't > sufficient >> to bypass call barring policies. If something else is needed for that >> then gruu may be irrelevant. >>>=20 >>> The proposal was that the emergency gruu would contain a "psapcb" >> token, which would have been used as an indicator for bypassing > policies >> etc. >>>=20 >>> (But, yes, the verification of the sender still applies also to the >> egruu) >>>=20 >>> Regards, >>>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 From keith.drage@alcatel-lucent.com Thu Dec 1 05:24:11 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DB011E82AA for ; Thu, 1 Dec 2011 05:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.947 X-Spam-Level: X-Spam-Status: No, score=-105.947 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 QguHNunucpgW for ; Thu, 1 Dec 2011 05:24:10 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0D36211E827F for ; Thu, 1 Dec 2011 05:24:09 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pB1DNhhH014099 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 1 Dec 2011 14:24:05 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 1 Dec 2011 14:23:59 +0100 From: "DRAGE, Keith (Keith)" To: Marc Linsner , "Dwight, Timothy M (Tim)" Date: Thu, 1 Dec 2011 14:23:57 +0100 Thread-Topic: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Thread-Index: Acyvtd9k5Gc5nwvmReerYI8LRrh78gAc0e0w Message-ID: References: <2B0F677F0B95454297753F58D4A07FA3B397C3AB@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 13:24:11 -0000 If you ask one particular public safety community. If you go elsewhere you get completely different answers. At least that is = what 3GPP found. The problem then arises that if each regulator can have different views, ho= w does one build such a timer into a terminal, that may be taken anywhere i= n the world by its owner, or may be taken out of the box anywhere in the wo= rld. (Yes IMS does make various assumptions in terms of the duration of an emerg= ency registration, which in IMS needs to be there to receive the potential = callback, but I am not convinced we came up with an ideal answer.) Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Marc Linsner > Sent: 30 November 2011 23:15 > To: Dwight, Timothy M (Tim) > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead > of eGRUU >=20 > Tim, >=20 > If you ask the public safety community, they will ask for a 1 hour time > period for special callback treatment. They don't expect special status > beyond that time period. >=20 > -Marc- >=20 > -----Original Message----- > From: "Dwight, Timothy M (Tim)" > Date: Wed, 30 Nov 2011 17:12:09 -0500 > To: Christer Holmberg , Paul Kyzivat > > Cc: "ecrit@ietf.org" > Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead > of eGRUU >=20 > >Thanks Christer. > > > >Maybe it's not easy to implement, but I'm uncomfortable that a device, > >once used to place a 911 call, is permanently marked as accessible to an > >unlimited number of calls from entities that pass the "I am a PSAP" test= . > > > >tim > > > >> -----Original Message----- > >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >> Sent: Wednesday, November 30, 2011 4:05 PM > >> To: Dwight, Timothy M (Tim); Paul Kyzivat > >> Cc: ecrit@ietf.org > >> Subject: RE: [Ecrit] PSAP Callback indication: > >> Resrouce-Priority instead of eGRUU > >> > >> > >> Hi, > >> > >> I'm not Paul, but I will reply anyway :) > >> > >> I will double check, but I don think that there is any time > >> limit (at least not a "relatively short" one) for a call to > >> be considered and treated as a callback. The network entities > >> that makes the prioritization may not even know when the > >> associtaed emergency call was made (so, if there were some > >> time limit I think the callback would need to contain timing > >> information). > >> > >> Regards, > >> > >> Christer > >> > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> On Behalf Of Dwight, Timothy M (Tim) > >> Sent: 30. marraskuuta 2011 23:55 > >> To: Paul Kyzivat > >> Cc: ecrit@ietf.org > >> Subject: Re: [Ecrit] PSAP Callback indication: > >> Resrouce-Priority instead of eGRUU > >> > >> Paul, > >> > >> Does there need also to be some "time limit"? ISTM that > >> after some [relatively short] period of time, a call from a > >> PSAP is no longer a "call back" and needn't be prioritized. > >> > >> tim > >> > >> > -----Original Message----- > >> > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> > Sent: Wednesday, November 30, 2011 3:30 PM > >> > To: Dwight, Timothy M (Tim) > >> > Cc: ecrit@ietf.org > >> > Subject: Re: [Ecrit] PSAP Callback indication: > >> > Resrouce-Priority instead of eGRUU > >> > > >> > On 12/1/11 5:08 AM, Dwight, Timothy M (Tim) wrote: > >> > > Paul, > >> > > > >> > > "call barring" is a standard GSM service. You can invoke > >> > it yourself with a "star code" or "hash code". It's also > >> possible to > >> > bar incoming calls only when roaming. Similarly there are various > >> > flavors of call diversion (aka call > >> > forwarding) that can be set similarly. This is what I meant. > >> > Services the user invokes or to which he is subscribed, > >> that have the > >> > effect of preventing delivery of a call. > >> > > >> > OK. These examples are much more helpful. > >> > So it seems you are looking for another attribute that can > >> be input to > >> > a policy engine that makes such decisions. > >> > > >> > So, on one hand its desired to indicate that the caller wants this > >> > call to receive special treatment, and then there is the issue of > >> > determining if the caller is entitled to ask for such treatment. > >> > > >> > ISTM that Priority:emergency should be sufficient as an > >> indicator that > >> > the treatment is required. Its been stated that this is > >> intended for > >> > use by the UAS. But the kinds of services we are discussing > >> bypassing > >> > are in general provided on behalf of the UAS, so I think it still > >> > applies. > >> > > >> > The Resource-Priority header probably also has a role here in cases > >> > where there are resource constraints in the network. > >> > > >> > Deciding if the caller is permitted to request this then > >> becomes the > >> > hard part. > >> > > >> > Thanks, > >> > Paul > >> > > >> > > tim > >> > > > >> > >> -----Original Message----- > >> > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> > >> Sent: Wednesday, November 30, 2011 2:52 PM > >> > >> To: Dwight, Timothy M (Tim) > >> > >> Subject: Re: [Ecrit] PSAP Callback indication: > >> > >> Resrouce-Priority instead of eGRUU > >> > >> > >> > >> On 12/1/11 4:35 AM, Dwight, Timothy M (Tim) wrote: > >> > >>> Paul, > >> > >>> > >> > >>> I assume this "mumble mumble" refers to features in the > >> > >> service provider network that might otherwise prevent > >> the callback > >> > >> from being delivered. The subscriber might have incoming calls > >> > >> barred for example. > >> > >> > >> > >> Do you mean that the provider has barred calls because > >> the bill has > >> > >> not been paid? I wouldn't consider this a "service" to > >> the user of > >> > >> the phone, but its a reality to deal with. > >> > >> > >> > >> I guess that is a significant issue in the case where outgoing > >> > >> emergency calls are allowed. > >> > >> > >> > >> This needs to be mentioned on the list. > >> > >> > >> > >> Thanks, > >> > >> Paul > >> > >> > >> > >> > >> > >> > >> > >>> tim > >> > >>> > >> > >>>> -----Original Message----- > >> > >>>> From: ecrit-bounces@ietf.org > >> [mailto:ecrit-bounces@ietf.org] On > >> > >>>> Behalf Of Paul Kyzivat > >> > >>>> Sent: Wednesday, November 30, 2011 2:06 PM > >> > >>>> To: Christer Holmberg > >> > >>>> Cc: Adam Roach; ECRIT > >> > >>>> Subject: Re: [Ecrit] PSAP Callback indication: > >> > >>>> Resrouce-Priority instead of eGRUU > >> > >>>> > >> > >>>> On 12/1/11 3:57 AM, Christer Holmberg wrote: > >> > >>>>> > >> > >>>>> Hi, > >> > >>>>> > >> > >>>>>>>> ISTM that a callback to the Contact address of a prior > >> > >>>> call should > >> > >>>>>>>> typically bypass many treatments, regardless of who > >> > it is from. > >> > >>>>>>>> > >> > >>>>>>>> In particular, it ought to go to the specific device > >> > >>>> identified by the > >> > >>>>>>>> contact address, not to some other device, VM server, etc. > >> > >>>>>>>> > >> > >>>>>>>> Perhaps that isn't what happens with IMS right now, but > >> > >>>> then maybe that > >> > >>>>>>>> ought to be re-thought. > >> > >>>>>>>> > >> > >>>>>>>> If that was normal behavior, then what else would be > >> > >> required for > >> > >>>>>>>> callbacks by a psap? > >> > >>>>>>>> > >> > >>>>>>>> There may need to be special treatment by the UA > >> itself, but > >> > >>>>>>>> that can be handled by using a unique temp > >> > >>>> gruu for the > >> > >>>>>>>> emergency call and remembering it in order to detect > >> > >>>> emergency callbacks > >> > >>>>>>>> in the UA. > >> > >>>>>>>> > >> > >>>>>>>> What am I missing? What sort of disruptive services do > >> > >>>> you expect will > >> > >>>>>>>> be applied to calls to a gruu? > >> > >>>>>>> > >> > >>>>>>> I don't think one can assume that any type of call, > >> > >>>> non-PSAP-callbacks and PSAP-callbacks, will be given the same > >> > >>>> special treatment by the network, just because they > >> are addressed > >> > >>>> using a Contact. > >> > >>>>>>> > >> > >>>>>>> And, it is not only about routing to another device, but > >> > >>>> also other services that normally would be applied. > >> > >>>>>> > >> > >>>>>> Rather than talk generically about "services", can we get > >> > >>>> tangible about > >> > >>>>>> what sorts of things the network might do that would be > >> > >>>> detrimental to a > >> > >>>>>> psap callback? > >> > >>>>>> > >> > >>>>>> AFAIK about the only thing that the network can do > >> > >>>> involves routing to > >> > >>>>>> some device other than the one addressed by the r-uri. E.g. > >> > >>>>>> - route to a VM server or message server that responds > >> > >> in some way. > >> > >>>>>> - forward to some other configured address > >> > >>>>>> > >> > >>>>>> IMO neither of those are appropriate if the URI is a gruu > >> > >>>> for a specific > >> > >>>>>> device and that device is reachable. They would be > >> > >>>> appropriate even for > >> > >>>>>> a psap callback if the device is not reachable. > >> > >>>>> > >> > >>>>> Again, it's not only about routing to a specific device. > >> > >>>>> > >> > >>>>> Before the request even reaches the device, it might e.g. > >> > >>>> be routed to different application servers in the network, > >> > >>>> triggering different kind of non-routing related services. A > >> > >>>> "normal" gruu addressed call could still be routed to such > >> > >>>> application servers, while a PSAP callback wouldn't. > >> > >>>> > >> > >>>> Without some tangible examples, what you say is just so much > >> > >>>> "mumble,mumble" to me. > >> > >>>> > >> > >>>> Either it is routed to some alternative device that terminates > >> > >>>> the call instead of the intended device, or else it is routed > >> > >>>> through some device that simply acts as an intermediary, still > >> > >>>> allowing the > >> > >> call to reach > >> > >>>> the intended device, or else it fails the call. > >> > >>>> > >> > >>>> Anything that acts as an intermediary, still allowing > >> the call to > >> > >>>> reach the intended destination, is probably benign. > >> (Do you have > >> > >>>> a > >> > >>>> counter-example?) > >> > >>>> > >> > >>>> Anything that routes to someplace other than the > >> intended device > >> > >>>> is of dubious appropriateness when the r-uri is a > >> GRUU. Again I'd > >> > >>>> be interested to hear some examples. > >> > >>>> > >> > >>>> Thanks, > >> > >>>> Paul > >> > >>>> _______________________________________________ > >> > >>>> Ecrit mailing list > >> > >>>> Ecrit@ietf.org > >> > >>>> https://www.ietf.org/mailman/listinfo/ecrit > >> > >>>> > >> > >> > >> > >> > >> > > >> > > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >> > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From keith.drage@alcatel-lucent.com Thu Dec 1 05:24:17 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6926111E829D for ; Thu, 1 Dec 2011 05:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.008 X-Spam-Level: X-Spam-Status: No, score=-106.008 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 8mDSCbWWdo9u for ; Thu, 1 Dec 2011 05:24:16 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 51DCC11E822B for ; Thu, 1 Dec 2011 05:24:16 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pB1DO4Is014281 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 1 Dec 2011 14:24:09 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 1 Dec 2011 14:24:05 +0100 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , "'Paul Kyzivat'" , "Dwight, Timothy M (Tim)" Date: Thu, 1 Dec 2011 14:24:03 +0100 Thread-Topic: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Thread-Index: Acyvp0CS1nxLO339S76iuwY9Hph1BwAADecgACAb+uA= Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se>, <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se>, <4ED68923.4060808@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D2B@ESESSCMS0356.eemea.ericsson.se> <4ED68CAB.5080602@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C255@FHDP1LUMXC7V31.us.one.verizon.com> <4ED69757.708@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C2D1@FHDP1LUMXC7V31.us.one.verizon.com> <4ED6A04D.5000705@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFA@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFA@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 13:24:17 -0000 As well as the potential routing off to another endpoint, I think we should= also be aware that some of the inline application of policy within either = a proxy or, dare I say it, SBC may also be inappropriate for a callback cal= l.=20 For example, an SBC may suppress some header fields. Is that always appropr= iate for a PSAP callback. I believe a common action is to suppress REFER re= quests. Should the normal policy restrictions on SDP media lines requested apply (t= hereby the PSAP potentially getting a 488 response from the terminating use= rs network entities) apply to a callback call. Regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Christer Holmberg > Sent: 30 November 2011 21:40 > To: 'Paul Kyzivat'; Dwight, Timothy M (Tim) > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead > of eGRUU >=20 >=20 > Hi, >=20 > >> "call barring" is a standard GSM service. You can invoke it yourself > with a "star code" or "hash code". > >> It's also possible to bar incoming calls only when roaming. Similarly > there are various flavors of call > >> diversion (aka call forwarding) that can be set similarly. This is > what I meant. Services the user > >> invokes or to which he is subscribed, that have the effect of > preventing delivery of a call. > > > > OK. These examples are much more helpful. >=20 > Yes, this is a good example of where the service logic would be different= . >=20 > But, in general, the idea is to not forward requests to application > servers at all (even if the call would eventually still reach the correct > device), e.g. due to the the risk of congestion etc (as indicated by > James). >=20 > >> So it seems you are looking for another attribute that can be input to > a policy engine that makes such decisions. > > > > So, on one hand its desired to indicate that the caller wants this call > to receive special treatment, and then there is the issue of determining > if the caller is entitled to ask for such treatment. >=20 > Correct. >=20 > > ISTM that Priority:emergency should be sufficient as an indicator that > the treatment is required. Its been stated that this is intended for use > by the UAS. But the kinds of services we are discussing > > bypassing are in general provided on behalf of the UAS, so I think it > still applies. >=20 > Agree (I earlier indicated the same). >=20 > > The Resource-Priority header probably also has a role here in cases > where there are resource constraints in the network. > > > > Deciding if the caller is permitted to request this then becomes the > hard part. >=20 > Yes. There needs to be a way for the network, when it receives a request > claiming to be a PSAP Callback, to determine that the call comes from a > PSAP. There might be different ways of doing that, depending on networks, > environments, operator agreements etc. >=20 > Regards, >=20 > Christer >=20 >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: Wednesday, November 30, 2011 2:52 PM > >> To: Dwight, Timothy M (Tim) > >> Subject: Re: [Ecrit] PSAP Callback indication: > >> Resrouce-Priority instead of eGRUU > >> > >> On 12/1/11 4:35 AM, Dwight, Timothy M (Tim) wrote: > >>> Paul, > >>> > >>> I assume this "mumble mumble" refers to features in the > >> service provider network that might otherwise prevent the callback > >> from being delivered. The subscriber might have incoming calls > >> barred for example. > >> > >> Do you mean that the provider has barred calls because the bill has > >> not been paid? I wouldn't consider this a "service" to the user of > >> the phone, but its a reality to deal with. > >> > >> I guess that is a significant issue in the case where outgoing > >> emergency calls are allowed. > >> > >> This needs to be mentioned on the list. > >> > >> Thanks, > >> Paul > >> > >> > >> > >>> tim > >>> > >>>> -----Original Message----- > >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>>> Behalf Of Paul Kyzivat > >>>> Sent: Wednesday, November 30, 2011 2:06 PM > >>>> To: Christer Holmberg > >>>> Cc: Adam Roach; ECRIT > >>>> Subject: Re: [Ecrit] PSAP Callback indication: > >>>> Resrouce-Priority instead of eGRUU > >>>> > >>>> On 12/1/11 3:57 AM, Christer Holmberg wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>>>>> ISTM that a callback to the Contact address of a prior > >>>> call should > >>>>>>>> typically bypass many treatments, regardless of who it is from. > >>>>>>>> > >>>>>>>> In particular, it ought to go to the specific device > >>>> identified by the > >>>>>>>> contact address, not to some other device, VM server, etc. > >>>>>>>> > >>>>>>>> Perhaps that isn't what happens with IMS right now, but > >>>> then maybe that > >>>>>>>> ought to be re-thought. > >>>>>>>> > >>>>>>>> If that was normal behavior, then what else would be > >> required for > >>>>>>>> callbacks by a psap? > >>>>>>>> > >>>>>>>> There may need to be special treatment by the UA itself, but > >>>>>>>> that can be handled by using a unique temp > >>>> gruu for the > >>>>>>>> emergency call and remembering it in order to detect > >>>> emergency callbacks > >>>>>>>> in the UA. > >>>>>>>> > >>>>>>>> What am I missing? What sort of disruptive services do > >>>> you expect will > >>>>>>>> be applied to calls to a gruu? > >>>>>>> > >>>>>>> I don't think one can assume that any type of call, > >>>> non-PSAP-callbacks and PSAP-callbacks, will be given the same > >>>> special treatment by the network, just because they are addressed > >>>> using a Contact. > >>>>>>> > >>>>>>> And, it is not only about routing to another device, but > >>>> also other services that normally would be applied. > >>>>>> > >>>>>> Rather than talk generically about "services", can we get > >>>> tangible about > >>>>>> what sorts of things the network might do that would be > >>>> detrimental to a > >>>>>> psap callback? > >>>>>> > >>>>>> AFAIK about the only thing that the network can do > >>>> involves routing to > >>>>>> some device other than the one addressed by the r-uri. E.g. > >>>>>> - route to a VM server or message server that responds > >> in some way. > >>>>>> - forward to some other configured address > >>>>>> > >>>>>> IMO neither of those are appropriate if the URI is a gruu > >>>> for a specific > >>>>>> device and that device is reachable. They would be > >>>> appropriate even for > >>>>>> a psap callback if the device is not reachable. > >>>>> > >>>>> Again, it's not only about routing to a specific device. > >>>>> > >>>>> Before the request even reaches the device, it might e.g. > >>>> be routed to different application servers in the network, > >>>> triggering different kind of non-routing related services. A > >>>> "normal" gruu addressed call could still be routed to such > >>>> application servers, while a PSAP callback wouldn't. > >>>> > >>>> Without some tangible examples, what you say is just so much > >>>> "mumble,mumble" to me. > >>>> > >>>> Either it is routed to some alternative device that terminates the > >>>> call instead of the intended device, or else it is routed through > >>>> some device that simply acts as an intermediary, still allowing the > >> call to reach > >>>> the intended device, or else it fails the call. > >>>> > >>>> Anything that acts as an intermediary, still allowing the call to > >>>> reach the intended destination, is probably benign. (Do you have a > >>>> counter-example?) > >>>> > >>>> Anything that routes to someplace other than the intended device is > >>>> of dubious appropriateness when the r-uri is a GRUU. Again I'd be > >>>> interested to hear some examples. > >>>> > >>>> Thanks, > >>>> Paul > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>> > >> > >> >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From christer.holmberg@ericsson.com Thu Dec 1 06:34:28 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8AD21F9178 for ; Thu, 1 Dec 2011 06:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, 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 bdVKaU8ewsYp for ; Thu, 1 Dec 2011 06:34:28 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A95AC21F9175 for ; Thu, 1 Dec 2011 06:34:27 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-8a-4ed79072ed21 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 75.99.09514.27097DE4; Thu, 1 Dec 2011 15:34:26 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.20]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Thu, 1 Dec 2011 15:34:26 +0100 From: Christer Holmberg To: Henning Schulzrinne , "Carlberg, Kenneth G." Date: Thu, 1 Dec 2011 15:34:24 +0100 Thread-Topic: [Ecrit] PSAP Callback indication: Resrouce-Priority instead ofeGRUU Thread-Index: AcywK0qoR9RpAzw+ST+E+eLic1tAxAACqujw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3A91B8C9@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se><201111300226.pAU2QOeO016560@mtv-core-2.cisco.com><7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se><4ED646F5.30300@alum.mit.edu><7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se><4ED68923.4060808@alum.mit.edu><201111302100.pAUL0dBU010082@mtv-core-4.cisco.com><4ED6A114.1060504@alum.mit.edu><7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFB@ESESSCMS0356.eemea.ericsson.se> <501C9ECF-0559-45A4-A547-EBD987D14F8B@cs.columbia.edu> <7664C222-C454-40F5-A6B7-6F13785D6D7A@cs.columbia.edu> In-Reply-To: <7664C222-C454-40F5-A6B7-6F13785D6D7A@cs.columbia.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , ECRIT Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead ofeGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 14:34:28 -0000 Hi Henning,=20 > Not really, at least not any more than any other URL that can=20 > be contacted. (I'm leaving out resource-prioritization in=20 > intermediate proxies here, since (a) I don't think that's all=20 > that important in practice for call backs and (b) makes the=20 > problems even harder.) As far as I know (needs to be double checked), there are no 3GPP/IMS requir= ements regarding network resource priorization for callbacks. The requireme= nts are more related to special treatment and policies. Regards, Christer > On Dec 1, 2011, at 8:10 AM, Carlberg, Kenneth G. wrote: >=20 > > Unless I missed something, there isn't anything in the=20 > approach that=20 > > identifies the UAs as being associated with a PSAP, and so=20 > nothing to=20 > > distinguish it from any other UA. As a result, while item 3 below=20 > > points out that the approach does not promote abuse risk, its still=20 > > subject to malicious DoS attacks. Correct? > >=20 > > -ken > >=20 > >=20 > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > Behalf > >> Of Henning Schulzrinne > >> Sent: Wednesday, November 30, 2011 8:33 PM > >> To: Christer Holmberg > >> Cc: Adam Roach; ECRIT > >> Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority > > instead > >> ofeGRUU > >>=20 > >> Here's a slightly different model: > >>=20 > >> (1) The UA requests (or automatically gets) a special emergency > > (temp) > >> GRUU; we can request this in some way, probably using a Contact=20 > >> parameter. sip.priority=3Demergency would probably work if we want to > > re- > >> use something. > >>=20 > >> (2) The UA uses that GRUU in the emergency call. There is=20 > no need to=20 > >> mark it - the PSAP has no control over call handling at=20 > the emergency=20 > >> caller anyway, so it does the same thing whether the UA=20 > knows about=20 > >> special handling or not. > >>=20 > >> (3) The PSAP places a normal call-back. The proxy knows=20 > that this is > > a > >> special GRUU that will only be used for emergency calls,=20 > so it can do=20 > >> all bypass actions it wants. Since the UA won't use this GRUU for=20 > >> "normal" calls, there is no abuse risk. > >>=20 > >> Henning > >>=20 > >> On Nov 30, 2011, at 4:43 PM, Christer Holmberg wrote: > >>=20 > >>>=20 > >>> Hi, > >>>=20 > >>>>> I think you still need a GRUU (at least). > >>>>=20 > >>>> Maybe gruu helps here, maybe not. It seems that gruu isn't > > sufficient > >> to bypass call barring policies. If something else is=20 > needed for that=20 > >> then gruu may be irrelevant. > >>>=20 > >>> The proposal was that the emergency gruu would contain a "psapcb" > >> token, which would have been used as an indicator for bypassing > > policies > >> etc. > >>>=20 > >>> (But, yes, the verification of the sender still applies=20 > also to the > >> egruu) > >>>=20 > >>> Regards, > >>>=20 > >>=20 > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >=20 >=20 > = From HKaplan@acmepacket.com Thu Dec 1 06:36:53 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E4411E8356 for ; Thu, 1 Dec 2011 06:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] 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 WjyJVYsyiVKp for ; Thu, 1 Dec 2011 06:36:52 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id D08F211E830C for ; Thu, 1 Dec 2011 06:36:45 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 1 Dec 2011 09:36:42 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.245]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 1 Dec 2011 09:36:42 -0500 From: Hadriel Kaplan To: Paul Kyzivat Thread-Topic: Network handling of callback (was: PSAP Callback indication: Resrouce-Priority instead of eGRUU) Thread-Index: AQHMsDakWx4ubnQTkECb7nsEsr958w== Date: Thu, 1 Dec 2011 14:36:42 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se>, <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se>, <4ED68923.4060808@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D2B@ESESSCMS0356.eemea.ericsson.se> <4ED68CAB.5080602@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C255@FHDP1LUMXC7V31.us.one.verizon.com> <4ED69757.708@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C2D1@FHDP1LUMXC7V31.us.one.verizon.com> <4ED6A04D.5000705@alum.mit.edu> In-Reply-To: <4ED6A04D.5000705@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: <5983502D9FEB75469046ABCF1316308E@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "ecrit@ietf.org" Subject: [Ecrit] Network handling of callback (was: PSAP Callback indication: Resrouce-Priority instead of eGRUU) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 14:36:53 -0000 [changing subject title because this thread is going all over the place] Right, so call-barring, call-forwarding, do-not-disturb, and such are netwo= rk features/services that might need to be exempted for PSAP callbacks. =20 But there are also network policies (rather than services) that might need = to be exempted: blocking calls if the UA does not have inbound call service= , blocking the call if the UA does not have credit/paid-minutes left, restr= icting UA's to only one call at a time, restricting the bandwidth for media= (ie, bandwidth CAC), blocking the early media from a UA, restricting the c= odecs allowed, and certain privacy rules/logic for information coming back = from the UA - all of which might need to be exempted for PSAP callbacks. And then of course there're the logs - providers/carriers will definitely w= ant to log these calls as being PSAP callbacks in particular. None of the above has anything to do with GRUUs, though. -hadriel On Nov 30, 2011, at 4:29 PM, Paul Kyzivat wrote: > On 12/1/11 5:08 AM, Dwight, Timothy M (Tim) wrote: >> Paul, >>=20 >> "call barring" is a standard GSM service. You can invoke it yourself wi= th a "star code" or "hash code". It's also possible to bar incoming calls = only when roaming. Similarly there are various flavors of call diversion (= aka call forwarding) that can be set similarly. This is what I meant. Ser= vices the user invokes or to which he is subscribed, that have the effect o= f preventing delivery of a call. >=20 > OK. These examples are much more helpful. > So it seems you are looking for another attribute that can be input to a = policy engine that makes such decisions. >=20 > So, on one hand its desired to indicate that the caller wants this call t= o receive special treatment, and then there is the issue of determining if = the caller is entitled to ask for such treatment. >=20 > ISTM that Priority:emergency should be sufficient as an indicator that th= e treatment is required. Its been stated that this is intended for use by t= he UAS. But the kinds of services we are discussing bypassing are in genera= l provided on behalf of the UAS, so I think it still applies. >=20 > The Resource-Priority header probably also has a role here in cases where= there are resource constraints in the network. >=20 > Deciding if the caller is permitted to request this then becomes the hard= part. >=20 > Thanks, > Paul >=20 >> tim >>=20 >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Wednesday, November 30, 2011 2:52 PM >>> To: Dwight, Timothy M (Tim) >>> Subject: Re: [Ecrit] PSAP Callback indication: >>> Resrouce-Priority instead of eGRUU >>>=20 >>> On 12/1/11 4:35 AM, Dwight, Timothy M (Tim) wrote: >>>> Paul, >>>>=20 >>>> I assume this "mumble mumble" refers to features in the >>> service provider network that might otherwise prevent the >>> callback from being delivered. The subscriber might have >>> incoming calls barred for example. >>>=20 >>> Do you mean that the provider has barred calls because the >>> bill has not >>> been paid? I wouldn't consider this a "service" to the user of the >>> phone, but its a reality to deal with. >>>=20 >>> I guess that is a significant issue in the case where >>> outgoing emergency >>> calls are allowed. >>>=20 >>> This needs to be mentioned on the list. >>> =09 >>> Thanks, >>> Paul >>>=20 >>>=20 >>>=20 >>>> tim >>>>=20 >>>>> -----Original Message----- >>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>>> On Behalf Of Paul Kyzivat >>>>> Sent: Wednesday, November 30, 2011 2:06 PM >>>>> To: Christer Holmberg >>>>> Cc: Adam Roach; ECRIT >>>>> Subject: Re: [Ecrit] PSAP Callback indication: >>>>> Resrouce-Priority instead of eGRUU >>>>>=20 >>>>> On 12/1/11 3:57 AM, Christer Holmberg wrote: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>>>>> ISTM that a callback to the Contact address of a prior >>>>> call should >>>>>>>>> typically bypass many treatments, regardless of who it is from. >>>>>>>>>=20 >>>>>>>>> In particular, it ought to go to the specific device >>>>> identified by the >>>>>>>>> contact address, not to some other device, VM server, etc. >>>>>>>>>=20 >>>>>>>>> Perhaps that isn't what happens with IMS right now, but >>>>> then maybe that >>>>>>>>> ought to be re-thought. >>>>>>>>>=20 >>>>>>>>> If that was normal behavior, then what else would be >>> required for >>>>>>>>> callbacks by a psap? >>>>>>>>>=20 >>>>>>>>> There may need to be special treatment by the UA >>>>>>>>> itself, but that can be handled by using a unique temp >>>>> gruu for the >>>>>>>>> emergency call and remembering it in order to detect >>>>> emergency callbacks >>>>>>>>> in the UA. >>>>>>>>>=20 >>>>>>>>> What am I missing? What sort of disruptive services do >>>>> you expect will >>>>>>>>> be applied to calls to a gruu? >>>>>>>>=20 >>>>>>>> I don't think one can assume that any type of call, >>>>> non-PSAP-callbacks and PSAP-callbacks, will be given the same >>>>> special treatment by the network, just because they are >>>>> addressed using a Contact. >>>>>>>>=20 >>>>>>>> And, it is not only about routing to another device, but >>>>> also other services that normally would be applied. >>>>>>>=20 >>>>>>> Rather than talk generically about "services", can we get >>>>> tangible about >>>>>>> what sorts of things the network might do that would be >>>>> detrimental to a >>>>>>> psap callback? >>>>>>>=20 >>>>>>> AFAIK about the only thing that the network can do >>>>> involves routing to >>>>>>> some device other than the one addressed by the r-uri. E.g. >>>>>>> - route to a VM server or message server that responds >>> in some way. >>>>>>> - forward to some other configured address >>>>>>>=20 >>>>>>> IMO neither of those are appropriate if the URI is a gruu >>>>> for a specific >>>>>>> device and that device is reachable. They would be >>>>> appropriate even for >>>>>>> a psap callback if the device is not reachable. >>>>>>=20 >>>>>> Again, it's not only about routing to a specific device. >>>>>>=20 >>>>>> Before the request even reaches the device, it might e.g. >>>>> be routed to different application servers in the network, >>>>> triggering different kind of non-routing related services. A >>>>> "normal" gruu addressed call could still be routed to such >>>>> application servers, while a PSAP callback wouldn't. >>>>>=20 >>>>> Without some tangible examples, what you say is just so much >>>>> "mumble,mumble" to me. >>>>>=20 >>>>> Either it is routed to some alternative device that >>>>> terminates the call >>>>> instead of the intended device, or else it is routed through >>>>> some device >>>>> that simply acts as an intermediary, still allowing the >>> call to reach >>>>> the intended device, or else it fails the call. >>>>>=20 >>>>> Anything that acts as an intermediary, still allowing the >>>>> call to reach >>>>> the intended destination, is probably benign. (Do you have a >>>>> counter-example?) >>>>>=20 >>>>> Anything that routes to someplace other than the intended >>>>> device is of >>>>> dubious appropriateness when the r-uri is a GRUU. Again I'd be >>>>> interested to hear some examples. >>>>>=20 >>>>> Thanks, >>>>> Paul >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>=20 >>>=20 >>>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From HKaplan@acmepacket.com Thu Dec 1 06:47:30 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AACE11E83C5 for ; Thu, 1 Dec 2011 06:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] 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 wk17X09zSfdo for ; Thu, 1 Dec 2011 06:47:29 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6835611E80A6 for ; Thu, 1 Dec 2011 06:47:29 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 1 Dec 2011 09:47:27 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.245]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 1 Dec 2011 09:47:28 -0500 From: Hadriel Kaplan To: "ecrit@ietf.org" Thread-Topic: GRUUs for callbacks Thread-Index: AQHMsDgl1NrXSdBLLUiHrDmliyRhCg== Date: Thu, 1 Dec 2011 14:47:27 +0000 Message-ID: <20FE3C02-8303-4D48-8412-7153A6A8FF86@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Subject: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 14:47:30 -0000 Howdy, So before people get too enamored with the idea of GRUUs, I would just like= to point out that as far as I can tell GRUU support is quite rare. I have= n't checked in a year or so, but last time I checked: only a handful of SIP= service providers in the World support GRUUs (and I mean literally countab= le by fingers on two hands). This is only what my company sees and maybe i= t's only the providers we're in, and obviously this could have changed as w= ell... but I doubt it. (and yes, this includes deployed 3GPP IMS networks, = PacketCable networks, OTT providers, wireline and mobile providers, transit= providers, and other flavors of Tier-1 through Tier-3 providers) And there are actual technical problems with deploying GRUUs, which I tried= to enumerate in: http://tools.ietf.org/html/draft-kaplan-dispatch-gruu-problematic-00 -hadriel From christer.holmberg@ericsson.com Thu Dec 1 12:03:59 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5B911E8073 for ; Thu, 1 Dec 2011 12:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, 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 KDBWiRHTXKIQ for ; Thu, 1 Dec 2011 12:03:58 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACAD11E807F for ; Thu, 1 Dec 2011 12:03:58 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-15-4ed7ddac7b2a Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DD.B0.09514.CADD7DE4; Thu, 1 Dec 2011 21:03:57 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.20]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Thu, 1 Dec 2011 21:03:56 +0100 From: Christer Holmberg To: Hadriel Kaplan , "ecrit@ietf.org" Date: Thu, 1 Dec 2011 21:03:55 +0100 Thread-Topic: GRUUs for callbacks Thread-Index: AQHMsDgl1NrXSdBLLUiHrDmliyRhCpXHZcEx Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D31@ESESSCMS0356.eemea.ericsson.se> References: <20FE3C02-8303-4D48-8412-7153A6A8FF86@acmepacket.com> In-Reply-To: <20FE3C02-8303-4D48-8412-7153A6A8FF86@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 20:03:59 -0000 Hi, > So before people get too enamored with the idea of GRUUs, I would just li= ke to point out that as far as I can tell GRUU support is quite rare. I ha= ven't checked in > a year or so, but last time I checked: only a handful of SIP service prov= iders in the World support GRUUs (and I mean literally countable by fingers= on two hands). =20 > This is only what my company sees and maybe it's only the providers we're= in, and obviously this could have changed as well... but I doubt it. (and = yes, this includes=20 > deployed 3GPP IMS networks, PacketCable networks, OTT providers, wireline= and mobile providers, transit providers, and other flavors of Tier-1 throu= gh Tier-3 providers) And, out of those who DO support GRUU, none of course support eGRUU :) AFAIK, some countries do not require the callback to reach the same device = as made the emergency call, so in such cases a non-GRUU Contact would of co= urse work - assuming there is some other way to identity the callback, as s= pecial handling etc may still be required. The advantage of using gruu for identification purpose is reduces the assum= ptions we make on the PSAP behavior, and if the gruu is unique (ie we don't= include static values) it allows the home proxy to identity the callback. = But, as I was told in Taipei, we actually have pretty good influence in def= ining PSAP behavior. Regards, Christer From HKaplan@acmepacket.com Thu Dec 1 13:04:03 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFB511E809D for ; Thu, 1 Dec 2011 13:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] 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 kuzXhXslnB3d for ; Thu, 1 Dec 2011 13:04:03 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id D14B511E8089 for ; Thu, 1 Dec 2011 13:04:02 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 1 Dec 2011 16:03:59 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.245]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 1 Dec 2011 16:03:59 -0500 From: Hadriel Kaplan To: Christer Holmberg Thread-Topic: GRUUs for callbacks Thread-Index: AQHMsGy+1NrXSdBLLUiHrDmliyRhCg== Date: Thu, 1 Dec 2011 21:03:58 +0000 Message-ID: <42304189-3281-46FD-9C2C-2C2B63944E6F@acmepacket.com> References: <20FE3C02-8303-4D48-8412-7153A6A8FF86@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D31@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D31@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 21:04:03 -0000 Just to be clear - not supporting GRUUs doesn't mean the callback won't rea= ch the same UA. As far as I can tell, it is surprisingly uncommon for prov= iders to support multiple registered UAs for the same AoR - some do, but th= ey're a small minority afaict. I don't know why that is in all cases (I kn= ow why in some cases), but the point is if the PSAP makes a callback to the= AoR it will get to the same phone that made the previous PSAP call in most= providers I know of today. And frankly we kinda need that to be the case, because most PSAPs connect t= o providers over PSTN trunks, not native SIP - that PSTN trunk will be gett= ing the callback from the PSAP, and the PSTN gateway will generate the SIP-= based callback that ultimately reaches either a native SIP client, or an MT= A or another gateway or whatever - so unless GRUU somehow works across the = PSTN, we're not gonna be able to rely on it for the near future *anyway*. An RPH header or something like one, on the other hand, could theoretically= be generated by the PSTN gateway because it knows its trunk is connected t= o a PSAP; or we could use an ISUP-based indicator; or we could apply logic = rules to add it - rules which don't depend on stored state about previous c= alls for hours/ever. -hadriel On Dec 1, 2011, at 3:03 PM, Christer Holmberg wrote: >=20 > Hi, >=20 >> So before people get too enamored with the idea of GRUUs, I would just l= ike to point out that as far as I can tell GRUU support is quite rare. I h= aven't checked in >> a year or so, but last time I checked: only a handful of SIP service pro= viders in the World support GRUUs (and I mean literally countable by finger= s on two hands). =20 >> This is only what my company sees and maybe it's only the providers we'r= e in, and obviously this could have changed as well... but I doubt it. (and= yes, this includes=20 >> deployed 3GPP IMS networks, PacketCable networks, OTT providers, wirelin= e and mobile providers, transit providers, and other flavors of Tier-1 thro= ugh Tier-3 providers) >=20 > And, out of those who DO support GRUU, none of course support eGRUU :) >=20 > AFAIK, some countries do not require the callback to reach the same devic= e as made the emergency call, so in such cases a non-GRUU Contact would of = course work - assuming there is some other way to identity the callback, as= special handling etc may still be required. >=20 > The advantage of using gruu for identification purpose is reduces the ass= umptions we make on the PSAP behavior, and if the gruu is unique (ie we don= 't include static values) it allows the home proxy to identity the callback= . But, as I was told in Taipei, we actually have pretty good influence in d= efining PSAP behavior. >=20 > Regards, >=20 > Christer From christer.holmberg@ericsson.com Thu Dec 1 13:32:15 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480EE11E80A5 for ; Thu, 1 Dec 2011 13:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 S4aKIrTRjwbw for ; Thu, 1 Dec 2011 13:32:14 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6668011E80A1 for ; Thu, 1 Dec 2011 13:32:14 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-53-4ed7f25d02b6 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D2.48.09514.D52F7DE4; Thu, 1 Dec 2011 22:32:13 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.20]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 1 Dec 2011 22:32:12 +0100 From: Christer Holmberg To: Hadriel Kaplan Date: Thu, 1 Dec 2011 22:28:34 +0100 Thread-Topic: GRUUs for callbacks Thread-Index: AQHMsGy+1NrXSdBLLUiHrDmliyRhCpXHf4Oj Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D34@ESESSCMS0356.eemea.ericsson.se> References: <20FE3C02-8303-4D48-8412-7153A6A8FF86@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D31@ESESSCMS0356.eemea.ericsson.se>, <42304189-3281-46FD-9C2C-2C2B63944E6F@acmepacket.com> In-Reply-To: <42304189-3281-46FD-9C2C-2C2B63944E6F@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 21:32:15 -0000 Hi, > Just to be clear - not supporting GRUUs doesn't mean the callback won't r= each the same UA. As far as I can tell, it is surprisingly uncommon for pr= oviders to support=20 > multiple registered UAs for the same AoR - some do, but they're a small m= inority afaict. I don't know why that is in all cases (I know why in some = cases), but the point=20 > is if the PSAP makes a callback to the AoR it will get to the same phone = that made the previous PSAP call in most providers I know of today. Correct. I don't think reaching the terminal is the biggest issue (if there are case= s which require gruu, we have the gruu mechanism). The bigger issue is to i= dentity the callback. > And frankly we kinda need that to be the case, because most PSAPs connect= to providers over PSTN trunks, not native SIP - that PSTN trunk will be ge= tting the=20 > callback from the PSAP, and the PSTN gateway will generate the SIP-based = callback that ultimately reaches either a native SIP client, or an MTA or a= nother gateway=20 > or whatever - so unless GRUU somehow works across the PSTN, we're not gon= na be able to rely on it for the near future *anyway*. Correct. ...unless you send the GRUU over ISUP UUI ;) > An RPH header or something like one, on the other hand, could theoretical= ly be generated by the PSTN gateway because it knows its trunk is connected= to a PSAP;=20 > or we could use an ISUP-based indicator; or we could apply logic rules to= add it - rules which don't depend on stored state about previous calls for= hours/ever. Correct. Regards, Christer On Dec 1, 2011, at 3:03 PM, Christer Holmberg wrote: > > Hi, > >> So before people get too enamored with the idea of GRUUs, I would just l= ike to point out that as far as I can tell GRUU support is quite rare. I h= aven't checked in >> a year or so, but last time I checked: only a handful of SIP service pro= viders in the World support GRUUs (and I mean literally countable by finger= s on two hands). >> This is only what my company sees and maybe it's only the providers we'r= e in, and obviously this could have changed as well... but I doubt it. (and= yes, this includes >> deployed 3GPP IMS networks, PacketCable networks, OTT providers, wirelin= e and mobile providers, transit providers, and other flavors of Tier-1 thro= ugh Tier-3 providers) > > And, out of those who DO support GRUU, none of course support eGRUU :) > > AFAIK, some countries do not require the callback to reach the same devic= e as made the emergency call, so in such cases a non-GRUU Contact would of = course work - assuming there is some other way to identity the callback, as= special handling etc may still be required. > > The advantage of using gruu for identification purpose is reduces the ass= umptions we make on the PSAP behavior, and if the gruu is unique (ie we don= 't include static values) it allows the home proxy to identity the callback= . But, as I was told in Taipei, we actually have pretty good influence in d= efining PSAP behavior. > > Regards, > > Christer From mlinsner@cisco.com Thu Dec 1 13:46:13 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15AEE1F0CB3 for ; Thu, 1 Dec 2011 13:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 STAoyspmHOzl for ; Thu, 1 Dec 2011 13:46:12 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 77E651F0CBC for ; Thu, 1 Dec 2011 13:44:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=4857; q=dns/txt; s=iport; t=1322775871; x=1323985471; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=QdcqbSsyXM1Guyir62CgV0fWrvnRB5Ej4ZVOHN0iY6U=; b=M1KZtgEZHVzqh2H4ApfQW4u179fEQnNExA5oevJ619/UvOp0Tejn3pRB pf58giSRIHs6h0eqo1EB0PZRTWwzAioPs9yOD9m6wc9GLf26Mx+TmydVj Mrgz746O+7u4ezeT4Cu3f3fuERQcp3e74KaKS//9N29ZTl/UfR9P284tO I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAML0106tJXG8/2dsb2JhbAA6CasAgQWBcgEBAQEDAQEBDwEnAgExCwwHCA4DAQIBAgFVIgYIBgENBSKHbZlJAY5Kj3oEh22DMwSIKIwvhUOMbQ X-IronPort-AV: E=Sophos;i="4.71,280,1320624000"; d="scan'208";a="40466774" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 01 Dec 2011 21:44:31 +0000 Received: from [10.116.195.123] (rtp-mlinsner-87110.cisco.com [10.116.195.123]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id pB1LiQaS031807; Thu, 1 Dec 2011 21:44:29 GMT User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 01 Dec 2011 16:44:25 -0500 From: Marc Linsner To: Hadriel Kaplan , Christer Holmberg Message-ID: Thread-Topic: [Ecrit] GRUUs for callbacks In-Reply-To: <42304189-3281-46FD-9C2C-2C2B63944E6F@acmepacket.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 21:46:13 -0000 Hadriel, ECRIT deals with NG Emergency Calling which includes PSAPs that are IP enabled, we're not particularly worried about legacy PSAPs. The original requirement deals with dropped calls to the PSAP and/or the PSAP call-taker needs additional information to affect emergency response. In these scenarios it's imperative the PSAP reach the same device that made the original call within seconds/minutes, this use case isn't worried about reaching the original caller hours/days after the fact. Multiple devices per AoR may not be today, but it's envisioned it may be a future norm. The eGRUU idea came from the fact that roaming IMS callers use visited networks for emergency calls, the home network hasn't a clue about the original emergency call. In this case, the home network, which could be in a different country, needs to know the current call they are handling is in fact a callback from an earlier emergency call. If the home network minted the eGRUU, they would recognize the call as coming from a PSAP. I wasn't at the Taipei meeting and it's unclear what was discussed that sidetracked the eGRUU idea. I believe we've come full circle from when we had this discussion years ago, giving the PSAP an RPH header that allows them 'god' status in the network was concluded to be a bad idea for several obvious reasons. I don't see the current lack of support for GRUU as a roadblock, if 3GPP accepts the eGRUU architecture, it would behove them to make sure it's implemented in their devices/networks. Hope this clears up a few issues. Carry on, -Marc- -----Original Message----- From: Hadriel Kaplan Date: Thu, 1 Dec 2011 21:03:58 +0000 To: Christer Holmberg Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] GRUUs for callbacks > >Just to be clear - not supporting GRUUs doesn't mean the callback won't >reach the same UA. As far as I can tell, it is surprisingly uncommon for >providers to support multiple registered UAs for the same AoR - some do, >but they're a small minority afaict. I don't know why that is in all >cases (I know why in some cases), but the point is if the PSAP makes a >callback to the AoR it will get to the same phone that made the previous >PSAP call in most providers I know of today. > >And frankly we kinda need that to be the case, because most PSAPs connect >to providers over PSTN trunks, not native SIP - that PSTN trunk will be >getting the callback from the PSAP, and the PSTN gateway will generate >the SIP-based callback that ultimately reaches either a native SIP >client, or an MTA or another gateway or whatever - so unless GRUU somehow >works across the PSTN, we're not gonna be able to rely on it for the near >future *anyway*. > >An RPH header or something like one, on the other hand, could >theoretically be generated by the PSTN gateway because it knows its trunk >is connected to a PSAP; or we could use an ISUP-based indicator; or we >could apply logic rules to add it - rules which don't depend on stored >state about previous calls for hours/ever. > >-hadriel > > >On Dec 1, 2011, at 3:03 PM, Christer Holmberg wrote: > >> >> Hi, >> >>> So before people get too enamored with the idea of GRUUs, I would just >>>like to point out that as far as I can tell GRUU support is quite rare. >>> I haven't checked in >>> a year or so, but last time I checked: only a handful of SIP service >>>providers in the World support GRUUs (and I mean literally countable by >>>fingers on two hands). >>> This is only what my company sees and maybe it's only the providers >>>we're in, and obviously this could have changed as well... but I doubt >>>it. (and yes, this includes >>> deployed 3GPP IMS networks, PacketCable networks, OTT providers, >>>wireline and mobile providers, transit providers, and other flavors of >>>Tier-1 through Tier-3 providers) >> >> And, out of those who DO support GRUU, none of course support eGRUU :) >> >> AFAIK, some countries do not require the callback to reach the same >>device as made the emergency call, so in such cases a non-GRUU Contact >>would of course work - assuming there is some other way to identity the >>callback, as special handling etc may still be required. >> >> The advantage of using gruu for identification purpose is reduces the >>assumptions we make on the PSAP behavior, and if the gruu is unique (ie >>we don't include static values) it allows the home proxy to identity the >>callback. But, as I was told in Taipei, we actually have pretty good >>influence in defining PSAP behavior. >> >> Regards, >> >> Christer > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From pkyzivat@alum.mit.edu Thu Dec 1 14:11:27 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1115E21F936F for ; Thu, 1 Dec 2011 14:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] 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 aTdubD-5J0u0 for ; Thu, 1 Dec 2011 14:11:26 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id F153521F936D for ; Thu, 1 Dec 2011 14:11:25 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta09.westchester.pa.mail.comcast.net with comcast id 3w0L1i0011vXlb859yBSgX; Thu, 01 Dec 2011 22:11:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta17.westchester.pa.mail.comcast.net with comcast id 3yBR1i00J07duvL3dyBSol; Thu, 01 Dec 2011 22:11:26 +0000 Message-ID: <4ED7FB8C.4060908@alum.mit.edu> Date: Fri, 02 Dec 2011 06:11:24 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: ecrit@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 22:11:27 -0000 On 12/2/11 5:44 AM, Marc Linsner wrote: > Hadriel, > > ECRIT deals with NG Emergency Calling which includes PSAPs that are IP > enabled, we're not particularly worried about legacy PSAPs. > > The original requirement deals with dropped calls to the PSAP and/or the > PSAP call-taker needs additional information to affect emergency response. > In these scenarios it's imperative the PSAP reach the same device that > made the original call within seconds/minutes, this use case isn't worried > about reaching the original caller hours/days after the fact. Multiple > devices per AoR may not be today, but it's envisioned it may be a future > norm. > > The eGRUU idea came from the fact that roaming IMS callers use visited > networks for emergency calls, the home network hasn't a clue about the > original emergency call. In this case, the home network, which could be in > a different country, needs to know the current call they are handling is > in fact a callback from an earlier emergency call. If the home network > minted the eGRUU, they would recognize the call as coming from a PSAP. I'm finding this a little confusing. Are you are saying that the UA making the emergency call will get an egruu from the registrar/scscf in the visited network, but the resulting call will be processed by the scscf of the home network? I don't see how that would happen. If the gruu came from the visited network, then the callback from the psap would have no reference to the home network. Thanks, Paul > I wasn't at the Taipei meeting and it's unclear what was discussed that > sidetracked the eGRUU idea. > > I believe we've come full circle from when we had this discussion years > ago, giving the PSAP an RPH header that allows them 'god' status in the > network was concluded to be a bad idea for several obvious reasons. > > I don't see the current lack of support for GRUU as a roadblock, if 3GPP > accepts the eGRUU architecture, it would behove them to make sure it's > implemented in their devices/networks. > > Hope this clears up a few issues. > > Carry on, > > -Marc- > > > > -----Original Message----- > From: Hadriel Kaplan > Date: Thu, 1 Dec 2011 21:03:58 +0000 > To: Christer Holmberg > Cc: "ecrit@ietf.org" > Subject: Re: [Ecrit] GRUUs for callbacks > >> >> Just to be clear - not supporting GRUUs doesn't mean the callback won't >> reach the same UA. As far as I can tell, it is surprisingly uncommon for >> providers to support multiple registered UAs for the same AoR - some do, >> but they're a small minority afaict. I don't know why that is in all >> cases (I know why in some cases), but the point is if the PSAP makes a >> callback to the AoR it will get to the same phone that made the previous >> PSAP call in most providers I know of today. >> >> And frankly we kinda need that to be the case, because most PSAPs connect >> to providers over PSTN trunks, not native SIP - that PSTN trunk will be >> getting the callback from the PSAP, and the PSTN gateway will generate >> the SIP-based callback that ultimately reaches either a native SIP >> client, or an MTA or another gateway or whatever - so unless GRUU somehow >> works across the PSTN, we're not gonna be able to rely on it for the near >> future *anyway*. >> >> An RPH header or something like one, on the other hand, could >> theoretically be generated by the PSTN gateway because it knows its trunk >> is connected to a PSAP; or we could use an ISUP-based indicator; or we >> could apply logic rules to add it - rules which don't depend on stored >> state about previous calls for hours/ever. >> >> -hadriel >> >> >> On Dec 1, 2011, at 3:03 PM, Christer Holmberg wrote: >> >>> >>> Hi, >>> >>>> So before people get too enamored with the idea of GRUUs, I would just >>>> like to point out that as far as I can tell GRUU support is quite rare. >>>> I haven't checked in >>>> a year or so, but last time I checked: only a handful of SIP service >>>> providers in the World support GRUUs (and I mean literally countable by >>>> fingers on two hands). >>>> This is only what my company sees and maybe it's only the providers >>>> we're in, and obviously this could have changed as well... but I doubt >>>> it. (and yes, this includes >>>> deployed 3GPP IMS networks, PacketCable networks, OTT providers, >>>> wireline and mobile providers, transit providers, and other flavors of >>>> Tier-1 through Tier-3 providers) >>> >>> And, out of those who DO support GRUU, none of course support eGRUU :) >>> >>> AFAIK, some countries do not require the callback to reach the same >>> device as made the emergency call, so in such cases a non-GRUU Contact >>> would of course work - assuming there is some other way to identity the >>> callback, as special handling etc may still be required. >>> >>> The advantage of using gruu for identification purpose is reduces the >>> assumptions we make on the PSAP behavior, and if the gruu is unique (ie >>> we don't include static values) it allows the home proxy to identity the >>> callback. But, as I was told in Taipei, we actually have pretty good >>> influence in defining PSAP behavior. >>> >>> Regards, >>> >>> Christer >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From HKaplan@acmepacket.com Thu Dec 1 14:21:21 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78891F0C38 for ; Thu, 1 Dec 2011 14:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] 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 yqMvCtjkpGMj for ; Thu, 1 Dec 2011 14:21:20 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id DA3F51F0C7E for ; Thu, 1 Dec 2011 14:20:41 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 1 Dec 2011 17:20:38 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.245]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 1 Dec 2011 17:20:38 -0500 From: Hadriel Kaplan To: Marc Linsner Thread-Topic: [Ecrit] GRUUs for callbacks Thread-Index: AQHMsHdzCIe/UJnBmUOGAvdJrqllXQ== Date: Thu, 1 Dec 2011 22:20:38 +0000 Message-ID: <5FF080FB-BB84-48CC-BDB4-E0A93460634D@acmepacket.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 22:21:21 -0000 On Dec 1, 2011, at 4:44 PM, Marc Linsner wrote: > ECRIT deals with NG Emergency Calling which includes PSAPs that are IP > enabled, we're not particularly worried about legacy PSAPs. I'm not either, since I don't make PSTN equipment - but it's widely known t= hat while some PSAPs are moving their internal nets to SIP, their connectio= ns to the providers will remain PSTN trunks for the foreseeable future. It= 's not what I want to happen, but that's not my decision to make. > The eGRUU idea came from the fact that roaming IMS callers use visited > networks for emergency calls, the home network hasn't a clue about the > original emergency call. In this case, the home network, which could be i= n > a different country, needs to know the current call they are handling is > in fact a callback from an earlier emergency call. If the home network > minted the eGRUU, they would recognize the call as coming from a PSAP. No, they wouldn't. All they'd know is that a eGRUU they provided to a UA i= s now in the request-URI of an INVITE from someone else. They can't assume= the eGRUU wasn't given by the UA or its human to other UAs to make free ca= lls to them. The only thing that prevents those types of things from happe= ning, is implicit trust and logging for fraud prevention folks to check out= later. But that's the same thing that would happen with RPH headers - the= y'd have to have trust in their peers to only use the RPH value when the ca= ll comes from PSAPs, and logging for fraud prevention later. And that's th= e same thing that happens with P-Asserted-IDs, billing headers, etc. This = trust model isn't new - it's used every day by virtually every service prov= ider on Earth, in both the PSTN and SIP. > I don't see the current lack of support for GRUU as a roadblock, if 3GPP > accepts the eGRUU architecture, it would behove them to make sure it's > implemented in their devices/networks. Ironically, 3GPP networks are exactly the types of networks which shouldn't= be using GRUUs to begin with. Their contacts aren't actually globally rou= table, and their domains/registrars aren't actually globally reachable. You guy need a way to indicate a callback is a callback, and you need a way= to believe/trust it - I grok that. You also need a way to reach the same UA instance in deployments where such= are possible - I grok that. Tying those two requirements into the same solution of GRUU is a bad idea. = There's a solution for the first problem which is pragmatically deployable= across all providers today; while there're problems with the solution to t= he second problem that we need to work on for SIP in general. -hadriel From mlinsner@cisco.com Thu Dec 1 14:30:07 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA5821F9334 for ; Thu, 1 Dec 2011 14:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 JB4Qwvq9vKAh for ; Thu, 1 Dec 2011 14:30:06 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2871821F9333 for ; Thu, 1 Dec 2011 14:30:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=6292; q=dns/txt; s=iport; t=1322778606; x=1323988206; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=BRtGalYzihnG1YoNZddv7UQjS/3sGHOSxL4QjafaC1Y=; b=ZBnV7FwaWlVID8NE/uH40jYm+SYdlNl/KY67RDZN+uezwA0ikZMisiHe DyEw+K704x4LlF7i9xh9c8yTNcCmgInKebWh5Ck5iAtRCQQlYb8B11t/j Va7HV7XWbby4cA/qz/x9Wo0MAANGs2zufNEgBHsHB0oOVWebS87CwsW9h I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALT+106tJXG9/2dsb2JhbAA6CQ6qcoEFgXIBAQEBAwEBAQ8BJwIBMRcHCA4DAQIBAgFVIgYIBgESIodtmVABjkqPdwSHbYMzBIgojC+FQ4wYVQ X-IronPort-AV: E=Sophos;i="4.71,281,1320624000"; d="scan'208";a="40462681" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 01 Dec 2011 22:30:05 +0000 Received: from [10.116.195.123] (rtp-mlinsner-87110.cisco.com [10.116.195.123]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pB1MU2GV012124; Thu, 1 Dec 2011 22:30:04 GMT User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 01 Dec 2011 17:30:01 -0500 From: Marc Linsner To: Paul Kyzivat , Message-ID: Thread-Topic: [Ecrit] GRUUs for callbacks In-Reply-To: <4ED7FB8C.4060908@alum.mit.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 22:30:07 -0000 -----Original Message----- From: Paul Kyzivat Date: Fri, 02 Dec 2011 06:11:24 +0800 To: Subject: Re: [Ecrit] GRUUs for callbacks >On 12/2/11 5:44 AM, Marc Linsner wrote: >> Hadriel, >> >> ECRIT deals with NG Emergency Calling which includes PSAPs that are IP >> enabled, we're not particularly worried about legacy PSAPs. >> >> The original requirement deals with dropped calls to the PSAP and/or the >> PSAP call-taker needs additional information to affect emergency >>response. >> In these scenarios it's imperative the PSAP reach the same device that >> made the original call within seconds/minutes, this use case isn't >>worried >> about reaching the original caller hours/days after the fact. Multiple >> devices per AoR may not be today, but it's envisioned it may be a future >> norm. >> >> The eGRUU idea came from the fact that roaming IMS callers use visited >> networks for emergency calls, the home network hasn't a clue about the >> original emergency call. In this case, the home network, which could be >>in >> a different country, needs to know the current call they are handling is >> in fact a callback from an earlier emergency call. If the home network >> minted the eGRUU, they would recognize the call as coming from a PSAP. > >I'm finding this a little confusing. >Are you are saying that the UA making the emergency call will get an >egruu from the registrar/scscf in the visited network, but the resulting >call will be processed by the scscf of the home network? No, it was intended the eGRUU would be minted by the home network and passed to the UA upon registration. -Marc- > >I don't see how that would happen. If the gruu came from the visited >network, then the callback from the psap would have no reference to the >home network. > > Thanks, > Paul > >> I wasn't at the Taipei meeting and it's unclear what was discussed that >> sidetracked the eGRUU idea. >> >> I believe we've come full circle from when we had this discussion years >> ago, giving the PSAP an RPH header that allows them 'god' status in the >> network was concluded to be a bad idea for several obvious reasons. >> >> I don't see the current lack of support for GRUU as a roadblock, if 3GPP >> accepts the eGRUU architecture, it would behove them to make sure it's >> implemented in their devices/networks. >> >> Hope this clears up a few issues. >> >> Carry on, >> >> -Marc- >> >> >> >> -----Original Message----- >> From: Hadriel Kaplan >> Date: Thu, 1 Dec 2011 21:03:58 +0000 >> To: Christer Holmberg >> Cc: "ecrit@ietf.org" >> Subject: Re: [Ecrit] GRUUs for callbacks >> >>> >>> Just to be clear - not supporting GRUUs doesn't mean the callback won't >>> reach the same UA. As far as I can tell, it is surprisingly uncommon >>>for >>> providers to support multiple registered UAs for the same AoR - some >>>do, >>> but they're a small minority afaict. I don't know why that is in all >>> cases (I know why in some cases), but the point is if the PSAP makes a >>> callback to the AoR it will get to the same phone that made the >>>previous >>> PSAP call in most providers I know of today. >>> >>> And frankly we kinda need that to be the case, because most PSAPs >>>connect >>> to providers over PSTN trunks, not native SIP - that PSTN trunk will be >>> getting the callback from the PSAP, and the PSTN gateway will generate >>> the SIP-based callback that ultimately reaches either a native SIP >>> client, or an MTA or another gateway or whatever - so unless GRUU >>>somehow >>> works across the PSTN, we're not gonna be able to rely on it for the >>>near >>> future *anyway*. >>> >>> An RPH header or something like one, on the other hand, could >>> theoretically be generated by the PSTN gateway because it knows its >>>trunk >>> is connected to a PSAP; or we could use an ISUP-based indicator; or we >>> could apply logic rules to add it - rules which don't depend on stored >>> state about previous calls for hours/ever. >>> >>> -hadriel >>> >>> >>> On Dec 1, 2011, at 3:03 PM, Christer Holmberg wrote: >>> >>>> >>>> Hi, >>>> >>>>> So before people get too enamored with the idea of GRUUs, I would >>>>>just >>>>> like to point out that as far as I can tell GRUU support is quite >>>>>rare. >>>>> I haven't checked in >>>>> a year or so, but last time I checked: only a handful of SIP service >>>>> providers in the World support GRUUs (and I mean literally countable >>>>>by >>>>> fingers on two hands). >>>>> This is only what my company sees and maybe it's only the providers >>>>> we're in, and obviously this could have changed as well... but I >>>>>doubt >>>>> it. (and yes, this includes >>>>> deployed 3GPP IMS networks, PacketCable networks, OTT providers, >>>>> wireline and mobile providers, transit providers, and other flavors >>>>>of >>>>> Tier-1 through Tier-3 providers) >>>> >>>> And, out of those who DO support GRUU, none of course support eGRUU :) >>>> >>>> AFAIK, some countries do not require the callback to reach the same >>>> device as made the emergency call, so in such cases a non-GRUU Contact >>>> would of course work - assuming there is some other way to identity >>>>the >>>> callback, as special handling etc may still be required. >>>> >>>> The advantage of using gruu for identification purpose is reduces the >>>> assumptions we make on the PSAP behavior, and if the gruu is unique >>>>(ie >>>> we don't include static values) it allows the home proxy to identity >>>>the >>>> callback. But, as I was told in Taipei, we actually have pretty good >>>> influence in defining PSAP behavior. >>>> >>>> Regards, >>>> >>>> Christer >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Thu Dec 1 14:38:50 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C75C81F0C45 for ; Thu, 1 Dec 2011 14:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 31rTl0pjZsMf for ; Thu, 1 Dec 2011 14:38:50 -0800 (PST) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id 590B51F0C38 for ; Thu, 1 Dec 2011 14:38:50 -0800 (PST) X-ASG-Debug-ID: 1322779129-011a9f099f41740001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id vyfs8XHr3wLMqk0C; Thu, 01 Dec 2011 14:38:49 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.29]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RWFHF-003MxG-OL; Thu, 01 Dec 2011 14:38:49 -0800 X-Barracuda-BBL-IP: 209.173.57.233 X-Barracuda-RBL-IP: 209.173.57.233 Mime-Version: 1.0 (Apple Message framework v1251.1) X-ASG-Orig-Subj: Re: [Ecrit] GRUUs for callbacks Content-Type: text/plain; charset=windows-1252 From: Brian Rosen In-Reply-To: <5FF080FB-BB84-48CC-BDB4-E0A93460634D@acmepacket.com> Date: Thu, 1 Dec 2011 17:38:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5FF080FB-BB84-48CC-BDB4-E0A93460634D@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1251.1) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1322779129 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.81864 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 22:38:50 -0000 > You also need a way to reach the same UA instance in deployments where = such are possible - I grok that. "Where such deployments are possible" because of design choices, = deployment choices or impairments (congestion, failure, =85)? The latter is okay. The former two are not.=20 Brian From mlinsner@cisco.com Thu Dec 1 15:07:15 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E132811E8150 for ; Thu, 1 Dec 2011 15:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=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 ljV2mjwKiIgD for ; Thu, 1 Dec 2011 15:07:14 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B750611E80A2 for ; Thu, 1 Dec 2011 15:07:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=3856; q=dns/txt; s=iport; t=1322780834; x=1323990434; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=VHiQXdMNCXM8y+BfzNstfSH6+AF4fOtSQ/kOAD5+LAg=; b=mgWGlu7s3n8++QudkfQVCYjdOSIUAS9AqTyGRlcJyaPQp35CA9lpW07D ywYf9sR6wJpDSYrvhPxpHNw74gVoa4YICholx7DMNM4T002j/og2gO3d3 frT+EkUIQnkRYeyzKGuw6m+fw2TA7wY67VAC6j64Mo3cZUULKWQdftuNq 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoFAEgI2E6tJV2Z/2dsb2JhbABDqBKCcYEFgXIBAQEBAxIBJwIBHCAMBwgOAwECAQIBdwYIBg4FGwehOgGOSo94iyAEiCiML4VDjG0 X-IronPort-AV: E=Sophos;i="4.71,281,1320624000"; d="scan'208";a="40484849" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 01 Dec 2011 23:07:14 +0000 Received: from [10.116.195.123] (rtp-mlinsner-87110.cisco.com [10.116.195.123]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pB1N7ATP007410; Thu, 1 Dec 2011 23:07:13 GMT User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 01 Dec 2011 18:07:09 -0500 From: Marc Linsner To: Hadriel Kaplan Message-ID: Thread-Topic: [Ecrit] GRUUs for callbacks In-Reply-To: <5FF080FB-BB84-48CC-BDB4-E0A93460634D@acmepacket.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 23:07:16 -0000 -----Original Message----- From: Hadriel Kaplan Date: Thu, 1 Dec 2011 22:20:38 +0000 To: Marc Linsner Cc: Christer Holmberg , "ecrit@ietf.org" Subject: Re: [Ecrit] GRUUs for callbacks > >On Dec 1, 2011, at 4:44 PM, Marc Linsner wrote: > >> ECRIT deals with NG Emergency Calling which includes PSAPs that are IP >> enabled, we're not particularly worried about legacy PSAPs. > >I'm not either, since I don't make PSTN equipment - but it's widely known >that while some PSAPs are moving their internal nets to SIP, their >connections to the providers will remain PSTN trunks for the foreseeable >future. It's not what I want to happen, but that's not my decision to >make. And PSAPs that opt for that scenario will understand their capability limitations. But that doesn't change this thread, the requirement is for PSAPs connected to the Internet and accepting IP sessions natively. > > >> The eGRUU idea came from the fact that roaming IMS callers use visited >> networks for emergency calls, the home network hasn't a clue about the >> original emergency call. In this case, the home network, which could be >>in >> a different country, needs to know the current call they are handling is >> in fact a callback from an earlier emergency call. If the home network >> minted the eGRUU, they would recognize the call as coming from a PSAP. > >No, they wouldn't. All they'd know is that a eGRUU they provided to a UA >is now in the request-URI of an INVITE from someone else. They can't >assume the eGRUU wasn't given by the UA or its human to other UAs to make >free calls to them. The only thing that prevents those types of things >from happening, is implicit trust and logging for fraud prevention folks >to check out later. But that's the same thing that would happen with RPH >headers - they'd have to have trust in their peers to only use the RPH >value when the call comes from PSAPs, and logging for fraud prevention >later. And that's the same thing that happens with P-Asserted-IDs, >billing headers, etc. This trust model isn't new - it's used every day >by virtually every service provider on Earth, in both the PSTN and SIP. I'm thinking they believe they will have more control over the UA software. We don't have requests/claims that callbacks from PSAPs are free. That is not the case in the majority of the US. Hence the eGRUU would simply negate features under control of the user anyway, so the point would be? Resource priority is NOT a requirement germane to this solution. > > >> I don't see the current lack of support for GRUU as a roadblock, if 3GPP >> accepts the eGRUU architecture, it would behove them to make sure it's >> implemented in their devices/networks. > >Ironically, 3GPP networks are exactly the types of networks which >shouldn't be using GRUUs to begin with. Their contacts aren't actually >globally routable, and their domains/registrars aren't actually globally >reachable. > >You guy need a way to indicate a callback is a callback, and you need a >way to believe/trust it - I grok that. >You also need a way to reach the same UA instance in deployments where >such are possible - I grok that. >Tying those two requirements into the same solution of GRUU is a bad >idea. There's a solution for the first problem which is pragmatically >deployable across all providers today; while there're problems with the >solution to the second problem that we need to work on for SIP in general. > >-hadriel I'm neutral to the eGRUU proposal. It is basically a last minute issue to an in-progress draft that was brought to the group by those claiming a problem with 3GPP and our PSAP callback draft. -Marc- > From HKaplan@acmepacket.com Fri Dec 2 06:58:31 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E843E21F8B81 for ; Fri, 2 Dec 2011 06:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] 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 yY+bJmfXS+1c for ; Fri, 2 Dec 2011 06:58:31 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 38D6F21F8B67 for ; Fri, 2 Dec 2011 06:58:31 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 2 Dec 2011 09:58:30 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.245]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 2 Dec 2011 09:58:30 -0500 From: Hadriel Kaplan To: Brian Rosen Thread-Topic: [Ecrit] GRUUs for callbacks Thread-Index: AQHMsQLa1T043IuJsUmNhT2eUed1Sg== Date: Fri, 2 Dec 2011 14:58:29 +0000 Message-ID: <11776ED1-8A53-4A11-906F-D92DD9D5A28B@acmepacket.com> References: <5FF080FB-BB84-48CC-BDB4-E0A93460634D@acmepacket.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 14:58:32 -0000 On Dec 1, 2011, at 5:38 PM, Brian Rosen wrote: >> You also need a way to reach the same UA instance in deployments where s= uch are possible - I grok that. > "Where such deployments are possible" because of design choices, deployme= nt choices or impairments (congestion, failure, =85)? >=20 > The latter is okay. The former two are not.=20 I meant in deployments where there could be more than one UA instance for t= he same AoR. But speaking for your general point of "they must do what we tell them and = I don't care what the repercussions are" - I can't speak to that. Personal= ly I don't feel the IETF or NENA should be in the business of telling peopl= e how to design, deploy, run, manage, and charge for their services, regard= less of the cost or impact that would have - but that's not a discussion fo= r this mailing list. Along those lines though, why aren't the ECRIT specs mandating IPv6 everywh= ere, and NATs or Firewalls must not exist? I mean if you're going to dicta= te market forces by fiat, you might as well be thorough. ;) -hadriel From br@brianrosen.net Fri Dec 2 07:30:39 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DAA21F8C55 for ; Fri, 2 Dec 2011 07:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 IFKYCk0cJLMl for ; Fri, 2 Dec 2011 07:30:39 -0800 (PST) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id 542DC21F8C54 for ; Fri, 2 Dec 2011 07:30:39 -0800 (PST) X-ASG-Debug-ID: 1322839837-011a9f4faf26020001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id GNF8YODKt7kPsOin; Fri, 02 Dec 2011 07:30:37 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.29]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RWV4P-000Rtd-Kr; Fri, 02 Dec 2011 07:30:37 -0800 X-Barracuda-BBL-IP: 209.173.57.233 X-Barracuda-RBL-IP: 209.173.57.233 Mime-Version: 1.0 (Apple Message framework v1251.1) X-ASG-Orig-Subj: Re: [Ecrit] GRUUs for callbacks Content-Type: text/plain; charset=windows-1252 From: Brian Rosen In-Reply-To: <11776ED1-8A53-4A11-906F-D92DD9D5A28B@acmepacket.com> Date: Fri, 2 Dec 2011 10:30:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9BF92E05-ECC4-499E-AC22-070D218B7C11@brianrosen.net> References: <5FF080FB-BB84-48CC-BDB4-E0A93460634D@acmepacket.com> <11776ED1-8A53-4A11-906F-D92DD9D5A28B@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1251.1) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1322839837 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.81930 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 15:30:39 -0000 I guess mostly because people can get hurt or die if we can't figure out = how to get them the help they need when, under stress, they do something = stupid like hang up before we got the info we needed. It happens now = (call back to device isn't something the PSTN does). Want to be next to = a PSAP call taker when they get voice mail on a call back? Been there. = Not pretty. You get this hopeless feeling that comes from knowing you = could help, and not being able to provide help, because the system = failed you. First time I saw it, I was a lot more upset than the call = taker. She'd had it happen a lot. It was new to me. I'd like to fix = that. Of course I'd like to prevent the hang up in the first place, but = the IETF, so far, has decided that call back is all we get. If call = back is all we have, then it has to work, IMO. We don't need to ban NATs or require IPv6 to make callback work. Neither IETF or NENA can tell people how to "deploy, run, manage, and = charge for their services". All we can do is write documents that say = "MUST". Doesn't seem to affect a lot of deployments, as you have = pointed out. =20 Regulators can. Is that preferable? Brian On Dec 2, 2011, at 9:58 AM, Hadriel Kaplan wrote: >=20 > On Dec 1, 2011, at 5:38 PM, Brian Rosen wrote: >=20 >>> You also need a way to reach the same UA instance in deployments = where such are possible - I grok that. >> "Where such deployments are possible" because of design choices, = deployment choices or impairments (congestion, failure, =85)? >>=20 >> The latter is okay. The former two are not.=20 >=20 > I meant in deployments where there could be more than one UA instance = for the same AoR. >=20 > But speaking for your general point of "they must do what we tell them = and I don't care what the repercussions are" - I can't speak to that. = Personally I don't feel the IETF or NENA should be in the business of = telling people how to design, deploy, run, manage, and charge for their = services, regardless of the cost or impact that would have - but that's = not a discussion for this mailing list. >=20 > Along those lines though, why aren't the ECRIT specs mandating IPv6 = everywhere, and NATs or Firewalls must not exist? I mean if you're = going to dictate market forces by fiat, you might as well be thorough. = ;) >=20 > -hadriel >=20 From HKaplan@acmepacket.com Fri Dec 2 07:37:20 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801891F0C5A for ; Fri, 2 Dec 2011 07:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] 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 plV2alClfRM7 for ; Fri, 2 Dec 2011 07:37:20 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id DE1B41F0C4C for ; Fri, 2 Dec 2011 07:37:19 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 2 Dec 2011 10:37:17 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.245]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 2 Dec 2011 10:37:16 -0500 From: Hadriel Kaplan To: Marc Linsner Thread-Topic: [Ecrit] GRUUs for callbacks Thread-Index: AQHMsQhFWpW2O1jgz0KnHjHjV9D+uA== Date: Fri, 2 Dec 2011 15:37:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 15:37:20 -0000 On Dec 1, 2011, at 6:07 PM, Marc Linsner wrote: > I'm thinking they believe they will have more control over the UA softwar= e. Generally I've found they don't think that way, and for good reason. > We don't have requests/claims that callbacks from PSAPs are free. That i= s > not the case in the majority of the US. Hence the eGRUU would simply > negate features under control of the user anyway, so the point would be? I was under the impression that when a consumer receives a call-back from a= PSAP, the consumer is not billed for that call - for example, if the user = has a pay-per-minute or credit-based plan, they will receive a PSAP callbac= k even if they have no credits/minutes left in their plan. Is that not the= case/goal? (I know that for wireless non-subscribers today there's no cal= lback, but I'm not clear if that is in/out-of-scope for ECRIT?) > Resource priority is NOT a requirement germane to this solution. Um... but it's been stated it was by others. -hadriel From HKaplan@acmepacket.com Fri Dec 2 07:51:11 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DBB21F8CA8 for ; Fri, 2 Dec 2011 07:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] 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 C5DcyajPQS5P for ; Fri, 2 Dec 2011 07:51:11 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id E115811E807F for ; Fri, 2 Dec 2011 07:51:10 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 2 Dec 2011 10:51:09 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.245]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 2 Dec 2011 10:51:10 -0500 From: Hadriel Kaplan To: Brian Rosen Thread-Topic: [Ecrit] GRUUs for callbacks Thread-Index: AQHMsQo1WpW2O1jgz0KnHjHjV9D+uA== Date: Fri, 2 Dec 2011 15:51:09 +0000 Message-ID: <03A23FD0-5593-4F99-92CD-88E172E906C5@acmepacket.com> References: <5FF080FB-BB84-48CC-BDB4-E0A93460634D@acmepacket.com> <11776ED1-8A53-4A11-906F-D92DD9D5A28B@acmepacket.com> <9BF92E05-ECC4-499E-AC22-070D218B7C11@brianrosen.net> In-Reply-To: <9BF92E05-ECC4-499E-AC22-070D218B7C11@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 15:51:11 -0000 On Dec 2, 2011, at 10:30 AM, Brian Rosen wrote: > I guess mostly because people can get hurt or die if we can't figure out = how to get them the help they need when, under stress, they do something st= upid like hang up before we got the info we needed. It happens now (call b= ack to device isn't something the PSTN does). Want to be next to a PSAP ca= ll taker when they get voice mail on a call back? Been there. Not pretty.= You get this hopeless feeling that comes from knowing you could help, and= not being able to provide help, because the system failed you. First time= I saw it, I was a lot more upset than the call taker. She'd had it happen= a lot. It was new to me. I'd like to fix that. Of course I'd like to pr= event the hang up in the first place, but the IETF, so far, has decided tha= t call back is all we get. If call back is all we have, then it has to wor= k, IMO. Right, and I'm completely on-board with that, and it's what I said at the m= ic too in Taipei. The rub is *it has to work*. Changing the fundamental n= ature of how SIP deployments are done is not a good path to getting it to w= ork, imho. > We don't need to ban NATs or require IPv6 to make callback work. Ah, but wouldn't it make it far easier to do callbacks? If there were no N= ATs and no Firewalls and everything was IPv6, then the PSAP could just call= directly back to the SIP UA bypassing all proxies/b2buas/domains/etc. But it's not practical to require that. And likewise, it's not practical t= o require GRUUs be used by all SIP domains. Supporting GRUUs is not some t= rivial little configuration knob on one system. It requires a re-architect= ing of the whole network, significant changes on many systems used today, a= nd a whole crap-load of testing. -hadriel From mlinsner@cisco.com Fri Dec 2 10:25:04 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628BF11E80E3 for ; Fri, 2 Dec 2011 10:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 xGJ8fHpFp6Yw for ; Fri, 2 Dec 2011 10:25:04 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id BA5A711E80E2 for ; Fri, 2 Dec 2011 10:25:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=379; q=dns/txt; s=iport; t=1322850303; x=1324059903; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=+ko0F+AIHcetqW6KKNN4w2tdjxnfgkofnR2hXmXfNtE=; b=QXjJJdz4Hp/bGs3MhbKJDFKcgUeaBY+bajTLuuKHsFq/KCNcBfqH1IVf sDsyUxSMwR8RS6wxfNxvu1kADMS3t+Pviu0TP/vtx2aoy1h2KM32/bjHr l3fXHO6CIlmmVmPPxRC0KkNsWvN9jVZHNCW8odYmlHthny/Hy2tyIPf8a A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAP8W2U6tJXG9/2dsb2JhbABDqiqBBYFyAQIEEgEnAgE8EwgOgQ8GDiAHoC0BnkWLIQSIK4wvhUSMbg X-IronPort-AV: E=Sophos;i="4.71,285,1320624000"; d="scan'208";a="40703860" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 02 Dec 2011 18:25:02 +0000 Received: from [10.82.254.92] (rtp-vpn6-1622.cisco.com [10.82.254.92]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pB2IOr6T032079; Fri, 2 Dec 2011 18:24:56 GMT User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Fri, 02 Dec 2011 13:24:50 -0500 From: Marc Linsner To: Hadriel Kaplan Message-ID: Thread-Topic: [Ecrit] GRUUs for callbacks In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 18:25:04 -0000 > > >> Resource priority is NOT a requirement germane to this solution. > >Um... but it's been stated it was by others. > >-hadriel > I believe 'others' are simply attempting to mark the call so it can be recognized as coming from a PSAP. 911 calls have no priority treatment today in the PSTN and they haven't asked for any on the public Internet. -Marc- From mlinsner@cisco.com Fri Dec 2 10:28:31 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2594921F8B5A for ; Fri, 2 Dec 2011 10:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 5fma86nHqtZJ for ; Fri, 2 Dec 2011 10:28:30 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 755FB21F8B55 for ; Fri, 2 Dec 2011 10:28:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=893; q=dns/txt; s=iport; t=1322850510; x=1324060110; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=+hcCD7Xy6ycYO5lnP3qvXj2zca0BSta0oqEKp87muL0=; b=hmRQ9ihSUdJcI8iODoKpZHLlbkBbPUTThGJY5rJGgPp/G2zwdPVqeMol Mvh11u4pBTUJEfYsBVVd1yilk0ceYJXgjm5CYgz0zaltXHOLbEXmyS4S1 g/5p4j08j2uRpGJl5asVe/khFL7OaW3x5mBVRHyJe/kzLX3fLg610M9A0 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADgY2U6tJXG+/2dsb2JhbABDqiqBBYFyAQIEEgEnAgE8EwgOgQ8GDh8IoCoBnkeLIQSIK4wvhUSMbg X-IronPort-AV: E=Sophos;i="4.71,285,1320624000"; d="scan'208";a="40704700" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 02 Dec 2011 18:28:30 +0000 Received: from [10.82.254.92] (rtp-vpn6-1622.cisco.com [10.82.254.92]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id pB2ISEQT013167; Fri, 2 Dec 2011 18:28:20 GMT User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Fri, 02 Dec 2011 13:28:11 -0500 From: Marc Linsner To: Hadriel Kaplan Message-ID: Thread-Topic: [Ecrit] GRUUs for callbacks In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 18:28:31 -0000 > > >> We don't have requests/claims that callbacks from PSAPs are free. That >>is >> not the case in the majority of the US. Hence the eGRUU would simply >> negate features under control of the user anyway, so the point would be? > >I was under the impression that when a consumer receives a call-back from >a PSAP, the consumer is not billed for that call - for example, if the >user has a pay-per-minute or credit-based plan, they will receive a PSAP >callback even if they have no credits/minutes left in their plan. Is >that not the case/goal? (I know that for wireless non-subscribers today >there's no callback, but I'm not clear if that is in/out-of-scope for >ECRIT?) > PSAP callbacks today are from a normal POTS service. If in fact those are not charged, it's news to me. There has been no requirement put forth in ECRIT for 'free' callbacks. -Marc- From rbarnes@bbn.com Fri Dec 2 10:38:44 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB6E1F0C4C for ; Fri, 2 Dec 2011 10:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 98FhepAXC8Am for ; Fri, 2 Dec 2011 10:38:43 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id BD9A41F0C36 for ; Fri, 2 Dec 2011 10:38:43 -0800 (PST) Received: from [192.1.255.200] (port=54026 helo=col-dhcp-192-1-255-200.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RWY0O-000HVo-Bh; Fri, 02 Dec 2011 13:38:40 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Fri, 2 Dec 2011 13:38:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Marc Linsner X-Mailer: Apple Mail (2.1084) Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 18:38:44 -0000 It sounds like there's some disagreement about requirements here. Would = it be useful to have a requirements document? --Richard On Dec 2, 2011, at 1:28 PM, Marc Linsner wrote: >=20 >>=20 >>=20 >>> We don't have requests/claims that callbacks from PSAPs are free. = That >>> is >>> not the case in the majority of the US. Hence the eGRUU would = simply >>> negate features under control of the user anyway, so the point would = be? >>=20 >> I was under the impression that when a consumer receives a call-back = from >> a PSAP, the consumer is not billed for that call - for example, if = the >> user has a pay-per-minute or credit-based plan, they will receive a = PSAP >> callback even if they have no credits/minutes left in their plan. Is >> that not the case/goal? (I know that for wireless non-subscribers = today >> there's no callback, but I'm not clear if that is in/out-of-scope for >> ECRIT?) >>=20 >=20 > PSAP callbacks today are from a normal POTS service. If in fact those = are > not charged, it's news to me. >=20 > There has been no requirement put forth in ECRIT for 'free' callbacks. >=20 > -Marc- >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From christer.holmberg@ericsson.com Fri Dec 2 12:38:08 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3D411E80E5 for ; Fri, 2 Dec 2011 12:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, 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 7HfiiD4YOb2e for ; Fri, 2 Dec 2011 12:38:07 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7430711E8083 for ; Fri, 2 Dec 2011 12:38:07 -0800 (PST) X-AuditID: c1b4fb3d-b7cfeae000005b81-7c-4ed9372e5e33 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 66.94.23425.E2739DE4; Fri, 2 Dec 2011 21:38:06 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.20]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Fri, 2 Dec 2011 21:38:06 +0100 From: Christer Holmberg To: "Richard L. Barnes" , Marc Linsner Date: Fri, 2 Dec 2011 21:33:46 +0100 Thread-Topic: [Ecrit] GRUUs for callbacks Thread-Index: AcyxIaDomRX3UwYTTTSqdBHG/2S41AAEBAGi Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D37@ESESSCMS0356.eemea.ericsson.se> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 20:38:08 -0000 Hi, The requirement is to be able to identify a PSAP callback. Whatever specfic treatments etc are then given to PSAP callbacks by differe= nt networks, and how/if PSAP callbacks are charged, is out of the scope. Regards, Christer ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Richard = L. Barnes [rbarnes@bbn.com] Sent: Friday, December 02, 2011 8:38 PM To: Marc Linsner Cc: ecrit@ietf.org Subject: Re: [Ecrit] GRUUs for callbacks It sounds like there's some disagreement about requirements here. Would it= be useful to have a requirements document? --Richard On Dec 2, 2011, at 1:28 PM, Marc Linsner wrote: > >> >> >>> We don't have requests/claims that callbacks from PSAPs are free. That >>> is >>> not the case in the majority of the US. Hence the eGRUU would simply >>> negate features under control of the user anyway, so the point would be= ? >> >> I was under the impression that when a consumer receives a call-back fro= m >> a PSAP, the consumer is not billed for that call - for example, if the >> user has a pay-per-minute or credit-based plan, they will receive a PSAP >> callback even if they have no credits/minutes left in their plan. Is >> that not the case/goal? (I know that for wireless non-subscribers today >> there's no callback, but I'm not clear if that is in/out-of-scope for >> ECRIT?) >> > > PSAP callbacks today are from a normal POTS service. If in fact those ar= e > not charged, it's news to me. > > There has been no requirement put forth in ECRIT for 'free' callbacks. > > -Marc- > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From jmpolk@cisco.com Fri Dec 2 13:48:11 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A09A11E812C for ; Fri, 2 Dec 2011 13:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 a+r9Ve0BxK+b for ; Fri, 2 Dec 2011 13:48:10 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 77BB711E80C9 for ; Fri, 2 Dec 2011 13:48:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2896; q=dns/txt; s=iport; t=1322862490; x=1324072090; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=e8Th4kOO8BhNUC8ScBkc8hfJw4r7dX4hlI+aJa8dM/k=; b=PwIkYrV9A0odJ/m20w0YSzZo41783tk1G1ClrI4bCil04Kw8wKB0NvMo EzhH7TfVwI0Qi1uIOJuuUtmvECVCdl2Ow8jQDkGyohaHghJFwb/+8+zhS RLL90YjIiT2KCcLe7aI52KLawynO3F+aTmOwGt1XI/RzkAH+0wZ78rWv6 E=; X-IronPort-AV: E=Sophos;i="4.71,286,1320624000"; d="scan'208";a="17441204" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 02 Dec 2011 21:48:10 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pB2Lm9rx028979; Fri, 2 Dec 2011 21:48:09 GMT Message-Id: <201112022148.pB2Lm9rx028979@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 02 Dec 2011 15:48:07 -0600 To: Christer Holmberg , "Richard L. Barnes" , Marc Linsner From: "James M. Polk" In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D37@ESESSCMS0356.ee mea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D37@ESESSCMS0356.eemea.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 21:48:11 -0000 At 02:33 PM 12/2/2011, Christer Holmberg wrote: >Hi, > >The requirement is to be able to identify a PSAP callback. > >Whatever specfic treatments etc are then given to PSAP callbacks by >different networks, and how/if PSAP callbacks are charged, is out of the scope. Through "the networks" may be out of scope (because ECRIT defines things way above layers 3 & 4), but you have to address congestion within SIP servers if you are also attempting to adjust endpoint behavior. Thus, you need to articulate two additional requirements req #2 - that endpoints behave a certain way (e.g., don't DND or divert callback) and req #3 - something about SIP server processing *not* leading to SOC defined mechanisms in which the callback never reaches (or times out before getting to) the original 911/112 caller. Now, req #2 could be covered within phonebcp, but req #3 isn't, and for an effective callback scenario, req #3 needs to be addressed. James >Regards, > >Christer > >________________________________________ >From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of >Richard L. Barnes [rbarnes@bbn.com] >Sent: Friday, December 02, 2011 8:38 PM >To: Marc Linsner >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] GRUUs for callbacks > >It sounds like there's some disagreement about requirements >here. Would it be useful to have a requirements document? > >--Richard > > >On Dec 2, 2011, at 1:28 PM, Marc Linsner wrote: > > > > >> > >> > >>> We don't have requests/claims that callbacks from PSAPs are free. That > >>> is > >>> not the case in the majority of the US. Hence the eGRUU would simply > >>> negate features under control of the user anyway, so the point would be? > >> > >> I was under the impression that when a consumer receives a call-back from > >> a PSAP, the consumer is not billed for that call - for example, if the > >> user has a pay-per-minute or credit-based plan, they will receive a PSAP > >> callback even if they have no credits/minutes left in their plan. Is > >> that not the case/goal? (I know that for wireless non-subscribers today > >> there's no callback, but I'm not clear if that is in/out-of-scope for > >> ECRIT?) > >> > > > > PSAP callbacks today are from a normal POTS service. If in fact those are > > not charged, it's news to me. > > > > There has been no requirement put forth in ECRIT for 'free' callbacks. > > > > -Marc- > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From pkyzivat@alum.mit.edu Sat Dec 3 08:04:49 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE86421F9293 for ; Sat, 3 Dec 2011 08:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] 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 nD90Bir1ImOg for ; Sat, 3 Dec 2011 08:04:49 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id CDB0021F9296 for ; Sat, 3 Dec 2011 08:04:48 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta05.westchester.pa.mail.comcast.net with comcast id 4fGt1i0031ap0As55g4nn2; Sat, 03 Dec 2011 16:04:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta22.westchester.pa.mail.comcast.net with comcast id 4g4n1i00A07duvL3ig4nww; Sat, 03 Dec 2011 16:04:47 +0000 Message-ID: <4EDA48A1.7040906@alum.mit.edu> Date: Sun, 04 Dec 2011 00:04:49 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Marc Linsner References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 16:04:50 -0000 On 12/2/11 6:30 AM, Marc Linsner wrote: >> I'm finding this a little confusing. >> Are you are saying that the UA making the emergency call will get an >> egruu from the registrar/scscf in the visited network, but the resulting >> call will be processed by the scscf of the home network? > > No, it was intended the eGRUU would be minted by the home network and > passed to the UA upon registration. So, if the UA was registered normally, to its home scscf, then it would get the gruu from there? But the emergency call might not traverse the home scscf? But the callback, because it uses a gruu from the home scscf, will traverse that one? In such a case, the home scscf won't know that an emergency call has been made (as Hadriel mentioned). And while it could apply some expiration time to the gruu, the clock for that would start ticking when the registration that minted the gruu was done. That could be a long time ago. (I gather it is not considered desirable to force a special registration just prior to the emergency call - due to the extra time it might take and the possibility that it might fail.) OTOH, IIUC for some IMS cases its also necessary to support emergency calls from SIMless devices that don't have a normal registration. In that case I gather there will be an emergency registration, possibly to a visited network. That is probably the easier case. Thanks, Paul From hgs@cs.columbia.edu Sat Dec 3 08:40:22 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484E621F8ECE for ; Sat, 3 Dec 2011 08:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 JzDxr+AR84eU for ; Sat, 3 Dec 2011 08:40:21 -0800 (PST) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id 53FA721F8C47 for ; Sat, 3 Dec 2011 08:40:13 -0800 (PST) Received: from upstairs-3.home (pool-96-242-116-37.nwrknj.fios.verizon.net [96.242.116.37]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id pB3Ge9hl017864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 3 Dec 2011 11:40:10 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <4EDA48A1.7040906@alum.mit.edu> Date: Sat, 3 Dec 2011 11:40:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu> References: <4EDA48A1.7040906@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: ecrit@ietf.org Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 16:40:22 -0000 We seem to have difficulty finding a single mechanism that meets all = requirements (such as non-forgeability and reach-the-same UA) in all = situations: - SBCs that destroy session identity - UAs and/or proxies that don't support GRUUs - call route divergence (route asymmetry), where the initial outbound = emergency call and the call back traverse different paths. Thus, maybe we need a more probabilistic approach that will work in most = situations, relying on *multiple* markers and indicators. We may not = achieve 100% coverage, but I suspect that the only way of doing that = would be a 100% deployment of an end-to-end cryptographic mechanism that = is recognized by all parties. (Since it seems close to impossible for = the caller to convey an element that survives round-trip, you would = probably have to identify the PSAP, not the call, since there's nothing = that can be signed by the caller and be recognized by third parties.) I can think of a few ingredients that are plausible and "survive" under = different circumstances, two of which we have been discussing before: (1) normal GRUUs, where the inbound proxy remembers that the outbound = call was an emergency call; may fail under some route asymmetry cases = and is subject to GRUU deployment issues. (2) In-Reply-To and Priority; does not require any GRUU or new SIP = elements, but fails with call-ID mangling SBCs and does not address = asymmetric call paths. (3) ARID (draft-ono-dispatch-attribute-validation), which allows = entities on the call path to validate that the call originated from a = PSAP, with pretty minimal infrastructure. (4) PSAP-signed calls (see below). I suspect there are others, but the basic goal seems to be that the = caller, the only one knowing reliably that an emergency call was placed, = needs to tell various elements responsible for inbound call handling to = provide special handling for a specific call, identified by some element = that survives the trip to and from the PSAP. If there was a standard = protocol that allowed a UA to request per-call features, we could = leverage that, but I haven't heard of such a thing. (Just to illustrate = the spirit: The caller could create a CPL rule that bypasses call = treatments just after placing the emergency call, but it seems fanciful = to suggest this as a general mechanism, given the additional complexity = in lots of places.) The usual other way of proving yourself is a challenge-response = mechanism, but that assumes that all the call handling elements share a = secret with the caller. I can't think of a way to build such a system = without a whole lot of new protocol machinery. I also wonder whether for the more complicated IMS scenarios, it = wouldn't be easier to just rely on PSAP signed requests, given that the = number of IMS operators is likely to be not that large and that they are = likely to be reasonably sophisticated operators. In other words, we = don't try to identify return calls, just PSAP-originated calls. Henning On Dec 3, 2011, at 11:04 AM, Paul Kyzivat wrote: > On 12/2/11 6:30 AM, Marc Linsner wrote: >=20 >>> I'm finding this a little confusing. >>> Are you are saying that the UA making the emergency call will get an >>> egruu from the registrar/scscf in the visited network, but the = resulting >>> call will be processed by the scscf of the home network? >>=20 >> No, it was intended the eGRUU would be minted by the home network and >> passed to the UA upon registration. >=20 > So, if the UA was registered normally, to its home scscf, then it = would get the gruu from there? But the emergency call might not traverse = the home scscf? But the callback, because it uses a gruu from the home = scscf, will traverse that one? >=20 > In such a case, the home scscf won't know that an emergency call has = been made (as Hadriel mentioned). And while it could apply some = expiration time to the gruu, the clock for that would start ticking when = the registration that minted the gruu was done. That could be a long = time ago. (I gather it is not considered desirable to force a special = registration just prior to the emergency call - due to the extra time it = might take and the possibility that it might fail.) >=20 > OTOH, IIUC for some IMS cases its also necessary to support emergency = calls from SIMless devices that don't have a normal registration. In = that case I gather there will be an emergency registration, possibly to = a visited network. That is probably the easier case. >=20 > Thanks, > Paul > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From pkyzivat@alum.mit.edu Sat Dec 3 08:52:16 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3008B21F91AB for ; Sat, 3 Dec 2011 08:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] 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 YUglk8guzuyC for ; Sat, 3 Dec 2011 08:52:15 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 61DD421F9290 for ; Sat, 3 Dec 2011 08:52:15 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta05.westchester.pa.mail.comcast.net with comcast id 4fu51i0051YDfWL55gsFbr; Sat, 03 Dec 2011 16:52:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta20.westchester.pa.mail.comcast.net with comcast id 4gsF1i00807duvL3ggsF35; Sat, 03 Dec 2011 16:52:15 +0000 Message-ID: <4EDA53C1.1080501@alum.mit.edu> Date: Sun, 04 Dec 2011 00:52:17 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: ecrit@ietf.org References: , <7F2072F1E0DE894DA4B517B93C6A05852C3A578D37@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D37@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 16:52:16 -0000 On 12/3/11 4:33 AM, Christer Holmberg wrote: > > Hi, > > The requirement is to be able to identify a PSAP callback. > > Whatever specfic treatments etc are then given to PSAP callbacks by different networks, and how/if PSAP callbacks are charged, is out of the scope. Based on the discussion, that doesn't seem to be a sufficient requirement. Specifically, it doesn't address *which* elements must be able to discover that the call is a psap callback. I am guessing your intent is that every server on the path be able to discover this by examining the indication in the signaling. But the mechanisms that have been discussed fall short in this regard: - the proposal to have a special uri parameter in an egruu allows anybody along the path to note this, until the egruu is translated. But most can't verify this is a valid marking. Only elements coordinated with the registrar issuing the gruu have much of a chance of determining that. - And elements downstream of the egruu translation can only detect this via H-I. If H-I isn't used they can't determine this. - The egruu itself doesn't guarantee that the call is a psap callback. If the egruu is only generated at the time an emergency call is made, and an expiration timer is started then, its possible to reduce the probability of fraud. But its not a very strong check. And I'm not sure how you guarantee that a UA doesn't request an egruu, use it in a non-emergency call, and then get the other end to call back on that egruu in order to get the benefits. ISTM that we trust the psap more than the UA making the emergency call. So ISTM it would make more sense to have the psap UA initiate the indication, without involvement of original calling UA. This suggests something like GETS. Thanks, Paul > Regards, > > Christer > > ________________________________________ > From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Richard L. Barnes [rbarnes@bbn.com] > Sent: Friday, December 02, 2011 8:38 PM > To: Marc Linsner > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] GRUUs for callbacks > > It sounds like there's some disagreement about requirements here. Would it be useful to have a requirements document? > > --Richard > > > On Dec 2, 2011, at 1:28 PM, Marc Linsner wrote: > >> >>> >>> >>>> We don't have requests/claims that callbacks from PSAPs are free. That >>>> is >>>> not the case in the majority of the US. Hence the eGRUU would simply >>>> negate features under control of the user anyway, so the point would be? >>> >>> I was under the impression that when a consumer receives a call-back from >>> a PSAP, the consumer is not billed for that call - for example, if the >>> user has a pay-per-minute or credit-based plan, they will receive a PSAP >>> callback even if they have no credits/minutes left in their plan. Is >>> that not the case/goal? (I know that for wireless non-subscribers today >>> there's no callback, but I'm not clear if that is in/out-of-scope for >>> ECRIT?) >>> >> >> PSAP callbacks today are from a normal POTS service. If in fact those are >> not charged, it's news to me. >> >> There has been no requirement put forth in ECRIT for 'free' callbacks. >> >> -Marc- >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From pkyzivat@alum.mit.edu Sat Dec 3 09:11:41 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0A321F91AB for ; Sat, 3 Dec 2011 09:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] 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 I4uYUWOuKQpk for ; Sat, 3 Dec 2011 09:11:40 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 89B4821F8E8E for ; Sat, 3 Dec 2011 09:11:40 -0800 (PST) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta07.westchester.pa.mail.comcast.net with comcast id 4h8h1i0020mv7h057hBhFq; Sat, 03 Dec 2011 17:11:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta11.westchester.pa.mail.comcast.net with comcast id 4hBg1i01N07duvL3XhBguS; Sat, 03 Dec 2011 17:11:40 +0000 Message-ID: <4EDA584E.2050604@alum.mit.edu> Date: Sun, 04 Dec 2011 01:11:42 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Henning Schulzrinne References: <4EDA48A1.7040906@alum.mit.edu> <02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu> In-Reply-To: <02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 17:11:41 -0000 Why not forget about detecting and verifying that the call is a *callback* to an emergency call. Instead, simply give the psap a way to initiate a "priority" call to some URI. Then expect the elements on the path to take special action on these, such as bypassing features like VM. We can rely on policy to restrict such calls to callbacks, or comparably compelling reasons. There is still work to be done to satisfy this, but some hard things are avoided. Thanks, Paul On 12/4/11 12:40 AM, Henning Schulzrinne wrote: > We seem to have difficulty finding a single mechanism that meets all requirements (such as non-forgeability and reach-the-same UA) in all situations: > - SBCs that destroy session identity > - UAs and/or proxies that don't support GRUUs > - call route divergence (route asymmetry), where the initial outbound emergency call and the call back traverse different paths. > > Thus, maybe we need a more probabilistic approach that will work in most situations, relying on *multiple* markers and indicators. We may not achieve 100% coverage, but I suspect that the only way of doing that would be a 100% deployment of an end-to-end cryptographic mechanism that is recognized by all parties. (Since it seems close to impossible for the caller to convey an element that survives round-trip, you would probably have to identify the PSAP, not the call, since there's nothing that can be signed by the caller and be recognized by third parties.) > > I can think of a few ingredients that are plausible and "survive" under different circumstances, two of which we have been discussing before: > > (1) normal GRUUs, where the inbound proxy remembers that the outbound call was an emergency call; may fail under some route asymmetry cases and is subject to GRUU deployment issues. > > (2) In-Reply-To and Priority; does not require any GRUU or new SIP elements, but fails with call-ID mangling SBCs and does not address asymmetric call paths. > > (3) ARID (draft-ono-dispatch-attribute-validation), which allows entities on the call path to validate that the call originated from a PSAP, with pretty minimal infrastructure. > > (4) PSAP-signed calls (see below). > > I suspect there are others, but the basic goal seems to be that the caller, the only one knowing reliably that an emergency call was placed, needs to tell various elements responsible for inbound call handling to provide special handling for a specific call, identified by some element that survives the trip to and from the PSAP. If there was a standard protocol that allowed a UA to request per-call features, we could leverage that, but I haven't heard of such a thing. (Just to illustrate the spirit: The caller could create a CPL rule that bypasses call treatments just after placing the emergency call, but it seems fanciful to suggest this as a general mechanism, given the additional complexity in lots of places.) > > The usual other way of proving yourself is a challenge-response mechanism, but that assumes that all the call handling elements share a secret with the caller. I can't think of a way to build such a system without a whole lot of new protocol machinery. > > I also wonder whether for the more complicated IMS scenarios, it wouldn't be easier to just rely on PSAP signed requests, given that the number of IMS operators is likely to be not that large and that they are likely to be reasonably sophisticated operators. In other words, we don't try to identify return calls, just PSAP-originated calls. > > Henning > > On Dec 3, 2011, at 11:04 AM, Paul Kyzivat wrote: > >> On 12/2/11 6:30 AM, Marc Linsner wrote: >> >>>> I'm finding this a little confusing. >>>> Are you are saying that the UA making the emergency call will get an >>>> egruu from the registrar/scscf in the visited network, but the resulting >>>> call will be processed by the scscf of the home network? >>> >>> No, it was intended the eGRUU would be minted by the home network and >>> passed to the UA upon registration. >> >> So, if the UA was registered normally, to its home scscf, then it would get the gruu from there? But the emergency call might not traverse the home scscf? But the callback, because it uses a gruu from the home scscf, will traverse that one? >> >> In such a case, the home scscf won't know that an emergency call has been made (as Hadriel mentioned). And while it could apply some expiration time to the gruu, the clock for that would start ticking when the registration that minted the gruu was done. That could be a long time ago. (I gather it is not considered desirable to force a special registration just prior to the emergency call - due to the extra time it might take and the possibility that it might fail.) >> >> OTOH, IIUC for some IMS cases its also necessary to support emergency calls from SIMless devices that don't have a normal registration. In that case I gather there will be an emergency registration, possibly to a visited network. That is probably the easier case. >> >> Thanks, >> Paul >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > From hgs@cs.columbia.edu Sat Dec 3 09:29:00 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A8821F9309 for ; Sat, 3 Dec 2011 09:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 c1-hleYdGENW for ; Sat, 3 Dec 2011 09:28:59 -0800 (PST) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAFD21F9205 for ; Sat, 3 Dec 2011 09:28:59 -0800 (PST) Received: from upstairs-3.home (pool-96-242-116-37.nwrknj.fios.verizon.net [96.242.116.37]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id pB3HSuco023434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 3 Dec 2011 12:28:57 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Henning Schulzrinne In-Reply-To: <4EDA584E.2050604@alum.mit.edu> Date: Sat, 3 Dec 2011 12:28:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu> References: <4EDA48A1.7040906@alum.mit.edu> <02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu> <4EDA584E.2050604@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: ecrit@ietf.org Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 17:29:00 -0000 That's roughly what I said below (last paragraph), so I'm a bit confused = by your response. Both the ARID and the signed call mechanism rely on = identifying the privileged caller (PSAP), rather than identifying a = callback. However, from a deployability perspective, this requires = significant changes in a number of places. If we're complaining about = GRUUs not being widely deployed, we can't exactly call deploying a = completely new solution an improvement. This is why I'm trying to suggest that searching for a single magic = solution that is - secure - works everywhere - works with broken implementations - works with no changes anywhere is a fool's errand. Rather, by combining solutions, we might allow = different providers/enterprise/UAs to pick their own trade-off and = migrate to better solutions over time. Henning On Dec 3, 2011, at 12:11 PM, Paul Kyzivat wrote: > Why not forget about detecting and verifying that the call is a = *callback* to an emergency call. Instead, simply give the psap a way to = initiate a "priority" call to some URI. Then expect the elements on the = path to take special action on these, such as bypassing features like = VM. >=20 > We can rely on policy to restrict such calls to callbacks, or = comparably compelling reasons. >=20 > There is still work to be done to satisfy this, but some hard things = are avoided. >=20 > Thanks, > Paul >=20 > On 12/4/11 12:40 AM, Henning Schulzrinne wrote: >> We seem to have difficulty finding a single mechanism that meets all = requirements (such as non-forgeability and reach-the-same UA) in all = situations: >> - SBCs that destroy session identity >> - UAs and/or proxies that don't support GRUUs >> - call route divergence (route asymmetry), where the initial outbound = emergency call and the call back traverse different paths. >>=20 >> Thus, maybe we need a more probabilistic approach that will work in = most situations, relying on *multiple* markers and indicators. We may = not achieve 100% coverage, but I suspect that the only way of doing that = would be a 100% deployment of an end-to-end cryptographic mechanism that = is recognized by all parties. (Since it seems close to impossible for = the caller to convey an element that survives round-trip, you would = probably have to identify the PSAP, not the call, since there's nothing = that can be signed by the caller and be recognized by third parties.) >>=20 >> I can think of a few ingredients that are plausible and "survive" = under different circumstances, two of which we have been discussing = before: >>=20 >> (1) normal GRUUs, where the inbound proxy remembers that the outbound = call was an emergency call; may fail under some route asymmetry cases = and is subject to GRUU deployment issues. >>=20 >> (2) In-Reply-To and Priority; does not require any GRUU or new SIP = elements, but fails with call-ID mangling SBCs and does not address = asymmetric call paths. >>=20 >> (3) ARID (draft-ono-dispatch-attribute-validation), which allows = entities on the call path to validate that the call originated from a = PSAP, with pretty minimal infrastructure. >>=20 >> (4) PSAP-signed calls (see below). >>=20 >> I suspect there are others, but the basic goal seems to be that the = caller, the only one knowing reliably that an emergency call was placed, = needs to tell various elements responsible for inbound call handling to = provide special handling for a specific call, identified by some element = that survives the trip to and from the PSAP. If there was a standard = protocol that allowed a UA to request per-call features, we could = leverage that, but I haven't heard of such a thing. (Just to illustrate = the spirit: The caller could create a CPL rule that bypasses call = treatments just after placing the emergency call, but it seems fanciful = to suggest this as a general mechanism, given the additional complexity = in lots of places.) >>=20 >> The usual other way of proving yourself is a challenge-response = mechanism, but that assumes that all the call handling elements share a = secret with the caller. I can't think of a way to build such a system = without a whole lot of new protocol machinery. >>=20 >> I also wonder whether for the more complicated IMS scenarios, it = wouldn't be easier to just rely on PSAP signed requests, given that the = number of IMS operators is likely to be not that large and that they are = likely to be reasonably sophisticated operators. In other words, we = don't try to identify return calls, just PSAP-originated calls. >>=20 >> Henning >>=20 >> On Dec 3, 2011, at 11:04 AM, Paul Kyzivat wrote: >>=20 >>> On 12/2/11 6:30 AM, Marc Linsner wrote: >>>=20 >>>>> I'm finding this a little confusing. >>>>> Are you are saying that the UA making the emergency call will get = an >>>>> egruu from the registrar/scscf in the visited network, but the = resulting >>>>> call will be processed by the scscf of the home network? >>>>=20 >>>> No, it was intended the eGRUU would be minted by the home network = and >>>> passed to the UA upon registration. >>>=20 >>> So, if the UA was registered normally, to its home scscf, then it = would get the gruu from there? But the emergency call might not traverse = the home scscf? But the callback, because it uses a gruu from the home = scscf, will traverse that one? >>>=20 >>> In such a case, the home scscf won't know that an emergency call has = been made (as Hadriel mentioned). And while it could apply some = expiration time to the gruu, the clock for that would start ticking when = the registration that minted the gruu was done. That could be a long = time ago. (I gather it is not considered desirable to force a special = registration just prior to the emergency call - due to the extra time it = might take and the possibility that it might fail.) >>>=20 >>> OTOH, IIUC for some IMS cases its also necessary to support = emergency calls from SIMless devices that don't have a normal = registration. In that case I gather there will be an emergency = registration, possibly to a visited network. That is probably the easier = case. >>>=20 >>> Thanks, >>> Paul >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>=20 >>=20 >=20 >=20 From pkyzivat@alum.mit.edu Sat Dec 3 11:13:10 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859C421F8E77 for ; Sat, 3 Dec 2011 11:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 Opz5QJyl6PVp for ; Sat, 3 Dec 2011 11:13:09 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8928E21F8E5F for ; Sat, 3 Dec 2011 11:13:09 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta07.westchester.pa.mail.comcast.net with comcast id 4j2K1i0040cZkys57jDAjf; Sat, 03 Dec 2011 19:13:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta10.westchester.pa.mail.comcast.net with comcast id 4jD91i00Y07duvL3WjD9Qe; Sat, 03 Dec 2011 19:13:09 +0000 Message-ID: <4EDA74C3.9070603@alum.mit.edu> Date: Sun, 04 Dec 2011 03:13:07 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Henning Schulzrinne References: <4EDA48A1.7040906@alum.mit.edu> <02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu> <4EDA584E.2050604@alum.mit.edu> <255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu> In-Reply-To: <255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 19:13:10 -0000 On 12/4/11 1:28 AM, Henning Schulzrinne wrote: > That's roughly what I said below (last paragraph), so I'm a bit confused by your response. Both the ARID and the signed call mechanism rely on identifying the privileged caller (PSAP), rather than identifying a callback. However, from a deployability perspective, this requires significant changes in a number of places. If we're complaining about GRUUs not being widely deployed, we can't exactly call deploying a completely new solution an improvement. > > This is why I'm trying to suggest that searching for a single magic solution that is > > - secure > - works everywhere > - works with broken implementations > - works with no changes anywhere > > is a fool's errand. Rather, by combining solutions, we might allow different providers/enterprise/UAs to pick their own trade-off and migrate to better solutions over time. Its possible we are not disagreeing much, but just thinking about things differently, or focusing on different things. But I am a bit concerned that a scatter gun approach, where providers pick the pieces they like, may just result in needless differences and systems that don't work well. If we agree that it isn't feasible to get an ideal system that meets all our wishes, then perhaps we can get a general agreement on a lesser set of requirements. E.g. - its most important for the psap to be able, on explicit request, to achieve expedited access to an arbitrary AOR. (This might be a callback to an emergency call, via Contact AOR or From AOR, or whatever of the emergency call. It might also be some other AOR.) - its nearly as important that the expedited access be able to reach devices that have recently made an emergency call but are normally not permitted or able to receive calls. - its important (but less so) to minimize fraud by preventing non- psaps from getting the sort of expedited access mentioned above. - it may be desirable that callees not be charged for receiving these expedited calls. (Decisions about this are based on policy.) If we were to agree to the above, then we could start identifying mechanisms to support each. But some of them might be incomplete. For instance, to achieve the first, we come up with a mechanism to indicate this is a psap expedited call. (e.g. urn:sos in From or P-A-ID.) For the second, maybe nothing else is required in signaling if the contact address is reachable - just some policy adjustments. In other cases it might require allowing some sort of emergency registration, and then would only work as long as that registration remains in effect. Some might not bother to minimize fraud at all. Others might depend on transitive trust to prevent unauthorized parties from making the indication for a psap expedited call. Or something like ARID might be used. The disabling of fees could presumably be driven by one of the above mechanisms if desired. Thanks, Paul > Henning > > On Dec 3, 2011, at 12:11 PM, Paul Kyzivat wrote: > >> Why not forget about detecting and verifying that the call is a *callback* to an emergency call. Instead, simply give the psap a way to initiate a "priority" call to some URI. Then expect the elements on the path to take special action on these, such as bypassing features like VM. >> >> We can rely on policy to restrict such calls to callbacks, or comparably compelling reasons. >> >> There is still work to be done to satisfy this, but some hard things are avoided. >> >> Thanks, >> Paul >> >> On 12/4/11 12:40 AM, Henning Schulzrinne wrote: >>> We seem to have difficulty finding a single mechanism that meets all requirements (such as non-forgeability and reach-the-same UA) in all situations: >>> - SBCs that destroy session identity >>> - UAs and/or proxies that don't support GRUUs >>> - call route divergence (route asymmetry), where the initial outbound emergency call and the call back traverse different paths. >>> >>> Thus, maybe we need a more probabilistic approach that will work in most situations, relying on *multiple* markers and indicators. We may not achieve 100% coverage, but I suspect that the only way of doing that would be a 100% deployment of an end-to-end cryptographic mechanism that is recognized by all parties. (Since it seems close to impossible for the caller to convey an element that survives round-trip, you would probably have to identify the PSAP, not the call, since there's nothing that can be signed by the caller and be recognized by third parties.) >>> >>> I can think of a few ingredients that are plausible and "survive" under different circumstances, two of which we have been discussing before: >>> >>> (1) normal GRUUs, where the inbound proxy remembers that the outbound call was an emergency call; may fail under some route asymmetry cases and is subject to GRUU deployment issues. >>> >>> (2) In-Reply-To and Priority; does not require any GRUU or new SIP elements, but fails with call-ID mangling SBCs and does not address asymmetric call paths. >>> >>> (3) ARID (draft-ono-dispatch-attribute-validation), which allows entities on the call path to validate that the call originated from a PSAP, with pretty minimal infrastructure. >>> >>> (4) PSAP-signed calls (see below). >>> >>> I suspect there are others, but the basic goal seems to be that the caller, the only one knowing reliably that an emergency call was placed, needs to tell various elements responsible for inbound call handling to provide special handling for a specific call, identified by some element that survives the trip to and from the PSAP. If there was a standard protocol that allowed a UA to request per-call features, we could leverage that, but I haven't heard of such a thing. (Just to illustrate the spirit: The caller could create a CPL rule that bypasses call treatments just after placing the emergency call, but it seems fanciful to suggest this as a general mechanism, given the additional complexity in lots of places.) >>> >>> The usual other way of proving yourself is a challenge-response mechanism, but that assumes that all the call handling elements share a secret with the caller. I can't think of a way to build such a system without a whole lot of new protocol machinery. >>> >>> I also wonder whether for the more complicated IMS scenarios, it wouldn't be easier to just rely on PSAP signed requests, given that the number of IMS operators is likely to be not that large and that they are likely to be reasonably sophisticated operators. In other words, we don't try to identify return calls, just PSAP-originated calls. >>> >>> Henning >>> >>> On Dec 3, 2011, at 11:04 AM, Paul Kyzivat wrote: >>> >>>> On 12/2/11 6:30 AM, Marc Linsner wrote: >>>> >>>>>> I'm finding this a little confusing. >>>>>> Are you are saying that the UA making the emergency call will get an >>>>>> egruu from the registrar/scscf in the visited network, but the resulting >>>>>> call will be processed by the scscf of the home network? >>>>> >>>>> No, it was intended the eGRUU would be minted by the home network and >>>>> passed to the UA upon registration. >>>> >>>> So, if the UA was registered normally, to its home scscf, then it would get the gruu from there? But the emergency call might not traverse the home scscf? But the callback, because it uses a gruu from the home scscf, will traverse that one? >>>> >>>> In such a case, the home scscf won't know that an emergency call has been made (as Hadriel mentioned). And while it could apply some expiration time to the gruu, the clock for that would start ticking when the registration that minted the gruu was done. That could be a long time ago. (I gather it is not considered desirable to force a special registration just prior to the emergency call - due to the extra time it might take and the possibility that it might fail.) >>>> >>>> OTOH, IIUC for some IMS cases its also necessary to support emergency calls from SIMless devices that don't have a normal registration. In that case I gather there will be an emergency registration, possibly to a visited network. That is probably the easier case. >>>> >>>> Thanks, >>>> Paul >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>> >>> >> >> > > From br@brianrosen.net Mon Dec 5 07:46:53 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23D821F8C22 for ; Mon, 5 Dec 2011 07:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] 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 7qe5q8WFkarW for ; Mon, 5 Dec 2011 07:46:52 -0800 (PST) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id B029021F8C28 for ; Mon, 5 Dec 2011 07:46:52 -0800 (PST) X-ASG-Debug-ID: 1323100011-011a9f4fb2daa50001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id gw24bj4rC7ssY8sy; Mon, 05 Dec 2011 07:46:51 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.33]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RXakk-00074m-Fz; Mon, 05 Dec 2011 07:46:50 -0800 X-Barracuda-BBL-IP: 209.173.57.233 X-Barracuda-RBL-IP: 209.173.57.233 Mime-Version: 1.0 (Apple Message framework v1251.1) X-ASG-Orig-Subj: Re: [Ecrit] GRUUs for callbacks Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <4EDA74C3.9070603@alum.mit.edu> Date: Mon, 5 Dec 2011 10:46:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net> References: <4EDA48A1.7040906@alum.mit.edu> <02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu> <4EDA584E.2050604@alum.mit.edu> <255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu> <4EDA74C3.9070603@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1251.1) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1323100011 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.82218 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: ecrit@ietf.org Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 15:46:53 -0000 phonebcp and NENA i3 docs differentiate between callbacks that are = immediate (within minutes of the call) and later. The former is (currently) to Contact, and the latter is to AoR (P-A-I = or From, ideally with Identity). The requirement for the former is pretty simple - that which is in = Contact gets back to the device that made the call. That's basic 3261 = isn't it? While priority is a nice to have, and free is a nice to have, neither is = essential, and if they were available, they would only apply to the URI = in Contact. It doesn't matter to the emergency call system what is in Contact. It's = just a URI that if called, gets to the right device. phonebcp says it = should remain valid for several minutes beyond the call unless the = subscription expires and is not renewed. It would be straightforward in my opinion to have PSAPs sign (Identity) = for callbacks if that would be helpful. Any reasonable marking (some = urn in R-URI with actual target in Route, the particulars of the = Identity header, or anything else straightforward is fine. They can = have any RPH, any Priority header, and populating In-Response-To is = easy. None of that applies to the later call back to P-A-I or From. They are = just calls. Brian On Dec 3, 2011, at 2:13 PM, Paul Kyzivat wrote: > On 12/4/11 1:28 AM, Henning Schulzrinne wrote: >> That's roughly what I said below (last paragraph), so I'm a bit = confused by your response. Both the ARID and the signed call mechanism = rely on identifying the privileged caller (PSAP), rather than = identifying a callback. However, from a deployability perspective, this = requires significant changes in a number of places. If we're complaining = about GRUUs not being widely deployed, we can't exactly call deploying a = completely new solution an improvement. >>=20 >> This is why I'm trying to suggest that searching for a single magic = solution that is >>=20 >> - secure >> - works everywhere >> - works with broken implementations >> - works with no changes anywhere >>=20 >> is a fool's errand. Rather, by combining solutions, we might allow = different providers/enterprise/UAs to pick their own trade-off and = migrate to better solutions over time. >=20 > Its possible we are not disagreeing much, but just thinking about = things differently, or focusing on different things. >=20 > But I am a bit concerned that a scatter gun approach, where providers = pick the pieces they like, may just result in needless differences and = systems that don't work well. >=20 > If we agree that it isn't feasible to get an ideal system that meets = all our wishes, then perhaps we can get a general agreement on a lesser = set of requirements. E.g. >=20 > - its most important for the psap to be able, on explicit request, > to achieve expedited access to an arbitrary AOR. > (This might be a callback to an emergency call, via Contact AOR > or =46rom AOR, or whatever of the emergency call. It might also > be some other AOR.) >=20 > - its nearly as important that the expedited access be able to reach > devices that have recently made an emergency call but are normally > not permitted or able to receive calls. >=20 > - its important (but less so) to minimize fraud by preventing non- > psaps from getting the sort of expedited access mentioned above. >=20 > - it may be desirable that callees not be charged for receiving these > expedited calls. (Decisions about this are based on policy.) >=20 > If we were to agree to the above, then we could start identifying = mechanisms to support each. But some of them might be incomplete. >=20 > For instance, to achieve the first, we come up with a mechanism to = indicate this is a psap expedited call. (e.g. urn:sos in =46rom or = P-A-ID.) >=20 > For the second, maybe nothing else is required in signaling if the = contact address is reachable - just some policy adjustments. In other = cases it might require allowing some sort of emergency registration, and = then would only work as long as that registration remains in effect. >=20 > Some might not bother to minimize fraud at all. Others might depend on = transitive trust to prevent unauthorized parties from making the = indication for a psap expedited call. Or something like ARID might be = used. >=20 > The disabling of fees could presumably be driven by one of the above = mechanisms if desired. >=20 > Thanks, > Paul >=20 >> Henning >>=20 >> On Dec 3, 2011, at 12:11 PM, Paul Kyzivat wrote: >>=20 >>> Why not forget about detecting and verifying that the call is a = *callback* to an emergency call. Instead, simply give the psap a way to = initiate a "priority" call to some URI. Then expect the elements on the = path to take special action on these, such as bypassing features like = VM. >>>=20 >>> We can rely on policy to restrict such calls to callbacks, or = comparably compelling reasons. >>>=20 >>> There is still work to be done to satisfy this, but some hard things = are avoided. >>>=20 >>> Thanks, >>> Paul >>>=20 >>> On 12/4/11 12:40 AM, Henning Schulzrinne wrote: >>>> We seem to have difficulty finding a single mechanism that meets = all requirements (such as non-forgeability and reach-the-same UA) in all = situations: >>>> - SBCs that destroy session identity >>>> - UAs and/or proxies that don't support GRUUs >>>> - call route divergence (route asymmetry), where the initial = outbound emergency call and the call back traverse different paths. >>>>=20 >>>> Thus, maybe we need a more probabilistic approach that will work in = most situations, relying on *multiple* markers and indicators. We may = not achieve 100% coverage, but I suspect that the only way of doing that = would be a 100% deployment of an end-to-end cryptographic mechanism that = is recognized by all parties. (Since it seems close to impossible for = the caller to convey an element that survives round-trip, you would = probably have to identify the PSAP, not the call, since there's nothing = that can be signed by the caller and be recognized by third parties.) >>>>=20 >>>> I can think of a few ingredients that are plausible and "survive" = under different circumstances, two of which we have been discussing = before: >>>>=20 >>>> (1) normal GRUUs, where the inbound proxy remembers that the = outbound call was an emergency call; may fail under some route asymmetry = cases and is subject to GRUU deployment issues. >>>>=20 >>>> (2) In-Reply-To and Priority; does not require any GRUU or new SIP = elements, but fails with call-ID mangling SBCs and does not address = asymmetric call paths. >>>>=20 >>>> (3) ARID (draft-ono-dispatch-attribute-validation), which allows = entities on the call path to validate that the call originated from a = PSAP, with pretty minimal infrastructure. >>>>=20 >>>> (4) PSAP-signed calls (see below). >>>>=20 >>>> I suspect there are others, but the basic goal seems to be that the = caller, the only one knowing reliably that an emergency call was placed, = needs to tell various elements responsible for inbound call handling to = provide special handling for a specific call, identified by some element = that survives the trip to and from the PSAP. If there was a standard = protocol that allowed a UA to request per-call features, we could = leverage that, but I haven't heard of such a thing. (Just to illustrate = the spirit: The caller could create a CPL rule that bypasses call = treatments just after placing the emergency call, but it seems fanciful = to suggest this as a general mechanism, given the additional complexity = in lots of places.) >>>>=20 >>>> The usual other way of proving yourself is a challenge-response = mechanism, but that assumes that all the call handling elements share a = secret with the caller. I can't think of a way to build such a system = without a whole lot of new protocol machinery. >>>>=20 >>>> I also wonder whether for the more complicated IMS scenarios, it = wouldn't be easier to just rely on PSAP signed requests, given that the = number of IMS operators is likely to be not that large and that they are = likely to be reasonably sophisticated operators. In other words, we = don't try to identify return calls, just PSAP-originated calls. >>>>=20 >>>> Henning >>>>=20 >>>> On Dec 3, 2011, at 11:04 AM, Paul Kyzivat wrote: >>>>=20 >>>>> On 12/2/11 6:30 AM, Marc Linsner wrote: >>>>>=20 >>>>>>> I'm finding this a little confusing. >>>>>>> Are you are saying that the UA making the emergency call will = get an >>>>>>> egruu from the registrar/scscf in the visited network, but the = resulting >>>>>>> call will be processed by the scscf of the home network? >>>>>>=20 >>>>>> No, it was intended the eGRUU would be minted by the home network = and >>>>>> passed to the UA upon registration. >>>>>=20 >>>>> So, if the UA was registered normally, to its home scscf, then it = would get the gruu from there? But the emergency call might not traverse = the home scscf? But the callback, because it uses a gruu from the home = scscf, will traverse that one? >>>>>=20 >>>>> In such a case, the home scscf won't know that an emergency call = has been made (as Hadriel mentioned). And while it could apply some = expiration time to the gruu, the clock for that would start ticking when = the registration that minted the gruu was done. That could be a long = time ago. (I gather it is not considered desirable to force a special = registration just prior to the emergency call - due to the extra time it = might take and the possibility that it might fail.) >>>>>=20 >>>>> OTOH, IIUC for some IMS cases its also necessary to support = emergency calls from SIMless devices that don't have a normal = registration. In that case I gather there will be an emergency = registration, possibly to a visited network. That is probably the easier = case. >>>>>=20 >>>>> Thanks, >>>>> Paul >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From pkyzivat@alum.mit.edu Mon Dec 5 08:43:19 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F2721F85A8 for ; Mon, 5 Dec 2011 08:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 9Jaw8QX4oL9d for ; Mon, 5 Dec 2011 08:43:18 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id D269121F8448 for ; Mon, 5 Dec 2011 08:43:17 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta06.westchester.pa.mail.comcast.net with comcast id 5UbG1i0040QuhwU56UjJ97; Mon, 05 Dec 2011 16:43:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta02.westchester.pa.mail.comcast.net with comcast id 5UjH1i00M07duvL3NUjHMU; Mon, 05 Dec 2011 16:43:18 +0000 Message-ID: <4EDCF4A4.60901@alum.mit.edu> Date: Tue, 06 Dec 2011 00:43:16 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Brian Rosen References: <4EDA48A1.7040906@alum.mit.edu> <02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu> <4EDA584E.2050604@alum.mit.edu> <255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu> <4EDA74C3.9070603@alum.mit.edu> <2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net> In-Reply-To: <2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 16:43:19 -0000 On 12/5/11 11:46 PM, Brian Rosen wrote: > phonebcp and NENA i3 docs differentiate between callbacks that are immediate (within minutes of the call) and later. > > The former is (currently) to Contact, and the latter is to AoR (P-A-I or From, ideally with Identity). > > The requirement for the former is pretty simple - that which is in Contact gets back to the device that made the call. That's basic 3261 isn't it? Yep, its basic 3261. But GRUU was an admission that people weren't implementing basic 3261. The lack of widespread support of GRUU may mean: - some don't see it as important to support out-of-dialog callback to the contact of a dialog - a perceived alternate way of implementing that makes the callback to the contact work without gruu. (E.g. an SBC substituting an address and supporting callbacks to it for some time, or supplying the AOR as the contact address in the call.) Maybe Hadriel will comment on what he has seen in the wild, or Robert will comment on what he has seen at sipit. > While priority is a nice to have, and free is a nice to have, neither is essential, and if they were available, they would only apply to the URI in Contact. Is there an expectation that the psap will try a callback to the AOR if callback to the Contact fails? ISTM that would be an expedient strategy. If so, it would be good if the callback to the AOR also could request priority, and to suppress features. Perhaps this could be at the discretion of the psap caller. > It doesn't matter to the emergency call system what is in Contact. It's just a URI that if called, gets to the right device. phonebcp says it should remain valid for several minutes beyond the call unless the subscription expires and is not renewed. If GRUU is not supported, and the native contact of the calling UA isn't globally routable, then callback to the contact might not work at all, or it may only work while the dialog is still up. > It would be straightforward in my opinion to have PSAPs sign (Identity) for callbacks if that would be helpful. I guess the problem with this is that it likely won't survive transit through an SBC. > Any reasonable marking (some urn in R-URI with actual target in Route, the particulars of the Identity header, or anything else straightforward is fine. They can have any RPH, any Priority header, and populating In-Response-To is easy. I figured that was the case. The trick is to find something that has a high probability of working in real deployments. (Possibly with adjustments to SBC policies to make it work.) This perhaps needn't be unforgeable, if the consequences of forging it are acceptable. That probably means that a forgeable mark not bestow free calls. A forgeable mark providing priority and/or bypassing call blocking on the receiving side might be tolerable. Conceivably the provider could only allow this some limited number of times to mitigate it. A forgeable mark bypassing features that screen callers or otherwise limit direct access to the callee is more problematic. Possibly this could be handled by the emergency caller's UA itself - by remembering that it made an emergency call recently or not. It could then reject calls with this marking if it hasn't recently made an emergency call. This isn't ideal, since it bothers the UA, but it avoids bothering the user. (But it still provides a vector for a DOS attack on the UA.) Thanks, Paul > None of that applies to the later call back to P-A-I or From. They are just calls. > > Brian > > On Dec 3, 2011, at 2:13 PM, Paul Kyzivat wrote: > >> On 12/4/11 1:28 AM, Henning Schulzrinne wrote: >>> That's roughly what I said below (last paragraph), so I'm a bit confused by your response. Both the ARID and the signed call mechanism rely on identifying the privileged caller (PSAP), rather than identifying a callback. However, from a deployability perspective, this requires significant changes in a number of places. If we're complaining about GRUUs not being widely deployed, we can't exactly call deploying a completely new solution an improvement. >>> >>> This is why I'm trying to suggest that searching for a single magic solution that is >>> >>> - secure >>> - works everywhere >>> - works with broken implementations >>> - works with no changes anywhere >>> >>> is a fool's errand. Rather, by combining solutions, we might allow different providers/enterprise/UAs to pick their own trade-off and migrate to better solutions over time. >> >> Its possible we are not disagreeing much, but just thinking about things differently, or focusing on different things. >> >> But I am a bit concerned that a scatter gun approach, where providers pick the pieces they like, may just result in needless differences and systems that don't work well. >> >> If we agree that it isn't feasible to get an ideal system that meets all our wishes, then perhaps we can get a general agreement on a lesser set of requirements. E.g. >> >> - its most important for the psap to be able, on explicit request, >> to achieve expedited access to an arbitrary AOR. >> (This might be a callback to an emergency call, via Contact AOR >> or From AOR, or whatever of the emergency call. It might also >> be some other AOR.) >> >> - its nearly as important that the expedited access be able to reach >> devices that have recently made an emergency call but are normally >> not permitted or able to receive calls. >> >> - its important (but less so) to minimize fraud by preventing non- >> psaps from getting the sort of expedited access mentioned above. >> >> - it may be desirable that callees not be charged for receiving these >> expedited calls. (Decisions about this are based on policy.) >> >> If we were to agree to the above, then we could start identifying mechanisms to support each. But some of them might be incomplete. >> >> For instance, to achieve the first, we come up with a mechanism to indicate this is a psap expedited call. (e.g. urn:sos in From or P-A-ID.) >> >> For the second, maybe nothing else is required in signaling if the contact address is reachable - just some policy adjustments. In other cases it might require allowing some sort of emergency registration, and then would only work as long as that registration remains in effect. >> >> Some might not bother to minimize fraud at all. Others might depend on transitive trust to prevent unauthorized parties from making the indication for a psap expedited call. Or something like ARID might be used. >> >> The disabling of fees could presumably be driven by one of the above mechanisms if desired. >> >> Thanks, >> Paul >> >>> Henning >>> >>> On Dec 3, 2011, at 12:11 PM, Paul Kyzivat wrote: >>> >>>> Why not forget about detecting and verifying that the call is a *callback* to an emergency call. Instead, simply give the psap a way to initiate a "priority" call to some URI. Then expect the elements on the path to take special action on these, such as bypassing features like VM. >>>> >>>> We can rely on policy to restrict such calls to callbacks, or comparably compelling reasons. >>>> >>>> There is still work to be done to satisfy this, but some hard things are avoided. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 12/4/11 12:40 AM, Henning Schulzrinne wrote: >>>>> We seem to have difficulty finding a single mechanism that meets all requirements (such as non-forgeability and reach-the-same UA) in all situations: >>>>> - SBCs that destroy session identity >>>>> - UAs and/or proxies that don't support GRUUs >>>>> - call route divergence (route asymmetry), where the initial outbound emergency call and the call back traverse different paths. >>>>> >>>>> Thus, maybe we need a more probabilistic approach that will work in most situations, relying on *multiple* markers and indicators. We may not achieve 100% coverage, but I suspect that the only way of doing that would be a 100% deployment of an end-to-end cryptographic mechanism that is recognized by all parties. (Since it seems close to impossible for the caller to convey an element that survives round-trip, you would probably have to identify the PSAP, not the call, since there's nothing that can be signed by the caller and be recognized by third parties.) >>>>> >>>>> I can think of a few ingredients that are plausible and "survive" under different circumstances, two of which we have been discussing before: >>>>> >>>>> (1) normal GRUUs, where the inbound proxy remembers that the outbound call was an emergency call; may fail under some route asymmetry cases and is subject to GRUU deployment issues. >>>>> >>>>> (2) In-Reply-To and Priority; does not require any GRUU or new SIP elements, but fails with call-ID mangling SBCs and does not address asymmetric call paths. >>>>> >>>>> (3) ARID (draft-ono-dispatch-attribute-validation), which allows entities on the call path to validate that the call originated from a PSAP, with pretty minimal infrastructure. >>>>> >>>>> (4) PSAP-signed calls (see below). >>>>> >>>>> I suspect there are others, but the basic goal seems to be that the caller, the only one knowing reliably that an emergency call was placed, needs to tell various elements responsible for inbound call handling to provide special handling for a specific call, identified by some element that survives the trip to and from the PSAP. If there was a standard protocol that allowed a UA to request per-call features, we could leverage that, but I haven't heard of such a thing. (Just to illustrate the spirit: The caller could create a CPL rule that bypasses call treatments just after placing the emergency call, but it seems fanciful to suggest this as a general mechanism, given the additional complexity in lots of places.) >>>>> >>>>> The usual other way of proving yourself is a challenge-response mechanism, but that assumes that all the call handling elements share a secret with the caller. I can't think of a way to build such a system without a whole lot of new protocol machinery. >>>>> >>>>> I also wonder whether for the more complicated IMS scenarios, it wouldn't be easier to just rely on PSAP signed requests, given that the number of IMS operators is likely to be not that large and that they are likely to be reasonably sophisticated operators. In other words, we don't try to identify return calls, just PSAP-originated calls. >>>>> >>>>> Henning >>>>> >>>>> On Dec 3, 2011, at 11:04 AM, Paul Kyzivat wrote: >>>>> >>>>>> On 12/2/11 6:30 AM, Marc Linsner wrote: >>>>>> >>>>>>>> I'm finding this a little confusing. >>>>>>>> Are you are saying that the UA making the emergency call will get an >>>>>>>> egruu from the registrar/scscf in the visited network, but the resulting >>>>>>>> call will be processed by the scscf of the home network? >>>>>>> >>>>>>> No, it was intended the eGRUU would be minted by the home network and >>>>>>> passed to the UA upon registration. >>>>>> >>>>>> So, if the UA was registered normally, to its home scscf, then it would get the gruu from there? But the emergency call might not traverse the home scscf? But the callback, because it uses a gruu from the home scscf, will traverse that one? >>>>>> >>>>>> In such a case, the home scscf won't know that an emergency call has been made (as Hadriel mentioned). And while it could apply some expiration time to the gruu, the clock for that would start ticking when the registration that minted the gruu was done. That could be a long time ago. (I gather it is not considered desirable to force a special registration just prior to the emergency call - due to the extra time it might take and the possibility that it might fail.) >>>>>> >>>>>> OTOH, IIUC for some IMS cases its also necessary to support emergency calls from SIMless devices that don't have a normal registration. In that case I gather there will be an emergency registration, possibly to a visited network. That is probably the easier case. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > From br@brianrosen.net Mon Dec 5 09:21:12 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4ADD11E80AF for ; Mon, 5 Dec 2011 09:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 8-DgOPrjHviJ for ; Mon, 5 Dec 2011 09:21:11 -0800 (PST) Received: from barmail5.idig.net (barmail5.idig.net [64.34.111.236]) by ietfa.amsl.com (Postfix) with ESMTP id BC51411E80A2 for ; Mon, 5 Dec 2011 09:21:11 -0800 (PST) X-ASG-Debug-ID: 1323105671-0491e57a6412cd00001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail5.idig.net with ESMTP id JFlMAQgoAgxiixk2; Mon, 05 Dec 2011 09:21:11 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.33]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RXcE3-000UTh-4D; Mon, 05 Dec 2011 09:21:11 -0800 X-Barracuda-BBL-IP: 209.173.57.233 X-Barracuda-RBL-IP: 209.173.57.233 Mime-Version: 1.0 (Apple Message framework v1251.1) X-ASG-Orig-Subj: Re: [Ecrit] GRUUs for callbacks Content-Type: text/plain; charset=iso-8859-1 From: Brian Rosen In-Reply-To: <4EDCF4A4.60901@alum.mit.edu> Date: Mon, 5 Dec 2011 12:21:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EDA48A1.7040906@alum.mit.edu> <02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu> <4EDA584E.2050604@alum.mit.edu> <255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu> <4EDA74C3.9070603@alum.mit.edu> <2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net> <4EDCF4A4.60901@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1251.1) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1323105671 X-Barracuda-URL: http://64.34.111.236:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.82225 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: ecrit@ietf.org Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 17:21:12 -0000 > Is there an expectation that the psap will try a callback to the AOR = if callback to the Contact fails? ISTM that would be an expedient = strategy. If so, it would be good if the callback to the AOR also could = request priority, and to suppress features. Perhaps this could be at the = discretion of the psap caller. Yes, that's likely what would happen. It would be good to have priority = and suppress features, but it's not really required. Brian From hgs@cs.columbia.edu Mon Dec 5 11:30:35 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749E321F8C0C for ; Mon, 5 Dec 2011 11:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 MaHP7CtqxxVx for ; Mon, 5 Dec 2011 11:30:35 -0800 (PST) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by ietfa.amsl.com (Postfix) with ESMTP id CD77621F8BD5 for ; Mon, 5 Dec 2011 11:30:34 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id pB5JUSuC019352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 5 Dec 2011 14:30:28 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Henning Schulzrinne In-Reply-To: <4EDCF4A4.60901@alum.mit.edu> Date: Mon, 5 Dec 2011 14:30:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EDA48A1.7040906@alum.mit.edu> <02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu> <4EDA584E.2050604@alum.mit.edu> <255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu> <4EDA74C3.9070603@alum.mit.edu> <2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net> <4EDCF4A4.60901@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 Cc: ecrit@ietf.org Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 19:30:35 -0000 Having spent some time in lawyer land, I think we have to be a bit = careful with dismissing those concerns. A carrier might be very = reluctant to dismiss a self-proclaimed PSAP callback on "too many = already" grounds, given that guessing wrong could have serious = consequences, including liability. On the other hand, telemarketing with = fake caller ID, often from non-US sources, is becoming an increasing = issue. Each of those perps typically only calls once and then = disappears. There is some chance to catch those at the proxy, based on = aggregate statistics. There's essentially no chance to do this at the = UA. (This is similar to what's happening in spam filtering for email, = where the receiver has essentially no hope of filtering this stuff.) I do agree that having a strongly UA-verifiable callback mechanism is = extremely helpful, since it allows a bit more room for error at the = proxy. What we need is a UA-setable nonce that survives the round trip at least = for emergency calls. There are a few options: - Call-Id - already discussed - =46rom tag? - New header specific to emergency calls - GRUU Thus, given the environment we live in, I'd be really uncomfortable if = the solution does not allow for reasonably-strong validation. I'm not = worried about bad guys intercepting the original emergency call or rogue = proxies (both seem more movie plot scenarios than probable), but = anything that allows random far-away parties to fake such calls seems to = invite mischief. Given the "far away" part, relying on the threat of = prosecution is also unlikely to be a deterrent. Henning >=20 > A forgeable mark providing priority and/or bypassing call blocking on = the receiving side might be tolerable. Conceivably the provider could = only allow this some limited number of times to mitigate it. >=20 > A forgeable mark bypassing features that screen callers or otherwise = limit direct access to the callee is more problematic. Possibly this = could be handled by the emergency caller's UA itself - by remembering = that it made an emergency call recently or not. It could then reject = calls with this marking if it hasn't recently made an emergency call. = This isn't ideal, since it bothers the UA, but it avoids bothering the = user. (But it still provides a vector for a DOS attack on the UA.) From pkyzivat@alum.mit.edu Mon Dec 5 12:52:21 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757EF21F8C04 for ; Mon, 5 Dec 2011 12:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] 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 jAGitgX+k-sb for ; Mon, 5 Dec 2011 12:52:20 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id D7DFE21F8C5B for ; Mon, 5 Dec 2011 12:52:07 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta14.westchester.pa.mail.comcast.net with comcast id 5YEl1i00127AodY5EYs8d6; Mon, 05 Dec 2011 20:52:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id 5Ys81i00N07duvL3fYs87Z; Mon, 05 Dec 2011 20:52:08 +0000 Message-ID: <4EDD2EF6.8060707@alum.mit.edu> Date: Tue, 06 Dec 2011 04:52:06 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Henning Schulzrinne References: <4EDA48A1.7040906@alum.mit.edu> <02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu> <4EDA584E.2050604@alum.mit.edu> <255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu> <4EDA74C3.9070603@alum.mit.edu> <2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net> <4EDCF4A4.60901@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] GRUUs for callbacks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 20:52:21 -0000 On 12/6/11 3:30 AM, Henning Schulzrinne wrote: > Having spent some time in lawyer land, I think we have to be a bit careful with dismissing those concerns. A carrier might be very reluctant to dismiss a self-proclaimed PSAP callback on "too many already" grounds, given that guessing wrong could have serious consequences, including liability. On the other hand, telemarketing with fake caller ID, often from non-US sources, is becoming an increasing issue. Each of those perps typically only calls once and then disappears. There is some chance to catch those at the proxy, based on aggregate statistics. There's essentially no chance to do this at the UA. (This is similar to what's happening in spam filtering for email, where the receiver has essentially no hope of filtering this stuff.) > > I do agree that having a strongly UA-verifiable callback mechanism is extremely helpful, since it allows a bit more room for error at the proxy. > > What we need is a UA-setable nonce that survives the round trip at least for emergency calls. There are a few options: > - Call-Id - already discussed > - From tag? > - New header specific to emergency calls > - GRUU > > Thus, given the environment we live in, I'd be really uncomfortable if the solution does not allow for reasonably-strong validation. I'm not worried about bad guys intercepting the original emergency call or rogue proxies (both seem more movie plot scenarios than probable), but anything that allows random far-away parties to fake such calls seems to invite mischief. Given the "far away" part, relying on the threat of prosecution is also unlikely to be a deterrent. OK, I buy your reasoning here. So we need some way to convey a nonce. This could potentially be something generated and remembered by the UAC as part of the emergency call. I guess other elements on the call path could remember it if they want. The mechanism for requesting suppression of services that interfere with the call reaching the UA remains an issue. It would be nice if this could be a more general mechanism. (In general, when in a call, I might want to hand out a right to make a callback, and give a resulting callback different treatment than an unanticipated call.) But maybe that is too much to try for. Thanks, Paul > Henning > >> >> A forgeable mark providing priority and/or bypassing call blocking on the receiving side might be tolerable. Conceivably the provider could only allow this some limited number of times to mitigate it. >> >> A forgeable mark bypassing features that screen callers or otherwise limit direct access to the callee is more problematic. Possibly this could be handled by the emergency caller's UA itself - by remembering that it made an emergency call recently or not. It could then reject calls with this marking if it hasn't recently made an emergency call. This isn't ideal, since it bothers the UA, but it avoids bothering the user. (But it still provides a vector for a DOS attack on the UA.) > > From RMarshall@telecomsys.com Tue Dec 6 13:20:27 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C6B11E80A5 for ; Tue, 6 Dec 2011 13:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.74 X-Spam-Level: X-Spam-Status: No, score=-100.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, USER_IN_WHITELIST=-100] 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 4OaJUQuTYr-5 for ; Tue, 6 Dec 2011 13:20:26 -0800 (PST) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [199.165.246.12]) by ietfa.amsl.com (Postfix) with ESMTP id 036D811E809C for ; Tue, 6 Dec 2011 13:20:25 -0800 (PST) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Tue, 6 Dec 2011 13:20:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Dec 2011 13:20:23 -0800 Message-ID: <06DC18EFB186744F914DABC7D278DEE101E94D3A@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <4EDD2EF6.8060707@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF82 Taipei ECRIT Minutes have been posted Thread-Index: Acyzj86HKmRU4OLpSIKOT0GgPUXmqgAzGfrw References: <4EDA48A1.7040906@alum.mit.edu><02BBB8BF-CDD8-4F86-A17C-B4283BE15789@cs.columbia.edu><4EDA584E.2050604@alum.mit.edu><255057E7-1251-4F8D-A918-B64C844065EB@cs.columbia.edu><4EDA74C3.9070603@alum.mit.edu><2C6CF869-417F-4891-8FB4-102D3D84694E@brianrosen.net><4EDCF4A4.60901@alum.mit.edu> <4EDD2EF6.8060707@alum.mit.edu> From: "Roger Marshall" To: Subject: [Ecrit] IETF82 Taipei ECRIT Minutes have been posted X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 21:20:27 -0000 ECRIT meeting minutes for IETF82 have been posted at link: http://www.ietf.org/proceedings/82/minutes/ecrit.txt Many thanks go to Jean Mahoney, who did a great job in capturing the comments and action items from the meeting. -roger marshall. CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. From forte@att.com Mon Dec 19 13:15:11 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89DA511E8098 for ; Mon, 19 Dec 2011 13:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.74 X-Spam-Level: X-Spam-Status: No, score=-104.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 ezqbNCnxPRiT for ; Mon, 19 Dec 2011 13:15:11 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id DDD6611E8080 for ; Mon, 19 Dec 2011 13:15:10 -0800 (PST) X-Env-Sender: forte@att.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1324329308!6591006!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.4.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22003 invoked from network); 19 Dec 2011 21:15:09 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-4.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Dec 2011 21:15:09 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id pBJLFbMP031472 for ; Mon, 19 Dec 2011 16:15:37 -0500 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id pBJLFV2g031387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Dec 2011 16:15:32 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Mon, 19 Dec 2011 16:14:51 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id pBJLEpKH004119 for ; Mon, 19 Dec 2011 16:14:51 -0500 Received: from [151.109.8.213] (dn151-109-8-213.dhcpn.ugn.att.com [151.109.8.213]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id pBJLEblG003710 for ; Mon, 19 Dec 2011 16:14:49 -0500 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Mon, 19 Dec 2011 16:16:14 -0500 From: "Andrea G. Forte" To: "ecrit@ietf.org Org" Message-ID: Thread-Topic: Adding top-level service labels Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Subject: [Ecrit] Adding top-level service labels X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 21:15:11 -0000 Dear all, Recently, the LoST Extensions draft has been ratified as RFC 6451. This means that people can start using LoST for non-emergency services. Furthermore, Telecom Italia (the first Italian mobile carrier) has contacted us for knowing the status of the service classification draft as they were interested in working in that area. We think that times have matured enough to resume our discussion on non-emergency location-based services. However, given that this is the ECRIT working group, I wanted to bring to the group's attention the draft on service URN update policy [http://tools.ietf.org/html/draft-forte-ecrit-service-urn-policy-00]. As a reminder, this draft would update "Section 4.1 of [RFC5031] in that the policy for adding top-level service labels is "Expert Review". The expert is designated by the RAI Area Director". Today standard action is required for this, which is a significant overkill to just add "food" or "lodging". I do not see any harm in introducing this change in policy but I would like to know the opinion of the WG. Thanks, -- Andrea G. Forte From wwwrun@rfc-editor.org Wed Dec 21 09:02:07 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD33E21F849D; Wed, 21 Dec 2011 09:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 VCyPiDDkF13q; Wed, 21 Dec 2011 09:02:07 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 404F221F849C; Wed, 21 Dec 2011 09:02:07 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 2526F72E004; Wed, 21 Dec 2011 09:00:29 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111221170031.2526F72E004@rfc-editor.org> Date: Wed, 21 Dec 2011 09:00:29 -0800 (PST) Cc: ecrit@ietf.org, rfc-editor@rfc-editor.org Subject: [Ecrit] RFC 6443 on Framework for Emergency Calling Using Internet Multimedia X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 17:02:07 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6443 Title: Framework for Emergency Calling Using Internet Multimedia Author: B. Rosen, H. Schulzrinne, J. Polk, A. Newton Status: Informational Stream: IETF Date: December 2011 Mailbox: br@brianrosen.net, hgs@cs.columbia.edu, jmpolk@cisco.com, andy@hxr.us Pages: 38 Characters: 98096 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ecrit-framework-13.txt URL: http://www.rfc-editor.org/rfc/rfc6443.txt The IETF has standardized various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From br@brianrosen.net Thu Dec 22 06:51:17 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2D121F8B2A for ; Thu, 22 Dec 2011 06:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 yPoEo+rVWeqw for ; Thu, 22 Dec 2011 06:51:16 -0800 (PST) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC7521F8B23 for ; Thu, 22 Dec 2011 06:51:16 -0800 (PST) X-ASG-Debug-ID: 1324565474-011a9f38c648810001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id ZmCzA4uHfwTMg7uo for ; Thu, 22 Dec 2011 06:51:14 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.61]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RdjzG-001Cbl-Hm for ecrit@ietf.org; Thu, 22 Dec 2011 06:51:14 -0800 From: Brian Rosen X-Barracuda-BBL-IP: 209.173.57.233 X-Barracuda-RBL-IP: 209.173.57.233 Content-Type: multipart/alternative; boundary="Apple-Mail=_95169FBA-8692-4629-A8CE-533B0DDB22EA" Date: Thu, 22 Dec 2011 09:51:10 -0500 X-ASG-Orig-Subj: Fwd: RFC 6443 on Framework for Emergency Calling Using Internet Multimedia References: <20111221170031.2526F72E004@rfc-editor.org> To: "ecrit@ietf.org Org" Message-Id: Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1324565474 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.34 X-Barracuda-Spam-Status: No, SCORE=0.34 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332, HTML_MESSAGE, SH_BIG5_05413_BODY_104 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.83798 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 0.21 SH_BIG5_05413_BODY_104 BODY: Body: contain "UNSUBSCRIBE" 0.00 HTML_MESSAGE BODY: HTML included in message Subject: [Ecrit] Fwd: RFC 6443 on Framework for Emergency Calling Using Internet Multimedia X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 14:51:17 -0000 --Apple-Mail=_95169FBA-8692-4629-A8CE-533B0DDB22EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tada! Begin forwarded message: > From: rfc-editor@rfc-editor.org > Subject: RFC 6443 on Framework for Emergency Calling Using Internet = Multimedia > Date: December 21, 2011 12:00:29 PM EST > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > Cc: ecrit@ietf.org, rfc-editor@rfc-editor.org >=20 >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 6443 >=20 > Title: Framework for Emergency Calling Using=20 > Internet Multimedia=20 > Author: B. Rosen, H. Schulzrinne, > J. Polk, A. Newton > Status: Informational > Stream: IETF > Date: December 2011 > Mailbox: br@brianrosen.net,=20 > hgs@cs.columbia.edu,=20 > jmpolk@cisco.com, andy@hxr.us > Pages: 38 > Characters: 98096 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-ecrit-framework-13.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc6443.txt >=20 > The IETF has standardized various aspects of placing emergency calls. > This document describes how all of those component parts are used to > support emergency calls from citizens and visitors to authorities. > This document is not an Internet Standards Track specification; it is > published for informational purposes. >=20 > This document is a product of the Emergency Context Resolution with = Internet Technologies Working Group of the IETF. >=20 >=20 > INFORMATIONAL: This memo provides information for the Internet = community. > It does not specify an Internet standard of any kind. Distribution of > this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see = http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --Apple-Mail=_95169FBA-8692-4629-A8CE-533B0DDB22EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Subject: RFC 6443 on Framework for Emergency Calling Using = Internet Multimedia
Date: December 21, 2011 12:00:29 PM = EST


A new Request for Comments is now available = in online RFC libraries.


=        RFC 6443

=        Title: =      Framework for Emergency Calling Using
=             &n= bsp;      Internet Multimedia
=        Author: =     B. Rosen, H. Schulzrinne,
=             &n= bsp;      J. Polk, A. Newton
=        Status: =     Informational
=        Stream: =     IETF
=        Date: =       December 2011
=        Mailbox:    br@brianrosen.net,
=             &n= bsp;      hgs@cs.columbia.edu,
=             &n= bsp;      jmpolk@cisco.com,  andy@hxr.us
=        Pages: =      38
=        Characters: 98096
=        Updates/Obsoletes/SeeAlso: =   None

       I-D = Tag:    draft-ietf-ecrit-framework-13.txt

=        URL: =        http://www.rfc-editor.o= rg/rfc/rfc6443.txt

The IETF has standardized various aspects = of placing emergency calls.
This document describes how all of those = component parts are used to
support emergency calls from citizens and = visitors to authorities.
This document is not an Internet Standards = Track specification; it is
published for informational = purposes.

This document is a product of the Emergency Context = Resolution with Internet Technologies Working Group of the = IETF.


INFORMATIONAL: This memo provides information for the = Internet community.
It does not specify an Internet standard of any = kind. Distribution of
this memo is unlimited.

This = announcement is sent to the IETF-Announce and rfc-dist lists.
To = subscribe or unsubscribe, see
 http://www.iet= f.org/mailman/listinfo/ietf-announce
 http://ma= ilman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching = the RFC series, see http://www.rfc-editor.or= g/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.= html.

Requests for special distribution should be addressed = to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org. =  Unless
specifically noted otherwise on the RFC itself, all RFCs = are for
unlimited distribution.


The RFC Editor = Team
Association Management Solutions, = LLC


_______________________________________________
IETF-Ann= ounce mailing list
IETF-Announce@ietf.org
https= ://www.ietf.org/mailman/listinfo/ietf-announce

= --Apple-Mail=_95169FBA-8692-4629-A8CE-533B0DDB22EA-- From rbarnes@bbn.com Thu Dec 22 08:15:39 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAFC21F8B06 for ; Thu, 22 Dec 2011 08:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Y2X7SMSuBxe3 for ; Thu, 22 Dec 2011 08:15:38 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 44EB321F853E for ; Thu, 22 Dec 2011 08:15:27 -0800 (PST) Received: from [128.89.254.29] (port=59827 helo=[192.168.2.17]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RdlIj-000Gqu-RI; Thu, 22 Dec 2011 11:15:26 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Thu, 22 Dec 2011 11:15:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <958E5009-87B2-4542-AF20-6960E3626031@bbn.com> References: <20111221170031.2526F72E004@rfc-editor.org> To: Brian Rosen X-Mailer: Apple Mail (2.1084) Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Fwd: RFC 6443 on Framework for Emergency Calling Using Internet Multimedia X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 16:15:39 -0000 /me pops champagne Thanks to everyone for all your hard work on this. --Richard On Dec 22, 2011, at 9:51 AM, Brian Rosen wrote: > Tada! >=20 > Begin forwarded message: >=20 >> From: rfc-editor@rfc-editor.org >> Subject: RFC 6443 on Framework for Emergency Calling Using Internet = Multimedia >> Date: December 21, 2011 12:00:29 PM EST >> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org >> Cc: ecrit@ietf.org, rfc-editor@rfc-editor.org >>=20 >>=20 >> A new Request for Comments is now available in online RFC libraries. >>=20 >>=20 >> RFC 6443 >>=20 >> Title: Framework for Emergency Calling Using=20 >> Internet Multimedia=20 >> Author: B. Rosen, H. Schulzrinne, >> J. Polk, A. Newton >> Status: Informational >> Stream: IETF >> Date: December 2011 >> Mailbox: br@brianrosen.net,=20 >> hgs@cs.columbia.edu,=20 >> jmpolk@cisco.com, andy@hxr.us >> Pages: 38 >> Characters: 98096 >> Updates/Obsoletes/SeeAlso: None >>=20 >> I-D Tag: draft-ietf-ecrit-framework-13.txt >>=20 >> URL: http://www.rfc-editor.org/rfc/rfc6443.txt >>=20 >> The IETF has standardized various aspects of placing emergency calls. >> This document describes how all of those component parts are used to >> support emergency calls from citizens and visitors to authorities. >> This document is not an Internet Standards Track specification; it is >> published for informational purposes. >>=20 >> This document is a product of the Emergency Context Resolution with = Internet Technologies Working Group of the IETF. >>=20 >>=20 >> INFORMATIONAL: This memo provides information for the Internet = community. >> It does not specify an Internet standard of any kind. Distribution of >> this memo is unlimited. >>=20 >> This announcement is sent to the IETF-Announce and rfc-dist lists. >> To subscribe or unsubscribe, see >> http://www.ietf.org/mailman/listinfo/ietf-announce >> http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >>=20 >> For searching the RFC series, see = http://www.rfc-editor.org/rfcsearch.html. >> For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >>=20 >> Requests for special distribution should be addressed to either the >> author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless >> specifically noted otherwise on the RFC itself, all RFCs are for >> unlimited distribution. >>=20 >>=20 >> The RFC Editor Team >> Association Management Solutions, LLC >>=20 >>=20 >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From mlinsner@cisco.com Thu Dec 22 08:27:18 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2E021F850E for ; Thu, 22 Dec 2011 08:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 ETGl5KYQ4ytZ for ; Thu, 22 Dec 2011 08:27:18 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E1A7B21F8507 for ; Thu, 22 Dec 2011 08:27:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=3548; q=dns/txt; s=iport; t=1324571238; x=1325780838; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=Yq9lHhnSMbwTVxptYt27/+89Km/jJ4j/kMAZj7PZSVY=; b=bc7plUqV21nGMDCOaV0f/JE6P2Vor3Tb11T35v+uSXwNGaTBG2KBvRhw 6I2klkG4S8HmsPgsThs8Z2ze2Fx9OjOUAEQV5p36p686zU7xRyFoTsUzL 06UBKHZ+sxsSq6cJI4L1VO+3EI39AyzrffIXyG8dXo7x92dlFju2rcHZg A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAVa806tJV2c/2dsb2JhbABDrC2BBYFyAQEBBAEBAQ8BJwIBESAXBwgRAwECAQxJCh4IBhMJCwcCBAGHYJdsgSYBnjSMDwSIN4xKhU+NAQ X-IronPort-AV: E=Sophos;i="4.71,393,1320624000"; d="scan'208";a="46217360" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 22 Dec 2011 16:27:17 +0000 Received: from [10.82.244.221] (rtp-vpn2-1245.cisco.com [10.82.244.221]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id pBMGRFam004738 for ; Thu, 22 Dec 2011 16:27:16 GMT User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 22 Dec 2011 11:27:13 -0500 From: Marc Linsner To: "ecrit@ietf.org Org" Message-ID: Thread-Topic: [Ecrit] Fwd: RFC 6443 on Framework for Emergency Calling Using Internet Multimedia In-Reply-To: <958E5009-87B2-4542-AF20-6960E3626031@bbn.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Ecrit] Fwd: RFC 6443 on Framework for Emergency Calling Using Internet Multimedia X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 16:27:18 -0000 +1 Especially Brian! After all, he has only aged 50 years in the last 5 !!! -Marc- -----Original Message----- From: "Richard L. Barnes" Date: Thu, 22 Dec 2011 11:15:17 -0500 To: Brian Rosen Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Fwd: RFC 6443 on Framework for Emergency Calling Using Internet Multimedia >/me pops champagne > >Thanks to everyone for all your hard work on this. > >--Richard > > >On Dec 22, 2011, at 9:51 AM, Brian Rosen wrote: > >> Tada! >> >> Begin forwarded message: >> >>> From: rfc-editor@rfc-editor.org >>> Subject: RFC 6443 on Framework for Emergency Calling Using Internet >>>Multimedia >>> Date: December 21, 2011 12:00:29 PM EST >>> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org >>> Cc: ecrit@ietf.org, rfc-editor@rfc-editor.org >>> >>> >>> A new Request for Comments is now available in online RFC libraries. >>> >>> >>> RFC 6443 >>> >>> Title: Framework for Emergency Calling Using >>> Internet Multimedia >>> Author: B. Rosen, H. Schulzrinne, >>> J. Polk, A. Newton >>> Status: Informational >>> Stream: IETF >>> Date: December 2011 >>> Mailbox: br@brianrosen.net, >>> hgs@cs.columbia.edu, >>> jmpolk@cisco.com, andy@hxr.us >>> Pages: 38 >>> Characters: 98096 >>> Updates/Obsoletes/SeeAlso: None >>> >>> I-D Tag: draft-ietf-ecrit-framework-13.txt >>> >>> URL: http://www.rfc-editor.org/rfc/rfc6443.txt >>> >>> The IETF has standardized various aspects of placing emergency calls. >>> This document describes how all of those component parts are used to >>> support emergency calls from citizens and visitors to authorities. >>> This document is not an Internet Standards Track specification; it is >>> published for informational purposes. >>> >>> This document is a product of the Emergency Context Resolution with >>>Internet Technologies Working Group of the IETF. >>> >>> >>> INFORMATIONAL: This memo provides information for the Internet >>>community. >>> It does not specify an Internet standard of any kind. Distribution of >>> this memo is unlimited. >>> >>> This announcement is sent to the IETF-Announce and rfc-dist lists. >>> To subscribe or unsubscribe, see >>> http://www.ietf.org/mailman/listinfo/ietf-announce >>> http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >>> >>> For searching the RFC series, see >>>http://www.rfc-editor.org/rfcsearch.html. >>> For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >>> >>> Requests for special distribution should be addressed to either the >>> author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless >>> specifically noted otherwise on the RFC itself, all RFCs are for >>> unlimited distribution. >>> >>> >>> The RFC Editor Team >>> Association Management Solutions, LLC >>> >>> >>> _______________________________________________ >>> IETF-Announce mailing list >>> IETF-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-announce >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@nsn.com Thu Dec 22 09:44:36 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACA921F8A55 for ; Thu, 22 Dec 2011 09:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.382 X-Spam-Level: X-Spam-Status: No, score=-106.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 MWzF2QMqsM4X for ; Thu, 22 Dec 2011 09:44:35 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id C946C21F85A4 for ; Thu, 22 Dec 2011 09:44:34 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pBMHiSFr008300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Dec 2011 18:44:28 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pBMHiSKf018166; Thu, 22 Dec 2011 18:44:28 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Dec 2011 18:44:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Dec 2011 19:46:22 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DE7CC57@FIESEXC035.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Fwd: RFC 6443 on Framework for Emergency Calling Using Internet Multimedia Thread-Index: AczAxpcP+y4Q6jpORw61IRO8RH3MCgAClPPA References: <958E5009-87B2-4542-AF20-6960E3626031@bbn.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Marc Linsner" , X-OriginalArrivalTime: 22 Dec 2011 17:44:28.0335 (UTC) FILETIME=[5A5883F0:01CCC0D1] Subject: Re: [Ecrit] Fwd: RFC 6443 on Framework for Emergency Calling Using Internet Multimedia X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 17:44:36 -0000 A lot of good news in time for Christmas: SIP Location Conveyance, Henning's appointment and now the publication of this document.=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of ext Marc Linsner > Sent: Thursday, December 22, 2011 6:27 PM > To: ecrit@ietf.org Org > Subject: Re: [Ecrit] Fwd: RFC 6443 on Framework for Emergency Calling > Using Internet Multimedia >=20 > +1 >=20 > Especially Brian! >=20 > After all, he has only aged 50 years in the last 5 !!! >=20 > -Marc- >=20 > -----Original Message----- > From: "Richard L. Barnes" > Date: Thu, 22 Dec 2011 11:15:17 -0500 > To: Brian Rosen > Cc: "ecrit@ietf.org Org" > Subject: Re: [Ecrit] Fwd: RFC 6443 on Framework for Emergency Calling > Using Internet Multimedia >=20 > >/me pops champagne > > > >Thanks to everyone for all your hard work on this. > > > >--Richard > > > > > >On Dec 22, 2011, at 9:51 AM, Brian Rosen wrote: > > > >> Tada! > >> > >> Begin forwarded message: > >> > >>> From: rfc-editor@rfc-editor.org > >>> Subject: RFC 6443 on Framework for Emergency Calling Using Internet > >>>Multimedia > >>> Date: December 21, 2011 12:00:29 PM EST > >>> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > >>> Cc: ecrit@ietf.org, rfc-editor@rfc-editor.org > >>> > >>> > >>> A new Request for Comments is now available in online RFC libraries. > >>> > >>> > >>> RFC 6443 > >>> > >>> Title: Framework for Emergency Calling Using > >>> Internet Multimedia > >>> Author: B. Rosen, H. Schulzrinne, > >>> J. Polk, A. Newton > >>> Status: Informational > >>> Stream: IETF > >>> Date: December 2011 > >>> Mailbox: br@brianrosen.net, > >>> hgs@cs.columbia.edu, > >>> jmpolk@cisco.com, andy@hxr.us > >>> Pages: 38 > >>> Characters: 98096 > >>> Updates/Obsoletes/SeeAlso: None > >>> > >>> I-D Tag: draft-ietf-ecrit-framework-13.txt > >>> > >>> URL: http://www.rfc-editor.org/rfc/rfc6443.txt > >>> > >>> The IETF has standardized various aspects of placing emergency > calls. > >>> This document describes how all of those component parts are used > to > >>> support emergency calls from citizens and visitors to authorities. > >>> This document is not an Internet Standards Track specification; it > is > >>> published for informational purposes. > >>> > >>> This document is a product of the Emergency Context Resolution with > >>>Internet Technologies Working Group of the IETF. > >>> > >>> > >>> INFORMATIONAL: This memo provides information for the Internet > >>>community. > >>> It does not specify an Internet standard of any kind. Distribution > of > >>> this memo is unlimited. > >>> > >>> This announcement is sent to the IETF-Announce and rfc-dist lists. > >>> To subscribe or unsubscribe, see > >>> http://www.ietf.org/mailman/listinfo/ietf-announce > >>> http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > >>> > >>> For searching the RFC series, see > >>>http://www.rfc-editor.org/rfcsearch.html. > >>> For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > >>> > >>> Requests for special distribution should be addressed to either the > >>> author of the RFC in question, or to rfc-editor@rfc-editor.org. > Unless > >>> specifically noted otherwise on the RFC itself, all RFCs are for > >>> unlimited distribution. > >>> > >>> > >>> The RFC Editor Team > >>> Association Management Solutions, LLC > >>> > >>> > >>> _______________________________________________ > >>> IETF-Announce mailing list > >>> IETF-Announce@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ietf-announce > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From rbarnes@bbn.com Fri Dec 30 14:22:22 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508D821F84D5 for ; Fri, 30 Dec 2011 14:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 RUVl4DzSD2Ar for ; Fri, 30 Dec 2011 14:22:21 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D379521F84C9 for ; Fri, 30 Dec 2011 14:22:20 -0800 (PST) Received: from [128.89.254.178] (port=52592 helo=[192.168.1.3]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RgkqC-000C3V-F2 for ecrit@ietf.org; Fri, 30 Dec 2011 17:22:20 -0500 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Dec 2011 17:22:20 -0500 Message-Id: To: "ecrit@ietf.org Org" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Ecrit] Using Internet services to call for help X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2011 22:22:22 -0000 The latest story of someone using an Internet service to call for help, = in this case Facebook messaging. She had to use Facebook because her = phone only had an IP connection (over WiFi) and no PSTN link. = In a fully ECRIT world, of course, she would have been able to actually = place a call/text to her local PSAP. Even without ECRIT-enabling her = device, though, Facebook would have been able to proxy her through to = 911, if only 1. The local emergency services had an IM-capable interface that they = advertised through LoST (cf. [1]), and=20 2. Facebook were able to get some idea of the victim's geolocation, = through something like an OBO request to the mobile provider or even a = generic IP-geo lookup. --Richard [1] = From martin.thomson@gmail.com Fri Dec 30 19:07:45 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64ADC21F84BD for ; Fri, 30 Dec 2011 19:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Yn5Uu8gub79U for ; Fri, 30 Dec 2011 19:07:42 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA0821F84B2 for ; Fri, 30 Dec 2011 19:07:41 -0800 (PST) Received: by eaak10 with SMTP id k10so8177471eaa.31 for ; Fri, 30 Dec 2011 19:07:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2RBJH+OoLacDyH9DIE+kiovkKjZNdiSyBBU17eBlkS4=; b=JKF64cOrj0HEZHBi9fivxxv7ima7SNpDfyDRZMHzQo7s4apRr2NfN36xDNITdk/ybG YV6bMxC5DDP8zYYu6UuZrjSOUD7VIwKMUTeQlGf3OiEY0/mKUYHQP38ccKhEAQqmNJma ZJ/0YhKDlqIk2tVGrX4bngwbax903pCRUyVhw= MIME-Version: 1.0 Received: by 10.204.153.12 with SMTP id i12mr9835358bkw.134.1325300860288; Fri, 30 Dec 2011 19:07:40 -0800 (PST) Received: by 10.204.186.80 with HTTP; Fri, 30 Dec 2011 19:07:40 -0800 (PST) In-Reply-To: References: Date: Sat, 31 Dec 2011 16:07:40 +1300 Message-ID: From: Martin Thomson To: "Richard L. Barnes" Content-Type: text/plain; charset=UTF-8 Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Using Internet services to call for help X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 03:07:45 -0000 Or, for 2. Facebook were able to get some idea of her location because she was able to tell Facebook. Don't assume that Facebook is (or should be) able to unilaterally able to acquire a person's location. Besides, her phone should have any number of ways of working out where it is, plus a straightforward API for sharing it with sites that have permission. On 31/12/2011, Richard L. Barnes wrote: > The latest story of someone using an Internet service to call for help, in > this case Facebook messaging. She had to use Facebook because her phone > only had an IP connection (over WiFi) and no PSTN link. > > > In a fully ECRIT world, of course, she would have been able to actually > place a call/text to her local PSAP. Even without ECRIT-enabling her > device, though, Facebook would have been able to proxy her through to 911, > if only > 1. The local emergency services had an IM-capable interface that they > advertised through LoST (cf. [1]), and > 2. Facebook were able to get some idea of the victim's geolocation, through > something like an OBO request to the mobile provider or even a generic > IP-geo lookup. > > --Richard > > > [1] > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >