I have been exploring further, and have noticed something strange.
When both clients connect behind the same NAT, everything works fine as it should.
However, when one of the clients is coming from a different network, the room states that the other is there, but they can't message nor exchange files.
Naturally this led me to look into Stun and webrtc-internals in Chrome.
My hunch seems correct since the webrtc-internals page appears to show both clients trying to establish a direct connection to each other's private, and not public, IP.
Hi,
I have been exploring further, and have noticed something strange.
When both clients connect behind the same NAT, everything works fine as it should.
However, when one of the clients is coming from a different network, the room states that the other is there, but they can't message nor exchange files.
Naturally this led me to look into Stun and webrtc-internals in Chrome. My hunch seems correct since the webrtc-internals page appears to show both clients trying to establish a direct connection to each other's private, and not public, IP.
googLocalAddress 192.168.1.7:60791 googRemoteAddress 192.168.0.100:36627
This doesn't make much sense since the same page shows indeed Stun being used
https://my.domain.com/testing/#bbb [stun:stun3.l.google.com:19302] optional: {DtlsSrtpKeyAgreement:true}
You can see I changed the stun server from the default one, but the problem remains with them both.
Why isn't Stun being used and directing media to the public IP instead of the private one?
Where can I look to debug this strange behavior?
Thanks