Subject: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 14 Jan 2006 18:13:16 +0100

hi all,

Section 6 of <draft-ietf-ecrit-requirements-02.txt> discusses 
requirements related to emergency identifiers. 
draft-ietf-sipping-sos-01.txt also lists requirements and they should be 
removed from sipping-sos draft and incorporated into the requirements 
document. Here is an attempt to merge these requirements.

The following requirements should be discussed in context of the ecrit
requirements document. They are extracted from
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sos-01.txt

3.  Requirements

    o  It should be possible for devices to provide user interfaces that
       can directly cause an emergency call, without the user having to
       "dial" or type a specific address.

[hannes] user interface specific requirement and therefore not relevant 
for the requirements document.

    o  Even as each country is likely to operate their emergency calling
       infrastructure differently, SIP devices should be able to reach
       emergency help and, if possible, be located in any country.

[hannes] this is not an identifier specific requirement.

    o  While traveling, users should be able to use their familiar "home"
       emergency number.

[hannes] this says that a large number of country specific emergency 
numbers must be understood.

  Users must also be able to dial the local
       emergency number in the country they are visiting.

[hannes] i am not sure that this requirement means (particularly in 
relationship to the previous sentence). does it mean that the user must 
be able to dial the familar home number or the number that is recognized 
in the visited country. in the latter case there is only the question 
how the end host / user learns this information.

    o  Any mechanism must be deployable incrementally and work even if
       not all SIP entities support emergency calling.  User agents
       conforming to the SIP specification [RFC3261], but unaware of this
       document, must be able to place emergency calls, possibly with
       restricted functionality.

[hannes] there might be some usefulness in providing a description of 
the different approaches (as it is done with the first paragraphs of 
section 5 and section 7 of the requirements draft.

there are two aspects:

- sip proxies understand / do not understand the emergency identifiers
- end hosts understand / do not understand the emergency identifiers

requirement Id9 might go a little bit into this direction but seems to 
conflict with requirement Id8.

    o  Given incremental deployment, emergency call functionality should
       be testable by the user without causing an emergency response.

[hannes] this is not a requirement regarding the emergency identifiers.

    o  Emergency calling mechanisms must support existing emergency call
       centers based on circuit-switched technology as well as future ECC
       that are SIP-capable.

[hannes] not relevant.

---

    User agents SHOULD allow users and/or administrators to configure
    additional emergency numbers.

[hannes] this requirement is not yet there. it might be better to write:

"
    Mechanisms for configuring user agents with emergency numbers SHOULD 
be provided.
"

this is, however, just a different wording than in requirement Id6.

    User agents SHOULD attempt to ascertain the set of emergency numbers
    that are valid in the geographic region that the user agent is
    currently located in.

[hannes] this requirement is not yet there. in some sense it relates to 
the ability for user agents to be configured with emergency numbers.

    If and only if an end system is unable to determine the emergency
    numbers valid in its current geographical location, it SHOULD
    recognize any of the number 000, 08, 110, 999, 118 and 119 as
    emergency numbers.

[hannes] if this requirements refers to sip proxies then it relates to
requirement Id4. the text might, however, give the impression that it 
relates to end systems only. it therefore only relates to implementation 
specific end host requirement.

ciao
hannes

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 16 Jan 2006 06:57:29 +0000

>    recognize any of the number 000, 08, 110, 999, 118 and 119 as

I recognise exactly one of those as being emergency numbers. Why aren't 112
and 911 on the list? I believe they cover far more people than the above 6.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: "Tim Dunn" <[email-masked]>
Date: Mon, 16 Jan 2006 00:44:34 -0700

A larger, pretty exhaustive list of worldwide emergency numbers can be found
at

http://www.sccfd.org/travel.html

Should all of these be included?

Tim Dunn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Clive D.W. Feather
Sent: Sunday, January 15, 2006 11:57 PM
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Jan 2006 09:15:31 -0500

I don't know why 911 and 112 somehow got omitted from the list, but  
including all emergency numbers is probably not such a great idea as  
some of these are also used for non-emergency services elsewhere and  
are popular for various PBX functions. Most seriously, many PBX use 2- 
digit to 4-digit dialing for internal extensions. All extensions  
listed in the "recognize as emergency numbers" list would then  
suddenly cease to work or dial the local fire department. Not a good  
thing.

The list (000, 08, ...) is borrowed from the current wireless (GSM)  
conventions. GSM phones obviously don't have to worry about PBX  
extensions.

Given the PBX extensions issue, it might be necessary to restrict the  
list to 112 and 911 only.

BTW, I particularly like the entry for S. Georgia Is./ S. Sandwich  
Is. in the table.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Jan 2006 14:21:26 +0100

hi all,

i think that the following issues need to be determined:

1) do we want to support the usage of country specific emergency numbers?

