I recently updated my asterisk (running on OpenBSD) from 1.4.x to 1.8.2.2. Not the most recent version but this version comes with OpenBSD 4.9. I did not have to update anything but one thing does not work anymore:
I use a dialplan which uses AGI to log call details. Here is an abstract:
…
exten => s,n,AGI(MyLog,${MyTimeStamp} Started outbound call from ${MyPhone} to “${MyExten}”)
…
exten => s,n,Dial(SIP/${MyExten}@xxxxxxxx,g) (xxxxxxx is my anonimised number)
exten => s,n,Hangup()
…
exten => h,n(log-answer),DeadAGI(MyLog,${MyTimeStamp} Outbound call from ${MyPhone} to “${MyExten}”…)
…
The first AGI (added for debugging purposes) works. The second (Dead)AGI does not work. Replacing it with AGI does not help. I tried to display the dialplan using the console (dialplan show) and the plan is correctly shown.
Can anybody tell me what is happening? Maybe exten => h, is not executed at all.
Or help me debugging: Is there a way to have asterisk log what dialplan steps are actually executed?
Actually I don’t know why Your DeadAGI isn’t executed, but You may look at Your asterisk-cli with asterisk -rvvvvv and make a call. The steps, the dialplan is running through will be visible in the cli than and will show up wheter the step is executed or not.
I tried the asterisk -rvvvvv console and indeed can see the the dialplan running. Great.
I tested by making an outgoing call which was not answered. The console shows:
– Executing [s@macro-OutboundCall:16] Dial(“SIP/WNKMR-00000000”, “SIP/xxxxxx@xxxxxx,g”) in new stack
– Called xxxxxx@xxxxxx
– SIP/xxxxxxx-00000001 is making progress passing it to SIP/WNKMR-00000000
[Aug 20 20:38:37] WARNING[32455]: app_dial.c:1328 wait_for_answer: Unable to write frame
== Spawn extension (macro-OutboundCall, s, 16) exited non-zero on ‘SIP/WNKMR-00000000’ in macro ‘OutboundCall’
== Spawn extension (homephone, xxxxxxxx, 1) exited non-zero on ‘SIP/WNKMR-00000000’
If I read the output after the dial asterisk seems NOT to continue on the line:
exten => h,1,…
I tried to replace the line with:
exten => h,n,…
But same result.
Is the behavior of asterisk changed in this area?
Is this a problem in the version of asterisk I am using?
Ah, it’s a macro where the extensions You’re using reside in…
IMHO the h-exten within a macro is not longer executed in 1.8 as app_macro itself is declared as depreciated (with 10).
You may try the following alternatives:
a) Put the content of the h-Exten from within the macro to the calling context
b) Redesign the dialplan to use the existing macro-Context as a Subprogramm invoked by a Gosub() call in the context where You actually call the macro. You’ll find informations about Gosub and the need of the Return-Statement within the Gosub-Routine by using Your favourite search engine
Macro was deprecated in 1.6, and simulated using Gosub with a caveat that it might not handle all the edge cases properly. That is a message that seems not to have been noted by most dialplan coders.
@david55:
I think, the confusion comes a bit from the fact, that app_macro is (even in 1.8) compiled by default. Only in the upcoming Asterisk 10 it will be disabled by default alltough it’s still availabe. And: Unfortunately all existing GUIs and even some parts of the asterisk-logic itself (e.g. features) still rely on this macro-logic or support this actively (Dial(…M()))
As an effect of all this, people didn’t start to convert the logic to Gosub-routines as they should have done and - in addtion - there’s still this annpying message when using Gosub-routines and reloading the dialplan:
Anyhow, You’re totally right, I’m avoiding macros indeed since 1.6 but I didn’t get it before that someone declared them as deprecated already in 1.6
Thanks for all the responses.
So the reason that the exten => h,1,… is not executed is that macros are simulated by gosub
To resolve my problem (exten => h,1,… is not executed within a macro) I need to rewrite my dialplan to use subroutines instead. That should no be too difficult, reading the various websites it seems like macros and subroutines are very similar:
MACRO(…) must be replaced by gosub(…)
The declaration of the macro is the same as the subroutine
MacroExit must be replaced by Return.
My question:
My reading the web never confirmed: Subroutines support that I have a embedded exten => h,1,… and that it is actually being run when the Dial(…) inside the subroutine gets disconnected.
Or do I need a different approach?
Subroutines may indeed have all special extensions like h,i a.s.o.
Thus You’re free to handle a h-Case within the subroutine, although You also may handle it in the calling context, as - if the Gosub-Routine doesn’t contain a h-exten, all h-extens of the stack will be executed (cause Your special subroutine may not the only/first one which was calledm there could be a Gosub->Gosub->…->Gosub)
