Last Update: Channel Stays Open?

I am a long term user of Freepbx. Not one who tinkers with it though. I have had vitelity for a few weeks now but not until I updated last night to the latest framework my channels are being left open and not hanging up.

Anyone else getting this? How can I kick from the command line other than restarting asterisk?

Thank you

You need to figure out why your channels are hanging.

In the interim from the Asterisk CLI ‘soft hangup (tab)’ key brings up the active channels. You can do a ‘show channels’ first to find out what is going on.

Well yes Of course I have to figure out why. That is sort of the reason why I posted. :slight_smile:

Thank you for the last bit though.

I updated my post as the tab key didn’t show.

Without information on your configuration (such as type of phones, if they are on the same network, network config etc.) it is impossible to diagnose.

Setting an rtp timeout in sip_general_custom.conf usually solves these problems.

Here is a link to the syntax

In general you are correct for a new install or if someone was busy tinkering around with the config files. However nothing eas touched except for an update. The entire system has been running for several years now.

I find it interesting another user has posted "Phones remain “in use” when they transfer a call. " similar to when I hand up the phone is still in use. It happens some of the time not all.

I looked in voipinfo and googled a bit on the file. (it shows as empty on my system) Would you be willing to leave me any more breadcrumbs?

Thank you

What kind of breadcrumbs? sip_general_custom.conf contains any variables fro the general section of sip.conf in Asterisk.

You can place the variable I sent you the link to in this file with whatever you want your timeout to be and then do an amportal restart.

That should solve the problem.

This is still an issue I believe.

2 Extensions completed a call. Extensions are not busy and can call out, but both freepbx and asterisk clui show them as busy.

Since they are not actually busy I can reboot ata and router and there is no effect.

FreePBX does not change any of the Asterisk code that takes care of the low level signaling.

Did anything change on your network? Are the phones local or remote? What kind of phones are they?


What type of trunk are these calls coming in on?

Zap type trunks can have this issues and in some very specific situations a sip connection can also.

If you have done the soft hangup command and it is listing connections that it still thinks are active when they are not, the common reason is that the asterisk code still thinks the connection is active when it is not.

The quick fix is using the soft hangup command to drop the ghost calls.

Here is some information I can provide. If you are using a zap type trunk, and it is not configured properly for your location. So that you know the zaptel (or Dahdi) drivers assume US configuration by default so if you are NOT in the US you need to configure it properly for your location. Because different locations have different end of call signaling some are close to the US and work sometimes while others are are not at all similar. So the server can think the port is still in use and thus the call it is connecting to can stay open because of it.

For sip connections the only time we have ever had this happen is with remote extensions. The network between the two locations has a issue and starts dropping packets. The connection between actually fails for a short period of time Say 30 seconds but the remote person does not wait that long so hangs up, and redials the connection. Mean while the phone attempts to send a hangup notice but the network is still goofed up at that point so that packet never makes it (udp is not a protocol that has error checking for post packets so oh, well). Mean while the user then calls again and get’s connected again right after the phone becomes active again. and a second call is now in progress. They hang up when done and everybody thinks things are good. But there is this ghost call which asterisk still thinks is going on because it has not been told otherwise.

Like I said it’s a specific setup and series of occurances to make it happen but we have had it happen about twice a year with a remote employee. The dead give away is using the FOP and noticing that there is still a call going 17 hours later. Or knowing that a conference room is no longer in use but it shows that person still connected to it.

