W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2015

Proposed disposition, CSRC issues

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 01 Sep 2015 18:03:22 +0200
Message-ID: <55E5CC4A.3070306@alvestrand.no>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
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:03:55 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:45 UTC