[Asterisk-bugs] [Asterisk 0007612]: [patch] Zaptel misreports channel in battery drop state as available, then refuses to open it

[noreply at bugs.digium.com]

The following issue has been RESOLVED. 
====================================================================== 
http://bugs.digium.com/view.php?id=7612 
====================================================================== 
Reported By:                rbraun
Assigned To:                mattf
====================================================================== 
Project:                    Asterisk
Issue ID:                   7612
Category:                   Core/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     resolved
Asterisk Version:           1.4.5 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        Yes 
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             07-28-2006 18:28 CDT
Last Modified:              07-05-2007 12:58 CDT
====================================================================== 
Summary:                    [patch] Zaptel misreports channel in battery drop
state as available, then refuses to open it
Description: 
In asterisk chan_zap, the function available() is used to check that a
channel is free before trying to dial on it. It is also used to find such a
channel when a Zap group dial is used, such as Dial(Zap/G1/5551212).
Chan_zap relies on the ZT_GET_PARAMS zaptel ioctl to find enough channel
information to ensure that the channel is available even if it does not
know of a call on that channel.

If the channel is in the battery drop state (ZT_TXSTATE_KEWL) or in the
guard time after it (ZT_TXSTATE_AFTERKEWL), the parameters returned by
ZT_GET_PARAMS do not indicate that the channel is not available to be used.
available() and zt_request() will thus select that channel, try to open it,
and fail (EBUSY is returned by zaptel due to the channel state). The result
is that a call being made to a group dial will fail even though there are
channels free in the zap group; as this results in a call failing to go
through, I am filing this as a major bug. We have worked around this in the
past by doing a manual rollover (e.g. priority 1 dials Zap/1, priority 2
dials Zap/2), but that should not be necessary.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
child of            0007755 [patch] workaround for race condition w...
====================================================================== 

---------------------------------------------------------------------- 
 qwell - 07-05-07 12:58  
---------------------------------------------------------------------- 
Fixed in svn branches 1.2, 1.4, and trunk, in revisions 2696, 2697, and
2698. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-05-07 12:58  qwell          Status                   assigned => resolved
07-05-07 12:58  qwell          Resolution               open => fixed       
07-05-07 12:58  qwell          Note Added: 0066544                          
======================================================================