a queue member. There was too much of an opportunity for the member
to hang up (either during a delay, announcement, or overly long
agi) between the time that he answered the phone and the time when
he actually was bridged with the caller. The consequence of this
was that if the member hung up in that interval, then proper
abandonment details would not be noted in the queue log if the caller
were to hang up at any point after the member hangup.
(closes issue #12561)
Reported by: ablackthorn
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@115320 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It fixes authentication with Primus in Canada, and has been in use for a very long
time without causing problems with any other providers.
(closes issue AST-36)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@115304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r115296 | russell | 2008-05-05 12:53:26 -0500 (Mon, 05 May 2008) | 28 lines
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.4@115297 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ignoring the way that macros expand. Instead, I have clarified in the
comment why the macro will work even if the scheduler id for the
task to be deleted changes during the execution of the macro.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@115196 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@114891 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and macroexten fields. This is needed because if macros are daisy-chained, the incorrect
context and extension are placed on the new channel. I also added locking to the channel prior
to accessing these variables as noted in trunk's janitor project file.
(closes issue #12549)
Reported by: darren1713
Patches:
app_queue.c.macroextenpatch uploaded by darren1713 (license 116)
(with modifications from me)
Tested by: putnopvut
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@114848 65c4cc65-6c06-0410-ace0-fbb531ad65f3
may end up finding tds.h in /usr/local/include instead of /usr/include. If
this happens, the grep that looks for the version (from tdsver.h) will fail
and we'll have some problems during the build.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@114695 65c4cc65-6c06-0410-ace0-fbb531ad65f3
redirect of two channels which are natively bridged will preserve audio
on both channels. This prevents a problem with Asterisk not re-inviting
due to one of the channels having being a zombie.
(closes issue #12513)
Reported by: mneuhauser
Patches:
asterisk-1.4-114602_restore-RTP-on-fixup.patch uploaded by mneuhauser (license 425)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@114632 65c4cc65-6c06-0410-ace0-fbb531ad65f3
would only work if the mansession_id cookie was first. Now, the code builds
a list of all of the cookies in the Cookie header. This fixes a problem
observed by users of the Asterisk GUI.
(closes AST-20)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@114600 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also, remove setting the amount of time to wait for a digit from 5 seconds back
down to 1/10 of a second. I believe this was so the beep didn't get played over
and over really fast, but a while back I put in another fix for that issue.
(closes issue #12498)
Reported by: jsmith
Patches:
app_chanspy_channel_walk.trunk.patch uploaded by jsmith (license 15)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@114597 65c4cc65-6c06-0410-ace0-fbb531ad65f3
mansession_id cookie is coded to be limited to 8 characters of hex, and this
could break logins from 64-bit machines in some cases.
(inspired by AST-20)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@114591 65c4cc65-6c06-0410-ace0-fbb531ad65f3
