QGOSUB asynchronous execution

I have created a very nice script that runs when a member of a queue picks up a call. The problem is, the script, which makes API calls to a third-party application, takes about 5-10 seconds to complete. While the dialplan is waiting for the Return() it does nothing, and the the call is not connected. The agent and the caller both hear 5-10 seconds of silence.

Is there a way to execute the system script without waiting for an exit code? I tried a couple different variations of:

exten => s,1,System(/usr/scripts/script.sh ${FROMEXTEN} EXT=${CALLERID(num)})
exten => s,1,System(/usr/scripts/script.sh ${FROMEXTEN} EXT=${CALLERID(num)} &)
exten => s,1,System("/usr/scripts/script.sh ${FROMEXTEN} EXT=${CALLERID(num)} &")

none of which displayed the desired behavior.

As a compromise, I tried doing a system beep when the script was done executing by doing

exten => s,1,System(/usr/scripts/script.sh ${FROMEXTEN} EXT=${CALLERID(num)})
same => s,1,Playback(beep)
same => n,Return()

but all that did was execute the script, beep, then wait for the script to end before running the Return()

I also tried several methods of adding additional commands to the QGOSUB= in the globals_custom.conf, but I couldn’t get anything to work like I expected.

Any help is much appreciated. Thank you!

Rather than QGOSUB, is there a built-in function to execute a macro context upon a queue agent picking up a call? Would this achieve my desired result? It seems like my desired result would be a macro rather than a GoSub anyway…

Macro is deprecated
https://wiki.asterisk.org/wiki/display/AST/app_macro+Deprecation

You want to likely use AGI over System
https://wiki.asterisk.org/wiki/display/AST/Application_AGI

So does that mean that in globals_custom.conf I should set

QAGI=subCreateTicket,start,1

instead of

QGOSUB=subCreateTicket,start,1

? Then, I would modify the context to remove the Return() line. If I’m reading the command syntax correctly, upon an agent answering a queue call, the system would run AGI(subCreateTicket,start,1) which would execute the script, but not wait for an answer.

I can see that QAGI is a thing that’s hard-coded, but is it used for anything else where setting it in globals would break something else?

I realize I could hand-edit some of these config scripts, but my goal is to create something that’s within the framework of proper customization so that I don’t break anything else, or make something that is undone the next time the server reloads.

Does that sound correct? Again, I apologize for my ignorance regarding Asterisk dialplans. I’m learning! :slight_smile:

OK, so I made the following modifications: In my globals_custom.conf I changed the entry back to:

QGOSUB=subCreateTicket,start,1

then, I changed my context in extensions_custom.conf to:

[subCreateTicket]
exten => s,1,AGI(/usr/scripts/createsupportticket.sh,${FROMEXTEN},EXT=${CALLERID(num)}:async)
same => n,Return()

It looks like the syntax is correct, and the script appears to be executing properly. I see the following in the debug output:

[2014-07-23 18:31:31] VERBOSE[36029][C-0000000b] pbx.c:     -- Executing [[email protected]:1] AGI("Local/[email protected];1", "/usr/scripts/createsupportticket.sh,+15555555555,EXT=5555:async") in new stack

and this is in the AGI debug:

<Local/[email protected];1>AGI Tx >> agi_request: /usr/scripts/createsupportticket.sh
<Local/[email protected];1>AGI Tx >> agi_channel: Local/[email protected];1
<Local/[email protected];1>AGI Tx >> agi_language: en
<Local/[email protected];1>AGI Tx >> agi_type: Local
<Local/[email protected];1>AGI Tx >> agi_uniqueid: 1406154690.109
<Local/[email protected];1>AGI Tx >> agi_version: 11.10.2
<Local/[email protected];1>AGI Tx >> agi_callerid: 5555
<Local/[email protected];1>AGI Tx >> agi_calleridname: Craig Hamm
<Local/[email protected];1>AGI Tx >> agi_callingpres: 0
<Local/[email protected];1>AGI Tx >> agi_callingani2: 0
<Local/[email protected];1>AGI Tx >> agi_callington: 0
<Local/[email protected];1>AGI Tx >> agi_callingtns: 0
<Local/[email protected];1>AGI Tx >> agi_dnid: unknown
<Local/[email protected];1>AGI Tx >> agi_rdnis: unknown
<Local/[email protected];1>AGI Tx >> agi_context: subCreateTicket
<Local/[email protected];1>AGI Tx >> agi_extension: s
<Local/[email protected];1>AGI Tx >> agi_priority: 1
<Local/[email protected];1>AGI Tx >> agi_enhanced: 0.0
<Local/[email protected];1>AGI Tx >> agi_accountcode:
<Local/[email protected];1>AGI Tx >> agi_threadid: 140225231136512
<Local/[email protected];1>AGI Tx >> agi_arg_1: +15555555555
<Local/[email protected];1>AGI Tx >> agi_arg_2: EXT=5555:async
<Local/[email protected];1>AGI Tx >>

The script is executing, and the ticket is being created with the proper variables, but I still hear no audio from either side of the call until the script has continued executing. What am I missing?

I came up with something that works: The AGI, instead of calling the script directly, calls another script, which is simply:

#!/bin/bash
/usr/scripts/createsupportticket.sh $1 $2 > /dev/null 2>&1 < /dev/null &

Maybe I’m wrong, but it kinda seems like a sloppy solution. However, it’s functional. If anyone can suggest a better way to do it, I’m all ears, but if not, this will work.

One thing to ask, though: What would be the advantage or disadvantage of this:

exten => s,1,AGI(/usr/scripts/invoketicketcreation.sh,${FROMEXTEN},EXT=${CALLERID(num)})

over this:

exten => s,1,System(/usr/scripts/invoketicketcreation.sh ${FROMEXTEN} EXT=${CALLERID(num)})

? They both work, but is there one I should or shouldn’t be using?

There are also the functions TrySystem() and Shell() which I didn’t even look at, but would either of those behave differently?

Thanks again for taking the time to help me out!

For anyone coming across this old post, please note that QGOSUB in globals does NOT get extension and priority. I used info from this post when trying to create pre-queue processing. The program worked great, but I much later found out calls were coming out of the queue LIFO instead of FIFO. I had no idea that the line above had anything to do with this issue.

Here’s what Mike from Sangoma support said when I entered a ticked for that issue:
"So it took some digging but the issue is that the following is set in “globals_custom.conf”:

QGOSUB=subQueueAlert,s,1

I went and added the globals custom line to my system and was able to reproduce the behavior. Removing this line (or removing the “,s,1” part) should cause the Queue call to assign the default queue order instead of forcing new calls into slot 1."

So I removed the ‘,s,1’ from the line in globals_custom.conf, then subQueueAlerts continued to run as it should, calls were handled FIFO and we lived happily ever after.

I hope this saves someone two hours paid support.
(But I’m really glad it was available!) :slight_smile:

2 Likes

Why not reporting this to issues.freepbx.org?

I think the issue is no documentation can be found on the QGOSUB global variable. Not really a dev issue.