W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2011

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

From: Göran Eriksson AP <goran.ap.eriksson@ericsson.com>
Date: Wed, 20 Jul 2011 21:42:52 +0200
To: Cullen Jennings <fluffy@cisco.com>
CC: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, Koen Vos <koen.vos@skype.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <CA4CFA5A.CB9E%goran.ap.eriksson@ericsson.com>


On 2011-07-20 15.48, "Cullen Jennings" <fluffy@cisco.com> wrote:

>
>On Jul 20, 2011, at 3:39 , 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?
>> 
>> 
>
>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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 20 July 2011 19:43:23 GMT