Subject: RE: [Ecrit] [issue9] LoST Response with PSAP Preference

From: "Roger Marshall" <[email-masked]>
Date: Thu, 8 Jun 2006 14:34:30 -0700

Marc:
Don't laugh too much, the requirements draft has text that already comes
close:

(Step 3, following Figure 1.)

"(3) The emergency caller might need to consult a mapping service to
determine the PSAP (or other relevant information) that is appropriate
for the physical location of the emergency caller, possibly considering
other attributes such as appropriate language support by the emergency
call taker."

-roger.

>-----Original Message-----
>From: Marc Linsner [mailto:[email-masked]] 
>Sent: Thursday, June 08, 2006 2:21 PM
>To: Roger Marshall
>Cc: [email-masked]
>Subject: RE: [Ecrit] [issue9] LoST Response with PSAP Preference
>
>Roger, 
>
>We have NOT seen a requirement for different routing for the 
>same location.
>
>Your example #1 is a legacy problem due to inferior mechanisms 
>in cellular end-point location.  As you well know, (almost) 
>all cellular calls are routed based on cell tower location, 
>not caller location.  In example #1, the cell tower that is 
>utilized at the airport most likely covers an area of the 
>county outside the airport.  Since the airport PSAP can't 
>handle emergencies outside of the airport, the only logical 
>choice is to route
>*all* calls from that particular cell tower to the county.  
>There is nothing the IETF can do to enhance cellular endpoint 
>location timing, the root of the real problem here.  As you 
>noted, wireline phones within the airport are routed properly 
>to the airport PSAP.
>
>So the point is that LoST will handle your airport example, 
>given that the LoST client knows where he is located in the 
>time envelope of a 911 call setup.
>
>With regards to your second example, maybe we should add 
>ethnicity tags to LoST??  (just kidding!)
>
>-Marc-
>
>
>
>> 
>> I would agree that emergency context routing would be easier 
>IF there 
>> were always only one call center for a given location, but I 
>> anticipate that in some areas this will never be the case.  Nor do I 
>> believe that an assortment of dial strings will make the problem 
>> simpler for the user.
>> 
>> Example_1, today the airport announcements that bellow, "If you have 
>> an emergency, call '9-1-1'", which summons airport personnel, not 
>> county - whereas if you dial '9-1-1' on your cell phone while in the 
>> same airport, you get the county PSAP.  I don't think the 
>airport will 
>> change their policy, and I would hope that a mobile location based 
>> query to LoST returns the Airport's URI for all cellular 
>calls made on 
>> the premises, but it may never happen (I'm guessing that the county 
>> would probably NOT want to give up ownership over this airport 
>> (cellular), or any number of corporate or university campus sites as 
>> well.
>> 
>> Example_2, The previously used Gaza strip example, if a 
>person made an 
>> emergency call for help while visiting Gaza, there may be a 
>> user-preferred question as to which Emergency Svc is 
>summoned, PLO or 
>> the Israeli, depending on the person's citizenship.
>> 
>> Maybe this problem of jurisdictional boundary overlays won't 
>be solved 
>> by some fancy feature in the LoST protocol in the short term, but I 
>> predict that it won't just go away.
>> 
>> -Roger.
>> 
>> 
>> >-----Original Message-----
>> >From: Brian Rosen [mailto:[email-masked]]
>> >Sent: Thursday, June 08, 2006 12:47 AM
>> >To: 'Henning Schulzrinne'; Roger Marshall
>> >Cc: [email-masked]
>> >Subject: RE: [Ecrit] [issue9] LoST Response with PSAP Preference
>> >
>> >Sorry to chime in late here; I'm in Europe with intermittent
>> Internet
>> >access.
>> >
>> >This whole line of thinking is incorrect in my opinion.
>> >
>> >There can only be ONE call center that takes the call. 
>> > 
>> >It cannot be the caller's opinion which one that is.  There
>> has to be a
>> >uniform rule.  The campus notifies the PSAP or the PSAP 
>notifies the 
>> >campus.
>> >They have to agree on the rule.
>> >
>> >There may be a need for a mechanism whereby one entity notifies the 
>> >other entity, but that is outside the scope of ecrit right now.
>> >
>> >There is only one entity that populates the data for a given
>> location
>> >in the database.  That entity gets to choose what goes in there.
>> >
>> >Brian
>> >
>> >-----Original Message-----
>> >From: Henning Schulzrinne [mailto:[email-masked]]
>> >Sent: Wednesday, June 07, 2006 8:08 PM
>> >To: Roger Marshall
>> >Cc: [email-masked]
>> >Subject: Re: [Ecrit] [issue9] LoST Response with PSAP Preference
>> >
>> >Storing user profiles on LoST servers hasn't really been 
>part of the 
>> >discussion so far.
>> >
>> >I wonder if there's a simple label we can apply to URLs, such as 
>> >"public" and "private" or "campus" (and maybe a
>> human-readable string
>> >since the decision which to call seems rather hard to
>> automate). By the
>> >way, the dial strings for each such service would also 
>likely differ.
>> >
>> >That, however, seems to be a somewhat different issue from using 
>> >multiple URLs for fail-over routing. It seems unwise to
>> commingle the
>> >two issues.
>> >
>> >On Jun 7, 2006, at 7:01 PM, Roger Marshall wrote:
>> >
>> >> When walking onto a campus, a call for emergency services
>> shouldn't
>> >> result in two different scenarios, depending on which 
>device/media 
>> >> you're using.  Though this is what happens in today's
>> world.  Today,
>> >> PSAP routing is inconsistent by technology, (you get campus
>> >PSAP when
>> >> using wired vs. city PSAP when using wireless).  I think the 
>> >> inconsistency should be fixed and it seems to me that LoST
>> >could help
>> >> fix it.
>> >>
>> >> I'm not promoting call-time user interaction with the
>> >returned set of
>> >> URIs, but rather when multiples are returned, that the
>> >device selects
>> >> the first one, and if for some reason it doesn't work, then
>> >the device
>> >> selects the second URI to route the call.  The order in
>> >which the URIs
>> >> are returned is a LoST Server setting (based on jurisdiction 
>> >> agreement).
>> >>
>> >> On the other hand, it now also occurs to me that we might want to 
>> >> consider a user specified profile driven return order
>> under certain
>> >> circumstances (let's say there is no way you want campus 
>police to 
>> >> come to your aid).  This one would probably be less
>> >controversial in a
>> >> commercial context for example, where you might want to
>> exclude one
>> >> brand of gas station from being included in the returned
>> list (e.g.,
>> >> since they had a worse track record with oil-spills).
>> >>
>> >>
>> >> Roger Marshall
>> >>
>> >
>> >_______________________________________________
>> >Ecrit mailing list
>> >[email-masked]
>> >https://www1.ietf.org/mailman/listinfo/ecrit
>> >
>> >
>> 
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/ecrit
>

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

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 8 Jun 2006 20:42:31 -0400

I have been a little concerned about disputed territory for a couple of
years now.  I don't think it's a big problem, but it's a problem.  My
preferred solution is to supply the country name in the location.  That will
disambiguate any disputed territory issues.

Brian

-----Original Message-----
From: Roger Marshall [mailto:[email-masked]] 
Sent: Thursday, June 08, 2006 5:35 PM
To: Marc Linsner
Cc: [email-masked]
Subject: RE: [Ecrit] [issue9] LoST Response with PSAP Preference

Marc:

-roger.

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 8 Jun 2006 19:46:02 -0500

Brian,

Have you just provided us with another possible use for composite (civic+geo) location information?  c.f. Henning's email on issue 2. 

> Sent: Friday, 9 June 2006 10:43 AM
> To: 'Roger Marshall'; 'Marc Linsner'
> Cc: [email-masked]
------------------------------------------------------------------------------------------------
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]

