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

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Feb 2013 10:19:17 +0100

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.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Adam Bergkvist <[email-masked]>
Date: Fri, 22 Feb 2013 10:43:41 +0100

> 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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Feb 2013 11:22:21 +0100

> think that's the right level if we were to support reading CSRC info as

I don't see how the Stats API comes in here. The information bit I see
the CRSC list provides is: These MST(s) was used to produce what you
get. It is a information about original identity of the media sources.
Thus I would guess that in the API it might be appropriate to map the
CSRC list to the MST IDs.

Please remember that the CSRC list is dynamic and can change frequently.

Cheers

Magnus Westerlund

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 22 Feb 2013 12:08:15 +0100

> CSRC list to the MST IDs.

Can you expand MST, please?

My googling for "CSRC" and "MST" together only came up with 
"Multi-Session Transmission" (from the COP draft), and that doesn't seem 
to fit.

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 22 Feb 2013 12:11:19 +0100

> Can you expand MST, please?

MediaStreamTrack is my guess.

---

From: Adam Bergkvist <[email-masked]>
Date: Fri, 22 Feb 2013 12:13:19 +0100

> "Multi-Session Transmission" (from the COP draft), and that doesn't seem

My interpretation: MST = MediaStreamTrack (in this context)

/Adam

---

From: Adam Bergkvist <[email-masked]>
Date: Fri, 22 Feb 2013 13:01:00 +0100

> CSRC list to the MST IDs.

Ok, I was talking about exposing the CSRC values directly. I think that 
and other RTP stuff belongs in the Stats API. However, if we map the 
info the CSRC list provides to track ids (or sourceId), then I agree 
it's a different case.

/Adam

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Feb 2013 14:19:18 +0100

> MediaStreamTrack is my guess.

Yes, that is what I meant. I should have made it clear. The
MediaStreamTrack is so bloody long word to write.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 27 Feb 2013 18:16:35 +0000

I think this is very useful for a bunch of things in conferences. I'd like to see an API so the CSRC list for outgoing RTP can be set on a per track basis, and the API allows the JS to get the CSRC of most recently received RTP packets for a given PC-Track and also be nice to have a callback any time the received CSRC changes.

---

From: Emil Ivov <[email-masked]>
Date: Wed, 27 Feb 2013 20:25:11 +0200

On 27.02.13, 20:16, Cullen Jennings (fluffy) wrote:
> I think this is very useful for a bunch of things in conferences.

+1

> I'd
> like to see an API so the CSRC list for outgoing RTP can be set on a
> per track basis, and the API allows the JS to get the CSRC of most
> recently received RTP packets for a given PC-Track and also be nice
> to have a callback any time the received CSRC changes.

+1 again. It would also if such an API would also the possibility to
retrieve audio levels from the RTP (Magnus already mentioned RFC6465)
so that applications can render such information.

(Like this for example: http://goo.gl/QTaqy )

Cheers,
Emil
>> 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.
>> 
>> 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.
>> 
>> Cheers
>> 
>> Magnus Westerlund
>> 
>> Färögatan 6                | Mobile +46 73 0949079 SE-164 80
>> Stockholm, Sweden| mailto: [email-masked] 
>> rtcweb mailing list [email-masked] 
> _______________________________________________ rtcweb mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
> 

-- 
https://jitsi.org

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 27 Feb 2013 10:33:11 -0800

On Feb 27, 2013, at 10:25 AM, Emil Ivov <[email-masked]> wrote:

> It would also if such an API would also the possibility to

+1 on that too

---

From: Justin Uberti <[email-masked]>
Date: Wed, 27 Feb 2013 16:21:15 -0800

Chrome currently surfaces audio level information via the getStats API,
albeit not for mixed audio levels.

---

From: Emil Ivov <[email-masked]>
Date: Thu, 28 Feb 2013 10:15:25 +0200

> +1 again. It would also if such an API would also the possibility to

Awfully sorry! This was supposed to say:

"It would also *be great* if such an API would also *provide* the
possibility to retrieve audio levels.

(Coffee deficiency!)

Emil

-- 
https://jitsi.org