Re: Proposed disposition, CSRC issues

I think #4 is MUST have and there was consensus to put it in. I don't see consensus to remove it. This is critical for building conferencing systems where there is rapid indication of which parties are adding sound to the conference. This is a feature many developers ask for. 

I think that we must have a way to have Client-to-mixer level sent by in RTP. If the default is to always offer this in the SDP and accept it if offered, and do it if negotiated in SDP, then I don't think that a controls surface to turn that on and off is needed. (people can mangle SDP if they want to turn it off). But if we decide the default is not to always offer this, then I think the #276 is needed. 

I don't care too much about #6 but it pretty trivial and don't have any objections to it going in


> On Sep 1, 2015, at 10:03 AM, 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
> 
> 
>

Received on Thursday, 3 September 2015 16:56:28 UTC