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

Re: Summary of replace track status

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Thu, 4 Jun 2015 12:27:14 +0000
To: Jan-Ivar Bruaroey <jib@mozilla.com>, Martin Thomson <martin.thomson@gmail.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>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D2475DC@ESESSMB209.ericsson.se>
On 02/06/15 04:39, Jan-Ivar Bruaroey wrote:

>> I agree, and if replaceTrack (initially at least) was specced to only
>> work if the UA could simply replace the content of existing outgoing RTP
>> stream(s) - SSRC and all being the same - would feel the simplest
>
> Simplest for whom? Browser implementers, spec writers, or users?
> Assuming no users want it to fail, then it seems simpler (to the user)
> for us to "just do it" (even in the hard corner-case).

That's a good point. Note though that there will be cases where it fails 
also with renegotiation (the most obvious one is if you try to replace 
an audio track with a video one).

I also re-read the JSEP draft, and it seems that the case Adam Roach 
mentions regarding re-negotiation should not really occur: the answerer 
is supposed to include all codecs it can use of the ones offered, not a 
single one. Combined with Harald's recent proposal [1] to in the offer 
include an ssrc per payload type it would mean that re-negotiations 
because of replaceTrack should rarely occur.

What I think would be best at this stage would be to get a replaceTrack 
proposal into the document, and then have it implemented and tested to 
see if it works for the use cases it's intended to solve. I don't care 
that much whether it is defined to fail or fire the negotiationneeded 
event if re-negotiation is needed.

[1] https://www.ietf.org/mail-archive/web/rtcweb/current/msg14702.html




>
> More importantly, IMHO, if the Sender/Receiver API is to outlive
> renegotiation, then it needs to absorb it, not operate within its limits.
>
> .: Jan-Ivar :.
>
>
Received on Thursday, 4 June 2015 12:27:42 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:44 UTC