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

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

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

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.

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

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

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

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

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.