Signaling server behind univetnion

Hi @Byter

I come back to this because my signaling server is working now. I’ve followed this guide:

https://markus-blog.de/index.php/2020/11/20/how-to-run-nextcloud-talk-high-performance-backend-with-stun-turnserver-on-ubuntu-with-docker-compose/

which is pretty much the same but as a docker version. So I just run it with the already installed docker on UCS. (And of course the univention-firewall.service)

Both how-tos just reference for the apache-vhost the github suggestion from the signaling server.
But you need an additional slash on the first RewriteRule:

<VirtualHost *:443>

    # ... existing configuration ...

    # Enable proxying Websocket requests to the standalone signaling server.
    ProxyPass "/standalone-signaling/"  "ws://127.0.0.1:8080/"

    RewriteEngine On
    # Websocket connections from the clients. !!! see the additional slash compared to 
    # strukturag/nextcloud-spreed-signaling on github
    RewriteRule ^/standalone-signaling/spreed/$ - [L]
    # Backend connections from Nextcloud.
    RewriteRule ^/standalone-signaling/api/(.*) http://127.0.0.1:8080/api/$1 [L,P]

    # ... existing configuration ...

</VirtualHost>

There is in fact already a commit and pull request from february but it didn’t pass until now. https://github.com/strukturag/nextcloud-spreed-signaling/pull/82

I write because on my five hours troubleshooting-way I also thought of dns errors before investigating more into the apache rewrites…

And another thing:
I have the feeling, that the signaling server really improves also connections with just two or three participants. So I can really recommend this peace of software.

Best, Bernd

1 Like