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:
Hi,
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:
https://janus.conf.meetecho.com/devicetest
Looking at the changesets, we found something that is probably related:
https://developer.mozilla.org/en-US/Firefox/Releases/59
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?
Thanks,
Lorenzo
_______________________________________________
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
_______________________________________________
dev-media mailing list
dev-media@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-media
