Summary:	ASTERISK-24404: When controlling inbound calls via AMI + async AGI, sometimes asterisk itself issues an EXEC Congestion command
Reporter:	Gabriel Gayan (ggayan)	Labels:
Date Opened:	2014-10-09 10:50:48	Date Closed:	2014-10-09 12:36:19
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Resources/res_agi
Versions:	11.13.0	Frequency of Occurrence	Occasional
Related Issues:
Environment:	- Ubuntu 14.04.1 x86_64 on VMware Fusion 7 - Adhearsion 2.5.4	Attachments:
Description:	From what I understand, when controlling a call via async AGI and AMI, the client application is the one that issues the commands and waits for a response. I am seeing in some inbound calls that Asterisk itself is issuing an "Exec Congestion", not being requested by the client application. Since the client app has not issued the command, it is not expecting such responses and it assumes that the call is running without any problem, so it  keeps issuing agi commands without receiving any response, thus waiting indefinitely until asterisk hangs up the call (in my case because of RTP inactivity timeouts). I extracted several logs for one of these calls: https://gist.github.com/ggayan/256204da1efce6a66ecc The default dialplan context is adhearsion and it is defined like this: [adhearsion] exten => _.,1,AGI(agi:async)
Comments:	By: Ben Klang (bklang) 2014-10-09 11:23:59.060-0500 Is there any chance that you have two Async AGI clients (two copies of Adhearsion) running? AsyncAGI provides no protection against multiple controllers attempting to handle the same call.  It would seem almost impossible to me that Asterisk would ever create a new AGI EXEC message by itself. By: Matt Jordan (mjordan) 2014-10-09 11:34:01.515-0500 Pretty much what [~bklang] said. :-) {{grep -r --include=*.c "EXEC Congestion" .}} yields nothing. By: Gabriel Gayan (ggayan) 2014-10-09 12:35:57.495-0500 It was indeed what Ben mentioned. Closing the issue.