Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <CAK35n0bHg556nKqYiM4UXBU6RXEKqy=rouPmx723vw+FjzKJRw@mail.gmail.com>
Date: Tue, 12 Sep 2017 21:34:45 -0600
Cc: Christer Holmberg <christer.holmberg@ericsson.com>,
 mmusic WG <mmusic@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D740A1E-0F86-4D41-9ABE-134B2C588AC5@iii.ca>
References: <CAK35n0ZYsjMTGGajpHuzg2_ARvG_V=PMbAPVgWZ9gHu_SMU7BA@mail.gmail.com>
 <CAK35n0bjyvcBOJBxec2oCkEXRRuGrY-FwhLf4cYXas2HfqB9Hw@mail.gmail.com>
 <7594FB04B1934943A5C02806D1A2204B4CCADFB5@ESESSMB109.ericsson.se>
 <F7765CFE-01FA-4788-B06F-EBB93C14BE2D@iii.ca>
 <CAK35n0bHg556nKqYiM4UXBU6RXEKqy=rouPmx723vw+FjzKJRw@mail.gmail.com>
To: Taylor Brandstetter <deadbeef@google.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/1xERMyBBrD4q4I9FkuHxR5aF-rY>
Subject: Re: [MMUSIC] draft-ietf-mmusic-msid-16 is out of sync with WebRTC 1.0
Precedence: list


> On Sep 12, 2017, at 12:30 PM, Taylor Brandstetter =
<deadbeef@google.com> wrote:
>=20
> Maybe a detailed example will make this more clear:
> 	=E2=80=A2 Endpoint A ("Alice") creates PeerConnection, adds =
track to it. Suppose this track's ID is "trackA".
> 	=E2=80=A2 RTCRtpTransceiver is created, along with an =
RTCRtpReceiver that has a track with a randomly generated ID. Let's call =
it "generatedA".
> 	=E2=80=A2 Endpoint B ("Bob") does the same thing; suppose they =
added a track with ID "trackB", and a remote track was created with ID =
"generatedB".
> 	=E2=80=A2 Alice creates offer, signals to Bob.
> 	=E2=80=A2 Bob applies remote description. The SDP contains =
"a=3Dmsid:streamA trackA", but Bob's remote track ("generatedB") already =
exists. So it just gets added to a stream, and the ID "trackA" gets =
ignored.
> 	=E2=80=A2 Bob creates answer, signals to Alice.
> 	=E2=80=A2 Same thing. The SDP contains "a=3Dmsid: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.
> =20
>=20

Thanks - that makes it perfectly clear.=20

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.=20=