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

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

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