Re: e911 and other regulatory req's? WAS: Re: Mozilla/Cisco API Proposal

On Tue, Jul 26, 2011 at 8:46 AM, Harald Alvestrand <

> At Saturday's F2F meeting, Cullen clarified that he intended the E911
> reference as an additional scenario where you needed the ability to say
> "capture the sound environment" rather than "optimize for voice".
> The people present concluded that the requirement is better captured by
> adding a "live music playing" scenario to the scenarios document than by
> adding an "emergency response" use case; E911 requirements are simply a too
> large can of worms, and most of them are probably irrelevant to what should
> go into the browsers; if relevant at all, they are relevant to the service
> provided by a Web application.
>
>
I had a side conversation with Richard Barnes on how this might integrate
with the LoST infrastructure.  Since LoST returns URIs, we concluded that a
LoST server could simply return an http: URI pointing to a web server at
which an e911-focused webrtc service was running.
There's a good bit of network assistance that might not happen in that case
(e.g. telling interception proxies to get out of the way of traffic to those
servers), but it should work as well as any other webrtc service.

>From this group's perspective, the key thing is that the LoST targeting
occurs *before* the webrtc sessions start in that case.

In the case where the webrtc session exists, and there is a "dial-out"
functionality that is invoked to call 911/112, then you'll end up in the
same case as a gateway with no location data.  At best the gatewaying server
can use whatever location data it has for the incoming client, run LoST, and
pick a service to contact.  At worst, it just hits the PSTN and dials
911/112 and gets what it gets.

If this becomes something that we need to tackle, I strongly suspect that
ECRIT is the right place to do it, not here.

regards,

Ted
(wearing no particular hat)