Subject: [Sipping] Other concerns within sos ID

From: [email-masked]
Date: Wed, 11 Feb 2004 11:13:55 EST

In a message dated 2/10/2004 5:18:03 PM Eastern Standard Time, [email-masked] 
writes:

> --On Tuesday, February 10, 2004 3:55 PM -0600 "James M. Polk" 
> <[email-masked]> wrote:
> 
> > I have an concern within the new sos ID, and that concern is in section
> > 4.1 - which reserves the following additional user addresses:
> >
> >     sos.fire    fire brigade
> >     sos.rescue    ambulance (rescue)
> >     sos.marine    marine guard
> >     sos.police    police (law enforcement)
> >     sos.mountain     mountain rescue
> >
> > as I have little confidence that Joe Citizen will be generally capable to
> > choose the correct one given their emergency experience. If these
> > addresses are intended for between two ERCs (for a call transfer, for
> > example) - I don't see the text stating that here.
> >
> I thought this was just to reflect current practice in places that already 
> have different numbers for the different emergency services. Is your 
> concern that the *current* numbers are understood by joe citizen but these 
> are not? If so, the UA can just do the mapping as it has to do already for 
> 911->sos@domain.
> 

So, where in the world are different numbers used to access these different 
emergency services? Not in the US where we use English. If they are used in 
some other country, then why aren't the "reserved" user addresses in the language 
of that country? Joe Citizen may be able to choose the correct one, but I 
don't think Heinrich Staatsangehoeriger or Pierre citoyen should be expected to 
choose the correct English word. We have to stop relying on English for 
everything.

My major concern with this whole plan is the presumption that the user's 
terminal would be able to figure out to use the SOS URI as well as the sub-address 
based on the number the person dials. There are fundamental, unanswered 
questions regarding if and how the terminal would know the local dialing plan.

