Data-channels not working in Docker

[Parth]

Data-channels not working in Docker

Hi! I'm using WebRTC for a game, the back-end is written in go, and the frontend is a browser client. Thanks to this library I was able to drop in WebRTC in place of websockets. The network performance is significantly better, this is an awesome project!

I do however have an issue running this within docker locally. So my gameserver can run within docker, or directly as a binary (just like the data-channels example), and it can run locally, or in the cloud. The following depicts what works and what doesn't.

	Locally	Cloud
Execute Binary Directly	Works	Works
Execute Within Docker	Error	Works

Reproducing

This can be easily replicated using the data-channels example:

1. First open the fiddle frontend.
2. In a local directory copy the Browser SDP to a file named sdp.
3. Place the Dockerfile provided below into this directory.
4. Execute: docker build -t data-channels . && docker run data-channels

This is likely a docker issue, and perhaps I should create a ticket there. But I get the sense that many people who use WebRTC will be interested in using it with Docker, however not everyone who uses Docker will be using WebRTC.

Thank you!

Dockerfile

FROM golang:1.10

WORKDIR /files
COPY sdp .
RUN cat /files/sdp

RUN go get github.com/pions/webrtc/examples/data-channels

CMD ["/bin/sh", "-c", "cat sdp | data-channels"]

Some other logs, that google didn't really offer much help with:

could not allocate udp6 stun:stun.l.google.com:19302: Failed to create STUN client: dial udp6 [2607:f8b0:400d:c0d::7f]:19302: connect: cannot assign requested address
could not allocate udp6 stun:stun.l.google.com:19302: Failed to create STUN client: dial udp6 [2607:f8b0:400d:c0d::7f]:19302: connect: cannot assign requested address

I attempted to change these sysctl settings on the host computer, but this issue has been replicated in macOS & Windows as well, my host environment is Ubuntu 18.04.

net.ipv6.conf.all.forwarding=1

[Sean-Der]

Hey @Parth Thanks for using pion-WebRTC, I am really excited to see the game you are working on when it is complete :)

So my assumption is that Chromium is creating ICE candidates using interfaces that don't route to your Docker container (so it is unable to communicate) a good way to see how this all works is using the ICE debugging stuff. Sorry it isn't documented but here is the commit that added it! I would enable it to compare.

This issue with networking also only exists on OSX/Windows unfortunately, because it puts all containers behind a NAT. I am not positive this will work, but can you calling this and then mapping these ports?

You could also try running your browser inside your containers.

My last idea would be to play with PORTALLOCATOR_ENABLE_ANY_ADDRESS_PORTS it is a feature of Chromium, I have never actually used it before (sorry!)

Happy to debug/throw ideas around in Slack also. We will find a way to figure it out though :)

[backkem]

I did some quick testing on my end. I'm running on Windows where docker has its own network adapter that places all containers behind a NAT, as Sean mentioned. If I run data-channels from a container I can connect using Chrome but not using Firefox. Firefox doesn't include an IP address of the Docker NAT in it's offer. I'm not sure if Firefox has a setting for this.

[Parth]

Hey guys, thanks for all the resources!

Few questions:

• Is there a way I can just not use STUN/ICE? My server has a static IP address, I can choose who creates the offer, and who creates the answer. What do you guys think about that strategy?
• From the first post, the logs about udp6 came from my gameserver. Does that mean I have the ICE logging enabled already?
• So this function is just a global function that's a member of the webrtc package? So I should just call that function during my server initialization before any clients join? What's the motivation for bounding the ports that are going to be used?

I'd love to continue the conversation on Slack, slack says.

Contact the workspace administrator for an invitation

my email is parth.mehrotra.cs@gmail.com

After we get this resolved I can leave a summary of what worked and close this issue (for future people who have similar problems with WebRTC/docker).

[backkem]

Hey, Some notes:

• No, there is no way to skip STUN/ICE in WebRTC.
• This warning probably shows up because the machine doesn't support IPv6. In master this logging should not be enabled using an environment variable. Maybe you have a version of the library from before that change?
• Yes, However, I would not recommend using it for this use-case.
• In order to join the gopher slack you can get an automatic invite using this link.

I'll try to brainstorm a workaround for this problem.

[backkem]

After some digging I found this issue. Firefox apparently implements these guidelines. They restrict the IP information that is allowed to be used without explicit user consent. To test this theory I checked the SDP for the gstreamer-receive example. This example indeed has the Docker NAT candidates in the SDP because of the consent provided when calling getUserMedia. I'll try to investigate if we can manually ask for permissions somehow.

[backkem]

Sadly I think the only workaround available in Firefox at the moment is to also request user media. More related issues:

• 1438823: Data channel only applications are restricted to default route addresses
• 1445771: Loopback and link-local addresses

Alternatively, I would suggest using Chrome for testing when using Docker.

[Parth]

Hey, Caught up with some other work at the moment, will report back soon!

[Parth]

Okay you gave me a bunch of good resources to go through, and this is my current understanding:

In certain conditions ICE has the potential to expose information about the client's network stack. This can be particularly bad if the client is behind a VPN. But if they're behind a VPN for reasons other than privacy (corporate network) they still may prefer to connect to their peer directly and may not care.

Because of this interesting tradeoff between privacy & media performance the draft suggests 4 modes that browsers can operate in.

By default the data-channels operate in a mode where they can't communicate with devices on a different interface, as chrome prevents some of those addresses from being known (still a bit unclear here, but I understand what's happening at a high level. I think I need to read a bit more about how network interfaces work & docker networking interfaces).

So what I can do is (when testing locally) call getUserMedia() during/before handshake and that will allow chrome to speak to a broader range of network devices.

Is this the correct workaround? Again it doesn't matter all that much what the form of the workaround is because this only affects engineers who are developing locally. So if we need to do something like "change setting X in browser Y" that's totally fine with us. In fact, something like that is preferred to adding getUserMedia() for local development. But you mentioned:

Alternatively, I would suggest using Chrome for testing when using Docker.

and I'm just not sure what I should do to get it to work, I've only used chrome so far.

Thanks again for your time and energy!

[backkem]

Using Chrome did work on my machine. I was only able to reproduce using FF. I'm not sure what we're doing differently. For me:

• Works: example data-channels running in Docker for Windows, paired with Chrome on Windows.
• Doesn't work: example data-channels running in Docker for Windows, paired with Firefox on Windows.
• Works: example gstreamer-receive running in Docker for Windows, paired with Firefox on Windows. Maybe you can test gstreamer-receive in your setup?

[Parth]

Let me give this a shot with:

• Windows
• gstreamer*

Will report back