Solved Calls going (almost) straight to voicemail

[Michael.Talbot]

One of the 3CX instances that we manage for our clients has just started misbehaving. When a user calls another user the called extension rings twice and then the call goes through to voicemail even though there is a 20 second ring time defined for the extension. External calls get put through to the call queue properly but, once there, the extensions on the queue ring twice before the queue goes on to the next defined behaviour.

The 3CX server is debian installed using the official ISO from 3CX and kept up-to-date (including the latest update) and this strange behaviour has only started happening in the last day or two. The exact same configuration (installed from a backup) on Windows does not have this problem.

Has anyone else seen this problem or have any ideas on how to fix it?

Thanks

Michael

 

[SweetAction]

Turn up log verbosity and replicate the issue. Then we can (maybe) see what's happening in the log.

 

[JohnS_3CX]

You can try to restart your services since the restored backup works fine on another machine.

 

[Michael.Talbot]

Thank you for your suggestions. I have tried restarting the services (and the server) but it has made no difference to the problem.

I also looked at the verbose log and it shows "L:1.1[Extn:114] failed to reach Extn:112, reason No Answer" which would be expected if extension 112 hadn't picked up after 20 seconds (The time set for the extension) but it happens after about 2 seconds.

I also did a packet capture on the call and there are no network issues that would be causing the problem.

 

[leejor]

How much time elapsed, in the log, from the Invite sent to the set, until the "failed to reach" message? When the extension answers is there silence or dialtone? Are the sets involved, local to the server?

 

[Michael.Talbot]

I have taken a very close look at the verbose log and compared it to the packet capture and found a distinct discrepancy.

In the verbose log I see the following:
12/15/2020 8:43:10 AM - Call from "User 1"<sip:114@IP:5060>;tag=xx to <sip:112@IP:5060>;tag=yy
....
12/15/2020 8:43:50 AM - L:1.1[Extn:114] failed to reach Extn:112, reason No Answer
12/15/2020 8:43:50 AM - [Flow] Current call diversion path:[]
12/15/2020 8:43:50 AM - [Flow] Building VoiceMail target of endpoint 112 from "User 1" <sip:114@IP:5060>
12/15/2020 8:43:50 AM - [Flow] Target endpoint for 112 is VMail:999
12/15/2020 8:43:50 AM - L:1.1[Extn:114] forwards call from Extn:112 to VMail:999 based on rule Fwd[Available/NoAnsw]

Which shows a 40 second delay from the call coming in to it being forwarded to voicemail. This would be fine if it was true (it isn't).

The packet capture shows the following:
Initial INVITE at Dec 15, 2020 08:43:10.308906000
Call terminated (SIP BYE) at Dec 15, 2020 08:43:20.586096000

So, from that, you can see the call lasted a fraction over 10 seconds rather than the 40 seconds 3CX shows. I made the test call so can guarantee that it did not last for more than 15 seconds.

The extension I rang is on the desk next to me so I know it rang briefly (which is what I heard on my headset) before the call was put through to voicemail (vm prompt played and then let me leave a message). The server is local (and worked properly on Friday) and there are no special settings for either extension.

 

[JettJ]

Getting the same issue here, had a look at the capture and no network issues. Tried resetting/restarting pretty much everything and still experiencing the same issue.

 

[leejor]

Is 3CX getting a 180 RINGING message, from the called set, after it sends the INVITE? Perhaps, if there is no response from the set, 3CX assumes they are no longer registered and sends the call to VM.

 

[Michael.Talbot]

Yes, there is a 180 RINGING message and the extension is definitely regiestered. I have tested with various internal extensions and with an external call but they all have the same behaviour.

 

[leejor]

The only other time I've seen an issue of a set ringing once, then going to VM is when DND was (unknowingly) active.

 

[Michael.Talbot]

I'm sure that DND is not active when I've run the tests so that won't be it.

 

[JettJ]

I've checked status in 3CX and everything is set to available, had a tech onsite who checked the phones as well, so I can confirm that's not it.

 

[leejor]

Is this limited to only certain sets (extensions), or are all affected? Are the sets local, behind an SBC, using STUN? If only certain extensions, are they the same name/model set? Any recent firmware updates?

 

[JettJ]

All extensions, tried SBC and STUN, no recent firmware updates. T27G and T43U, as well as phone app here.

 

[DamianG]

Seeing heaps of issues accross clients who had the U7 update deployed automatically. Annoying that if we disable automatic updates that we end up with 3CX (the company) contacting customers directly if updates are not applied, but then we get updates that cause the phone system to go down. Also the time to get a response from helpdesk is poor as well.

 

[JohnS_3CX]

Hi Michael,

I would suggest to create a brand new extension (not copied or reused), and leave absolutely everything as defaults.

Then log into that extension via the webclient and see if you can replicate the problem there.

The default settings, and the fact that it is not a deskphone should eliminate the probability that the problem is caused either by misconfiguration, or by the deskphone connectivity.

 

[JettJ]

Well, I just tried that.

No luck, I got 2 rings and then voicemail, dialing from a brand new default account on the app to a brand new default account on the web.

Attached is the redacted log

 

[JohnS_3CX]

Well, I just tried that.

No luck, I got 2 rings and then voicemail, dialing from a brand new default account on the app to a brand new default account on the web.

Attached is the redacted log

Thanks. The log ends at 180 Ringing though, it appears incomplete and we do not see what happens afterwards.

Ensure you have Verbose logging, and once the call is complete you can find the call number and filter for it. Should be the very last call on the list if the PBX is not too busy now

 

[JohnS_3CX]

If the system is running on a virtual machine, I would also suspect (possible) time drift issues.

So is this a VM?
If so, what hypervisor is being used?

 

[Michael.Talbot]

Yes, the 3CX instance is on Hyper-V (Server 2016) but the timestamps are all correct on the system and NTP is configured to keep the time in sync.