[asterisk-users] Originate Status Monitoring

[Richard Lyman]

Essien Ita Essien wrote:
> Hi all,
>
> I'm writing an application to Queue and Manage AMI Originate actions. 
> Basically, callfiles on steroids if you may :)
>
> I'm facing the following challenges, and any ideas or pointers will be 
> hugely appreciated.
>
> 1. When I successfully Queue an Originate... (Response is Success), how 
> will i know when the channel has been freed up? I had initially been 
> monitoring the Response/Message/ActionID trio, but i discovered that 
> this returns immedietly asterisk queues the command.
>
>   
You have to mod the Event: Hangup manager event to include something 
useful for you.

This is an example of adding the CallerIDNum/Name to the event.
http://dynx.net/ASTERISK/gnudialer/channel.c.hangup_callerid_ast1419.diff


>   I've also noticed that Events keep popping up during the life-time of 
> the Origination. I'm guessingthe solution would be to monitor for a 
> particular event. My question then is... can i _always_ count on Even: 
> Hangup, always being present, _nomatter_ what? (As i've noticed Hangup 
> is raised even on failed events)
>
>   
On failed 'attempts' it would be an origination 'failure', and those you 
need to use a...

; this extension MUST be here for OriginateFailure triggers
exten => failed,1,Hangup

in the context you use for your originate attempt.

That will produce another manager event, which will provide a Reason: code.

That code is the 'AST_CONTROL' of what last happened on that channel.
frame.h:#define AST_CONTROL_HANGUP              1
frame.h:#define AST_CONTROL_RING                2
frame.h:#define AST_CONTROL_RINGING             3
frame.h:#define AST_CONTROL_ANSWER              4
frame.h:#define AST_CONTROL_BUSY                5
frame.h:#define AST_CONTROL_TAKEOFFHOOK         6
frame.h:#define AST_CONTROL_OFFHOOK             7
frame.h:#define AST_CONTROL_CONGESTION          8
...

> 2. I have noticed that in version 1.4.21, the events do not carry any 
> associated ActionID (which is understandable, as they may not be in 
> response to any AMI commands). My question then i how can i reliably 
> detect which events have to do with me?
>
>   
Refer to the calleridnum/name section above.