Subject: [Ecrit] draft-rosen-sos-phonebcp

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 01 Mar 2006 16:31:46 -0500

I'm delighted to see this draft be written - it fills one of the major 
open work items that ECRIT, in my opinion, needs to address.

One trivial item: It's a URN, not urn. The latter is what you may need 
when the emergency service fails.

> It is desirable for the endpoint to do the mapping from location to
>    PSAP URI.  This will allow for a fallback map to be know.  It is
>    desirable for the first active signaling element (first hop proxy for
>    SIP) to do an [ecrit] mapping as well, as this will be the freshest
>    and most up-to-date URI of the appropriate PSAP.  If the device
>    included a PSAP URI from fallback mapping in the SIP INVITE, the
>    first SIP element SHOULD do its mapping and use this result to
>    forward the message towards the PSAP.  The fallback mapping's purpose
>    is in case the SIP element's mapping failed, the element would have a
>    route already in the message, just not one that is the freshest.

I think this can be clarified significantly. I don't see, for example, 
why a proxy would have a "fresher" URI. (I've written about my concerns 
regarding the need for a DHCP solution elsewhere.)

This all seems fairly simple: A UA that does resolution gets a new 
mapping whenever the mapping expires or the UA moves out of the coverage 
region specified in the mapping response (see the LoST draft).

Thus, a simple version of 6.2 is:

-- begin send-text ---

User agents that can obtain location information MUST perform the 
mapping from location information to PSAP URI using [LoST]. The mapping 
is performed whenever the UA acquires new location information that is 
outside the bounds of the current PSAP coverage region specified in the 
LoST response or the time-to-live value of that response has expired.

To deal with old user agents that predate this specification and with 
UAs that do not have access to their own location data, proxies that 
recognize a call as an emergency call that is not marked as such (see 
Section XXX) or where the request URI is a service:sos URN MUST also 
perform this mapping.

A UA MUST perform a mapping when placing an emergency call. If the 
mapping protocol does not return an answer within 500 ms and the UA has 
cached a PSAP URI from the mapping operation described above, the UA 
MUST use that cached PSAP URI value to place a call.

-- end send-text --

It seems to be that we want to make this process as simple and 
predictable as possible, removing deployment variability. I don't want 
the equivalent of "I thought *you* were going to take care of this". In 
a separate thread on the SIPPING list, there is a discussion on the 
evils of SHOULD; this applies here as well, not just in this paragraph.

Henning

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

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 01 Mar 2006 16:02:54 -0600

>open work items that ECRIT, in my opinion, needs to address.

2+ years of discussion and 3 days of writing will get you an ID (sometimes)...

We should have written this a looong time ago.

>One trivial item: It's a URN, not urn.

There are a few lower case acronyms and words that ought to be uppercase, 
including a few "shoulds" and "musts".  We'll fix that in the next version.

>The latter is what you may need when the emergency service fails.