[Home]

Summary:ASTERISK-10346: features don't work in AppDial
Reporter:Paul Bayley (pbayley)Labels:
Date Opened:2007-09-20 15:43:59Date Closed:2007-10-15 11:21:27
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_dial
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:DTMF-triggered actions (applicationmap features) work in a Dial only after the callee has picked up. In other words, only after an "AppDial" turns into a "Bridged Call".

This is necessary in those scenarios where I need to access features while still connected. I'm tempted to label this bug 'major' since I have yet to find a work-around.

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

I'll paint a simple scenario where it's necessary for features to work in AppDial:

I have a simple applicationmap which calls a Macro which has one line:
exten => s,1,SoftHangup(${BRIDGEPEER})

Thus when I hit a key, the other end hangs up and I continue past my Dial() in my dialplan. This allows me to continue using the dialplan after I hang up the other end, and it works as expected when the other end is answered.

If I use the console to "soft hangup" the channel I have specified in my Dial(), it works regardless if the other end has picked up or not. In other words, if the feature could trigger while it is ringing, everything ought to work as expected.

I tested this using an analog (Zap) phone to make sure it wasn't the SIP phone refusing to send DTMF tones while in a ring state. The cheap-o touch-tone phone sends DTMF tones blindly, and could not trigger the macro until the other end picked up.
Comments:By: Russell Bryant (russell) 2007-09-20 16:02:49

This is not something that I would expect to work.  It's not likely to work any time soon, either.  The features.conf stuff will only work on a bridge, as you have pointed out.

I personally classify this as a feature request and perhaps that we should update features.conf to explicitly specify that these things will only work on a bridge, but I'll let others chime in, as well.
By: Paul Bayley (pbayley) 2007-09-20 16:10:42

OK, I found a work-around. I don't know why I didn't think of this earlier:

1) Create a context like:
[answer-then-dial]
   exten => _X.,1,Answer()
   exten => _X.,2,Dial(Local/${EXTEN}@default||g)

2) Dial to this context:
   exten => 0,n,Dial(Local/${DEST}@answer-then-dial||g)
By: Paul Bayley (pbayley) 2007-09-20 16:14:21

russell,
Thanks for the prompt reply. I think some clarification would help those like me who have been butting their heads against a wall for hours. My work-around seems to work very well, so perhaps a note to that effect (perhaps pointing to this bug report) would do the job.
By: Russell Bryant (russell) 2007-09-20 18:23:43

Very nice idea to get it to work!  I am going to leave this open as a reminder to update features.conf to clarify this issue.
By: Digium Subversion (svnbot) 2007-10-15 11:19:37

Repository: asterisk
Revision: 85571

U   branches/1.4/configs/features.conf.sample

------------------------------------------------------------------------
r85571 | file | 2007-10-15 11:19:36 -0500 (Mon, 15 Oct 2007) | 4 lines

Document that DTMF based features only work when two channels are bridged together.
(closes issue ASTERISK-10346)
Reported by: pbayley

------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-10-15 11:21:27

Repository: asterisk
Revision: 85578

_U  trunk/
U   trunk/configs/features.conf.sample

------------------------------------------------------------------------
r85578 | file | 2007-10-15 11:21:26 -0500 (Mon, 15 Oct 2007) | 12 lines

Merged revisions 85571 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r85571 | file | 2007-10-15 13:39:59 -0300 (Mon, 15 Oct 2007) | 4 lines

Document that DTMF based features only work when two channels are bridged together.
(closes issue ASTERISK-10346)
Reported by: pbayley

........

------------------------------------------------------------------------