https://origsvn.digium.com/svn/asterisk/trunk
................
r116039 | russell | 2008-05-13 16:18:55 -0500 (Tue, 13 May 2008) | 32 lines
Merged revisions 116038 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r116038 | russell | 2008-05-13 16:17:23 -0500 (Tue, 13 May 2008) | 24 lines
Fix a deadlock involving channel autoservice and chan_local that was debugged
and fixed by mmichelson and me.
We observed a system that had a bunch of threads stuck in ast_autoservice_stop().
The reason these threads were waiting around is because this function waits to
ensure that the channel list in the autoservice thread gets rebuilt before the
stop() function returns. However, the autoservice thread was also locked, so
the autoservice channel list was never getting rebuilt.
The autoservice thread was stuck waiting for the channel lock on a local channel.
However, the local channel was locked by a thread that was stuck in the autoservice
stop function.
It turned out that the issue came down to the local_queue_frame() function in
chan_local. This function assumed that one of the channels passed in as an
argument was locked when called. However, that was not always the case. There
were multiple cases in which this channel was not locked when the function was
called. We fixed up chan_local to indicate to this function whether this channel
was locked or not. The previous assumption had caused local_queue_frame() to
improperly return with the channel locked, where it would then never get unlocked.
(closes issue #12584)
(related to issue #12603)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@116040 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r115566 | russell | 2008-05-08 14:17:04 -0500 (Thu, 08 May 2008) | 41 lines
Merged revisions 115565 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r115565 | russell | 2008-05-08 14:15:25 -0500 (Thu, 08 May 2008) | 33 lines
Merged revisions 115564 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r115564 | russell | 2008-05-08 14:14:04 -0500 (Thu, 08 May 2008) | 25 lines
Fix a race condition that bbryant just found while doing some IAX2 testing.
He was running Asterisk trunk running IAX2 calls through a few Asterisk boxes,
however, the audio was extremely choppy. We looked at a packet trace and saw
a storm of INVAL and VNAK frames being sent from one box to another.
It turned out that what had happened was that one box tried to send a CONTROL
frame before the 3 way handshake had completed. So, that frame did not include
the destination call number, because it didn't have it yet. Part of our recent
work for security issues included an additional check to ensure that frames that
are supposed to include the destination call number have the correct one. This
caused the frame to be rejected with an INVAL. The frame would get retransmitted
for forever, rejected every time ...
This race condition exists in all versions that got the security changes,
in theory. However, it is really only likely that this would cause a problem in
Asterisk trunk. There was a control frame being sent (SRCUPDATE) at the _very_
beginning of the call, which does not exist in 1.2 or 1.4. However, I am fixing
all versions that could potentially be affected by the introduced race condition.
These changes are what bbryant and I came up with to fix the issue. Instead of
simply dropping control frames that get sent before the handshake is complete,
the code attempts to wait a little while, since in most cases, the handshake
will complete very quickly. If it doesn't complete after yielding for a little
while, then the frame gets dropped.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@115567 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r115305 | russell | 2008-05-05 14:50:24 -0500 (Mon, 05 May 2008) | 13 lines
Merged revisions 115304 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r115304 | russell | 2008-05-05 14:49:25 -0500 (Mon, 05 May 2008) | 5 lines
Avoid putting opaque="" in Digest authentication. This patch came from switchvox.
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.6.0@115306 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r114922 | qwell | 2008-05-01 11:49:24 -0500 (Thu, 01 May 2008) | 10 lines
Allow dringXrange to properly default to 10, as was done in 1.4.
dringXrange is a new feature that was added, and it attempted to default, but only when the option was specified.
(closes issue #12536)
Reported by: bjm
Patches:
12536-dringXrange.diff uploaded by qwell (license 4)
Tested by: bjm
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114923 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r114892 | russell | 2008-04-30 11:34:24 -0500 (Wed, 30 Apr 2008) | 36 lines
Merged revisions 114891 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114891 | russell | 2008-04-30 11:30:01 -0500 (Wed, 30 Apr 2008) | 28 lines
Merge changes from team/russell/iax2_find_callno and iax2_find_callno_1.4
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.6.0@114893 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r114884 | kpfleming | 2008-04-30 09:49:51 -0500 (Wed, 30 Apr 2008) | 10 lines
Merged revisions 114880 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114880 | kpfleming | 2008-04-30 09:46:57 -0500 (Wed, 30 Apr 2008) | 2 lines
use the ARRAY_LEN macro for indexing through the iaxs/iaxsl arrays so that the size of the arrays can be adjusted in one place, and change the size of the arrays from 32768 calls to 2048 calls when LOW_MEMORY is defined
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114886 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r114866 | jpeeler | 2008-04-29 17:54:14 -0500 (Tue, 29 Apr 2008) | 2 lines
Fixes a problem where all the templates were marked as dead no matter what. The templates should only be marked as dead if a configuration file has been successfully loaded and has changes. Bug found while making API documentation for 1.6.0.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114867 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
Merged to 1.6 because it fixes a crash.
........
r114700 | mvanbaak | 2008-04-27 17:17:18 +0200 (Sun, 27 Apr 2008) | 8 lines
Make MWI in chan_skinny event based modeled after chan_zap and chan_mgcp.
(closes issue #12214)
Reported by: DEA
Patches:
chan_skinny-vm-events-v3.txt uploaded by DEA (license 3)
Tested by: DEA and me
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114701 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r114633 | mmichelson | 2008-04-24 16:35:39 -0500 (Thu, 24 Apr 2008) | 19 lines
Merged revisions 114632 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114632 | mmichelson | 2008-04-24 16:35:08 -0500 (Thu, 24 Apr 2008) | 11 lines
Re-invite RTP during a masquerade so that, for instance, an AMI
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.6.0@114634 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r114612 | qwell | 2008-04-24 11:47:01 -0500 (Thu, 24 Apr 2008) | 17 lines
Merged revisions 51989 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
(closes issue #12496)
Reported by: daniele
Patches:
misdn-moh-1.6.0-beta7.1.patch uploaded by daniele (license 471)
Tested by: daniele
Technically, I didn't use the patch above except to find out what revision to merge - but it's the same thing as this revision.
........
r51989 | crichter | 2007-01-24 06:57:22 -0600 (Wed, 24 Jan 2007) | 1 line
added fix from #8899
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114613 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r114538 | russell | 2008-04-22 13:04:39 -0500 (Tue, 22 Apr 2008) | 17 lines
Merged revisions 114537 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114537 | russell | 2008-04-22 13:03:33 -0500 (Tue, 22 Apr 2008) | 9 lines
If the dial string passed to the call channel callback does not indicate an
extension, then consider the extension on the channel before falling back
to the default.
(closes issue #12479)
Reported by: darren1713
Patches:
exten_dial_fix_chan_iax2.c.patch uploaded by darren1713 (license 116)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114539 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r114185 | kpfleming | 2008-04-16 15:47:30 -0500 (Wed, 16 Apr 2008) | 14 lines
Merged revisions 114184 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114184 | kpfleming | 2008-04-16 15:46:38 -0500 (Wed, 16 Apr 2008) | 6 lines
use the ZT_SET_DIALPARAMS ioctl properly by initializing the structure to all zeroes in case it contains fields that we don't write values into (which it does as of Zaptel 1.4.10)
(closes issue #12456)
Reported by: fnordian
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114186 65c4cc65-6c06-0410-ace0-fbb531ad65f3
