I’ve been migrating our createWebRtcTransport code from the listenIps api to the new webRtcServer api.
Our mediasoup process binds to both ipv6 and ipv4 IPs. When I construct the listenIps array, I prioritize either ipv4 or ipv6 candidates based on the IP address coming from the socketio signaling layer. I’ve found this has helped with some connectivity issues for some users inside of various kinds of IPv6 NATs. I think it probably speeds up the ICE process a bit too.
Since the WebRtcServer objects are created on startup, I’m not able to dynamically sort the candidate list like I can with the listenIps.
To get around this, I instantiate two WebRtcServer objects per worker: one sorted for ipv4 and one sorted for ivp6. I haven’t deployed this yet, but I think it should work. This approach means I need to bind to an extra port, but it’s not a big deal.
Ideally, I’d like to be able to use one WebRtcServer, and pass something like preferIpv6 to createWebRtcTransport.
My questions:
Is there a better way to accomplish this candidate sorting?
Would a preferIpv6 option be useful to anyone else? If so, I’m happy to put together a PR.
If you pass the ips in the preferred order in the listenInfos array in worker.createWebRtcServer() it should have the same effect as before when you use listenIps array. If not, please report a bug in GH by showing how you pass those ips to both WebRtcTransport and WebRtcServer and how the resulting transport.iceCandidates array look in both cases.
Yes, right. But I don’t know the preferred order when I create the WebRtcServer on startup. I only know the preferred order when a new client connects and requests a new transport. To get around this, I’m creating two WebRtcServers ahead of time, each sorted differently.
It seems we can manipulate the order of the candidates in the webRtcServer with the preferUdp and preferTcp flags. It would be convenient if I could also manipulate the order with preferIpv4 / preferIpv6