3CX v12 hangs up calls placed on hold

[ahodge7]

Hello, we've been experiencing some issues with our calls getting a disconnect signal when they are placed on hold (typically when trying to transfer to in office) and I'm not sure where the heart of the issue is. I'm covering my bases and asking if anyone else has experienced this and/or have a fix, or if this is less of an actual 3CX issue. Thanks!

-Adam

 

[leejor]

Is this a new issue, or did the issue just, suddenly start?

You need to be a bit more specific about how the calls are being handled. Is the "hold" being used, a local function (button) on the set? What type of sets are involved, all one make? The call then taken off hold (is the party still there?), then what sort of transfer is done, attended or blind?
The 3CX activity log will show what device ended the call, if it turns out to be the sets, then perhaps the calls are not being handled in the correct manner.

 

[ahodge7]

I apologize for the delay in my response, I was gathering information. I found that the issue wasn't when a call was placed on hold, but when it's being transferred. I believe it's one queue that is being affected, but I'm still gathering the info to confirm/deny that.

What is happening is when a customer is calling in, they'll get the Digital Receptionist, and then select the option that takes them to the queue in question. They've reported that they will hear the hold music, but then the call ends. The same will happen when transferring a call to the queue from in house. This is a recent development, only within the past couple of weeks, which is why I'm lacking in some details. I'm not entirely sure where to get the log information for instances such as this (disconnecting calls), whether I search that queue's activity or check the individual extensions that have advised that a customer told them about being disconnected. Both methods aren't turning up anything wrong, so I figured I'm either looking in the wrong place or I'm just not seeing it.

 

[leejor]

Troubles that are intermittent (especially when you can't duplicate them at will), take a bit of effort, and in many cases, patience, to diagnose. You may have to place inbound calls, until you get a failure, then check the activity log for that call, to see if there is an indication of what ended it. Compare it to a call that didn't drop. Setting the logs to Verbose mode will provide a lot more detail.

 

[ahodge7]

Again, apologies for the delayed response. The issue was somewhat resolved, or at the least we're a step closer. I found an issue with the phone server's LAN connection. We're still experiencing dropped calls, and the most I can gather from the Server Activity Logs is that it is happening on our end. I'm almost certain that it's outside of 3CX at this point (possible need of a new modem, this one's old).

I AM having another issue, however. When I repaired our connection, it reset the computer's IP and threw all of our phones into "Out of Office" mode, which we don't have protocols for since the phones operate strictly on the same network as the phone server. I was able to set the IP back to what it was (easier than changing everything else to a new IP) and most of the phones just had to be set to In Office on the dial pad and they were back to normal, however a couple of them won't retain that setting. This was only confirmed today, so I'm still monitoring when this changes back to Out of Office and if the Server Activity Logs offer any insight, but it wouldn't hurt to ask if there's a setting I might be overlooking.

 

[leejor]

Are you talking about Android App devices, or 3CX Windows phones? The general behaviour seems to be that if the IP of the device doesn't match the subnet of the IP that is set for the server, then it is assumed that it is out of the office. It may not actually work this way, but appears to. Have you tried re-provisioning the devices that are having issues?

 

[ahodge7]

These are 3CX Windows phones. I'm not completely sure how they work, but that sounds like sound logic. Unfortunately, the affected phones share the same IP settings as the unaffected phones but somehow still act like "Out of Office" is the default. Do you know of a setting like that, or is it always default "In Office" unless the IP doesn't match, then use the "Out of Office" settings if available?

I've not yet re-provisioned the affected phones because I'm still troubleshooting an issue with our phone server's connectivity (could very well be the issue, but I just don't see it affecting the same phones, and only those phones and only the one queue that drops calls during a transfer.) I'll still give it a shot, though, and post results.

 

[leejor]

In the "old" days, when manually configuring the 3CX Windows phone, if the device were never to be used outside of the office, then only the internal IP of the 3CX server could be entered. There would be no information on what to do out of the office. With auto configuration, the settings used are for all devices, so even if they never leave the office, they still "know" how to contact the server.

If you haven't done so, then a re-send of the configuration file might be the place to start. Next step would be the removal of the 3CX phone from the computer, re-install a "fresh" download, then re-provision.

 

[ahodge7]

This issue has been resolved. The issue was with corrupted configurations in our phone server's general internet connection. A simple diagnostic run on that connection resulted in refreshing the default gateway IP and enabling DHCP. While this caused us to have to change all of the individual phones' internal IP to match (re-provisioning to all of them), it has since resolved the issues of constantly getting booted into using the external IP, the calls are not dropping, and any other various problems that arose out of this.

In short, 3CX wasn't the issue necessarily. It was primarily our router. Thanks for helping me troubleshoot this, leejor!