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

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

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.

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