WebRTC, STUN and TURN in case of local user and remote ones

Hi All,

Hope there’s a good soul who could point me in the right direction to understand if problems are expected to block deployment or not.


  1. Sizing; 2-5 users (family & friends)
  2. Utilization - rare (one or two calls a day, not long) - hence rare use.
  3. JItsi to be placed as docker image on the SystemA
  4. SystemA is behind router (local IP, but port forwarding not an issue).
  5. ClientA will be browser sitting on SystemA
  6. Other clients will be remote over WAN/Internet.

Expected problems:
a) STUN might get confused as ClientA will have LAN IP.
b) considering Jitsi would be in docker maybe having ports mapped and not bridged/host networking - could help (TBC).
c) because of A, call might be pushed to TURN.
d) with 1o1 call - not much of a problem re bandwidth.
e) biggest question is how connections will work in terms of call with i.e. 3 participants (where one of them is ClientA - on same system as SystemA/Jitsi in docker).

Did my RTFM but probably (hope not) not enough, i.e.

Expectation is that STUN will fail in case if ClientA is involved, but will all participants get audio/video via TURN or only to/from ClientA? This is where I’m confused the most.
Understanding is that in case of a call without ClientA - STUN will work and no TURN will be in use (assuming these clients have all requirements in terms of NAT, etc. to allow use of STUN).

From networking side the idea is to somehow enforce hairpinning (as on GCNAT) with use of iptables, i.e. by user initiating session, to SNAT packets with destination to local IP, etc. biggest problem am seeing is that it is all on the very same system, so the only option might be to use pre-routing chain (not sure if possible at all, even if multiple IPs would be used on single interface - it will be still same IP stack on localhost).

The need is to avoid setting up Jitsi in thirdparty location or on separate system from SystemA.

Context: SystemA function is to literally run Jitsi “server” and browser in kiosk mode to be connected to call upon a trigger.

Any ideas are more than welcome on how to set it up.

this is way more difficult than setting up a VPS. Before trying it you have to ensure you have enough bandwith to work if not you will waste a lot of time. For 5 external users you will need at least 20-50 Mbits/s uploaddepending on quality. Your computer being both a client and a server will need plenty of CPU/Ram to be responsive.
After that you need a true certificate (Let’s encrypt) and a split DNS for your local client. If you can forward external ports 80, 443 and 10000 to your Docker I don’t see why you should bother with Turn and stun, things will be painful enough.

Thanks @gpatel-fr.
The question is really about how the 3 way call would look like connectivity wise (who with who and how), especially given one client in LAN/localhost (SystemA/ClientA).

Bandwidth shouldn’t be an issue, neither is certificate. Am more concerned of the NAT traversal etc. issue.

VPS side is a monthly cost of something which might be used once a week for 30-60 mins sometimes 2h and to get right resources it is not peanuts, i.e. eurovps is ~80EUR/month. The key is that server has to be up and running, so can’t use idea of pausing or shutting down server, would take too long to start on i.e. AWS EC2 and gets complicated.

The idea is also to have it running on own resources and to not buy a service elsewhere.

So the question is back to academic one - how WebRTC, STUN, TURN and connectivity would look like in case of 3 way video call (let’s forget about resources, etc. at the moment).

Well, the only sane way is to mimick completely what happens when an Internet user accesses a VPS, that is, you should have a split DNS (local DNS that emulates the true DNS and returns a local address instead of the internet one, that is, if an internet user asks for meet.jetson.org, it gets if that’s your internet address, and if the local user - you on your ‘server/workstation’ computer - asks for meet.jetson.org, you get - the local address of your container - and your ISP box redirects to If you have that, turn, stun, will sort themselves out (your container should have also full internet access).
Note that I don’t know Docker, I assume that you can do the same on Docker that you could do with a Linux container.

@gpatel-fr - thanks again.

Would you or anyone else, please be able to describe the WebRTC, STUN and TURN (if gets involved to establish connection).

Let’s have 3 examples (picture below) - guess is it is mainly about video connection as audio unless 1o1 call needs to be mixed at the server?:

  1. call between ClientA and ClientB.
    a) will the STUN manage to get direct (p2p) connection between ClientA and ClientB for video and audio?
  • take one - negative: My take is that, it won’t work, cause NAT escape/traversal will cause UDP packets sent from ClientB to STUN server in SiteA and this will open “whole in the firewall” or via UPnP, but ClientA given having direct reach to STUN - won’t open any whole
  • take two: more positive: Having ClientB opened connection, if ClientA would try to contact ClientB - then it would use already the whole in ClientB firewall, and at the same time would open whole in its own SiteA firewall - so practically it would work, but given it is not coordinated by STUN, then it won’t work in current implementation.
  • take three: client side portion is smart enough to send back packets to ClientA and it will just work then with direct connection.
    Fallback option is that it will turn into TURN based connection going via Server.
  1. ClientB to ClientC
    a) both can open NAT via escape option or UPnP - both coordinated by STUN.
    b) will the video stream be sent directly/p2p between the two?
    c) audio stream - will be sent directly too or via server?

  2. All three clients in the call connectivity is possible as per above but given 3 ways call questions are:
    a) ClientB and ClientC for video streams - will they have direct connection or regardless of network connectivity capabilities it would go through server in SiteA
    b) audio stream - will go through server in SiteA as needs to be mixed or mixing is done at client end?

I’m trying to get to the bottom of how WebRTC, STUN and TURN get connections in Jitsi.
Getting NAT 1:1, or multi-NAT is not an issue - the unknown portion for me is the Jitsi components behavior.
From the reading it seems like most of the time video streams are routed through server, but question is if it depends on activation of some of functionality on Jitsi or is not possible at all ot have direct video stream between participants? WebRTC with STUN sounds like allows that.

I’m all happy to do homework and read some docs on Jitsi components and all am looking for is a point into direction where examples are discussed or logic, which will give me answers on these questions.

Thanks again!

Sorry, I have never felt the urge to be a teacher in my wretched life :slight_smile:
I know next to nothing about STUN and I hope fervently never to have to know more; I have dumped all I know about TURN here. Good reading and good luck.

Thank you for all your help.

Just to make summary of findings.
Jitsi plays TURN server for more than p2p call or can be forced to do it even in case of such call.
Normally for p2p (1o1 call) direct connection is established with h264 codec. With play of settings Jitsi can be forced to do that for other calls too (but for 3 or more participants it will always play TURN server.

The key finding was that Jitsi is SFU (Selective Forwarding Unit).
There’s good read about it: https://testrtc.com/different-multiparty-video-conferencing/
With that digested everything has became clear.

@gpatel-fr - thanks again for your swift replies.