Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 


Hi All,

We have an interesting problem that we have been working on that really does not make any sense, so we are hoping that some of you clever folks out there can assist. We are testing the 3CX IP PBX SIP product in our lab and as expected run into a number of issues, most of which we fixed along the way without any problem. However, one issue remains.


We have the 3CX sitting behind a Pix running 8.0(4). Between the Pix and 3CX is a switch with very basic config.


The Pix is configured with all inbound access lists for port 5060 from VOIP provider, and we have also now made static entries for ports 10,000 to 10,050 as the 3CX seems to like this configuration. When we try another third party SIP PBX behind the Pix with exactly the same configuration it works with out bound and inbound calls 100% perfectly. Also, if we put the 3CX behind an IOS router it also seems to work pretty well, but behind the Pix we just cant get continuous success with inbound calls but outbound calls are 100% fine. We tried the third party PBX behind the Pix and made around 100 back to back inbound calls with 100% success. When we plug the 3CX in behind the Pix we get random inbound call failure as the packets seem to stop traversing the Outside to Inside interface on the Pix. Sometimes inbound calls do connect but with a delay of maybe 6 - 8 secs.


We have run a number of PCAPs but the problem can not be captured on the 3CX box when the failure occurs as no traffic is getting to the box. So, we used debug SIP which has shown up a problem with the capture. Please see below the extracts from the SIP debug output showing that the invite is not getting set up between Outside and Inside interfaces correctly. Instead we see the entry of "NP Identity Ifc".


Pix# SIP::INVITE received from Outside:<<VOIP PROVIDER IP>>/5060 to Inside:<<3CX INTERNAL IP>>/5060


Pix# SIP::INVITE received from Outside:<<VOIP PROVIDER IP>>/5060 to NP Identity Ifc:<<3CX INTERNAL IP>>/5060

We have tried turning off SIP inspect, but no change. However, if we do a restart of the Pix this does clear the issue for maybe 10 - 20 calls, then the calls will fail again, and then without any changes after maybe 20 mins the calls will start again. The problem is completely random which does suggest NAT, but the config works absolutely fine with other PBX systems, and how does the 3CX have any control over the Pix???

Very strange, anyone any ideas ????



I am assuming that a clear conn will do as much as the reload that you do. The issue remains in that the Connection (as your capture specifies) builds the connection to the NP interface, which of course, is not gonna be forwarded anywhere.

For your  test scenario, are you using NAT?  are you allowing the inbound connections using static PAT? What happens if you Nat the inside PBX to another free IP address?


Hi Mike,

To answer your questions:

Clear conn and clear xlate do not always clear the problem, only a full reload restart seems to work. In my experience a reload is never required on the Pix/ASA as those commands always fix this type of issue.

Yes, we are using NAT, here is the sample of our config:

static (Inside,Outside) udp interface sip sip netmask

static (Inside,Outside) udp interface 10000 10000 netmask

172.16. 0.254 is the PBX and for the UDP RTP traffic the config continues the same through to port 10050. Have not tried to NAT the pbx to another address as it would require considerable reconfiguration to test, which is OK but I like to troubleshoot by making as few changes as possible then retest. What is your thinking behind trying another address in the same network scope ?


Hi All,

We have now fixed this problem and found the issue.

It was down to the SIP inspect on the Pix not working with the 3CX SIP server. The 3CX was seeing the Pix as a back to back proxy and therefore not accepting the inbound packets. As soon as we turned off SIP inspection on the firewall and rebooted all was fine. The interesting point here is that it took a full reload to apply the changes and fix the problem.

Hope this helps anyone else who runs into this issue.


This document was generated from the following discussion: INTERMITTENT SIP CONNECTIVITY PROBLEM BEHIND PIX