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

From: "Roger Marshall" <[email-masked]>
Date: Wed, 7 Jun 2006 16:01:05 -0700

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

>-----Original Message-----
>From: Henning Schulzrinne [mailto:[email-masked]] 
>Sent: Wednesday, June 07, 2006 3:08 PM
>To: Roger Marshall
>Cc: LoST Issue Tracker; [email-masked]
>Subject: Re: [Ecrit] [issue9] LoST Response with PSAP Preference
>
>> The question then is whether the campus wants to be the 
>first to know 
>> about the fire (to evacuate), or the local jurisdiction (to roll 
>> trucks).  I think all I'm trying to say is that the LoST protocol 
>> should support ordering, and to point out a use case wherein it may 
>> need to be configurable based on location.
>
>This goes back to my earlier note. When getting these two 
>URLs, what would a client do with this? Would you indicate
>
>"if you don't like the amateur cops from the University 
>[URL1], please call the real ones from the NYPD [URL2]"
>
>?
>
>Or would you always indicate a hierarchy of services, as in
>
>campus police
>NYPD
>NY state troopers
>FBI
>
>Since this mapping is for the PSAP, not the actual first 
>responders, I always thought it was the job of the campus PSAP 
>to decide whether to call in the city cops. At least, this is 
>how it works on our campus (for on-campus calls).
>
>Henning
>

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 7 Jun 2006 20:07:37 -0400

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.

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 8 Jun 2006 03:47:05 -0400

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