Re: Proposed disposition, CSRC issues

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