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

[Taylor Brandstetter <[e-mail]>]

>
> yes, webrtc ends up with the track from A to B and B to A having different
> track IDs


That's not what I'm talking about. I'm talking about the track ID in the
remote description not matching the ID of the remote MediaStreamTrack.

Maybe a detailed example will make this more clear:

   1. Endpoint A ("Alice") creates PeerConnection, adds track to it.
   Suppose this track's ID is "trackA".
   2. RTCRtpTransceiver is created, along with an RTCRtpReceiver that has a
   track with a randomly generated ID. Let's call it "generatedA".
   3. Endpoint B ("Bob") does the same thing; suppose they added a track
   with ID "trackB", and a remote track was created with ID "generatedB".
   4. Alice creates offer, signals to Bob.
   5. 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.
   6. Bob creates answer, signals to Alice.
   7. 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.


On Tue, Sep 12, 2017 at 6:52 AM, Cullen Jennings <[e-mail]> wrote:

> >
> > In the current state of WebRTC 1.0, track IDs are not guaranteed to be
> symmetrical between the sending and receiving PeerConnection. This is
> because "addTrack" not only creates an RtpSender, but a whole
> RtpTransceiver, which has an RtpReceiver, which has a MediaStreamTrack with
> a generated ID. So if "addTrack" is called, and a remote description is set
> later, it's the MID that correlates the "m=" section with the track, not
> the track ID, and the track ID in SDP is effectively ignored.
>
> I'm not following the problem here ... yes, webrtc ends up with the track
> from A to B and B to A having different track IDs but the msid draft
> clearly allows the offer and answer to have different app data in the MSID
> line. What's the issue on this?
>
>
> PS - As side note, I've argued since before 2013 that we did not need to
> signal track ID in SDP but I think that train left the station long ago and
> I'd rather not change it at this point. The mostly compelling argument I
> recall on why we need this was hangouts uses it.
>
>
>