Hello All, I recently set up a self-hosted instance of nextcloud (using official nextcloud-aio docker image) for my workplace. We notice that strange things happen when the user leaves the desktop talk app running for 24 hours. specifically when they join a call, they show up as trying to join with a spinning circle, and then drop off. When the user restarts the app (full quit, not just closing window) it works fine, though sometimes it takes a couple restarts. This is mildly inconvenient, and kinda embarrassing, (especially when demonstrating the software to my boss who is used to non-free platforms) so I have set out to solve it. looking in the logs I noticed a lot of Janus related errors like:
janus_client.go:489: Received event for unknown transaction, ignoring: {
"janus": "ack",
"session_id": [MASKED_ID],
"transaction": "[MASKED_TRANSACTION]"
}
mcu_janus_publisher.go:146: Room [MASKED_ROOM_ID] destroyed
mcu_janus_publisher.go:65: Publisher [MASKED_PUBLISHER_ID]: associated room has been destroyed, closing
janus_client.go:469: Unable to deliver message {
"janus": "detached",
"session_id": [MASKED_ID, matches previous session_id],
"sender": [MASKED_SENDER_ID]
and
hub.go:2854: Could not upgrade request from [MASKED_IP]: websocket: the client is not using the websocket protocol: 'upgrade' token not found in 'Connection' header
(Multiple occurrences)
After doing some poking around I thought the issue might be the reclaim_session_timeout flag being zero. as a long running client might need to be able to reclaim its session. However I am such a docker noob that I can’t figure out how to change it without taking Nextcloud-talk offline. Before I sink too much time into this, I want to make sure I am on the right track. A few setup specifics:
- My team is using official desktop talk clients.
- I do not know the exact “magic number” for making the issue happen, but it consistently happens when we leave Talk running for more than 24 hours. Restarting talk twice always fixes this.
- nextcloud-aio docker image has been updated to latest official image (though the issue was also there prior to the upgrade).
- We are running it behind nginx so I followed the proxy instructions to make sure that was correctly set up. It is possible this is the source of the problem, however new sessions have no problems with videoconferencing.
If anyone has any insight on this or useful resources, thanks in advance!