Calls last more than 20 minutes are dropped

[apitsos]

Hi!

I am having a client who complains about the dropping of a line if a call lasts for more than 20 minutes or something. I investigated a little bit the problem and I ended up on this (https://www.3cx.com/community/threads/calls-drop-after-15-minutes.51261/) thread from 2017. But this thread ends as solved after upgrading the firmware on the Yealink devices, which seems not to be the problem in our case, as the Yealink T58A IP phones that the client has are with the latest firmware supported by 3CX. We also are running the latest 3CX version (V.16).

My mind went to the SIP ALG setting of the firewall, but this is also disabled! The client has a SOPHOS SG135 firewall.

Any ideas would be helpful.

 

[leejor]

Does the 3CX Activity Log show that it is the set, that is dropping the call? Is it multiple sets? Is it all sets of one type (make/model)? Did this just start, at some point?

 

[apitsos]

Hi @leejor,

Thanks for your reply. I am sorry, but I am not aware of how to find this information in Activity Log. What exactly should I search for in Activity Log?

Thanks a lot in advance for your time, providing answers.

 

[leejor]

This is 8 years old, but the format of the logs has not changed. You can specify which extension logs to display to narrow things down.

https://www.3cx.com/blog/docs/server-activity-log-example-1/

If you find a log , of the call ending (dropping), you can post that, if you aren't sure what it's telling you.

 

[apitsos]

Hmm... I can't find anything in the logs with the term "dropping". I suppose I need to do what the post says. I need to put the user to make a call and when it drops to tell me in order to check the logs at that moment.

Is it true that the Activity Logs are only the very recent ones?

 

[leejor]

One end, or the other will probably show a "BYE" message. Depending on your settings/system, you can usually go back several pages of logs. When first opened, it will show the most recent.

 

[apitsos]

I am still having these problems with my client, but I can't understand the reason of these line drops. Unfortunately I didn't have the opportunity to check the Activity Logs on time. When I am informed or being able to connect to their PBX, the logs are already gone.

They mentioned recently that the same moment that a call was dropped, which was running for 18 minutes and 44 seconds another colleague was able to complete his phone call, 19 minutes and 29 seconds long!

It really doesn't make any sense to me, because if there was a problem causing such a behavior, shouldn't be the same on all cases? And what about when a call of 18 minutes drops, but the exact same moment another call, longer than that, is running up to the end without issues?

There is something else that I'd like to share with you. The client has Yealink T58A IP phones and it happened 2 or 3 times the devices not to ring. It looked like the device was stuck or something, because after a power cycle they were running normally again!

I have a feeling that something else is happening here. Either the "Android" devices are sticking, because they are running with an Android OS, or the PBX itself, which is a miniPC (Intel NUC) with poor resources (Celeron J4005 @ 2.70 GHz, 4 GB RAM, 240GB SSD), is sticking or creating issues. At least that is my opinion. But of course, I also need to say, whenever I login and see the 3CX dashboard of the PBX, neither the CPU or the Memory usage are high. So that is REALLY confuses me.

I would really appreciate any input here.

 

[Alphabetic]

Hi can you please fill this out

• 3CX Version, e.g. Standard Annual 16.0.2.910
• Server OS, e.g. Debian 9 / Windows Server 2012 R2 / Raspberry Pi
• Is the 3CX Server Hosted and where?
• IP Phone Make/Model/Firmware
• Provisioning Method: Local / VPN / STUN / SBC
• Trunk Provider or Gateway Make/Model
• Has the Firewall Checker passed: YES / NO
• Are custom Phone Templates being used: YES / NO

 

[JohnS_3CX]

You should really see who ends the call from a SIP perspective.

If only trunk calls are affected (internal extension calls are ok) then you would want to run a capture and replicate it to see whether the provider sends a BYE for example.

 

[apitsos]

• 3CX Version: Enterprise Annual 16.0.5.619
• Server OS: Debian 9 / The one that comes with the ready Debian-3CX iso file
• Is the 3CX Server Hosted and where? No, it's on premises, as already mentioned
• IP Phone Make/Model/Firmware: Yealink / T58A / 58.85.0.5
• Provisioning Method: Local / VPN / STUN / SBC: Local
• Trunk Provider or Gateway Make/Model: BITel
• Has the Firewall Checker passed: YES
• Are custom Phone Templates being used: NO

Hi @kieferschild!

Thanks a lot for your interest and your willing to help. Please find above the answers on your questions.

 

[apitsos]

You should really see who ends the call from a SIP perspective.

If only trunk calls are affected (internal extension calls are ok) then you would want to run a capture and replicate it to see whether the provider sends a BYE for example.

Hi @JohnS_3CX!

Thanks for the answer. May I kindly ask you how can I check it? Is it through the "Activity Logs" only? Because when I react is too late and I can't find anything there.

 

[JohnS_3CX]

You can find the Capture button in the Activity Log page which creates a pcap file while the call is running. When the call drops, end the capture and download it.

It can now be analyzed in Wireshark see who ended the call.

 

[apitsos]

That's not possible to be done. I have to be in communication with the client the whole day (or days) until that happens again! Isn't there any other way to get logs, as this is not happening every day or on every call...?

 

[Alphabetic]

I've just checked - i believe this is not a supported provider, am i right?

have you got re-invites enabled on the sip trunk?

If you like, i can share with you how to set up captures?

 

[JohnS_3CX]

You can enable Verbose logging from the same page, and let it run continuously until it happens (will make the files larger and is more intensive on the system but should be ok).

When you catch a case, you can log in and download the Support Info file (top right of dashboard).

Those logs can be analyzed more carefully and if needed you can also use the 3CX Bin Log viewer where you can isolate a specific call and see exactly what happened in a very detailed manner.
https://www.3cx.com/docs/3cx-log-viewer/

It's a bit more time consuming but it should reveal some useful information once you know what call to isolate.

 

[apitsos]

have you got re-invites enabled on the sip trunk?

Hi @kieferschild!

If you mean the option "Supports Re-Invite", which is under the SIP Trunk > "Options" tab > Advanced, yes, I have enabled that.

 

[apitsos]

You can enable Verbose logging from the same page, and let it run continuously until it happens (will make the files larger and is more intensive on the system but should be ok).

When you catch a case, you can log in and download the Support Info file (top right of dashboard).

Those logs can be analyzed more carefully and if needed you can also use the 3CX Bin Log viewer where you can isolate a specific call and see exactly what happened in a very detailed manner.
https://www.3cx.com/docs/3cx-log-viewer/

It's a bit more time consuming but it should reveal some useful information once you know what call to isolate.

That sounds nice. I will give a try. Thanks a lot @JohnS_3CX!

 

[JohnS_3CX]

Sure thing. You might wanna disable re-invites on the trunk, often they don't play nice.

 

[Alphabetic]

Ok so as said above you need to find who's sending the BYE.

Since the problem cannot be replicated easily you're going to need to set up a capture.

Ensure you have a successful backup - Do this out of hours.

Tools you're going to need are PuTTY and WinSCP (browse files on linux)

Using PuTTY you will need to log in to your PBX with your linux root details.

Run the following commands:

sudo su
apt-get update
apt-get install tshark
mkdir /home/wireshark

Reboot the PBX

Now we'll start our captures, this will make 20 files 10MB in size which will overwrite.

tshark -i any -b filesize:10240 -b files:20 -w /home/wireshark/mine.pcap

This PuTTY session will need to stay open and running - this can be run during production.

When customer calls to say its happened you can cancel the trace and then use WinSCP to browse the folder /home/wireshark and download them to your desktop.

When using WinSCP you need to press Advanced and changed the following to Sudo Su

 

[AWS2P]

If you mean the option "Supports Re-Invite", which is under the SIP Trunk > "Options" tab > Advanced, yes, I have enabled that.

Try to disable this, already got dropped calls due to this enabled.