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

Re: Summary of replace track status

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 29 May 2015 14:34:26 -0700
Message-ID: <CABkgnnUxTyvchY1AMFO2pFywe=XZN5uBEhCi2bQYfnA2Rr2XVQ@mail.gmail.com>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, Peter Thatcher <pthatcher@google.com>, Adam Roach <adam@nostrum.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 29 May 2015 at 13:28, Stefan Håkansson LK
<stefan.lk.hakansson@ericsson.com> wrote:
> On 29/05/15 18:17, Martin Thomson wrote:
>> On 29 May 2015 at 05:55, Stefan Håkansson LK
>> <stefan.lk.hakansson@ericsson.com> wrote:
>>> I think you are right, and it also seems (based on feedback from others)
>>> that replaceTrack should work even if a renegotiation is required.
>> That's not what I got from Cullen's comment.  His point was that
>> replacing should work from any state.  Your statement here leads me to
>> infer that replaceTrack can cause renegotiation.  That's what
>> addTrack/removeTrack are for.
> I did not get that from Cullen's comment either. I got that from
> Harald's [1], Ekr's [2] and Jan-Ivar's [3] (but I'm not sure I interpret
> this one correct) comments (it is also how Jan-Ivar's PR [4] is designed
> if IIUC).

I didn't get that from Harald's comment either.  I disagree with ekr
regarding POLA.

Either replaceTrack(old, new) is functionally equivalent to
removeTrack(old), addTrack(new), or it is a transparent or seamless
replacement.  It seems like the whole point is the seamless
replacement option.  A seamless replacement can fail, for the reasons
we've already established [1].  The only question is what happens to
the old track when that happens.  I believe that the right answer is
to have the old track continue.  For several reasons:

1. Any change will not be immediate, so stopping the old track would
be delayed anyway, so replaceTrack cannot be relied upon as a means of
causing transmission of the old track to cease.

2. It's easy for an app that wants to stop transmission to have that
happen by stopping the track.  An application can do this based on a
promise rejection if that is the behaviour they desire.  The
alternative is not possible: they can't just re-attach the old track
if they want continuous transmission, because of the glitch that will

3. POLA:  if x.setValue(a); x.setValue(b) throws on the second call,
it would be surprising if x.getValue() returned null.

I agree that Cullen's point regarding when the function may be called
is important (i.e., it should be callable at any time, regardless of
signaling state), but that is orthogonal to the question under debate.

[1] I believe that the fallback to renegotiation option has been
discussed and discarded, if it has not, I will try to explain why
that's a bad idea again.
Received on Friday, 29 May 2015 21:34:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:07 UTC