Asterisk / AMI / Perform actions based on the status of "Originate" action

I'm brand new to Asterisk. I'm using Asterisk AMI over http, and the "Originate" command to dial and connect two external phone numbers. Is it possible to add some additional logic (to the dialplan?) that would

a) do something when the calls are successfully connected (like make an http call, or log something in a db table)
b) do something else when the calls are NOT connected successfully (Say one of the parties accidentally hung up before the call could even get started).

I know I could repeated "poll" the server and check the events, but that seems inefficent if it could be done at a lower level. From what I've read so far in Asterisk: The Definitve Guide, I think it's possible ... I'm just not sure how yet :)

Any suggestions pointing in the right direction would be greatly appreciated!
LVL 53
_agx_Asked:
Who is Participating?
 
kode99Commented:
I had to hook up my Asterisk lab setup.  With originate it is slightly different than a normal call.

So when you start the call it rings into the extension, then when that extension is answered the dialout occurs.  The portion where the extension rings is not really in the dialplan.  So if you reject that call nothing happens BUT you will get a even on the AMI telling you that the call was rejected etc.

This will be like this,  where ActionID matches the value you set when you made the call.
 
Event: OriginateResponse
Privilege: call,all
ActionID: ABC123456
Response: Failure
Channel: SIP/2223
Context: Polycom6701
Exten: 2231
Reason: 5
Uniqueid: <null>

What the Reason number means is seen here.
http://www.voip-info.org/wiki/view/Asterisk+Manager+API+Action+Originate

This even also fires a success after the call has been completed.

If you were watching the events you would also get Hangup event with a cause value and text info.  I think you need to be monitoring for call activity to see this event though.

Once you have picked up the extension the call will proceed normally in the dialplan from the point the originate specified.  So this is fairly simple in that you just need to add a bit of logic following the Dial line that checks the DIALSTATUS variable and do what you need to accordingly.

http://www.voip-info.org/wiki/view/Asterisk+variable+DIALSTATUS
0
 
kode99Commented:
This can be done strictly through the AMI interface by monitoring the activity through events.  It means watching all the traffic and sorting out those relevant to your originate but it works.

Here's a list of events in Asterisk 11 for example,
https://wiki.asterisk.org/wiki/display/AST/Asterisk+11+AMI+Events

You will see the individual channel setup,  connection of those channels, and the shutdown.

The big benefit is that you don't have to modify the dialplan this way.  The drawback is there are a fair number of events to sift through.  I use this method for a status panel through AMI over TCP.  I would suggest logging all the call activity generated from one of your originate commands and you will have a example of the events you need to be monitoring for.

A second option would be to use the UserEvent in the dialplan which will send a event to the AMI with whatever information you want to send.  It is fairly simple but will require you to do some logic in your dialplan.  

You can also use the curl command to do a http request from the dialplan,  basically the same work as using a UserEvent in that you need to do the dialplan modifcations.
http://www.voip-info.org/wiki/view/Asterisk+cmd+Curl

You can also post data to a database but then you would have to poll the database.  It is better to stay with something event driven.
0
 
_agx_Author Commented:
> The drawback is there are a fair number of events to sift through.

Yeah, I was hoping to avoid monitoring and use something a little more direct, like trigger a curl call at the end of the call, and pass the final status ie connected, no answer, etc..  I'm just not sure where to add that to the dialplan.
0
Cloud Class® Course: Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

 
_agx_Author Commented:
> The portion where the extension rings is not really in the dialplan ...
>  So if you reject that call nothing happens BUT you will get a even on
>  the AMI telling you that the call was rejected etc.

Interesting.. I didn't know that.  In my case I'm connecting two external numbers using the "Local" channel. Is the same true for the "Local" channel as well, since it's not an "extension" per se (at least not as I understand them)

My originate action between the two numbers looks something like this

Action: Originate
Channel:  Local/1NPANXX1111/@existing-internal-context
Context:  external-to-external-calls-context
Exten:  1NPANXX3333

BTW: Thanks for the good descriptions. It gives me a better picture of what's happening with the call flow.  I'm tied up on another task, but will set up monitoring and check the events you mentioned later.
0
 
kode99Commented:
Have you looked at the AMI traffic?

The local channel is likely going to change where you need to do the dialplan modifications and may add a few more events to the AMI traffic.

I have not used local channels with my AMI apps so not sure how it will show up. I imagine you will see the setup for the local channel,  much the same as the setup for a direct sip to sip call,  then possibly a 2nd round for the connection of the two calls.

If I get the time this week I'll take a look at how the local channels showup in the AMI for connecting up calls.
0
 
_agx_Author Commented:
Sorry, its my turn to be caught up with a deadline. I'll try and get back to this on the w/e
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.