Manager API & using Action ID - launching multiple reqs

I am interacting with the Asterisk Manager API (v1.2.4) in order to create an application that may do the following:

  • Launch multiple originate requests without waiting for the response with the callerid/uniqueid to build call instances in order to create an asynchronous dialing app
  • Have the ability to ignore originate request, and associated events, that were not originated by my application

The ActionID capability of the Manager API appears to be the key, but in tests seems largely not useful. An example:

[code]Action: originate
Channel: SIP/3002
Context: test_agent
Extension: s
Priority: 1
ActionID: 1234

Response: Success
ActionID: 1234
Message: Originate successfully queued[/code]

The response with the all crucial unique ID, but no ActionID associated!

Event: Newchannel Privilege: call,all Channel: SIP/3002-4325 State: Down CallerID: <unknown> CallerIDName: <unknown> Uniqueid: 1139730137.636

Is there anyway to do this with the ActionID, or is the ActionID really only just a way to tie an ‘ack’ to the request? What use is that, really, if you have to wait for the Newchannel even to get the uniqueID for that call?

Also tried to tag the originate with a variable to see if I would get that back in the sequence in order to associate with the uniqueID:

[code]Action: originate
Channel: SIP/3002
Context: test_agent
Extension: s
Priority: 1
Variable: mapi_id=1234

Response: Success
Message: Originate successfully queued

Event: Newchannel
Privilege: call,all
Channel: SIP/3002-7cce
State: Down
CallerID:
CallerIDName:
Uniqueid: 1139730589.637[/code]

But, once again, nothing in the NewChannel for me to tie in the uniqueID with that request. Also, using the ‘channel’ would not be an option, as I may be launching multiple requests to the same channel (ie - phone numbers, local extensions, etc).

Any other ideas? I can not believe that one must serialize requests to the Manager API.

Does anyone see an issue with this scenario?:

  • Tag any new originate with a seperate unique ID as a variable, something like: mapi_id=(my_unique_id)
  • Then anytime you get your first response you do a GetVar
  • Then you have the ability to associated the uniqueID with your my_uniqueID

Also, if your ‘mapi_id’ is not there, then you know to ignore all events to that uniqueID as you did not originate.

Anyone have better ideas?

[quote]Does anyone see an issue with this scenario?:

  • Tag any new originate with a seperate unique ID as a variable, something like: mapi_id=(my_unique_id)
  • Then anytime you get your first response you do a GetVar
  • Then you have the ability to associated the uniqueID with your my_uniqueID

Also, if your ‘mapi_id’ is not there, then you know to ignore all events to that uniqueID as you did not originate.
[/quote]
Sure, you can do it. Channel var is attached to channels and you can use it. Alternatevily you can use channel name. It is easy.

[quote=“Slav”][quote]Does anyone see an issue with this scenario?:

  • Tag any new originate with a seperate unique ID as a variable, something like: mapi_id=(my_unique_id)
  • Then anytime you get your first response you do a GetVar
  • Then you have the ability to associated the uniqueID with your my_uniqueID

Also, if your ‘mapi_id’ is not there, then you know to ignore all events to that uniqueID as you did not originate.
[/quote]
Sure, you can do it. Channel var is attached to channels and you can use it. Alternatevily you can use channel name. It is easy.[/quote]

How does one use channel name if they are launching calls to the same channel, such as a ‘Local’ channel?

Originating calls with a Local/ channel is tricky if you want to track them. A Local channel can create 2 fake channels each with unique IDs that will then drop off if the call connects to a real channel(like a Zap/SIP/IAX channel) which will themselves have new UnqueIDs.

As for Identifying them by channel variables, I believe that inheritence of channel variables has come a long way in the 1.2 tree I’m not sure if channel variable inheritence from Local channels to their Real channels works in all cases.

