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

From: "Roger Marshall" <[email-masked]>
Date: Wed, 7 Jun 2006 14:59:12 -0700

Henning:
See response in-line.  Thanks.

>-----Original Message-----
>From: Henning Schulzrinne [mailto:[email-masked]] 
>Sent: Wednesday, June 07, 2006 2:13 PM
>To: Roger Marshall
>Cc: LoST Issue Tracker; [email-masked]
>Subject: Re: [Ecrit] [issue9] LoST Response with PSAP Preference
>
>
>
>Roger Marshall wrote:
>
>> In addition to basing the ordered list on location, there 
>may be other 
>> preferential information to consider, such as the inclusion 
>of special 
>> attributes (similar to a web server receiving accept-encoding(?) 
>> headers
>
>Accept-encoding (and the other Accept-* headers) are all query 
>headers that guide the server in returning one object. HTTP 
>does not deliver a bag of responses.
>
>> from a web client).  Though these may not always apply, these 
>> shouldn't be precluded from being allowed in the protocol, 
>since they 
>> could be used in the future to support the following use cases:
>> 
>> 1. ) Ability to differentiate between fixed and mobile subscribers.
>> Some PSAPs today support mobile calls, while others don't.  This is 
>> largely a result of PSAP equipment capabilities and training, and 
>> won't be suddenly remedied any time soon for IP-based calls.  There 
>> may be a need to have the LoST server return a PSAP URI 
>appropriate to 
>> the type of call being made - whether fixed, or mobile.
>
>This seems like a query parameter, rather than offering the 
>client a whole list of choices. (If the client knows the 
>difference between mobile and not, it can presumably indicate 
>which answer it is looking for.)
>

Agree.

>
>> 
>> 2. ) Public jurisdictional conflicts.  A person is walking onto a 
>> college campus, when she is unexpectedly injured.  A witness 
>makes an 
>> emergency call from a campus installed emergency phone, while the 
>> injured person makes an emergency call from her cell phone.  Campus 
>> personnel show up, followed by other off-campus (e.g. county) 
>> emergency personnel.  Despite having plenty of assistance, extra 
>> resources weren't really necessary in this case.  In addition, total 
>> available emergency service capacity was reduced, and extra 
>cost was incurred.
>
>I'm unsure as to how this can be resolved by a location 
>mapping protocol, as opposed to some backend coordination 
>protocol where the campus police tells the city police which 
>incidents its currently working on. Location information 
>itself clearly isn't sufficient to know that these two 
>incidents are the same - the second caller could be calling 
>about the building that's on fire...
>

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. 

>
>
>> 
>> 3. ) Private jurisdictional conflict.  Same as above, except this 
>> time, applied to a corporate campus which experiences a minor hazmat 
>> spill.  A call for 9-1-1 should get the corporate hazmat team, but 
>> instead results in the county fire trucks arriving at the company's 
>> front gate without the company having prior knowledge which 
>would have 
>> been  necessary to deal with the problem.  Large companies usually 
>> like to field emergency calls first, so they can invoke 
>their own processes first.
>
>At least in my model of how LoST would work, the company could 
>either "carve out" a particular area where it is the "PSAP" 
>(presumably with permission of the local jurisdiction) or the 
>outbound proxy/ESRP does the appropriate routing.
>

I agree that coordination is the best policy, still I don't see this as
much of a "carving out" into a separate boudary, as much as of a 2nd
tier "overlaid" choice for routing (used as a fallback), so again, the
LoST response could order appropriately.  I don't really think there is
any real disagreement here.

>
>> 
>> I proposed that LoST clients may be allowed to include special 
>> attributes (not defined here, but which may be defined later) in the 
>> LoST request.  I would also say that the requirement for the LoST 
>> server is that they could ignore these special attributes.
>
>I agree that we should be able to include additional query 
>attributes beyond the service identifier and location. As with 
>most extensions, there are probably two options:
>
>- ignore if you don't understand them (and maybe indicate the 
>ones the server did take into account)
>- refuse the request if a server doesn't understand a 
>particular qualifier
>
>For simplicity and because of the nature of what we're trying 
>to do, I'm inclined to only support the former.
>

Agreed.

-roger.

>> Roger Marshall

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 07 Jun 2006 18:08:09 -0400

> 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