davidliu

Looking at the example code, this is caused by how it's ordered in the mediasoup library. `Consumer.pause()`: 1. `track.enabled` is set to false 2. `onRemoveTrack` gets called * Notably, the...

https://github.com/versatica/mediasoup-client/blob/64298846a1d0b49f719b7665c93b6719722571d1/src/handlers/ReactNativeUnifiedPlan.ts#L1000 Sets the direction to `inactive` for the transceiver as well as the media object in the sdp (and then renegotiates).

Yeah, checked it and the receiver still has the track in this case. ---- For my original issue, the sender unpublished and republished an audio track with the same track...

Looks like there's a race condition where the data packet comes in before the connection is finished processing the join response. I'll look into fixing this.

Which version of LiveKit specifically is being used here? 2.0.0? Can you also check which version of io.github.webrtc-sdk is being used (run `gradle dependencies`)?

How often would you say the error occurs, percentage wise?

Wait, you wrote a `buildPeerConnectionFactory` method, but how does that PeerConnectionFactory get injected into our LiveKit SDK?

Is there a reason why you're not going through `LocalParticipant.createVideoTrack()`? It sounds like the association between two separate PeerConnectionFactories are causing the issue.

`createVideoTrack` has an overload to pass in your own custom video capturers. You should try that.

LiveKit handles creating the video source and calling `VideoCapturer.initialize` with the appropriate capturerObserver from our internal PeerConnectionFactory. You don't need to call it yourself.