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

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

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
> >> 
> >> 
> 
>