Summary
Issue with voice call and screen share feature.
Steps to reproduce
version: 7.1.2
steps
Expected behavior
Hi Riley,
what Calls plugin version are you using?
What clients are participating in the call (web client, desktop app, mobile client, …) and what versions are they?
Can you describe your deployment model a bit, please? Are you using an SSL offloader, a loadbalancer, binary/docker deployment? HA environment?
Hey @agriesser,
The call plugin that we are using is the new native voice call feature added in 7.0. This issue happened on both web and client platforms (client version is the most up to date at 5.1.1). our deployment is self-hosted using the binary.
Yes, I know - but the plugin has also a version number and there have been some fixes to the audio device detection and reconnection in the most recent versions.The latest version of the plugin 0.7.1, you can check the version in your marketplace to make sure you have the latest one running (and you can also update it directly through the marketplace).
With regads to your issues:
Number 1 could be related to audio device detection issues or security problems with the browser. Please note that your Mattermost server needs to run with the https:// protocol for Calls to work using the browser and the desktop apps. If your audio devices work properly, please restart the desktop app and try again then. There are currently some issues with re-detection of disconnected/sleeping bluetooth headsets and a restart of the desktop app usually fixes this problem.
Number 2 could be related to websocket connection errors. Are you using a reverse proxy in front of your Mattermost application and if so, which software are you using and do you have any specific configuration with regards to the websockets? You can check for examples in the documentation.
Number 3 might also be related to Number 1 and the missing https support. Also please make sure that your clients can connect to the port 8443 UDP on your mattermost server, since this is the data connection used by the plugin.
Thank you @agriesser about the version location I did update the version to 0.7.1. It does however look like 8443 is not forwarded or open. I’ll see if this is the problem.
The port udp/8443 cannot be proxied through a reverse proxy, it needs to be directly accessible by your clients. Also depending on your networking and plugin configuration, an external STUN server might be used. If you want to make sure that no external resources are being used, set the “ICE Host Override” setting in your Calls plugin configuration to the domainname of your Mattermost server.
Hey @agriesser, I think I understand what I’m missing after looking over the docs and digging a bit on the state of my environment. From my understanding I need to have tls setup which means that I need to change the server to listen on port to 443 and setup tls. After tls is setup incoming udp 8443 and outgoing udp 3478 ports need to be open to the outside for the rtc and stun servers. does this sound correct?
Yes, this sounds good. But you do not necessarily need a separate stun server, you can (for the sake of simplicity, depending on your deployment) just use the ICEHostOverride setting in your Calls-plugin configuration and have it point to your mattermost domain name. That way, only this domain will receive traffic on tcp/443 (for the normal Mattermost traffic and the websockets) plus udp/8443 for the rtc/voice traffic.
Ok so I would just set the ice host override to for example mm.domain.com or server ip and I wouldnt need to have a stun server.
Correct. Let me know if that works for you.
Hi @agriesser thank you for your help on this thread. I did find out later that an nginx server is in front of our instance of MatterMost. Just so I’m on the same page for this setup the MatterMost server needs to be forwarded on the normal port and ssl termination needs to be setup on the nginx server, correct?
The calls port (udp/8443) needs to go directly to the Mattermost application server, it should not go through the nginx application.
So if mm.domain.com points to the server where nginx is running and this is not the server where the Mattermost application is running, the nginx server will have to forward this traffic with iptables, f.ex.
If nginx and Mattermost are running on the same machine, just make sure that port 8443/udp is available publicly (just like 443/tcp), but not via nginx.
Maybe those deployment schemes help to understand your options:
https://docs.mattermost.com/configure/calls-deployment.html
If they don’t, let me know and I’ll try again 
@agriesser
Ok I do understand the setup from these two pictures is what I understand I need to do
Hmm… I don’t understand the difference between mattermost and calls in your graph - do you mean the separate processes (mattermost as the core application, the integrated webserver and calls being the plugin)? If so, yes, this is correct.
The clients need to directly connect to the server where the Calls plugin is running via udp/8443 and they need to continue to connect to the mattermost server as they always did.
If your nginx reverse proxy is located on a different server than the mattermost application server, you will probably need to create a new domain name for the connection to the calls plugin (or you need to set the ICEHostOverride to the public IP which gets routed to the calls plugin on this server).
Right now I assume that mattermost.yourdomain.com points to the nginx reverse proxy block in your diagram and that this is a separte computing instance which then forwards to another computing instance where the mattermost application server and the calls plugin are running.
Most likeley, this second computing instance does not have a dedicated public IP, so you can now either set one up and point it to this instance and only allow udp/8443 on the public IP so the calls plugin can be reached from your clients or you can set up a port forwarding (not using nginx, but iptables) on your nginx reverse proxy instance which then forwards udp/8443 on the public interface to the internal IP of your mattermost computing instance.
Hope I explained that well, if not, let me know where I need to rephrase
Hey @agriesser,
Ok Thank you for explaining this portion. What about the ports on this graph? Are there any issues? I don’t have TLS enabled on the MatterMost server however it does go through a reverse proxy that does give https.
According to your scheme, you’re accessing your Mattermostserver via https://domain.com:9080, so it’s TLS but on a non-standard port, which is fine (as long as your SiteUrl configuration setting also reflects exactly this URL including the protocol scheme and the port).
The calls plugin does not need to be TLS enabled explicity, udp/8443 is enough and to be honest, I’m not sure if there’s some kind of encryption going on on this port, but I’m pretty sure there is. Anyways, you do not have to take care of that, just make sure this port directly goes to your application server and not through your reverse proxy.
If you want to forward 8443 through your reverse proxy, you could use iptables there:
iptables -t nat -A PREROUTING -p udp --dport 8443 -j DNAT --to <internalip>:8443
Hi @Riley.B ,
just trying to check back in once again - please let me know if you were able to solve your issue or if there’s anything I can still help you with.
I might upgrade our instance to the new 7.7.1 release to see if this fixes this issue.