I get it now.
Google and other institutions have free STUN/TURN servers up and running to further the adoption of WEBRTC
So Supplying the Peers with the list of free STUN servers with our STUN server at the top.
Nope, it doesn't work like that !
Both parties (client/server) should know and use one STUN server unless you want them to connect to many, they should already agreed on where to meet .
Look at STUN as it is a simple proxy with extra functionality that register connections and tunnel the data between them, the client connections and the server (your server) will register as usual as delivery point within that one STUN server.
Would ensure that our STUN server has a long list of backups, while we also only have to run one STUN server ourselves and thereby ensure that the providers of free STUN servers don't feel abused.
What do you use to test the stun/turn servers?
First, you don't need a list as explained above, only one will be enough, so if you have your own STUN server, then hardcode its address:port in client and server, or (later down will explain neat trick i do always..)
I test STUN with the demos from sgcWebSocket, i had used it in the past with LakeOfSoft VC, so for me using the demo and watching the events is enough to know it is works.
I recommended sgcWebSocket because unlike LoS VC, it has so many features and these are networking, connections and security targeted, so very nice collection.
Now, we drifted from your first question into STUN and meeting protocols, so if you are able to provide your own public STUN, why not test
SSH with port forwarding, it is easy and simple and will work in most small boxes (my router have
SSH server), for your setup if you don't need very high traffic then it might be the perfect usage and will simplify your server part greatly as there is nothing to change to it, your server doesn't need to have an
SSH or you can add it internally, but a separated
SSH client on your server that will establish the
SSH tunnel to your public
SSH serve, and that is it !, also the client doesn't need to do any
SSH code or connection as the port they are seeing is acting the same as your own server (app) .
Also you can write your own tunnel a simple
TCP server server that listen and accept connections to a port then forward all the data into the connection from your server, in other words replicate the
SSH forward above but without
SSH, as you don't care about the data encryption here, because either your clients data is encrypted or not between client - yourproxy, so
SSH in this case will only provide security between yourproxy-server, which is useless as security measure.
What i am saying : don't complicate things for your self, and always use you are feeling good about, STUN or
SSH or your own tunnel,... now i remembered another approach might be even easy, use WireGuard with your own server, WireGuard is very capable to do tunneling and combining
IP's and establishing shared subnets...., but be please notice WireGuard is very easy to setup as there is just few settings, and very easy to miss setup.
The trick i wanted to share is, i use DNS TXT record to store important data for my networks applications, so in your case as example i would not hardcode your server
IP and port into the clients code but let them resolve a DNS with TXT record where the server connection point, it is the same as resolving the A/AAAA record but with extra information, i do many tricks like that .. etc pin the preferred security or the public key for the server.