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

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
>>> detection, noise suppression and gating for E911 calls. This allows
>>> operator to hear the background noise and decide things like if they
>>> 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
>>> 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
>>> 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
>> 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
>> 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
>> 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.


Received on Wednesday, 20 July 2011 19:43:22 UTC