[asterisk-dev] Out-of-order events from AMI interface - to be expected, or a bug?

[Alex Villací­s Lasso]

I am currently the main developer of the Elastix Call Center (a system 
to set up a call center running on top of Elastix). I have a problem 
with a specific version of Asterisk (1.4.26.1 through 1.4.28), and I 
need to know whether my program or Asterisk is at fault.

In one mode of operation of the program ("Outgoing Calls"), a daemon 
reads call records from the database, and originates calls using the AMI 
interface as in the following code:
                 $resultado = $this->_astConn->Originate(
                     $sCanalTrunk, $infoCampania->queue, 
$infoCampania->context, 1,
                     NULL, NULL, NULL,
                     (isset($datosTrunk['CID']) ? $datosTrunk['CID'] : 
NULL),
                     
"ID_CAMPAIGN={$infoCampania->id}|ID_CALL={$tupla->id}|NUMBER={$tupla->phone}|QUEUE={$infoCampania->queue}|CONTEXT={$infoCampania->context}",
                     NULL,
                     TRUE, $sKey);

channel: $sCanalTrunk is a PHP string that contains a value such as 
"SIP/SomeTrunk/1234567" or "Local/7777 at from-internal"
extension: $infoCampania->queue is the number of a queue on which agents 
like "Agent/1234" log in
context: $infoCampania->context usually has the value "from-internal"
priority: always set to 1
async: always set to TRUE
actionid: $sKey is a computed ID that is looked for in the 
OriginateResponse event to relate the event with the call record.

The code for this daemon installs event handlers for the following 
events: OriginateResponse, Join, Link, Unlink, Hangup. The code is 
written on the assumption that a successful call origination will 
generate the following events in this order: OriginateResponse, Join, 
(Link, Unlink) (one or more times), Hangup. In particular, the code 
expects OriginateResponse to precede all other events for the generated 
call, since it is the one that provides the Uniqueid value that allows 
the code to track the call through all of the other events. The code 
tracks the Link event to record which queue agent was assigned the 
generated call.

On the previously mentioned Asterisk versions, I am getting an 
unexpected situation, when using "Local/XXXX at from-internal" as a 
channel. I am getting the first Link event for the call *before* the 
corresponding OriginateResponse event. Since this OriginateResponse 
event is the one that contains the Uniqueid for the actionid the code 
specified, the Link event is ignored, and this results in the code being 
unable to track the agent that is handling the call. I have observed 
that when pressing a digit in the SIP phone keypad, Asterisk generates a 
pair of Unlink, Link events that make the daemon code aware that a call 
is being handled.

The worrying thing about this is that this does not occur with all calls 
that use "Local/XXXX at from-internal" as a channel. It only occurs in 
about one of every three calls. If this behavior occurred on every 
single call, I would think this is a special case. But this inconsistent 
behavior makes me think this is an Asterisk bug.

So, I have the following questions:
Is there any guarantee on the order of events associated with a 
generated call?
Are there any special cases that I need to know about the event order?
Is it correct for a external AMI client to depend on a particular event 
order?