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

On Wed, 20 Jul 2011, Göran Eriksson AP wrote:
> On 2011-07-18 20.13, "Cullen Jennings" <> wrote:
> >
> >As a side note, I hate the label voip / audio. They are not the right 
> >labels for what we are talking about. This is all voip and it is all 
> >audio. But ignoring the labels...
> >
> >Let me bring up another use case. E911 calls need to be handled more or 
> >less like music instead of speech. For example you turn of voice 
> >activity detection, noise suppression and gating for E911 calls. This 
> >allows PSAP operator to hear the background noise and decide things 
> >like if they need to delay the paramedics knocking on the door until 
> >after the police arrive. (where I live average response time of police 
> >is far worse than average response time of ambulance so this decision 
> >impacts lives).
> >
> >I'm arguing the JS app, which is the only thing that knows if this call 
> >was being used for that type of purpose, should support a hint along 
> >the lines of this. I'm not saying the browsers should have to pay 
> >attention to this hint - some will use it, some will ignore it, but I 
> >want one hint that all apps can use and not have to write separate code 
> >for each browser.
> But are e911 requirements (and other telco like service/features that 
> come from regulatory requirements) those we should prioritize in the 
> first phase of webRTC? There are lot's of such requirements (especially 
> if we go down to national level)..
> Given the challenges in bringing RTC to the browser, perhaps we should 
> take the e911 like use cases in subsequent phases, when the community 
> have gathered some more experience having solved the "basic" stuff?

Is there any documentation anywhere about what E911 services around the 
world expect or hope the calling client to provide?

If it's a simple list of things, e.g. just "enable a mode where you amp 
the microphone when there's nothing audible rather than cutting it out 
entirely" then it may be worth providing a mechanism for this in the first 
version -- after all, this could save lives.

If it's a really complicated protocol where the client is expected to set 
up new RTP streams to send geolocation coordinates or whatnot in a manner 
that could be abused to seriously invade a user's privacy, maybe it's 
something that we should instead punt for the first version.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 26 July 2011 02:46:42 UTC