How to configure a Gateway for Jitsi

I’ve deployed the Jitsi on my backend server and it worked as expected. Basically I just open the port 10000 and bind the port 443 to the port 6443, then I can create and join a video meeting successfully. In other words, I use the port 6443 to create the TLS connection and use the port 10000 to accept the UDP streams.

Now, I use another machine as my gateway, which developed a gateway component Envoy. Here is the config of my Envoy:

static_resources:
listeners:

  • name: listener_jitsi_https
    address:
    socket_address:
    address: 0.0.0.0
    port_value: 6443
    filter_chains:
    • filters:
      • name: envoy.filters.network.http_connection_manager
        typed_config:
        @type”: HttpConnectionManager
        stat_prefix: ingress_http
        http_filters:
        • name: envoy.filters.http.router
          route_config:
          name: local_route
          virtual_hosts:
          • name: local_service
            domains: [“*”]
            routes:
            • match:
              prefix: “/”
              route:
              cluster: cluster_jitsi_https
              transport_socket:
              name: envoy.transport_sockets.tls
              typed_config:
              @type”: DownstreamTlsContext
              common_tls_context:
              tls_certificates:
          • certificate_chain:
            filename: “/home/administrator/envoy/xxx.crt”
            private_key:
            filename: “/home/administrator/envoy/xxx.key”
  • name: listener_jitsi_udp
    reuse_port: true
    address:
    socket_address:
    protocol: UDP
    address: 0.0.0.0
    port_value: 10000
    udp_listener_config:
    downstream_socket_config:
    max_rx_datagram_size: 9000
    access_log:
    • name: envoy.access_loggers.file
      typed_config:FileAccessLog
      path: “/home/administrator/envoy/udp.log”
      listener_filters:
    • name: envoy.filters.udp_listener.udp_proxy
      typed_config:
      @type’: UdpProxyConfig
      stat_prefix: example_ingress_udp
      cluster: cluster_jitsi_udp
      upstream_socket_config:
      max_rx_datagram_size: 9000
      clusters:
  • name: cluster_jitsi_https
    connect_timeout: 30s
    type: LOGICAL_DNS
    load_assignment:
    cluster_name: jitsi_cluster_https
    endpoints:
    • lb_endpoints:
      • endpoint:
        address:
        socket_address:
        address: xxx
        port_value: 6443
        transport_socket:
        name: envoy.transport_sockets.tls
        typed_config:
        @type”: UpstreamTlsContext
  • name: cluster_jitsi_udp
    connect_timeout: 30s
    type: LOGICAL_DNS
    load_assignment:
    cluster_name: jitsi_cluster_udp
    endpoints:
    • lb_endpoints:
      • endpoint:
        address:
        socket_address:
        address: xxx
        port_value: 10000

As you see, I route HTTPS request from IP_Gateway:6443 toxxx:6443, and I route the UDP request from IP_Gateway:10000 to xxx:10000. (xxx is the domain name of my backend server.)

Then, I add a new line in the file /etc/hosts on my client machine: IP_Gateway xxx so that all of requests to xxx will be redirected to my Gateway machine.

Well, I just tried to visit the index page on my client machine: https://xxx:6443, it worked as exptected. However, when I click on the button “Start meeting”, I just jump to a page, which told me that “You have been disconnected.”. It doesn’t seem that the UDP stream works as exptected.

Can someone help me?

Jumping straight to “You have been disconnected” sounds like signalling (XMPP, over HTTPS) is not working. If it was only the UDP port not working, you would be able to join the conference but have no audio/video.

Check the browser console logs, they will tell you exactly what is happening. Probably the URL in websocket / bosh in config.js doesn’t point to the right place.

Hmm. Thanks a lot. It seems that you are right. I just checked the console logs of my browser and I found the error like this:

WebSocket connection to ‘wss://xxx:6443/xmpp-websocket?room=11111&token=mytoken’ failed:

So it seems that it is the protocol which cause this issue as I didn’t do any configuration about wss for my Gateway.

wss:// is an HTTPS request with an upgrade to WebSocket. Your gateway will need to support WebSocket.

Take the URL and replace wss:// with https:// and open it in your browser, if you see Prosody’s “It works” screen then the gateway is working but probably needs to be configured to support WebSocket.

If you don’t see “It works” then even the initial HTTPS request isn’t working, so you’ll have to solve that before even worrying about WebSocket support.

Great! You are totally right about wss and my gateway does support wss.