Bug#482997: asterisk: Extremely choppy sound and high CPU usage

[Faidon Liambotis]

tags 482997 + confirmed
thanks

Torgeir Skjøtskift wrote:
> When making calls involving IAX2 channels, sound is extremely choppy
> and CPU usage spikes.
> 
> Messages on the CLI indicate problems while channels are active:
> WARNING[12301]: File chan_iax2.c, Line 4436 (socket_read): Received
> mini frame before first full voice frame
> 
> IAX2 registry entries become unregistered
> IAX2 peers become UNREACHABLE
> 
> This problem seems to be caused by the 2etch4 update, since it works
> fine in 2etch3 (see http://www.debian.org/security/2008/dsa-1563).
> 
> To replicate:
> Set asterisk console debug and verbose to 100
> SIP phones on machine A 
> via IAX2 trunk to machine B
> via IAX2 trunk back to meetme room on machine A
> 
> Creating 5-10 simultaneous calls should reveal the problem.
This is indeed a regression from the versions before the security fix.

upstream has fixed this with a commit[1] with the following description:
   Merge changes from team/russell/iax2_find_callno_1.2 These
   changes address a critical performance issue introduced in the
   latest release. The fix for the latest security issue included a
   change that made Asterisk randomly choose call numbers to make
   them more difficult to guess by attackers. However, due to some
   inefficient (this is by far, an understatement) code, when
   Asterisk chose high call numbers, chan_iax2 became unusable after
   just a small number of calls. On a small embedded platform, it
   would not be able to handle a single call. On my Intel Core 2 Duo
   @ 2.33 GHz, I couldn't run more than about 16 IAX2 channels.
   Ouch. These changes address some performance issues of the
   find_callno() function that have bothered me for a very long
   time. On every incoming media frame, it iterated through every
   possible call number trying to find a matching active call. This
   involved a mutex lock and unlock for each call number checked.
   So, if the random call number chosen was 20000, then every media
   frame would cause 20000 locks and unlocks. Previously, this
   problem was not as obvious since Asterisk always chose the lowest
   call number it could. A second container for IAX2 pvt structs has
   been added. It is an astobj2 hash table. When we know the remote
   side's call number, the pvt goes into the hash table with a hash
   value of the remote side's call number. Then, lookups for
   incoming media frames are a very fast hash lookup instead of an
   absolutely insane array traversal. In a quick test, I was able to
   get more than 3600% more IAX2 channels on my machine with these
   changes.
There is another regression[2] thas has been similarly fixed in 1.2.28.1.

It is, unfortunately, a huge commit, since it backports various stuff 
(astobj2) from 1.4.
But I don't see another option to be honest and neither did upstream -- 
and 1.2 is in their deep-freeze state, similar to our own (security 
fixes and grave bugs only).

security team, what do you think?
Should I prepare a new version with these changes and upload it to 
security-proposed-updates?

Regards,
Faidon

1: http://svn.digium.com/view/asterisk?view=rev&revision=115296
2: http://svn.digium.com/view/asterisk?view=rev&revision=115564