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

On Jul 20, 2011, at 12:42 , Göran Eriksson AP wrote:

> On 2011-07-20 15.48, "Cullen Jennings" <> wrote:
>> On Jul 20, 2011, at 3:39 , 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?
>> Just to be clear, I was not suggesting we do this because it was a
>> regulatory requirement, I was suggesting doing ti because it was useful.
>> I guess I would like to hear more about why people think this is so hard.
>> We seem to agree we need an extensible hints structure for things like
>> this in the future. We have lots of experience with codec selection. I'm
>> proposing that the it is optional to implement and the browser can ignore
>> the hint. So what is that people don't like about this? I'm just not
>> getting it?
> Thanks Cullen- Just wanted to get it clarified that we exclude some of the
> e911-like stuff in the first round, :-)!
> Personally, I have no strong opinion on how this particular question
> should be solved but Your approach with optional sounds reasonable-
> my concern is more general that we have pretty enough with stuff to handle
> anyway in the first phase of 'webrtc' in both w3c and ietf.

Fair enough, clearly there is far more that could be done than we want to do in the first stage. Right now I am in the mode of listing all the stuff and then trying to pick off waht is easy, what is hard, what we don't want to do intiall but we need to consider in the design so we don't paint ourselvers into a corner. 

Received on Wednesday, 20 July 2011 20:05:13 UTC