webrtc: pion/webrtc v2.2.26 wrong transceivers reuse, cannot re-add removed tracks on receiver side.

Your environment.

• Version: Ubuntu 20.04.2 LTS 64-bit - GNOME Version 3.36.8
• Browser: Google Chrome Version 91.0.4472.77 (Official Build) (64-bit)
• Used pion versions:

github.com/pion/dtls/v2 v2.0.4 // indirect
github.com/pion/quic v0.1.4 // indirect
github.com/pion/rtcp v1.2.6
github.com/pion/sctp v1.7.11 // indirect
github.com/pion/srtp v1.5.2 // indirect
github.com/pion/stun v0.3.5
github.com/pion/transport v0.12.0 // indirect
github.com/pion/turn/v2 v2.0.5
github.com/pion/webrtc/v2 v2.2.26

What did you do?

First of all, thank you for your product and support!

We are using pion to implement our own SFU.

We are trying to figure out why, although Chrome’s webrtc-internal stats display packet reception, negotiation, and transceiver status change are correct, the audio/video stream doesn’t show when tracks are removed and then re-added.

Steps

The panelist initiates the call with only the webcam video track (to simplify debugging) and publishes it, attendees joins the call with only the microphone audio track.

The panelist’s audio/video stream is then added to the attendees subscriptions and correctly displayed.

The broadcast of the panelist’s audio/video stream is stopped and the attendees subscriptions are stopped.

Then the panelist’s audio/video stream is added again and the subscriptions restored.

I am attaching the log of the negotiations on both the panelist and the attendant side and the stats.

We don’t think this is your issue, but it would be great if we could get support to try and understand why the stream isn’t being received again.

EDIT 2021-06-24

Note that:

• both negotiations logs are copy/pasted from chrome://webrtc-internals and reflect the javascript side of the client.
• you can also see the SDP generated by your go implementation of webrtc on calls to setRemoteDescription of logs
• the add and removal of screen-sharing works correctly even when done multiple times
• the attendee never remove the initial stream with one track coming from the mic
• you can also see that the id of the tracks remains the same at the next addition which to my knowledge is not normal behavior
• we have verified that the track.stop() method is not called for any remote track.

Obviously any information and suggestions will be welcome.

We regret not being able to share more information, we are still investigating, and will keep you updated in case we manage to isolate or solve the problem on our side or on your side.

What did you expect?

The audio/video stream should be visible again.

What happened?

The audio/video stream is not restored.

panelist-negotiations.txt attendee-negotiations.txt