WebRTC audio over NAT (No AWS)

[Bruno Amaral]

Hey guys, 

I've spent some hours reading many topics here about NAT and WebRTC related problems, but most of the cases seemed to be about AWS or cloud services hosting, where you would have two or more network interfaces. In my case here, I'm just running a server on our LAN, and clients within the same LAN network can connect and use WebRTC audio. Then I tried to make some users outside our network connect, so I just forwarded the ports (5066 TCP - 16000 - 33000 UDP, plus the usual ones) on my firewall/router. Users from other networks can connect to server, everything loads great, everything but the webrtc audio.

I can see the call coming through on FS CLI, but then for some reason it disconnects. I did try to make some sense out of the explanation here , but I had the same results. When I tried to set my WAN IP address on sip.nginx, the call wouldnt even show up on the CLI.

Any idea is welcomed! Thanks.

[Chad Pilkey]

What error message are they getting? Can you get a full browser log and paste it to pastebin.com and link it back here.

[Bruno Amaral]

Thanks for stoping by Chad!

The client sees the 1007 error.

This is the browser log for the failed call - http://pastebin.com/RBpi58gZ

Here's a FS log of a failed try, from a client outside our network - http://pastebin.com/d1L0pPAD

To collect these logs, I did a new installation from scratch, took a ubuntu 14 template and went through the steps to install the latest beta build. I did not modify anything, just installed bigbluebutton and bbb-demo.

I did go over and over about my firewall rules, but I think they're ok, eveything else is working. I had a test asterisk box running to see if UDP and RTP traffic could pass by my firewall, forwarded the same UDP range to it and it did work.

[Chad Pilkey]

A 1007 error is an ICE Negotiation failure. That means that the server set up the web socket successfully, but the client and server couldn't send their media to each other. That explains why the call gets to Freeswitch and then fails.

It looks like Freeswitch is trying to use the server's local IP "192.168.20.11" on port 31572. For clients inside your network that local IP is likely reachable, but clients outside your network won't be able to connect because "192.168.20.11" doesn't mean anything to them.

In order to get it working you will need to change some of the Freeswitch properties from your local IP address to whatever your public IP address is. Note that using your Fully Qualified Domain Name (bbb-test.unicruz.edu.br) will not work, it needs to be the actual external IP address.

I think you will need to do some of the steps outlined in this section, https://code.google.com/p/bigbluebutton/wiki/090InstallationUbuntu#Audio_not_working. Unfortunately I've never tried to get Freeswitch working behind a router so it will probably take some experimentation. Try and document what the settings were before changing them in case you want to revert back.

Maybe other people can chime in if they've successfully done it.

[Bruno Amaral]

Yes, FS is trying to use my local bbb IP address to answer clients outside my network, that will never work. I looked over some FS documentation, and they suggest to use "auto-nat" for the the ext-rtp-ip and ext-sip-ip parameters. I guess I've already tried that, but I'll give it a go later.

I'll keep trying different configurations here, and if I come to a success, I'll post it here.

 

Thanks for your time Chad, and if anyone has a suggestion please share it.

[Chad Pilkey]

I would first try the following parts and test if it works. Some of the parts deal with the websocket and that is working fine for you so I wouldn't bother with those sections.

Change

<X-PRE-PROCESS cmd="set" data="external_rtp_ip=stun:stun.freeswitch.org"/>

To

<X-PRE-PROCESS cmd="set" data="external_rtp_ip=EXTERNAL_IP_ADDRESS"/>

Change

<X-PRE-PROCESS cmd="set" data="external_sip_ip=stun:stun.freeswitch.org"/>

To

<X-PRE-PROCESS cmd="set" data="external_sip_ip=EXTERNAL_IP_ADDRESS"/>

