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

From: [email-masked]
Date: Tue, 7 Jan 2003 11:48:12 EST

In a message dated 1/6/2003 6:51:38 PM Eastern Standard Time, 
[email-masked] writes:

The problem 
occurs with 118 and 119, which presumably are omitted from the shorter 
list since they mean something other than emergency somewhere. 

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

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.

In a message dated 1/4/2003 1:33:09 PM Eastern Standard Time, 
[email-masked] writes:

[MAP] > The seventh paragraph states that the "sos" user name and user names 
> starting with "sos." MUST NOT be assigned to any user. Such a 
> restriction can not possibly be enforced due to possible existing 
> conflicts (as noted in Section 6). 

[HS] 
Do you have any suggestions that work better? The section 'Alternative 
Identifiers Considered' describes why I believe that none of the obvious 
alternatives is workable if you want

Yes, I have a suggestion, but I know it is highly controversial and is not 
liked, since it goes against the vision of how the Internet MUST work. I 
don't think that the draft (Section 10 in -04) makes the case that the 
alternatives listed are not workable.

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?

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

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

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 07 Jan 2003 12:25:26 -0500

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

> other) numbers in the phone be dropped.

Again, something you should take up with 3GPP first.

> outbound proxy knows what to do with it. Can't this form be included in the 

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

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

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

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Jan 2003 13:15:05 -0500

> download of parameters when it is turned on.)

Are you suggesting that it be illegal to have a portable device that 
doesn't use a local proxy? (E.g. a satelite phone, or an 802.11b based 
phone.)

These are very meaningful devices to consider. And its not clear (to me) 
if they are even subject to any regulatory requirements about local 
emergency service. If I'm wandering around Iraq with my satelite phone 
and dial the local emergency number, is my call supposed to be routed 
from the satelite to some local Iraq proxy to check for local emergency 
numbers?

Also, there are some problems with using a local proxy to provide dial 
plan and so resolve emergency services. tel:911 is not a valid tel uri - 
it must have a context, such as tel:911;phone-context=+1. However, for a 
mobile phone it is difficult to know what context to use. It might need 
to be discovered at the same time as the local proxy is selected. This 
is equivalent to requiring the phone to obtain a local dial plan.

	Paul