I am using voip-unlimited as a sip provider and calls to and from my 3CX phone system keep dropping after 30 seconds exactly with ACK not receieved.

The 3CX system is installed on a Win XP Pro PC as reccommended and we have also tried it on a Server 2003 machine as well with all software firewalls and anti-virus disabled.

I only get this issues with voip-unlimited as it works OK with sipgate. Port 5060 is what 3CX require opening on the firewall which has been done bu the firewall checker in 3CX reports that the port is being translated to something else.

On Cisco devices it is referred to as “SIP Fixup” and it is enabled by default on both routers and PIX devices. Because this is a default setting, no indication of it being on or off is visible in the configuration. “SIP Fixup” causes many problems and, if enabled, will cease to work with VoIP/SIP. To disable SIP Fixup on Cisco devices you must issue the following commands: fixup protocol sip 5060 fixup protocol sip udp 5060

In addition some provision must be provided to allow the inbound SIP traffic to reach the SIP device(s). Access lists or conduits may be helpful. Following is a portion of the configuration for an example access list: access-list 101 permit tcp host 100.1.1.2 host 100.1.1.5 eq 5060

Additionally, when you set the Global Default UDP timeout value on a SonicWALL firewall, you still MUST fix the pre-existing rules’ individual UDP timeout values. New rules will inherit the Global Default. Since 30 seconds is no longer a sufficient UDP timeout as it once was (to allow for the UDP heartbeat sessions to keep-alive from the phones to the border manager), we must increase the UDP timeout to the suggested 300 seconds Globally on the firewall, AND the specific out-bound firewall rule (or default rule as the case maybe) to the UDP timeout of 300 seconds.

From CLI interface, type the following commands.

