Subject: [Ecrit] Services with same Service Number

From: "Karl Heinz Wolf" <[email-masked]>
Date: Tue, 15 Jan 2008 15:25:15 +0100

I tried the LoST Server implementation available at:

http://honamsun.cs.columbia.edu/lost_homepage/

I did a listServicesByLocation and then requested a mapping for all
the services with the sample US location. What confuses me is the
fact, that there are different services all with the same service
number 911 (but different SIP URIs).
A user is expected to dial the service number in case of emergency, in
this case 911. Which service should the client choose then?
sos.police, sos.poison?

By the way: I looked at listServices and listServicesByLocation
(Section 10 and 11 in the lost draft). The listServicesByLocation
explicitly says that the LoST server returns only child services. In
the section above, listServices, this is not noted (but the examples
just show child services). Is this intended?

cheers
karl heinz

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

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 15 Jan 2008 14:39:08 -0600

Karl

If I understand your question correctly, dialing 911 in the US 
doesn't separate police from fire from several other services -- all 
these types of calls (save for some like the suicide hotline and 
poison) are answered by the same call center within a geopraphic 
area, and the call taker decides where to direct the call (i.e., to 
the police, or to the fire department or to an ambulance or mountain 
rescue or emergency forest service).  This is pretty universal within 
the US. There are no (that I know of) 3 digit dial-strings for poison 
centers or suicide hotlines. Each of these is at least 7 digits long, 
and sometimes 10 digits long (if an area requires an area code before 
each 7 digit number).

Again, I may have misunderstood what you are asking

Hope this helps

James

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Wed, 16 Jan 2008 08:31:44 +0100

James,

thank you for your answer. I expected the US 911 service to work as
you explained it to me. So I expected that a US LoST server would just
return a service:sos URN and not separate child service URNs with
different SIP URIs and same service number as in the example LoST
server http://honamsun.cs.columbia.edu/lost_homepage/
If you use the client on this web page it returns:

for police:

<displayName xml:lang="en">North Carolian Police Dept.</displayName>
<service>urn:service:sos.police</service>
<uri>sip:[email-masked]</uri>
<serviceNumber>911</serviceNumber>

for fire:

<displayName xml:lang="en">North Carolian Fire Dept.</displayName>
<service>urn:service:sos.fire</service>
<uri>sip:[email-masked]</uri>
<serviceNumber>911</serviceNumber>

and so on, all with service Number 911.
So that is what confuses me. When I dial 911 now, where should the call go now?

One more question: should a country, that has separate services also
provision a urn:service:sos in the LoST server or just child services?

cheers
karl heinz

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 16 Jan 2008 02:41:27 -0600

Karl

[stating this as an individual, which should be redundant here]

To the question: where should a 911 call get routed to? The answer in 
the US at least, is the PSAP, with the (trained) call taker deciding 
which service or services need to be engaged.   For example, where 
there are child services (as you call them), if you get in an auto 
accident, which service do you call, the police or fire or 
ambulance/medical? A PSAP can get more than one to the scene of the 
accident with a single call.  Other locations employing child 
services may necessitate one call per service.  After all, as much as 
all of us believe we should have the right to call who we want to 
call, sometimes we're not the best educated on who the call should go 
to; whereas a trained PSAP call-taker can make perhaps a better 
decision about how many different services ought to take part in 
providing help.

To the question about each country employing a single service or 
multiple services, that's up to each country.  But I think a lot of 
this answer depends on the social behaviors of that country's 
citizens.  Making a change in what people are expected to do to a 
critical service can have some dire consequences until that behavior 
is learned throughout a country. Conversely, limiting multiple 
choices down to one may frustrate citizens thinking they are being 
deprived of the right to call who they want to call directly.  This 
question does not have an engineering answer/solution - it is a 
social answer/solution to what that country's public will accept in a 
reasonable amount of time.

James

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Wed, 16 Jan 2008 11:07:02 +0100

Hi James,

thank you again for your quick reply. I'm sorry, but you misunderstood
my question.

Taking your car accident example: you start you SIP client, it does
location determination and service discovery and gets:

for police:

for fire:

now the user dials 911 as usual. Now what should the client do? Call
the police SIP URI or the Fire SIP URI?

Concerning the question: must a service:sos entry always exist in
every LoST database even though the country just uses child-services
police, fire, ambulance, ...? I do not want to change the number of
existing services in countries, but is it allowed that a LoST server
returns an error for service:sos because just service:sos.police .fire
and .ambulance is provisioned or should service:sos result in a
mapping (to what service then?).

Thanks for help and I hope I explained my (implementation related)
question understandable!

cheers
karl heinz

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 16 Jan 2008 04:45:24 -0600

FWIW, I have the same question that Karl has. I understand that in some 
places, people expect to be able to call a more specific service directly, 
but they need to dial a different number to reach that service, don't they?

You guys are the experts, but if a country has

> <displayName xml:lang="en">North Carolian PSAP</displayName>
> <service>urn:service:sos</service>
> <uri>sip:[email-masked]</uri>

> <serviceNumber>911</serviceNumber>

I'm not seeing how "911" should go anywhere except 
<service>urn:service:sos</service>, and if a country has both

<service>urn:service:sos.police</service> and
<service>urn:service:sos.fire</service>

with serviceNumber 911, and does not have

<service>urn:service:sos</service>

with serviceNumber 911, I'm not seeing how the client can choose between the 
two services with the same serviceNumber.

Is this obvious to everyone except me?

Thanks

Spencer

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 Jan 2008 08:05:25 -0500

I think a country which only had a single emergency number would not
normally list individual services.  It would only list the single sos
service.

However, if it did, it would list all services with the single number as the
service number as well as the sos service.  That shouldn't cause any
confusion at the endpoint. 

Generally, because of 1-1-2, every country has SOME service that responds to
1-1-2 even if they don't really have a single emergency number system.  That
would be the service whose URI was in sos.  

