Anwendungs Server als Client betreiben mit Indy

[QuickAndDirty]

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.
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?

Edit:
According to this Document I would need a TURN server.
https://www.viagenie.ca/publications...n-turn-ice.pdf
I'm beginning to understand what it's all about.
Never would have thought that STUN works behind a Sophos Firewall. It needs a TURN Server.

[Kas Ob.]

Zitat von QuickAndDirty:

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.

Zitat von QuickAndDirty:

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.

[QuickAndDirty]

I'm in the process of reading on STUN and TURN.
I think it will be a STUN/TURN server combination at the end.
I was baffeled that all but symmetric NAT are basically unsafe and open to the STUN procedure...
Every NAT that can use STUN is basically vulnerable for a port scan.
That's why all NAT/Firewalls out there in corporate newtworks are symmetric NAT.
So these Symmetric NAT need a relay server that can also relay TURN connections.

Now I'm trying to under understand ICE candidates and why the way they are exchanged isn't part of the god damn specification.

[Kas Ob.]

Here an article might help
https://community.cisco.com/t5/colla...e/ta-p/4766853

The article mostly UDP focused, because UDP .. well you know the differences from TCP, but what not very popular knowledge that is UDP is very fast, really faster that TCP, but with problems with dropped and not-queued packets, here comes the even more powerful protocol DTLS to remedy the reliability and security in one go.

Notice that HTTP3 is mostly based on Google QUIC https://en.wikipedia.org/wiki/QUIC and it is beat HTTP(S) over TCP in every speed test and latency, with TLS1.3 DTLS (where TLS1.3 provide 0 or 1 roundtrip hand shake) can outperform anything you heard of.

About ICE : it is to some degree can be avoided, in other words you can ditch it altogether, and replace it with any mechanism you prefer, like simple HTTP request to your own server to made the first signaling and ID tickets, a mean to establish the meeting point and decide on TURN or STUN, i still prefer STUN and there is STUNS which is DTLS over STUN, it is simpler and have wider usage and support.

Anyway, knowledge is priceless, so keep reading and good luck !