asterisk

Commit Graph

Author	SHA1	Message	Date
David Vossel	6732590f86	Merge code associated with AST-2009-006 (closes issue #12912) Reported by: rathaus Tested by: tilghman, russell, dvossel, dbrooks git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.2@215958 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Sean Bright	84c5074ec3	Fix build errors on FreeBSD (uint -> unsigned int). (closes issue #14006) Reported by: alphaque Patches: astobj2.h-patch uploaded by alphaque (license 259) (Slightly modified by seanbright) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.2@161421 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Russell Bryant	f8d551bd2b	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. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.2@115296 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago

Author

SHA1

Message

Date

David Vossel

6732590f86

Merge code associated with AST-2009-006

(closes issue #12912)
Reported by: rathaus
Tested by: tilghman, russell, dvossel, dbrooks



git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.2@215958 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Sean Bright

84c5074ec3

Fix build errors on FreeBSD (uint -> unsigned int).

(closes issue #14006)
Reported by: alphaque
Patches:
      astobj2.h-patch uploaded by alphaque (license 259)
      (Slightly modified by seanbright)


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.2@161421 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Russell Bryant

f8d551bd2b

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.

git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.2@115296 65c4cc65-6c06-0410-ace0-fbb531ad65f3

3 Commits (1.2)