Connection drops immediately after connecting

Currently using PeerJS with Meteor (here is the project: https://github.com/domschiener/peered). Everything works fine locally on the same connection, but as I deploy it to my server and try to connect with a friend, the connection is very unstable and oftentimes drops immediately after connecting.

Anyone have an idea as to why that could be?

PeerJS:  Socket open
Success! Your Peer ID is: Ajrgmd6A3KwDLnuoB
PeerJS:  Creating RTCPeerConnection.
PeerJS:  Listening for ICE candidates.
PeerJS:  Listening for `negotiationneeded`
PeerJS:  Listening for data channel
PeerJS:  Listening for remote stream
PeerJS:  Setting remote description RTCSessionDescription {type: "offer", sdp: "v=0
↵o=- 6918372162384193671 2 IN IP4 127.0.0.1
↵s…id:data
↵a=sctpmap:5000 webrtc-datachannel 1024
↵"}
Received new connection ERQFHRAHkFDRMLnJf
PeerJS:  Set remoteDescription: OFFER for: ERQFHRAHkFDRMLnJf
PeerJS:  Created answer.
PeerJS:  Set localDescription: answer for: ERQFHRAHkFDRMLnJf
PeerJS:  Received ICE candidates for: ERQFHRAHkFDRMLnJf
PeerJS:  Added ICE candidate for: ERQFHRAHkFDRMLnJf
PeerJS:  Received data channel
PeerJS:  Data channel connection success
PeerJS:  DataChannel closed for: ERQFHRAHkFDRMLnJf
PeerJS:  Cleaning up PeerConnection to ERQFHRAHkFDRMLnJf
Connection closed```

[abardik]

@Bobisback, You don’t have to setup your own TURN for testing purposes (look at the comments above about numb.viagenie.ca).

Maybe it can be usefull for somebody, so I’ll try to simplify some webrtc details here.

The webrtc idea is to connect two devices directly to each other the shortest and fastest way. If devices on the same host, the first candidate (127.0.0.1 typ host) is used. This candidate is available anytime and anywhere if your device’s network adapter is not disabled. And any clients on this one host can connect to each other directly. If your devices in the same network, another candidate will come in help (local_network_address typ host). Webrtc clients use this type of candidates next after localhost. And it works because all of your local network devices have a ‘physical’ connections between each other. In other words, if you can ping other computer, you can reach it with webrtc.

Next, if your devices in different networks or network segments, including internet, they can’t ping each other (and connect to each other with webrtc or anything else) if they don’t have a direct public IP address (dynamic or static, it doesn’t matter). The examples are everywhere: any office computer, most of home computers behind Wi-Fi router, etc. In this situation, STUN with UDP hole punching technique is coming to help. To be pretty simple, your device makes a request to STUN and receives a response with global IP:port, with which it connected to STUN (this IP:port is your internet provider’s NAT IP:port which is used to transfer your requests and receive responses from web servers). Today, by statistics, in ~80% situations regular NATs will receive packets and transfer it to your device not only from hosts you requested, but from any other hosts. So, you can send this IP:port to another webrtc client, and that client can connect to this IP:port and send you any data. Once again, this is an external well-reached from anywhere IP:port of your provider’s NAT (not yours), which is used then to transfer incoming packets to your host only. This is called a UDP hole punching (you can google a detailed explanation with examples). And this IP:port from STUN is a ‘srvflx’ candidate in your webrtc logs.

But in some situations (~20%) NAT accepts packets on that IP:port only from the same host you sent request to, or uses new port for every single request-response. So, if you send a request to google STUN (and NAT assign some port to you for this request), it will accept packets (or even just one response) on this port from google STUN only and from nobody else. This kind of NATs are called ‘symmetrical NATs’. In this case, your webrtc client will try to use ‘srvflx’ candidate and will fail. And here we have TURN.

TURN provides public IP:port for you to send it to other webrtc clients as your ‘relay’ candidate. Webrtc clients will try to use ‘relay’ candidates only if they failed to connect with ‘host’ and ‘srvflx’ candidates. Actually, the algorithm a little bit smarter and uses candidates based on not only ‘typ’, but on ‘network-cost’ and other parameters. TURN works like your company’s NAT and provides a real always reachable public IP:port (dynamic or static), but without ‘symmetrical issue’. But all of your trafic is going through your TURN now. So, you have to place your TURN in well accessable locations, such as AWS infrastructure.

The last thing about establishing webrtc connection is a ‘trickle ICE’. This technique is invented to reduce a connection time. Without it webrtc client sends SDP only when it got all candidates from its network, STUN and TURN servers. This collection work could take a lot of time (seconds). So, with trickle ICE enabled, webrtc client sends SDP as soon as it obtained its first candidate (which is localhost typ host). Another peer can reach this candidate if they both works on the same host. So, it makes sense to send an SDP immediately. Then, local network candidates are obtained (it’s very fast) and sent, and it’s possible to connect to all computers in your local network (no delay, practically). If your peers in diffefrent networks, the ‘srvflx’ candidate should be obtained from STUN (1-2 seconds) and used to try to connect. And, finally, TURN candidates (another 1-2 seconds). So, to avoid this delay, webrtc clients try to connect as soon as possible and then they send additional candidates, and another peers try to connect with those new candidates until they are connected. Even if a connection is already established, webrtc clients can use another candidates if they decided (based on network-cost parameter, for example) that new candidate is better then old one. Sometimes this technique fails, and we have dropped connections in a few seconds after successful connect.

So, if all of your devices are in the same network segment (wi-fi or ethernet), you don’t have to use any STUN or TURN, because all of your devices are ‘pingable’ to each other. But, if you have some kind of personal or corporate firewall or something that can block incoming or even outgoing trafic on your devices, you could hit this (fire)wall. I never experienced this kind of problems before, but theoretically it could be.

Try to find any pure webrtc example (no peerjs or other libraries). If you have no netwrok limitations you will connect in any direction. And then you can continue your experiments with peerjs.

[abardik]

If you successfully established LTE connection and transfered some data and it has been live for several minutes, than I believe the reason of your initial issue is gone. Now, I think you have another problem - unstable connection. It can be anything. For example, bad LTE signal or bug in your code. You should try to write as simple test as possible to exclude your bugs. But from the other side, your serverreflexive candidate is failed on your screenshot. Without srvflx candidate you can not rich remote peer if your device does not have a public IP (it’s true for many home routers and LTE devices). If you have established LTE connection, than: a) you have a public IP and your connection is established with host candidate; or b) your screenshot is outdated because it’s not possible to connect to remote peer without public IP and with failed srvflx (STUN) and/or relay (TURN) candidates. Anyway, it’s hard to say something more usefull without being on your computer, sorry.