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

["Richard L. Barnes" <[e-mail]>]

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

That sounds like a LoST provisioning failure to me, thus not a case that needs to be addressed at all.

--Richard





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