Questions regarding using the Jitsi installation's own local stun server?

Questions regarding using the Jitsi installation’s own local stun server, for STUN_MAPPING_HARVESTER_ADDRESSES

In the file /etc/jitsi/videobridge/sip-communicator.properties .

There is a setting:

org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=meet-jit-si-turnrelay.jitsi.net:443

Why is the address “meet-jit-si-turnrelay.jitsi.net” used?

Can I change to my own Jitsi instance since the current Jitsi installation installs a local stun server?

org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=jitsi.mydomain.com:443

What are the pros and cons of doing so?

As Australia is a long distance from where “meet-jit-si-turnrelay.jitsi.net” is hosted, it seems possible to reduce latency and international network traffic by using a local stun server. If anyone who understands Jitsi well, can you please comment on my ideas of preferring to use the local stun server verses a sun server which is based on the other side of the world, transversing the pacific ocean via a submarine communications cable which is already saturated by network traffic.

The name “STUN_MAPPING_HARVESTER_ADDRESSES” indicates to me that the Jitsi installation will determine which stun server to used based on this setting, but is it possible to reduce CPU resources by directly defining the stun server so that the process of determining which server can be bypassed. Though I guess that this is not something that would take up a lot of CPU resources, is determined at the start of a call, and is then never called again during the meeting’s life.

Would this be away to bypass the determination of which stun server to use (when the public IP address is the same as the Jitsi server’s internal IP address)?

org.ice4j.ice.harvest.DISABLE_AWS_HARVESTER=true
#org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=meet-jit-si-turnrelay.jitsi.net:443
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=<publicIPaddress>
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=<publicIPaddress>

Despite my ideas and questions above, if my understanding of the STUN server’s purpose it is only used in the initial setup of a participant to a meeting, to help the participant’s side determine its internet facing IP address? And if this is true, there will be very little internet traffic, which only occurs once per participant (joining a meeting), hence any savings are only small.

The STUN server allows clients to find out their public address, the type of NAT they are behind and the Internet side port associated by the NAT with a particular local port. This information is used to set up UDP communication between the client and the VoIP provider to establish a call.

How does it work? The client, usually inside a private network, sends a binding request to a STUN server on the public Internet. The STUN server responds with a success response that contains the IP address and port number of the client, as observed from the server’s perspective.

1 Like

STUN_MAPPING_HARVESTER_ADDRESSES is used for the JVB to find its own address mapping(s) on startup if it’s behind NAT (as an alternative to hard-coding the mapping using NAT_HARVESTER_LOCAL_ADDRESS and NAT_HARVESTER_PUBLIC_ADDRESS or using the AWS harvester if on AWS). It is only relevant if your server is behind NAT.

It’s not the STUN address that is sent to clients for them to use.

It would not be advisable to use a STUN server running on the same machine for this purpose as it would not successfully discover the public IP since it is also inside the NAT. (OK for clients to use a STUN server on the same machine as the JVB though.)

The STUN addresses sent to clients can either be configured in Prosody’s config (if using mod_turncredentials or mod_external_services) or hardcoded in config.js.

1 Like

Thanks for the reply.

So these settings are not use at all when the Jitsi sever is not behind a NAT?

