Re: Proposed disposition, CSRC issues

The problem with RTCRtpContributingSource.audioLevel is that if the goal is merely to figure out what sources are generating energy, then the CSRCs are just as good.  If the goal is to actually process the audio levels, then it is not helpful to retrieve audioLevel data at the same frequency (e.g. Once a second) one might request CSRCs.  So either way, obtaining audioLevel via this polling scheme doesn't seem to be helpful.

On Sep 3, 2015, at 21:33, Peter Thatcher <pthatcher@google.com<mailto:pthatcher@google.com>> wrote:

By the way, if it helps, this is the best we had at the time when we gave up:

dictionary RTCRtpContributingSource {
  double packetTime;
  unsigned int csrc;
  int audioLevel;
{

partial interface RTCRtpReceiver {
  // A read rather than an event because it would fire so frequently.
  sequence<RTCRtpContributingSource> getContributingSources();
}

On Thu, Sep 3, 2015 at 9:28 PM, Peter Thatcher <pthatcher@google.com<mailto:pthatcher@google.com>> wrote:
#4 came up in ORTC, and we went through a number of ideas and designs, and in the end, it was a complex API to get right, and all of the developers involved that were asking for it basically said "this isn't that important; we can live without it".

So, I agree with Harald's conclusion on #4.  And all of this conclusions, for that matter.


As for it being a MUST in the API, the chairs made a clear position that if something is going to be part of 1.0, then it MUST have a PR by the time of the f2f.  Is there such a PR for CSRCs?


On Thu, Sep 3, 2015 at 9:56 AM, Cullen Jennings <fluffy@iii.ca<mailto:fluffy@iii.ca>> wrote:

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