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

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?




> 
>
>
>
>On Jul 18, 2011, at 7:39 , Stefan Håkansson LK wrote:
>
>> On 2011-07-14 01:54, Koen Vos wrote:
>>> Stefan Håkansson wrote:
>>>> More and more can be done by analysing the input signal (e.g.
>>>> determining if it is speech or music), so perhaps there will be no
>>>> need for API support.
>>> 
>>> That may work in the long term.  But Opus currently has no
>>>speech/music detector, and I think it will take a while to build one
>>>that is good enough for most use cases.  So for now the API seems the
>>>only way we could set the Opus mode.
>>> 
>>> What are you actually proposing: to hard code the Opus mode, or to
>>>quickly invent a reliable speech/music detector?
>> I'm proposing that we should not have "audio" or "voip" attributes in
>> the API, at least not initially. When the initial version is in use, and
>> actual use of it indicate that it would be really beneficial (in certain
>> use cases), then we could add it - or perhaps technology catches up
>> (maybe a good speech/music detector is available by that time, and it
>> can be introduced with no alteration of the API).
>> 
>> Maybe practical use will indicate that the most important improvements
>> of the API is something completely different.
>> 
>> I have zero knowledge of Opus so I will refrain from commenting on that
>> part:)
>> 
>> Stefan
>>> 
>>> best,
>>> koen.
>>> 
>>> 
>>> Stefan Håkansson wrote:
>>> 
>>>>>> could help the codec perform at its optimum). And this set could be
>>>>>> irrelevant for a new generation of codecs. "audio" vs "voip" is
>>>>>>just one
>>>>>> example, and it is specific for one codec. I think the general
>>>>>>trend also is
>>>>> 
>>>>> On the contrary, things like AGC and noise suppression are
>>>>>independent
>>>>> of _any_ codec (at least they are in the WebRTC stack Google
>>>>> open-sourced). Opus implements a few more things internally, but
>>>>>there's
>>>>> no reason in principle why those things couldn't be done outside the
>>>>> codec as well. The point is that this switch is the difference
>>>>>between,
>>>>> "Please actively distort the input I give you to make it sound
>>>>> 'better'," vs. "Please preserve the original input as closely as
>>>>> possible," and that semantic has little to do with the actual codec.
>>>> 
>>>> I still think we should not go in this direction - at least not
>>>>initially. Let's add it later if there is a clear need. More and more
>>>>can be done by analysing the input>signal (e.g. determining if it is
>>>>speech or music), so perhaps there will be no need for API support.
>>>> 
>>>> Stefan
>> 
>> 
>
>
>Cullen Jennings
>For corporate legal information go to:
>http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
>
>

Received on Wednesday, 20 July 2011 10:40:28 UTC