W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2011

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

From: Göran Eriksson AP <goran.ap.eriksson@ericsson.com>
Date: Tue, 26 Jul 2011 22:39:13 +0200
To: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <CA54F1D5.CDF1%goran.ap.eriksson@ericsson.com>


On 2011-07-26 14.46, "Harald Alvestrand" <harald@alvestrand.no> wrote:

>On 07/25/11 22:46, Ian Hickson wrote:
>> On Wed, 20 Jul 2011, Göran Eriksson AP wrote:
>>> On 2011-07-18 20.13, "Cullen Jennings"<fluffy@cisco.com>  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.
>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.
Thanx for getting this clarified. I consider it agreed by the group to
include a scenario like that Cullen described in the requirement doc and
to push e911 requirements for future work (beyond webrtc WG).

---Göran




>
>
>
Received on Tuesday, 26 July 2011 20:56:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 26 July 2011 20:56:46 GMT