Using Chromium in a Docker container to connect to mediasoup in another container fails (with mediasoup >=3.5.8)

I have a complex setup with multiple docker containers, but I’ll try to describe the relevant part. I realize it all may be too vague or unclear, but I’ve given up on this problem, so I am looking for a different point of view.

  • There is docker container running mediasoup. There is a NestJS application that takes care of starting the media server and for the initial communication.
  • There is a Chromium 77 browser in another docker container that opens a given web page then streams the audio and video to mediasoup server in the other container. Of course, the browser uses mediasoup-client
  • Audio and video are then streamed to another container with ffmpeg that records them to a file.

So far, so good. The things is everything was running fine until we upgraded mediasoup to 3.5.11 and mediasoup-client to 3.6.5. After that, upon creating a transport and right after the server attempting to produce, the browser crashes with a similar error:

 [198:198:0529/] Failed to parse: "candidate:2071985302 1 tcp 1350508287 54424 typ prflx raddr rport 9 tcptype  generation 0 ufrag Dnkv network-id 1". Reason: Invalid TCP candidate type.

The error makes sense, because, as you can see, there is a blank space after tcptype, meaning it is blank.

However running Chromium outside of Docker works perfectly fine. I can access the same page and send streams to mediasoup.

All debugging attempts had little success or have been futile. However, here is the information I managed to gather:

  • The error happens in the device handler (in our case it is Chrome74.ts), in send(), when it tries to run await this._pc.setLocalDescription(offer);. This runs one time for audio and it is fine, and when it gets to the video stream, it causes the browser error.
  • After the above runs for the video, the browser throws the error message in the terminal.
  • The IP and the port in the error are not in the candidate list that is initially send by the server (upon transport creation and connecting).
  • The IP in the error message is the IP of the docker container running Chromium
  • The above makes me think there is some sort of communication happening directly between the browser and mediasoup-server. Since it is not going through our code, I was unable to trace it.
  • I could not figure out how is the tcptype affected by the changes in 3.5.8. It may not be, but something, somewhere is generating a broken SDP.

What I tried but did not fix the problem:

  • Trying all server versions from 3.5.8 to 3.5.11
  • Using 3.5.8, but reverting the uv_udp_init_ex() change (while keeping the updated libuv).
  • Using different STUN servers
  • Using or nor using TURN servers
  • Using a different version of mediasoup-client. (the problem seems to originate from the server)
  • When running router.createWebRtcTransport(), passing enableTcp: false makes the error disappear, but the browser still fails.

The only thing that helped was downgrading the server to 3.5.7, probably, because of restoring the older version of libuv.

So my questions would be: Has anyone come across anything similar? Can you suggest where to look for the potential source of data (ICE candidates?), that is converted to an invalid SDP? Something I might be missing or some place where in the code that I need to look into?