Re: [Ecrit] Comment on latest changes to phone bcp - dial strings

["Elwell, John" <[e-mail]>]

 

> -----Original Message-----
> From: Richard L. Barnes [mailto:[e-mail]] 
> Sent: 08 April 2011 16:10
> To: Brian Rosen
> Cc: Elwell, John; [e-mail]
> Subject: Re: [Ecrit] Comment on latest changes to phone bcp - 
> dial strings
> 
> I think the point is that since we're talking about the 
> *difference* between a normal phone and an ECRIT-enabled 
> phone, we don't need to solve the dial-string interop problem.
> 
> If you assume the phone can already dial numbers, then the 
> phone and the proxy already have some convention that they've 
> agreed upon for sending dialed digits.  Maybe its tel:12345, 
> maybe it's [e-mail], maybe it's 4967.  If it's not 
> upgraded to give some special treatment to specific dial 
> strings, A non-upgraded phone is going to send dialed digits 
> in whatever convention it's configured with, and it's the 
> proxy's job to do the recognition and routing.  
> 
> So it seems like what the document should be saying is:
> -- If an endpoint supports emergency dialstring recognition, 
> then it MUST replace things with service URN as described in 
> this document
> -- Otherwise, it sends the dialed digits like any other dialed digits.
> ... which I think is what John was suggesting.
[JRE] Yes, that is basically what I was suggesting. So a phonebcp-compliant device will normally send a URN and a non-compliant device will continue to work as at present. This just leaves the case where a phonebcp-compliant device fails to recognise an emergency dial string, because it wasn't configured and it wasn't obtained from LoST. In that case I think it makes sense just to let it behave as a non-compliant device.

John


