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

On Thu, Apr 16, 2015 at 9:53 AM, Justin Uberti <juberti@google.com> wrote:

>
>
> On Wed, Apr 15, 2015 at 7:48 PM, Peter Thatcher <pthatcher@google.com>
> wrote:
>
>> 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.
>>
>
> This particular issue won't result in too many dead m-lines; we will still
> be able to recycle m=lines that aren't in use by either side. We just won't
> be able to recycle "half-dead" m-lines, which is probably OK.
>
>
>>
>>
>>> 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.
>>
>
> I think this will be a real problem for conferences, since the list could
> grow without bound.
>

​But then it's up to the conference server to add/remove m-lines, right?
The browser doesn't have anything to do with it.  So the real question is:
 how does the conference server know that it's safe to remove m-lines that
it's not using any more?   Using MSID as an indication for such a thing
seems a little strange.

​



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