Edit /opt/freeswitch/conf/sip_profiles/external.xml and change

    <param name="rtp-ip" value="$${local_ip_v4}"/>
    <param name="sip-ip" value="$${local_ip_v4}"/>
    <param name="ext-rtp-ip" value="$${local_ip_v4}"/>
    <param name="ext-sip-ip" value="$${local_ip_v4}"/>

to

    <param name="rtp-ip" value="$${local_ip_v4}"/>
    <param name="sip-ip" value="$${local_ip_v4}"/>
    <param name="ext-rtp-ip" value="$${external_rtp_ip}"/>
    <param name="ext-sip-ip" value="$${external_sip_ip}"/>

[Bruno Amaral]

Tried that, same results...

Via: SIP/2.0/WS 2b88e9ojbg65.invalid;branch=z9hG4bK6707004;received=192.168.20.11;rport=51012

From: "bozb1iq3jff1-bbbID-bruno" <sip:bozb1iq3jff1...@bbb-test.unicruz.edu.br>;tag=oaum80l1gd

To: <sip:91...@bbb-test.unicruz.edu.br>

Call-ID: rbfq8o0phm3e14mjptt8

CSeq: 1053 INVITE

User-Agent: FreeSWITCH-mod_sofia/1.5.15b+git~20141027T191421Z~75815877d6~64bit

Content-Length: 0

The client still receives the LAN IP address as the address to connect to, even though it does send INVITE to my FQDN .

[Bruno Amaral]

Just wanted to give a heads up on this matter, I ended up giving up on the idea. Too bad, the WebRTC audio was one major improvement, even more for users with a bit of latency. I tried several different configurations, looked for help on the FS mailing list, but I was unable to solve it. Maybe it's a simple fix, but I just cant see it now. I'm trying to order a new block of IPs from our ISP so we can set a valid IP directly on our server, but I dislike the idea of my BBB Server staying out of our Firewall. For now, we're just using flash audio.

Thanks again for the suggestions so far, and to the BBB team for the amazing software.

[HostBBB.com]

Bruno,  what firewall appliance are you using?

If you log on to server, can you

1) sudo ping your.domainname.com

2) telnet your.domainname.com 5066

Want to make sure your able to route thru external ip back to server.

We have been working on getting web-rtc working thru a few different firewall appliances (Squid, Sonic) and experienced some issues like you are experiencing.

In one scenario, we ended up setting up a dedicated stun/turn server that supports udp and tcp, and will relay the media streams between server and the clients in worst case. This greatly improved connection success.

Regards,

Stephen

hostbbb.com

[Kent B]

´Hello

I have this same webrtc problem behind nat. When i telnet to 5066 i get this error message:

kent@xxxxxxx:~$ telnet xxxxx.se 5066

Trying xx.xx.xx.xx...

Connected to xxxxx.se.

Escape character is '^]'.

HTTP/1.1 400 Bad Request

Sec-WebSocket-Version: 13

Connection closed by foreign host.

Regards Kent

[Bruno Amaral]

Stephen, we have at the moment a Cisco ASA 5500 series firewall.

I can`t ping my FQDN, but that's a setting I have on my firewall, can that be a problem?

Yes, I can telnet on 5066.

I did some research on STUN servers, I tried using a public one (stun.freeswitch.org), but I guess I either didn't set up right on the config files or this STUN server isnt working. Either way, it didnt work. But I was thinking that the final answer to this might have something to do with STUN, and hearing you had success with this gives me some perspective.

[Bruno Amaral]

My ISP just delivered an extra IP address range, and I succesfully managed to make WebRTC audio work, though that was previsible since no NAT is involved now, and the public IP address is set on the eth0 of my server.

But one thing I had to do was follow the instructions here, even though no multiple network interfaces were involved. So I'm guessing you have to change those settings on FreeSwitch and sip.nginx in any case where you'd have your server open for clients on the internet. Does that sounds right devs? 

Wish I had the same success as Stephen did deploying a STUN/TURN server on my network, but that wasn't the case. 

Waiting for Issue 1863 to get resolved! :-)