Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for synchronization

Harald Alvestrand <> Sun, 17 February 2013 10:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7926021F8574 for <>; Sun, 17 Feb 2013 02:47:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.072
X-Spam-Status: No, score=-110.072 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hOKyFrxCXPgE for <>; Sun, 17 Feb 2013 02:47:58 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4B02A21F87D5 for <>; Sun, 17 Feb 2013 02:47:58 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A13739E0E6; Sun, 17 Feb 2013 11:47:57 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KflHe6XOSA+7; Sun, 17 Feb 2013 11:47:55 +0100 (CET)
Received: from [IPv6:2001:470:de0a:27:5530:2938:2a9:d32e] (unknown [IPv6:2001:470:de0a:27:5530:2938:2a9:d32e]) by (Postfix) with ESMTPSA id 28E3839E029; Sun, 17 Feb 2013 11:47:55 +0100 (CET)
Message-ID: <>
Date: Sun, 17 Feb 2013 11:47:54 +0100
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jim Barnett <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for synchronization
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: Sun, 17 Feb 2013 10:47:59 -0000

On 02/16/2013 10:36 PM, Jim Barnett wrote:
> Harald,
>    You say:  " I don't think it can happen. It would require having the same MediaStreamTrack in two MediaStreams, and I don't think we can do that".   When we discussed this in the past, we certainly envisaged allowing the same Track to be in multiple streams.  Why else would MediaStream have an addTrack() method?  If we want to ensure monogamy, don't we have to change this to createTrack()?

I think the current understanding is that a track is the container for 
some amount of state, including the muted state, and that when you 
addTrack() to a MediaStream, the state (including mute) of the new track 
is independent of the old track after that point.

createTrack() might indeed be a better name.

