Hello everyone. I recently just set up a FreePBX server using the AsteriskNOW CD. I have everything upgraded through the module page to 2.6. I purchased 1 trunk and 2 DID’s from the FreePBX store. I also have 2 Aastra 6730i sip phone set up and connected.
I have set up and configured the trunk per the information page in my sipstation account. Everything for the most part is working fine…EXCEPT…About every third or so incoming call to the FreePBX box does not go through and the caller gets a “not in service message”. If that caller calls right back it will go through. I am stumped as to what could be causing this.
I have forwarded ports 5060UDP and 10001-20000 UDP in my firewall.
At first I set everything up with the auth-key that sip station gives you to automaticall have the FreePBX madule configure the trunks and all but it was not connecting every third or so incoming call. So I though that maybe the auto configure messed up so I deleted the key from the system and set up the trunks and incoming routes manually. It does the same thing…“number not in service”. When I had it set up through the Sipstation module I ran a firewall test in that module and everything passed.
It does this with both my DID’s. I dont have anything complicated set up with the inbound routes, the DID’s both go to a separate IVR’s.
What more information can I give you all to help me troubleshoot this?
If it helps any I have a Sonicwall TZ180 Firewall. The FreePBX box is set to IP 192.168.99.3
Sonicwall firewalls are notorious for being ‘problematic’ though most often it is related to their content filter and thus blocking Module Admin (and sometimes the sipstation module).
If you are getting the “Not In Service” message when calling into your DID then it tells you a couple things. First, you are registered and their server sees you. If you were not registered, it would immediately send you a busy signal back and you would not get that message. (BTW - The SIPSTATION module shows you that same information, your registration status as seen by the gateways). The other thing that message tells you is that they have tried to send you the call to your registered address and the call failed so they eventually timed out and it results in that message.
That is not something you are likely going to get too much help here on (despite peoples best intent). You could try tracing your network with wireshark and see what you are getting as it may provide a hint as to what is going on. What you probably need to do is contact their support at the email they provide (see your portal account) and they will have to have someone do a trace and let you know if anything is coming back from your server when that issue happens.
One long shot though. Are you running Asterisk 1.6 (don’t recall which version). If so, there was a short lived bug that resulted in all calls being refused (which is why I say it is a long shot since some of yours succeed). The forum thread on it is:
and the setting to fix it in your SIP trunk configuration is:
session-timers=refuse
though you should really upgrade Asterisk to address the issue. Otherwise, check with the SIPSTATION guys and they should be able to tell you what they are seeing coming back from you (or what they are not seeing) that is resulting in it timing out.
Hi Philippe, thank you very much for your responce. I have none of those services activated on the sonicwall. However what I tried after doing some readong and some thinking is, on the Sonicwall I set it to use “Enable consistent NAT” under the SIP setttings. So far so good and I havent had the “not in service” message. So as of now it seems to be fixed, I will wait a few days and monitor.
Does this make sense that “Enable consistent NAT” would cause/fix this issue?
very possibly. The way the service, and ‘any’ service works that tries to get around your NAT, is that you register as well as send ‘pings’ (OPTION messages via the qualify=yes setting). This keeps your firewall open on what ever port you are NATed through and that is what the SIP Server sees. When an incoming call comes in for you, the Server sends it to this NAT address vs. 5060 (by default) since most firewalls will keep that pin hole open. This results in the service working for most people regardless of whether they have setup port forwarding to 5060 which many forget.
I have seen some firewalls do different things which can break this. In some cases they are ‘smart’ about the SIP messaging, so they see the ‘pings’ or the registration packets and when the return packets come back they close the pin holes again, thus blocking inbound calls. When that happens, you usually get no calls in. In your case, it’s very possible that you send a registration which opens up a NAT port. Then some time later you send an OPTIONS message, and since it decided not to be consistent it decides to change the port, closing the pin hole that was opened with the registration and thus blocking inbound calls again since the registration port is what is remembered. (You could have tried turning off qualify=yes to see if that affected this).
The service does have the option to force your new call INVITES to always go to 5060 but it needs to be manually configured and is usually only used when problematic firewalls will not honor the NAT port that was last seen.