- From: Marco Pracucci <marco.pracucci@spreaker.com>
- Date: Thu, 8 Dec 2011 17:59:25 +0100
- To: Randell Jesup <randell-ietf@jesup.org>
- Cc: public-webrtc@w3.org
> Except that a browser interface means it has to be in the chrome in > some manner, which leads to all sorts of discoverability problems. > I don't have a problem with being offered in chrome (though I might > not mandate it), but I think having the application be able to offer > the option within their UI (and possibly explain it, or use > something to decide when to suggest it to a user) is a plus. Also, > if it's in their UI, they control where it shows up and what it > looks like, and they don't have to say "if your partner hears > clipping or odd-sounding audio, turn off EC. To do this, on IE go > here..., on Firefox go here..., on Opera, on Safari, oh, and by the > way, if you're on a mobile device....". > > Another use-case might be where it knows (via several possible > mechanisms) the other side is muted; it knows there's no echo to > cancel. > > I also see no security reasons to avoid giving the app access to the > EC control. > > I'd vote strongly in favor of letting the App turn EC on and off. What if the UA has a default behavior that tries to guess if EC should be on/off, but the app can override it? Marco -- Marco Pracucci marco.pracucci@spreaker.com Twitter: @pracucci Mobile: +39 393 97 57 212 Skype: mpracucci
Received on Thursday, 8 December 2011 17:00:49 UTC