Clients behind Non-symmetrical NAT failed to connect with each other. STUN servers worked only for clients within same network

[linegel]

What version of this package are you using? Latest from NPM

What happened? Connection with video stream failed. All similar issues answers suggest that TURN server is required to solve it BUT accordingly to RFC this ONLY should be required to connect clients when at least one of clients is behind symmetric NAT.

NAT was tested with that tool repo

What did you expect to happen? Connection to be created.

Are you willing to submit a pull request to fix this bug? I have no idea why it doesn't work, unfortunately :(

[felquis]

Try using config iceServer with stun:global.stun.twilio.com:3478?transport=udp as it is described in the README.md https://github.com/feross/simple-peer/blob/d47e7ce672ee7d36ac00d28cd5ce46f95535f644/README.md#api

It solved my problem.

For more info check the https://github.com/feross/simple-peer/blob/d47e7ce672ee7d36ac00d28cd5ce46f95535f644/README.md#connection-does-not-work-on-some-networks

relevant source https://github.com/feross/simple-peer/blob/f1a492d1999ce727fa87193ebdea20ac89c1fc6d/index.js#L1038-L1048

Instantiation example:

new SimplePeer({
    trickle: true,
    initiator: true/false,
    config: {
      iceServers: [
        { urls: 'stun:stun.l.google.com:19302' },
        { urls: 'stun:global.stun.twilio.com:3478?transport=udp' }
      ]
    },
  })

[byrond]

It seems like ?transport=udp is invalid for a STUN server URL in most browsers. I get errors like this:

Error creating offer: SyntaxError: Failed to construct 'RTCPeerConnection': 'stun:global.stun.twilio.com:3478?transport=udp' is not a valid stun or turn URL.

I have tested using this tool: https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

Our issue may or may not be related to non-symmetrical NAT. Clients connected to the same VPN node (with the same public IP) are not able to establish WebRTC connections but can connect to STUN servers and get a public IP srflx response. If clients are connected to different VPN nodes with different public IP addresses, a connection can be established. I assume clients behind the same public IP are forced to traverse the NAT (VPN), but maybe simple-peer doesn't like this for some reason (clients connecting with each other using the same IP)?

When we use the JS fiddle on this page while connected to VPN, it returns "normal NAT": https://webrtchacks.com/symmetric-nat/

When we add two STUN servers to the trickle ICE testing page (link above) in Firefox, we see two "srflx" responses with the public IP and different ports. I understand sometimes that means it is a symmetric NAT.

We have so far been unable to determine whether this is a NAT, VPN, WebRTC, or simple-peer issue. Any ideas on how we can narrow this down?