Re: Proposed disposition, CSRC issues

Agree with Harald and Gustavo. These are non-trivial changes to the API,
and app developers have managed to find other solutions.

On Mon, Sep 7, 2015 at 5:24 AM, Gustavo Garcia <ggb@tokbox.com> wrote:

> I support Haralds's proposal for #4, #6 and #276.
>
> AFAIK all the existing use cases can be implemented if clients send audio
> levels by default and/or using Datachannels to convey some information from
> mixer to clients.  I understand this is not ideal in some cases, specially
> for some existing server implementations, but IMO that is not enough to
> make these new APIs a must for 1.0.
>
>
> On Tue, Sep 1, 2015 at 6:03 PM, Harald Alvestrand <harald@alvestrand.no>
> wrote:
>
>> We have 3 issues that relate to CSRC information in our tracker.
>> We've had debate about them - most recently from July 31 to August 18 -
>> but very few people have contributed, and there seems to be no strong
>> consensus.
>>
>> The tracker issues are:
>>
>> #4 Need API to read the CSRC on received tracks
>> #6 Need API to receive mixer to client audio level information for a track
>> #276 Control to turn on Client-to-Mixer Audio Level in offers
>>
>> The contributors and their (no doubt mischaracterized) positions from
>> the August mail thread are roughly:
>>
>> - Bernard Aboba has called CSRC information "not a must have"
>> - Cullen Jennings has called CSRC information "useful for a bunch of
>> things"
>> - Inaki Baz Castillo has said that "the usecase is **really** big"
>> - Harald Alvestrand (me) has said that "I don't regard this as an
>> important use case".
>>
>> There was also a spate of debate about this in February, with a few more
>> participants.
>>
>> Given that:
>>
>> a) there doesn't seem to be a consensus that CSRC information is important
>> b) we're trying to limit the scope of 1.0 features that we don't have
>> consensus to add
>> c) generation of volume information is hard to retrofit later (old
>> clients wouldn't generate it)
>> d) new interfaces for retrieving information are not so hard to retrofit
>> later
>>
>> I'm suggesting the following disposition for these issues:
>>
>> #4: We don't add any such API in WebRTC 1.0
>> #6: We don't add any such API in WebRTC 1.0.
>> #276: We find a convenient place to say that implemementations MUST use
>> this feature (that is, send volume information) if negotiated
>> successfully.
>> We don't add any API for turning this functionality off in WebRTC 1.0.
>>
>> This will give us a situation where volume information is flowing to the
>> mixer, and the mixer can take advantage of it if desired - and at a
>> later stage, we can add APIs for reading the information that already
>> flows in the system on incoming flows.
>>
>> Does this seem like an appropriate disposition given where we are?
>>
>> Harald
>>
>>
>>
>>
>