Re: Proposed disposition, CSRC issues

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
>
>
>
>