2) if we say yes in (1)
then we need to provide a story for

2a) roaming users to learn emergency numbers supported in the network 
they visit

2b) sip proxies that potentially receive emergency calls with emergency 
numbers used in other countries.

the underlying question is: what migration scenarios do we want to support?
* sip proxies that do not understand 
<draft-schulzrinne-sipping-service-01.txt> (but end host do)
* end hosts that do not understand 
<draft-schulzrinne-sipping-service-01> but end host understand 
draft-ietf-sipping-sos-01.txt.
* end host understand neighter draft-ietf-sipping-sos-01.txt nor 
draft-schulzrinne-sipping-service-01.txt

ciao
hannes

Henning Schulzrinne wrote:
> digit to 4-digit dialing for internal extensions. All extensions  listed 
> in the "recognize as emergency numbers" list would then  suddenly cease 
> to work or dial the local fire department. Not a good  thing.
> 
> BTW, I particularly like the entry for S. Georgia Is./ S. Sandwich  Is. 
> in the table.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 17 Jan 2006 08:44:32 -0500

In the "big picture" sense, this is an absolute requirement.  Nations spend
untold millions of dollars/euros/yen/... teaching their citizens, especially
children, what the local emergency number is.  We cannot change the dialing
sequence.  Therefore, we have to, in one way or another, support local
emergency numbers.

The way I have always thought this would happen is that the local dialing
plan would translate the local emergency number into the universal emergency
URN.  To do so, some element may have to learn the local emergency number.
We need a mechanism for it to do so.

As we know, while often place for dial plan interpretation is the endpoint,
in some systems, a proxy does it.  Roaming phones need to learn the local
number.  Proxies serving roaming phones need to learn the local emergency
number.

The former seems relatively easy.  Some local mechanism (dare I say DHCP?)
could inform it.  The mapping function could provide it, and if the phone
did mapping at boot (or some entity in the location determination path did
it) it could get the local emergency number from the mapping protocol.  The
proxy has a more difficult problem because in general, it can't query any
local infrastructure at the endpoint, and prior to an emergency call, it
does not have the location of the phone.

This would drive us towards either having some new mechanism for the phone
to tell the proxy what the local emergency number is, or requiring that the
phone recognize the local number regardless of whether it does any other
dial plan interpretation.

Brian
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hannes Tschofenig
Sent: Tuesday, January 17, 2006 8:21 AM
To: Henning Schulzrinne
Cc: [email-masked]
Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers

hi all,

2) if we say yes in (1)

ciao
hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Jan 2006 09:11:39 -0500

> We need a mechanism for it to do so.

I agree that this is vitally important. Unfortunately, the normal SIP  
configuration mechanism that is being discussed in SIPPING is  
unlikely to be appropriate, as it does not take location into  
account.  The goal should be that, at least for mobile devices, both  
my "home" emergency number and my "visited" emergency number work.  
Having recently visited India, I made an effort to find the local  
emergency number (100, plus others), but it required significant  
effort and I suspect that most visitors wouldn't know what to dial if  
an emergency occurred.

> number.  Proxies serving roaming phones need to learn the local  

They need to learn the emergency number(s) local to the caller, given  
that the first-hop proxy may well be in another continent from the  
mobile device, for example.

This is why I have proposed a mechanism in the LUMP work to leverage  
the mapping infrastructure; it is almost trivial to solve the problem  
once you have a location mapping protocol.

> could inform it.  The mapping function could provide it, and if the  

DHCP, unfortunately, does not satisfy the "home" number requirement  
that I think we should strive for. It also requires yet another  
protocol machinery.

> does not have the location of the phone.

