You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are waiting for ice gathering completion before we start ice trickling. In theory, this should not be needed, and it's probably slowing down connection times on wasm, especially if the socket is configured with multiple stun servers. However, last I checked, if we removed the wait, nat hole punching started failing.
I originally wrote this as a comment on #35 before I realized there was a separate issue for it here - I've edited my comment to move the relevant text from there into a new comment here.
From poking around at #35, I suspect the NAT traversal issue when removing the wait might be because ICE gathering starts with the host interface as the first candidate, but the STUN-based candidates take a while to appear: if we send the first offer we can as soon as we can, then the STUN-based ICE candidates probably haven't had a chance to appear yet.
But I also see we construct an offer to send before we finish waiting for ICE gathering to complete, so I'm unsure how to square that with this theory.. unless NAT traversal is currently unreliable on high latency connections - I haven't tested that yet.
We are waiting for ice gathering completion before we start ice trickling. In theory, this should not be needed, and it's probably slowing down connection times on wasm, especially if the socket is configured with multiple stun servers. However, last I checked, if we removed the wait, nat hole punching started failing.
Solve the todo here:
matchbox/matchbox_socket/src/webrtc_socket/wasm.rs
Line 130 in d7696ad
Care should be taken to make sure that nat hole punching still works after.
The text was updated successfully, but these errors were encountered: