[asterisk-dev] invasive fixes to chan_iax2 in 1.4

[Loic Didelot]

Hello,
I now compared SIP against IAX performance on Russel's branch.

I flooded the server with registrations (900) with 1 ms in between.
During this process I try to launch a call, with SIP or IAX based on the
flooding I am doing. Asterisk answers the call and plays a sound file.

With SIP things are great. The call is connected really fast. With IAX
it is a whole other story. It takes a hell lof of time to get connected.
The IAX protocol is just not responsive

The number of channels "sip show channels" or "iax show channels" is
similar. Just to make sure both flood tools do approximately the same.

Now, I guess on IAX it is related how many threads I configure inside
iax.conf 

For now my settings are:
iaxthreadcount = 100
iaxmaxthreadcount = 150

I think the highes value possible is 512 which I tried but it did not
really improve the situation.

The setting of rtcachefriends in the config has no impact my my test
results.

Can anyone confirm those results? Compared to SIP it is at the moment
too easy to DOS IAX because of the poor performance. No fast internet
connection needed. Just a few UDP packages and IAX is down.

I do not say that this is different on some older iax implementations.
So I think the latest developments are some big improvements and should
be merged quite soon, depending on more test results.

Best regards,
Loic Didelot.



On Fri, 2007-08-17 at 16:20 -0400, Russell Bryant wrote:
> Greetings,
> 
> I have a branch where I have fixed some bugs in chan_iax2.  The code is intended
> to go in both 1.4 and trunk.  The changes are rather invasive, so I wanted to
> describe the changes and justify them before merging them in.
> 
> svn diff http://svn.digium.com/svn/asterisk/branches/1.4/channels/chan_iax2.c
> http://svn.digium.com/svn/asterisk/team/russell/iax_refcount/channels/chan_iax2.c
> 
> This branch is targeted at fixing a set of crashes.  They were brought to my
> immediate attention by being given access to a system that could be easily
> crashed by issuing a reload while running a registration load test.
> 
> The problems turned out to be related to the handling of iax2_peer objects.
> However, the handling of iax2_user objects suffers from the same problems so the
> same changes have been made to them, as well.  There are various situations
> where peers could get destroyed while other threads still hold references to them.
> 
> To fix this problem, I made it so the objects are reference counted.  To do
> this, I had 3 choices.
> 
> 1) Don't use any object model.  Just write it in "manually".  This felt like the
> worst choice.  It's best to use a common implementation when possible.
> 
> 2) Use astobj.h.  This hasn't made it very far throughout the code base.  The
> API is a set of macros which are cumbersome to use, and especially to debug, in
> my opinion.  However, it's certainly better than option #1, as it is a common
> implementation already in use in some places.  However, it is likely that this
> is going to be deprecated in favor of astobj2.
> 
> 3) Use astobj2.  Luigi Rizzo and one of his students, Marta Carbone, have
> written a new reference counted object model and have had it in a branch for a
> long time now.  After reviewing astobj versus astobj2, I perferred astobj2, and
> decided to go with that.  It doesn't use macros, and is still more efficient.
> 
> Another reason that I chose to go with astobj2 was that I *know* this is not the
> end of problems of this type.  In fact, there is a nice set of crashes on the
> bug tracker which the fix will be converting the ast_channel struct over to a
> reference counted object model, which is going to be a big job.  Since we are
> likely going to have to do more conversions of object handling to this method, I
> figured it was worth bringing in astobj2 to 1.4 so that we can use it as needed,
> and not do all of this work using a model that we know will be deprecated in the
> near future.
> 
> If you have any comments or objections, I would like to hear them.  Also, feel
> free to ask for any clarification or more detailed explanations of the things I
> have mentioned here.
> 
> If there are no objections, I will be merging these changes into 1.4 next week.
> 
-- 
Loic DIDELOT (CTO)
voipGATE S.A.
Tel: +352 20 200 223
Fax: +352 20 200 923
E-mail: ldidelot at voipgate.com
Web: http://www.voipgate.com