> 
> --Richard
> 
> 
> On Apr 8, 2011, at 11:00 AM, Brian Rosen wrote:
> 
> > How do you propose to fix the problem with not having a 
> standardized behavior for coding dial strings that is going 
> to be interoperable?
> > 
> > An existing proxy that doesn't handle 4967 wouldn't support 
> phonebcp today.  If it was upgraded, it would be upgraded to 
> support 4967.  I'd expect it would also handle other ways, 
> for backwards compatibility if nothing else.  If the upgraded 
> proxy can handle emergency calls from existing devices, 
> great, but I don't see how to mandate that.
> > 
> > If the device was upgraded, it should support 4967.
> > 
> > Brian
> > 
> > On Apr 8, 2011, at 10:50 AM, Elwell, John wrote:
> > 
> >> Brian,
> >> 
> >> I am concerned about a device that works today by 
> embedding a dial string in a SIP or TEL URI in some way, but 
> not in accordance with RFC 4967. I would wager that devices 
> supporting RFC 4967 are in a minority.
> >> 
> >> Many such devices work today with dial strings for 
> non-emergency calls, and in  most cases for emergency calls 
> too (not using NG911). So I could dial 112 from many devices 
> attached to networks in Europe and somehow an emergency call 
> would be made. If I upgrade one of those devices to start 
> encoding dial strings using RFC 4967, would they still work? 
> Would they still be able to make non-emergency calls? Would 
> they still be able to make emergency calls? My concern is 
> that by mandating this we would break what works today.
> >> 
> >> John
> >> 
> >> 
> >>> -----Original Message-----
> >>> From: Brian Rosen [mailto:[e-mail]] 
> >>> Sent: 08 April 2011 15:32
> >>> To: Elwell, John
> >>> Cc: [e-mail]
> >>> Subject: Re: [Ecrit] Comment on latest changes to phone bcp - 
> >>> dial strings
> >>> 
> >>> phonebcp can't really deal in any sensible way with type 3, 
> >>> because there isn't any way to write "do the right thing" in 
> >>> the text, and the range of what "the right thing" could 
> be is large.
> >>> 
> >>> What it deals with is type 2 (and of course, type 1).
> >>> 
> >>> It says that devices don't have to handle dial string 
> >>> interpretation, but if they don't, they must code dial 
> >>> strings as 4967 says in order that all proxies can recognize 
> >>> emergency calls and do correct processing.  
> >>> 
> >>> If we don't mandate specific behavior for conforming devices, 
> >>> we condemn any device that doesn't do full emergency 
> >>> processing to be subject to "do the right thing" at the proxy.
> >>> 
> >>> We've tried to avoid saying things in the text that basically 
> >>> amounts to: proxies and their associated registrars must 
> >>> refuse service to devices that don't allow the proxy to meet 
> >>> it's obligations to do the right thing for emergency calls.  
> >>> Of course there is no way to write such requirements, and 
> >>> mostly, there is no way to even discover what the registrar 
> >>> would need to know to make a decision.
> >>> 
> >>> Brian
> >>> 
> >>> On Apr 8, 2011, at 10:04 AM, Elwell, John wrote:
> >>> 
> >>>> Brian,
> >>>> 
> >>>> The problem with the text in the draft at present is it 
> >>> modifies behaviour for non-emergency calls, and I don't think 
> >>> that is acceptable.
> >>>> 
> >>>> I can imagine 3 types of devices:
> >>>> 1) Devices that comply with phonebcp, recognise an 
> >>> emergency dial string and convert to a service URN.
> >>>> 2) Devices that comply with phonebcp but do not recognise 
> >>> certain emergency dial strings.
> >>>> 3) Devices that do not comply with phonebcp.
> >>>> 
> >>>> To support type 3 devices, there will have to be some form 
> >>> of agreement between the device and the proxy as to how dial 
> >>> strings are delivered to the proxy. This applies to any dial 
> >>> string, whether it is for an emergency call or something 
> >>> else. This is common practice today, and generally does not 
> >>> involve RFC 4967 Tel URIs. Many working implementations 
> >>> pre-date RFC 4967. To support type 3 devices making emergency 
> >>> calls, proxies will presumably need to recognise emergency 
> >>> dial strings when delivered by whatever means dial strings 
> >>> are delivered by those devices. 
> >>>> 
> >>>> So I don't see the sense of upgrading those proxies to also 
> >>> support RFC 4967 dial stings from type 2 devices. It would be 
> >>> better for proxies to treat type 2 and type 3 devices the same.
> >>>> 
> >>>> John
> >>>> 
> >>>>> -----Original Message-----
> >>>>> From: Brian Rosen [mailto:[e-mail]] 
> >>>>> Sent: 08 April 2011 14:29
> >>>>> To: Elwell, John
> >>>>> Cc: [e-mail]
> >>>>> Subject: Re: [Ecrit] Comment on latest changes to phone bcp - 
> >>>>> dial strings
> >>>>> 
> >>>>> The BCP can't cover devices that don't conform to it, so the 
> >>>>> fact that some existing devices don't do what it says isn't 
> >>>>> relevant.  This doesn't update 3261.  It says if you do 
> >>>>> emergency calls, do it this way.  The same applies to 
> >>>>> downstream proxies.  Standardizing behavior makes sure that 
> >>>>> regardless of the device and the proxy, the call will be 
> >>>>> recognize as an emergency call and the right processing 
> >>> done for it.
> >>>>> 
> >>>>> Emergency calls have some special processing.  I'd love to 
> >>>>> mandate that all devices conforming to it recognize dial 
> >>>>> strings, and process them into the urn.  There was objection 
> >>>>> to going that far, and thus we have this alternate path.  
> >>>>> Your text won't work as is: it would have to be followed by a 
> >>>>> new requirement on proxies to recognize anything the device 
> >>>>> could put out.
> >>>>> 
> >>>>> Brian
> >>>>> On Apr 8, 2011, at 3:50 AM, Elwell, John wrote:
> >>>>> 
> >>>>>> In 9.2:
> >>>>>> "ED-63 The initial SIP signaling method is an INVITE request:
> >>>>>> 1.   The Request URI SHOULD be the service URN in the 
> >>>>> "sos" tree.  If
> >>>>>>     the device does not interpret local dial strings, 
> >>>>> the Request-
> >>>>>>     URI MUST be a dial string URI [RFC4967] with the 
> >>>>> dialed digits."
> >>>>>> I have a concern about the "MUST" in the last sentence 
> >>>>> (previously it was SHOULD). If the device does not interpret 
> >>>>> local dial strings, it will not recognise an emergency call, 
> >>>>> and therefore cannot be expected to comply with the 
> >>>>> requirements of this BCP.
> >>>>>> 
> >>>>>> I am not aware of any RFC that updates RFC 3261 to mandate 
> >>>>> the use of RFC 4967 when sending a dial string, so therefore 
> >>>>> this statement in phone BCP is effectively changing the 
> >>>>> behaviour of RFC 3261 for all calls (not just emergency 
> >>>>> calls), which I believe should be outside the scope of the BCP.
> >>>>>> 
> >>>>>> Different practices exist today for submitting dial 
> >>>>> strings, and acceptable forms will depend on the local proxy. 
> >>>>> For example, often a URI in the form "SIP:[e-mail]" 
> >>>>> is used in practice, and therefore for an emergency call it 
> >>>>> would be, for example, "SIP:[e-mail]".
> >>>>>> 
> >>>>>> An example of acceptable text would be:
> >>>>>> "If the device does not interpret local dial strings and 
> >>>>> therefore is unable to recognise a request for an emergency 
> >>>>> call, it will behave as for any other call request for which 
> >>>>> the dial string cannot be interpreted. Normally this will 
> >>>>> involve submitting the dial string in the INVITE request in a 
> >>>>> form acceptable to the local proxy (e.g., in the form of a 
> >>>>> dial string URI [RFC4967])."
> >>>>>> 
> >>>>>> John
> >>>>>> _______________________________________________
> >>>>>> Ecrit mailing list
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/ecrit
> >>>>> 
> >>>>> 
> >>> 
> >>> 
> > 
> > _______________________________________________
> > Ecrit mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ecrit
> 
>