I\'m trying to make a peer to peer Javascript game that can be played on mobile browsers.
There are a few different factors that could at at play here.
I would determine what NAT type you are behind on each side, you can read more about that here https://webrtchacks.com/symmetric-nat. If both networks are behind symmetric NATs you are going to need a TURN server.
If you don't have a browser you could also use Pion TURN a Go TURN client and server.
I would also check when gathering candidates if there is an intersection on IPv4/IPv6. Some phone providers are only giving out IPv6.
UDP may not be allowed at all. This isn't common, but possible. In this case you will be forced to use TURN. NAT traversal via TCP is possible, but not supported by WebRTC AFAIK.
A TURN server is a solution to the problem. If there were workarounds that didn't require it, nobody would be using it. A common misconception here is that if you add a TURN server to the system, it will relay all traffic. That isn't true, it is only used as a fallback for the connections that can not be established otherwise. In comparison to the alternative of routing all your game messages through a websocket server this will still save you 80%+ of the traffic.
The next step is to install a TURN server. coturn is widely used and reasonably well documented. It is stable enough that, once setup, the amount of maintenance required is very low.