Re: Need API to read the CSRC on received tracks (#4)

On 08/14/2015 05:06 PM, Cullen Jennings wrote:
>> On Aug 1, 2015, at 11:26 AM, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:
>>
>> The primary benefit is to allow the UI in a conference to indicate which participants are generating audio energy. So if you hear a dog barking it can help narrow down which participant to mute. For conferences that do not mute by default that can be valuable. 
> There are two things here - the first (which you point out above) is UI to show active speaker in real time. I think this would be very good to have. 
>
> The second is the audio levels attribute send in the RTP extension from the browser to switch. I think that is critical to have. Without that there is no way to start to enable conferences without keys and I think the WG should prioritize things that helps with privacy - this is one of them. 
>
OK - you're talking about conferences where the mixer is unable to
decode the media, but still wants to select only a few media streams for
forwarding (for example loudest speaker & accompanying image). The
extension would give information to the mixer about the audio volume of
tracks sent from the browser.

This is audio from browser to switch. This can be sent completely
without any API surface (we have "MUST be implemented" in the rtp-usage
draft (section 5.2.2); the draft does say "The use of this encryption
<of the extension> is RECOMMENDED, however usage of the encryption can
be explicitly disabled through API or signalling." - this seems to
indicate a need for an API surface. The RTP usage draft doesn't say
whether the extension should always be used when negotiated, but that
seems logical.

However, this is not issue #4. Can we discuss this under another subject
line / bug number?

The mixer-to-client audio level is also a separate issue from #4 - in
fact it is #6. Can we discuss that on a separate thread too?

Received on Tuesday, 18 August 2015 14:03:28 UTC