Yeah, I mean the docker solution should be nice, if someone anyway already uses docker as platform for many other things. But as I never used it so far and also donât see any reason why I should, I donât like to use it just for one piece of software to run. The things you mention also donât look like itâs an âeasierâ solution in any way.
@https: As the turn server already listens to port 8443 now, could there be a problem using the same port for the spreed server? At least port 8443 is offered in the https section of the conf file. But I guess you can choose any free port? I wonder why I donât need the forward port 8080 where my spreed server listens to it so far (non https so far).
I will also try to get it work with https now and let you know how it works.
âŹ: Okay I tried to make spreed listen to https. For the first: It is not possible to use port 8443, if that is already used by the turn server. At least good to know for me as noob in this topics ;).
I tried to use port 8444 and adjusted the apache conf, spreed server conf and also the one for the nextcloud app, but at least I always got some handshake error message, trying to access the spreedme app.
But looking into the apache conf, I guess that the connection actually already is in https.
This is, what my nextcloud apache conf contains according to the guides:
<Location /webrtc>
ProxyPass http://127.0.0.1:8080/webrtc
ProxyPassReverse /webrtc
</Location>
<Location /webrtc/ws>
ProxyPass ws://127.0.0.1:8080/webrtc/ws
</Location>
ProxyVia On
ProxyPreserveHost On
RequestHeader set X-Forwarded-Proto 'https' env=HTTPS
I donât exactly understand all of this, but isnât this a sort of just redirecting the https request of the client internally to the http port where the spreed server listens? I mean even that spreed does not listen explicit to an https port, the access over the web browser is (as long as apache is configures accordingly) just possible over https, which also doesnât change, when accessing the spreedme app. This also explains why there is no port forwarding for 8080 necessary.
The official instructions say:
"Running for production
Spreed WebRTC should be run through a SSL frontend proxy with support for Websockets."
and then refer to documentation files that (for apache) show exactly the lines I show above.
So I guess everything is as it should be and the connection is âsaveâ through https, or am I wrong?