An issue has been identified here (probably just related to Unified-Plan). It happens when RTP packets are received by a remote WebRTC endpoint (mediasoup-client or libmediasoupclient) before the corresponding local consumer has been created in the remote endpoint application.

If that happens, the remote RTCPeerConnection will wrongly associate the unknown RTP packet and its new SSRC to any previously existing SDP m= section, so later, when the consumer is locally created (via transport.consume()) such an action would fail with “Failed to set local answer sdp: Failed to process the bundled m= section.”.

The way to avoid this race condition is simple:

Always create the server side consumer by setting paused: true in transport.consume() in the server.

Then transmit consumer parameters to the remote endpoint as usual.

Call transport.consume() in remote endpoint with those parameters.

Then signal “done” to the server and unmute the server side consumer by calling consumer.resume().