I don't see the problem.  Every country SHOULD have an sos service.  A
country that has a single number emergency system normally SHOULD NOT list
other services, but if it does, it uses the single emergency number and the
single PSAP URI for all of the services.  A country that does not have a
single emergency number still should list an sos service with some URI and
service number, and MUST list their services with their service numbers and
URIs.

Brian

> -----Original Message-----
> From: Spencer Dawkins [mailto:[email-masked]]
> Sent: Wednesday, January 16, 2008 5:45 AM
> To: ECRIT
> Subject: Re: [Ecrit] Services with same Service Number
>

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 16 Jan 2008 08:58:34 -0600

Hi, Brian,

Thanks for the feedback.

> would be the service whose URI was in sos.

OK so far...

> service number, and MUST list their services with their service numbers 

I'm with you up to this point. In the problem I thought Karl was raising, he 

>> > <serviceNumber>911</serviceNumber>

which use the same serviceNumber and DIFFERENT uris for multiple services.

What happens then? I have some thoughts but someone else probably has 
clearer thoughts.

Spencer

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 Jan 2008 10:34:21 -0500

Right, I see the problem; since we have no priority or precedence of
services, if the user enters "9-1-1", what URI should be used?

The answer is of course urn:service:sos, but we don't have anything that
says that anywhere.

We have two options:
1. Disallow the circumstance; two services can't have the same service
number
2. Specify priority somehow

Let's think through the cases:
1. The U.S. case works with 1), and if we specified sos has priority, then
it would work with 2)
2. The German case.  1-1-2 is fire/ems, 1-1-0 is police.  So, police would
have a different service number and URI, fire/ems would have the same uri
and the same service number.  Priority wouldn't really matter; whether you
used 1-1-2 for fire or 1-1-2 for sos, it works.
3. The French case.  Police is 1-7, medical has "more severe - 1-5, less
severe 1-8", and Fire is 1-8.  1-1-2 is answered by 1-5 or 1-8 in different
parts of the country.  This works without priority, because all of the
services have different service numbers and uris and sos has it's own
service number and a uri that overlaps with 1-5 or 1-8 depending on
location.

Go look at:
http://en.wikipedia.org/wiki/Emergency_telephone_number

and see if you can spot a problem with making sos have more priority than
any subservice when the sos dial code is re-used for a specific service.

Brian

> Sent: Wednesday, January 16, 2008 9:59 AM
> To: 'ECRIT'
> > Generally, because of 1-1-2, every country has SOME service that
> responds
> > to

---

From: Ted Hardie <[email-masked]>
Date: Wed, 16 Jan 2008 09:03:11 -0800

>2. Specify priority somehow

I think we're heading off into some tall, tall weeds here.  Let's back up
a step.  The base case is this:  a client presents a LoST server with a specific
service  URN and a location.  It sends back a set of URIs, commonly including
a SIP URI, which will be used to reach the service responders.   It also
gets back a service number.  That's used *in cases where the client cannot
invoke the protocols associated with the URIs directly*.  In the case
where the client got a SIP URI, and has a SIP stack, it uses SIP.  If it
didn't need voice and got an SMS URI, it might use SMS.  

If it does not have a SIP stack, it may use the service number.  But in that
case, there *is no guarantee it is being routed to the same PSAP as it would
have reached with a known locality*; it gets routed to whatever its circuit-switched
routing takes it.  It likely can't even send along the location with that
invocation.  This is a fallback or "additional info" that a user might find handy
the next they are near this location and calling from some less-capable
device like a payphone (not that there are many of those any more).  It
should never take precedence over a locality-informed URI.

I hope that is clear enough to everyone. 

I think "listServices", which is where we started this discussion, may be somewhat
confusing because you see all at once that the match between URIs and service
numbers may not one-to-one (and, based on jurisidictional choices, it can be interesting
in lots of ways), but the influence of location on specific results is opaque.
But that query shouldn't take the place of the actual LoST query and
results processing.  Start from *that* context, and work outward to listServices, and
I believe it gets a lot clearer fast.

			regards,
				Ted

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 16 Jan 2008 12:58:13 -0500

Hmmm. No, I don't think it's about the ability of the client to invoke
services. It's about the methods the user uses to invoke services. Users
dial digits. The main purpose of the service number was for dialed digit
string recognition, for backward compatibility with existing ways that
people currently signal "Connect me with emergency services". That is,
they pick up the phone (SIP or not) and dial 9-1-1, 1-1-2, 0-0-0, or
whatever string that they think should connect them with the help they
need. 

The device sees that the user dialed "9-1-1", and sees that this string
is one of the stings returned by LoST (or otherwise configured). The
device now needs exactly one service urn and route uri to associate with
that string, to create a properly formed SIP INVITE (per phonebcp), if
it uses SIP. If it has more than one, then it needs precise rules for
selecting one. I think this is what Brian said. And I agree with Brian.
Barbara

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Wednesday, January 16, 2008 12:03 PM
To: Brian Rosen; 'Spencer Dawkins'; 'ECRIT'
Subject: RE: [Ecrit] Services with same Service Number

>2. Specify priority somehow

I think we're heading off into some tall, tall weeds here.  Let's back
up
a step.  The base case is this:  a client presents a LoST server with a
specific
service  URN and a location.  It sends back a set of URIs, commonly
including
a SIP URI, which will be used to reach the service responders.   It also
gets back a service number.  That's used *in cases where the client
cannot
invoke the protocols associated with the URIs directly*.  In the case
where the client got a SIP URI, and has a SIP stack, it uses SIP.  If it
didn't need voice and got an SMS URI, it might use SMS.  

