Asterisk v1.2 - New Subroutine Apps

I am trying to get my head around the utility of how the subroutines work in v1.2x: … +cmd+Gosub … md+GosubIf … d+StackPop … d+StackPop

What does this do that a macro does not? The reason I am interested, is I would like an application to do the following:

  • Answer
  • Record the persons name/intended party to connect
  • Put caller on hold/parked
  • Call the intended party and play name
  • Ask the intended party if they want to accept the call (1 - yes, 2 - no)
  • If yes connect
  • If no send to voicemail

The issue I see, is that in a context where I dial the intended party, it will immediately connect the call.

It’s got me stumped as well, I was hoping that the return statement had the option of returning a value that could be tested by the calling line. Doesn’t appear to be the case unfortunately.

In answer to your question, regardless of the method (macro or gosub) could you not do the following.

Answer the call, and record details
Park the call
Dial the extension and play recording/IVR
If call accepted, call ParkedCall()
If not, use timeout on park to send to VM?



I’m assuming that I don’t understand your question because it would blow my mind to actually be able to explain something to you :smile:

If I understand you correctly, then I’m doing exactly what you want.

The key is to use the M flag and invoke a macro in your Dial command. For example (after you’ve collected the call-screen introduction recording from the caller)

exten => s,n,Dial(${ALLHOUSE},20,TtmM(play-screen^${ANNOUNCE}))

In the play-screen macro, after playing the screen and getting a “send the call to voicemail” DTMF response from the callee, set the value of MACRO_RESULT, like:


What I’ve deduced is that if you leave the value of MACRO_RESULT unset, at the end of the macro execution the call connects. If you set it to some kind of GOTO, or to CONTINUE, the call is never bridged.

So to rephrase, and hopefully clarify, the slightly odd behavior is that if you desire the call to simply connect at the end of the macro, you leave MACRO_RESULT undefined, and it implicitly bridges the call, then hangs up upon completion. I guess what I’m saying is it would have been cleaner, to me, if there were an explicit value for MACRO_RESULT, such as “CONNECT”, which triggered this behavior. It would also be helpful if the wiki mentioned this (I’ll add a note there if nobody disagrees with this post in a couple of days).

I hope that helps.

[Edit: found a bug here today! Changed the Dial flags to TtmM (i.e., it was TtmgM, so I removed the g flag). The g flag caused the caller to continue on in the calling context after the callee hung up. Which is expected behavior, but not what I wanted here!
Edit2: (hopefully) further clarified the MACRO_RESULT variable]

That just might do it, thanks! Testing now.

I have been scouring the web for a couple of hours looking for this exact solution - I’m a little lost on how the macro should be structured, so if anyone might be able to shed some light on this for me, it would be much appreciated.