It can easily cache location-to-number mappings, as these are long- 
term stable and national. Indeed, it could simply walk through all  
country codes and get the mappings ahead of time.

> dial plan interpretation.

I don't think either is necessary. This is simply a location-to- 
identifier mapping problem, which we are already solving.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 17 Jan 2006 09:29:09 -0500

>country codes and get the mappings ahead of time.

The proxy doesn't have the location of the caller until a call the phone
recognizes as an emergency call is placed.  If the proxy does dial plan
interpretation, then the phone won't know it's an emergency call, and won't
send location when the local emergency number is dialed.

The proxy has to learn BEFORE an emergency call is placed, what the local
emergency number is.  That's pretty tough now.  We would have to have the
phone send it's location in advance, which is unacceptable.  There are
privacy considerations in the proxy knowing what the local emergency number
is (it may tell you what country the phone is in), but I think that's
unavoidable.  People worried about that level of privacy would need to have
a phone that did it's own recognition of the local emergency number.  

Caching the HOME emergency number is conceivable, for either the phone or
the proxy, but only if there was some indication of where home was.  I am
unaware of any mechanism that would tell you that.  You could conceivably
configure that, I guess, but you probably can't learn it.  Caching in the
phone assumes some non-volatile, but endpoint writable storage.  Dunno if
that is an acceptable requirement.  Probably, it's okay.

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Tuesday, January 17, 2006 9:12 AM
To: [email-masked]
Cc: 'Hannes Tschofenig'; [email-masked]
Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers

Henning

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Jan 2006 15:59:32 +0100

hi henning,

please find some comments inline:

Henning Schulzrinne wrote:
> configuration mechanism that is being discussed in SIPPING is  unlikely 
> to be appropriate, as it does not take location into  account.  The goal 
> should be that, at least for mobile devices, both  my "home" emergency 
> number and my "visited" emergency number work.  Having recently visited 
> India, I made an effort to find the local  emergency number (100, plus 
> others), but it required significant  effort and I suspect that most 
> visitors wouldn't know what to dial if  an emergency occurred.

one question that comes into my mind would then be:
if you can update your sip user agent implementation with this 
configuration/discovery mechanism then why cannot you just update the UA 
to support, let's say, draft-ietf-sipping-sos-01.txt and/or
draft-schulzrinne-sipping-service-01.txt.

your "home" emergency number can be mapped at the end host to an 
identifier described in these documents.

do i understand you right that you would like to provide a configuration 
mechanism for the end host so that the user can dial a local emergency 
number and then this local emergency number is mapped to a global 
emergency identifer at the end host. right?

ciao
hannes

> It can easily cache location-to-number mappings, as these are long- term 
> stable and national. Indeed, it could simply walk through all  country 
> codes and get the mappings ahead of time.
> 
> 
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Jan 2006 16:00:47 +0100

hi brian,

> sequence.  Therefore, we have to, in one way or another, support local

this is certainly true. there is, however, a user interface issue here 
too. the number the user dials does not necessarily need to appear on 
the wire.

so, if you always use the same emergency number but internally the sip 
implementation uses, for example, 
draft-schulzrinne-sipping-service-01.txt to represent the emergency call 
on the wire then there is no need to define a mechanism for the end host 
to dynamically retrieve country specific emergency numbers while abroad.

> We need a mechanism for it to do so.

it is a good question of who has to translate a locally known emergency 
number to a such a global emergency identifier. if it is the end host 
then there is probably no problem (or?). if this mapping is provided by 
the sip proxy then every sip proxy theoretically needs to understand all 
emergency numbers used in the world. there is no need to dynamically 
configure these proxies since these numbers do not change frequently.

> number.   Proxies serving roaming phones need to learn the local emergency

i am not sure that this is actually true. see above.
hence, the solution are not necessary.

ciao
hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 17 Jan 2006 11:52:41 -0500

>too. the number the user dials does not necessarily need to appear on 
Yes, that is the entire issue here.  From the entity that does dial plan
interpretation towards the proxy that does routing, we would see the
universal URN.  If the endpoint does dial plan interpretation, then the
endpoint needs to know the local emergency dialing string to know when to
substitute the universal URN.  If a downstream proxy does dial plan
interpretation, it needs to know the emergency number dial string for each
of its clients (and we would see the dialstring on the wire) to do the same
thing.

Put this in concrete terms:  I visit Chicago (where the dialstring is 911)
from London (where the dialstring is 999).  If my phone does dial plan
interpretation, I dial 9-1-1 on my phone.  The phone has to know that I'm in
Chicago, and it has to know that in Chicago, the emergency dial string is
9-1-1.  If the same phone visits Australia, it has to know it's in
Australia, and it has to find out that the dialstring in Australia is 000.

If my phone does not do dialplan interpretation, but my IP-PBX (in London)
does, then my IP-PBX would have to figure out that I was in Chicago, and use
some new mechanism to find out that 911 is the emergency dialstring.  And so
on...

>to dynamically retrieve country specific emergency numbers while abroad.
No, see above, either the endpoint or a proxy needs to know the local
dialstring so it can detect it, and put the universal URN on the INVITE.

....
>configure these proxies since these numbers do not change frequently.
If the end host does the dial plan interpretation, it needs to somehow
determine what the local emergency dialstring is.  If the proxy does it, it
has to determine what the location of the endpoint is, and then use that to
determine what the dialstring should be.  There are no mechanisms for any of
this.

Brian

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 17 Jan 2006 11:55:28 -0500

Brian,

> The proxy has to learn BEFORE an emergency call is placed, 
> what the local emergency number is.  That's pretty tough now. 

I realize ECRIT is dealing with emergency calling, but this problem pertains
to all applications with roamers that use site-local numbers such as 211,
311, 411, etc. in North America.  What is a SIP proxy located in Paris going
to do with a UA located in Texas that invites tel:211 ?  My point is this
issue needs looked at outside of ECRIT.  Whoever created site-local numbers
now needs to figure this out....(kinda sounds like private addressing....)
 
> Caching the HOME emergency number is conceivable, for either 
> the phone or the proxy, but only if there was some indication 
> of where home was.  I am unaware of any mechanism that would 
> tell you that.  You could conceivably configure that, I 
> guess, but you probably can't learn it.  Caching in the phone 
> assumes some non-volatile, but endpoint writable storage.  
> Dunno if that is an acceptable requirement.  Probably, it's okay.

This is all based on the assumption that the user will know/attempt to dial
the local emergency number vs. their HOME emergency number.  As you state,
the HOME emergency number is easy to cache/map, the local emergency number
is difficult at best.

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Jan 2006 13:43:20 -0500

> now needs to figure this out....(kinda sounds like private addressing....)

Note that tel:211 (or tel:911) are *not* valid tel URIs. They would only 
be valid with a context parameter.

I will note that the mechanism I describe in 
http://www.cs.columbia.edu/sip/draft/lump/draft-schulzrinne-ecrit-lump-01.html#anchor3 
is generalizable to other services.

The solution assumes that the dial string representation in 
draft-rosen-iptel-dialstring-02 is invertible, i.e., a device can take 
something like sip:911@somewhere;user=dialstring and recognize that it 
matches the digits "9" "1" "1" dialed by a user. Alternatively, the 
protocol would have to convey dial strings formatted as, say, KPML or MGCP.

> the HOME emergency number is easy to cache/map, the local emergency number

I suspect the right behavior is something like:

- Device gets configured manually or by the user's home provider with 
one or more "home" emergency numbers, e.g., using the SIP configuration 
mechanism. This could be based on the customer's billing address or some 
user selection.

IMS devices not used in a corporate PBX setting will also acquire the 
list of "default" identifiers that way.

All devices will have non-volatile storage, if only to store the user 
credentials, so I can't see that as a problem.

- When roaming, the device uses its location to ask for the local 
dialplan entries (dial string -> service URN pairs, to be precise). If a 
user dials one of the strings, the device emits a service URN.

- Proxies also create a mapping table from (SIP dialstring URLs, 
location) tuples to service URNs. As noted, proxies can pre-populate 
these tables as long as the granularity for the mappings is based on 
countries. Even Quebec or the French-speaking part of Belgium seem to 
have decided to stick with the overall national emergency number(s).

Leaving aside the mechanisms needed, would this work?

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Jan 2006 13:56:13 -0500

