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