2

I'm using the chrome://webrtc-internals/ URL to debug our WebRTC application behavior when the STUN/TURN servers are down. One interesting thing I'm noticing is that under "Stats Tables" there appear to be good, "peerreflexive" local ICE candidates being generated, for example:

Cand-2rjZ43jF (localcandidate)
Statistics Cand-2rjZ43jF
timestamp   10/24/2017, 9:19:39 AM
ipAddress   192.168.59.1
networkType unknown
portNumber  40555
priority    1845501695
transport   udp
candidateType   peerreflexive

The thing is this candidate never comes to me through the onicecandidate callback.

Is this just an internal quirk of Chrome or is there a way to get these perfectly good candidates?

mpr
  • 3,250
  • 26
  • 44

1 Answers1

1

I don't know exactly how this ICE candidate is generated. But as you can see, the candidate points to 192.168.59.1 which is your LAN IP address. So this candidate will only work for connecting to someone at the same LAN as you're computer.

kontrollanten
  • 2,649
  • 19
  • 32
  • Yes this is in fact the standard scenario in our application--which is designed more for LAN usage. Really we don't want to use ICE/STUN/TURN at all, but it's a required part of WebRTC. – mpr Oct 24 '17 at 21:56
  • I wouldn't say it's a required part. It depends on use case. You can setup a call between two browser parts without defining any STUN/TURN servers. I haven't tried to make a call to another computer on the same network, but it should work the same way – kontrollanten Oct 24 '17 at 21:58
  • Well part of the signaling portion of the protocol is to exchange ICE candidates, and when the STUN/TURN server doesn't respond, Chrome doesn't generate any "icecandidate" events, from what I'm seeing. I posted the question because curiously enough, the webrtc-internals URL does show some candidates and I'd love to attempt to use them. – mpr Oct 24 '17 at 22:20