Re: Summary of replace track status

On 5/30/15 2:01 AM, Peter Thatcher wrote:
> I don't consider this a realistic test.  You're basically assuming 
> that signalling RTT is near-0.  I think you'd have to retry with a 
> realistic signalling RTT.

I agree, though it's much faster than a visit through a (potentially 
busy) server, which I think we've been assuming.

I've updated the fiddle with a |additionalSignalingDelayMs| you can set.

By setting it unrealistically high, I notice the video stops half-way 
through re-negotiation. Aren't we fixing that with simultaneous support 
for current and pending local descriptions?

> ​ Andif you can still see flicker with near-0 RTT,
> ​I think it's a failure.

If the gamut is "we [now] don't really need replaceTrack in 1.0" and 
"it's a failure" at the same time, then maybe it's just right? ;)

>     I'm also wondering why we don't add
>     |pc||.turnOnAutoRenegotiation();| to do renegotiation over a
>     data-channel automatically with zero JS involvement.
>
> ​
> ​
>
> ​A library can already do that.

Yes, though AFAIK nobody has. A quick-flag would advertise this awesome 
feature.

.: Jan-Ivar :.