<div dir="ltr">My one concern is if we stop optimizing Local channels and allow the 
ast_channel to live for the duration of the call, this could 
significantly increase open FD's.  This would be a bigger issue for systems using res_timing_timerfd, since that causes alert pipe's to be created.<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 11, 2014 at 11:39 AM, Joshua Colp <span dir="ltr"><<a href="mailto:jcolp@digium.com" target="_blank">jcolp@digium.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Matthew Jordan wrote:<br>
<br>
<snip><div><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
All of these scenarios are currently handled by core_unreal and<br>
core_local in some fashion. It is, however, very complex code that -<br>
particularly with Local channel chains - is prone to error. The<br>
implementation today faces two problems:<br>
(1) Knowledge of what is on the other side of the bridge is known by the<br>
bridge, but not by either Local channel half. In order to get that<br>
knowledge, both Local channel halves must take control of the bridge<br>
(and all of its participants), then synchronize with each other.<br>
(2) When multiple Local channels can optimize in a chain, they have to<br>
communicate with each other (or at least compete with each other) to see<br>
who optimizes out first. This can change the information that a Local<br>
channel has about how it can optimize: for example, a Local channel may<br>
view that it is in a two party bridge with another Local channel,<br>
attempt to optimize, only to find out later that it is now in a<br>
multi-party bridge with multiple Real channels.<br>
(3) When optimization occurs, there can be *no* information in flight on<br>
the Local channel. This is particularly difficult as the write queue<br>
exists on the ast_channel struct - which means that the bridging layer<br>
has to be informed to not write to the channel when the optimization<br>
occurs. Again, more points of synchronization and locking.<br>
<br>
There's a few possible approaches that may simplify the implementation:<br>
<br>
  * Use approaches such as Josh's native Local bridge to move logic out<br>
of core_unreal and core_local into bridge implementations. The bridges<br>
actually have state now, and *know* who is in the bridge with them. A<br>
bridge implementation could be written that handles a Local channel +<br>
one other channel, and it could tell the Local channel when it can optimize.<br>
</blockquote>
<br></div></div>
I ended up toying with a prototype[1] last night which does Local channel optimization using this approach.<br>
<br>
It implements a native bridge technology which requires at least one Local channel to be present in the bridge. Once two channels have joined it stores the bridge and peer channel on each Local channel shared structure in the bridge. If the shared structure contains information about both sides of the Local channel it queues up a task with all of the bridges/channels to optimize. The task is executed in a serialized fashion using a taskprocessor and moves the respective channels around. If there is a chain of Local channels involved then multiple tasks are queued. Some may fail due to actions taken before they are executed, but another task will have already been queued to optimize once again. This happens until the entire chain is collapsed.<br>

<br>
[1] <a href="http://svn.digium.com/svn/asterisk/team/file/bridge_unreal_optimizer/" target="_blank">http://svn.digium.com/svn/<u></u>asterisk/team/file/bridge_<u></u>unreal_optimizer/</a><div class="HOEnZb"><div class="h5">
<br>
<br>
-- <br>
Joshua Colp<br>
Digium, Inc. | Senior Software Developer<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - US<br>
Check us out at: <a href="http://www.digium.com" target="_blank">www.digium.com</a> & <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a><br>
<br>
-- <br>
______________________________<u></u>______________________________<u></u>_________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
  <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/<u></u>mailman/listinfo/asterisk-dev</a><br>
</div></div></blockquote></div><br></div></div>