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

["Timothy B. Terriberry" <[e-mail]>]

Harald Alvestrand wrote:
>> 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.

I don't think it can happen if you're talking to a browser. But this is 
SDP, and the other end-point might not be a browser, but may be trying 
to control a browser's behavior. It can certainly generate SDP like 
this. We should say what that behavior will be.

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

What I actually meant was this:
a=msid: 25 a x
a=msid: 25 b y
a=msid: 50 a x

I.e., both SSRC 25 and SSRC 50 are contributing to the same 
MediaStreamTrack (for any reason... FEC, layering, simulcast, etc.) in 
the first MediaStream, but only the first SSRC is declared to contribute 
to a MediaStreamTrack in the second MediaStream.

> That was certainly my intention. But as noted above, I think "same
> appdata" isn't meaningful.

I think that needs to be spelled out in the draft, including what "not 
meaningful" actually means.

>> 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 was looking at this from a receiver's perspective, not a sender's.

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

That's a good point.

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

That sounds reasonable to me.

>> 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
>
> I think simulcast fits best as a within-one-track concept; representing

Yeah... there's arguments for both approaches. I haven't thought about 
it enough to decide which is better.

> That seems to make sense to me. But "someone else's problem".

It certainly doesn't need to be solved in the msid draft, but it does 
need to get solved somewhere.