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

On Thu, Apr 16, 2015 at 9:58 AM, Peter Thatcher <pthatcher@google.com>
wrote:

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

Conference server knows just like any other WebRTC endpoint - if there is
no remote RtpSender for an m= line (i.e. no MSID), the line can be
reclaimed.