Subject: RE: [Sipping] Other concerns within sos ID

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 11 Feb 2004 13:46:36 -0500

Thanks for your comments.  While I have some replies, in line, you do 
raise a pretty important issue, which deserves attention.

The fundamental idea that this draft proposes is that emergency calls 
get special attention.  The special attention is that location is included 
on the call.  There are also routing implications, but the inclusion of 
location is the key issue.

The draft proposes that, one way or another, the call is determined to 
be an emergency call, and as a consequence, location is included.  
You point out the problem that if you have some address (phone number), 
which neither the UA or the outbound proxy recognizes as an emergency
number, 
then it will not get special attention.

The issue you raise with local emergency numbers is complicated by VPN 
tunnels.  My usual example is the patron of a cafe in Chicago seeing an 
accident while connected via a hotspot through a VPN tunnel to an employer's

VoIP system in Sierra Leone.  In this example, dialing the Sierra Leone 
emergency number would not be an emergency call, but 9-1-1 would be.  

The answer that works is that the PHONE knows its location, and the PHONE 
knows the local emergency number (or the phone has some other way to 
determine an emergency call).  If that is uniformly true, then it works.  
If that's not true, then the outbound proxy has a problem.  It has to know 
the location of the phone to determine the "local" (to the phone) emergency 
number.  So far, we haven't dealt with how we do that, but there are 
proposals that location is added by the outbound proxy when it can determine

location, but the phone cannot.

If the outbound proxy knows the location of the phone, then it could, 
in theory, determine the local (to the phone) emergency number, and then it 
could do
the right thing.  That seems to work also.

The thing that wouldn't work is the cross cases, where the phone knows its 
location, but cannot recognize local numbers (didn't have a dialing plan), 
or where the phone has dialing plans, but know way to be told the local 
emergency number.  The latter is probably fixable.  The former is more 
difficult.  We either have to fix it, or prohibit it somehow.

I also realized that there is a dialing plan conflict.  In my example, 
the employer in Sierra Leone has a local dialing plan.  If it has a conflict

with the local (to the phone) emergency number, there is a problem.  
That problem exists whether the phone or the proxy interprets the dialing 
plan.  The same problem would exist today for someone calling into an access

number for a PBX which allowed dialing within the PBX dial plan.  
If they were in a different continent, the local=to-the-phone)
emergency number would not work, the local-to-the-pbx emergency number 
would get them to an ERC, but not the right one.

There is no real solution that I can think of to this problem.  
You could always force the local-to-the-phone emergency number to override 
the local-to-the-pbx dial plan, but that is not very satisfactory.  
Better to not use a number to reach emergency services (use some other key 
sequence).

More inline.
...snip...

>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.
The assumption is that the phone presents an appropriate interface for
initiating an emergency call, and the result is a call to one of these
URLs.  You don't normally type them. 

>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. 
Covered above, noting that it might be a proxy, and not the phone, that has
the dialing plan

>
>Further, I have a serious concern with the description 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".) 
Generally, I think you are right; the only emergency numbers are the ones
local-to-the-phone.  Either the phone, or the proxy has to know where the
phone is, both to determine what the local emergency number is, and to
correctly route.

>The 3rd requirement (in Section 3) is incorrect. When someone is traveling,
>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.
Again, generally I agree.  It's a very unfortunate situation, because if you
are a visitor, your awareness of the local emergency number is not very
good,
while you clearly know your home emergency number.  

>On the other hand, if a person is traveling and getting service from their 
>proxy back at the company office, they can't expect to get any emergency 
>service from that proxy. 
No, the architecture is designed to make this work.  The local-at-the-pbx
proxy will find the location of the roaming party and route it to the
correct
ERC

>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. 
There are phones out there now.  What would you have us do with them?
I think this is a reasonable backwards compatibility specification

>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." 
I think this is incorrect.  First of all, a proxy can redirect to sos.
Secondly, you can't get "without restriction" because you don't get
location. 

>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." 
I don't understand what this adds to the requirements.  We have to address
some issues, but if we do, then this should be superfluous.

>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 
Rewording is required, I agree, but it has to refer to local-to-the-phone.

