Internal calls not disconnecting

[Phil George]

Hi All,
We have a single 3CX PBX at our HQ and other remote sites which are all connected back via MPLS to our main site. We have noticed an infrequent issue where if a call is made between two users at a remote site, when that call ends and both have hung up the call remains 'live'. We then have to manually drop the call via the 3CX client software as they will continue to show as in a call until it is dropped, or the 3 hour timeout.

We have recently replaced all of the network switches at one of the sites with the latest FW installed and this hasn't resolved it. What else could be causing this?

 

[YiannisH_3CX]

Hello @Phil George

You should check the activity log of the PBX and see if there is a BYE messaging coming from the extensions when the call is terminated. You could also use wireshark and check the signalling.

 

[Phil George]

Hi Yiannis,

I can't see any BYE messaging in the activity log, only INVITE. If I do a search for BYE it returns no results?

 

[esben]

Have you had any luck with this? We have the same problem in one of the sites most internal call or forwarded calls remain live making the phones unusable until phone call is terminated on the PBX.

 

[leejor]

What is the set up at the remote location...SBC, VPN...just behind a router? How many sets are there in total?

 

[Phil George]

No luck yet esben.

It is on an MPLS network, so the routers at the remote sites are managed by our ISP and then basically route the internal traffic back to our HQ. We have 4 remote sites that it happens at, some more than others. Plus it doesn't happen all the time, sometimes it does end the call quite normally.

 

[leejor]

I'm not certain, by your description, if the sites are using VPN, or are "seen" as being on the same LAN .

Do you have, or have you tried, setting the extensions to enable PBX Delivers audio?

 

[Phil George]

I'm not 100% sure, one uses VPN the others are on different subnets but ultimately 'seen' as being on the same LAN.

I haven't tried that, let me see if I can find the setting and see if it works.

 

[leejor]

If that works, it is not ideal to leave it that way, it's a work-around, and may indicate that there may be an issue with the routers and how they see the devices sitting behind them. There are a lot of variables involved, and a number of questions about the set up that are unanswered.

that fact the call is not dropping means that t is probably an issue with the "messaging " ports...5060, or which ever has been chosen to use on the sets. I'm not certain if each set requires a unique port, in your particular situation, or if all sets can use the same port. how does 3CX "see" a set when it communicates with it? As a public IP plus port, or, as a private IP (same LAN/subnet) plus port?

 

[Phil George]

Ok, I'll see if I can get some time to track a call through the system and see what is going on. You think it will be port 5060 they are connecting on internally? All of our settings have been left as default.

 

[leejor]

The (communications) port usually used by SIP devices is 5060. It's the most common default, and usually doesn't need to be changed, but, there are situations where it must be, for things to actually work. This is the local port on the device itself, not port 5060 at the 3CX server end. You would have to change the device port if you have more than one device behind a router and were NOT using an SBC, or VPN. In that case, 3CX only has the public IP of the router and the port of the device, so , each must be unique.

I'm not certain as to whether this applies in your case, as i don't know your network set-up. It just seems that the "BYE" messages are not getting through. You may have to troubleshoot using Wireshark, allowing you to narrow down the cause.

 

[Phil George]

Thanks, I'll give it a try and see if I can find the cause.