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

[Christer Holmberg <[e-mail]>]

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:[e-mail]] On Behalf Of Taylor Brandstetter
Sent: 27 July 2017 02:23
To: mmusic WG <[e-mail]>
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 <[e-mail]<mailto:[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.

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