Internal extension to extension call time limit to catch ghost channels

We have a client with a PBX hosted offsite. The internet at their office has been poor lately, going down due to weather. This recently caused some inter-extension calls at the office to get stuck “in-use”. The phones re-registered properly after internet came back, and would otherwise work fine but the BLF’s were showing the phones that were on the call as in-use, because per Asterisk the calls were still in progress (and going on for 36 hours by the time they reported this to me, per the show channels report). I had to use asterisk cli to kill the calls to restore things to normal for those phones.

I read using the limit option on the dial command, but I really only want to put a limit of a couple hours on internal extension-to-extension calls.

Other post with similar issue, but they wanted to limit ALL calls.

Limit info:

https://wiki.asterisk.org/wiki/display/AST/Asterisk+11+Application_Dial

Thoughts? Any other way to catch/stop these kinds of scenarios short of a time limit? I’d think there would be some kind of keep-alive within SIP needed to keep the call up?

FPBX 14.0.5.25
Asterisk 13.19.1
Endpoints are PJSIP and Sangoma S705

I’m not familiar with the Sangoma phones, but try setting Session Timers for an extension to Always, which should cause Asterisk to send a re-invite every 30 minutes during a call.

Confirm that this doesn’t break anything (calls lasting more than 30 minutes don’t get dropped) and that it works as intended (pulling the phone’s network cable during a call causes the channel to clear at the end of 30 minutes).

If successful, it should be safe to implement system wide.

If the test fails, use pjsip logger to see whether re-invites are being sent and whether a proper response is received.

I will try that when I go onsite tomorrow.

On another post of similar issue, I saw Skyking recommend rtptimeout in sip settings. The default (and what it’s set to now) is 30, rtpholdtimeout is 300 and rtpkeepalive is 0. That sounds perfect for solving this (no RTP = Bye Bye!), however since it’s already configured, I wonder why that didn’t cause the call to drop since those are on already?

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