Yeah, this is how the new spec is written. removeTrack will null out the track in the sender, and addTrack will not attempt to reuse that sender, because that sender has been negotiated to send previously. This means you'll get a new m-section for that added track, and the previous m-section will have its send bit cleared.

Best regards,
Byron  Campen

On 2/23/18 8:50 AM, Lorenzo Miniero wrote:

I noticed what may be an issue in Firefox > 58. In my client side renegotiation 
code, if I replace, let's say, a webcam with another on an existing PeerConnection 
and do a new offer/answer, it looks like it works (the local stream is updated), 
but the SDP offer actually has a=inactive in the related m-line.

The way the code works is that it calls removeTrack on the related PC sender, 
and then adds the new track with addTrack. I know it's much easier to do with 
replaceTrack (no renegotiation needed) but for the sake of simplicity I'm doing 
it this way as not all browsers implement replaceTrack correctly. In Firefox 58 
this works as expected, in Firefox 59 and 60 I get the inactive m-line instead.

This is quite easy to replicate, as you need to just open this demo page, and 
then change the devices while in the call to force a renegotiation:

Looking at the changesets, we found something that is probably related:

       The RTCPeerConnection.addTransceiver() method has been added. In
       addition, the behavior of addTrack() has been updated to create a
       transceiver as required

Does this mean that the removeTrack/addTrack I'm currently doing is not 
supported anymore, or is still supposed to work and this is a regression?

dev-media mailing list

dev-media mailing list

Reply via email to