Docker windows problem

[snon]

Hi,

new to the product, but has successfully installed and worked with it on CentOS servers. However, we want to run development locally and use Docker for this.
Created a simple docker compose:
image: flashphoner/webcallserver:latest
ports:
- "22:22"
- "8443:8443"
- "8444:8444"
- "30000-33000:30000-30000/udp"
environment:
PASSWORD: "xxx"
LICENSE: "xxx"
volumes:
- ./docker-data/flashphoner:/conf

Connecting to https://localhost:8444/admin/demo.html works fine. And the websocket works fine.

But, when the ICE candidates comes back they include the container IP and a lot of other local IPs (including the external IP of the developers network), BUT since Docker (on Windows atleast) doesn't provide a way to communicate with the container IP directly (the calls must be done to localhost), the connection fails.

More details on the Docker for windows situation here: https://github.com/docker/for-win/issues/221

On windows it's also not possible to run network mode HOST

So, my question is this: is there a way to have "localhost" included as an ICE candidate? Then Docker will be able to forward the connection properly (tested with netcat and debug inside container on port 31001)

Thanks!

 

[Max]

Good day.

On windows it's also not possible to run network mode HOST

We do not recommend to use Docker on Windows. Maybe, it would work normally in WSL 2, but now Linux is Docker native environment.
Please try to set the following parameter in flashphoner.properties (the file should be placed to conf folder you mount)

rtc_ice_add_local_interface=true

then add to environment: section the parameter

LOCAL_IP: localhost

In this case, WCS should bind to localhost and should add this to candidates list.
If this does not help, please use Docker on more suitable OS.

 

[snon]

Many thanks for the tip!

I guess some progress was made. When setting both LOCAL_IP and EXTERNAL_IP to 127.0.0.1 it does look like the candidate is correct:
o=Flashphoner 0 1592215009019 IN IP4 127.0.0.1
s=Flashphoner/1.0
c=IN IP4 127.0.0.1
t=0 0
m=audio 31006 RTP/SAVPF 111 8 9
c=IN IP4 127.0.0.1
a=mid:0
a=rtpmap:111 opus/48000/2
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=ptime:20
a=ice-pwd:3kmjd2osnnao6kjc2mgisja9uj
a=ice-ufrag:86dcfae0/aeee/11ea/87d4/27c7c15aad24ccldm1earmhtnj
a=fingerprint:SHA-256 46:2A:9C:233:AB:32:97:BE:79:AA:79:35:F5:9C:AD:F8:8A:AC:A 0:0E:A48:06:F4:36:76:36:A3:A9:69:A7
a=candidate:1 1 udp 2130706431 127.0.0.1 31006 typ host
a=candidate:1 2 udp 2130706431 127.0.0.1 31006 typ host
a=end-of-candidates
a=rtcp-mux
a=rtcp:31006 IN IP4 127.0.0.1
a=recvonly
m=video 31008 RTP/SAVPF 102 125 124 123 127 108 96
c=IN IP4 127.0.0.1
a=mid:1
a=rtpmap:102 H264/90000
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001 f
a=rtpmap:125 H264/90000
a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01 f
a=rtpmap:124 H264/90000
a=fmtp:124 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d003 2
a=rtpmap:123 H264/90000
a=fmtp:123 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=64003 2
a=rtpmap:127 H264/90000
a=fmtp:127 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001 f
a=rtpmap:108 H264/90000
a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01 f
a=rtpmap:96 VP8/90000
a=rtcp-fb:* ccm fir
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* goog-remb
a=ice-pwd:3kmjd2osnnao6kjc2mgisja9uj
a=ice-ufrag:86dcfae0/aeee/11ea/87d4/27c7c15aad24ccldm1earmhtnj
a=fingerprint:SHA-256 46:2A:9C:233:AB:32:97:BE:79:AA:79:35:F5:9C:AD:F8:8A:AC:A 0:0E:A48:06:F4:36:76:36:A3:A9:69:A7
a=candidate:1 1 udp 2130706431 127.0.0.1 31008 typ host
a=candidate:1 2 udp 2130706431 127.0.0.1 31008 typ host
a=end-of-candidates
a=rtcp-mux
a=rtcp:31008 IN IP4 127.0.0.1
a=recvonly


However, no traffic is passed and the candidate is marked as remote in Chrome internals (if that means anything - I don't have that level of understanding of the protocol):

Unless the above provides any additional clues, the conclusion is that this will not work.

 

[Max]

Unless the above provides any additional clues, the conclusion is that this will not work.

In this case, the only way is to use Docker on Linux, not on Windows.

 

[snon]

Thanks! We ended up running VirtualBox (with a small CentOS install with FP) on the dev machines.

Using bridge mode we can connect from the host to FP perfectly!

 

[snon]

Update: bridge mode caused all kinds of problems (packet loss, windows firewall etc) so we ended up with two interfaces, one NAT for internet access and one host-only with fixed IP that we can access FP from the host.

We still use Docker on the same host and that poses another set of issues, here's an article that pointed us in the right direction: https://www.tcg.com/blog/yes-you-can-run-docker-and-virtualbox-on-windows-10-home/

And, to top it off, we had issues with OpenJDK crashing inside the VirtualBox machine so we had to change to Oracle Java.

Now we have a dev setup that allows us to continue =)