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

From: [email-masked]
Date: Tue, 17 Dec 2002 14:25:06 EST

In a message dated 12/13/2002 3:52:32 PM Eastern Standard Time, 
[email-masked] writes:

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

[MAP] And that's the idea in the PSTN - the millions of phones don't have to 
know the dialing plan, only the fewer fixed switches have to deal with it, 
which often happens at 2 AM. I don't know what the solution to this is in the 
Internet model, unless one accepts the concept of an "intermediate entity 
support" that Keith mentioned. No, I don't know what "appropriate processing" 
would be either, but that is what the current draft says the device should be 
"allowed" to do (based on "SOS". The point is that if there is any 
"appropriate processing" that the device does when one enters "SOS", or 
pushes a button labeled that, then it MUST do the same thing if someone dials 
911 (or whatever the local emergency number is.)

> 
> The 4th paragraph should be reworded as:
> 
> In addition, user agents and proxies MUST also recognize the appropriate 
> local emergency number, expressed as ...

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

[MAP] I agree, but then any suggestion that it do something special for 
SOS@anydomain should be removed, too.

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

[MAP] Again, we need to decide whether these are just "protocol identifiers" 
or they are intended for human readibility. If they are only protocol 
identifiers as you've said, then we could define a set (how would we know it 
was complete?) and just label them "1", "2", "3", etc. But I believe it has 
been clearly stated that the intention is for the URI to be "human readible", 
so one could expect the local langauge to be used.

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

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

[MAP] I don't have an alternative if the intention is to make it look like a 
normal address. It's partly why I'm against the idea of defining an "SOS" 
url. The alternate is to just put the number dialed into a tel:uri (e.g., 911 
for certain local areas) and let either the user agent or an "intermediate 
entity" figure out how to handle it, just as it does for any other dialed 
number. Same solution for "service numbers" and other things allowed in local 
dialing plans like #77, 311, 0, 011, etc.

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: Michael Hammer <[email-masked]>
Date: Tue, 17 Dec 2002 15:06:00 -0500

Mike,

In all cases, one must "dial" or input something.  On some phones it is 
possible to simply push a button and that translates to a dialed number.

I think the experience of the PSTN showed that having a well known service 
indicator was better than every place doing its own thing.  But, I don't 
expect that the various PSTN administrative domains will converge on either 
911 or 112.  At least in the case of the Internet, because of the early 
nature of VoIP there is at this time the possibility of converging on one 
thing.

The fact that this is a service indicator as opposed to a routable address 
means that each locality can translate that into the local address of the 
emergency number, e.g. PSAP.  I think this helps the mobile user who may 
not know the local peculiar number.

In arguing against this, you have not reduced the infrastructure workload 
one bit, but you have pushed the problem to the end-user to configure, with 
attendant Murphy's Law consequences.

Mike H.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 20 Dec 2002 23:20:29 -0500

> 911 (or whatever the local emergency number is.)

We may not be able to achieve this 100% of the time without re-creating 
the phone network. As I mention in another note, the local number is 
often easier if you are using a local gateway.

Note that it is not hard to handle the local emergency number if the 
call is routed to a local PSTN gateway. Thus, this is not as much a 
problem of configuring the local emergency number as making sure that 
emergency calls stay local. Indeed, as a first approximation, all 
three-digit calls should probably stay local. This then becomes a 
discovery problem - if I normally use my home service to route calls to 
the PSTN, how do I find the geographically local phone server?

> SOS@anydomain should be removed, too.

The whole point is that this is univeral and not object to local 
configuration. It is the only solution that has a chance of actually 
working in non-constrained environments.

> so one could expect the local langauge to be used.

I guess we should just have used ASN.1 for SIP to begin with :-) The 
whole point is that these are universal service identifiers, not 
identifying the local police department. You seem to fundamentally 
misunderstand the point of this.

> dialing plans like #77, 311, 0, 011, etc.

The idea is to have one universal address that machines can translate 
into appropriate actions. Machines have no problem doing the mapping. 
The point is that there is no intermediate entity that can usefully 
recognize all service numbers.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 20 Dec 2002 23:23:38 -0500

Mike has identified my goal precisely: using the necessary transition in 
technology to add features and services, not to slavishly repeat the 
mistakes of the past, just faster and on packets. This may not happen, 
but this doesn't suggest giving up without trying.

Michael Hammer wrote:
> I think the experience of the PSTN showed that having a well known 
> service indicator was better than every place doing its own thing.  But, 
> I don't expect that the various PSTN administrative domains will 
> converge on either 911 or 112.  At least in the case of the Internet, 
> because of the early nature of VoIP there is at this time the 
> possibility of converging on one thing.
> 
> The fact that this is a service indicator as opposed to a routable 
> address means that each locality can translate that into the local 
> address of the emergency number, e.g. PSAP.  I think this helps the 
> mobile user who may not know the local peculiar number.
> 
> In arguing against this, you have not reduced the infrastructure 
> workload one bit, but you have pushed the problem to the end-user to 
> configure, with attendant Murphy's Law consequences.