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

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

I can agree that when multiple URIs are returned that they be returned
per an ordered list, (based on resiliancy considerations more than any
other thing), but in addition, I propose the following:

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
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.

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.

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.

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.

Roger Marshall

>-----Original Message-----
>From: Henning Schulzrinne [mailto:[email-masked]] 
>Sent: Tuesday, June 06, 2006 3:35 PM
>To: LoST Issue Tracker
>Cc: [email-masked]
>Subject: Re: [Ecrit] [issue9] LoST Response with PSAP Preference
>
>At least in SIP, preference values have been of little use, as 
>there's little information to be gleaned from this, beyond 
>some rough order. (If somebody labels two servers as 0.5 and 
>0.6, is this any different from
>0.3 and 0.4 or 0.01 and 0.02?)
>
>My concern is that this creates essentially four layers of 
>selection and choices in the overall resolution process:
>
>- LoST
>- DNS NAPTR (for SIP)
>- DNS SRV (also for SIP)
>- SIP redirection and proxying at a PSAP server
>
>Do you try all instances of SIP servers in the NAPTR records 
>for the first LoST record first or do you go to the second 
>LoST record if the first NAPTR record fails (no SIP response)? 
>Do you go to the second LoST record if the first PSAP is busy? 
>Should you go to the second LoST record because your ping time 
>to that PSAP (server) is better?
>
>I'm neutral on having multiple URIs, in the ordered-list 
>manner Hannes suggested, but the behavior and interaction with 
>the other mechanisms would need to be very clearly defined. 
>For example, I think that emergency fail-over is better 
>handled at the SIP redirection layer, where you simply put a 
>set of backup proxies somewhere and list them last in the SIP 
>NAPTR/SRV lists. This avoids all caching issues.
>
>An example of something to avoid: If the server inserts the 
>second URL believing that this is only the 
>absolute-last-choice leading to a national call center in some 
>bunker in South Dakota, and the caller picks URLs by ping 
>time, the result may not exactly be what we'd want.
>
>
>Henning
>
>Hannes Tschofenig wrote:
>> New submission from Hannes Tschofenig <[email-masked]>:
>> 
>> Roger indicated that the LoST response would provide a preference 
>> value attached to each URI. See 
>> http://www1.ietf.org/mail-archive/web/ecrit/current/msg01937.html
>> 
>> Does someone have more information about the usage scenario?
>> If we return multiple URIs cannot we just use the first one in the 
>> list as the preferred one (primary contact) and the rest as 
>alternate contact URIs?
>> 
>> ----------
>> assignedto: hannes
>> messages: 22
>> nosy: ecrit, hannes
>> priority: critical
>> status: unread
>> title: LoST Response with PSAP Preference
>> 
>> __________________________________________________
>> LoST Issue Tracker <[email-masked]> 
>> <http://www.tschofenig.priv.at:8080/lost/issue9>
>> __________________________________________________
>> 
>> _______________________________________________
>> 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: Henning Schulzrinne <[email-masked]>
Date: Wed, 07 Jun 2006 17:12:48 -0400

> 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.

> 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.)

> 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...

> 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.

> 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.