Re: [rtcweb] draft-ietf-rtcweb-rtp-usage: CSRC in the API?

[Adam Bergkvist <[e-mail]>]

On 2013-02-22 10:19, Magnus Westerlund wrote:
> WebRTC WG,
>
> As editor of the RTP usage specification in RTCWEB WG, we have had a
> noted issue in our draft specification
> (https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/). In
> Section 12.5. of version 05 (Contributing Sources) we had the following:
>
> (tbd: does the API need to provide the ability to add a CSRC list to
>     an outgoing packet? this is only useful if the sender is mixing
>     content)
>
> This is clearly an API question. We intended to remove it. However, I
> like to hand it over to you in W3C to consider on the impact on the API
> this has.
>
>  From my personal view point this has two aspects:
>
> Exposing when a received MediaStreamTrack is actually the mix (or
> switch) of other MediaStreamTracks, a mix performed by a WebRTC endpoint
> or RTP middlebox (Mixer). Applications that like to know who are
> currently seen or audible needs this information mapping. We also have
> specified an optional to support RTP header extension (RFC6465) that
> provide energy levels for each contributing source. If that is used,
> that information would be something an application would like to render
> somehow.
>
> The other aspect is when an WebRTC endpoint mixes media to produce a new
> MediaStreamTrack, for example with the Web Audio API, then one need to
> consider if and how the CSRC list is populated.

Reading CSRC info:
Right now, the SSRC(s) of a track is only exposed via the Stats API. I 
think that's the right level if we were to support reading CSRC info as 
well.

Updating CSRC info:
IMO, we shouldn't add anything in the MediaStream API for this. If it's 
needed, it should be supported by the API that initiates the mixing.

/Adam