Summary:	ASTERISK-06295: PRI Channels Blocking and unavailable with PRI "Call" flag set true.
Reporter:	Mark Edwards (edwar64896)	Labels:
Date Opened:	2006-02-12 16:45:20.000-0600	Date Closed:	2011-06-07 14:00:43
Priority:	Blocker	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	PRI channels are becoming blocked (and therefore unavailable for use) with the PRI Flag "Call" being set on. the "Call" flag (p->call in the PRI structure) for each blocked channel appears to be being set and not released on hangup or reset. Once blocked, the channel remains unavailable for in or outbound dialing or reset. Even with no "channels" in operation (show channels) the blocking PRI Call Flag can be seen in the PRI structures (zap show channel $n) 3-4 hours of consistent use results in no ZAP channels being available for use and the requirement to reset the Asterisk box to clear the flags. ****** ADDITIONAL INFORMATION ****** This bug shows itself consistently under tags/1.2.4. although it is not possible to identify specific steps to reproduce the blocking behaviour on demand other than conducting normal callcentre operation with multiple outbound agents. It does not appear to be present in tags/1.2.3. Does not appear to be related to high load levels in our case. Our E1 span is 10 channels with a need for 5 or 6 outbound calls max at any one time. It is a showstopper for us as we are using PRI for outbound calls and are running out of available PRI channels after about 3-4 hours of constant use. The symptom of the problem is an attempt to dial out with no more available channels results in dial failure with cause code 34 - CHANUNAVAIL dialstatus. The only way to reset the PRI flags on the blocked channels is to restart Asterisk. We have, for now, rolled back to 1.2.3. Suggest channels/chan_zap.c and zaptel for initial investigation. PRI Call Flag visible for each channel with a "zap show channel $n" Comments relating to this issue have been added to bug 6147 as symptoms appear to be similar. I am comfortable if bug marshalls decide to close this bug as a duplicate, however I am not comfortable that this bug is currently related to agents as appears to be current thinking on 6147. My gut tells me that there is an issue somewhere in chan_zap.c or zaptel/wcte11xp as the problem is visible with no asterisk channel structures in memory (show channels). At least, there appears to be a relationship between this bug and some of the comments in 6147.
Comments:	By: Mark Edwards (edwar64896) 2006-02-12 17:51:36.000-0600 Confession and Request. Confession: I have posted this bug for the wrong project category. Reason - version 1.2.4 of "asterisk" indicates the issue whereas 1.2.3 doesn't. Both tests use 1.2.3 of zaptel indicating that the bug is probably not in Zaptel and more likely elsewhere in the asterisk tree. apologies. Request - can someone identify a more appropriate category and change it pls. my pref for now would be chan_zap.c (Channel Drivers) I'd change it if I could... ta. By: Mark Spencer (markster) 2006-02-14 11:33:48.000-0600 This is a technical support issue.  Please pursue through Digium tech support (support@digium.com).  If you are unable to get a resolution to your problem, please e-mail me your support ticket number.  Thanks!