<div class="gmail_quote">On Wed, Mar 3, 2010 at 7:50 AM, Jared Smith <span dir="ltr"><<a href="mailto:jsmith@digium.com">jsmith@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Tue, 2010-03-02 at 21:18 -0600, Tim Ringenbach wrote:<br>
<br>
<div class="im">
> 1. I've heard the complaint that IAX2 suffers on the performance front<br>
> because of it's use of a single port for singling and audio.<br>
<br>
</div>Changing the IAX protocol to use different ports for signaling and audio<br>
would break one of the fundamental advantages of the IAX protocol, in<br>
that it does a much better job of traversing NAT firewalls because of<br>
this design. I'm not saying the performance can't be improved, I'm just<br>
saying that splitting the media out to a different port probably isn't<br>
the best way.<br></blockquote><div><br>You don't have to break the great NAT transversal to implement that though. You could start out with one part and negotiate switching the media to a second one. Media flows on the signaling port until you handshake on the media port, and if you never succeed, then nothing different happens.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> 2. Eliminate channel masquerades and come up with some better way to<br>
> handle the need for them.<br>
<br>
</div>There's a new bridging API in Asterisk 1.6.2 and later which already<br>
addresses this concern. There's still a lot of work to be done to start<br>
moving apps over to the new API, but from what (little) I understand,<br>
the hardest part has already been done.<br></blockquote><div><br>Cool, I wasn't aware of that. I heard something about a new bridging API but I didn't understand it's purpose. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> 3. Run a tool like helgrind or ThreadSanitizer on asterisk and fix all<br>
> the errors, add unit tests so they don't come back, etc. Some of those<br>
> tools need annotations in the source to flag false positives, so add<br>
> those too.<br>
<br>
</div>There are a lot of tools we *could* run against Asterisk... in my own<br>
spare time last last fall I experimented with the clang analyzer<br>
utility. While it pointed out a fair number of places where we could<br>
improve the code, it also pointed out a lot of false positives, and so<br>
we have to weigh the benefits of taking a developer's time to analyze<br>
each one vs. the other things they could be doing.<br>
<br>
Unfortunately, I don't think that a student would be in the best<br>
position to know which of the items are serious concerns and which are<br>
false positives, as it takes a pretty robust understanding of the<br>
Asterisk code. Maybe there is some low hanging fruit that can be done<br>
by a student over the summer, and he can highlight places that require<br>
more in-depth analysis by an experienced developer?<br>
<font color="#888888"><br>
</font></blockquote></div><br>That's a good point.<br>