> - Jim
> -----Original Message-----
> From: [] On Behalf Of Harald Alvestrand
> Sent: Saturday, February 16, 2013 12:05 PM
> To:
> Subject: Re: [rtcweb] Proposal for dealing with CNAMEs and MSIDs for synchronization
> On 02/14/2013 06:35 PM, Timothy B. Terriberry wrote:
>> Magnus Westerlund wrote:
>>> I agree that you need to have the corresponding objects on the
>>> receivers side. When it comes to identifiers I get a bit confused
>>> here on how the MSID draft is supposed to work. It switches between
>>> MediaStream and MediaStreamTrack in section 4. Is the WMS semantics
>>> providing the MediaStream IDs or the MediaStreamTrack IDs the SSRC is associated with?
>>> The current text appears to indicate both. Is the ID making it
>>> possible to distinguish between the two types?
>> According to Section 1.1, it is "providing necessary semantic
>> information for the association of MediaStreamTracks to MediaStreams...."
>> IIUC, it is the "identifier" token which indicates the MediaStream,
>> and the "appdata" token which indicates the MediaStreamTrack. The text
>> of Section 4 says "The value of the msid corresponds to the 'id'
>> attribute of a MediaStream," but I think it is supposed to say "msid
>> identifier" instead of the whole attribute.
> Yep. Thanks for catching this.
>> It goes on to say "The appdata for a WebRTC MediaStreamTrack consists
>> of the 'id' attribute of a MediaStreamTrack." It is not clear what
>> happens if an SSRC has two msids with different "identifier" tokens
>> but the same "appdata" token.
> I don't think it can happen. It would require having the same MediaStreamTrack in two MediaStreams, and I don't think we can do that.
>> The thing I think is currently somewhat confusing is the relationship
>> between MediaStreamTracks that belong to multiple MediaStreams. In the
>> current W3C API, creating a new MediaStream from an existing
>> MediaStreamTrack creates a clone of that track, rather than
>> incorporating the track by reference. Both tracks would have the same
>> underlying "source", but there is currently no representation of a
>> source in the MediaStream API, nor any way to tell if two tracks have
>> the same source from JS. In the SDP, an SSRC which has multiple msid
>> attributes presumably creates multiple MediaStreamTracks with the same
>> source.
>> It is not clear what is supposed to happen if one SSRC has two msid
>> attributes, and another SSRC has a single msid which matches one of
>> the msid attributes of the first SSRC, but is missing the other msid
>> attribute. I'd be happy with almost anything (including "the SDP gets
>> rejected as invalid"), but I think we should say something about it.
> Let me see ... if you mean this:
> a=msid: 25 a x
> a=msid: 25 b y
> a=msid: 50 b w
> it means that there are 2 MediaStreams (a and b) both carrying the media that's coming on SSRC 25 as a track, and one of these is also carrying the media coming on SSRC 50 as a track.
>> I also think the msid draft should be clear that just because two
>> msid's have the same appdata (indicating MediaStreamTracks with the
>> same "id" attribute), they should not necessarily be intended for the
>> same MediaStreamTrack object. It currently says that "If two different
>> SSRCs have the same value for identifier and appdata, it means that
>> these two SSRCs are both intended for the same MediaStreamTrack." It
>> does NOT say that if they have different identifiers and the same
>> appdata, they are NOT intended for the same MediaStreamTrack object.
> That was certainly my intention. But as noted above, I think "same appdata" isn't meaningful.
>> Even more important is the case of a single SSRC with multiple msid's:
>> the draft should make clear that this will correspond to multiple
>> MediaStreamTrack JS objects (with a common "source"... a property that
>> is currently ill-defined in the W3C API), even if the "appdata" token
>> is the same.
> Even with the same source, the data might actually not be the same (if it has been transformed, reencoded or otherwise mangled). If it's the same data, it seems reasonable to let it be sent once.
>>>> I think it is perfectly reasonable to require that all SSRCs that share
>>>> the same msid attributes (i.e., that belong to the same
>>>> MediaStreamTrack) use the same CNAME.
>>> MediaStreamTrack or MediaStream?
>> I meant MediaStreamTrack. This would be to handle cases like layered
>> codecs, FEC, or a source which plans to switch codecs (e.g., to use CN).
> We already have a requirement for all SSRCs that belong to the same
> MediaStream to have the same CNAME, so  this is just a subset of that -
> that's why I wondered.
>>> At some point we will need to have a mapping between the API concepts
>>> and RTP to be written up and agreed on. We will have to find the most
>>> suitable spot for that.
>> Section 4 of the msid draft appears to attempt some of that (at least
>> w.r.t. SSRCs). I don't think it's anywhere near complete.
> The msid draft tries to explain what the semantics of the identifiers
> is. If there are procedural matters to be documented, I think the JSEP
> draft should do it, since it's the "how do we map onto..." document.
>>> As long as only one encoding and one RTP stream is sent for each media
>>> source then implicit its tracks must have a common CNAME over all the
>>> MediaStreams it occurs in.
>> I think we still want to support simulcast (though possibly not in
>> Version 1), but it's an open question how we do so. We might very well
>> want the alternatives to be in different MediaStreamTracks with
>> different msids (or a receiver would have no way to select among those
>> alternatives in JS), so they wouldn't be covered by the "same msid"
>> case I suggest above, and would need some other mechanism to signal
>> that they originate from the same "source".
> I think simulcast fits best as a within-one-track concept; representing
> it as multiple tracks means that the application has to do explicit
> manipulation of it, and that doesn't sound right to me.
> It should be one of those "just ask for it, and if you get it, it just
> works" things.
>> However, I think defining CNAME behavior in the simulcast case isn't
>> really rtcweb-specific. Right now, as I read
>> draft-westerlund-avtcore-rtp-simulcast-01, it requires that related
>> encodings be tagged with your proposed SDES item SRCNAME with the same
>> value (though that draft only defines a multiple-session approach, and
>> you know how well that's likely to go over in this group). I think
>> this is a mistake, however, since
>> draft-westerlund-avtext-rtcp-sdes-srcname-02 says SRCNAME is "scoped
>> by" (which I take to mean "only unique in the context of the same")
>> CNAME. What draft-westerlund-avtcore-rtp-simulcast-01 probably wants
>> instead is to require the same CNAME:SRCNAME pair.
>> draft-even-clue-rtp-mapping-04 Section 6.2 (which has an incomplete
>> example of single-session, SSRC-multiplexed simulcast) has a similar
>> problem.
> That seems to make sense to me. But "someone else's problem".
>> _______________________________________________
>> rtcweb mailing list
> _______________________________________________
> rtcweb mailing list