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

[Brian Rosen <[e-mail]>]

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