If you have time, please expand with a bit more detail on your above comment (particularly on exactly which setting in which files.

I think what you are referring to is (am I correct?)
/etc/jitsi/meet/jitsi.yourdomain.example-config.js

 p2p: {
...
        // The STUN servers that will be used in the peer to peer connections
        stunServers: [
            { urls: 'stun:jitsi.mydomain.com:3478' },
            // { urls: 'stun:meet-jit-si-turnrelay.jitsi.net:443' }
        ]
...

And even then, this is only used for p2p calls.

Correct.

And even then, this is only used for p2p calls.

STUN on the client is not needed for the client to connect to the JVB. It’s needed for P2P when both peers are behind a NAT, since a direct connection between them is not possible without discovering at least one of their public addresses.

3 Likes

So, we don’t even need any STUN server if I have video bridge not behind NAT and I don’t allow p2p call? that’s interesting and I have to look more into this as we don’t need stun server if one of the two peers (Video bridge <-> Client for more than 2 person conference and Client <-> Client for p2p) is not behind NAT, then how does the behind NAT peer’s ip address is being resolved? & when does TURN server come into play?

If you’re not using P2P then (client-side) STUN is not relevant. The clients both connect to the videobridge which has a public IP. (This is different from the STUN harvester that the JVB can use to find out its own NAT mapping.)

TURN is still needed though if a client cannot reach the videobridge over UDP, since TURN can relay for them using TCP. The videobridge does have TCP support but it’s inferior to TURN/TCP and disabled by default.

1 Like

so normally I don’t need turn server? or how can I decide that whether I need it or not or does this have any performance improvement/impact?
in our conference we have disabled p2p and don’t have turn server but still from network stats sometimes I see the network connection is TCP and normally UDP. what does it mean actually?
and Thanks for the reply with useful info’s…!! :heartbeat:

If you have no TURN server, then you should enable the TCP harvester in the videobridge so that clients can use TCP for media if UDP is blocked (e.g. behind some corporate firewalls). It should usually work OK, but since it doesn’t do a real TLS exchange some strict firewalls will still block it. And by doing it this way you put more load on the JVB, since the JVB does a lot more work to forward media than a TURN server does.

Your question about seeing TCP in your network stats is too vague to really answer. It might be that you already have the TCP harvester enabled, or it might be that you’re seeing other unrelated TCP traffic.

1 Like

Apologies jbg, I am still confused on the matter of STUN and STUN_MAPPING_HARVESTER_ADDRESSES.

If the Jitis server is not behind a NAT and does not require these settings, how does the JVB server know its own address mapping(s) ?

Is it still useful for JVB servers which do not use NAT, and therefore their internal IP address is actually also its Public Internet address, to be told that their Internal IP = Public IP in some way?

For example, for JVB severs which are directly connected to the Internet (i.e. Internal IP = Public IP) would it still be useful to state the following information ? :

org.ice4j.ice.harvest.DISABLE_AWS_HARVESTER=true
#org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=meet-jit-si-turnrelay.jitsi.net:443
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=<publicIPaddress>
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=<publicIPaddress>

What I think I am asking is;
When the JVB server is not inside a NAT, :

  1. how does JVB server know it is not inside a NAT?,
  2. how does the JVB server knows what its public IP address is?,
  3. how does the JVB server know that its Internal IP = Public IP ?

If the answer is the “JVB server has to determine these facts”, then in what way can I tell the JVB server this information so that it does not need to determine this information?

If the answer is the “JVB server does not need to determine these facts” Maybe this configuration is correct for a JVB server who’s Internal IP = Public IP ?

org.ice4j.ice.harvest.DISABLE_AWS_HARVESTER=true
# org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=meet-jit-si-turnrelay.jitsi.net:443
# org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=<publicIPaddress>
# org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=<publicIPaddress>

If it’s not behind NAT, then there are no mappings needed; the IP addresses it binds are public IP addresses.

It’s not necessary.

This could be useful if the server has multiple IP addresses and you want to explicitly select one. You can also use org.ice4j.ice.harvest.BLOCKED_ADDRESSES to achieve a similar goal though.

The default assumption is that the address JVB binds is the address that it will advertise. Configuring NAT mappings adjusts that assumption. Without NAT, it doesn’t need adjusting.

The OS tells it what addresses the system has.

See #1.

This is fine. The file can also be empty; if you’re not on AWS then the AWS harvester doesn’t do anything.

Thanks again for your quick reply, jbg.

As my Jitsi servers is directly connected to the Internet, its internal IP is also its public IP, so I have commented out all three harvester lines as per my last configuration. And guess what, the Jitsi server still works. I would not have known I could do that, if it was not for your explanation.