Incoming Calls Began Dropping After 32 Seconds, In The Last Week

[Jim.Lloyd]

On 11/08/2021, my PBX started the "32 second call drop" thing. Rebooting the PBX seems to resolve the issue for a few days. I rebooted on 11/08, 11/12, and today (11/15).

Things have been doing fine for about 5 months. I am running "18.0 Update 1 (Build 237)" as of 10/18/2021, on a RPi4B-8GB. I went through the firewall settings, yesterday, and redid the inbound rules & forwards, just to make sure there were no typos. The 3CX Firewall test comes up clean. Haven't yet checked to see if the wireless adapter has some how come out of disable.

I am down to that I am running a dynamic IP, since I am running from home. The IP has only changed for me when I change routers, or am offline for more than a few days. But, I am wondering if I need to ask my ISP for something, like no port redirects or something like that.

Any ideas would be most appreciated.

 

[leejor]

Calls dropping at about 32 seconds is usually a "no ACK" issue, which means SIP messaging is not getting through as it should.. Have a look at the Activity Log, there may be something helpful in there.

 

[Jim.Lloyd]

Leejor, I will... I need to wait until the issue reoccurs. The logs are purged when restarting, so I lost everything prior to the restart. Will I see ACK issues in 3 days, and what will that mean...?

 

[leejor]

But, I am wondering if I need to ask my ISP for something, like no port redirects or something like that.

Hmm... this question has me wondering what sort of service you actually have. Could it be that you are sitting behind another router, and your provider issues a private IP to you?

If it is only incoming calls that are dropping then I suspect that you do not get an ACK from your provider, but a look at the logs should confirm this.

 

[YiannisH_3CX]

Leejor, I will... I need to wait until the issue reoccurs. The logs are purged when restarting, so I lost everything prior to the restart. Will I see ACK issues in 3 days, and what will that mean...?

It will mean that the session is not completed successfully so the call drops. In a typical inbound call you will see an Invite coming from the provider, then the PBX will reply with a 200 OK accepting the call and then the PBX will wait for an ACK message to complete the session.
If the ACK is not received you will see the PBX sending multiple 200 OK messages in an attempt to receive a reply. If a reply is not received within 32 seconds the call drops.

You could also run a packet capture to check the above and it might help to run a packet capture on your router/modem if possible to confirm.

If I were to guess, you are having some sort of network issues and the STUN replies report a wrong IP so your provider is sending the ACK to the wrong IP. You could also contact your provider and they can tell you what they are seeing.

Also you could set your IP to static and test like that for a few days

 

[Jim.Lloyd]

YiannisH_3CX & leejor... Thank you for the replies. I am still waiting for the issue to return, and I will do the packet captures BEFORE I reboot the system >) A lot has changed since I last certified on 15.5, as well as from 16 to 18.
-
For the system setup...
- Broadvoice SIP
- Spectrum on a dynamic IP {doesn't change if the FW/Router MAC doesn't}
- Cisco RV160W router {has its own 'quirks' running FW Rules (**)
- 3CX on RPi4B-8GB {Upgraded from v16 to v18 in September}
. The whole thing runs fine for a while, then develops the 32 second issue until I reboot. That just started a few weeks ago, so this issue is throwing me. The router has been in place since June, and v18 has been running for almost 2 months. I keep everything updated as updates come out.

(**) - The RV160W FW Rules have a 'quirk':
. A 'Deny' rule takes precedent over any 'Allow' rule, no matter where I put it in the list. Unlike the RV320 I recently replaced, it doesn't read "Top-Down".
. The more common rule set of allowing ports for your specific IPs followed by a "deny all IPs" after results in no IPs able to contact the destination... 3CX over Ports 5060, in this case. I resorted to creating other forward rules to a dead IP address after the needed rules for my SIP provider, and that worked for me. I don't like doing that, for several reasons. I am more prone to a router denial of service disruption, no to mention the possibility the router may leak resources and start acting weird... kind of like what I am currently seeing.