Menu
I wish to understand what generates the ICE candidates in a local webRTC application that does not use a STUN server.
233
ICE candidates. As well as exchanging information about the media (discussed above in Offer/Answer and SDP), peers must exchange information about the network connection. This is known as an ICE candidate and details the available methods the peer is able to communicate (directly or through a TURN server).
An ICE candidate describes the protocols and routing needed for WebRTC to be able to communicate with a remote device.
As it turns out, we can use WebRTC enabled communication without having to set up a STUN/TURN or signaling server. As long as both peers are on an IPv6 network.
Once the WebRTC Client has all the collected ICE addresses of itself and its peer, it starts initiating connectivity checks. These checks essentially try sending media over the various addresses until success. The downside of using ICE is the time it takes, which can be 10s of seconds.
Without a STUN server configured, the only candidates you might get from onicecandidate are host candidates, based on your system's IP address in its local network. The browser running on your system already knows this IP, and does not need ask a STUN server for it.
A STUN server is only needed to learn what IP addresses a system might be contactable on from outside a NAT. A STUN server acts as a mirror that sends back the IP it sees from packets sent through the NAT.
70
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
