- From: Justin Uberti <juberti@google.com>
- Date: Fri, 9 Dec 2011 13:52:51 -0500
- To: Randell Jesup <randell-ietf@jesup.org>
- Cc: public-webrtc@w3.org
- Message-ID: <CAOJ7v-15-3c=axSFgs7RRyv-sBEA7nF5oYPHr98kK=iKe4iOLg@mail.gmail.com>
On Fri, Dec 9, 2011 at 12:26 PM, Randell Jesup <randell-ietf@jesup.org>wrote: > On 12/9/2011 11:54 AM, Dominique Hazael-Massieux wrote: > >> Le jeudi 08 décembre 2011 à 17:11 -0500, Randell Jesup a écrit : >> >>> Yeah, I can see that having to guide the user through a specific UI >>>> isn't great; but how frequently does one have to deal with this? Is this >>>> something that we need for the 1st release of Web RTC, or can this be a >>>> feature that a later release could address? >>>> >>> >>> I see this as quite trivial; I see little or no advantage in waiting. >>> >>> The scope reduction seems to be virtually nil to me. I could code it >>> up faster than writing this email... ;-) >>> >> >> I would be better positioned to see if the required changes are trivial >> with a concrete proposal — could you suggest something :)? >> > > To PeerConnection add: > > attribute boolean EchoCancellation; > > and have it default to true. If we want the app to be able to indicate > the EC status (and it should), it can read that, and since EC status can > change asynchronously, it makes sense to let them know: > > attribute Function? onechocancelchange; > > The event notifier is in my mind optional, though a good idea. > > I'm not adding it to an MediaStreanTrack, since only the browser knows > what is actually getting to the speakers or the actual types of devices. We might end up with additional parameters down the road that the app may want to control, so I'd prefer to wrap this property in a MediaOptions object, which could later have other properties (e.g. AGC), and have a callback to indicate changes to that object, i.e. attribute MediaOptions mediaOptions; attribute Function? onmediaoptionschange;
Received on Friday, 9 December 2011 18:53:49 UTC