I’m running Mediasoup and binding to both IPv4 and IPv6 addresses. All of my users are on mobile devices.
Everything works fine for the vast majority of users. But there are some users on “weird” networks that have a problem finishing the DLTS handshake on send transports.
As an example of weird network:
- Put your iPhone into hotspot mode, and connect another device via Wifi to your hotspot
- Try to connect using libwebrtc from the iPhone (not the connected device)
- The send transport won’t get past the DTLS handshake, but recv transports work just fine.
This use case is rare, but I think it’s valid and I’d like to support it.
I’ve also had this same problem with users behind some sort of IPv6/IPv4 NAT, as described here: Client on IPv6 NAT can only complete ICE with send transports - #8 by ibc
The problem with these “weird” networks it that they have two possible routes to send packets (ipv4 + ipv6), but only one possible route to receive packets (ipv4 OR ipv6, depending on the network).
If libwebrtc tries to connect DTLS from a client role over the bad route, it quickly gives up and switches to the good route.
If libwebrtc tries to connect DTLS from a server role over the bad route, it waits forever for dtls message from the mediasoup server, which never comes.
I am able to resolve this by changing send transports to use the same DTLS roles as recv transports. I do this by changing this line in mediasoup-client from “server” to “client”.
- Is there a reason that send transports must used the “reverse” DTLS roles? In my tests, they seem to work fine with the same roles as the recv transports. But maybe I missed something?
- Is there a better way to change the DTLS roles on a transport, other than changing the source code?