Trunks stop working every few days (incoming only)

[Del]

Hello,

I seem to be having trouble with a SAIL PBX (V5) with trunks and incoming calls.
All works perfectly then randomly every few days all calls go to the SIP providers voicemail, outgoing calls still work fine.
3 different test trunk provider behave the same.
Trunks all show as registered from the SAIL web interface (though one time they did show registered to 127.0.0.1) - If I issue a commit from the web gui incoming calls immediately start to work again.
I originally thought it might be linked to when the external IP from the ISP changes? I'm pretty sure it had changed each time they stop.
Can I get Debian/SAIL to check this and issue a commit if that is the cause?

Anything I can try to troubleshoot?

Heres some of the asterisk log when incoming call were down

Code Select Expand

[2017-10-26 17:59:44] ERROR[1501] chan_sip.c: Peer '4189702' is trying to register, but not configured as host=dynamic
[2017-10-26 17:59:44] NOTICE[1501] chan_sip.c: Registration from '<sip:4189702@sip.voipcheap.co.uk>' failed for '127.0.0.1:5060' - Peer is not supposed to register
[2017-10-26 17:59:44] SECURITY[1378] res_security_log.c: SecurityEvent="FailedACL",EventTV="1509037184-954445",Severity="Error",Service="SIP",EventVersion="1",AccountID="4189702",SessionID="0x7f278c0ff828",LocalAddress="IPV4/UDP/127.0.0.1/5060",RemoteAddress="IPV4/UDP/127.0.0.1/5060",ACLName="peer_not_dynamic"
[2017-10-26 17:59:44] ERROR[1501] chan_sip.c: Peer '2127491' is trying to register, but not configured as host=dynamic
[2017-10-26 17:59:44] NOTICE[1501] chan_sip.c: Registration from '<sip:2127491@sipgate.co.uk>' failed for '127.0.0.1:5060' - Peer is not supposed to register
[2017-10-26 17:59:44] ERROR[1501] chan_sip.c: Peer '4189702' is trying to register, but not configured as host=dynamic
[2017-10-26 17:59:44] NOTICE[1501] chan_sip.c: Registration from '<sip:4189702@sip.voipcheap.co.uk>' failed for '127.0.0.1:5060' - Peer is not supposed to register
[2017-10-26 17:59:44] SECURITY[1378] res_security_log.c: SecurityEvent="FailedACL",EventTV="1509037184-962073",Severity="Error",Service="SIP",EventVersion="1",AccountID="4189702",SessionID="0x7f278c0ff828",LocalAddress="IPV4/UDP/127.0.0.1/5060",RemoteAddress="IPV4/UDP/127.0.0.1/5060",ACLName="peer_not_dynamic"
[2017-10-26 17:59:44] ERROR[1501] chan_sip.c: Peer '4189702' is trying to register, but not configured as host=dynamic
[2017-10-26 17:59:44] NOTICE[1501] chan_sip.c: Registration from '<sip:4189702@sip.voipcheap.co.uk>' failed for '127.0.0.1:5060' - Peer is not supposed to register
[2017-10-26 17:59:44] WARNING[1501] chan_sip.c: Forbidden - wrong password on authentication for REGISTER for '4189702' to 'sip.voipcheap.co.uk'
[2017-10-26 17:59:44] WARNING[1501] chan_sip.c: Forbidden - wrong password on authentication for REGISTER for '2127491' to 'sipgate.co.uk'
[2017-10-26 17:59:44] NOTICE[1501] chan_sip.c: Peer '404' is now Reachable. (13ms / 2000ms)
[2017-10-26 17:59:44] NOTICE[1501] chan_sip.c: Peer '402' is now Reachable. (19ms / 2000ms)
[2017-10-26 17:59:45] NOTICE[1501] chan_sip.c: Peer '401' is now Reachable. (61ms / 2000ms)
[2017-10-26 17:59:54] NOTICE[1501] chan_sip.c: Peer '2127491' is now Reachable. (1ms / 2000ms)
[2017-10-26 17:59:56] NOTICE[1501] chan_sip.c:    -- Registration for '30201321@46.31.231.185' timed out, trying again (Attempt #3)
[2017-10-26 18:00:16] NOTICE[1501] chan_sip.c:    -- Registration for '30201321@46.31.231.185' timed out, trying again (Attempt #4)
[2017-10-26 18:00:36] NOTICE[1501] chan_sip.c:    -- Registration for '30201321@46.31.231.185' timed out, trying again (Attempt #5)

Any suggestion appreciated 

[sysadmin]

Sorry for the delay in replying to this.   I was pretty sure that this issue had been reported through ProVu support and we were awaiting login creds from the customer.  In any event, the error messages in the log suggest you have your registration direction confused in the trunk.  You can post the SIP peer and register entries if you'd like us to look at it.



 

[Del]

Sorry for the delay in replying to this.   I was pretty sure that this issue had been reported through ProVu support and we were awaiting login creds from the customer.  In any event, the error messages in the log suggest you have your registration direction confused in the trunk.  You can post the SIP peer and register entries if you'd like us to look at it.

The registration string looked like this for both trunks:

Code Select Expand

username:secret@host/username
username:secret@host/username

It seemed that the problem wasn't when the external IP changed, we found out that power had been dropping out knocking off the router and PBX, it seemed like the PBX booted and was ready to go before the router had connected to the internet and without a commit it wouldn't receive incoming calls.
A battery backup has been installed now and haven't had the issue since.

[Del]

Seems to have started doing the same thing again.
New log attached. If anything else is needed let me know. Thanks.

[sysadmin]

From your log, you look to have lost internet comms just after midnight until around 03:50 followed by a shorter drop of a minute or two.  Two of your trunks successfully re-registered after the second drop, the third didn't and only came back with an Asterisk reload. It was attempting to register but wasn't seeing any packets returned.  These kinds of problems are quite common with some routers.  Basically, after a comms drop, the router messes up the port forwarding and the natting breaks.   BT routers, for example, are known to have some issues with port forwarding.

There's nothing wrong with Asterisk, it just isn't getting packets back.   If you google the problem you'll find quite a lot of references to this same issue.  Here are some of the things others have done to fix the issue.

As a "sticking plaster" fix, you can use cron to schedule a daily Asterisk reload just before prime shift using asterisk -rx 'core reload'
You can try moving the Asterisk box into the DMZ to see if the router handles it better there
You can replace the router with one that works properly

[Del]

Thanks! I'll recommend a new router.