[Home]

Summary:ASTERISK-24240: Asterisk disconnects AMI client intermittently (TCP FIN, PSH, ACK) after Action: Originate
Reporter:David Rees (AsteriskAndObelisk)Labels:
Date Opened:2014-08-16 22:50:27Date Closed:2014-08-17 16:03:35
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Core/ManagerInterface
Versions:11.6.0 Frequency of
Occurrence
Related
Issues:
Environment:uname: "Linux cust86 2.6.34.10-0.6-pae #1 SMP 2011-12-13 18:27:38 +0100 i686 i686 i386 GNU/Linux" Asterisk: Asterisk 11.6-cert4, Copyright (C) 1999 - 2013 Digium, Inc. and others.Attachments:
Description:I have a program which maintains a long-lasting connection to Asterisk's AMI service (TCP port 5038) and monitors events sent by Asterisk. My program will reconnect itself immediately after being disconnected from Asterisk.

My program also sends Action: Originate and also monitors the responses to those Actions.

Using Wireshark, I found that Asterisk disconnected my client program a few seconds after sending an Action: Originate, however this is not consistent - sometimes the connection is not broken, other times it is disconnected 3 times between Action: Originate and Event: Hangup.

Wireshark shows that Asterisk is sending TCP "FIN, PSH, ACK" or just "FIN, ACK" to my client program.

This is a major problem for me because call events would have been sent in the time-between being disconnected and reconnecting, for example I often miss "Event: Dial" events because they're sent during the time period when I'm reconnecting. Those Dial events convey important information about the state of the call that I cannot infer from elsewhere.

When I have 2 instances of my program open and only 1 instance sends the Action: Originate, then the other instance maintains its connection and is able to monitor all events. So clearly the disconnects are in response to the Action: Originate command.

My program periodically sends Action: Ping, and I have never encountered a disconnect in response to this.

I marked this as a regression as I did not experience this behavior with Asterisk 1.6.
Comments:By: Matt Jordan (mjordan) 2014-08-17 16:03:35.846-0500

AMI is most likely disconnecting the session due to a write timeout. This is not a bug, but a result of your application not responding to events fast enough on the thread that services the events.

You can increase the write timeout in manager.conf:

{noformat}
; If the device connected via this user accepts input slowly,
; the timeout for writes to it can be increased to keep it
; from being disconnected (value is in milliseconds)
;
; writetimeout = 100
{noformat}