[Home]

Summary:ASTERISK-07550: [patch] chan_zap plays dialtone even if channel seize fails
Reporter:Rolf Braun (rbraun)Labels:
Date Opened:2006-08-18 16:43:14Date Closed:2006-11-12 18:36:51.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_zap
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) patch-1.2.10
Description:Zaptel's ZT_HOOK ioctl returns -EBUSY if called to take a channel in ZT_TXSTATE_KEWL or ZT_TXSTATE_AFTERKEWL back off the hook. I believe this is correct behavior despite interactions with other bugs (see bug 7612). However, chan_zap will play a dialtone when such a channel is taken off hook on the other end, despite that zaptel refuses to acknowledge the offhook in this state. This is accompanied by a warning in the console output (in debug mode) containing the text "zt hook failed". The result is a dialtone on which nothing can be dialed. The correct behavior would seem to be to play silence; the attached patch forces chan_zap to check the return code of the ioctl and bail if the line could not be seized.

****** ADDITIONAL INFORMATION ******

It is somewhat unlikely this bug would be encountered often at most sites; however, we have KEWLTIME set to 1.5 seconds and AFTERKEWLTIME to 2.5 seconds at one site. This is to provide an extended disconnect supervision required by a third-party legacy PBX, as well as a guard time which triggers another behavior where we drop battery again to avoid a race condition (to be filed as a feature request). The extended time allows more opportunity to see bugs where something doesn't work right if zaptel is in TXSTATE_KEWL or TXSTATE_AFTERKEWL.

The patch applies against 1.2.10 but I see nothing in the source (either in chan_zap or in zaptel) which would point to this being fixed in the 1.4 trunk.
Comments:By: Rolf Braun (rbraun) 2006-08-18 16:44:31

Ugh -- this should have been reported under chan_zap and not zaptel.
By: jmls (jmls) 2006-11-01 05:34:29.000-0600

does anyone have any comments to make on this ?
By: Tilghman Lesher (tilghman) 2006-11-12 18:36:51.000-0600

Merged in 47522.