<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/2740/">https://reviewboard.asterisk.org/r/2740/</a>
     </td>
    </tr>
   </table>
   <br />



 <p>Ship it!</p>



 <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Looks good to me.  The ast_write() function has a default case where it does not check if the tech has a write routine before calling.</pre>
 <br />









<p>- rmudgett</p>


<br />
<p>On August 3rd, 2013, 7:05 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, David Lee, Joshua Colp, and Putnopvut.</div>
<div>By Matt Jordan.</div>


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









<div style="margin-top: 1.5em;">
 <b style="color: #575012; font-size: 10pt;">Repository: </b>
Asterisk
</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;">While working on cleaning up the bridge baseline test, I noticed a few troubling things:

* Surrogate channels, which exist only as a quick stand-in for a &#39;real&#39; channel so that the real channel can be moved into another thread, were leaking out into the outside world. This is a &quot;bad thing&quot;, as these channels only exist to be immediately hung up and are an implementation detail of Asterisk&#39;s internals.

* When we create a channel, we publish a *lot* of snapshots. This is due to a number of channel set routines that publish snapshots when their property changes - in general, this is a good thing (as we have specific events tied to the changing of account codes and AMA flags) and it reduces the burden on developers to &quot;know&quot; that if they change these properties they should publish an event. Before a channel is finished being allocated, however, is not a good thing - and the plethora of snapshots is wasteful.

* The Masquerade event somehow returned. I thought we killed it already.

This patch does the following:
(1) It provides a Surrogate channel technology with a consolidated &quot;implementation detail flag&quot; on the channel technology. This tells consumers of Stasis that the creation of this channel is an implementation detail in Asterisk and can be ignored (if they so choose). This consolidates the conference recorder/announcer flags as well - these flags had no additional meaning beyond &quot;ignore this channel please&quot;.

(2) It modifies allocation of a channel in two ways:
   (a) If a channel technology can be determined from the name, we set it directly in the allocation routine. This prevents the initial publication of the message from going out with a NULL channel technology where possible. This lets Stasis consumers get the right channel technology on the first publication.
   (b) It reorganizes allocation to make use of the &#39;finalized&#39; property on the channel. This was already used to know that a channel had completely finished its construction in the masquerade routine; now we also use it to know whether or not the setting of certain channel properties is occurring during or post construction. The various set routines were modified accordingly as well.

(3) The masquerade event is now dead, Jim. It no longer serves any purpose whatsoever - if you perform a call pickup you&#39;ll get a Pickup event; if you perform an attended transfer you will still get those events; if you steal a channel to put it elsewhere you&#39;ll get the corresponding NewExten or BridgeEnter events.
</pre>
  </td>
 </tr>
</table>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </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;">The bridge_baseline test is now producing sane output.</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>trunk/apps/confbridge/conf_chan_announce.c <span style="color: grey">(396109)</span></li>

 <li>trunk/apps/confbridge/conf_chan_record.c <span style="color: grey">(396109)</span></li>

 <li>trunk/channels/chan_bridge_media.c <span style="color: grey">(396109)</span></li>

 <li>trunk/include/asterisk/channel.h <span style="color: grey">(396109)</span></li>

 <li>trunk/main/cdr.c <span style="color: grey">(396109)</span></li>

 <li>trunk/main/cel.c <span style="color: grey">(396109)</span></li>

 <li>trunk/main/channel.c <span style="color: grey">(396109)</span></li>

 <li>trunk/main/channel_internal_api.c <span style="color: grey">(396109)</span></li>

 <li>trunk/main/manager_bridges.c <span style="color: grey">(396158)</span></li>

 <li>trunk/main/manager_channels.c <span style="color: grey">(396109)</span></li>

</ul>

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







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








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