I’ve observed that some of my corporate clients were unable to connect to my Jitsi deployments, after I updated deploy configurations to use latest packages that updated Nginx multiplexing Regexps for h2 and http/1.1 in
My clients complained of an
ERR_EMPTY_RESPONSE on their Chrome browser when they tried to access my Jitsi URL from their official laptops. At the same time, I saw this in my
2020/08/11 06:24:08 [error] 10929#10929: *27725 recv() failed (104: Connection reset by peer) while proxying and reading from upstream, client: <client-ip>, server: 0.0.0.0:443, upstream: "127.0.0.1:5349", bytes from/to client:330/3253, bytes from/to upstream:3253/609
I added an Nginx
log_format to print
ssl_preread_alpn_protocols in my access_log and RCA revealed that these client machines weren’t sending ALPN values somehow, even with latest versions of Chrome/Firefox browsers. I was able to reproduce an empty response behavior via cURL on my Mac OS machine that has an installation of cURL that is known to not send ALPN.
As per online forums and this StackOverflow answer, it seems like client machines have an antivirus/firewall installation that downgrades HTTP2 connections and strips ALPN values. The
ngx_stream_ssl_preread_module on my server thus receives a blank value for
ssl_preread_alpn_protocols. As a result, my Jitsi installation is unable to distinguish between an HTTP request and a TURN request and defaults everything to my TURN server (running on port 5349) which returns an empty response of course.
Temporary solution that works for now
The whole point for me to rely on TURN was because corporate clients were unable to use Jitsi installs from their official machines with or without VPN. I switched back to my previous setup with a dedicated Coturn server running on port 443 and a dedicated Jitsi server serving at port 443. I also removed
/etc/jitsi/modules-enabled/60-jitsi-meet.conf and updated my Nginx configuration to use port 443 rather than 4444. This has allowed for smooth connectivity as now regardless of ALPN values, my Nginx server serves Jitsi and my Coturn server serves p2p requests.
However, there are some clients who are able to access my Jitsi web interface but their p2p fails and they keep getting thrown out of the call. They are not able to see other participants either. IMO, we need a better solution to this as neither a separate TURN server completely covers all scenarios, nor multiplexing on the basis of ALPN values works for all clients.