If it does not have a SIP stack, it may use the service number.  But in
that
case, there *is no guarantee it is being routed to the same PSAP as it
would
have reached with a known locality*; it gets routed to whatever its
circuit-switched
routing takes it.  It likely can't even send along the location with
that
invocation.  This is a fallback or "additional info" that a user might
find handy
the next they are near this location and calling from some less-capable
device like a payphone (not that there are many of those any more).  It
should never take precedence over a locality-informed URI.

I think "listServices", which is where we started this discussion, may
be somewhat
confusing because you see all at once that the match between URIs and
service
numbers may not one-to-one (and, based on jurisidictional choices, it
can be interesting
in lots of ways), but the influence of location on specific results is
opaque.
But that query shouldn't take the place of the actual LoST query and
results processing.  Start from *that* context, and work outward to
listServices, and
I believe it gets a lot clearer fast.

			regards,
				Ted

>> > However, if it did, it would list all services with the single
number as
>> > the
>> > 1-1-2 even if they don't really have a single emergency number
system.
> > > That
>> > country that has a single number emergency system normally SHOULD
NOT
>> list
>> > other services, but if it does, it uses the single emergency number
and
>> > the
>> > single emergency number still should list an sos service with some
URI
>> and
>> > service number, and MUST list their services with their service
numbers
>> > and
>> > URIs.
>>
>> I'm with you up to this point. In the problem I thought Karl was
raising,
>> he

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 16 Jan 2008 12:05:02 -0600

Karl

