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

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:mmusic-bounces@ietf.org] *On Behalf Of *Taylor 
> Brandstetter
> *Sent:* 27 July 2017 02:23
> *To:* mmusic WG <mmusic@ietf.org>
> *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 
> <deadbeef@google.com <mailto:deadbeef@google.com>> 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
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic