Hello, all! I'm looking at the wiki page and info on the mailing list and I'm getting conflicting info... I am using the manager API from the telnet CLI and I am testing creating calls with it. I login with events: on and I can originate calls just fine. However, when I set ActionID on an Originate, I cannot see anywhere where that actionid carries into the Event output. But I found this on a post from January: Yes, ActionID is a value you can use when issuing a command. It there so that you can be sure you respond to your own responses not to someone else's or that you respond to an response instance in the correct way. In a multi-threaded app you might have several actions outstanding so you will need to know what response corresponds to which command. Which indicates that the actionid should be coming through. Is there perhaps some setting I'm missing? Thanks! -- -M There are 10 kinds of people in this world: Those who can count in binary and those who cannot.
In article <20050913161718.GA22773@brutus.pewamo.office>, Michael George <george@mutualdata.com> wrote:> Hello, all! > > I'm looking at the wiki page and info on the mailing list and I'm getting > conflicting info... > > I am using the manager API from the telnet CLI and I am testing creating calls > with it. I login with events: on and I can originate calls just fine. > > However, when I set ActionID on an Originate, I cannot see anywhere where that > actionid carries into the Event output. > > But I found this on a post from January: > Yes, ActionID is a value you can use when issuing a command. It there so > that you can be sure you respond to your own responses not to someone else's > or that you respond to an response instance in the correct way. In a > multi-threaded app you might have several actions outstanding so you will > need to know what response corresponds to which command. > > Which indicates that the actionid should be coming through. Is there perhaps > some setting I'm missing?The ActionID will be present in the Response message. If you don't specify "Async: yes" in the Originate message, the Response won't be returned until the call has failed or been answered. If you do specify "Async: yes", the Response comes back immediately saying the request has been queued. When the call subsequently fails or is answered, you will receive an OriginateFailure or OriginateSuccess event, which will carry the ActionID of the original request. However, the ActionID will not be present in the Newchannel, Newexten, Link (and so on) events that occur while the call is being placed and answered. Hope this helps. Cheers Tony -- Tony Mountifield Work: tony@softins.co.uk - http://www.softins.co.uk Play: tony@mountifield.org - http://tony.mountifield.org
Michael George wrote:> Hello, all! > > I'm looking at the wiki page and info on the mailing list and I'm getting > conflicting info... > > I am using the manager API from the telnet CLI and I am testing creating calls > with it. I login with events: on and I can originate calls just fine. > > However, when I set ActionID on an Originate, I cannot see anywhere where that > actionid carries into the Event output. > > But I found this on a post from January: > Yes, ActionID is a value you can use when issuing a command. It there so > that you can be sure you respond to your own responses not to someone else's > or that you respond to an response instance in the correct way. In a > multi-threaded app you might have several actions outstanding so you will > need to know what response corresponds to which command. > > Which indicates that the actionid should be coming through. Is there perhaps > some setting I'm missing? > > Thanks! >Hi, have you set Async attribute of your Originate Action to 'true'? Because as far as I know Events are only generated if it is set to true. Joerg