config system session-helper <enter> show system session-helper <enter> (look for the session instance that refers to SIP, should be #12) delete 12 <enter> * example only, be sure to select the corresponding number to be deleted *

Confirm deletion of session-helper entry by running the “show system session-helper” command again. #12 will be there because #13 moved up in rank, but no reference to SIP or port 5060 noted.

End <enter>

Try the follow configuration the Linksys BEFSR41 router:

From the ADMIN page of the router navigate to [APPLICATIONS & GAMING] > [PORT TRIGGERING]

Enter [TCP] as the application.

Enter [5060] into the Start Port and End Port for both the Triggering and Forwaded Ranges

Check the Enable box.

Save Settings and reboot VOIP Telephone.

Then after you realize its not really even worth owning this device, go buy a decent router…

Untangle devices utilize the SIP NAT helper in IPTables. With no configuration outbound calls should work fine. For incoming calls and external phones you must add a port forward; forward from external port 5060 TCP & UDP to the internal IP of the SIP device(s). For IAX do the same thing for port 4569. In Untangle port forwards are located under Config → Networking → Port Forward.

If for some reason the Linux IPTables SIP NAT helper is not working properly, a port forward for RTP traffic will be required. Ports 10000-20000 UDP will need to be forwarded to the internal address of the SIP devices as well.

The SIP ALG must be disabled as the implementation does not work and completely breaks SIP/RTP traffic

This has been tested and confirmed on the FVS338 model; please note without ALG this device seems to work and even has a rudimentary QoS (Protocol based and device based)

QoS setup:

Security ⇒ Services ⇒ create new rule named RTP, UDP protocol ports 10k-20k, maximize throughput do the same thing, but name it RTP2 and select Minimize Delay as well

Network Configuration → LAN Settings → LAN Groups. Here you should see the name and IP address of everything on your network.

In the group column, the default name is Group1. Identify your VOIP phones (by IP), and click on edit beside each one.

Change the group for all your VOIP phones to another group. In my case, I changed all to Group2.

The problem I have found out today from ISP is that the firewall being used for this connection cannot have port translation disabled and as 3cx requires static port mapping for port 5060 it won't work.

We have a fixed IP so I have fixed this problem in part by disabling STUN resolution but now I am getting one way audio.

On Cisco devices it is referred to as “SIP Fixup” and it is enabled by default on both routers and PIX devices. Because this is a default setting, no indication of it being on or off is visible in the configuration. “SIP Fixup” causes many problems and, if enabled, will cease to work with VoIP/SIP. To disable SIP Fixup on Cisco devices you must issue the following commands: fixup protocol sip 5060 fixup protocol sip udp 5060

In addition some provision must be provided to allow the inbound SIP traffic to reach the SIP device(s). Access lists or conduits may be helpful. Following is a portion of the configuration for an example access list: access-list 101 permit tcp host 100.1.1.2 host 100.1.1.5 eq 5060

Additionally, when you set the Global Default UDP timeout value on a SonicWALL firewall, you still MUST fix the pre-existing rules’ individual UDP timeout values. New rules will inherit the Global Default. Since 30 seconds is no longer a sufficient UDP timeout as it once was (to allow for the UDP heartbeat sessions to keep-alive from the phones to the border manager), we must increase the UDP timeout to the suggested 300 seconds Globally on the firewall, AND the specific out-bound firewall rule (or default rule as the case maybe) to the UDP timeout of 300 seconds.

From CLI interface, type the following commands.

config system session-helper <enter> show system session-helper <enter> (look for the session instance that refers to SIP, should be #12) delete 12 <enter> * example only, be sure to select the corresponding number to be deleted *

Confirm deletion of session-helper entry by running the “show system session-helper” command again. #12 will be there because #13 moved up in rank, but no reference to SIP or port 5060 noted.

End <enter>

Try the follow configuration the Linksys BEFSR41 router:

From the ADMIN page of the router navigate to [APPLICATIONS & GAMING] > [PORT TRIGGERING]

Enter [TCP] as the application.

Enter [5060] into the Start Port and End Port for both the Triggering and Forwaded Ranges

Check the Enable box.

Save Settings and reboot VOIP Telephone.

Then after you realize its not really even worth owning this device, go buy a decent router…

Untangle devices utilize the SIP NAT helper in IPTables. With no configuration outbound calls should work fine. For incoming calls and external phones you must add a port forward; forward from external port 5060 TCP & UDP to the internal IP of the SIP device(s). For IAX do the same thing for port 4569. In Untangle port forwards are located under Config → Networking → Port Forward.

If for some reason the Linux IPTables SIP NAT helper is not working properly, a port forward for RTP traffic will be required. Ports 10000-20000 UDP will need to be forwarded to the internal address of the SIP devices as well.

The SIP ALG must be disabled as the implementation does not work and completely breaks SIP/RTP traffic

This has been tested and confirmed on the FVS338 model; please note without ALG this device seems to work and even has a rudimentary QoS (Protocol based and device based)

QoS setup:

Security ⇒ Services ⇒ create new rule named RTP, UDP protocol ports 10k-20k, maximize throughput do the same thing, but name it RTP2 and select Minimize Delay as well

Network Configuration → LAN Settings → LAN Groups. Here you should see the name and IP address of everything on your network.

In the group column, the default name is Group1. Identify your VOIP phones (by IP), and click on edit beside each one.

Change the group for all your VOIP phones to another group. In my case, I changed all to Group2.

Thanks for your help everyone. Got this issue fixed, it was a firewall related issue and after some dicussion with the ISP that managed this particular firewall it has been resolved.

I would however like any input from anyone on improving call quality with VoIP. Most of the calls are OK but we do get the odd one where there is a few seconds silence and then the call returns to normal.

The phone system and the phones are all on a seperate physical network and it has it's own dedicated ADSL connection (up to 8Mbps probably getting about 3-4). Should I be looking at quality of service options on the firewall and which ports should they be applied to?

1st Post

Further to this voip-unlimited does seem problematic had to enable keep alives on 3cs and turn off external stun resolution. voip-unlimited support isnt great as they always tell you its a firewall issue. The rules in t he firewall need to be right and our ISP has set them correctly but enabling keep alives is the only way to get it to work,

TrevorR wrote:

Hi Benratty

I'm having the same issue on a 3CX with a Sofaware devices and Voip Unlimited. Do you know what your ISP changed in the firewall config to resolve this?

1st Post

Hi all,

Dunno if this will help as the thread looks kinda old, but if you go into the 3CX admin webpage, then go to the Admin settings, take note of the SIP Port number, change it to 1234. then in settings on the server restarrt the PostGres DB (does the server in addition) then try to make a call - it wont work, now go back into the admin page and put it back to the port used earlier (I was on 5060 default) and again apply, restart the PostGres DB (and server service) et voila!

1st Post

I got this issue and have spend the day resolving it. The issue came from users on our WAN no the LAN.

Seems the 'Static Public IP' was interfering in our WAN users (who were connected to us but not through our internet connection), so under Settings > Network > STUN server I ticked "Turn off STUN Requests" and set the Static Public IP to the same as the NIC.

Completely solving the issue of calls hanging up after 30 seconds. I could have pointed them to the router that connects all the branches I guess, but I did just the same as the NIC and it worked and I don't wish to mess with it as it's working.

1st Post

On my case, my one-way audio problem occurred between a 3CX bridge between two 3CX PABXs where one of them had secondary IP address which was causing this trouble.

Removing the secondary IP address resolved the problem.

I've done some troubleshooting until identify a pattern then, i had to reduce the scope problem as much as i could to reproduce on a simpler way, so analysis would be easier and through that analysis i saw on a perimeter firewall, what was causing this mess.

Not really, the older Checkpoint models allow you to expose the system to the internet but that comes with risks. Where we have these 3CX systems now we have updated firewalls/routers to compatible models listed on 3CX website. Draytek ones a really good and work well so far no issues.