W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2015

Re: ReplaceTrack and track.id (Re: ReplaceTrack - need to evaluate alternatives)

From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 15 Apr 2015 19:48:12 -0700
Message-ID: <CAJrXDUEFp-vs+Cu6==Nfm=zSn_yV_R+7a+cP8d=Xz2Hrq-_OGA@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Wed, Apr 15, 2015 at 6:57 PM, Justin Uberti <juberti@google.com> wrote:

> The two arguments (that I know of) against using mid by itself:
> 1) addTrack followed by removeTrack followed by addTrack will result in
> the same mid for the second track, due to the quirks of SDP. This means
> that sometimes addTrack gives you a new mid, sometimes it won't. This is
> unfortunate, although if we wanted to go down this path, we could
> prohibit recycling m= sections without a corresponding mid change. IOW, you
> could only recycle rejected m= sections, and so the example here would
> result in two m= lines.

This is effectively the problem I was also expressing.  If one does
addTrack + removeTrack + addTrack, can we use a different MID the second
time without accumulating dead m-lines over time?  If we can, then there is
no problem.  If we can't, then either JS cannot safely do
addTrack+removeTrack repeatedly too many times (do to the accumulation) or
we must have multiple RtpSenders with the same MID but at different times.
I think I'd be OK with the accumulation of dead m-lines.  If an app really
had an accumulation problem, they could get around it by doing one of:
 using replaceTrack, munging SDP, or using the future 1.1 API.

> 2) without a=msid, there is no way to detect a recyclable m= line
> (currently we can look for a=msid to determine this).
> Specifically, if you have a remote description without a=msid in a m=
> section, and you stop your local track for that m= section, you don't know
> whether to set port 0 (i.e. dead m= section) or not in subsequent offers,
> because you can't tell if the remote side is still using that m= section.
​So basically we just need a way to know "I'm a WebRTC endpoint; I know
what to do if you remove/recycle an m-line"?  For that I would suggest two
possible solutions:

1.  ​Have an a=removable line.  Do one thing and do it well (instead of
having multiple meaning tied to a=msid).

2.  Don't remove/recycle m-lines.   Would it really be that bad if we
didn't?  We don't right now, and no one has complained.  And, as I
mentioned, JS could always overcome an accumulation problem by using
replaceTrack, munging SDP, or using the future 1.1 API.

All that said, as much as I prefer the idea of having only 1 ID (MID), I
would probably be OK with an SDP attribute like a=RtpSenderLabel if that
ends up being more simple due to the quirks of SDP.

> On Wed, Apr 15, 2015 at 5:12 PM, Peter Thatcher <pthatcher@google.com>
> wrote:
>> Ah, I see.  It's true that if we didn't allow JS to choose the value, it
>> would be the same as now where the JS cannot choose the track ID.  So we
>> wouldn't be losing anything compared to the status quo.
>> But isn't the JS always able to set it anyway via SDP munging?
>> On Wed, Apr 15, 2015 at 3:24 PM, Martin Thomson <martin.thomson@gmail.com
>> > wrote:
>>> On 15 April 2015 at 15:19, Peter Thatcher <pthatcher@google.com> wrote:
>>> > And te question isn't whether to allow the JS to choose the MID.  It's
>>> > whether to have two IDs/labels (MID + something else), or just one
>>> (MID).
>>> > If one will work, I prefer one.
>>> Like I said, I am OK with just one and with that one being a=mid; I
>>> was pushing back at your suggestion that we let the JS set it, that's
>>> all.
Received on Thursday, 16 April 2015 02:49:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:43 UTC