If you start to work with WebRTC you'll notice that onicecandidate returns many types of candidates, I was wondering what are they, because in my case the connection involves only 2 phones, but I receive many other candidates.
If you work with this event you'll probably code something like this:
Which represents the phase that you see other candidates in the server.
According to MDN It does : "fired to indicate that a new candidate has been gathered. This candidate needs to be delivered to the remote peer over the signaling channel your code manages."
Okay, now if we look to the logs, we'll see something like this :
And here comes my questions. What I discover after reading the docs is that this other candidates are simply other routes from the same phone (or any device) to ensure that the connection will occur.
Why do several appear :
- The device has multiple interfaces (Wi-Fi, phone, IPv4, and IPv6), and each interface generates a "host" candidate.
- The STUN server map uses the public IP/NAT and generates "srflx" (server-reflexive) type candidates.
- If there is a TURN, "relay" candidates appear.
- ICE can also generate "prflx" candidates during P2P checks.
Expected behavior :
ICE will try all options and choose the one that works best; manual filtering is not necessary in most cases.
In this phase you must send this candidate (which will be picked automatically) to your backend server (probably a WebSocket). MDN docs also said the same:
In my case I'm sending a webrtc_ice_candidate type message to indicate that a new candidate has gathered.
Top comments (0)