I understand your question better.  I think Brian's explanation is 
best for the question you ask.  But I will add this (mostly as a 
restatement of Brian's comments):

Ultimately, if a SIP UA gets a single service number back (from LoST) 
from a single service URN, it can only contact that single service 
destination.  If, in your example, LoST returns more than 
one  service with the *same* service number, this would lead to 
confusion unless your SIP UA has some form of configuration and/or 
priority of which to use first (if the user dials 911, from your 
example, the first URI used is police). Determining the URI priority 
of which to use (i.e., configuring the UA) has not been addressed 
yet, and might not be within the IETF, as I personally believe this 
is a local jurisdiction issue - which will have different outcomes 
based on the number of roaming/nomadic UAs wondering into each area 
that has different priorities/expected configurations (but this is 
really getting into Ted's tall weeds! So I'll stop this line of thought).

That said, your example has different URIs for each service - which 
can each be initiated with different INVITEs for different/multiple 
dialogs concurrently (if the UA can do this - which could end up as a 
3-way call to both the fire and police departments, with the UA as 
the media mixer).

In your example, I don't think North Carolina would give back 
separate URIs (one each for fire and police), but would give back a 
single URI to an ESRP (at the border of the ESInet) or the PSAP 
(which would direct the call to whomever they believe should be 
contacted to best serve the UA's situation).

In a country that has multiple URIs (returnable by LoST), each with 
different service numbers, a UA would likely call one URI at a time 
(with different child URNs or different service numbers), and 
everything works as predicted here.

I hope I didn't confuse Brian's explanation with what I've added.

James

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 Jan 2008 13:25:17 -0500

What she said.

Brian

> From: Stark, Barbara [mailto:[email-masked]]
> Sent: Wednesday, January 16, 2008 12:58 PM
> To: Ted Hardie; Brian Rosen; Spencer Dawkins; ECRIT
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential, proprietary, and/or
> privileged material. Any review, retransmission, dissemination or other
> use of, or taking of any action in reliance upon this information by
> persons or entities other than the intended recipient is prohibited. If
> you received this in error, please contact the sender and delete the
> material from all computers. GA622

---

From: Ted Hardie <[email-masked]>
Date: Wed, 16 Jan 2008 10:26:19 -0800

>is one of the stings returned by LoST (or otherwise configured).

I think you have the mapping wrong.  The 911 string dialed by the
user is the UI invocation; it's the 3-button equivalent of the big
red button that says "call for help" in jurisdictions that have a single
response view of the world.  If LoST had not been previously run,
I would expect it to cause LoST to take the location of the device
and a service urn of sos (unadorned, since 911 is general).  It should
then get back a set of URIs and a service number.  Presuming
that the device can use one of those URIs, it would then invoke the
protocol processing associated with the URI scheme (SIP, in
the examples we've been discussing).  If it cannot, then it
might use the service Number to create a circuit switched call.
That circuit switched call might be to 112.

As "additional data" in a phone with sufficient power, it might
also return to the user the information "dialing local emergency
response at 112", so the user knows it can invoke local emergency
response.    When the user next dials 112,  them implementation
would do exactly the same thing as it did with 911, only the
service number and invocation string would happen to match.

Again, this is the base case.  If the phone pre-loads LoST information
and gets mappings beyond those for which the user knows invocation
UI methods, it might in some cases create them.  That might be a drop
down list, a voice prompt (now press one for fire, two for police, three
for medical emergencies, or stay on the line) or something else.
It might also add the service numbers to a list of patterns in looks
for as invocations of emergency services (since an invocation
results in the same device behavior whether  the invocation string
matches the resulting service number or not, this is okay).  But if it pre-loads this
information by *replacing* the invocation string 911 with 112 because of
local data on the service number, it has not done anyone any favors. 

				regards,
					Ted

> The

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 Jan 2008 13:50:07 -0500

> That circuit switched call might be to 112.
Huh?

The numbers came from LoST.  For the phone to recognize them, it has to have
them, and it gets them from LoST primarily.  There ARE other ways: it can
get dial string to service mappings by configuration for example.

That's the service number.

It compares local strings to these service numbers, and when it has a match,
it invokes emergency call processing.  

The result of the match of dialed digits is the service URN.

PhoneBCP says that it should update its location and the service URN to PSAP
URI mapping at call time.  So it should take the service URN and get a new
PSAP URI from LoST.  If that fails, it can use the cached URI.

That's the PSAP URI

The phone looks for the service number, maps the service number to the
service URN and maps the service URN to the PSAP URI.
> service number and invocation string would happen to match.
Where did this come from?  There isn't anything like that I know of.
It may well be the case that you can get two service numbers for one
service.  This would be the case in, for example, the U.K, where both 9-9-9
and 1-1-2 are acceptable.  However, you get that from LoST, or you get it
from configuration and it still gives you service number to service URN.
You can have more than one service number that maps to the same service URN,
but in this thread, we're talking about having a service number map to more
than one service URN, and we have a problem with that.

> local data on the service number, it has not done anyone any favors.
Agree, but that's not the problem at hand.  The problem at hand is having
9-1-1 map to urn:service:sos AND having 9-1-1 map to urn:service:sos.police.

It's okay to have more than one service number map to the same service URN,
it's a problem to have more than one service URN map to the same service
number.

Brian

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 16 Jan 2008 14:19:22 -0500

>2. Specify priority somehow

As we think about these two options, we should also consider the
possibility that configured "home" service numbers might overlap with
LoST-provided numbers. It's theoretically possible for the same string
to have a completely different service urn in different countries.

Based on previous discussions, I'm assuming that you (Brian) would
prefer for the LoST urn and uri to have precedence. I think that would
be an ok rule. Are you thinking phonebcp for this?
Barbara

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 Jan 2008 14:28:14 -0500

Good thought.  Implies we can't just rule it away; the configuration tool
and LoST don't talk to one another.

The problem you hint at will definitely occur.  The typical use for
configuration data is to get "home" dial strings, and LoST gives you
"visited" dial strings.  I agree we're sure to get problems there.

So, yes, I would favor LoST over any other way to get the data, and yes, I'm
thinking phonebcp.

Brian

> Sent: Wednesday, January 16, 2008 2:19 PM
> material from all computers. GA625

---

From: Ted Hardie <[email-masked]>
Date: Wed, 16 Jan 2008 11:40:52 -0800

>get dial string to service mappings by configuration for example.

First, I just went to look up "service number" in phonebcp, and found
that the string isn't even found.  It consistently uses "dial string" as
you use it above.  Some reference mapping "dial string" in phonebcp
specifically to "service Number" in LoST seems like a good idea,
probably here:

ED-7/SP-6 Local emergency dial strings SHOULD be determined from LoST
   [I-D.ietf-ecrit-lost].

Second, if I understood Barbara right, she saying that what users will
do on phone is mostly dial numbers; I agree with that, and I think phonebcp
agrees with that when it talks about recognition of both local and
home dial strings in Section 5.  Those largely come out of the user's
head as known UI invocations; since a user may or may not know
the local dial string, both UI invocations have to work.  I think
we agree on that, and that the current phonebcp text says it here:

   ED-3 Endpoints SHOULD recognize dial strings of emergency calls.  If
   the service provider always knows the location of the device, then
   the service provider could recognize them.

   SP-2 Proxy servers SHOULD recognize emergency dial string if for some
   reason the endpoint does not recognize them.  This cannot be relied
   upon by the device if the service provider cannot always determine
   the location of the device.

   ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the
   Request-URI of the INVITE.

   ED-5/SP-4 Local dial strings MUST be recognized.

   ED-6/SP-5 Home dial strings MAY be recognized.

Where I have been focused in this discussion is on what a device does if it gets
back a service Number with a LoST response and cannot use the URIs in the
set that is returned.  I think the what it does if it *can* is clear:  it uses those
URIs.  I think where we may disagree is what it does if it cannot:  I think either
the device or the user should be able to take the service Number and attempt
to make a call (either on that phone or another) using just the service Number.
The particular case in my head is the one where a device with a cellular
data connection that would normally complete this using SIP finds it cannot
and falls back to a circuit-switched call instead (e.g. 1xRTT).  That , in essence,
treats the service Number as both a dialstring and more-or-less as the source
of a constructed Tel URI. 

Possibly we disagree on this point, and I'd be interested to know whether we
do or do not.

<snip>

>9-1-1 map to urn:service:sos AND having 9-1-1 map to urn:service:sos.police.

If 9-1-1 maps to urn:service:sos and 9-1-1 maps to urn:service:sos.police
and the contact URIs returned in the set are the same, there is no fundamental
problem.  The call still completes and gets to the right place.  If the UI
invocation used to make the call was just the dialed string, then I would
say that the top-level of the hierarchy should be used (urn:service:sos
rather than urn:service:sos.police) as an indicator. 

If 9-1-1 maps to urn:service:sos and 9-1-1 maps to urn:service:sos.police
and the contact URIs returned in the set are not the same, I believe
the sensible thing to do for a UI invocation based on the dial
string only is to route to urn:service:sos; it's the top of the hierarchy
and if you have no other input, that's what you use.  But if there
is another way to make the selection (drop down, voice prompt,
etc.), you might allow that to make a direct selection of the
urn:service:sos.police choice, and then route directly there.  Forbidding
that because there is no dialstring possibility doesn't make sense to
me.  People may *mostly* use dialstrings on phones, but there are more
capable devices out and allowing them to make more precise choices
seems reasonable to me if it does not prevent the base case from
working.

				regards,
					Ted

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 Jan 2008 15:06:49 -0500

I'm doing an update to phonebcp now, so I'll fix the terminology issue.

Definitely agree users will dial numbers to reach emergency services.  We
don't like big red emergency buttons.  However, it's possible that better
UIs that don't have the problems of big red emergency buttons can be
devised, and I wouldn't want to rule them out.

IFF the phone has an alternate way to place a call (use CS instead of PS)
AND its PS mechanisms fail, then indeed it could use any of the dial strings
it has to try to reach someone who can help.  I think that such cases are
pretty much restricted to IMS systems, and I don't think we need to spend
much time on them, but if there is support, we could mention it in phonebcp.
I think those cases are rare enough that we don't need much guidance (like
what number has priority if there is more than one).

The only way you can get to the situation where you have two URIs for the
same dial string is something like the case Barbara discusses ("home"
configuration + "visited" LoST discovery), or the case described below.
When dialing is used, we must just use a rule (highest point in the
hierarchy, LoST results preferred over other sources).  

Generally, making choices when you are stressed is usually NOT a good idea,
and getting the call to someone ASAP is probably more important.

If the LoST database looked like the example we're using, the rule would
work, and it would be possible to generate a UI that allowed a user to
choose police/fire/ems or overall emergency, with the call going to the
appropriate URI.  That may actually be of some use if we could get the UI
right.  All the URIs may actually resolve to the same domain, but the PSAP
may be able to use the information profitably (the user is passing
information on which service they think they need).  That could preload
certain screens at the PSAP.  Of course, the call taker may decide to
override that based on the information gleaned from the call, and local
policy, but it could shave some time off response.

However, it ONLY works if there is a clear rule for what the UA should do
when the digits that map to two URIs is entered, and it only works if
someone develops a UI that really does work better than dial strings.

Brian

> Sent: Wednesday, January 16, 2008 2:41 PM
> To: Brian Rosen; 'Stark, Barbara'; 'Spencer Dawkins'; 'ECRIT'

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 16 Jan 2008 15:34:39 -0600

Using ordering to imply priority isn't ideal, but as long as it is very clear in LoST (not phonebcp, this is protocol semantics) it should work.

I'm concerned about the question Barbara raised though.

To provide an extreme example of Barbara's conundrum: What if 911 called for a pizza in Greenland?  I assumed that this could be addressed by UA configuration on a device that the user owns; that is, they teach their UA to understand that 911 == urn:service:sos.  However, that doesn't work if they are visiting someone and just pick up their host's UA.  It also doesn't work if you force LoST to take priority.

I agree though, forcing a series of questions for an emergency call isn't a good idea.  We need a sensible default behaviour.  Perhaps something along the lines of any service in the urn:service:sos* path overrides any other service.

_M

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Thursday, 17 January 2008 7:07 AM
> To: 'Ted Hardie'; 'Stark, Barbara'; 'Spencer Dawkins'; 'ECRIT'
> > set that is returned.  I think the what it does if it *can* is clear:
> it
> > uses those
> > and falls back to a circuit-switched call instead (e.g. 1xRTT).  That ,
> in
> > essence,
> > Possibly we disagree on this point, and I'd be interested to know
> whether
> > we
> > do or do not.
> >
> >
> > <snip>
> >
> > >
> > >>
> > >> matches the resulting service number or not, this is okay).  But if
> it
> > >> pre-loads this

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 Jan 2008 16:56:16 -0500

We're not proposing to use ordering.  We're proposing to use hierarchy (sos
is higher than sos.police).  I agree that sos is higher than any other
service.

I'm not sure I understand why you think following LoST doesn't work.
If you are visiting the U.S. from Greenland, and you dial 9-1-1, you should
get a PSAP.  If you intended to order pizza, you will be surprised.
However, you definitely DON'T want to get the local pizza service.
Always preferring LoST would always make the local dialing plan take
priority.  That is correct.  Any configuration is wrong.  I don't feel great
about not having a way to override LoST, but I think it's a much more likely
failure to have local configuration be wrong then to have LoST be wrong.

Brian

> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Wednesday, January 16, 2008 4:35 PM
> To: Brian Rosen; Ted Hardie; Stark, Barbara; Spencer Dawkins; ECRIT
> Using ordering to imply priority isn't ideal, but as long as it is very
> clear in LoST (not phonebcp, this is protocol semantics) it should work.
> 
> To provide an extreme example of Barbara's conundrum: What if 911 called
> for a pizza in Greenland?  I assumed that this could be addressed by UA
> configuration on a device that the user owns; that is, they teach their UA
> to understand that 911 == urn:service:sos.  However, that doesn't work if
> they are visiting someone and just pick up their host's UA.  It also
> doesn't work if you force LoST to take priority.
> 
> I agree though, forcing a series of questions for an emergency call isn't
> a good idea.  We need a sensible default behaviour.  Perhaps something
> along the lines of any service in the urn:service:sos* path overrides any
> other service.
> 
> _M
> 
> > > >The numbers came from LoST.  For the phone to recognize them, it has
> to
> > > have
> > > Where I have been focused in this discussion is on what a device does
> if
> > > it gets
> > > to make a call (either on that phone or another) using just the
> service
> > > Number.
> > > >> information by *replacing* the invocation string 911 with 112
> because
> > > of
> > > problem.  The call still completes and gets to the right place.  If
> the
> > UI
> > > >It's okay to have more than one service number map to the same
> service
> > > URN,

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 16 Jan 2008 16:57:50 -0500

This is not purely hypothetical. There are numbers (118 is an example)  
that are both emergency numbers and have other functions elsewhere  
(directory assistance).

One reasonable mechanism is to display a warning when you dial an  
emergency dial string. If you expected pizza, you'll investigate. This  
case can only arise if that number is emergency at home, non-emergency  
in the visited country. In other words, the person dialing will  
probably recognize the source of the problem if given a sensible error  
message. ("The number you have dialed - 911 - is configured as an  
emergency number.")

The incidence of such cases should be very small, since it only  
affects tourists and certain short dialing strings. It seems highly  
unlikely that somebody remembers the US poison control 800# and then  
dials that while vacationing in Europe.

We have this problem today, to some extent: Dialing 112 on a GSM  
cellphone gets you emergency services anywhere, or so I've been told.  
I don't know if there's a directory service or pizza parlor using that  
number outside Europe.

Henning

On Jan 16, 2008, at 4:34 PM, Thomson, Martin wrote:

> Using ordering to imply priority isn't ideal, but as long as it is  
> very clear in LoST (not phonebcp, this is protocol semantics) it  
> should work.
>
> To provide an extreme example of Barbara's conundrum: What if 911  
> called for a pizza in Greenland?  I assumed that this could be  
> addressed by UA configuration on a device that the user owns; that  
> is, they teach their UA to understand that 911 == urn:service:sos.   
> However, that doesn't work if they are visiting someone and just  
> pick up their host's UA.  It also doesn't work if you force LoST to  
> take priority.
>
> I agree though, forcing a series of questions for an emergency call  
> isn't a good idea.  We need a sensible default behaviour.  Perhaps  
> something along the lines of any service in the urn:service:sos*  
> path overrides any other service.

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 16 Jan 2008 16:31:36 -0600

Brian, I think that you misunderstood.  The LoST _is_ overriding configuration, but it is giving you pizza, not a PSAP.  You can't say that you definitely want a PSAP and have LoST override configuration at the same time.

As Henning has pointed out, this is not hypothetical.  Someone who is used to 118 for emergency is going to get directory services instead of a PSAP if LoST is given supreme powers of priority.

> Sent: Thursday, 17 January 2008 8:56 AM
> To: Thomson, Martin; 'Ted Hardie'; 'Stark, Barbara'; 'Spencer Dawkins';
> 'ECRIT'
> isn't
> > > > >them, and it gets them from LoST primarily.  There ARE other ways:
> it
> > > can
> > > > that the string isn't even found.  It consistently uses "dial
> string"
> > as
> > > > back a service Number with a LoST response and cannot use the URIs
> in
> > > the
> > > > URIs.  I think where we may disagree is what it does if it cannot:
> I
> > > > think either
> > > > and falls back to a circuit-switched call instead (e.g. 1xRTT).
> That
> > ,
> > > in
> > > > essence,
> > > > treats the service Number as both a dialstring and more-or-less as
> the
> > > > source
> > ------------------------------------------------------------------------
> --
> > ----------------------
> > ------------------------------------------------------------------------
> --
> > ----------------------
> > [mf2]
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 16 Jan 2008 16:34:07 -0600

I agree.  You'll hopefully only have a few seconds before you actually connect, but at least you can then quickly apologise (in an appropriately contrite tone, of course) to the PSAP operator and not waste PSAP resources.  Then you go looking for pizza in a phone book.

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, 17 January 2008 8:58 AM
> To: Thomson, Martin
> Cc: Brian Rosen; Ted Hardie; Stark, Barbara; Spencer Dawkins; ECRIT

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 16 Jan 2008 17:48:41 -0500

I had only meant "LoST overrides" to apply to emergency services.  If in
fact the visited directory service number is 116, and your home fire
emergency number is 1-1-6, and you dial 1-1-6 on your phone while visiting,
you probably should get fire.  I say "probably", only because I wished it
would work that way.  It's not really clear to me that it actually should,
because it means we need to have escape mechanisms.  After all, this is a
change from current practice.  Currently, the VISITED dial plan holds, not
the home dial plan, for most services.  Something like Vonage is an
exception of course.

I wonder if we can actually specify this.  We may have to leave it to
implementers.  Vonage's answer, who does not normally support the
visited/home idea may have different needs than a mobile phone system which
does.  Do we really even have to specify what happens when a visited dial
string is NOT an emergency number but it is in the home dial plan?  We DO
need to specify what happens when the dial string is an emergency number in
the local dial plan.

Brian

> Sent: Wednesday, January 16, 2008 5:32 PM
> Brian, I think that you misunderstood.  The LoST _is_ overriding
> configuration, but it is giving you pizza, not a PSAP.  You can't say that
> you definitely want a PSAP and have LoST override configuration at the
> same time.
> 
> As Henning has pointed out, this is not hypothetical.  Someone who is used
> to 118 for emergency is going to get directory services instead of a PSAP
> if LoST is given supreme powers of priority.
> 
> very
> called
> > > configuration on a device that the user owns; that is, they teach
> their
> > UA
> > > > Definitely agree users will dial numbers to reach emergency
> services.
> > > We
> > > > IFF the phone has an alternate way to place a call (use CS instead
> of
> > > PS)
> > > > it has to try to reach someone who can help.  I think that such
> cases
> > > are
> > > > The only way you can get to the situation where you have two URIs
> for
> > > the
> > > > Generally, making choices when you are stressed is usually NOT a
> good
> > > idea,
> > > > appropriate URI.  That may actually be of some use if we could get
> the
> > > UI
> > > > right.  All the URIs may actually resolve to the same domain, but
> the
> > > PSAP
> > > > However, it ONLY works if there is a clear rule for what the UA
> should
> > > do
> > > > > >> red button that says "call for help" in jurisdictions that have
> a
> > > > > single
> > > > >    ED-3 Endpoints SHOULD recognize dial strings of emergency
> calls.
> > > If
> > > > >    SP-2 Proxy servers SHOULD recognize emergency dial string if
> for
> > > some
> > > > > the device or the user should be able to take the service Number
> and
> > > > > attempt
> > > > > data connection that would normally complete this using SIP finds
> it
> > > > > cannot
> > > > > >> UI methods, it might in some cases create them.  That might be
> a
> > > drop
> > > > > >> down list, a voice prompt (now press one for fire, two for
> police,
> > > > > three
> > > > > >> matches the resulting service number or not, this is okay).
> But
> > if
> > > > it
> > > > > >> pre-loads this
> > > > > >Agree, but that's not the problem at hand.  The problem at hand
> is
> > > > having
> > > > > invocation used to make the call was just the dialed string, then
> I
> > > > would

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 16 Jan 2008 17:49:22 -0500

On Jan 16, 2008, at 5:31 PM, Thomson, Martin wrote:

> configuration, but it is giving you pizza, not a PSAP.  You can't  
> say that you definitely want a PSAP and have LoST override  
> configuration at the same time.
>
> As Henning has pointed out, this is not hypothetical.  Someone who  
> is used to 118 for emergency is going to get directory services  
> instead of a PSAP if LoST is given supreme powers of priority.

I think only the opposite can happen (get police instead of directory  
assistance), unless LoST service strings are used for directory  
services, for a yet-to-be-defined urn:service:directory. Also, the  
case only occurs if the pre-configured home emergency dial string  
matches another non-emergency services *and* the user dials that  
number while traveling, thinking they are getting the non-emergency  
service (e.g., because they saw it advertised in the front section of  
the phone book).

While this is a theoretical problem, I don't see it as a major one  
that needs fixing. The number of such cases seems small, given that it  
has to involve 3-digit numbers and tourists.

The 118 case is for Finland:
http://www.fonecta.com/directory_assistance/index.php

http://en.wikipedia.org/wiki/Emergency_telephone_number documents a  
number of uses of 118 for emergencies, for example, Switzerland and  
Bolivia.

Thus, a Bolivian tourist would have to come to Finland, want to get  
directory assistance and then find that his phone recognizes that as  
the home dial string for an ambulance.

If this is a problem, the only possible solution is to only recognize  
a few "universal" emergency numbers as home dial strings (112, 911)  
and make sure that no other non-emergency service uses those numbers.  
As I mentioned before, 112 pretty much has achieved that status -  
you're going to be lonely repairman if you advertise that number for  
your plumbing service.

The problem of having a single dial string for multiple emergency  
services (sos, sos.police) is a separate one.

Henning

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 16 Jan 2008 17:00:36 -0600

It sounds like both you and Henning are saying the same thing.  And it sounds OK to me:

_Emergency_ numbers in the local dial plan overrule all else.

We'll ensure that LoST rules supreme for those.  Do you want a specific order?  i.e.

Emergency (Local, from LoST)
Emergency (Home)
Other...

> Sent: Thursday, 17 January 2008 9:49 AM
> > > > to understand that 911 == urn:service:sos.  However, that doesn't
> work
> > > if
> > > > along the lines of any service in the urn:service:sos* path
> overrides
> > > any
> > > > other service.
> > > >
> > > > _M
> > > >
> > > > > AND its PS mechanisms fail, then indeed it could use any of the
> dial
> > > > > strings
> > > > > pretty much restricted to IMS systems, and I don't think we need
> to
> > > > spend
> > > > > I think those cases are rare enough that we don't need much
> guidance
> > > > (like
> > > > > work, and it would be possible to generate a UI that allowed a
> user
> > to
> > > > > choose police/fire/ems or overall emergency, with the call going
> to
> > > the
> > > > > > > > I think you have the mapping wrong.  The 911 string dialed
> by
> > > the
> > > > > > >> user is the UI invocation; it's the 3-button equivalent of
> the
> > > big
> > > > > > >> and a service urn of sos (unadorned, since 911 is general).
> It
> > > > > should
> > > > > > >> that the device can use one of those URIs, it would then
> invoke
> > > the
> > > > > > >The numbers came from LoST.  For the phone to recognize them,
> it
> > > has
> > > > to
> > > > > > have
> > > > > > Second, if I understood Barbara right, she saying that what
> users
> > > will
> > > > > > do on phone is mostly dial numbers; I agree with that, and I
> think
> > > > > > phonebcp
> > > > > >    ED-4/SP-3 Emergency calls MUST be marked with a Service URN
> in
> > > the
> > > > > > > > It might also add the service numbers to a list of patterns
> in
> > > > looks
> > > > > > and the contact URIs returned in the set are the same, there is
> no
> > > > > > fundamental
> > > > > > that because there is no dialstring possibility doesn't make
> sense
> > > to
> > > > > > me.  People may *mostly* use dialstrings on phones, but there
> are
> > > more
> > > > > > >it's a problem to have more than one service URN map to the
> same
> > > > > service
> > > > > > >number.
> > > > > > >
> > > > > > >Brian
> > > > >
> > > > >
> > > > --------------------------------------------------------------------
> --
> > --
> > > --
> > > > ----------------------
> > > > --------------------------------------------------------------------
> --
> > --
> > > --
> > > > ----------------------
> > > > [mf2]
> > >
> >

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Thu, 17 Jan 2008 09:35:10 +0100

James,

I'm glad my initial question is clear now.

> is a local jurisdiction issue - which will have different outcomes

At least there should somewhere be a note that it may happen to have
the same service number for more than one service - if you allow that
at all. Otherwise implementers won't consider this case.

> contacted to best serve the UA's situation).

This was also somehow my expectation. But the LoST Server
implementation by Columbia university shows this data I provided in
the initial example. So I thought this sample data would represent the
way how LoST servers will be provisioned in the US.

cheers,
karl heinz

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Thu, 17 Jan 2008 10:27:49 +0100

Thank you all for your comments.

I started this topic because I'm working on an implementation. A few
days ago, I found the web page of the columbia university LoST server,
and I was curios if my implementation would work with that server. I
did not consider the case that there might be multiple services with
the same service number before. So when I used the LoST server, and
ask my implementation for the 911 mapping it always gives me the last
mapping I performed with LoST findService. When the last query was for
sos.police, I would be connected to the police. Was the last mapping
done for sos.fire, it get the fire uri back. I'm afraid every
implementation would do something different.

So it believe it is necessary to say somewhere:

- is it allowed to have multiple services with the same service number
in the LoST database
- does urn:service:sos always have to exist even though there are
child services?

I'm not sure that voice prompts or drop downs to choose a service are
a good idea. What about analog telephone adapters and language
problems even starting before connecting to a PSAP?

And please do not forget my question about listServicesByLocation.

cheers
karl heinz

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Thu, 17 Jan 2008 10:36:23 +0100

> from configuration and it still gives you service number to service URN.

just one question on that: is it allowed to have more than one
<serviceNumber> Element in LoST? It is defined as optional in the XML
schema - so there may be zero or one servicenumber element. Is this
correct?
so, how do you get both numbers from LoST?

cheers,
karl heinz

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 18 Jan 2008 07:57:05 -0500

Ted,
I believe I understand your point, now.

It sounds like you're saying:
If the device recognizes a dial string / service number as being
associated with a service urn (either through LoST or configuration),
but does not have a routing uri that is usable by a client on the
device, then the device ...

I can see several ways to come at the question of what "..." is.
In phonebcp, there is a requirement that in the absence of a uri, the
SIP client will go ahead and send a SIP INVITE with just the service
urn. If there is no service urn, then the INVITE is sent with the dialed
digits. If we see the case you describe as being a subset of cases where
there is no SIP routing uri, then this requirement would apply.

But it sounds like you want a different requirement. You seem to be
saying that if there is no (usable) uri for the Route header, then a
device needs to see if it has a uri that is usable by a different client
(and use that if it does); and if it doesn't, but it has a non-IP
interface that supports outbound calls, then it should send the call out
that interface (using the dialed digits, unless there is some mapping
unique to that outbound call interface that says "map these dialed
digits or service urn to dial string <xyz>").

I think that for a LoST server to be configured to know valid service
urns and service numbers, and be able to validate a location, but not
have SIP routing URIs would be a really bad thing. Since a LoST server
cannot know whether or not the device requesting info also has another
outbound calling interface, the data in the LoST server must always
include SIP routing info. To do otherwise, would be severely negligent
on the part of the LoST provider, IMO.

Which means that our device requirements should be able to assume that a
LoST server provides SIP URIs. 

This means that the device of interest (one that got a LoST response
without a usable uri) would be one which doesn't have a SIP client, but
does have other clients and has an outbound non-IP calling interface.
Phonebcp doesn't really address such a device. Since SIP can do voice,
video, and text, it's not clear to me why we need to spend time on such
a device.

If we're looking for a way to make sure that emergency calls go over
GSM/CDMA, when a cellular device is unable to get its location and/or
emergency routing info, I think that such requirements need to rest with
3GPP/3GPP2.
Barbara

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Wednesday, January 16, 2008 2:41 PM
To: Brian Rosen; Stark, Barbara; 'Spencer Dawkins'; 'ECRIT'
Subject: RE: [Ecrit] Services with same Service Number

do on phone is mostly dial numbers; I agree with that, and I think

Where I have been focused in this discussion is on what a device does if
it gets
back a service Number with a LoST response and cannot use the URIs in
the
set that is returned.  I think the what it does if it *can* is clear:
it uses those
URIs.  I think where we may disagree is what it does if it cannot:  I
think either
the device or the user should be able to take the service Number and
attempt
to make a call (either on that phone or another) using just the service
Number.
The particular case in my head is the one where a device with a cellular
data connection that would normally complete this using SIP finds it
cannot
and falls back to a circuit-switched call instead (e.g. 1xRTT).  That ,
in essence,
treats the service Number as both a dialstring and more-or-less as the
source
of a constructed Tel URI. 

whether we
do or do not.

<snip>

it
>9-1-1 map to urn:service:sos AND having 9-1-1 map to
urn:service:sos.police.

If 9-1-1 maps to urn:service:sos and 9-1-1 maps to
urn:service:sos.police
and the contact URIs returned in the set are the same, there is no
fundamental
problem.  The call still completes and gets to the right place.  If the
UI
invocation used to make the call was just the dialed string, then I
would
say that the top-level of the hierarchy should be used (urn:service:sos
rather than urn:service:sos.police) as an indicator. 

If 9-1-1 maps to urn:service:sos and 9-1-1 maps to
urn:service:sos.police
and the contact URIs returned in the set are not the same, I believe
the sensible thing to do for a UI invocation based on the dial
string only is to route to urn:service:sos; it's the top of the
hierarchy
and if you have no other input, that's what you use.  But if there
is another way to make the selection (drop down, voice prompt,
etc.), you might allow that to make a direct selection of the
urn:service:sos.police choice, and then route directly there.
Forbidding
that because there is no dialstring possibility doesn't make sense to
me.  People may *mostly* use dialstrings on phones, but there are more
capable devices out and allowing them to make more precise choices
seems reasonable to me if it does not prevent the base case from
working.

				regards,
					Ted

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

---

From: Ted Hardie <[email-masked]>
Date: Fri, 18 Jan 2008 08:58:47 -0800

>device, then the device ...

It's important to recognize that this may "that is usable by a client
on the device at that moment".  There may be cases where the client
has SIP but cannot make either a connection to a SIP proxy or
directly to the SIP interface of the PSAP.  That might be something
as simple as a temporary error in a firewall config or something
as deliberate as someone DDoSing the SIP interface of the PSAP.

>there is no SIP routing uri, then this requirement would apply.

It's difficult for to understand the case where there is no service URN,
but I think using the dialed digits here is very similar to saying that
you can treat the "service number" returned as the source of
a constructed Tel: URI.  That means any interface  you have (whether
it be SIP or something else) might try that constructed Tel: URI.

>digits or service urn to dial string <xyz>").

Yes.  This is obviously not a first choice, but if you've gotten back
a service Number and you have other clients/non-IP interfaces,
trying that number on those interfaces makes sense.

>LoST server provides SIP URIs.

See above.  It's not about whether the LoST server provides SIP URIs; it's
about whether the client can use them.  A bad firewall config, a DoS
attack, and client update/virus that munges the SIP client can all
temporarily blank the usability of that URI.  If we're providing additional
data (the service Number), treating it as usable for more than a UI
matching algorithm makes sense to me.

>emergency routing info, I think that such requirements need to rest with

Devices that have more than one interface are now common, and they may
get more common; folks that have more than one device are really, really
common.  Some of those devices and interfaces can make phone calls without
SIP.  Let's recognize that fact.

				regards,
					Ted