[asterisk-dev] GSoC 2010 - Calling for Project Ideas and Mentors

[Tim Ringenbach]

On Wed, Mar 3, 2010 at 7:50 AM, Jared Smith <jsmith at digium.com> wrote:

> On Tue, 2010-03-02 at 21:18 -0600, Tim Ringenbach wrote:
>
>  > 1. I've heard the complaint that IAX2 suffers on the performance front
> > because of it's use of a single port for singling and audio.
>
> Changing the IAX protocol to use different ports for signaling and audio
> would break one of the fundamental advantages of the IAX protocol, in
> that it does a much better job of traversing NAT firewalls because of
> this design.  I'm not saying the performance can't be improved, I'm just
> saying that splitting the media out to a different port probably isn't
> the best way.
>

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.



>
> > 2. Eliminate channel masquerades and come up with some better way to
> > handle the need for them.
>
> There's a new bridging API in Asterisk 1.6.2 and later which already
> addresses this concern.  There's still a lot of work to be done to start
> moving apps over to the new API, but from what (little) I understand,
> the hardest part has already been done.
>

Cool, I wasn't aware of that. I heard something about a new bridging API but
I didn't understand it's purpose.

>
> > 3. Run a tool like helgrind or ThreadSanitizer on asterisk and fix all
> > the errors, add unit tests so they don't come back, etc. Some of those
> > tools need annotations in the source to flag false positives, so add
> > those too.
>
> There are a lot of tools we *could* run against Asterisk... in my own
> spare time last last fall I experimented with the clang analyzer
> utility.  While it pointed out a fair number of places where we could
> improve the code, it also pointed out a lot of false positives, and so
> we have to weigh the benefits of taking a developer's time to analyze
> each one vs. the other things they could be doing.
>
> Unfortunately, I don't think that a student would be in the best
> position to know which of the items are serious concerns and which are
> false positives, as it takes a pretty robust understanding of the
> Asterisk code.  Maybe there is some low hanging fruit that can be done
> by a student over the summer, and he can highlight places that require
> more in-depth analysis by an experienced developer?
>
>
That's a good point.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20100303/e695e4ea/attachment-0001.htm