As lk-jwt-service is hosted in a bridge network, the previous
`extra_hosts` using 127.0.0.1 would just loop back to the container
itself. Using `network_mode: host` is unnecessary, and the
`host-gateway` approach works well for both Podman and Docker

Host loopback issues are prevalent in non-Livekit scenarios too: push
gateways is another example. Considering moving these to a dedicated
Docker section of the troubleshooting page.

@@ -441,3 +443,2 @@
 
-- [MSC4143 - MatrixRTC proposal][MSC4143]
-- [MSC4195 - LiveKit proposal][MSC4195]
+- [MSC4143 - MatrixRTC – Real-time communication over Matrix][MSC4143]

@@ -476,3 +478,3 @@
 <summary>Using LiveKit's built-in TURN server</summary>
 
-First, set up LiveKit's built-in TURN server with its own domain - we'll use `livekit-turn.example.com` in our example.
+First, set up LiveKit's built-in TURN server with its own domain - we will use `livekit-turn.example.com` in our example.

@@ -483,3 +485,3 @@
   enabled: true
 
-  # note: the TLS port will always be advertised as :443
+  # Note: LiveKit will always advertise its TURNS-TLS port on 443,

@@ -484,2 +486,3 @@
 
-  # note: the TLS port will always be advertised as :443
+  # Note: LiveKit will always advertise its TURNS-TLS port on 443,
+  # so further load balancing is needed to route from 443 back to

@@ -510,3 +514,3 @@
 Recreate the LiveKit container (with `docker compose up -d livekit`) to apply these changes. Remember to allow the new `50300:50400/udp` ports through your firewall.
 
-Then, we will configure a route from port 443 of the host back to our `livekit-turn.example.com` service on port 5349. To both **multiplex** this and LiveKit's websocket on the same port, we will use a layer-4 reverse proxy with **SNI routing** capabilities, such as [caddy-l4][caddy-l4] on the host system.
+Then, configure a route from port 443 on the host back to the `livekit-turn.example.com` service on port 5349. To multiplex the service and LiveKit's websocket on the same port, use a layer 4 reverse proxy with SNI routing capabilities, such as [caddy-l4], on the host system.

