Fresh-ish install with current. no fallback to 4443 - no video/audio when 3rd user joins

been fighting this upgrade all day! :smiley:
I can’t foward udp ports through haproxy, so I need to use tcp port 4443. However, it doesn’t appear 4443 is listening when running netstat. udp 10000 does show up. I have tried to add
org.jitsi.videobridge.TCP_HARVESTER_PORT=4443 to videobridge sip-communicator.properties without any luck.
Any thoughts?

How are you forwarding through haproxy, is it http or http2?

for 443, its http2

for 4443 its just tcp passthru

this all worked fine prior to may failed attempt to upgrade. instead of giving up and rolling back, Im going to fight through it!

And you are having valid certificates on the web-frontend and coturn?

I don’t think coturn is running…I installed without turn-server option…
yes…using valid certs…but haproxy is set not to validate jitsi webserver. I’m able to get to jitsi and can get a p2p going without issue if that means anything.

I’m not sure you can front bridge tcp port with a haproxy, as this is not http traffic, you need to port forward that, it will not work otherwise.

If your only option is this haproxy forwarding you need coturn. This is how it looks on a clean install:

# netstat -anp | grep -e nginx -e turn
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      5400/nginx: master
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      5400/nginx: master
tcp        0      0 0.0.0.0:4444            0.0.0.0:*               LISTEN      5400/nginx: master
tcp        0      0 10.19.0.5:4445          0.0.0.0:*               LISTEN      5570/turnserver
tcp        0      0 1xx.xx.xxx.xxx:4445     0.0.0.0:*               LISTEN      5570/turnserver
tcp        0      0 127.0.0.1:4445          0.0.0.0:*               LISTEN      5570/turnserver
tcp        0      0 10.19.0.5:4445          0.0.0.0:*               LISTEN      5570/turnserver
tcp        0      0 1xx.xx.xxx.xxx:4445     0.0.0.0:*               LISTEN      5570/turnserver
tcp        0      0 127.0.0.1:4445          0.0.0.0:*               LISTEN      5570/turnserver
tcp6       0      0 :::80                   :::*                    LISTEN      5400/nginx: master
tcp6       0      0 :::4444                 :::*                    LISTEN      5400/nginx: master
tcp6       0      0 ::1:4445                :::*                    LISTEN      5570/turnserver
tcp6       0      0 ::1:4445                :::*                    LISTEN      5570/turnserver
sctp                ::1:4445                                        LISTEN      5570/turnserver
sctp                10.19.0.5:4445                                  LISTEN      5570/turnserver
sctp                1xx.xx.xxx.xxx:4445                             LISTEN      5570/turnserver
sctp                127.0.0.1:4445                                  LISTEN      5570/turnserver

haproxy will forward tcp traffic if set to.
This was a working configuration until I screwed it up today while trying to upgrade.

fyi…this is from my backup server…

The easiest is to uninstall and start with clean install, if this possible. Just delete the content in /var/lib/prosody after uninstall (there is a bug in current stable where this is not cleaned we will address this with new stable release probably tomorrow). That clean install should result with running coturn and everything is behind nginx and your current haproxy setup that works will work for both the web and media traffic to coturn.
We had disabled tcp handling in the bridge by default as coturn is performing better than the bridge and tcp …

thanks…will try this now…which ports to I need to forward from haproxy? I’m assuming its 4444 or 4445?

@damencho
afaird that didn’t work for me. I have a few other sites running on nginx…and using server_name/virtual host name to access them. when trying to hit jitsi, the server_name appears to be ignored, and another sites page is loading. I’ve tried add the server_name to 60-jitsi-meet.conf, but that didn’t work for me.

btw…i do appreciate your help :smiley:

You can set all other sites to listen to 4444 or 4445 was it, check jitsi-meet one, and then everything will work through this, but all needs to be http2. This is workaround from other community members, I read.

uug…that will prob break the other sites…in my config, only untust traffic from the internet goes through haproxy…so I’ll need to think on this one…time to open another beer. if it comes down to it, how do I revert to the prev version? or how can I enable tcp handling with the bridge?

after two beers, I think I figured it out! time to go to bed. I’ll followup in the morning with what I did to work around my issue.

ok…this is what I did to workaround my issue:

  1. removed jitsi-meet-turnserver (apt purge jitsi-meet-turnserver). This removed the nginx module 60-jitsi-meet.conf and likely changed some other nginx configs.
  2. Changed turnserver.conf listening ports. in my case, I used 4444 and 4443 for tls
  3. verified nginx site was listing to 443 instead of 4444
  4. edit prosody config. Under turncredentials, I commented out the lines for stun and turn. Then updated the port for turrns to match what I used in step2, 4443
  5. restart all the services (coturn,nginx, videobridge, jicofo,etc)

Hope this helps someone else that may have a similar issue or usecase

Note that some firewalls block port 4443. That’s why we go through the trouble of multiplexing on 443.

Boris

@Boris_Grozev
I love that you guys did that too, and I’m sure many will apprecate it. My use case may be unique.
In my case, I have a few internal sites using nginx too. split dns is used to hit the internal interface to avoid hairpinning/loopback issues. When trying with the default configuration, the host headers didn’t seem to be handled correctly( even when with the server_name option being used in the 60-jitsi-meet.conf).
To allow external access to jitsi, I have a reverse proxy in front of it (haproxy). haproxy can’t handle udp proxying, so I have to use tcp. I’m not sure if haproxy can handle multiplexing, but I should probably take a look!

I thought at one point, meet.jit.si was behind a haproxy. If that is still the case, how are you guys handling it?

a snip of my haproxy conf can be found in this post

We use haproxy only for signaling. The TURN servers use their own IP addresses (and so do the bridges).

Boris