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

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 06 Jun 2006 21:36:40 +0000

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 06 Jun 2006 18:35:28 -0400

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

---

From: Brian Rosen <[email-masked]>
Date: Wed, 7 Jun 2006 01:28:21 -0400

I prefer to be explicit rather than implicit, but I don't care that 
much.

Brian