<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 10, 2014 at 6:59 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>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
<br>
<snip><div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It's important to point out that optimization's goal was never the<br>
removal of the channel. If anything, nuking Local channels has - in<br>
my opinion - always made life more difficult for everyone, not<br>
easier.<br>
<br>
The goal was performance - minimize the frame path. If I'm picturing<br>
this correctly, this doesn't *quite* optimize as efficiently as<br>
completely removing the Local channels - but it may still be<br>
sufficient.<br>
<br>
Real-01 Local-02;1 Local-02;2 Real-03 ------><br>
<-------------> <------------> <------- \ / \ /<br>
\ / -B0- -NLB- -B1- Real-03<br>
Real-01<br>
<br>
In this case - and this is assuming I understand the proposed Native<br>
Local Bridge correctly! - Local-02;1 has as its actual destination<br>
target Real-03, while Local-02;2 has as it actual destination<br>
Real-01. When B0 pushes a frame to Local-02;1, Local-02;1 knows that<br>
it should just pass it on to its destination. Rather than passing to<br>
its bridge, it writes directly to Real-03. The same happens in<br>
reverse for Real-03 to Local-02;2.<br>
</blockquote>
<br></div>
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".<br>
</blockquote><div><br></div><div>I don't disagree with that.<br><br></div><div>Optimization of Local channels is a complexity that is hard for us, and hard for users of Asterisk. It improves performance - but I'm not sure how much we improve it by is actually worth that pain.<br>
<br></div><div>When it was first written, people cared less about the guts of Asterisk, and operations internally were generally simpler. If this complexity is going to stick around, we have to find a way to manage it appropriately.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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).<br>
<br>
Where the NLB would be in use is this:<br>
<br>
Real-01 (B1) <-> Local-02;1 <-> Local-02;2 (B2) <-> Local-03;1 <-> Local-03;2 (B3) <-> Real-02<br>
<br>
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.<br>
<br>
This works no matter what each far end is doing.<br>
<br>
The reason optimizing your example is hard is because frames have to come from a channel within the bridge and pass through it.<div class=""><br></div></blockquote><div><br></div><div>Well, there are both good and bad things about this.<br>
<br>On the good side, AMI events that exist today won't change. Fewer breaking changes is good. Optimization begin/end events wouldn't occur, but the semantics of Local channels otherwise behaves the same.<br><br>
On the bad side, the simplest case is now the case that receives no improvements. You only get benefit from the Native Local Bridge if you have chains of Local channels - which I would imagine to be relatively rare in practice.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Creating a chain of these works by the real 'endpoints' getting<br>
passed down the chain of Local channels via control frames.<br>
<br>
There's two issues I can see with this - one minor, one maybe not.<br>
(1) There's a small amount of work here that occurs by the Local<br>
channel passing the frame on to its destination channel. It's minor,<br>
but it would be slightly more work than what occurs during today's<br>
optimization. (2) More seriously: I wonder if the destination<br>
shouldn't be a channel but a bridge. The above optimization cannot<br>
work for multi-party bridges: there is no single channel destination.<br>
Today's optimization does work in that scenario via a bridge swap -<br>
the single party on one end gets swapped with the Local channel in<br>
the multi-party bridge. This really is a minor case - the idea of<br>
optimizing channels into multi-party bridges is admittedly<br>
ridiculously new - but it may be useful to think through this use<br>
case.<br>
</blockquote>
<br></div>
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).<br>
</blockquote><div><br></div><div class="">Which, if it can't optimize, is a bunch of needless work.<br><br></div><div class="">Trade-offs!<br></div><div class=""><br> <br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I would think you'd need it if you had a hook that needed the audio<br>
on that Local channel - such as a MixMonitor.<br>
</blockquote>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The NLB compatibility code actually checks whether something like a MixMonitor is on either Local channel and won't allow it to be used.<br>
<br>
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? ;)<br clear="all"></blockquote><div><br></div><div>I think this proposal is tantamount to killing Local channel optimization. <br>
</div></div><br></div><div class="gmail_extra">I'm not sure that's a bad thing, but I'd certainly like to get more opinions.<br><br></div><div class="gmail_extra">-- <br><div dir="ltr"><div>Matthew Jordan<br></div>
<div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div><div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div>
</div>
</div></div>