No Incoming Calls At Night

stcs49 · March 8, 2014, 12:43pm

Hi,

This is the first time I have posted on the forum and also new to using / setting up Asterisk. I have been working on a project for almost 3 months and have learnt a lot, most of time the hard way.

Our setup is as follows:-

HP Proliant ML350P Gen8 Server ( 3Ghz Xeon Quad, 8GB Ram, 1TB Raid 1 )
Cyberoam NG25iNG Hardware Firewall
CentOS 6.5
Asterisk 11.7.0
FreePBX 2.11.0.24
Above installed using the Schmooze.com 64bit Distro directly from the download link on the Schmooze.com website.

12 Extensions - ( 2 in use at the minute for testing )
4 Call Queues
1 IVR - ( 4 options, 1 for each queue ) - failover back to IVR

g729a Codec installed with correct amount Digium Commercial Licenses installed ( 6 in total as we are call recording )
g729 codec is shown in the Show Translation output

We have fibre broadband which connects from the fibre modem into the Cyberoam, this authenticates the PPPoE connection to the ISP and gets the ISP static assigned IP address, the PBX is on the internal LAN port, not in a DMZ, we have a static IP 81.xxx.xxx.xxx on the WAN port of Cyberoam and a 192.xxx.xxx.xxx on the LAN port of Cyberoam. We have no port forwarding setup to expose the PBX to the internet. 2 laptops connecting wirelessly to the internal network and using Zoiper Biz softphones for the calls, FOP2 is also installed and working correctly.

Our calls are being routed via an IP Trunk from an overseas 3rd party provider, this is configured in the trunk peer details as follows:-

type=friend
nat=yes
HOST=ip address of provider
disallow=all
context=from-trunk
canreinvite=no
allow=g729
dtmfmode=rfc2833
dtmfrelax=yes

We are only interested in receiving incoming calls so we have no configured outgoing call route, this is intentional. We are able to receive incoming calls during the day, our issue is that every night we have no incoming calls at all.

Our overseas callers are not able to make calls to our PBX during the night, we have not set any night service or time controls within FreePBX or Asterisk that we are aware of, it was a stock install
from the distro and configured as above. We don’t make any changes on our PBX but the following day the calls are able to connect.

This seems very strange as we don’t change any config our end, our overseas provider also state they don’t make any changes their end, but the calls just start to connect the following morning???

At the time we cannot receive incoming calls from the trunk we can make calls internally, always have been able to, we have re-booted the server when this happens to see it that resolves the issue, but when the server is back online, still no incoming calls.

We have run packet captures when test calls are being made but it shows nothing, not a trace of a call attempting to connect, we thought it could be some sort of time control somewhere but it doesn’t happen at the same time every night, yesterday they stopped after 17:30, the day before it was after 20:30 when calls stopped?

Has anyone had anything like this happen before?
We have checked the log files for clues but cannot see anything obvious, the PBX GUI is showing the trunk online, sip show peers, sip show registry all show the trunk as online even when we get no calls.

Does anyone know of any tools that we could use to try and get to the bottom of this, the PBX will be hosting a 24/7 service when it goes live, but at the moment that won’t be happening unless we can resolve the loss of call during the night.

Any advice help would be appreciated, as I said at the start, I’m new to this and could of easily missed something obvious.

david55 · March 8, 2014, 2:00pm

The problem lies outside Asterisk and possibly even outside your local network. Does your ISP may gratuitous changes to your IP address?

Incidentally, you have some options that I believe no longer work with Asterisk 11 (but default to how you have set them) and some that have an option value that is, at best deprecated. Could I suggest you read the documentation and/or look for errors when parsing the configuration files. Also you have nat= but you have no options that would enable NAT. None of these are time of day related.

If you had been receiving the request packets, you would have been redirected to freepbx.org, as all dialplan issues need to be dealt with by the author of the third party dialplan.

dejanst · March 11, 2014, 5:40pm

This is very eazy. Do a packet capture or check out Asterisk CLI and make incomming call during the night. If you don’t see any SIP Invite messages in the packet capture or don’t see any output on Asterisk CLI, the VoIP provider is not sending you the calls during that time. It’s as simple as that.

stcs49 · March 12, 2014, 11:35am

Hi,

Thank you both for your replies.

I was already going down that route as it seemed the most likely cause, you have just strengthened my belief in this, since my original post this is what we have done to try and resolve the issue:-

Ran packet captures when calls from overseas were made. Using wireshark and viewing the SIP call output it revealed no attempt of a connection from the provider relating to any INVITE for a call to be placed.
We have used a UK Voip provider for testing our config, we have added a second trunk using the details to reflect the new connection and pointed the incoming route to our existing IVR. With our server on the UK provider we have received every test call placed without issue, even during the night. Probably not the best way of troubleshooting but it proved our basic config was not the issue as suggested by our overseas provider.

Being satisfied that the main config, IVR, call queues etc all function as expected we have reverted the setup back to the single overseas provider, again we get no calls until we contact them, once again the calls come in and stop during the night. We have a suspicion of what may be happening but this is not the place to comment.

We have presented our test results to the overseas provider who have stated it will take them 2 weeks to run some debugging, they still insist the fault is our end!!

Why it would take 2 weeks to debug this?? who knows, we are in negotiations to move to a new overseas provider.

Once again, thank you for taking the time to reply, much appreciated.