Single extension drops calls

[MCNY]

• 3CX Version: Enterprise 18.0 (Build 935)
• Server OS: Linux (debian 10.13)
• Is the 3CX Server Hosted and where? Azure
• IP Phone Make/Model/Firmware version: N/A
• Trunk Provider: Twilio
• Has the Firewall Checker passed: YES
• Are custom Phone Templates being used: NO

I have a single user that has experienced drop calls from the iOS app and from the WebClient. Not all calls are dropped. Both internal and external calls to different external and internal recipients. Log led me to believe that the user was initiating the hang up. Initially only iOS app was being used, so I thought the user was accidentally hitting the hang-up. Turns out they always lay the phone flat on the desk and use speaker phone. Hands no where near the device when the call drops.

Seems to have happened while the user is in the office on our network (wifi) and while they are remote at their home (their wifi). Laptop used is managed by us and the WebClient via Chrome also dropped the calls. Usually the call is 2-13 minutes in process before the drop occurs. No pattern that I see on length. Not all calls. Logs via Twilio don't appear to show any issues on their end and an internal call was also dropped as I have been working with the user.

I have deleted the iOS app on the users cell phone and reinstalled/provisioned. Any additional troubleshooting steps recommended?

 

[TheodorosG_3CX]

Just to clarify, if for example you remove the iOS client and only use the webclient, the issue is the same?
In the webclient, is there any headset integration?

 

[MCNY]

Thank you for the reply. I did not remove the iOS client from her phone, but asked her to use the webclient to make her next group of calls. That is when I received feedback about a dropped internal call and another dropped external call. No headset setup for the webclient or iOS. Great question.
I was hoping that there was something other than the log viewer logs (set to medium) that I could review for the clients (iOS or webclient). Is there something that tells me what is going on from the client application perspective? Verbose would be a problem from the warning since I can't make the error happen on command and would need to leave it on Verbose for many hours to capture the issue.

 

[TheodorosG_3CX]

I'm afraid that without verbose the information is restricted and will not help.

 

[MCNY]

Thank you for the recommendation to go ahead with Verbose logging. That sounds like the next step.
Are you confirming that client logging doesn't exist? (logs generated by the client applications as opposed to the server)

 

[TheodorosG_3CX]

Most probably not at the moment. In this case you will need to wait until it is replicated again