We handled this in the astGUIclient/VICIDIAL project by using the only method available at the time, giving a unique Call ID to the CallerIDName field, which in the 1.0 tree is the only user-defined field that would follow all call channel legs throughout the life of a call. Once we abandon 1.0 tree compatibility we will take a look at channel variables again, so it would be good to hear from you how it works for you.

I’m also working on Asterisk Manager and i have the same problem as you…

mflorell: you use callerid field. If you send Originate command, the events matching to “exten number” won’t have the callerid field that you defined. The callerid will only match to the phone of “Channel field” (first phone which rings). Then you can’t really have all the events matching to your call.

So, I don’t know what to do. What is the best solution for you ?

CallerIdName does work to track events of channels involved with a call, but yes it is a bit tricky if you want all events. What you have to do is watch all events to see when your Originated CallerIDName shows up, At that event it will be tied to a UniqueID. From there you can track that UniqueID through all of it’s events. if another NewState or some other channel changing even happens you may see another UniqueID show up and then you will need to watch that one for all of it’s events. Any way you look at it there is nothing to use if you want to see every event for an Originated channel you have to follow the UniqueIDs, but that is possible with CallerIDname because there will always be an initial declaration of CallerIDName with UniqueIDs, usually when they are first Originated.

This is how we have been tracking calls for the last 3 years inside of astGUIclient/VICIDIAL and it works across all version of Asterisk so I know it does work, it just took a while to figure it all out.

I even wrote up a whitepaper 2 years ago about this very topic, but none of the Core developers thought it worthy of time to pursue:
freedomphones.net/Manager_AP … epaper.txt

Something that I notice :

When you put an integer value in callerID field (in the Originate Action), you get this value in the callerID field of the events. But if you put a string value, the value appears in callerIDName field of events…

It would be better if we could use callerID and callerIDName fields in the Originate Action.

You can, you just have to send callerid properly formatted:

“CALLERIDNAMEX” <3125551212>

Will set both the calleridname and calleridnum.

[quote=“mflorell”]You can, you just have to send callerid properly formatted:

“CALLERIDNAMEX” <3125551212>

Will set both the calleridname and calleridnum.[/quote]

Thank you. It’s good !

There is a big problem with Events. When you send Originate action, you receive Events only after pick up the phone (or after the timeout) !

So you can’t check if the phone is ringing, busy, or disconnected…

[quote=“aurelius”]There is a big problem with Events. When you send Originate action, you receive Events only after pick up the phone (or after the timeout) !

So you can’t check if the phone is ringing, busy, or disconnected…[/quote]

I solved the problem with Parameter : Async

Hi,

I ve a big problem with the Manager.
When I have many clients (3 clients or more) connected to the Manager, it seems that they doesn’t receive all events, and events received are not the sames between them.

With 2 clients no problem.

Soemone has ever had this problem ???

Yep, it’s much better to just have a single central listening app on the server that will keep track of Manager events. More connections from each client will slow down the output and the server and stuff will get droppedif it is trying to listen to everything.

MATT—

[quote=“mflorell”]Yep, it’s much better to just have a single central listening app on the server that will keep track of Manager events. More connections from each client will slow down the output and the server and stuff will get droppedif it is trying to listen to everything.

MATT—[/quote]

Matt, from your experience can you tell about the scalability of such single manager API proxy - how many “simultaneous” calls can it handle in real time?

Specifically, I need several hundred simultaneous requests to manager API on one asterisk with reasonable response time. Is this achievable?

What is the situation with manager API stability in asterisk now? What is better - to have just one connection or maybe a pool of few (maybe up to 10) connections?

The manager doesn’t really work by number of consecutive calls. I am assuming that you want to do something like initiate 500 calls at the same time, and if your Asterisk system can handle that many calls, the manager is certainly capable of initiating 500 calls in about 5-15 seconds. As for monitoring the state of all of them, that is possible too depending on how much output you are looking for.

We limit our systems to 100 calls at once and our Manager API apps work just fine with that. I would recommend a single app over 10 apps, that just makes your Asterisk server work harder.