Re: [MMUSIC] draft-ietf-mmusic-msid-16 is out of sync with WebRTC 1.0

[Taylor Brandstetter <[e-mail]>]

>
> What I would have expected to happen in this case is when Bob applies the
> remote description, the trackID of that track changes from "generatedB" to
> "trackA".
>

That would mean that MediaStreamTrack IDs can change after creation, which
seems dangerous. It's pretty normal to assume that IDs are immutable.

Based on the conversation we just had in the WebRTC virtual interim
<https://www.w3.org/2011/04/webrtc/wiki/September_13_2017>, it sounds like
the preferred path forward would be to go in the opposite direction, and
say that the "msid-appdata" field is *always* ignored by WebRTC endpoints
(when applying a remote description). We could also go a step further, and
have JSEP never populate the field. Right now JSEP says:

the "a=msid" lines MUST use [the RTCRtpSender's] track's ID.  If no
> MediaStreamTrack is attached, a valid ID MUST be generated
>
> As a JSEP author, do you have any thoughts on that, Cullen?

On Tue, Sep 12, 2017 at 8:34 PM, Cullen Jennings <[e-mail]> wrote:

>
> > On Sep 12, 2017, at 12:30 PM, Taylor Brandstetter <[e-mail]>
> wrote:
> >
> > Maybe a detailed example will make this more clear:
> >       • Endpoint A ("Alice") creates PeerConnection, adds track to it.
> Suppose this track's ID is "trackA".
> >       • RTCRtpTransceiver is created, along with an RTCRtpReceiver that
> has a track with a randomly generated ID. Let's call it "generatedA".
> >       • Endpoint B ("Bob") does the same thing; suppose they added a
> track with ID "trackB", and a remote track was created with ID "generatedB".
> >       • Alice creates offer, signals to Bob.
> >       • Bob applies remote description. The SDP contains "a=msid:streamA
> trackA", but Bob's remote track ("generatedB") already exists. So it just
> gets added to a stream, and the ID "trackA" gets ignored.
> >       • Bob creates answer, signals to Alice.
> >       • Same thing. The SDP contains "a=msid:streamB trackB", but the
> track ("generatedA") already exists and the ID "trackB" is ignored.
> > The MSID draft clearly doesn't align with this. It assumes a track is
> always created when a new track ID is seen in SDP.
> >
> >
>
> Thanks - that makes it perfectly clear.
>
> What I would have expected to happen in this case is when Bob applies the
> remote description, the trackID of that track changes from "generatedB" to
> "trackA". It seems like that track is being reused to now carry "trackA"
> and is the only way the data survives. It also mirrors what would have
> happened if the track was not created ahead of time and just crated by Bob
> applying the remote offer.