[Questions] - [help]: how to config turnserver.conf for this use case?

[walteroa2023]

Hi experts, Im newbie in WebRTC, but as far as I understood, in order to communicate 2 agents in different networks I should use coturn, as suggested by pairdrop (kinda airdrop, but multiplatform http://github.com/schlagmichdoch/PairDrop).

Now, the case is:

• fake Public IP (in fact, fake, because is behind CGNAT): 181.186.20.66
• real Public IP: 100.125.188.144
• Home router: port forwarding from fake public IP to internal Reverse proxy
• Reverse Proxy (npm) running on docker as container: 10.0.0.250 ports 80 & 443
• PairDrop Server running on docker as container: 10.0.0.250:9100 mapped in RP to fqdn: drop.micasa.ar
• Coturn running running on docker as container: 10.0.0.250:3478
• server name: srv1
• domain name: micasa.ar

Traffic Flows: (need to communicate to each others)

1) Agent A and Agent C, both in the same internal network, no NAT, no need to use TURN/STUN. [green agents] 2) Agent A (on internal network) and Agent B (on mobile network), so in this case TURN/STUN has to be used to enable peer to peer flow. [green agent vs. pink agent]

My questions: (coming from turnserver.conf)

• what should be my realm name?
• what should be my server name?
• what should be my listening IP?
• what should be my public IP?
• should I have a relay address? or not needed?
• should I have a leg into DMZ or direct exposed to internet?
• if no, should I have a port forwarding for STUN/TURN ports in my home router?
• should it work behind CGNAT?
• How to test this environment?

Sorry, too much questions, but no idea how to start with turnserver.conf ...

Thx a lot in advance!

[eakraly]

Hi @walteroa2023

Looking at your network configuration it looks like putting your TURN server in the same network as one of the clients defeats the purpose of having TURN. The idea of having TURN in between 2 clients is when they cannot reach each other directly (because NAT) but they can reach out to some common network (usually public internet) where you put TURN server which allows connection between the clients. When you put your TURN server in the same network as pairdrop you basically stay with the same issue - your AgentB not able to reach your internal network.

Now to your questions (most of them easily answered by looking into README.turnserver):

• Realm name: whatever you want - "walteroa2023-super-awesome-realm" is fine :)
• Server name: probably do not need that one
• Listening IP: I guess that is the IP you got from docker (10.0.0.250) since this is the only IP turn has
• Public IP: your real public IP 181.186.20.166
• Relay IP: not needed in your case
• As I mentioned above - something you probably must have. If TURN cannot allocate directly accessible connections from Internet then it will not be functional (as peers will not be able to reach it). If you can "plumb" your turnserver to a public IP without NATs in between that will allow it to work.
• Again, probably not.
• Testing: you must test it from Internet (aka AgentB) using turnutils_uclient or https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/