Some calls not dropping after caller hangs up

[Tom Cowley]

Hi,

We have a managed 3CX on our MPLS network which previously has worked without any issue. Recently we swapped out the internet connection and router at one of our biggest sites, and ever since then we've encountered problems with our internal calls at that site. It only affects a small percentage of calls, but for some reason the 3CX will see them as still in progress even though the call ended a long time ago. Sometimes the duration will be 2-3 hours when in reality the call only lasted a short amount of time. We find the caller might be unable to make another call if they have a couple stuck or the phone appears engaged when someone calls it. It only appears to affect internal calls Has anyone come across this before and do you have any thoughts on what it might be?

It's been going on for a few weeks now, so I'd be very grateful for any help or advice.

Thanks,

Tom

 

[cobaltit]

I mean I think you already know what it is. It worked without issue until you swapped internet and router. So clearly it's a networking issue (which is usually the case). To rule out other potential causes please elaborate on your setup as outlined here:

https://www.3cx.com/community/threads/information-to-provide-when-requesting-help.67558/

 

[Tom Cowley]

Hi, thanks for getting back to me so quickly.

I'll answer as much as I can:

3CX version: Professional Perpetual 16.0.619
Server: Previously Windows and recently (after the problem started occurring) moved to Linux (unsure which flavour)
Hosted: Yes, by our telco company who also provide our MPLS. Unsure on physical location.
IP Phone: We run a mixture of T19, T46 and W60P
Provisioning Method: Unsure. I don't know where to check.
Trunk Provider: Looks like they're provided by our telco, Spitfire.
Firewall checker: fails, and quite badly too.
Custom templates: Yes, but only to change a few minor things such as logo and stutters etc.

It's worth pointing out that we use the same templates elsewhere with no issue. Also worth noting that while the firewall checkers fails, the problem is only happening at one site - the one with the new router.

The site is fairly complex. We have a fibre ring which breaks out via a core L3 fibre switch to an L2 ethernet switch to which the new MPLS router is connected. The L3 fibre switch also has a few point to point connections.

Previously the L3 switch was set as the client gateway with a static route to the MPLS router, and I changed this when the new router was installed so that the default gateway is the new MPLS router. I've taken the voice VLAN interface off the core switch since the problem started to see if it's a routing issue.

I'm guessing the phone system is sometimes missing the BYE packet, but my provider obviously wants to assume the LAN is at fault, whereas I suspect it's the WAN, so I'm not sure where to go from there....

 

[Tom Cowley]

In fact, since taking a log of all the calls we're dropping I've only seen this happen between internal calls involving at least 1 DECT phone....

I'm not sure if that helps to shed any more light on the situation?

 

[Tom Cowley]

And I've managed to capture a call that got stuck (left) and a call that went fine (right). Seems the DECT call isn't registering the BYE packet.....

Not sure why there were 2 entries per call though, seems the first just went to the SIP IP and the 2nd to the SIP IP port 5060....

 

[Tom Cowley]

No one's got any ideas on this? Has anyone seen it before? Can't imagine why it's only affecting DECT handsets...

 

[YiannisH_3CX]

A call is only dropped when the BYE message is acknowledged (ACK message). Since there is no ACK message received after the BYE then the call stays active.
To see why this happens you will need to run a packet trace on the PBX and on the DECT base it self.
This way you will be able to see what is sent by the PBX and what arrives (if anything) at the DECT station. I think you will find that either the DECT is not receiving the BYE or the ACK message does not make it back to the PBX. Either way something in the middle is preventing it. The packet trace will help you narrow down the issue and locate the culprit.