If anyone else is having a similar issue, I have created jira ticket #FS-6691 To clarify the issue, some RTP packets are initially sent out an unexpected/incorrect interface when the session first begins. It seems that freeswitch will eventually send the packets the correct direction, if the clients continue to send traffic from the correct IP. In my test setup, these rogue RTP packets going the wrong direction actually cause incorrect entries in my firewall. This leads to the clients not getting their source translated any more, and exaggerates this condition. On Thu, Jul 24, 2014 at 9:35 AM, sangdrax8 <sangdrax8@gmail.com> wrote:
I am trying to get the current git pull to work using the default configurations that are provided. I am having issues that seem related to routing, or possibly NAT. Let me try and explain my issue, and see if someone knows there is a setting I am missing or if this is actually some strange bug.
Basic setup: I am using the default configuration provided, only changing the default password for clients. My test machine has 2 interfaces, eth0 on the internet (no NAT), and eth1 on an internal RFC address. With the default configuration, the "internal" profile is on the internet address from eth0 on port 5060. The "external" profile is on the same eth0 ip, on port 5080.
Problem: So everything looks normal, and I can register two soft clients (Groundwire, one android one iPhone) to the internal profile. When I place a call between 1000 and 1001, the SIP packets all work exactly as expected, but I get no audio. Using these same to clients on an older build (still 1.5.x) in my production environment works just fine. So I would think the clients settings are fairly standard.
Looking at the server, I found that the freeswitch is sending the audio packets to the RFC address of my clients (192.168.x.x) and is deciding to send these packets out my eth1 interface. Now I do route all RFC's out eth1, so this test server can be connected to from the inside. It doesn't have an interface in the same subnet as the clients though, just a route for all RFC's internally. Testing a theory, I removed the route to the 192.168.x.x range which the phones happen to be in (wifi network gets NAT to the internet when connecting to this machine as most clients probably do). Once I do this, and with no changes to my freeswitch, the audio works. With out this route on the base server, freeswitch sends the UDP packets out eth0, back to the correct Internet IP my clients connected from.
I thought maybe this had something to do with nat.auto, or localnet.auto, but using the acl cli command, it would seem these things all check out correctly. When I ask it if the 192.168 net is in the nat.auto it returns true, so it would see to know it SHOULD be natting for that network. The only false I get is for the subnet that my eth0 is in.
If, by chance, I had been testing with a range that my server didn't have a route to (if I didn't route all RFC's internally) I probably wouldn't have seen this.