mirror of
https://forgejo.ellis.link/continuwuation/continuwuity/
synced 2026-08-07 05:09:45 +00:00
docs(turn,livekit): Add troubleshooting steps for incorrect IPs
This commit is contained in:
stratself
+21
-5
@@ -91,7 +91,7 @@ #### Firewall hints
|
||||
|
||||
### 3. Telling clients where to find LiveKit
|
||||
|
||||
To tell clients where to find LiveKit, you need to add the address of your `lk-jwt-service` to the `[global.matrix_rtc]` config section using the `foci` option.
|
||||
To tell clients where to find LiveKit, you need to add your `lk-jwt-service`'s address to the `[global.matrix_rtc] > foci` field of your Continuwuity config file.
|
||||
|
||||
The variable should be a list of servers serving as MatrixRTC endpoints. Replace the URL with the address you are deploying your instance of lk-jwt-service to:
|
||||
|
||||
@@ -139,7 +139,7 @@ ### 4. Configure your Reverse Proxy
|
||||
reverse_proxy 127.0.0.1:7880
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
**Note**: if you run Caddy inside a container (e.g. by following the example [here](../deploying/docker.mdx#caddy-using-caddyfile)) instead of on the host, then:
|
||||
|
||||
- Put these containers on the same bridge network as caddy (by defining `networks: [ caddy ]` in each of the services), and
|
||||
@@ -343,7 +343,9 @@ ## Testing
|
||||
{"url":"wss://livekit.example.com","jwt":"a_really_really_long_string"}
|
||||
```
|
||||
|
||||
Use this token to test at the [LiveKit Connection Tester](https://livekit.io/connection-test). If everything works there, then you have set up LiveKit successfully!
|
||||
Use this token to test at the [LiveKit Connection Tester][livekit-connection-test]. If everything works there, then you have set up LiveKit successfully!
|
||||
|
||||
[livekit-connection-test]: https://livekit.com/webrtc/connection-test
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
@@ -387,6 +389,19 @@ # --- some errors ---
|
||||
|
||||
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.
|
||||
|
||||
### Incorrect IP address for LiveKit
|
||||
|
||||
By default, LiveKit auto-discovers its public IP address(es), which is reflected in the "Establishing WebRTC connection" section of the connection test page. If these IPs are incorrect, you may want to hardcode your own IP by doing the following:
|
||||
|
||||
```diff
|
||||
### in your livekit.yaml ###
|
||||
rtc:
|
||||
# ... other configs here ...
|
||||
- use_external_ip: true
|
||||
+ use_external_ip: false
|
||||
+ node_ip: "1.2.3.4"
|
||||
```
|
||||
|
||||
### Workaround for non-federating servers
|
||||
|
||||
When deploying on servers with federation disabled (`allow_federation = false`), LiveKit will fail as it can't fetch the required [OpenID endpoint](https://spec.matrix.org/v1.17/server-server-api/#get_matrixfederationv1openiduserinfo) via federation paths.
|
||||
@@ -543,8 +558,9 @@ # in your coturn.conf
|
||||
Then configure LiveKit, making sure to replace `COTURN_SECRET` with the one you generated:
|
||||
|
||||
```yaml
|
||||
# livekit.yaml
|
||||
### in your livekit.yaml ###
|
||||
rtc:
|
||||
# ... other configs here ...
|
||||
turn_servers:
|
||||
- host: coturn.example.com
|
||||
port: 443
|
||||
@@ -556,4 +572,4 @@ # livekit.yaml
|
||||
|
||||
</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 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".
|
||||
|
||||
@@ -191,6 +191,8 @@ ### Errors with Trickle ICE
|
||||
- `code=401` - unauthorized credentials
|
||||
- Ensure your `turn_secret` matches coturn's `static-auth-secret`
|
||||
- Ensure the credentials you obtained from the Testing steps has not expired yet. You can adjust `turn_ttl` in your Continuwuity configuration to increase this, or simply re-request a new one
|
||||
- Wrong IP address advertised
|
||||
- This may be caused by coturn not recognizing its public-facing IP correctly, due to particular network setups. You can configure `external-ip=<desired-public-ip>` to fix this issue.
|
||||
|
||||
### 404 when calling the turnServer endpoint
|
||||
|
||||
|
||||
+32
-35
@@ -29,19 +29,12 @@ ### Prebuilt binary
|
||||
|
||||
#### Performance-optimised builds
|
||||
|
||||
For x86_64 systems with CPUs from the last ~15 years, use the
|
||||
`-haswell-` optimised binaries for best performance. These
|
||||
binaries enable hardware-accelerated CRC32 checksumming in
|
||||
RocksDB, which significantly improves database performance.
|
||||
The haswell instruction set provides an excellent balance of
|
||||
compatibility and speed.
|
||||
Continuwuity provides `*-maxperf` tagged binaries, which uses the `release-max-perf` build profile with [link-time optimisation (LTO)][lto-rust-docs]. For the x86_64 architecture, these binaries specifically target the Haswell architecture (hence the `-haswell-` name extension), and enables hardware-accelerated CRC32 checksumming in
|
||||
RocksDB which significantly improves database performance. If you're using an x86_64 system with CPUs from the last ~15 years, consider using these images for best performance.
|
||||
|
||||
If you're using Docker instead, equivalent performance-optimised
|
||||
images are available with the `-maxperf` suffix (e.g.
|
||||
`forgejo.ellis.link/continuwuation/continuwuity:latest-maxperf`).
|
||||
These images use the `release-max-perf` build profile with
|
||||
[link-time optimisation (LTO)][lto-rust-docs]
|
||||
and, for amd64, target the haswell CPU architecture.
|
||||
|
||||
[lto-rust-docs]: https://doc.rust-lang.org/cargo/reference/profiles.html#lto
|
||||
|
||||
@@ -59,28 +52,7 @@ ### Nix
|
||||
|
||||
### Compiling
|
||||
|
||||
Alternatively, you may compile the binary yourself.
|
||||
|
||||
#### Using Docker
|
||||
|
||||
See the [Building Docker Images](../development/index.mdx#building-docker-images)
|
||||
section in the development documentation.
|
||||
|
||||
#### Manual
|
||||
|
||||
##### Dependencies
|
||||
|
||||
- Run `nix develop` to get a devshell with everything you need
|
||||
- Or, install the following:
|
||||
- (On linux) `liburing-dev` on the compiling machine, and `liburing` on the target host
|
||||
- (On linux) `pkg-config` on the compiling machine to allow finding `liburing`
|
||||
- A C++ compiler and (on linux) `libclang` for RocksDB
|
||||
|
||||
##### Build
|
||||
|
||||
You can now build Continuwuity using `cargo build --release`.
|
||||
|
||||
Continuwuity supports various optional features that can be enabled during compilation. Please see the Cargo.toml file for a comprehensive list, or ask in our rooms.
|
||||
Alternatively, you may compile the binary yourself. See the [Appendix subsection](#compiling-continuwuity) for more details.
|
||||
|
||||
## Adding a Continuwuity user
|
||||
|
||||
@@ -207,7 +179,7 @@ ### Other Reverse Proxies
|
||||
|
||||
- `/_matrix/client` - core Client-Server APIs. These should be available on port :443
|
||||
|
||||
- `/_continuwuity/` - Continuwuity's integrated account management interface for OAuth-compatible clients
|
||||
- `/_continuwuity/` - Continuwuity's integrated account management interface and authentication path for OAuth-compatible clients
|
||||
|
||||
You can optionally reverse proxy the following individual routes:
|
||||
|
||||
@@ -215,7 +187,7 @@ ### Other Reverse Proxies
|
||||
Continuwuity to perform delegation (see the `[global.well_known]` config section)
|
||||
- `/.well-known/matrix/support` if using Continuwuity to send the homeserver admin
|
||||
[contact and support page][well-known-support]
|
||||
- `/` and `/_continuwuity/logo.svg` if you would like to see the Continuwuity landing page
|
||||
- `/` and `/_continuwuity/resources` if you would like to see the Continuwuity landing page
|
||||
|
||||
Refer to the respective software's documentation and online guides on how to do so.
|
||||
|
||||
@@ -286,10 +258,10 @@ ## How do I know it works?
|
||||
As a quick health check, you can also use these cURL commands:
|
||||
|
||||
```bash
|
||||
curl https://example.com/_conduwuit/server_version
|
||||
curl https://example.com/_continuwuity/server_version
|
||||
|
||||
# If using port 8448
|
||||
curl https://example.com:8448/_conduwuit/server_version
|
||||
curl https://example.com:8448/_continuwuity/server_version
|
||||
|
||||
# If federation is enabled
|
||||
curl https://example.com:8448/_matrix/federation/v1/version
|
||||
@@ -305,3 +277,28 @@ ## What's next?
|
||||
- For Audio/Video call functionality see the [**Calls**](../calls.md) page.
|
||||
- Consult the [Maintenance](../maintenance.mdx) page for guidance on maintaining your homeserver.
|
||||
- If you want to set up an appservice, take a look at the [**Appservice Guide**](../appservices.md).
|
||||
|
||||
## Appendix
|
||||
|
||||
### Compiling Continuwuity
|
||||
|
||||
#### Using Docker
|
||||
|
||||
See the [Building Docker Images](../development/index.mdx#building-docker-images)
|
||||
section in the development documentation.
|
||||
|
||||
#### Manual
|
||||
|
||||
##### DEPENDENCIES
|
||||
|
||||
- Run `nix develop` to get a devshell with everything you need
|
||||
- Or, install the following:
|
||||
- (On linux) `liburing-dev` on the compiling machine, and `liburing` on the target host
|
||||
- (On linux) `pkg-config` on the compiling machine to allow finding `liburing`
|
||||
- A C++ compiler and (on linux) `libclang` for RocksDB
|
||||
|
||||
##### BUILD
|
||||
|
||||
You can now build Continuwuity using `cargo build --release`.
|
||||
|
||||
Continuwuity supports various optional features that can be enabled during compilation. Please see the Cargo.toml file for a comprehensive list, or ask in our rooms.
|
||||
|
||||
Reference in New Issue
Block a user