webRTC - Failed to set remote answer only for public (LAN or same access point works fine)

I use RTCMulti and all works fine if i use my own wifi point.

I have running turnserver.

For public not work.

Error can be :

 InvalidStateError: Failed to execute 'setRemoteDescription' on 'RTCPeerConnection': Failed to set remote answer sdp: Called in wrong state: stable 

 can be also have-remote-offer

Why in LAN works fine but not working public?

direct link

Source

UPDATE :

I have coturn already on my cent8 Vps and i activate turn server.

Maybe something wrong here:

# Coturn TURN SERVER configuration file

listening-port=3478
#
tls-listening-port=5349

listening-ip=159.89.8.40

relay-ip=159.89.8.40
#relay-ip=2607:f0d0:1002:51::5

external-ip=159.89.8.40

realm=maximumroulette.com

cert=/etc/letsencrypt/live/maximumroulette.com/cert.pem
pkey=/etc/letsencrypt/live/maximumroulette.com/privkey.pem
log-file=/var/log/coturn/turnserver.log

simple-log
allow-loopback-peers

cli-password=qwerty

# Do not allow an TLS/DTLS version of protocol
#
#no-tlsv1
#no-tlsv1_1
#no-tlsv1_2

Also in my client part i have :

    stunList: [
      "stun:maximumroulette.com:19302",    << IS IT CORRECT
      "stun:maximumroulette.com:3478",   << IS IT CORRECT
      "maximumroulette.com:3478",     << IS IT CORRECT
      "maximumroulette.com:5349",   << IS IT CORRECT
      "stun:stun.l.google.com:19302",
      "stun:stun1.l.google.com:19302",
      "stun:stun.l.google.com:19302?transport=udp",
    ],

Also can be something about CORS maybe:

I dont know how but my web page cert info gives :

Common Name (CN)    ai.maximumroulette.com
Organization (O)    <Not Part Of Certificate>
Organizational Unit (OU)    <Not Part Of Certificate>

Look like my main page is under subdoimain...

Solution

When your WebRTC setup works fine on your local network (LAN) but encounters issues over a public network, several factors can contribute to the problems you’re experiencing. The InvalidStateError that you’re seeing indicates that there are issues with the signaling state of your peer connections, particularly around the negotiation of session descriptions (offers and answers).

You need a TURN server like Coturn and a signaling server to support such configuration like WebRTC Signaling with STUN/TURN support in NodeJS. Try the WebRTC live streaming demo first, to make sure it works for your scenario.

Here are some common reasons why you might encounter these issues only on a public network:

NAT/Firewall Issues:

Local networks (LAN) often have minimal NAT (Network Address Translation) and firewall configurations, allowing direct communication between devices without interference. Over the public internet, however, NAT and firewalls can block or reroute the traffic needed for a peer-to-peer connection.
This is where your TURN server comes into play. A TURN server relays traffic between peers when they cannot establish a direct connection due to NAT or firewall restrictions. Ensure your TURN server is correctly configured and accessible from outside your network.

Timing and Asynchronous Operations:

The error related to setRemoteDescription being called in the wrong state often occurs if your signaling isn’t properly synchronized. For example, attempting to set a remote description when your peer connection isn’t expecting it can lead to this issue.
Ensure that your signaling messages (offer, answer, candidate) are handled in the correct order. You might need to implement more robust handling to queue these operations until the peer connection is ready to process them.

Session Description Protocol (SDP) Negotiation:

The error message suggesting issues with remote offer handling (have-remote-offer) implies that there might be confusion or mismanagement in the SDP negotiation process.
Check how offers, answers, and ice candidates are being handled and applied. Ensure that you are not sending an answer or applying candidates before an offer is properly set.