---

From: John Schnizlein <[email-masked]>
Date: Thu, 8 Jun 2006 20:56:28 -0400

How does a host with cellular network access (and its best location 
estimate) know which side of the wall/fence it is on along the winding 
boarder between Israel and Palestine?

Seriously, (although I can appreciate the use of humor) the fantasy 
that any protocol or effort of the IETF can resolve issues inherent in 
disputed territory should not influence our technical effort.

John

On Jun 8, 2006, at 8:46 PM, Thomson, Martin wrote:
>
> Have you just provided us with another possible use for composite 
> (civic+geo) location information?  c.f. Henning's email on issue 2.
>
>> preferred solution is to supply the country name in the location.  
>> That
>> will disambiguate any disputed territory issues.
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 8 Jun 2006 20:56:47 -0400

A different solution for the "East Jerusalem" problem is that the  
service provider routes the LoST request to the politically  
appropriate venue. An Israeli service provider and a Palestinian one  
would have different boundaries in their database. (Maybe that  
boundary would depend on whether the server is affiliated with Hamas  
or Fatah...)

The problem with the country code is that an end system using GPS has  
no way to obtain such a code automatically. You'd have to assume that  
ISPs would provide country code information via DHCP, say.

On Jun 8, 2006, at 8:46 PM, Thomson, Martin wrote:

>> will
> [mf2]_______________________________________________
> Ecrit mailing list
> [email-masked]