- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 26 Jul 2011 08:46:13 -0400
- To: public-webrtc@w3.org
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.
Received on Tuesday, 26 July 2011 12:46:37 UTC