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 <jc...@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 >
-- _____________________________________________________________________ -- 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
