Subject: RE: [Sipping] Comments on sos draft -03 (URI)

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 7 Jan 2003 13:15:57 -0500

I don't think this works.  Not all dialing plans are the same,
and even if all 3G phones have the same dialing plans, that
won't be the same as, say, an enterprise telephony system.

In most US enterprises, and for that matter, in most US college
campuses, the emergency number is 9-911.  911 would not connect
(the 9 would be interpreted as "outside line", and the 11 would
probably be interpreted as an illegal number).  In a "greenfield"
all-VoIP system, this could be changed, but in general, it can't.
A great many enterprise systems have 3 digit extensions where 1
is a legal first digit. 

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, January 07, 2003 12:25 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Sipping] Comments on sos draft -03 (URI)
> 
> 
> > [MAP] This is the fundamental problem. If a number means 
> something else 
> > someplace else, then it can't be coded into the phone and setup to 
> > automatically initiate a call to emergency if dialed. This 
> also applies if 
> > the number means nothing somewhere else. For example, if 
> 118 means emergency 
> > somewhere, but is unused in the US, then if I dial 118 on 
> my SIP phone when 
> > I'm in the US, it can't be allowed to initiate a call to 
> emergency. People 
> > can get fined for false calls to emergency, but you can't 
> very easily fault 
> > someone if it was the design of their phone that did it 
> when they dialed a 
> > non-existant digit string.
> 
> I guess you'll have to argue this with 3GPP, since they 
> preload a set of 
> numbers into the phone.
> 
> There are basically two kinds of errors:
> 
> (1) The user dials a three-digit number reasonably expecting 
> it to reach 
> emergency and it reaches, say, repair service or nobody. Bad, with 
> potentially life-threatening consequences.
> 
> (2) The user dials a three-digit number, believing it reaches some 
> service like repair or directory assistance, and gets 
> connected to the 
> police department. Unless the caller insists on getting 
> grandma's phone 
> number, this is mostly a nuisance. (I don't think 
> accidentally dialing 
> 911 is a crime, since this occurs quite commonly with cell 
> phones that 
> have one-button emergency calls. Reporting a non-existing 
> emergency is, 
> obviously, punishable.) This becomes a problem if this number 
> is widely 
> advertised. If the device recognizes the three-digit number 
> combination, 
> it can easily pop up a dialog that says "you're dialing an emergency 
> number, please confirm". (This, btw, argues for translating 
> all of these 
> into sos URIs, since there's otherwise no way for the user to dial 
> tel:118 for directory assistance since the proxy will *always* assume 
> its an emergency number.)
> 
> My interpretation of the 3GPP list is that none of the 
> numbers, with the 
> exception of 118 and 119, are used for anything else of 
> importance, so 
> that (2) is not likely to be common. This is not terribly satisfying, 
> but pragmatic, given case (1).
> 
> 
> > 
> > As Henning wrote on 12/21: "Are you arguing that 112 does 
> *not* work on GSM 
> > phones in 
> > the US? (I don't know; I don't want to try on mine...)"
> > 
> > I believe that this rules out any numbers being 
> automatically recognized by a 
> > phone device, unless that device has specific knowledge 
> about the local 
> > dialing plan. So, until the issue of how a phone knows the 
> local dial plan is 
> > solved/answered, I suggest that all discussion of storing 
> emergency (or 
> > other) numbers in the phone be dropped.
> 
> Again, something you should take up with 3GPP first.
> 
> > The first "tel:sos" says it is not a valid tel URI and it 
> only works if every 
> > outbound proxy knows what to do with it. Can't this form be 
> included in the 
> > definition of tel:url?
> 
> It could, but the other problem remains. Plus, conceptually, I'm 
> reluctant to classify emergency calls as a tel(ephone) 
> service. If we go 
> down this route of what is essentially a URN, I think it's cleaner to 
> define a new URN scheme that identifies generic communication 
> services, 
> similar to the ISBN schemes and organizations, as in
> 
> URN:service:sos
> 
> We had a related discussion in the IPTEL working group, since this is 
> one of the major open issues remaining for the tel URI. 
> Defining the URN 
> is easy, defining the resolution is hard, particulary if you want to 
> allow things like
> 
> URN:service:pizza
> 
> or even
> 
> URN:service:phone-directory
> 
> where multiple providers want to be reached via that URN. I 
> don't think 
> NAPTR works for this, for example. You effectively recreate the 
> 'mnemonic name' problem, see RFC 2972, 3367 and 3368 for one such 
> service. Indeed, you could use
> 
> go:sos
> 
> today, except that CNRP seems to have been one of those 
> 2000-era ideas 
> that floundered. (http://www.realnames.com is no more...)
> 
> > 
> > The draft says that a URI parameter won't work since it "requires 
> > mechanism-aware user agents", but everything we've been 
> discussing seems to 
> > be based on a premise that the user agent is 
> "mechanism-aware" (has a special 
> > button or recognizes "emergency" numbers).
> 
> Not really. I can take a SIP phone and dial 911 or any of the other 
> numbers and that would work (assuming it gets translated to a 
> tel URI) 
> or dial sos@mydomain and this will work, without any UA modification. 
> Clearly, some proxy has to recognize these identifiers, but 
> UAs do not. 
> (Actually, even that's not true for the common case where the 
> gateway is 
> in the same country. Dialing tel:911 today may work, even 
> though you may 
> be talking to a police department that's in a different part of the 
> country.)
> 
> > 
> > Special domain: Same as tel:uri.
> > 
> > Further, the statement in support of not using the tel:sos 
> scheme also says 
> > that the "SIP URI proposed here only requires a user's home 
> domain to be 
> > appropriately configured". This is a major disadvantage 
> with this scheme, 
> > which I suppose has been the subject of some past 
> discussions. There is a 
> > fundamental problem with this approach. The user's home 
> domain is not subject 
> > to any of the regulations that apply to the local area 
> regarding the support 
> > of emergency telephone service. It couldn't even be 
> required to support it. 
> 
> I don't know what you mean by 'local area'. I don't see how I can 
> require Starbucks to support a PSTN gateway in each of its 
> 802.11 hot spots.
> 
> > Depending on the user's home domain to know how to handle 
> emergency calls for 
> > the area that the user is in (if the home domain even knows 
> where they are) 
> > is very problematic. It presumes that the home domain not 
> only understands 
> > the "sos.", but knows how to call the emergency service 
> local to the user. I 
> > can't imagine for a monent that any local regulatory body 
> (which, in the end, 
> > controls how emergency services are reached) would accept a 
> scheme that 
> > depends on some distant equipment, which it does not 
> control through 
> > regulations, to be the critical point in providing 
> emergency service.
> 
> Are you mandating that every LAN, every 802.11 hotspot, every IETF 
> wireless LAN has to have:
> - an outbound SIP proxy server, and
> - a PSTN gateway that can dial 911
> ?
> 
> Good luck. I'm trying to build a system that will work well 
> once this is 
> true and will work ok (and be testable) until this is true.
> 
> 
> > 
> > The solution to the above is to state that the outbound 
> proxy must recognize 
> > and take action on all emergency calls, whether dialed with 
> 911, 118, etc. or 
> 
> The draft already says that. The problem is that there may be no 
> outbound proxy in every LAN or local geographic area. After 
> all, this is 
> not a mandatory piece of equipment and not every network will be 
> SIP-aware. I want to be able to use SIP phones without local support. 
> Once we have outbound proxies everywhere, things will work 
> better (and 
> exactly as well as your proposal).
> 
> > by the use of a special button on the phone which sends a 
> special URI. The 
> > URI can be some new form defined within the context of the 
> tel:url, since it 
> > is intended as a direct replacement for a telephone number, 
> or some other 
> > form. The user's home domain is never responsible to 
> handling emergency 
> > calls. Further, all calls require the use of an outbound 
> proxy. (The 
> > alternative is for the phone itself to be able to perform 
> the functions of 
> > the outbound proxy, which requires, among other things, 
> that it know the 
> > entire local dialing plan. It could know this through 
> configuration or 
> > download of parameters when it is turned on.)
> > 
> > (See, I said it was controversial!)
> 
> 
> > 
> > Mike Pierce
> > Artel
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 07 Jan 2003 13:47:52 -0500

This is another argument for having the end system convert locally 
recognized digit strings into 'sos'.

My

> campuses, the emergency number is 9-911.  911 would not connect

I think there are attempts to change this; see 
http://emergency.lib.uci.edu/ or 
http://www.news.cornell.edu/Chronicle/97/7.24.97/911.html or 
http://www.med.umich.edu/medschool/faculty/handbook/phones.html
for some quick Google research.

I doubt that anybody sane will assign somebody extension 911.

> A great many enterprise systems have 3 digit extensions where 1

There are probably two pragmatic approaches:

- Network-based: Don't assign 000, 08, 112, 110, 118, 119, 911 and 999 
as regular numbers. 0-00 would seem to be difficult since that's the 
common way that you'd dial an international number from a European PBX 
phone. However, it should never appear as anything but the initial part 
of an overlap dialing string, which wouldn't be in a tel: URI to begin with.

One can argue how difficult it would be to vacate the other half dozen 
numbers.

- UA-based: The UA recognizes these numbers and then asks whether you 
want extension 112 or emergency. 
(http://www.citrus.usda.gov/Staff2001.htm has them all :-)) If it's the 
extension, the normal tel:112;phone-context mechanism tells the proxy 
that it shouldn't call the fire department.

Needless to say, neither approach is particularly satisfactory. Since 
the outbound proxy is the one mangling extension 112 into an emergency 
call, it might be nice to able to ask it. Generalized, having a 
mechanism where you can ask a proxy what it would do with a tel URI 
would be nice. OPTIONS with Max-Forward plus one of the tracing 
mechanism discussed (Jiri's draft, say) here may come close, but seems 
rather complicated.

Clearly, this could be part of the SIP device configuration, but that 
wouldn't help for a visiting device that gets its configuration from home.

Henning