Jose Arias
2009-Jul-29 12:49 UTC
[asterisk-users] Matching Originate action with its NewChannel event
An application commanding asterisk with AMI is going to launch lots of concurrent calls in very few seconds using the Originate AMI command but it's also going to need to be able to cancel very quickly any call of them even before each OriginateResponse event comes in. All the calls will be done by the same trunk (a trunking enabled channel). But there's a problem for canceling any call: there's no way to know what channel to hangup to because all channel prefixes in the NewChannel event are the same (the trunking channel one) and although the Originate action has an ActionId property, it isn't available in the NewChannel event but only in the OriginateResponse event, being very late. I've read some of you are using the CallerId property but in this case it's not an option because the application needs to establish the same callerId for all of them. Is there any solution using AMI? I'm planning to use asterisk 1.4.18 Thanks Jose -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20090729/fca908a4/attachment.htm
Scott Gifford
2009-Jul-29 15:45 UTC
[asterisk-users] Matching Originate action with its NewChannel event
Jose Arias <cyr2242 at gmail.com> writes:> An application commanding asterisk with AMI is going to launch lots of > concurrent calls in very few seconds using the Originate AMI command but it's > also going to need to be able to cancel very quickly any call of them even > before each OriginateResponse event comes in. All the calls will be done by the > same trunk (a trunking enabled channel). But there's a problem for > canceling any call: there's no way to know what channel to hangup to because > all channel prefixes in the NewChannel event are the same (the trunking channel > one) and although the Originate action has an ActionId property, it isn't > available in the NewChannel event but only in the OriginateResponse event, > being very late.I had a similar problem with faxes, and at the suggestion of somebody on the list, solved it like this: I sent a custom identifier variable in with the AMI command, which was then available to the channel. I directed the calls into a custom dialplan which used UserEvent to send an event with the identifier variable and all of the channel information. The script could then use this event to associate the identifier it generated with the channel information for that call. I just used the fax filename as a unique identifier, and I passed it in with a Variable line to AMI, called FaxFile. The dialplan entry was like this: exten => s,1,UserEvent(FaxStarted|Channel: ${CHANNEL}|Uniqueid:${UNIQUEID}|FaxFile: ${FAXFILE}) I then matched everything up by lookin at the FaxFile part of the user event. In your case, you could just make up a unique identifier of your own to send. Hope this helps, ----Scott.