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