Dockerize app

[forresthopkinsa]

Should fix #3

Let me know if I missed anything here

[forresthopkinsa]

Looks like I need to rebase on master to account for recent commits, I'll do that later

[forresthopkinsa]

Original commits were moved to forresthopkinsa/bitlink:dockerize-0

[jbis9051]

The current config doesn't work for Firefox.

For some reason, Firefox (and Chrome) doesn't allow WebRTC to connect to 127.0.0.1 via UDP. Chrome, however, allows connecting to 127.0.0.1 TCP (which is why chome works but Firefox does not).

If you attempt to connect in FireFox with the current config, you will get something like ICE failed, add a STUN server and see about:webrtc for more details.

I've got around this by using MEDIASOUP_LISTEN_IP=192.168.1.197 aka my internal IP address for development. Since it wasn't localhost FireFox connected to it without issue.

I'm unsure how to do something similar with a docker image. Would we need the developer to pass in their internal IP in an environment variable? Ideally I would like it to continue to work in FireFox in development/demo.

Note, production environments aren't effected by this.

[bmcgonag]

@jbis9051 you might try passing in the docker0 address if you are running it on the same machine, or set the flag --net host when you run the docker command.

I haven't had a chance to try it yet, but plan to later, so can update my thoughts (particularly as a firefox user).

[forresthopkinsa]

Nothing needs to be changed in the Docker image to account for that; the image doesn't set that variable to anything on its own. But it would probably be a good idea to document this behavior for anyone trying to run the image.

It's the docker-compose.yml that would need to be changed for this. I'm not sure how we can get around that, other than to tell people to edit the file with their own IP if they want it to work with Firefox. I'll think about that one for a bit.

@bmcgonag I'm interested to see how it works for you. Keep in mind though that I can't instruct people to use host networking, because that's only supported on Linux hosts. Instead we have to jump through the requisite hoops for bridge networking.

[jbis9051]

Added notes about FF issue 9dbd089.

[bmcgonag]

Apologies for the long delay, but my system died (actually I killed it through stupidity, not related to this project at all), but had to get time to reinstall it, and get it setup again.

I ran the docker-compose, and it came up after the build, just fine. Able to access it through localhost with no issue.

About to attempt the dockerfile alone.

[bmcgonag]

Ok, in testing with my wife on another machine on my network, we can both connect to 1 room, but are not able to hear or view each other's cameras. After giving the browser permission, we each see our own camera, but cannot hear or see each other. This is using the docker-compose version with no changes.

[jbis9051]

@bmcgonag

Ok, in testing with my wife on another machine on my network, we can both connect to 1 room, but are not able to hear or view each other's cameras. After giving the browser permission, we each see our own camera, but cannot hear or see each other. This is using the docker-compose version with no changes.

This is expected. With the default setup, Mediasoup will announce to any external devices "connect to 127.0.0.1 for WebRTC". Your wife's device will try connecting to itself and fail. Instead we need to tell those external devices to connect to the correct device. I suggest you use the internal IP of the computer running the docker container.

For me this looks like:

// docker-compose.yml
  environment:
      MEDIASOUP_ANNOUNCED_IP: "192.168.1.197"
      MEDIASOUP_LISTEN_IP: "0.0.0.0"

With the above setup, I was able to get it working on Chrome/Firefox and external devices.

Please note, you may run into permissions issues while accessing the camera/microphone on external devices if you are not using HTTPS. See https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia "Privacy and security" section for more information.

[bmcgonag]

Still working on this, but I did try the above suggestion, setting the machine IP for the Announce IP, and 0.0.0.0 for the listen IP. I did leave the default port settings already in the compose file.

I then setup a reverse proxy with SSL through LetsEncrypt, and was able to join the same room (as chat was working), but still could not see or hear the other machine.

I'm sure I'm doing something wrong. Here's my docker-compose file.

version: '3.2'

services:
  server:
    build: .
    environment:
      PORT: "3000"
      MEDIASOUP_LISTEN_IP: "0.0.0.0"
      MEDIASOUP_ANNOUNCED_IP: "192.168.7.221"
      MEDIASOUP_MIN_PORT: "3001"
      MEDIASOUP_MAX_PORT: "3020"
    ports:
      - "3000-3020:3000-3020/tcp"
      - "3000-3020:3000-3020/udp"

Note, I did have to change the version to 3.2, as my Ubuntu 20.04 install with docker-compose says 3.8 is not a valid version.

[jbis9051]

@bmcgonag

I then setup a reverse proxy with SSL through LetsEncrypt, and was able to join the same room (as chat was working), but still could not see or hear the other machine.

Hmm. Are you sure that ports 3001-3020 were accessible through the proxy?

[bmcgonag]

No. What are those port ranges used for?

I'm looking at nginx and prot ranges, and if those are listen ports, then it's a bit untenable to try and proxy them all.

[jbis9051]

@bmcgonag

No. What are those port ranges used for?

Those are used for WebRTC. Aka what allows the video and audio to work. They don't need to proxied through nginx just accessible directly.

[bmcgonag]

@bmcgonag

No. What are those port ranges used for?

Those are used for WebRTC. Aka what allows the video and audio to work. They don't need to proxied through nginx just accessible directly.

Ok, then it was definitely open as far as firewall goes. No ports blocked on internal network. Maybe it if went out to the internet and back in?

I"ll try something a little different tomorrow. Just wasn't allowing access to Mic or Camera without https. I can probably generate a self signed cert and try, just no mobile devices allowed.

[jbis9051]

Seems very inconsistent. Just tried again and Chrome <---> Chrome worked but Chrome <---> Firefox and external devices didn't work.