MIME-Version: 1.0
In-Reply-To: <CAK35n0ZYsjMTGGajpHuzg2_ARvG_V=PMbAPVgWZ9gHu_SMU7BA@mail.gmail.com>
References: <CAK35n0ZYsjMTGGajpHuzg2_ARvG_V=PMbAPVgWZ9gHu_SMU7BA@mail.gmail.com>
From: Taylor Brandstetter <deadbeef@google.com>
Date: Wed, 26 Jul 2017 17:23:15 -0700
Message-ID: <CAK35n0bjyvcBOJBxec2oCkEXRRuGrY-FwhLf4cYXas2HfqB9Hw@mail.gmail.com>
To: mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="001a1143b9281a0afc055541924c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/JKIND3Drv-4OF_Bzvh0_-2gigxM>
Subject: Re: [MMUSIC] draft-ietf-mmusic-msid-16 is out of sync with WebRTC 1.0
Precedence: list

--001a1143b9281a0afc055541924c
Content-Type: text/plain; charset="UTF-8"

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>
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
>

--001a1143b9281a0afc055541924c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Ping. Harald (the author of this document) is on sabbatica=
l, so I&#39;d appreciate some guidance from someone else familiar with IETF=
 processes. It&#39;s already in the RFC editor queue, which seems like a pr=
oblem.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Th=
u, Jul 20, 2017 at 6:41 PM, Taylor Brandstetter <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:deadbeef@google.com" target=3D"_blank">deadbeef@google.com</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">In th=
e current state of WebRTC 1.0, track IDs are not guaranteed to be symmetric=
al between the sending and receiving PeerConnection. This is because &quot;=
addTrack&quot; not only creates an RtpSender, but a whole RtpTransceiver, w=
hich has an RtpReceiver, which has a MediaStreamTrack with a generated ID. =
So if &quot;addTrack&quot; is called, and a remote description is set later=
, it&#39;s the MID that correlates the &quot;m=3D&quot; section with the tr=
ack, not the track ID, and the track ID in SDP is effectively ignored.<div>=
<br></div><div>This is all related to the &quot;early media&quot; functiona=
lity, and is explained further in a blog post by Jan-Ivar; see the &quot;Co=
rrelate by transceiver.mid&quot; section:=C2=A0<a href=3D"https://blog.mozi=
lla.org/webrtc/the-evolution-of-webrtc/" target=3D"_blank">https://blog.moz=
illa.<wbr>org/webrtc/the-evolution-of-<wbr>webrtc/</a></div><div><br></div>=
<div>So, the question became &quot;why signal track IDs at all?&quot; This =
was brought up in a May virtual interim (<a href=3D"https://www.w3.org/2011=
/04/webrtc/wiki/May_2_2017" target=3D"_blank">https://www.w3.org/2011/04/<w=
br>webrtc/wiki/May_2_2017</a>), and we decided to investigate removing them=
. To my knowledge this topic hasn&#39;t been brought up on this mailing lis=
t yet.</div><div><br></div><div>Is this something still worth considering, =
or is it too late? &quot;a=3Dmsid&quot; would switch to only containing the=
 stream ID, not the track ID. Implementers would presumably have a transiti=
onal period where they support parsing both forms of &quot;a=3Dmsid&quot;, =
after which they start generating the new format, as we&#39;ve done for oth=
er things.</div><div><br></div><div>The benefits are that the SDP would be =
slightly smaller, and the complexity of the standards could be slightly red=
uced. The downside is that more applications that rely on track IDs would n=
eed to be updated (though many will need to be updated anyway).</div><div><=
br></div><div>Regardless of the outcome of this decision, &quot;mmusic-msid=
&quot; really ought to be updated before publication. It&#39;s been out of =
sync with WebRTC 1.0 for about a year; here&#39;s the first editor&#39;s dr=
aft that broke the track ID symmetry:=C2=A0<a href=3D"https://w3c.github.io=
/webrtc-pc/archives/20160722/webrtc.html" target=3D"_blank">https://w3c.git=
hub.<wbr>io/webrtc-pc/archives/<wbr>20160722/webrtc.html</a></div></div>
</blockquote></div><br></div>

--001a1143b9281a0afc055541924c--