docs(livekit): Fix wordings according to PR comments

- Use proper capitalization to match software brandings
- websocket -> WebSocket
- resolve other wording issues

docs/calls/livekit.mdx

@@ -149,7 +149,7 @@ ### 4. Configure your Reverse Proxy
 </Tab>
 <Tab label="Caddy (in container)">
 
-Requires `livekit` and `lk-jwt-service` to be on the same docker bridge network as Caddy.
+Requires `livekit` and `lk-jwt-service` to be on the same Docker bridge network as Caddy.
 
 ```ini
 livekit.example.com {
@@ -173,7 +173,7 @@ ### 4. Configure your Reverse Proxy
 </Tab>
 <Tab label="Traefik (via Docker labels)">
 
-Requires `livekit` and `lk-jwt-service` to be on the same docker bridge network as Traefik.
+Requires `livekit` and `lk-jwt-service` to be on the same Docker bridge network as Traefik.
 
 ```
 # on LiveKit itself
@@ -183,7 +183,7 @@ # on the JWT service
 ```
 
 </Tab>
-<Tab label="Nginx">
+<Tab label="nginx">
 
 ```ini
 server {
@@ -206,7 +206,7 @@ # on the JWT service
         proxy_set_header Host $http_host;
         proxy_buffering off;
 
-        # websocket
+        # WebSocket
         proxy_http_version 1.1;
         proxy_set_header Upgrade $http_upgrade;
         proxy_set_header Connection $connection_upgrade;
@@ -214,13 +214,18 @@ # on the JWT service
 }
 ```
 
-Note that for websockets to work, you need to have this somewhere outside your server block:
+Note: To enable WebSockets proxying functionality, include the following snippet somewhere outside your server block:
 ```
 map $http_upgrade $connection_upgrade {
     default upgrade;
     ''      close;
 }
 ```
+
+See nginx's [WebSocket proxying documentation][nginx-websockets] for further details.
+
+[nginx-websockets]: https://nginx.org/en/docs/http/websocket.html
+
 </Tab>
 </Tabs>
 
@@ -315,7 +320,7 @@ ### Common errors in Element Call UI
 
 ### Docker loopback networking issues
 
-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.
+Some distros do not allow Docker containers in bridge networks to connect to their host's public IP by default. This makes `lk-jwt-service` fail connecting to `livekit` or `continuwuity` on the same host, causing refused and timed out connections to appear in the log entries of the JWT service, even when `LIVEKIT_URL` has been configured correctly.
 
 You can also test that this is the case by cURLing from a sidecar container:
 
@@ -324,7 +329,7 @@ ### Docker loopback networking issues
 # --- some errors ---
 ```
 
-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`):
+To resolve this, configure an `extra_hosts` file mapping LiveKit's and Continuwuity's domain names to Docker's custom host loopback address, represented here by `host-gateway`:
 
 ```diff
 # in docker-compose.yaml
@@ -338,7 +343,7 @@ # in docker-compose.yaml
 
 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.
+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 enquire in the support rooms.
 
 [docker-add-host]: https://docs.docker.com/reference/cli/docker/container/run/#add-host
 [podman-add-host]: https://docs.podman.io/en/latest/markdown/podman-run.1.html#add-host-hostname-hostname-ip
@@ -450,7 +455,7 @@   # replace these with your actual certificate and key files
 ```
 
 ```yaml
-### add these ports to livekit's docker-compose ###
+### add these ports to livekit's docker-compose.yml ###
 ### if you're using `network_mode: host`, you can skip this part
 ports:
   - "127.0.0.1:5349:5349/tcp"
@@ -460,7 +465,7 @@   # "3478:3478/udp" # (optional UDP port)
 
 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, 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][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][caddy-l4], on the host system.
 
 ```
 ## in your Caddyfile ##
@@ -510,7 +515,7 @@ # in your coturn.conf
 
 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-over-TLS on 443 instructions](./turn#turn-over-tls-on-443) to set up coturn with TLS, as well as multiplexing with LiveKit's websocket on port 443.
+After that, refer to the following [TURN-over-TLS on 443 instructions](./turn#turn-over-tls-on-443) to set up coturn with TLS, as well as multiplexing with LiveKit's WebSocket on port 443.
 
 Then configure LiveKit, making sure to replace `COTURN_SECRET` with the one you generated: