AsyncAGI – How To Jump In Dial Plan When No Action Initiated On Channel Or AMI User Is Disconnected

Home » Asterisk Users » AsyncAGI – How To Jump In Dial Plan When No Action Initiated On Channel Or AMI User Is Disconnected
Asterisk Users 6 Comments

Hi

Is there any way to detect inactivity on channel when AsyncAGI is used?
I want to detect whether application handling calls using AMI & AGI has stopped responding.

Alternatively, how can dialplan check if there is any AMI user connected and decide dial plan execution?

Thanks & Regards, Amit Patkar

6 thoughts on - AsyncAGI – How To Jump In Dial Plan When No Action Initiated On Channel Or AMI User Is Disconnected

  • It means, AMI application is no more running or crashed or lost network connection with asterisk server. In such cases call is neither answered nor disconnected by Asterisk. I want to detect such state and jump to next dial plan to answer or reject the calls

    Regards Amit Patkar

  • No, there is no automatic coordination mechanism between AsyncAGI and AMI. In fact, AsyncAGI doesn’t know *which* AMI session is even managing the channels – it just waits for the appropriate AMI action to come across and signal something to the channels.

    Your external application would have to manage this process. A simple solution would be to use an AMI library that supports automatic reconnects. On a reconnect, ask Asterisk for the current channels; if any exist, handle their recovery either by determining their application state or by releasing them back to the dialplan.

  • Thanks Mathew. I understand that there is no coordination between AsyncAGI & AMI. Is there any dial plan function which can tell us if there is active AMI
    session?

    Thanks & Regards, Amit Patkar

  • Hi Amit,

    I’d some daemons that use AsyncAGI, but now, I use FastAGI again because:

    1. Asterisk must call the daemon via socket: the realibility of this socket indicates implicitly that the daemon is alive and answer.

    2. With FastAGI, it’s really easy to implement the multi-worker pattern with pre-fork socket like with a http server to distribute the load. With AsyncAGI, it needs more work and you have a spof with the dispatcher. In fact, with FastAGI, the dispatcher is the Linux kernel itself, less risks of bugs.

    My personal conclusion is: even if AsyncAGI is younger than FastAGI, it doesn’t seem that it’s always better in all situations 😉

    Have a nice week at Astricon.