-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Self-hosted call.element support (like it's done for jitsi) #2371
Comments
Bumping this up... |
I scraped at the documentation to get element call server going. I have tested this to call between ElementX android <> ElementX android; ElementX android <> Element Web (nightly). Here are my instructions. If you find something needs to change do point that out. Proxy setupDNS namesI am assuming that the domain name is mydomain.com. Make sure the following dns names have public ip/FQDN:
Nginx proxy configThe following assumes that the elementcall docker container is running at 192.168.1.2. The following config forwards the call to element call/livekit running via docker.
Docker setupElement callUse the following docker compose:
Here are the supporting files:
livekit.yaml
redis.conf
Synapse changeset the following in homeserver.yaml
Firewall/Router port forwardsFor LivekitFrom https://docs.livekit.io/home/self-hosting/ports-firewall/ For Element CallForward TCP port 443 to Nginx server |
@rajil , thanks. My question was not about setting up Element call - it's done, no problems - a bit different from your approach, but I believe, it's a matter of taste. My question is about making Mobile & Desktop apps to use self-hosted version, because for now they use call.element.io without any possibility to change that in the settings. |
@alexander-potemkin The nightly version of ElementX Android already allows changing from call.element.io. And so does the nightly version of Element Desktop. |
@rajil , my hopes were for Element "Classic"... Anyway, thanks for letting know! If that's not too much to ask, could you please, let me know how it's handled? Does it follow |
Element Classic is no longer being developed AFAIK. I had to apply the change manually in the EX client settings (not sure if there is a .well-known for it). |
Thank you. My question remains then:
|
It seems that .well-known support is on the way |
As it's a commit into element-call, it's the only service that is affected; if they push it to JS SDK - it might affect Desktop clients, but not mobiles. Unless I'm missing something. |
Mobile is also supported. |
Will see! |
I simply want to send you a big THANK YOU! Due to the current lack of docs I'd never be able to set up EC today without your post. Awesome starting point! |
Adding some comments after I did the described setup: If the Element-Call-VM is behind a firewall like pfSense and is not directly exposed to the internet, you need to change the line in livekit.yaml to:
With this setting, livekit will detect the external IP address via STUN. Having this set to "false" won't work in this scenario. Furthermore, some .well-known's must be changed / added: .well-known/matrix/client must be extended with this:
.well-known/element/element.json must be introduced, so Element-X gets the changed server:
The Element-Web config.json at the server which serves Element-Web (Usually the same machine which runs Synapse) must be extended by these:
Element-Desktop will, for now, not get the information from the .well-known/element/element.json. I hope they will implement this in the future. |
I found that Element-Call as for now is using VP8 as codec. This really kills battery at Apple devices (iPhone/iPad) which are getting very hot during calls. VP8 is not a hardware-supported codec here, so all must be done in software. I've filed an issue here, but meanwhile you can force livekit to use H.264 which solves all these problems: In
This will force livekit to use H.264 and all is back to normal in the Apple world, iPhones not getting hot anymore, battery use for 15 minutes video call on an iPhone 14 is down to 3% now. |
I got all this working (thank you to the amazing devs and the helpful community members who helped me along my way) and wanted to post my setup as a bit of extra reference material, in addition to @rajil 's great starting point above. What really made the setup "click" for me was this realization: your goal is to get each service individually exposed to the internet. That's it. You set a few key values for the sake of Element X knowing where each service lives, but the services do not directly communicate with each other. I was initially making things a lot harder for myself because I was trying to set up fancy container networking, under the false assumption that the services were interdependent. They are not; they are discrete, independent services that are for the most part blissfully ignorant of each other. Any configuration values that refer to another service are ONLY to tell Element X where that service lives. Without further ado, here are the configuration file changes that I made: homeserver.yml (Synapse)
config.json (Element Call)
livekit.yaml (Livekit)
Nginx config (Element Call, Livekit, and Livekit-JWT)
Nginx config (Synapse)I won't paste the entire file here, but the only changes relevant are for the
And now here are the commands that I use to run the actual containers. I'm in an environment where I use
With the services running, now you need to set up some port forwards on your router. Port 7881 TCP and port range 50100-50200 UDP, to whichever machine is hosting your services. That's it. Notably, I did NOT need to include a At this point you should be able to restart your phone or log out / log in to Element X and have it routing calls through your self-hosted instance! 🎉 |
Having setup-docs is nice and all, but the original issue still persists, at least for element desktop. While Element X now uses the To workaround this i currently host a configured element-web instance and users are encouraged to use that web-version instead. I would however prefer to be able to use element desktop because it better integrates into the OS. |
... and because it's the only app (across mobiles and web) that offers search functionality. |
Your use caseWhat would you like to do?Inform others how I selfhosted element-call on FreeBSD Why would you like to do it?Helping others and learn from others if I did something wrong How would you like to achieve it?By posting the below instructions: Caddyfile:
homeser.yaml:
dits/config.json:
livekit.yaml:
Build element-call:
Build livekit:
clone and run lk-jwt-service:
Have you considered any alternatives?No response Additional contextNo response |
Your use case
What would you like to do?
I would like to configure my own element-call support on the server side, so that all of the clients would pick it up instead of call.element.io
Why would you like to do it?
To facilitate self-hosted calls.
How would you like to achieve it?
Ideally, that element call service would be populated through the server; but .well-known approach, like it's done for Jitsi, works too.
Have you considered any alternatives?
Yes. The alternative - it's to rebuild and repackage and publish all of the Element clients. Doable, but feels a bit unreasonable.
Additional context
element-hq/element-call#2228
element-hq/element-desktop#1566
The text was updated successfully, but these errors were encountered: