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

Adam Bergkvist <> Fri, 22 February 2013 09:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67BBE21F86B7 for <>; Fri, 22 Feb 2013 01:43:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gqDGPQ5Nta+u for <>; Fri, 22 Feb 2013 01:43:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1782721F8533 for <>; Fri, 22 Feb 2013 01:43:42 -0800 (PST)
X-AuditID: c1b4fb30-b7f0d6d000007e61-00-51273dcefc8f
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 88.40.32353.ECD37215; Fri, 22 Feb 2013 10:43:42 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Fri, 22 Feb 2013 10:43:41 +0100
Message-ID: <>
Date: Fri, 22 Feb 2013 10:43:41 +0100
From: Adam Bergkvist <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Magnus Westerlund <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42KZGfG3RvecrXqgQesqYYvej0sYLdb+a2d3 YPJYsuQnk8fReftZA5iiuGxSUnMyy1KL9O0SuDL2PPjEUvCbt2LFlVmsDYyd3F2MnBwSAiYS k16tY4OwxSQu3FsPZHNxCAmcZJRYdPsXK4SzhlGib/FXFpAqXgFtif3LvrOD2CwCqhJ7bpwA 62YTMJKYtOQ6I4gtKhAl8f5qEzNEvaDEyZlPwHpFBMwkHk7YD1bPLBAp0bT5PCuILSzgLHF8 1SagOAfQMk2J7U80QUxOAS2JTScrIaotJBa/OcgOYctLbH87B2y6kICGxK7Zf5knMArOQrJs FpKWWUhaFjAyr2Jkz03MzEkvN9/ECAzIg1t+G+xg3HRf7BCjNAeLkjhvuOuFACGB9MSS1OzU 1ILUovii0pzU4kOMTBycUg2M60+94Gxb9b/q4u4v25L5665ZGex9Ejxzbee2EruUTQk1d1Te l32LWV2x9xtvuv2rNwY5p55N6JL94bXUWm/C/a2JU2YkxcpvbdVcrnh4770lew9bzFd/vZbb 7NekvTvvMeVMFfyhXi9y+9aV48nFc8U6y1YyP0/bZ98pfHDP0uzs91YrUi6f8lBiKc5INNRi LipOBAB2otuyFgIAAA==
Cc: "" <>, "" <>
Subject: Re: [rtcweb] draft-ietf-rtcweb-rtp-usage: CSRC in the API?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Feb 2013 09:43:44 -0000

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

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.