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

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.
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.



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.
>>
>
>