@@ -557,3 +561,3 @@
 ```
 
-Then, generate a long random secret for LiveKit, and add it to your coturn config under the `static-auth-secret` option. You can add as many secrets as you want, so set a different one for LiveKit to use.
+Then, generate a long random TURN secret for LiveKit, and add it to your coturn config under the `static-auth-secret` option. You can add as many secrets as you want, so set a different one for LiveKit to use.

@@ -578,3 +582,3 @@
 </details>
 
-After finishing configuration, you can run the Testing steps again to check that TURN-over-TLS is working. In the LiveKit connection test page, there should be a green tick saying "Can connect to TURN".
+After you finish configuring the services, you can run the Testing steps again to check that TURNS-over-443 is working. There should now be a green tick in the [LiveKit connection test page][livekit-connection-test] with "Can connect to TURN" to confirm this is set up successfully.

@@ -226,3 +226,3 @@
 ### TURNS-over-443
 
-Normally, TURN would work on their default setups. However, there are situations where clients are in very restrictive networks that disallows non-standard ports and UDP. In these cases, a TURN-over-TLS server on port :443 could be employed to relay traffic for them.
+Normally, TURN would work on their default setups. However, there are situations where clients may be unable to use nonstandard ports or UDP connections, such as in highly restrictive networks. In such cases, a TURN-over-TLS (a.k.a. TURNS) server on port 443 could relay traffic for the clients.

@@ -229,2 +228,3 @@
+Normally, TURN would work on their default setups. However, there are situations where clients may be unable to use nonstandard ports or UDP connections, such as in highly restrictive networks. In such cases, a TURN-over-TLS (a.k.a. TURNS) server on port 443 could relay traffic for the clients.
 
-However, port 443 is usually utilized by other HTTPS services. Therefore, one would need to **multiplex** both TURN HTTPS on these ports, and filter packets to them via **SNI routing**.
+However, port 443 is usually utilized by other HTTPS services. Therefore, one would need to **multiplex** both TURNS and HTTPS on these ports, and filter packets to them via **SNI routing**.

@@ -466,3 +468,3 @@
 ### Additional TURNS-over-443 configuration
 
-Most of the time, LiveKit [**does not need TURN**][sspaeth-matrix-voip-turn] to function. However, there are situations where clients are in very restrictive networks that disallows non-standard ports and UDP. In these cases, a TURN-over-TLS server on port :443 could be employed to relay traffic for them.
+Most of the time, LiveKit [**does not need TURN**][sspaeth-matrix-voip-turn] to function. However, there are situations where clients may be unable to use nonstandard ports or UDP connections, such as in highly restrictive networks. In such cases, a TURN-over-TLS server on port 443 could relay traffic for the clients.

@@ -483,3 +485,3 @@
   enabled: true
 
-  # note: the TLS port will always be advertised as :443
+  # Note: LiveKit will always advertise its TURN-over-TLS port on 443,

@@ -560,2 +563,3 @@
+Then, generate a long random TURN secret for LiveKit, and add it to your coturn config under the `static-auth-secret` option. coturn allows multiple secrets in its configuration, so set a different one for LiveKit to use.
 
-After that, refer to the following [**TURN instructions**](./turn#turns-over-443) to set up coturn with TLS, as well as multiplexing with LiveKit's websocket on port 443.
+After that, refer to the following [TURNS-over-443 instructions](./turn#turns-over-443) to set up coturn with TLS, as well as multiplexing with LiveKit's websocket on port 443.

@@ -578,3 +582,3 @@
 </details>
 
-After finishing configuration, you can run the Testing steps again to check that TURN-over-TLS is working. In the LiveKit connection test page, there should be a green tick saying "Can connect to TURN".
+Once the services are configured, run the Testing steps again to check that TURNS-over-443 is working. There should now be a green tick in the [LiveKit connection test page][livekit-connection-test] showing "Can connect to TURN" to confirm this is set up successfully.

@@ -35,3 +35,3 @@
 :::
 
-If you want to enable TURN-over-TLS (TURNS), add the appropriate cert/key paths to your `coturn.conf` by adding the following lines:
+If you want to enable TURN-over-TLS (TURNS), add the appropriate certificate and key paths to your `coturn.conf` by adding the following lines:

@@ -226,3 +226,3 @@
 ### TURNS-over-443
 
-Normally, TURN would work on their default setups. However, there are situations where clients are in very restrictive networks that disallows non-standard ports and UDP. In these cases, a TURN-over-TLS server on port :443 could be employed to relay traffic for them.
+TURN servers are generally reachable on their default ports, as configured above. However, there are situations where clients may be unable to use nonstandard ports or UDP connections, such as in highly restrictive networks. In such cases, a TURN-over-TLS server on port 443 could relay traffic for the clients.

@@ -149,2 +149,2 @@
-    - Put these containers on the same bridge network as caddy (by defining `networks: [ caddy ]` in each of the services), and
-    - Use appropriate container hostnames (`lk-jwt-service` and `livekit`) instead of `127.0.0.1` in the Caddyfile
+</Tab>
+<Tab label="Caddy (in container)">

@@ -151,2 +150,3 @@
+<Tab label="Caddy (in container)">
 
-</details>
+Requires `livekit` and `lk-jwt-service` to be on the same docker bridge network as Caddy.

@@ -191,0 +173,4 @@
+</Tab>
+<Tab label="Traefik (via Docker labels)">
+
+Requires `livekit` and `lk-jwt-service` to be on the same docker bridge network as Traefik.

@@ -191,0 +183,4 @@
+```
+
+</Tab>
+<Tab label="Nginx">

@@ -277,1 +214,4 @@
+}
+```
 
+Note that for websockets to work, you need to have this somewhere outside your server block:

@@ -366,3 +316,3 @@
 ### Docker loopback networking issues
 
-Some distros do not allow Docker containers to connect to its host's public IP by default. This would cause `lk-jwt-service` to fail connecting to `livekit` or `continuwuity` on the same host. As a result, you would see connection refused/connection timeouts log entries in the JWT service, even when `LIVEKIT_URL` has been configured correctly.
+Some distros do not allow Docker containers in bridge networks to connect to its host's public IP by default. This would cause `lk-jwt-service` to fail connecting to `livekit` or `continuwuity` on the same host. As a result, you would see connection refused/connection timeouts log entries in the JWT service, even when `LIVEKIT_URL` has been configured correctly.

@@ -375,3 +325,3 @@
 ```
 
-To alleviate this, you can try one of the following workarounds:
+To resolve this, we can configure an `extra_hosts` file mapping LiveKit's (and Continuwuity's) domain name to Docker's custom host loopback address (represented by `host-gateway`):

@@ -394,3 +338,4 @@
 
 After implementing the changes and restarting your compose, `lk-jwt-service` should now connect to your other services. The sidecar container test above should now return an `OK` from LiveKit.
 
+For more information about the `host-gateway` parameter, kindly refer to the `--add-host` documentation for [Docker][docker-add-host] and [Podman][podman-add-host]. Should you have further difficulties, feel free to inquire in the support rooms.

@@ -241,3 +241,3 @@
 - Route `livekit.example.com` to the [LiveKit services](./livekit.mdx) with TLS termination by Caddy
 
-Please note that all traffic from Coturn's perspective will be coming from caddy-l4's IP now.
+Please note that all traffic from Coturn's perspective will be coming from Caddy-L4's IP now.