Manager interfac not returning status until call is answered


When I Originate over the AMI (Asterisk 1.4) I don’t see any state/event changes over the same socket until the call is actually answered - which makes it really hard to pull out uniqueid. This is the command I’m passing in:

Action: Login
UserName: baidkal
Secret: 2coools

Action: Events
EventMask: on

Action: Originate
Channel: IAX2/test/4479143....  <--- full phone number here
WaitTime: 0
Context: conferences
Exten: 123434
Priority: 1

At this point the phone starts ringing, the CLI shows the call going up, another screen I have with a telnet connection to :5038 shows the events flowing past, but ^^this screen just blocks until the call is actualy answered - at which point all the Newchannel and Event messages all pile in at the same time. Ultimately I want to drive AMI with some perl/IO, but it will fail to register the initial change in call status and the call’s uniqueid until I can find a fix to this problem.

I would be grateful if somebody could try telnetting to their port 5038 and stuffing anoriginate in to see if you get ‘State: Ringing’ back over the wire before picking up? However, be sure to watch the same connection - it seems to be fine on a secondary listening connection.

Thanks for any ideas,


[edit - typo in the subject line is really annoying me now]

Have you tried events: off ?

are you terminating the last line with \r\n\r\n ?

Yes, I have played with Events and Eventsmask, but still no events until the call answers. I’m hitting return at least twice to give “\r\n\r\n…”


I have updated the snipped above to show that I’m also enabling Events according to these docs

Meanwhile, ‘core show channels’ at the CLI shows:

baikal*CLI> core show channels
Channel              Location             State   Application(Data)
IAX2/test-2         (None)               Ringing (None)
1 active channel
0 active calls

So call progress is clearly known to Asterisk, but is failing to come back over the socket when expected.

Very weird!


christo - I don’t know if anyone here can defend the AMI but it seems from our testing that it’s not that reliable. We have been testing sending commands over sockets for .NET and it always seems to hang/timeout on getting a result back from that port.

Wondering if anyone else has experienced these sorts of problems with the AMI and remote access through sockets…?


Anybody else got any thoughts on this? I’m outta ideas! I have tried with the lastest sources off the digium svn repository and the same thing still happens. I have also played with ActionID and I could probably hack a fix using that, but I’m pretty sure that this would have broken a lot of applications which use asterisk’s AMI and it would be good to know if this is intentional, or a bug.


We have a C program that uses AMI to detect call hangup and we discovered it works much differently in 1.4.1 then it did in 1.2.x. And it seems a bit erratic. Doesn’t alwys do the same thing twice in a row. We see different numbers (one to many) of call hangup data in a single packet and not in the same order always. And with little to no documentation of 1.4.x it took the programmers a couple days of debugging to find the erratic behaviour.

I may not have explained it quite correctly since I am not the programmer.

Support guy