Jitsi Meet behind NAT and Nginx reverse proxy

Hi Jitsi Team,

Recently, I need set up a Jitsi Meet Sever behind NAT and Nginx reverse proxy to serve the video conference which can be joined by the web clients both from outside the NAT and inside the NAT. This is my goal.

After went through many tips in this forum, I prepared a network design as below picture.
I have two questions about it, would you please share your light on these.

  1. Which IP I should set for @JISTI_IP and which IP I should set for @PUBLIC_IP (red color in the picture)
  2. Is there any other configuration of Jitsi or Network I should set for the goal I mentioned above.

Use the more modern jvb.conf config file, you can create multiple static mappings, one for your public IP and one for your private one.

Hi Saghul,
Thanks for your response, would you please share more example about the “modern jvb.conf” you mentiond?

This is the jvb.conf reference file: jitsi-videobridge/reference.conf at master · jitsi/jitsi-videobridge · GitHub

And here is how you can configure ice4j with multiple static mappings: docker-jitsi-meet/jvb.conf at 4a0b48c4118b9df5242dd2152303edb810e5b942 · jitsi/docker-jitsi-meet · GitHub

Thank you saghul, I will try jvb.conf changes in my lab later.

Two more questions,

  1. I think there is no need to both change jvb.conf and sip-communicator.properties, Either changes in jvb.conf or sip-communicator.properties should be ok, , right?

  2. I wonder when I use below configuration changes in sip-communicator.properties:

whether I need to uncomment the line in jitsi config.js or not as below:
// Disables ICE/UDP by filtering out local and remote UDP candidates in
// signalling.
webrtcIceUdpDisable: false,

You should switch to the former, since the latter is deprecated and support for it will eventually go away.

No you don’t need to uncomment that, it’s off by default.

Oh, That’s big information for me. So I will try jvb.conf way asap, thank you

Would you please share from which version “the jvb.conf way” was supported and from which version the sip-communicator.properties way will be deprecated? Do we have such information now?

IIRC it has already been deprecated for a while, but dropping support for it likely won’t happen soon, so no rush.