[asterisk-dev] bridge_unreal: An alternative approach to Local/Unreal channel optimization

[Corey Farrell]

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.


On Tue, Mar 11, 2014 at 11:39 AM, Joshua Colp <jcolp at digium.com> wrote:

> Matthew Jordan wrote:
>
> <snip>
>
>
>
>> All of these scenarios are currently handled by core_unreal and
>> core_local in some fashion. It is, however, very complex code that -
>> particularly with Local channel chains - is prone to error. The
>> implementation today faces two problems:
>> (1) Knowledge of what is on the other side of the bridge is known by the
>> bridge, but not by either Local channel half. In order to get that
>> knowledge, both Local channel halves must take control of the bridge
>> (and all of its participants), then synchronize with each other.
>> (2) When multiple Local channels can optimize in a chain, they have to
>> communicate with each other (or at least compete with each other) to see
>> who optimizes out first. This can change the information that a Local
>> channel has about how it can optimize: for example, a Local channel may
>> view that it is in a two party bridge with another Local channel,
>> attempt to optimize, only to find out later that it is now in a
>> multi-party bridge with multiple Real channels.
>> (3) When optimization occurs, there can be *no* information in flight on
>> the Local channel. This is particularly difficult as the write queue
>> exists on the ast_channel struct - which means that the bridging layer
>> has to be informed to not write to the channel when the optimization
>> occurs. Again, more points of synchronization and locking.
>>
>> There's a few possible approaches that may simplify the implementation:
>>
>>   * Use approaches such as Josh's native Local bridge to move logic out
>> of core_unreal and core_local into bridge implementations. The bridges
>> actually have state now, and *know* who is in the bridge with them. A
>> bridge implementation could be written that handles a Local channel +
>> one other channel, and it could tell the Local channel when it can
>> optimize.
>>
>
> I ended up toying with a prototype[1] last night which does Local channel
> optimization using this approach.
>
> 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.
>
> [1] http://svn.digium.com/svn/asterisk/team/file/bridge_unreal_optimizer/
>
>
> --
> Joshua Colp
> Digium, Inc. | Senior Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> Check us out at: www.digium.com & www.asterisk.org
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140311/198bc50b/attachment.html>