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

On 02/22/2013 10:43 AM, Adam Bergkvist wrote:
> 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.

Support reporting this in stats - it's another thing the user may want 
to interrogate.

CSRC can only be useful if one knows the CSRC to originator mapping 
information. This has to come out of band - there's no API or protocol 
to carry it at the moment, AFAIK.

>
> 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.
At the moment, we don't have an API that allows mixing in a client.

Handling of CSRCSs on the originator side shouldn't be exposed at the 
API until we have something to connect it to, and the rules should be 
developed as part of specifying the extension for manipulating mixes.

Not a high priority item for the browser, in my opinion.

Received on Friday, 22 February 2013 11:05:12 UTC