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