> emergency identifer at the end host. right?

Yes. (I'm assuming "local" here means the valid emergency telephone 
number used in the geographic vicinity the user finds himself in.)

There are two reasons:

- Naturally, if somebody visits a foreign country and sees a firetruck 
with 999 on the side, he or she expects to be able to dial that number 
and summon that fire truck (or its cousin);

- There's the "tourist collapses, good samaritan finds tourist cell 
phone and dials local emergency number" case.

This has to work whether there's an outbound proxy in the visited 
country or the tourist's home country. (I suspect localized outbound 
proxies will be rare, but nevertheless.)

Henning

---

From: Andrew Newton <[email-masked]>
Date: Tue, 17 Jan 2006 14:31:05 -0500

I must be missing a large part of the context.

On Jan 17, 2006, at 1:43 PM, Henning Schulzrinne wrote:

> - Device gets configured manually or by the user's home provider  
> with one or more "home" emergency numbers, e.g., using the SIP  
> configuration mechanism. This could be based on the customer's  
> billing address or some user selection.

What do you mean my "home" emergency number?  Is it 911?  Or is it  
+1-212-555-1234?

If is something like 911, then it could just be configured with that  
information based upon where you bought the phone.

> IMS devices not used in a corporate PBX setting will also acquire  
> the list of "default" identifiers that way.
>
> All devices will have non-volatile storage, if only to store the  
> user credentials, so I can't see that as a problem.
>
> dialplan entries (dial string -> service URN pairs, to be precise).  
> If a user dials one of the strings, the device emits a service URN.

What was the point of being configured with a "home" emergency number  
if the device is translating location-specific emergency numbers into  
URNs?

> location) tuples to service URNs. As noted, proxies can pre- 
> populate these tables as long as the granularity for the mappings  
> is based on countries. Even Quebec or the French-speaking part of  
> Belgium seem to have decided to stick with the overall national  
> emergency number(s).

Shouldn't the proxy be translating the "home" emergency number to a  
URN?  Isn't that the number the user will dial?

What about?
1) Device gets configured as you stated above.
2) Device translates all configured emergency numbers to URN.
3) URN is handed to the mapping service (along with location), which  
then hands back a PSAP URI.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 17 Jan 2006 14:46:10 -0500

See in line

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Andrew Newton
Sent: Tuesday, January 17, 2006 2:31 PM
To: Henning Schulzrinne
Cc: [email-masked]
Subject: Re: [Ecrit] Issue 30: Requirements regarding Emergency Identifiers

- Device gets configured manually or by the user's home provider with one or
more "home" emergency numbers, e.g., using the SIP configuration mechanism.
This could be based on the customer's billing address or some user
selection.

Well, in most places in the U.S., it would be 9-1-1, but there are some
places where it would be an E.164.   Of course, we need an international
solution, so the general case is it's an arbitrary dialstring, inclusive of
E.164s

Nah, "where you bought the phone" is not the issue.  Where "home" is would
be the issue.  Configuration could probably handle this.

IMS devices not used in a corporate PBX setting will also acquire the list
of "default" identifiers that way.

- When roaming, the device uses its location to ask for the local dialplan
entries (dial string -> service URN pairs, to be precise). If a user dials
one of the strings, the device emits a service URN.

What was the point of being configured with a "home" emergency number if the
device is translating location-specific emergency numbers into URNs?

Because someone has to recognize the home emergency number and translate it
into the appropriate universal URN.

- Proxies also create a mapping table from (SIP dialstring URLs, location)
tuples to service URNs. As noted, proxies can pre-populate these tables as
long as the granularity for the mappings is based on countries. Even Quebec
or the French-speaking part of Belgium seem to have decided to stick with
the overall national emergency number(s).

Shouldn't the proxy be translating the "home" emergency number to a URN?
Isn't that the number the user will dial?

The user dials the home number (or the  "visited" number).  Some entity,
possibly the phone, translates to the universal URN

What about?

3) URN is handed to the mapping service (along with location), which then
hands back a PSAP URI.

If the phone does dialplan interpretation, that works for the home number,
but not for the visited number.

If a proxy does dialplan interpretation, it doesn't work; the proxy has to
know what home is, and also has to know what visited is.

-andy