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

From: "Roger Marshall" <[email-masked]>
Date: Thu, 8 Jun 2006 13:51:44 -0700

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

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 8 Jun 2006 17:20:36 -0400

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.
> 
> 
> Internet 
> >access.
> has to be a 
> >uniform rule.  The campus notifies the PSAP or the PSAP notifies the 
> >campus.
> >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.
> >
> location 
> >in the database.  That entity gets to choose what goes in there.
> >
> >Brian
> >
> >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.
> >