<div dir="ltr"><div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 5, 2018 at 5:23 PM Seán C. McCord <<a href="mailto:ulexus@gmail.com">ulexus@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">As to the events should have a deterministic order or not, I cannot speak, but this is definitely normal behaviour.<div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 5, 2018 at 12:22 PM Jean Aunis <<a href="mailto:jean.aunis@prescom.fr" target="_blank">jean.aunis@prescom.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  

    
  
  <div bgcolor="#FFFFFF">
    <p>Hello,</p>
    <p>It looks like the ARI events ordering during channel destruction
      is not deterministic. I noticed this for ChannelLeftBridge and
      ChannelDestroyed events : given a channel is in a bridge and is
      hanged up, sometimes ChannelLeftBridge is raised before
      ChannelDestroyed, sometimes it's the contrary. Test conditions are
      exactly the same in both cases.<br>
    </p>
    <p>Is this non-deterministic behaviour normal, or should it be
      considered as a bug ?</p>
    <p>To my mind, ChannelDestroyed should always be the very last event
      raised for a given channel. From a developper point of view, it
      would give a clear indication that the resources associated to the
      channel can be freed.</p>
    <p>Regards<br clear="all"></p></div></blockquote></div></blockquote><div>The events regarding a Channel entering and leaving a Bridge are deterministic with respect to the Bridge's lifetime, but are not deterministic with respect to the Channel's lifetime. While it's a bit different, this is discussed somewhat on the AMI specification page:</div><div><br></div><div><a href="https://wiki.asterisk.org/wiki/display/AST/AMI+v2+Specification#AMIv2Specification-Bridging">https://wiki.asterisk.org/wiki/display/AST/AMI+v2+Specification#AMIv2Specification-Bridging</a></div><div><br></div><div>While AMI and ARI are two different APIs, both are built on top of a shared internal abstraction layer inside Asterisk that determines that event ordering. In the case of channels, channel event ordering is guaranteed when those events are published to what is known as the 'channel' topic for that channel. The act of entering / leaving a bridge is published to the bridge's topic, which is technically independent of the channel's topic. As such, the ordering of those events as they are presented to the AMI / ARI topics is not guaranteed.</div><div><br></div><div>An example can be seen in publishing the bridge leave message:</div><div><br></div><div>void ast_bridge_publish_leave(struct ast_bridge *bridge, struct ast_channel *chan)<br>{<br>    struct stasis_message *msg;<br><br>    if (ast_test_flag(&bridge->feature_flags, AST_BRIDGE_FLAG_INVISIBLE)) {<br>        return;<br>    }<br>    msg = ast_bridge_blob_create(ast_channel_left_bridge_type(), bridge, chan, NULL);<br>    if (!msg) {<br>        return;<br>    }<br><br>    /* state first, then leave blob (opposite of enter, preserves nesting of events) */<br>    bridge_publish_state_from_blob(bridge, stasis_message_data(msg));<br>    stasis_publish(ast_bridge_topic(bridge), msg);<br>    ao2_ref(msg, -1);<br>}<br></div><div><br></div><div>Note that we're publishing that message to the bridge topic - ast_bridge_topic(bridge) - as opposed to the channel topic (which would be ast_channel_topic(chan)). (To be pedantic, if you really wanted to preserve event ordering for both the bridge and the channel's respective lifetimes, you'd have to make a new aggregation topic for each channel / bridge and publish their messages to those aggregation topics, but that's a lot of overhead.)<br></div><div><br></div><div>You could argue that it *should* be ordered with respect to both the channel and bridge's lifetime, but generally enforcing that ordering imposes a penalty on the system, as it requires more synchronization. If someone went down that path, it'd require some careful testing to ensure it doesn't bog things down in some massive way.<br></div></div><br>-- <br><div dir="ltr" class="gmail_signature">Matthew Jordan<br>Digium, Inc. | CTO<br>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div></div></div></div>