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

[Joshua Colp]

Matthew Jordan wrote:
>

<snip>

>
> It's important to point out that optimization's goal was never the
> removal of the channel. If anything, nuking Local channels has - in
> my opinion - always made life more difficult for everyone, not
> easier.
>
> The goal was performance - minimize the frame path. If I'm picturing
>  this correctly, this doesn't *quite* optimize as efficiently as
> completely removing the Local channels - but it may still be
> sufficient.
>
> Real-01       Local-02;1         Local-02;2         Real-03 ------>
> <-------------> <------------> <------- \   /               \  /
> \  / -B0-               -NLB-             -B1- Real-03
> Real-01
>
> In this case - and this is assuming I understand the proposed Native
>  Local Bridge correctly! - Local-02;1 has as its actual destination
> target Real-03, while Local-02;2 has as it actual destination
> Real-01. When B0 pushes a frame to Local-02;1, Local-02;1 knows that
> it should just pass it on to its destination. Rather than passing to
> its bridge, it writes directly to Real-03. The same happens in
> reverse for Real-03 to Local-02;2.

As it is right now this approach can't optimize a bridged scenario above 
but I'm not sure that's a bad thing. While having a goal of optimizing 
things as much as possible is good in this scenario that's costing us a 
lot of complex code (with issues) and also requiring outside consumers 
to understand what can happen. I'd personally like to see Local channels 
become a connection between things instead of channels that can 
transmogrify, morph, and disappear. It makes both of our lives easier. 
To outside consumers they become "these channels have the same semantics 
as other channels but are implemented as a connection, and a single 
event will be produced which shows you how they are connected".

As for your diagram no NLB would be present there because a bridge does 
not exist within chan_local. Making it use the bridging framework would 
require rewriting it, as it can not work within the confines of what 
bridging requires (ie: you can't have a channel doing two things at once).

Where the NLB would be in use is this:

Real-01 (B1) <-> Local-02;1 <-> Local-02;2 (B2) <-> Local-03;1 <-> 
Local-03;2 (B3) <-> Real-02

In this case B2 would be an NLB and optimize things so media coming from 
Real-01 would be queued onto Local-03;2 for reading by B3 and media 
coming from Real-02 would be queued onto Local-02;1 for reading by B1. 
This bypasses Local-02;2 and Local-03;1 in the middle.

This works no matter what each far end is doing.

The reason optimizing your example is hard is because frames have to 
come from a channel within the bridge and pass through it.

>
> Creating a chain of these works by the real 'endpoints' getting
> passed down the chain of Local channels via control frames.
>
> There's two issues I can see with this - one minor, one maybe not.
> (1) There's a small amount of work here that occurs by the Local
> channel passing the frame on to its destination channel. It's minor,
> but it would be slightly more work than what occurs during today's
> optimization. (2) More seriously: I wonder if the destination
> shouldn't be a channel but a bridge. The above optimization cannot
> work for multi-party bridges: there is no single channel destination.
> Today's optimization does work in that scenario via a bridge swap -
> the single party on one end gets swapped with the Local channel in
> the multi-party bridge. This really is a minor case - the idea of
> optimizing channels into multi-party bridges is admittedly
> ridiculously new - but it may be useful to think through this use
> case.

Yes, as it is right now this doesn't optimize as much as the code that 
currently exists. I can say though that now when any video and audio 
frame go through a Local channel they no longer attempt to optimize out. 
(Yes, every 20ms pretty much the code attempts to do the optimization).

<snip>

>
> I would think you'd need it if you had a hook that needed the audio
> on that Local channel - such as a MixMonitor.

The NLB compatibility code actually checks whether something like a 
MixMonitor is on either Local channel and won't allow it to be used.

Now that I've given a diagram to show where things optimize and how it 
isn't inside of chan_local... what do you think NOW? ;)

-- 
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