RE: Proposed disposition, CSRC issues

With respect to #6, I agree with Harald that we should pass - because use cases such as dominant speaker detection can be implemented without it (e.g. on the server side), and also because #4 and #6 probably can't be implemented with the same approach.  

I am also in agreement with Harald's recommendation on #276.   

With respect to #4, we have implemented a polling mechanism.  It seems to function, and it was a relatively small amount of work to specify and implement.  On the other hand, it seems to only be of interest to developers of conferencing applications, so it is hard to argue it is more important than items that can benefit a wider audience. 

________________________________________
From: Harald Alvestrand [harald@alvestrand.no]
Sent: Tuesday, September 01, 2015 9:03 AM
To: public-webrtc@w3.org
Subject: Proposed disposition, CSRC issues

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

Received on Tuesday, 1 September 2015 16:45:49 UTC