Calls being dropped after approx 30 minutes


#1

Calls are being dropped after 30 minutes. This happens when the employee is talking. See attached. There are no session timers in our FreePBX configuration that I can find. Our employees often have long calls when dealing with patients as well as insurance providers. We are using sipstation unlimited channels with cyberlink/Sangoma cloud hosting (freepbxhosting.com), Free PBX 14, Digium D70 phones.

The configuration is identical to the configuration at another location (but different SIPStation and FreePBXhosting accounts). The second location does not have this issue. The only difference between the two locations is that at the location referenced here call recordings are set to “Force” on inbound and outbound routes while call recording at the second location not having the call limit issue is set to “Don’t Care.”

Is there a time limit for recording a call? If so, is there a way to modify or override that limit?


(Lorne Gaetz) #2

It’s almost certainly a NAT issue. Since the PBX has a public IP, I would look to the NAT router on site. This can also explain why one site is okay, and the other is not, the NAT router is configured differently. As a first step, you might enable the send OPTIONS param on the actual phone to see if it keeps the session alive while you’re on a call.


(Matt Brooks) #3

Also, make sure you have also read this guide on how to configure FreePBX with NAT.

https://wiki.freepbx.org/display/FPG/NAT+Configuration+FreePBX+12

Side note: Some NATs like to reset the connection after some time, definitely check to see if that is the case.


(Dave Burgess) #4

We’ve had many reports of conversations getting dropped at specific times; 30 minutes and 60 minutes being common ones. If you search back through the discussions, you will find many of these simply by searching for “30 minutes”. Uniformly, these are NAT sessions being dropped by “over aggressive” routers.

If you look through your logs, you will find the sessions being dropped in the /var/log/asterisk/full log. The reason will help you narrow down if the control port (typically 5060) or the RTP port (10000-20000) is the one causing the connection to drop.


#5

It’s not a NAT issue. The virtual server is on a public IP (FreePBXHosting). I emailed sipstation support to look in to it and their response was:

“I found the example calls you provided. On each of these calls I see the BYE coming from your PBX. The BYE is what ends the call. This shows me there is something in the PBX causing these calls to drop. SIPStation has no limitations based on duration of calls that we will drop the call.”

The only difference in the configuration of the freepbxhosting servers is that the one dropping calls has call recordings set to “force.” This weekend I will test with call recording off

In the meantime, any other suggestions would be greatly appreciated.


#6

The routers at both locations are identical and have identical settings. I checked every setting.


(Lorne Gaetz) #7

It is a NAT issue, and the problem is the channel between the phone and the PBX, not the PBX to the trunk. Recording is not related. When the SIP channel is set up between the PBX and the phone, a time limit is set of 30 minutes, seen in the SIP header as Session-Expires: 1800. At about the halfway point there is an attempt to renegotiate the expiry which fails causing the channel then drops at 1800 seconds. With the phone channel down, the PBX then sends BYE to the provider exactly as you’ve confirmed. Assuming you’re not using TLS, all of this is visible via sngrep: Virtuous Signalling


#8

Could it be at the phones themselves and not the router?


#9

I am still unable to determine the issue I’ll dig deeper this weekend. in the meantime if I set the Session Timers to NO in the extensions advanced settings will that prevent the session expiration until I can track down the actual proximate cause? Another alternative would be to set Session-Expires: 3600, but FreePBX 14 does not appear to allow me to edit the sip configuration files outside of the GUI.


#10

Well, after not being able to reproduce the issue, I dug a little deeper and it came down to two toll free numbers (insurance providers) that the calls dropped after 30 minutes. Running a filtered search on CDR reports, but expanding the maximum time to 4,000 seconds I found a number of successful calls longer than 30 minutes, several over an hour. At this point I am inclined to conclude that the issue is on the other end of the calls.

Thanks for all of the input, it was very helpful.


(system) closed #11

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.