[Sipping-emergency] Re: Emergency-req: 8-12

At 08:00 PM 2/22/2003 -0500, Henning Schulzrinne wrote:

>>    - Proper call routing to the PSAP(based on caller location)
>>    - The call
>>    - Any priority flags
>
>Since the call is already identified as an emergency call, I don't see the 
>need for any additional flags. (Adding such a flag mechanism would 
>introduce additional attack vectors, for example.)

I'm not proposing them, but they still might become a requirement from the 
jurisdiction. My list above was a possible projection of what an IP list 
could look like. I believe the priority flag was and is mentioned not as 
expected, just possible (that's why I use the word "any" - if there aren't 
any, you can't include them)

>>    - The location of the caller
>>    - A valid (should be verifiable) Contact Header (or mandatory Via 
>> header of the UAC and any/all Proxies involved in the call routing) for 
>> callback
>
>These items are enumerated in the beginning of the end-to-end section. 
>They do not apply to the last-mile architecture.

Fair. I believe you can use them how you like. If you believe this list (or 
the section half of the whole list) is applicable to only the e2e section, 
then by all means include what you feel is appropriate. I was only offering 
a list, not 'the' list.

>>What's not so obvious is whether there needs to be further (any?) 
>>security involved that could fail the call. If security considerations 
>>are necessary, with the full realization that the emergency call could 
>>fail if they are not met, then the following is the minimum to be 
>>included in the list above:
>>    - Assurance that none of the signaling (headers) have been munged"
>>This is from my unpublished framework ID on this subject, but it could be 
>>easily used in this doc. I would stress that at least the first 3 bullets 
>>are included here, as this is exactly what PSAPs want today.
>
>Noted. Added 'integrity' under call setup.
>
>>#9 - From section 5
>>"End-to-end emergency calls originate on an Internet device, traverse IP 
>>networks and terminate on an IP capable ECC (IECC)."
>>Comment: this can be a moderately misleading statement. The most likely 
>>event or infrastructure will have the Emergency call hit the first Proxy 
>>and then travel straight to the local IECC (and not across the Internet - 
>>which most people define as traffic passing between two Tier 1 ISPs).
>
>Where is that Internet definition from?

Patrik Fältström is one of my coworkers who is part of this discussion 
within Cisco frequently. This is his tenuous definition - though he speaks 
it not in the absolute sense, but hesitantly as it hasn't been agree upon 
anywhere in the community. My use it as a guide, though opinions vary 
(obviously).

>I would define anything that's on an IP network connected to the global 
>Internet as an Internet device.
>
>>If the Proxy is not local to the UA, then the issue of how this non-local 
>>proxy will know where the local PSAP is relative to this UA making the 
>>emergency call.
>
>Indeed.
>
>>#10 - From Section 5.2, 2nd sentence:
>>"... ECCs only serve a small region ..." This isn't true in London that I 
>>know of. I don't know the exact nature of other major cities in Europe of 
>>Asia. Regardless, this statement made is not universally true, and has a 
>>major example where it isn't. Text couching this statement is recommended.
>
>removed 'small'
>
>>#11 - From section 5.2, 2nd paragraph, 3rd sentence:
>>"In caller-based resolution, the caller's UA consults a directory and 
>>determines the correct IECC based on its location."
>>Comment: This is omitting the possibility of a Geopriv WG ID (you're 
>>aware of) and another ID you wrote in which the UA could have its 
>>location "feed" to in upon boot-up (via DHCP). Both IDs state that if the 
>>UA has its Geo-Loc present in the UA, some future functionality in SIP 
>>(not defined yet) could include the location information in a Header or 
>>MIME body, and not need this look-up (nor does it have to determine 
>>anything - as the location information is "just there" in the UA.
>
>Note that the text speaks of finding the correct IECC, not of determining 
>the location. The idea is that if a UA knows its location (via whatever 
>means, including the ones you mention), it can directly query a 
>location-to-IECC mapping service and then contact the IECC.

But.... doesn't the UA *not* know the IP address of the PSAP? If it doesn't 
in the INVITE, then the Proxy has to direct the INVITE (with the sos@) 
towards the proper PSAP. This will require the Proxy to know which PSAP to 
do to (unless there is only one in the area - in the case of a large 
regional service). Maybe I'm missing something...?

>This model has trust advantages since the UA can choose whatever mapping 
>service it considers trustworthy ahead of time, get back a reply it can 
>trust (since it presumably has made sure it's talking to the right 
>directory service) and can then easily use standard server authentication 
>mechanism to detect that it is indeed talking to the desired IECC. This 
>makes the trust problem much more tractable. In effect, the caller gets to 
>choose its "PSAP certifying authority" without every PSAP having to be 
>accredited by one certifying authority.

That will never happen

>I'm hoping that this type of mechanism is both implementable and can allay 
>the fears of Jon of talking to the corner PSAP run by the Sopranos.
>
>
>>#12 - also from section 5.2, 2nd paragraph, last sentence:
>>"(It appears undesirable to have either the UA or every outbound proxy 
>>server contain a copy of
>>the location-to-ECC mapping since this table changes frequently.)"
>>Question: How often do any of these stated 5000 PSAPs move (as you elude 
>>to with this above comment)?
>
>I hope you don't expect me to know that :-) I suspect that they don't move 
>often, but consolidations, in particular, seem not uncommon. Also, you'd 
>not only need all 5,000 US PSAPs, but every PSAP-equivalent in the world. 
>Since you probably don't want to download the whole table over a wireless 
>interface each time two PSAPs merge, you then need a synchronization 
>mechanism.

how hard would this be to include in something like a DHCP configuration 
download? Or have the UA periodically do something like an OPTIONs query to 
the Proxy it knows, and exchange the necessary information to learn the 
available choice in the background.

>I suspect this can all be done (after all, this isn't all that different 
>than downloading a version of Zagat's on your PDA and there are lots more 
>restaurants in NYC than they are PSAPs, I suspect...), so I'll mention it 
>as a possibility.
>

cheers,
James

               *************************************
"People generally demand more respect for their own rights than
                          they are willing to allow for others"

_______________________________________________
Sipping-emergency mailing list
Sipping-emergency@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-emergency