Re: Proposed disposition, CSRC issues

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