Connected to Asterisk currently running on cpanel3 (pid = 6966)
cpanel3*CLI> show channels
Channel Location State Application(Data)
SIP/401-00da3940 (None) Up Bridged Call(SIP/kieranmulle2-
SIP/kieranmulle2-00b [email protected]:7 Up Dial(SIP/200&SIP/201&SIP/401|2
2 active channels

I to had this problem after doing a

yum update

Scenario: LAN-based SIP phones and asterisk making outbound calls on a SIP trunk. When the SIP phone hung-up, the SIP trunk did NOT hang up. Curiously, CALLBACKs would NOT hang-up either.

At the time, I was running asterisknow beta 2.

I dangled a few ask for assistance (elsewhere) to no success. Having a pretty straightforward setup, I decided to re-install. After successfully replicating the problem AGAIN after updates, I re-re-installed and then re-introduced all the available yum updates but EXCLUDING the asterisk-core repository.

In making the asterisk-core update LAST, the problem did NOT repeat itself. If that asterisk-core wasn’t last, the problem WOULD replicated (I was able to replicate it in a VirtualBOX VM sandbox).

Sorry that I cannot be more fine-grained for you then “re-install” (and as of this writing I do not recall the from-to versions of asterisk involved). Time frame was January-February 2009.

I hope someone can be more fine-grained for you as re-install is drastic; otherwise, asterisk-core updates last [appears] to help.


P.S.: Have since upgraded to asterisknow 1.5 true (non-beta) edition WITHOUT incident.

I can call out, and I can receive calls on the Wildcard TDM410P Board, but the channels will stay open after hanging up the call.
1: Calling from PSTN->410P/asteriskNow->SIP-Softphone
2: calling from SIP-Softphone->410P/asteriskNow->PSTN
Same problem in both scenario, and it makes no difference if I hang up the SIP or the PSTN first.

I’m located in Vietnam, and maybe it has something to do with signaling??
(But then I don’t understand the problem when hanging up the SIP phone)

My installation is a AsteriskNOW - 1.5.0

Let me know what info I need to provide to get help.

Please double check your Wildcard driver and asterisk settings to verify that they are configured for your telcom standard. By default the drivers will assume North American signaling if nothing is specified. you’ll need to set the drivers to support Vietnam so that it can detect and send the proper voltage changes on a hangup.

This week (2009/5/22) asterisk14-1.4.25-1 was released to the asterisk-current updates.

In the update’s change log are a number of “fixes” for channel stays open like problems as well as a couple of corrections to sip-based session [not] closing fixes.

So, at an asterisk level (not a freepbx level), there may be some relief for you in the just released update to 1.4.25-1.

It’s accessible via

yum update


These fixes really only have a bearing on the issue if he was running 1.4.22 or greater. He is not so it will not. Also starting at 1.4.22 asterisk requires the used of Dadhi drivers instead of zaptel. So if he changes to that version he’ll need to change his configuration settings and load new drivers.

Based on the track record of version greater then 1.4.22 (1.4.23.x and 1.4.24.x all have major issues)… it is not recommended until some time has proven that they have really addressed all the issues they created…

Since I don’t know for sure what configuration file actually controls this issue, I have just made my best guess and posted the content for the relevant files… I think.

Is this the correct files?
Where can I find the valid options for the parameters that I need to change?

Thanks for your support :slight_smile:

File: /etc/dahdi/system.conf

Autogenerated by /usr/sbin/dahdi_genconf on Thu May 21 06:31:23 2009 – do not hand edit

Dahdi Configuration File

This file is parsed by the Dahdi Configurator, dahdi_cfg

Span 1: WCTDM/0 “Wildcard TDM410P Board 1” (MASTER)

channel 1, WCTDM/0/0, no module.

channel 2, WCTDM/0/1, no module.


channel 4, WCTDM/0/3, no module.

Global data

loadzone = us
defaultzone = us

I have tried replacing “us” with “vn” -> No Luck

File: /etc/asterisk/ztscan.conf
description=Wildcard TDM410P Board 1
devicetype=Wildcard TDM410P
location=PCI Bus 10 Slot 13

File:/etc/asterisk/zapata_additional.conf is empty

File: /etc/asterisk/zapata.conf
;# Flash Operator Panel will parse this file for zap trunk buttons
;# AMPLABEL will be used for the display labels on the buttons

;# %c Zap Channel number
;# %n Line number
;# %N Line number, but restart counter
;# Example:
;# ;AMPLABEL:Channel %c - Button %n

;# For Zap/* buttons use the following
;# (where x=number of buttons to dislpay)


; include zap extensions defined in AMP
#include zapata_additional.conf

; XTDM20B Port #1,2 plugged into PSTN
;AMPLABEL:Channel %c - Button %n

yes you need to edit /etc/dahdi/system.conf. I don’t have access to the Dadhi driver code currently but you’ll have to go looking and find the supported Country code, set it and reload the drivers and then reload asterisk.

Sometimes that will include modifying driver load routine to also pass a country code at start time. You’ll need to google and/or review the code to find that out. (UK is one of those that needs both).

I have tried to change this to all countries in this reagon, but no luck.
loadzone = us
defaultzone = us

The problem is that the system don’t hang up the call, when the landline PSTN trunk is either the calling party or the called party.
I can see this by the command "sip show channels"
Last Message 73821402 4b814b8977b 00103/00000 0x8 (alaw) No Tx: ACK 7000 59C62AB206A 00101/00002 0x4 (ulaw) No Rx: ACK
2 active SIP channels

This happens in 3 different scenarios:

  1. When the party on the trunk hangs up
  2. When the party in the ZIP extension hang up
  3. When both party hang up.

It all works fine when I call from sip extension to sip trunk, and vice verse.

This problem is killing me… please help.

I don’t have a server running using Dadhi currently to help more.

You are going to need to do some research (google search time) as you are either missing something and/or found a bug in the code for your region. Try asterisk support and the forum pages as they might be better at addressing this. it’s clearly NOT a FreePBX issue but a Dadhi configuration issue.

Hi all!

I’ve just updated my freepbx with all tha latest modules and upon testing some functionalities some of them are having trouble already. I’m using asterisk 1.2.35, the latest zaptel, and the lastest core&framework or freepbx. has anyone else experienced this, when i try to call out on pstn using my ip phone and transfer the call to the conference number we’re using, after all has hung up, the call to pstn is still connected on the conference room, even if i hangup already the pstn phone. upon picking it up after 10 seconds it’s still connected. i checked on the asterisk cli using show channels and it’s still connected. even amportal restart won’t disconnect it. the only way to disconnect it to restart asterisk itself. when I dial the other way, meaning call coming from pstn going to my zap channel to my ip phone, calls are good and tranfers and hangups are all good. it’s just the outbound where i’m having trouble now. here’s the scenario:

IP PHONE transfers PSTN to CONFERENCE 6001
IP PHONE hangs up, PSTN hangs up
upon checking show channels in asterisk cli, PSTN still connected
upon picking up PSTN phone after 10secs, it indeed is still connected

IP PHONE transfers PSTN call to CONFERENCE 6001
BOTH hang up and upon checking show channels all are already in hung up state
all are hangup properly.

Hope somebody could help me resolve my issue. TIA! God Bless