Continue processing DialPlan during Dial() but prior to hangup

Evening - Asterisk noob here. I’m developing an app to work with Asterisk and I want to be able to POST some JSON information immediately after a Dial() is made. I have read docs and found ways to continue after the call has been completed/hungup/etc, but I need to have it dial and then immediately proceed.

…. start of call up here works fine…
same => n,Dial(SIP/1${DestinationNumber}@outbound001,60)

same => n,jsonadd(inbound_json,string,key1,${value1})

same => n,jsonadd(inbound_json,string,key2,${value2})

same => n,jsonadd(inbound_json,string,key3,${value3})

same => n,jsonadd(inbound_json,string,CallTime,${CallTime})

same => n,Log(NOTICE, ${JSONPRETTY(inbound_json)})

same => n,Set(inbound_post_result=${SHELL(curl -X POST https://URL/api/destination -H ‘Content-Type: application/json’ -H 'server-auth-key:MYKEY-HERE

same => n,Congestion

Any ideas?

Thanks in advance!

After doing some more digging, perhaps Originate() might be a better solution? Jam there is figuring out what application I can use to bridge the existing channel with the newly originated channel. Once the new channel is answered (or not) Originate seems to proceed through the original dialplan - allowing me to POST.

I know you guys don’t appreciate noobs doing complicated things - so I apologize. If it’s any consolation - I’m a Cisco CCNP Voice guy who’s thinking about defecting! =) So concepts aren’t lost on me - just the specifics.

Thanks again for the community’s time.

Fundamentally in dialplan you can’t do two things at once. It’s a sequential operation, and Dial blocks so it doesn’t continue until it exists. Dial does provide pre-dial handlers[1] that can be executed before dialing the channel. As for using Originate coordinating it all may prove complicated unless you potentially involve AMI or other things, but you’re really fighting the way dialplan plans.

[1] https://wiki.asterisk.org/wiki/display/AST/Pre-Dial+Handlers

Dial also has a goto option, where the call i not bridged, but the two sides each run their own dialplan. One of them can then, explicitly, bridge to the other.

Try adding in a local channel as a parallel dial that runs your code.

just don’t answer the local channel.

Nailed it John. I did it last night and tested successfully! It was like 1:00am so I didn’t update post. Felt a bit hacky but it totally worked for my POC. In production I think we’ll end up running everything through ARI (open
to suggestions) so I can keep the data stuff I’m doing completely asynchronous and independent from the call engine.

Thank you to you both for your replies!

here’s the summarized version of how it’s implemented (all specifics removed). Hope this helps someone else out there:
exten => 1111,1,Log(Notice, doing some Asterisk magic)
same => n,NoOp(custom stuff)
same => n,NoOp(custom stuff)
same => n,Dial(SIP/1${DestinationNumber}@outbound001&LOCAL/100@post_inbound,60)
same => n,Congestion

[post_inbound]
exten => 100,1,NoOp()
same => n,Wait(1)
same => n,jsonadd(inbound_json,string,Key1,{Value1}) same => n,jsonadd(inbound_json,,string,Key2,{Value2})
same => n,jsonadd(inbound_json,string,Key3,{Value3}) same => n,jsonadd(inbound_json,,string,Key4,{Value4})
same => n,Log(NOTICE, {JSONPRETTY(inbound_json)}) same => n,Set(inbound_post_result={SHELL(curl -X POST https://myapp/api/whereiwanttopost -H ‘Content-Type: application/json’ -H 'server-auth-key: ‘mykey’ -d ‘${inbound_json}’)})
same => n,Hangup

1 Like