[asterisk-dev] chan_sip -- improving the speed of sip reloads

Russell Bryant russell at digium.com
Wed Nov 21 12:18:31 CST 2007


Steve Murphy wrote:
> In the IAX2 implementation, really, there were only 2 places where the
> code iterates that concerned me, and that is in iax2_getpeername(), and
> iax2_getpeertrunk(). If these functions are (or could be) called
> frequently, a good alternative is to create another hashtable keyed by
> the ip/port info so these things can just be directly looked up instead
> of a linear search. I would think this whether iterators had a problem
> or not. If they are frequently called, I would go the hashtable route
> before I would change to a different method of iteration.

Both of these are called during each call setup.  I do agree that both of them
could benefit from the use of ao2_callback() instead of the ao2_iterator approach.

Speaking of chan_iax2 efficiency, another place that could drastically benefit
from the use of a hash table is the find_callno function.  If you take a look at
it, you'll see my rant on its problems.  To fix this, we need the IAX2 pvt
structures in a hash table keyed by the remote end's IP address and port number.

 * \todo XXX Note that this function contains a very expensive operation that
 * happens for *every* incoming media frame.  It iterates through every
 * possible call number, locking and unlocking each one, to try to match the
 * incoming frame to an active call.  Call numbers can be up to 2^15, 32768.
 * So, for an call with a local call number of 20000, every incoming audio
 * frame would require 20000 mutex lock and unlock operations.  Ouch.
 *
 * It's a shame that IAX2 media frames carry the source call number instead of
 * the destination call number.  If they did, this lookup wouldn't be needed.
 * However, it's too late to change that now.  Instead, we need to come up with
 * a better way of indexing active calls so that these frequent lookups are not
 * so expensive.

This is definitely one of, if not the most offending pieces of code in that
module.  We really need to fix it ...

-- 
Russell Bryant
Senior Software Engineer
Open Source Team Lead
Digium, Inc.



More information about the asterisk-dev mailing list