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

[Jim Barnett <[e-mail]>]

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

- Jim

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Harald Alvestrand
Sent: Saturday, February 16, 2013 12:05 PM
To: [e-mail]
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb