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

From: Taylor Brandstetter <[email-masked]>
Date: Thu, 20 Jul 2017 18:41:58 -0700

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

---

From: Taylor Brandstetter <[email-masked]>
Date: Wed, 26 Jul 2017 17:23:15 -0700

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]>
wrote:

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

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 27 Jul 2017 19:28:18 +0000

So is the summary that you propose we remove the track ID from the MSID
attribute?

If so, I'm in favor.

On Thu, Jul 20, 2017 at 6:42 PM Taylor Brandstetter <[email-masked]>
wrote:

> 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.
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>