Summary:ASTERISK-03986: Zap option 'c' breaks Dial option 't'
Reporter:bdolljr (bdolljr)Labels:
Date Opened:2005-04-25 15:24:30Date Closed:2008-01-15 15:35:31.000-0600
Versions:Frequency of
Environment:Attachments:( 0) chan_zap.c.diff
Description:When using Zap option 'c' confirmed dial, the called party can no longer transfer a call with Dial option 't'.


Not sure if this should be a bug against app_dial, but I don't see a Zap category.
Comments:By: Michael Jerris (mikej) 2005-04-25 15:35:34

Is this related too http://bugs.digium.com/bug_view_page.php?bug_id=0004065 ?  Can you process any dtmf from remote party?

By: bdolljr (bdolljr) 2005-04-25 15:57:00

It doesn't appear to be related because the examples in 4065 don't use Zap 'c'.  Our config is a Te110p on NI2 pri.  When option 'c' is omitted, DTMF works fine (at least '#' to transfer).

I did notice that *ANY* DTMF will confirm a Zap 'c' dial.  Not just a '#'.  FWIW.

By: Brian West (bkw918) 2005-04-25 22:13:42

This is NOT a major bug.  The work around is to not use them together.  Use the M (macro) option to accomplish this if you like...


By: bdolljr (bdolljr) 2005-04-25 23:23:43

Well, to tell you the truth...  I was looking for a category other than MAJOR to post this under, but following the bug guidelines which say

"A bug which completely prevents Asterisk from operating in a method that it normally is expected to operate -- and particularly if it cannot be reasonably worked around -- is MAJOR"

...and since I'm using STABLE 1.0.7 and the Macro functionality can't be used to create this behavior as a workaround... I posted this bug.

I would be happy to be corrected if Macro can accomplish this functionality in STABLE or if anyone could point me to any documentation which says these features are not expected to operate together.

As I understand, the enhancements to Macro are only in HEAD.

I've spent days trying to work around this issue and have not found a reasonable solution, since moving to HEAD (and thus getting pretty decent Macro support) is not an option for our production systems.

By: bdolljr (bdolljr) 2005-04-25 23:49:24

Additionally,  if I were to use HEAD and the new Macro capabilities it still would not be a reasonable workaround.

I would like to Dial(SIP/7960&Zap/g0c/XXXXXXX,30,tr)

In the scenario where SIP/7960 is obviously my Cisco 7960 and Zap/g0c/XXXXXXX is my cell phone...

I'm dialing on a PRI with answer supervision.

When my cell phone is off, and my cell phone voice mail immediately picks up the call, my SIP extension stops ringing.

Therefore, I only get one second of ring on my SIP phone instead of 30 seconds.  This basically makes my SIP phone unusable.

Zap 'c' allows for my SIP phone to continue to ring "until" the Zap call is confirmed where any implementation of Macro does not.

Looking at chan_zap.c I can see that it "eats" all DTMF's when the 'c' option is used.  Maybe it could only do this for the confirmation DTMF tone and then revert back to non 'c' behavior.

By: bdolljr (bdolljr) 2005-04-26 08:21:41

Patch uploaded. Disclaimer on file.

edited on: 04-26-05 08:22

By: Kevin P. Fleming (kpfleming) 2005-04-26 21:09:20

Committed to CVS HEAD, thanks!

By: Digium Subversion (svnbot) 2008-01-15 15:32:16.000-0600

Repository: asterisk
Revision: 5509

U   trunk/channels/chan_zap.c

r5509 | kpfleming | 2008-01-15 15:32:16 -0600 (Tue, 15 Jan 2008) | 2 lines

reset 'confirm' mode so DTMF can be used by Zap callees after confirming (bug ASTERISK-3986)



By: Digium Subversion (svnbot) 2008-01-15 15:35:31.000-0600

Repository: asterisk
Revision: 5730

U   branches/v1-0/channels/chan_zap.c

r5730 | russell | 2008-01-15 15:35:31 -0600 (Tue, 15 Jan 2008) | 2 lines

reset 'confirm' mode so DTMF can be used by Zap callees after confirming (bug ASTERISK-3986)