Hi everyone!
Iām very excited about the open-sourced HPB and so I wanted to try it with my Nextcloud instance in a docker environment.
I was able to build the images and run the containers from https://github.com/gary-kim/nextcloud-spreed-signaling/tree/enh/noid/docker, but as soon as I try to integrate the Janus server, the video streams canāt be joined anymore.
Without Janus everything seems to work. Does the Janus server need to be reachable directly from the Internet? Our Docker containers are all placed behind a traefik reverse proxy and can communicate over a docker network.
If you need any config files, just let me know
Thanks in advance and best regards
Chris
Hi there.
I was also playing with the high performance backend and made my own containers of nats and signaling and placed them behind a traefik proxy. However, I would like to have a complete understanding, which ports of which services need to be available to the public and how the communication flow between services is.
Can anyone provide an example network map or flowchart for the high performance backend?
Ben
I finally got it running. The WebSockets port of the Janus server just needs to be reachable by the signaling server, but you have to expose some UDP ports (adjust the configuration in janus.jcfg to the same port range) to the internet.
ThatĀ“s great.
Maybe itĀ“s possible to tell us step by step your way.
Thanks
Django43
Hi
As weāre using Docker Swarm with Portainer and Traefik as a reverse proxy, I donāt know how much I could help you with my docker-compose stack.
But basically I built the Docker images with the Dockerfiles from gary-kimās Github repository. By now, I have switched to some other images (see: https://github.com/lnobach/nctalk-backend-cloud-config). We already had a coturn server running, so i re-used it.
Hereās our stack:
spreedbackend:
image: lnobach/spreed-signaling:0.1.2
labels:
- "traefik.enable=true"
- "traefik.http.services.nextcloud_spreed.loadbalancer.server.port=8080"
- "traefik.http.routers.nextcloud_spreed.rule=Host(`host.name.invalid`)"
- "traefik.http.routers.nextcloud_spreed.entrypoints=websecure"
- "traefik.http.routers.nextcloud_spreed.tls.certresolver=letsencrypt"
- "traefik.http.middlewares.spreed_headers.headers.customRequestHeaders.X-Forwarded-Proto=https"
- "traefik.http.routers.nextcloud_spreed.middlewares=spreed_headers"
volumes:
- spreed_config:/config
networks:
- traefik_default
- nextcloud
restart: unless-stopped
depends_on:
- nats
- janus
nats:
image: nats:2.1
volumes:
- nats_config:/config
command: ["-c", "/config/gnatsd.conf"]
networks:
- nextcloud
restart: unless-stopped
janus:
image: canyan/janus-gateway:0.9.2
command: ["janus"]
ports:
- "port-range:port-range/udp" # same in janus.jcfg
volumes:
- janus_config:/usr/local/etc/janus
networks:
- nextcloud
- traefik_default
restart: unless-stopped
Inside the janus.jcfg I changed the rtp_port_range under media and nat_1_1_mapping = āexternal.ipā under nat.
I hope this will help you
Thanks, just curious, how are you handling WebRTC DTLS encryption?
I kept the defaults regarding DTLS in janus.jcfg
Got it, thanks. It is still unclear to me, based on the description from lnobachās site if that means there is a MITM vulnerability or not? I cannot tell, but am interested. Docker has vulnerabilities, and Docker + MITM combined would be excessive IMO, but if it is not an actual MITM threat then I am simply being too cautious
Hereās the description of the parameter from the janus.jcfg.example file regarding self-signed DTLS certificates:
Notice that self-signed certificates are fine for the purpose of WebRTC DTLS connectivity, for the time being, at least until Identity Providers are standardized and implemented in browsers. If for some reason you want to enforce the DTLS stack in Janus to enforce valid certificates from peers, though, you can do that setting ādtls_accept_selfsignedā to āfalseā below: DO NOT TOUCH THAT IF YOU DO NOT KNOW WHAT YOUāRE DOING!
https://webrtchacks.com/webrtc-and-man-in-the-middle-attacks/
Following the above link, DTLS-MITM-attacks can easily be successful, if the signaling server is not secured well. So as I understand, the problem is not using DTLS with self-signed certificates itself. Itās only a problem, if someone manages to compromise your signaling server.