I'm having a weird issue with a WebRTC connection between 2 users on different networks.
User A is using a phone hotspot, user B is on my home WiFi.
When user A is the first to join the page, this user sends an offer and some ICE candidates to user B. User B sends an answer and some ICE candidates back to user A, but after about 20 seconds the ICE connection state changes to "failed" (safari) or "disconnected" (chrome). User A and user B are unable to setup a working WebRTC connection.
However, when user B is the first to join the page & creates the offer, and user A sends back an answer, both users are able to connect without issue.
In both cases, user A & user B both have a correct looking localDescription & remoteDescription on their end, but in the second case where the connection fails, the connectionState & ICEConnectionState are "failed" (safari) or "disconnected" (chrome) for both users.
I am using both a TURN and STUN server in my RTCPeerConnection's configuration, and tested the server is working properly using the Trickle ICE WebRTC example
I suspect that somehow user A or user B are unable to see or use all the available ICE candidates for the other user, however I'm unsure how best to troubleshoot the issue. Is there an easy way to see what ICE candidates are available / active for a given RTCPeerConnection object?
Update:
Looking at the chrome://webrtc-internals (as philipp-hancke sugested) shows that
if user B sends the offer:
4 ICE candidate pairs are available (2 host, 1 srflx, 1 relay)
An ICE candidate pair using the external IP for user B, and a TURN server relay for user A is selected. The connection works.
If user A sends the offer:
Again 4 ICE candidate pairs are available (2 host, 1 srflx, 1 relay), but the ICE Candidate pair shows (not connected) and no WebRTC connection is made
Update 2: I've accepted Philipp Hancke's answer since it answered the initial question I asked, even it I haven't solved my problem yet. I've asked a new question here.
This sounds like a long-standing bug in webrtc. Using TURN servers typically solves the problem which explains why this hasn't been a priority for anyone to work on.
chrome://webrtc-internals is the one-shop-stop location to go for debugging issues like this.