Under Review Sporadic Problem with Windows V18 Client (Pickup from Call-Queues / Transfer / New-Call)

[23lcs42]

Hello Community,

Since Version 18, there's a Problem with the Windows V18-Clients at a small private Customer. They're all using the native Windows Clients on their Windows 10 Machines. Most of the time, everything went well with Call-Handling and so on. During the day, some of them run in the following Problem;

Call coming in to Call-Queue, and is signaling on every client, as it should be. So one of the active Users tries to accept the Call from the Queue, as showing in the Video. It's not possible to click the green Accept-Button for the affected User, only the red Decline-Button works.. After that, it's also not possible to initiate a new outgoing Call (second Video). The User has to Force-Quit the 3CX-Client through Task-Manager, the normal Application-Shutdown didn't lead to any change of the described behavior.

Has anyone experienced this Issue?

The Customer is running the Debian-Server Version on a local VM (18.0 (Build 314)), only 12 local Extensions. Plenty of CPU / RAM and Storage available for the Machine.

https://www.dropbox.com/s/6ig27ktcyacmzoi/Video 19.01.22, 11 14 15.mp4?dl=0

https://www.dropbox.com/s/q4cqw3wbe7eineb/Video 19.01.22, 11 16 40.mp4?dl=0

Best regards,

André

 

[NickD_3CX]

Hi André,

Could you check what version of the Desktop app this is happening on? You can check this by r0ght-clicking on the icon in the Notification Area, then selecting "About".

Also you say you have 12 users, does that happen to all, or just 1 user and always the same user?
Does it happen vert often?

Last question, is there any security software installed on the users computer (e.g. AV software) and are all windows updates installed?

 

[23lcs42]

Hello Nick,

thank you for your reply! The Desktop-App Version is 18.7.10.

It happens to all but one Client, but we haven't found any difference between their Systems. (Same Hardware / Software etc.). For all affected Clients, it happens on a daily basis, between 3 - 5 times during the day.

The Windows 10 Installation is always up-to-date, and there's only Microsoft Defender active, no third-party security software.

 

[NickD_3CX]

In order to track this down, we would need to enable some extensive logging on both the server side and the client side.

Before we do this though, one more question, do these users happen to also have a IP Phone configured to the same extension?

 

[23lcs42]

Hallo Nick,

no, the Users are exclusively working with the Windows-Clients, no IP-Phones involved.

 

[NickD_3CX]

OK, I'll send you a PM shortly.

 

[uhs-roycruse]

Hi Nick, as per my other thread we are experiencing this issue as well.

I have now seen it for myself and have a verbose log for an example of this happening.

The situation in this logged call was 2 remote clients using the desktop app from home - one tried to call the other and the receiver could not answer the call. The client was ringing and when pressing the green button the button would dim as you click indicating being pressed but the call does not answer.

I'll PM you the log file

 

[NickD_3CX]

Hi Nick, as per my other thread we are experiencing this issue as well.

I have now seen it for myself and have a verbose log for an example of this happening.

The situation in this logged call was 2 remote clients using the desktop app from home - one tried to call the other and the receiver could not answer the call. The client was ringing and when pressing the green button the button would dim as you click indicating being pressed but the call does not answer.

I'll PM you the log file

Hi!

For the time being we have the logs required for our Dev Team to investigate. Once we have an update I will try and inform this thread.

 

[uhs-roycruse]

Hi Nick,

Ok let me know if my log files are useful or if there's any other testing you would like me to do - this issue is super urgent from our point of view - its causing user rejection of the phone system. Half our staff work from home using the desktop app only - the other half are here in the office either with desktop app only or with desktop app + a fanvil phone - we do not see the issue at all locally in the office either with the software only users or the ones with phones.

This issue also seems to happen if the client has been idle for some time - if i test again immediately after the failure it works over and over again even if i try 20+ times. but leaving the client alone for 30 minutes or more (i havnt tested for a minimum time as yet) its then easily replicated.

Its worrying this issue was reported in january and is still not fixed as if we have this issue for that kind of time im going to get hung drawn and quartered for recommending and implementing 3cx...

I believe this is happening 10s of times a day on our system amongst our remote users...

 

[Evolute IT]

Hi Nick,

Ok let me know if my log files are useful or if there's any other testing you would like me to do - this issue is super urgent from our point of view - its causing user rejection of the phone system. Half our staff work from home using the desktop app only - the other half are here in the office either with desktop app only or with desktop app + a fanvil phone - we do not see the issue at all locally in the office either with the software only users or the ones with phones.

This issue also seems to happen if the client has been idle for some time - if i test again immediately after the failure it works over and over again even if i try 20+ times. but leaving the client alone for 30 minutes or more (i havnt tested for a minimum time as yet) its then easily replicated.

Its worrying this issue was reported in january and is still not fixed as if we have this issue for that kind of time im going to get hung drawn and quartered for recommending and implementing 3cx...

I believe this is happening 10s of times a day on our system amongst our remote users...

This only happens to WFH users? If so, I would check the firewall and the VM config to make sure you're not having dropped packets or things like that causing the app to become unresponsive for remote users.

We use the app only (remote, PBX in AWS) and never experienced this.

 

[uhs-roycruse]

This only happens to WFH users? If so, I would check the firewall and the VM config to make sure you're not having dropped packets or things like that causing the app to become unresponsive for remote users.

We use the app only (remote, PBX in AWS) and never experienced this.

Already run the firewall test in 3cx and trawled through our firewall logs...
Also wouldnt any FW issue blocking the app stop it answering calls ALL the time not just a few times a day per user ?

 

[Evolute IT]

Already run the firewall test in 3cx and trawled through our firewall logs...
Also wouldnt any FW issue blocking the app stop it answering calls ALL the time not just a few times a day per user ?

Depends. For example, we had a weird issue with packet loss on our network and ended up discovering that our DDOS protection on our Fortigate was dropping voice packets because of that protection. Once disabled, never had issues again.

 

[MvK_Invision-ICT]

@NickD_3CX ,
Any update on this post?

It looks like the same issue I have with one of our customers. I am currently troubleshooting with Charalambos with a 3CX support ticket, but so far no luck in a solution.

 

[NickD_3CX]

@NickD_3CX ,
Any update on this post?

It looks like the same issue I have with one of our customers. I am currently troubleshooting with Charalambos with a 3CX support ticket, but so far no luck in a solution.

Hi!

I just checked the case and I don't have any update yet on the matter, it is still under investigation.

As you are working with my colleague Charalambos in support, I highly recommend you continue to do so just to make sure the issue is the same.

 

[Charles_3CX]

@MvK_Invision-ICT, Can you kindly reply back on the ticket that you have with us in regards to this issue, as I don't have any replies currently or any open tickets with regards to this.

 

[uhs-roycruse]

Just an update from our site... this has been reported twice this week from 3cx desktop users in the office so my original theory of only happening to remote clients using external ip is now overridden although the frequency of occurrence is an order of magnitude more for remote clients by my estimation.

 

[hogan71088]

Hi Guys,

I can confirm we're also seeing this behaviour.