Further, I have a serious concern with the desciption in 4.2 that a terminal 
must recognize many different digits strings and generate an SOS, independent 
of where it is located, if it "has no knowledge of local emergency numbers". 
This would result in many invalid calls to an emergency center, since many of 
these numbers could be valid (non-emergency) numbers (see note about 118 in 
Finland). Again, this relates to the question of how the terminal knows the local 
dial plan. Unless a method can be defined so that a terminal generates an SOS 
only for the specific emergency number or numbers valid for the place it is 
physically located (or for the place that the user thinks they are in, that is, 
their virtual location), this entire scheme is faulty and can not be used. 
Section 6 covers the issue of Identifying the Local Emergency Number. There 
should be a statement that some method of doing this identification is required, 
or else the terminal can not generate an SOS based on dialed numbers. (Note the 
statement in Section 9 about being able to "clearly and unambiguously 
identity emergency calls".)

The 3rd requirement (in Section 3) is incorrect. When someone is travelling, 
and getting service in a foreign country, there is no requirement that they be 
able to dial their "familiar" home emergency identifier (presuming this 
refers to the emergency "number"). This is contradictory in many places. As noted, 
118 is directory assistance in Finland and a "familiar" emergency number 
elsewhere. This case is proof that this requirement is impossible to meet.

On the other hand, if a person is travelling and getting service from their 
proxy back at the company office, they can't expect to get any emergency 
service from that proxy.

The 4th requirement is misleading. It is not acceptable to have "restricted 
functionality" regarding access to emergency services due to user agents not 
being aware of this document. There is clearly "restricted functionality" 
concerning generation of the SOS URI, but that does not need to be stated. The final 
sentence should state: "User agents conforming to the SIP specification 
[RFC3261], but unaware of this document, must be able to place emergency calls 
without any restriction using entry of normal emergency numbers, although they 
will not generate the SOS URI."

The following requirement is missing: "It MUST be possible for a user of a 
SIP device to dial a local emergency number in the normal manner and properly 
reach the emergency service."

The statement in Section 5 that an "outbound proxy server MUST recognize all 
local emergency numbers ..." is incorrect (and impossible). (Possibly this 
sentence was meant to say " ... all local emergency numbers listed in Section 
4.2...", but this is still impossible). An outbound proxy only needs to recognize 
those emergency numbers applicable to the local areas for which it is 
providing service. An outbound proxy located in and providing service for callers in 
the US certainly does not have to recognize the emergency number used in some 
country in Africa. A visitor from that country must dial 911 for an emergency 
if they are in the US and receiving service from a service provider in the US. 
If the person from Africa is travelling in Asia and uses the proxy in the US 
for service, they can't expect it to correctly handle emergency service. The 
proxy could not possibly distinguish between the emergency numbers for Asia, 
Africa, US, and all the other local dialing plans that the user might know 
about. This is an application that must be limited to entry of E.164 numbers (which 
does not include any emergency numbers or local dialing plans).

Further, in Section 5, it is unclear how to interpret the phrase "as well as 
the tel URIs enumerated in Section Section 4.2" (as a requirement). Section 
4.2 listed two tel URIs (911 and 112) as examples ("such as"), not as an 
exhaustive list. Did this intend to say "as well as tel URIs formed from all the 
emergency numbers enumerated in the first paragraph of Section 4.2"?

The Security Considerations in Section 9 has several problems. Emergency 
calls are not more sensitive than normal calls, so do not have a greater need for 
confidentiality. If "sips" itself may "cause the call to fail", then it can 
not be used.

The requirement for the user agent to "reveal a different amount of 
information to the callee when making an emergency call" also applies to those calls 
dialed with the traditional emergency number when the user agent does not know 
the dial plan and therefore can not "clearly and unambiguously identity 
emergency calls". This function of revealing information must be possible without the 
SOS mechanism. If based on the SOS capability, then this makes it even more 
important for the user agent to correctly identify emergency calls (and not 
mistakenly trigger off of numbers assigned as emergency in other countries).

Conclusion:

The draft needs to make it clear how the SOS uri can be used in specific 3 
cases:

1. User dials the traditional emergency number, the terminal recognizes it, 
and send the SOS URI.
2. User enter the SOS uri directly (types on a keyboard).
3. User presses a button or icon that causes the appropriate SOS URI to be 
sent.

and cannot be used in the following case:

4. User dials the traditional emergency number, the terminal does not 
recognize it, and does not send the SOS URI.

Case 1 can only occur if the terminal knows the "local" dial plan. ("Local" 
is with respect to where the user perceives they are getting service from.)
Case 2 requires support for the local language.
Case 3 is a machine-to-machine communication and does not require 
recognizable words. It can use the reserved English words since no foreign speaker sees 
them.
Case 4 is used when the terminal does not know the local dial plan. It 
depends on a proxy to interpret the number, just as for any other dialed number.

Mike Pierce
Artel

---

From: Michael Hammer <[email-masked]>
Date: Wed, 11 Feb 2004 11:52:03 -0500

One additional question that was touched on in this email:

If an sos URI contains a domain name, I presume that a proxy will forward 
the request based on that domain name and never look at the local part 
containing the "sos.xxx".  Is that correct?

If so, does that mean that the proxy in that domain is expected to look at 
the location information and forward to the appropriate ECC proxy?

As for internationalization, that could get out of hand.  Was the intent 
that these URIs are machine readable only?  I suspect that some 
internationally recognized icons on the user agents that translate into 
these URIs will be needed.  But, that could be tricky as well:

sos.fire     picture of flames
sos.rescue   picture of Red Cross/Crescent?
sos.police   picture of badge/police belt?
sos.marine   picture of boat + cross/crescent?
sos.mountain picture of mountain + cross/crescent?

But those icons are phone implementation details.

Mike

At 11:13 AM 2/11/2004 -0500, [email-masked] wrote:
>In a message dated 2/10/2004 5:18:03 PM Eastern Standard Time, 
>[email-masked] writes:
>
>
>So, where in the world are different numbers used to access these 
>different emergency services? Not in the US where we use English. If they 
>are used in some other country, then why aren't the "reserved" user 
>addresses in the language of that country? Joe Citizen may be able to 
>choose the correct one, but I don't think Heinrich Staatsangehoeriger or 
>Pierre citoyen should be expected to choose the correct English word. We 
>have to stop relying on English for everything.
>
>terminal would be able to figure out to use the SOS URI as well as the 
>sub-address based on the number the person dials. There are fundamental, 
>unanswered questions regarding if and how the terminal would know the 
>local dialing plan.
>
>Further, I have a serious concern with the desciption in 4.2 that a 
>terminal must recognize many different digits strings and generate an SOS, 
>independent of where it is located, if it "has no knowledge of local 
>emergency numbers". This would result in many invalid calls to an 
>emergency center, since many of these numbers could be valid 
>(non-emergency) numbers (see note about 118 in Finland). Again, this 
>relates to the question of how the terminal knows the local dial plan. 
>Unless a method can be defined so that a terminal generates an SOS only 
>for the specific emergency number or numbers valid for the place it is 
>physically located (or for the place that the user thinks they are in, 
>that is, their virtual location), this entire scheme is faulty and can not 
>be used. Section 6 covers the issue of Identifying the Local Emergency 
>Number. There should be a statement that some method of doing this 
>identification is required, or else the terminal can not generate an SOS 
>based on dialed numbers. (Note the statement in Section 9 about being able 
>to "clearly and unambiguously identity emergency calls".)
>
>The 3rd requirement (in Section 3) is incorrect. When someone is 
>travelling, and getting service in a foreign country, there is no 
>requirement that they be able to dial their "familiar" home emergency 
>identifier (presuming this refers to the emergency "number"). This is 
>contradictory in many places. As noted, 118 is directory assistance in 
>Finland and a "familiar" emergency number elsewhere. This case is proof 
>that this requirement is impossible to meet.
>
>On the other hand, if a person is travelling and getting service from 
>their proxy back at the company office, they can't expect to get any 
>emergency service from that proxy.
>
>The 4th requirement is misleading. It is not acceptable to have 
>"restricted functionality" regarding access to emergency services due to 
>user agents not being aware of this document. There is clearly "restricted 
>functionality" concerning generation of the SOS URI, but that does not 
>need to be stated. The final sentence should state: "User agents 
>conforming to the SIP specification [RFC3261], but unaware of this 
>document, must be able to place emergency calls without any restriction 
>using entry of normal emergency numbers, although they will not generate 
>the SOS URI."
>
>SIP device to dial a local emergency number in the normal manner and 
>properly reach the emergency service."
>
>The statement in Section 5 that an "outbound proxy server MUST recognize 
>all local emergency numbers ..." is incorrect (and impossible). (Possibly 
>this sentence was meant to say " ... all local emergency numbers listed in 
>Section 4.2...", but this is still impossible). An outbound proxy only 
>needs to recognize those emergency numbers applicable to the local areas 
>for which it is providing service. An outbound proxy located in and 
>providing service for callers in the US certainly does not have to 
>recognize the emergency number used in some country in Africa. A visitor 
>from that country must dial 911 for an emergency if they are in the US and 
>receiving service from a service provider in the US. If the person from 
>Africa is travelling in Asia and uses the proxy in the US for service, 
>they can't expect it to correctly handle emergency service. The proxy 
>could not possibly distinguish between the emergency numbers for Asia, 
>about. This is an application that must be limited to entry of E.164 
>numbers (which does not include any emergency numbers or local dialing plans).
>
>Further, in Section 5, it is unclear how to interpret the phrase "as well 
>as the tel URIs enumerated in Section Section 4.2" (as a requirement). 
>Section 4.2 listed two tel URIs (911 and 112) as examples ("such as"), not 
>as an exhaustive list. Did this intend to say "as well as tel URIs formed 
>from all the emergency numbers enumerated in the first paragraph of 
>Section 4.2"?
>
>calls are not more sensitive than normal calls, so do not have a greater 
>need for confidentiality. If "sips" itself may "cause the call to fail", 
>then it can not be used.
>
>information to the callee when making an emergency call" also applies to 
>those calls dialed with the traditional emergency number when the user 
>agent does not know the dial plan and therefore can not "clearly and 
>unambiguously identity emergency calls". This function of revealing 
>information must be possible without the SOS mechanism. If based on the 
>SOS capability, then this makes it even more important for the user agent 
>to correctly identify emergency calls (and not mistakenly trigger off of 
>numbers assigned as emergency in other countries).
>
>Conclusion:
>
>1. User dials the traditional emergency number, the terminal recognizes 
>it, and send the SOS URI.
>Case 1 can only occur if the terminal knows the "local" dial plan. 
>("Local" is with respect to where the user perceives they are getting 
>service from.)
>recognizable words. It can use the reserved English words since no foreign 
>speaker sees them.

_______________________________________________
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: Tom Taylor <[email-masked]>
Date: Wed, 11 Feb 2004 15:57:48 -0500

The human factors aspect of this stuff has traditionally been the domain of the 
ITU-T.  I have a feeling they should be brought into the discussion.  I would have 
to check, but the relevant experts used to be located in Study Group 2.

Michael Hammer wrote:

> If an sos URI contains a domain name, I presume that a proxy will 
> forward the request based on that domain name and never look at the 
> local part containing the "sos.xxx".  Is that correct?
> 
> If so, does that mean that the proxy in that domain is expected to look 
> at the location information and forward to the appropriate ECC proxy?
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 11 Feb 2004 23:00:52 -0500

> local part containing the "sos.xxx".  Is that correct?

We have discussed two options in the past. One is the one you describe 
(and is normal SIP behavior); on the other hand, an outbound proxy could 
indeed inspect the URI and treat the call as an emergency call. I'd like 
to have a separate discussion as to whether such 'early intercept' is 
desirable.

This behavior would need to be specified in the emergency-arch draft.

> at the location information and forward to the appropriate ECC proxy?

Yes.

> As for internationalization, that could get out of hand.  Was the intent 

I don't see how multiple languages could work in practice. Since 
emergency calls can be routed to strange places, outside the local 
calling area, every proxy would have to understand every possible 
variation of 'police' in hundreds of languages.

> that these URIs are machine readable only?  I suspect that some 

Mostly machine-generated. But that's a user interface issue that I 
thought IETF specs generally stayed out of.

> But those icons are phone implementation details.

I would also consider them somewhat unlikely to be visible on most 
devices, certainly hard phones with plastic buttons.

For soft phones, if there is local dial plan discovery, the phone can 
display the appropriate icons or, easily, a word that means something in 
the user's native language.

In general, I suspect that the use of different numbers is declining. 
For example, in Germany, due to 112 as the GSM emergency number and the 
EU common-emergency-number plans, dialing 112 will get you all emergency 
services, even though 110 is the designated police number.

Henning

---

From: Michael Hammer <[email-masked]>
Date: Thu, 12 Feb 2004 10:47:24 -0500

At 11:00 PM 2/11/2004 -0500, Henning Schulzrinne wrote:
>I don't see how multiple languages could work in practice. Since emergency 
>calls can be routed to strange places, outside the local calling area, 
>every proxy would have to understand every possible variation of 'police' 
>in hundreds of languages.
>
>Mostly machine-generated. But that's a user interface issue that I thought 
>IETF specs generally stayed out of.

Agreed.  I was only suggesting that the dial-plan+local-language 
combination could be rather difficult.  The below stuff was just suggesting 
that a GUI to machine translation could help solve that.

>devices, certainly hard phones with plastic buttons.

Old POTS black phones yes, but many hard phones and cell phones today all 
come with a display and control software.  So, it does not have to be a 
softphone on a PC.

>In general, I suspect that the use of different numbers is declining. For 
>example, in Germany, due to 112 as the GSM emergency number and the EU 
>common-emergency-number plans, dialing 112 will get you all emergency 

It would be nice if Asia, Africa, and South America had standard regional 
emergency numbers.  (perhaps someone will tell us there is)

Australia is apparently "000".

Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Feb 2004 11:53:31 -0500

> 
> Old POTS black phones yes, but many hard phones and cell phones today 
> all come with a display and control software.  So, it does not have to 
> be a softphone on a PC.

Certainly.

> It would be nice if Asia, Africa, and South America had standard 
> regional emergency numbers.  (perhaps someone will tell us there is)
> 

http://www.911dispatch.com/web_graphic/graphic1.html has a graphic and 
lists of numbers. As you can see, very little coherence, but lots of 
countries with a single NNN.