>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 traveling 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). 
Not correct, as above, the outbound proxy can provide emergency call routing
even if the caller is roaming

>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"? 
We can improve the wording here

>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. 
There are those who don't agree with you about confidentiality.  
I agree that calls can't fail if sips fails.  There is text in the location 
requirements for sip document about this.

>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). 
I think you propose something impossible.  If the call is recognized as an
emergency call, and routed as such, it will be routed as sos@localdomain,
and have location.  If it is not recognized, it will be treated per the 
local-to-the-pbx dial plan, and will not have location.  While we may want
to consider failure cases (you might reach some ERC, without location,
which is better than nothing), the goal is to not ever have this happen.

>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. 
The design is that a proxy can recognize the call as an emergency call
and cause the correct treatment for it.

>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.)
Or the proxy
 
>Case 2 requires support for the local language. 
Agreed.  Text needed.

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

>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. 
Disagree, as above

Brian 

_______________________________________________
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: Wed, 11 Feb 2004 14:15:06 -0500

> Better to not use a number to reach emergency services (use some other key 

In general, I think the correct long-term user interface solution is to 
have a hotkey or address book entry *with user confirmation* rather than 
having users trying to remember digit strings. The digit string model 
currently works rather badly for the PSTN - do you know, without looking 
at the hotel phone card insert, whether you need to dial 9-911, 0, 911, 
0-911 or some other combination to get emergency help in a US hotel, let 
alone in some hotel in a foreign country?

> while you clearly know your home emergency number.  

This is a trade-off with no provably 'right' solution, so we need to 
make choices. GSM cell phone users expect that 112 works everywhere 
(which it apparently does, even in the US), for example. My hunch is 
that the collisions for traveling users are at best a nuisance (and 
outweighed by the safety advantages), but that's a hunch.

> There are those who don't agree with you about confidentiality.  

And I think there's a reasonable case to be made that, on average, 
calling 911 is probably more security-relevant than calling your dry 
cleaner, for a variety of reasons. The document makes no quantitative 
claim, so I just don't see the harm.

> requirements for sip document about this.

Among many of the topics discussed here, this has all been discussed 
before, with the current text trying to reflect the earlier consensus. 
We can't make progress if we re-open the same issues again and again.

We should probably split the discussion into separate issues as the mail 
messages are getting far too long.

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 11 Feb 2004 18:44:32 -0600

At 02:15 PM 2/11/2004 -0500, Henning Schulzrinne wrote:

>having users trying to remember digit strings.

This is something that the wireless industry used for a while with less 
than desirable affects (too many unintentional calls by hitting the one 
button accidentally). The PSAPs in the US (and I am only speaking for them 
in this comment) are quite opposed right now to this hotkey/button idea 
resurfacing.

>The digit string model currently works rather badly for the PSTN - do you 
>know, without looking at the hotel phone card insert, whether you need to 
>dial 9-911, 0, 911, 0-911 or some other combination to get emergency help 
>in a US hotel,

this is a good point - it changes based on the TDM switch configuration for 
that phone

>let alone in some hotel in a foreign country?
>
>
>This is a trade-off with no provably 'right' solution, so we need to make 
>choices. GSM cell phone users expect that 112 works everywhere (which it 
>apparently does, even in the US), for example. My hunch is that the 
>collisions for traveling users are at best a nuisance (and outweighed by 
>the safety advantages), but that's a hunch.

curiosity question, if 112 works in the US, does 911 work anywhere in Europe?

>Henning

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 11 Feb 2004 19:53:14 -0500

> button accidentally). The PSAPs in the US (and I am only speaking for 
> them in this comment) are quite opposed right now to this hotkey/button 
> idea resurfacing.

I guess my ** were not bold enough. I'm well aware of the hotkey issues 
and that's why I said "with user confirmation". That would eliminate the 
nuisance calls.

---

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

Picked up one relevant clarification item.

> Rewording is required, I agree, but it has to refer to local-to-the-phone.

'Local' has too many meanings - I guess it should always be qualified. I 
reworded this as referring to a the emergency numbers *local to the 
outbound proxy*. This is primarily meant to deal with phones that don't 
understand the conventions in the 'sos' document.