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

From: "Elwell, John" <[email-masked]>
Date: Fri, 8 Apr 2011 09:50:25 +0200

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:[email-masked]" is used in practice, and therefore for an emergency call it would be, for example, "SIP:[email-masked]".

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

---

From: Brian Rosen <[email-masked]>
Date: Fri, 8 Apr 2011 09:29:20 -0400

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:

> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 8 Apr 2011 16:04:56 +0200

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:[email-masked]] 
> Sent: 08 April 2011 14:29
> To: Elwell, John
> Cc: [email-masked]
> 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
> > 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:[email-masked]" 
> is used in practice, and therefore for an emergency call it 
> would be, for example, "SIP:[email-masked]".
> > 
> > "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

---

From: Brian Rosen <[email-masked]>
Date: Fri, 8 Apr 2011 10:32:29 -0400

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

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 8 Apr 2011 16:50:30 +0200

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

> Sent: 08 April 2011 15:32
> To: Elwell, John
> Cc: [email-masked]
> 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.
> 
> 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
> 
> > 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.
> > 
> > 1) Devices that comply with phonebcp, recognise an 
> emergency dial string and convert to a service URN.
> > 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
> >

---

From: Brian Rosen <[email-masked]>
Date: Fri, 8 Apr 2011 11:00:51 -0400

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 8 Apr 2011 11:09:39 -0400

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 [email-masked], 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

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 8 Apr 2011 17:16:55 +0200

> From: Richard L. Barnes [mailto:[email-masked]] 
> Sent: 08 April 2011 16:10
> To: Brian Rosen
> Cc: Elwell, John; [email-masked]
> 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 [email-masked], 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.  
> 
> -- If an endpoint supports emergency dialstring recognition, 
> then it MUST replace things with service URN as described in 
> this document
[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.

John

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 8 Apr 2011 11:26:04 -0400

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

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

--Richard

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 8 Apr 2011 17:30:02 +0200

Referring to what Richard says and my response to that, I think the case you are concerned about is a corner case that we don't need to deal with.

John 

> Sent: 08 April 2011 16:01
> To: Elwell, John
> Cc: [email-masked]
> > 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