[asterisk-bugs] [Asterisk 0015796]: The order of the execution inside the Dial app is wrong

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15796 
====================================================================== 
Reported By:                falves11
Assigned To:                tilghman
====================================================================== 
Project:                    Asterisk
Issue ID:                   15796
Category:                   Applications/app_dial
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.1 
SVN Revision (number only!): 214821 
Request Review:              
====================================================================== 
Date Submitted:             2009-08-30 22:44 CDT
Last Modified:              2009-08-31 08:51 CDT
====================================================================== 
Summary:                    The order of the execution inside the Dial app is
wrong
Description: 
As you can see in my dialplan, I have D(w${EXTEN}) and M(voicedetection)
No matter in what order I include these parameters, the macro executes
first. It makes sense that the D() part executes first,because I need to
use a macro to do human voice detection, but I am dialing with D() in a
second stage, so unless I dial first I cannot do voice detection. I tried
doing SendDTMF inside the macro, but the digits are heard in the calling
side, when I need them to got to the called side.
In general, the order of execution of D() and M() should be given by the
order in which we write them in the dial string. This bug may affect all
versions.

dialplan show inbound                                                     
                                                                           
                             
[ Context 'inbound' created by 'pbx_config' ]
  '_X.' =>          1. Set(CALLERPRES()=allowed)                 
[pbx_config]                                                               
                                                 
                    2. Set(GROUP()=trunkgroup1)                  
[pbx_config]
                    3. Verbose(0,ACTIVE CALLS ${GROUP_COUNT(trunkgroup1)}
${EXTEN}-ANI->${CALLERID(num)} IP:->${CHANNEL(recvip)}) [pbx_config]
                    4. Set(CALLERID(all)=${CALLERID(num)})       
[pbx_config]
                    5.
Dial(Sip/XXXX at XX.XX.XX.XX,25,L(1800000)D(w011${EXTEN}#)M(voicedetection)) 

[ Context 'macro-voicedetection' created by 'pbx_config' ]
  's' =>            1. NoCDR()                                   
[pbx_config]
                    2. Set(MACHINE=0)                            
[pbx_config]
                    3. verbose(0,Begin Answer)                   
[pbx_config]
                    4. WaitForSilence(500,20)                    
[pbx_config]
                    5. Verbose(0,WAITSTATUS 1 ${WAITSTATUS})     
[pbx_config]
                    6. GotoIf($[${WAITSTATUS}=SILENCE]?SILENCE:TIMEOUT)
[pbx_config]
     [TIMEOUT]      7. Verbose(0,DETECTED TIMEOUT)               
[pbx_config]
     [SILENCE]      8. Verbose(0,DETECTED NOISE)                 
[pbx_config]


====================================================================== 

---------------------------------------------------------------------- 
 (0109839) falves11 (reporter) - 2009-08-31 08:51
 https://issues.asterisk.org/view.php?id=15796#c109839 
---------------------------------------------------------------------- 
I want to point out that we need a way to do Human Answer Supervision in
Asterisk, as the old Dialogic-based products did.
I mean when I receive an inbound call and dial an outbound call, I need to
understand what is picking up the call on the far end, and bridge the two
channels together if it is acceptable. There is another flag in the Dial
function, G(), but it is absurd that there is no way to bridge the channels
after doing some processing. Maybe the solution to this puzzle would be to
write a function to bridge the two channels in the dial plan. Then we could
do some processing prior to the callers start talking. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-08-31 08:51 falves11       Note Added: 0109839                          
======================================================================