(fast) AGI and AMI synchronization ?

Home » Asterisk Users » (fast) AGI and AMI synchronization ?
Asterisk Users 2 Comments

Hi,

I’ve been developing some CTI software around asterisk for a while,
mainly with the help of AMI and fast AGI.
It works quite fine, but I have some trouble sometimes with the
un-synchronized property of these 2.
Let me explain, we have a dialplan like this one :

exten = s,n,UserEvent(useful_input_data)
(…) a few actions
exten = s,n,AGI(agi://127.0.0.1:3333/fetch,queuename)

The idea is to setup a “cti server” that talks with both AMI and AGI
channels, the first one mainly when one just want to send some data
from asterisk to the “cti server”, and the second one when the dialplan
needs some data from this server.

My issue is that the AGI requests are received (from the CTI server
point of vue) a little bit before the AMI events. In most cases, I don’t
really care because it is only “a little”, and the data asterisk needs
to fetch from the AGI are set on time. But sometimes not, especially in
cases like above, when there are only a few dialplan lines between
UserEvent and AGI …

In order to handle that, I thought “let’s make a sync/meeting point,
with the help of the AMI NewExten event, when the app is AGI”.
The idea would be to keep the AGI connection open as long as the good
AMI NewExten event is not received, then to reply and close it, in
order for the dialplan to proceed.
However, when trying to do this, nothing more occurs on the AMI
connection, thus I come to a deadlock …

My question is then, before switching to -dev issues : is there an option
somewhere to handle this, whether on the AMI or on the AGI side ?
The asterisk version we’ve been using for a long time is 1.4 and my
current attempts are done on 1.8 branch.

Thanks,

2 thoughts on - (fast) AGI and AMI synchronization ?

  • AMI is single threaded link so waiting on it will bring things to hang mode
    but FastAGI & dialplan is multithread. Better to manage all info by AMI in a
    local hash or array and use sleep/waiting on AGI till required info
    populated to hash/array by AMI.

  • OK, I found my problem.
    I don’t really know why I did not receive AMI events during the few tests
    I did, actually, but as for my original issue, the key point is that I use
    select() with fds instead of threads. In this case, the order in which the
    fds are put in the “fd set” matters. The AGI fd was prior to the AMI one,
    thus gave this asynchronous impression …
    Thanks for the answers, though.

    Corentin LE GALL
    Proformatique (Groupe Avencall) – 10bis rue Lucien Voilin – F-92800 Puteaux
    Tel (+33/0)1.41.38.99.60 – Fax (+33/0)1.41.38.99.70
    http://wiki.xivo.fr