Nextcloud Talk HPB questions regarding docker and Janus

[Chartman123]

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

[bedawi]

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

[Chartman123]

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.

[Django43]

That´s great.

Maybe it´s possible to tell us step by step your way.

Thanks

Django43

[Chartman123]

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

[sourvader]

Thanks, just curious, how are you handling WebRTC DTLS encryption?

[Chartman123]

I kept the defaults regarding DTLS in janus.jcfg

[sourvader]

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

[Chartman123]

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!

WebRTC and Man in the Middle Attacks - webrtcHacks

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.