I already read a bit in the form about the issues others encounter while trying to use the call plugin. However, none of them have solved my problem. Here is the output of my Mattermost server log. I appreciate if any of you could help me to solve this problem.
{"timestamp":"2022-11-07 21:22:52.731 +03:30","level":"warn","msg":"Unrecognized config permissions tag value.","caller":"api4/config.go:431","tag_value":"sysconsole_write_*_read"}
{"timestamp":"2022-11-07 21:28:36.750 +03:30","level":"error","msg":"callback failed: not found","caller":"app/plugin_api.go:974","plugin_id":"com.mattermost.calls","origin":"main.(*Plugin).handleLeave websocket.go:372"}
{"timestamp":"2022-11-07 21:28:51.761 +03:30","level":"error","msg":"failed to read RTP packet","caller":"app/plugin_api.go:974","plugin_id":"com.mattermost.calls","origin":"main.(*logger).Error log.go:92","error":"EOF"}
{"timestamp":"2022-11-07 21:28:51.790 +03:30","level":"error","msg":"callback failed: call state is missing from channel state","caller":"app/plugin_api.go:974","plugin_id":"com.mattermost.calls","origin":"main.(*Plugin).handleLeave websocket.go:372"}
{"timestamp":"2022-11-07 21:32:30.686 +03:30","level":"warn","msg":"Unrecognized config permissions tag value.","caller":"api4/config.go:431","tag_value":"sysconsole_write_*_read"}
{"timestamp":"2022-11-07 21:32:41.221 +03:30","level":"warn","msg":"Unrecognized config permissions tag value.","caller":"api4/config.go:431","tag_value":"sysconsole_write_*_read"}
With regards to your logs: I’ve never seen these error messages. Can you confirm that your Mattermost server version is supported by the plugin? What server version are you running, what plugin version did you install and how did you install it (manual upload or via the market place)?
Also, please enable debug logging in your config.json (set LogSettings.FileLevel to debug) or set it via mmctl config set LogSettings.FileLevel "debug" and restart your server (systemctl restart mattermost) or reload the configuration ( mmctl config reload).
Then try to disable and enable the calls plugin using system console or mmctl plugin disable com.mattermost.calls && mmctl plugin enable com.mattermost.calls and post the log output.
Also please post the output of lsof -i :8443 before and after you enabled the plugin.
What docker deployment method and installation instructions did you use? Can you please share the output of docker ps once your containers are running?
I am running Mattermost without nginx in a separate server. But I have a server reverse proxy to this server using nginx.
Here is the output os my docker ps:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0360b2b1a498 mailserver/docker-mailserver:latest "/usr/bin/dumb-init …" 4 days ago Up 47 hours 110/tcp, 0.0.0.0:25->25/tcp, :::25->25/tcp, 0.0.0.0:465->465/tcp, :::465->465/tcp, 143/tcp, 993/tcp, 995/tcp, 0.0.0.0:587->587/tcp, :::587->587/tcp, 4190/tcp mailserver
de81f57deaaa mattermost/mattermost-enterprise-edition:7.4 "/entrypoint.sh matt…" 6 days ago Up 19 hours (healthy) 8067/tcp, 0.0.0.0:8065->8065/tcp, :::8065->8065/tcp, 8074-8075/tcp mattermost_mattermost_1
26853c1c1eaa postgres:13-alpine "docker-entrypoint.s…" 6 days ago Up 19 hours 5432/tcp
I also have a simple mail server for handling the email sending stuff. @agriesser
Thanks. As you can see here, your mattermost application container is only listening on the port 8065 on the external interface which is also the port your nginx is proxying too. This is OK and sufficient if you just want to use the standard Mattermost functionality, but for calls, at least one additional port needs to be opened directly to the application server as you can see in the deployment guide.
You will need to make sure that the port udp/8443 is exposed directly to your Mattermost container and that clients can also access this port directly without having to go through nginx (nginx cannot proxy UDP ports, so if your domainname points to the server where nginx is running, you will have to create a second domain name which then points to the mattermost application container and add this domainname to the ICEHostOverride configuration setting in the calls plugin) or you can set up iptables to forward this port on your nginx reverse proxy to the internal server where the Mattermost container is running:
Well the problem solved. But now I have a bit weird bug that was not there before. I was able to use voice plugin to send voice messages before. But after forwarding the port 8443 to the Mattermost server ip address I am not able to either send or receive any voice message.
I looked at the code for the voice plugin but could not find anything related to overlapping ports or the like, so I’m unsure why this is happening and if these two plugins are excluding each other or something like that.
Could it be that when there is an active stream or the calls plugin occupies your microphone, that you cannot record a new voice mail for that reason? When you restart your mattermost client and immediately try to make a call recording, does this work then?
Any error messages when you try to send or receive a voicemail and can you make it work again after removing the iptables rule again or was this just a bad coincidence and is not directly related?
You could also try to disable and re-enable the plugins again to “restart” them FWIW.
The IP address can be used, the container name not. Whatever you put here needs to be reachable directly by the client, since this information will be used by the client to connect to the endpoint. A desktop client cannot resolve your containername or internal container IP.
I looked at the code for the voice plugin but could not find anything related to overlapping ports or the like, so I’m unsure why this is happening and if these two plugins are excluding each other or something like that.
Could it be that when there is an active stream or the calls plugin occupies your microphone, that you cannot record a new voice mail for that reason? When you restart your mattermost client and immediately try to make a call recording, does this work then?
Any error messages when you try to send or receive a voicemail and can you make it work again after removing the iptables rule again or was this just a bad coincidence and is not directly related?
You could also try to disable and re-enable the plugins again to “restart” them FWIW.
I am not sure but for now the only way I could make the call plugin works properly is by forwarding port 8443 to the local IP address of the mattermost container. Even setting the IP address didn’t work for me. I am going to test some other things later today or tomorrow. Will update you here.
I think I figured out what was the problem. I activated the anti-virus plugin and set it to check all of the files before uploading. I think that plugin prevented all of the audio files from uploading and generated a runt-time a error. Now the voice plugin is working perfectly. Thank you for the help @agriesser
Interesting and hard to debug - thanks for sharing this with us!
I’m closing this topic now, since the plugins are both working for you and there was no issue with enabling both of them - hope that’s OK.
@agriesser Hi,
Help me please! I have use call plugin. It only works when I call my server ip localhost. If I use another wifi I cannot connect to the call. How to fix this error?
Thanks,
Shanks