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

[Henning Schulzrinne <[e-mail]>]

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

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

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


_______________________________________________
Sipping-emergency mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-emergency