FreeSWITCH in docker container gives 1007

[Nikola Radovanovic]

Hi all,

recently I have got a task to explore available options regarding splitting BBB among different docker containers. 

One of the things to 'dockerize' is FreeSWITCH. As first step I compiled latest release (1.10) and 'plant' it instead of one set by BBB installer script (/opt/freeswitch) and replaced conf and share folders with the ones BBB set initially. This worked without problem. Next, I built FreeSWITCH inside a container and copied same conf and shared folder into it, so its the same as on host. Since my host was behind NAT I followed configuration guidelines for this scenario; but I get 1007 ICE when trying to use greenlight client, and not sure where it get stuck. I forwarded 15000-32768 TCP/UDP ports from router to a PC that runs the docker image and also did: 

sudo iptables -A DOCKER -t nat -p udp -m udp ! -i docker0 --dport 15000:32768 -j DNAT --to-destination 172.16.238.6:15000-32768

Where 172.16.238.6 is (static) IP of FreeSwitch container.

How can I debug this? Any help is more than welcome since I have no clue about BBB.

Side question: what I need to configure in order to replace Etherpad with docker image? I tried to just run docker exposing 9001 on host but that did not work.

Thank you kindly

[Brent W. Baccala]

This might be the same kind of issue I had.

I don't completely understand your setup, but I got 1007 ICE because my clients were behind a firewall and the server couldn't send UDP packets to them.

It's not enough for the clients to be able to send UDP to FreeSWITCH.  FreeSWITCH also has to be able to send UDP back to the clients.

The "standard" way to fix this is to run a TURN server (like coturn) which lets your clients connect via TCP and then relay UDP "backwards" through the tunnel. 

[Chad Pilkey]

Running within a docker container adds its own challenges. A TURN server might work, but it will then be sending all traffic over TCP when you really want UDP for most users.

When everyone is failing to connect to audio, the place to look is about:webrtc in Firefox. That will tell you if you server is sending the wrong IP for its candidate or if it's sending the right IP and it just isn't connecting.

[Gerhard Peters]

I had the same issue on a AWS server. After troubleshooting for a while I notice that in the security group I did not set the port as UDP. After making that change it worked

[Nikola Radovanovic]

I will try to explain setup first: there is one host (HW not VM) behind NAT (standard CISCO router from my ISP, nothing fancy). On this HW (192.168.0.17) I have BBB installed by using bbb-install script. BBB installs docker for greenlight and Postgresql. I have following router configuration:

Now, this setup works, but with one catch: when I wan to access BBB instance running on this server from my laptop for instance, I have to add 192.168.0.17 in its /etc/hosts file - otherwise it does not work. Not sure why.

What I did next is to compile FS on BBB server and replace the one that BBB sets up via deb packages. I kept config files though. It works same as with original installation.

When I move FS to a docker container, then I get ICE 1007 when loading echo on BBB server, which did not happen previously. I am forwarding ports in range 15000 to 32768 from host running FS in docker directly to running FS container. I am not sure where error is, my guess its some configuration, but not sure where to look at.

Thank you all

[Chad Pilkey]

I put the place to look in my previous message. If use Firefox, get the 1007 error and then open a tab to about:webrtc. Once you're on the diagnostics page check to see what IP and port the remote candidate is set to.

[Nikola Radovanovic]

Thank you for the suggestion. Yes, in the meantime I did this. Strange thing is that sometimes it works and sometimes is not. I have attached log here, so if anyone is kind to take a look - it does not says to me much since I have no experience in WebRTC

Kindest regards

[Paulo R. Lanzarin]

Are you running FS's container in bridge mode? Did you try running it in network mode instead of doing the port mapping?

On Wed, Apr 1, 2020 at 6:49 AM Nikola Radovanovic <niko...@gmail.com> wrote:

Thank you for the suggestion. Yes, in the meantime I did this. Strange thing is that sometimes it works and sometimes is not. I have attached log here, so if anyone is kind to take a look - it does not says to me much since I have no experience in WebRTC

Kindest regards

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bigbluebutton-dev/1d000f0f-75c9-49f4-a8dd-730f410338b5%40googlegroups.com.

[Nikola Radovanovic]

I created network manually in bridged mode in order to support IPv6:

docker network create --driver bridge --ipv6 --subnet fd15:555::/64 --subnet 172.16.238.0/24 mynet --attachable

Did not think of that...I will try. Thanks!

[Paulo R. Lanzarin]

yeah, just "--network host" with no port mapping

--

You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bigbluebutton-dev/2afcd5c9-c552-4332-8a65-ef40254a1d22%40googlegroups.com.