<html>
 <body>
  <div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
   <table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
    <tr>
     <td>
      This is an automatically generated e-mail. To reply, visit:
      <a href="https://reviewboard.asterisk.org/r/2799/">https://reviewboard.asterisk.org/r/2799/</a>
     </td>
    </tr>
   </table>
   <br />





<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
 <p style="margin-top: 0;">On September 3rd, 2013, 6:34 p.m. UTC, <b>jrose</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I tried running this test a few times with this patch in place after observing that in the disconnect test, LINKEDID_END events could occur on either channel. It ended up failing every time due to pretty much the same reason. LINKEDID_END events were able to come in on either channel. Sometimes they would hit Bob twice, sometimes they would hit Alice twice, sometimes they would hit Alice then Bob and sometimes Bob then Alice. I&#39;m not sure this was intended, but I was able to accomodate this variance in the disconnect test by pulling out the LINKEDID_END events and putting them into a separate CEL type which matched against LINKEDID_END instead of the channel name and simply had a LINKEDID_END with an ID for each phase of the test.</pre>
 </blockquote>




 <p>On September 3rd, 2013, 6:36 p.m. UTC, <b>jrose</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Oh, and now I&#39;ve seen it pass a couple times... which happens when the LINKEDID_END events come in on the channels expected by the test.</pre>
 </blockquote>








</blockquote>

<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I&#39;m just going to remove checking for that event. If it isn&#39;t deterministic, it is a little hard to check for.</pre>
<br />










<p>- Matt</p>


<br />
<p>On August 28th, 2013, 3:34 p.m. UTC, Matt Jordan wrote:</p>








<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/static/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
 <tr>
  <td>

<div>Review request for Asterisk Developers.</div>
<div>By Matt Jordan.</div>


<p style="color: grey;"><i>Updated Aug. 28, 2013, 3:34 p.m.</i></p>







<div style="margin-top: 1.5em;">
 <b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>


 <a href="https://issues.asterisk.org/jira/browse/ASTERISK-22323">ASTERISK-22323</a>


</div>



<div style="margin-top: 1.5em;">
 <b style="color: #575012; font-size: 10pt;">Repository: </b>
testsuite
</div>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
 <table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">This patch does a few things.

1) It updates the simple_bridge test for Asterisk 12, such that it handles the correct AMI events, CDR entries, and CEL events.
2) It adds a tool (and I emphasize it as a tool to aid in development) that will snoop CEL AMI events and dump them out in YAML. I found this to be helpful when producing the expected CEL events for this test; it may help others as well.
3) It updates and simplifies the CEL parsing. More on that below.

-- CEL PARSING --

For a single channel, the CEL events related to that channel should always have a well-defined ordering. That is, for a given test, a channel should always transition through the same states in the same order, e.g.,
  CHAN_START
  APP_START
  BRIDGE_ENTER
  BRIDGE_EXIT
  APP_END
  HANGUP
  CHAN_END

CEL gets tricky, however, because in addition to verifying that the events for a single channel occurred in the correct order, we also care whether or not events across channels occurred in the correct order.

For example, take this test, where Alice calls Bob. The events for each channel may look something like this (simplified greatly):

  Alice                   Bob
 -------               ---------
  CHAN_START           CHAN_START
  APP_START            ANSWER
  ANSWER               BRIDGE_ENTER
  BRIDGE_ENTER         BRIDGE_EXIT
  BRIDGE_EXIT          HANGUP
  APP_END              CHAN_END
  HANGUP
  CHAN_END

Because Alice and Bob will be executing on separate threads, a total ordering of all events is impossible to verify. The notion that such an ordering was ever possible led to the downfall of the original CEL checking. The existing CEL checking handles this, but requires identifying all events and establishing more relationships than is strictly necessary. In reality, what we want to verify between Alice and Bob is closer to the following:

  Alice                   Bob
 -------               ---------
  CHAN_START           
  APP_START            
                       CHAN_START    (verify that Bob starts after Alice&#39;s application start)
                       ANSWER
  ANSWER                             (verify that Alice answers after Bob answers)
  BRIDGE_ENTER         BRIDGE_ENTER  (verify that Bob enters the bridge after Alice answers)
  BRIDGE_EXIT          BRIDGE_EXIT
  APP_END
  CHAN_END             CHAN_END

So what we need are just three orderings between the channels:
 * Bob&#39;s CHAN_START must happen after Alice&#39;s APP_START
 * Alice&#39;s ANSWER must happen after Bob&#39;s ANSWER
 * Bob&#39;s BRIDGE_ENTER must happen after Alice&#39;s ANSWER

The CEL event checking now allows for this by letting an event be tagged with an identifier. Any other event can declare that they have a partial ordering with that event, and state that they must happen before or after that event. If they do not happen before or after that event, the test fails. However, unlike the previous implementation, we don&#39;t have to declare identifiers for all events, nor define an ordering for all events.</pre>
  </td>
 </tr>
</table>



<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">

 <li>/asterisk/trunk/tests/bridge/simple_bridge/test-config.yaml <span style="color: grey">(4090)</span></li>

 <li>/asterisk/trunk/lib/python/asterisk/cel.py <span style="color: grey">(4090)</span></li>

 <li>/asterisk/trunk/lib/python/asterisk/ami.py <span style="color: grey">(4090)</span></li>

</ul>

<p><a href="https://reviewboard.asterisk.org/r/2799/diff/" style="margin-left: 3em;">View Diff</a></p>







  </td>
 </tr>
</table>








  </div>
 </body>
</html>