Subject: [Sipping] Comments on revised 'sos' draft

From: [email-masked]
Date: Fri, 13 Dec 2002 13:15:21 EST

Comments on draft-schulzrinne-sipping-sos-03 (Dec 2002) as follows:

1. Introduction

While it may be useful to have a "universal identifier", independent of 
location, to call for help, it is also mandatory for all "telephony" devices 
to support the local dialing plan, especially the local emergency numbers. 
While some statements are included regarding this need, it is not identified 
how this can be done.

Some may read this introduction as meaning that this capability may replace 
the ability to dial regular emergency telephone numbers. (Section 3 says 
"SHOULD also recognize the numbers 911 and 112" and says nothing about the 
many other emergency numbers in use around the world.) A second paragraph 
should be added to the Introduction which says something like:

This capability to support a special universal identifier does not replace 
any requirements that a user must be able to dial local emergency numbers and 
have the UA correctly handle the call, including any appropriate processing..

3. Emergency URI

The 4th paragraph states that "user agents and proxies SHOULD also recognize 
the telephone numbers 911 and 112" and "SHOULD recognize additional, local 
emergency numbers". It notes that including all [60] worldwide emergency 
numbers would interfere with existing local dialing. In fact, including 
built-in recognition of any one of these codes would certainly interfere with 
local dialing someplace. No explicit recognition of specific codes can be 
built-in to user agents in a manner which ignores the many local dialing 
plans.

(Note that this is part of a much bigger issue concerning how a SIP UA knows 
the local dialing plan. In order for this to work, there would have to be an 
administrative function that loads a UA with information concerning the local 
dialing plan, including what the local emergency numbers are.)

The 4th paragraph should be reworded as:

In addition, user agents and proxies MUST also recognize the appropriate 
local emergency number, expressed as ...

If the approach in the 6h paragraph of defining subaddresses is used (e.g., 
fire, rescue, police), it would be necessary to be able to define many other 
types, as well as to deal with language differences. Note that "SOS" itself 
was chosen due it its international recognition and not being dependent on a 
particular language. There would need to be, at a minimum, an IANA 
Considerations for assignment of other subaddresses.

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). While this restriction may be "recommended", just as it might be 
recommended that a PBX not use an extension number of 911, this can not be 
the basis for any processing on the URL in a proxy. Depending on a URL of the 
form "sos@any_domain" to call the emergency center is not sufficient. This 
could result in many unwanted calls to emergency centers.

4. Request handling

The 4th paragraph talks about "testing" by use of OPTIONS. Since the testing 
is only "recommended", there should be no reason that the random intervals be 
a "MUST".

The next paragraph states that "any proxy ... that receives such a request 
MUST forward the request to the appropriate local emergency number". Since 
this certainly does not refer to the test call in the preceding paragraph, 
this paragraph should be moved.

Mike Pierce
Artel

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 13 Dec 2002 15:52:41 -0500

Mike, thanks for your helpful comments.

> This capability to support a special universal identifier does not 
> replace any requirements that a user must be able to dial local 
> emergency numbers and have the UA correctly handle the call, including 
> any appropriate processing..

Clearly, normal numbers, including emergency numbers, should remain 
dialable as is. After all, the user probably wants to be able to dial 
"411" for directory assistance, too (see separate iptel discussion on 
that topic). Nothing in the draft prevents that, I believe.

Thus, I'm somewhat at a loss what 'appropriate processing' the UA should 
do and, more importantly, how it should know what the local emergency 
number is. I don't think manual configuration is a reasonable option. 
The whole idea of a universal identifier is to push this knowledge into 
fewer devices (proxies, gateways) that tend to stay put rather than 
billions of devices that tend to move around. Thus, I'm fundamentally 
opposed to recreating the current local configuration mess in SIP.

> 
> 3. Emergency URI
> 
> The 4th paragraph states that "user agents and proxies SHOULD also 
> recognize the telephone numbers 911 and 112" and "SHOULD recognize 
> additional, local emergency numbers". It notes that including all [60] 
> worldwide emergency numbers would interfere with existing local dialing. 
> In fact, including built-in recognition of any one of these codes would 
> certainly interfere with local dialing someplace. No explicit 
> recognition of specific codes can be built-in to user agents in a manner 
> which ignores the many local dialing plans.
> 
> (Note that this is part of a much bigger issue concerning how a SIP UA 
> knows the local dialing plan. In order for this to work, there would 
> have to be an administrative function that loads a UA with information 
> concerning the local dialing plan, including what the local emergency 
> numbers are.)

Indeed; I don't want to go there since that's the wrong solution. From 
what I've heard, 112 is built into GSM devices and works everywhere, 
even in the US. Is there any country where 911 or 112 means something 
other than emergency (or nothing)?

> local emergency number, expressed as ...

This is not a useful requirement for user agents. That's exactly what 
we're trying to get away from.

> 
> If the approach in the 6h paragraph of defining subaddresses is used 
> (e.g., fire, rescue, police), it would be necessary to be able to define 
> many other types, as well as to deal with language differences. Note 
> that "SOS" itself was chosen due it its international recognition and 
> not being dependent on a particular language. There would need to be, at 
> a minimum, an IANA Considerations for assignment of other subaddresses.

I agree that an IANA section is needed. These are protocol identifiers, 
so there is no need for 'sos.feuer' and 'sos.polizei' or 'sos.gendarme'. 
The notion is that 'sos' (without qualifier) would get you normal 
emergency service and the rest is for special situations only. All 
countries that worry about this are moving to a single emergency number. 
Thus, being memorable and universal only matters for 'sos', not the 
remainder.

> 
> 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). While this restriction may be 
> "recommended", just as it might be recommended that a PBX not use an 
> extension number of 911, this can not be the basis for any processing on 
> the URL in a proxy. Depending on a URL of the form "sos@any_domain" to 
> call the emergency center is not sufficient. This could result in many 
> unwanted calls to emergency centers.

I would appreciate alternate suggestions. Local dialing plans are not an 
option. Since losing one of billions of possible user names is not 
exactly a big deal, I don't see this as a major problem. The first time 
somebody accidentally reaches an emergency number, they'll fix that.

The one alternate solution which is being discussed in iptel would be a 
new URI for communications services, such as telsvc:sos. This has the 
advantage of avoiding name collisions, but the serious disadvantage that 
the outbound proxy needs to handle it. The current proposal has the 
advantage that I can know ahead of time whether universal emergency 
calling works, without relying on random visited networks.

Henning

_______________________________________________
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