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

From: Flemming Andreasen <[email-masked]>
Date: Tue, 12 Sep 2017 08:53:56 -0400

We need more list discussion and inputs to consider making such a change.

Thanks

-- Flemming & Bo (MMUSIC chairs)

On 8/5/17 1:52 PM, Christer Holmberg wrote:
>
> Hi,
>
> Nothing prevents us from doing changes to a draft, even if it’s 
> already in the RFC editor’s queue. The question is whether we consider 
> the change essential enough at that stage.
>
> Regards,
>
> Christer
>
> *From:*mmusic [mailto:[email-masked]] *On Behalf Of *Taylor 
> Brandstetter
> *Sent:* 27 July 2017 02:23
> *To:* mmusic WG <[email-masked]>
> *Subject:* Re: [MMUSIC] draft-ietf-mmusic-msid-16 is out of sync with 
> WebRTC 1.0
>
> Ping. Harald (the author of this document) is on sabbatical, so I'd 
> appreciate some guidance from someone else familiar with IETF 
> processes. It's already in the RFC editor queue, which seems like a 
> problem.
>
> On Thu, Jul 20, 2017 at 6:41 PM, Taylor Brandstetter 
> <[email-masked] <mailto:[email-masked]>> 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.
>
>     This is all related to the "early media" functionality, and is
>     explained further in a blog post by Jan-Ivar; see the "Correlate
>     by transceiver.mid" section:
>     https://blog.mozilla.org/webrtc/the-evolution-of-webrtc/
>
>     So, the question became "why signal track IDs at all?" This was
>     brought up in a May virtual interim
>     (https://www.w3.org/2011/04/webrtc/wiki/May_2_2017), and we
>     decided to investigate removing them. To my knowledge this topic
>     hasn't been brought up on this mailing list yet.
>
>     Is this something still worth considering, or is it too late?
>     "a=msid" would switch to only containing the stream ID, not the
>     track ID. Implementers would presumably have a transitional period
>     where they support parsing both forms of "a=msid", after which
>     they start generating the new format, as we've done for other things.
>
>     The benefits are that the SDP would be slightly smaller, and the
>     complexity of the standards could be slightly reduced. The
>     downside is that more applications that rely on track IDs would
>     need to be updated (though many will need to be updated anyway).
>
>     Regardless of the outcome of this decision, "mmusic-msid" really
>     ought to be updated before publication. It's been out of sync with
>     WebRTC 1.0 for about a year; here's the first editor's draft that
>     broke the track ID symmetry:
>     https://w3c.github.io/webrtc-pc/archives/20160722/webrtc.html
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 12 Sep 2017 07:52:52 -0600

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

---

From: Taylor Brandstetter <[email-masked]>
Date: Tue, 12 Sep 2017 11:30:46 -0700

>
> 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 <[email-masked]> 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.
>
>
>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 12 Sep 2017 21:34:45 -0600

> On Sep 12, 2017, at 12:30 PM, Taylor Brandstetter <[email-masked]> wrote:
> 
> 	• 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.

---

From: Taylor Brandstetter <[email-masked]>
Date: Wed, 13 Sep 2017 10:01:05 -0700

>
> 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 <[email-masked]> wrote:

> >       • 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".
> >       • Bob applies remote description. The SDP contains "a=msid:streamA
> >       • Same thing. The SDP contains "a=msid:streamB trackB", but the
> track ("generatedA") already exists and the ID "trackB" is ignored.
> 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.