So I was introducing mediasoup to one of my consulting clients. And I came across something that I’ve never experienced. When they joined the mediasoup-demo room neither of us could see or hear each other. When I tried on my end by joining from a different device, even tried it with a mobile it was working fine.
The websocket was working fine and both of us were getting activeSpeaker events but no media. Here’s a screenshot of the information pop up:
My theory is that it has something to do with TURN servers? As I have not configured any TURN servers on the mediasoup-demo deployment that I use, because I assumed that the clients will be communicating with the server which obviously has a public IP address that’s reachable from both ends.
Not super familiar with the demo specifically, but I agree with you that this looks like a WebRTC networking issue. The 0x0 resolution suggests the connection isn’t established in the first place. I’m assuming that your client never saw/sent any media, and the only media successfully exchanged was between your own devices.
For the vast majority of applications you wouldn’t need a TURN server (I don’t have one set up either), but it’s possible your client is behind a firewall blocking outgoing WebRTC traffic on your defined port range. If your client is savvy, you could ask them to examine chrome://webrtc-internals and check the ICE connection state to confirm… Or alternatively you can setup verbose logging on the mediasoup worker and see what’s happening with the connection (probably preferable since you don’t have to ask the client to do anything).
Setting up coturn is definitely a reasonable next step and is pretty quick to do. Put it on port 443 and enable TLS (shouldn’t be blocked by most firewalls). You can make sure it’s working locally before involving your client by temporarily setting iceTransportPolicy to ‘relay’ to force usage of TURN while you’re doing your own testing. Remember to remove this when you’re done testing since TURN isn’t needed with mediasoup’s ICE-lite architecture outside of this specific firewalling scenario.
Hi @dimoochka. Thanks allot for replying. So I deployed another one of my mediasoup instances and this time added a TURN server, it started to work for him apparently. So yes I believe there must have been something that’s blocking outgoing packets from his side.
But it is very strange that this issue was only happening for him on chrome, on firefox the mediasoup demo instance for which I posted this issue was working perfectly fine. If it was a proxy/firewall blocking the data why would it work on firefox?
That’s very odd behavior. Could be a very specific bug (you’d need at least a mediasoup-server log to see where this was failing). Obviously this software is interoperable between those two browsers under routine circumstances. Alternatively could be a local software firewall that’s got app-based outgoing filtering? Also very rare as most software firewalls only prevent incoming connections.
