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
........
r115537 | russell | 2008-05-07 16:11:33 -0500 (Wed, 07 May 2008) | 10 lines
Fix up a problem that was introduced into the scheduler when it was converted
to use doubly linked lists. The schedule() function had an optimization that
had it try to guess which direction would be better for the traversal to insert
the task into the scheduler queue. However, if the code chose the path where
it traversed the queue in reverse, and the result was that the task should be
at the head of the queue, then the code would actually put it at the tail,
instead.
(Problem found by bbryant, debugged and fixed by bbryant and me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@115538 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r115525 | tilghman | 2008-05-07 13:40:21 -0500 (Wed, 07 May 2008) | 2 lines
Don't free the object on destroy, as astobj2 takes care of that for you
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@115526 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r115329 | mmichelson | 2008-05-05 17:14:06 -0500 (Mon, 05 May 2008) | 15 lines
#execing the same file multiple times led to warning messages saying that the same file was
being #included twice. This was due to the fact that #exec created a temporary file which
was then #included. The name of the temporary file was the name of the #exec'd file, with
the Unix timestamp and thread ID concatenated. The issue was that if multiple #exec statements
of the same file were reached in the same second, then the result was that the temporary files
would have duplicate names. To resolve this, the temporary file now has microsecond resolution
for the timestamp portion.
(closes issue #12574)
Reported by: jmls
Patches:
12574.patch uploaded by putnopvut (license 60)
Tested by: jmls, putnopvut
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@115330 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r115324 | russell | 2008-05-05 17:01:56 -0500 (Mon, 05 May 2008) | 2 lines
Simplify code by using a taskprocessor for dispatching events in the Asterisk core.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@115326 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r115321 | mmichelson | 2008-05-05 16:43:21 -0500 (Mon, 05 May 2008) | 21 lines
Merged revisions 115320 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r115320 | mmichelson | 2008-05-05 16:41:34 -0500 (Mon, 05 May 2008) | 13 lines
Don't consider a caller "handled" until the caller is bridged with
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.6.0@115322 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
................
r115197 | mmichelson | 2008-05-02 09:28:55 -0500 (Fri, 02 May 2008) | 14 lines
Merged revisions 115196 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r115196 | mmichelson | 2008-05-02 09:28:19 -0500 (Fri, 02 May 2008) | 6 lines
Clarify a comment that was, well, just wrong. It turns out that
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.6.0@115198 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r115157 | tilghman | 2008-05-01 21:33:04 -0500 (Thu, 01 May 2008) | 2 lines
Add attributes to various API calls, to help track down bugs (and remove a deprecated function)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@115158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r115078 | bbryant | 2008-05-01 18:09:08 -0500 (Thu, 01 May 2008) | 2 lines
Add two new console commands "pri show version" and "ss7 show version" that will show the version of each library respectively.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@115079 65c4cc65-6c06-0410-ace0-fbb531ad65f3
