https://origsvn.digium.com/svn/asterisk/trunk
........
r113836 | mmichelson | 2008-04-09 12:48:33 -0500 (Wed, 09 Apr 2008) | 14 lines
There was a subtle logical difference between 1.4 and trunk with regards to how timeouts
were handled. In 1.4, if the absolute timeout were reached on a call, no matter what
the return value of ast_spawn_extension was, the pbx would attempt to go to the 'T'
extension or hangup otherwise. The rearrangement of this function in trunk made this check
only happen in the case that ast_spawn_extension returned 0. If ast_spawn_extension returned
1, then the fact that the timeout expired resulted in a no-op, and would cause an infinite
loop to occur in __ast_pbx_run. This change fixes this problem. Now timeouts will
behave as they did in 1.4
(closes issue #11550)
Reported by: pj
Tested by: putnopvut
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113837 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r113785 | file | 2008-04-09 13:52:04 -0300 (Wed, 09 Apr 2008) | 12 lines
Merged revisions 113784 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113784 | file | 2008-04-09 13:50:45 -0300 (Wed, 09 Apr 2008) | 4 lines
If we receive an AUTHREQ from the remote server and we are unable to reply (for example they have a secret configured, but we do not) then queue a hangup frame on the Asterisk channel. This will cause the channel to hangup and a HANGUP to be sent via IAX2 to the remote side which is the proper thing to do in this scenario.
(closes issue #12385)
Reported by: viraptor
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113786 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r113682 | mmichelson | 2008-04-09 09:41:58 -0500 (Wed, 09 Apr 2008) | 17 lines
Merged revisions 113681 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113681 | mmichelson | 2008-04-09 09:40:05 -0500 (Wed, 09 Apr 2008) | 9 lines
If Asterisk receives a 488 on an INVITE (not a reinvite), then
we should not send a BYE.
(closes issue #12392)
Reported by: fnordian
Patches:
chan_sip.patch uploaded by fnordian (license 110) with small modification from me
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113683 65c4cc65-6c06-0410-ace0-fbb531ad65f3
................
r113508 | mmichelson | 2008-04-08 14:09:16 -0500 (Tue, 08 Apr 2008) | 15 lines
Blocked revisions 113507 via svnmerge
........
r113507 | mmichelson | 2008-04-08 14:07:38 -0500 (Tue, 08 Apr 2008) | 8 lines
Fix potential buffer overflow that could happen if more than 100 announce files
were specified when calling ParkAndAnnounce. This overflow is not exploitable remotely
and so there is no need for a security advisory.
(closes issue #12386)
Reported by: davidw
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113509 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r113452 | qwell | 2008-04-08 12:32:42 -0500 (Tue, 08 Apr 2008) | 9 lines
Move AST_FEATURE_FLAG_* and FEATURE_RETURN_* to features.h so that they can be used by modules.
(closes issue #12384)
Reported by: fnordian
Patches:
features.patch uploaded by fnordian (license 110)
(patch modified by me, to give FEATURE_RETURN_* an AST_ prefix)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113453 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r112874 | murf | 2008-04-04 22:33:13 -0300 (Fri, 04 Apr 2008) | 15 lines
Found a little problem with the sip request handling that could lead to a quick crash of asterisk, and a road to a DOS attack if left unfixed.
Attaching to a running asterisk with "telnet hostname 5060", I would input "something", then hit return three times, and asterisk crashes.
I traced it to handle_request_do(), which zeroes out the data (an ast_str ptr) if the string is too short.
Instead of freeing the struct and nulling the pointer, it now just resets it, because this
ast_str is expected by the calling routine to still be there after handle_request_do() returns.
This appears to fix the crash. I assume that it was introduced with ast_str's being adopted. It's a subtle and easy-to-miss sort of problem.
I also found all the places where the req.data is freed, and made sure the ptr is Nulled out as well;
no good leaving bad ptrs laying around-- I didn't need to do this, but it seemed a good thing to do...
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113299 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r113297 | file | 2008-04-08 12:05:35 -0300 (Tue, 08 Apr 2008) | 12 lines
Merged revisions 113296 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113296 | file | 2008-04-08 12:03:43 -0300 (Tue, 08 Apr 2008) | 4 lines
If audio suddenly gets fed into one side of a channel after a lapse of frames flush the other factory so that old audio does not remain in the factory causing the sync code to not execute.
(closes issue #12296)
Reported by: jvandal
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113298 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r113241 | jpeeler | 2008-04-07 16:35:48 -0500 (Mon, 07 Apr 2008) | 23 lines
Merged revisions 113013 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
................
r113013 | jpeeler | 2008-04-07 10:18:10 -0500 (Mon, 07 Apr 2008) | 15 lines
Merged revisions 113012 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113012 | jpeeler | 2008-04-07 10:16:44 -0500 (Mon, 07 Apr 2008) | 7 lines
(closes issue #12362)
(closes issue #12372)
Reported by: vinsik
Tested by: tecnoxarxa
This one line change makes an if inside a for loop (in realtime_peer) check all the ast_variables the loop was intending to test rather than just the first one.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113242 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r113207 | mmichelson | 2008-04-07 15:22:06 -0500 (Mon, 07 Apr 2008) | 7 lines
This is a "fix" for something that's been bugging the crap out of me for a while.
The variable name "flag" to distinguish between whether a message is being forwarded or
is new is not a helpful name. The newly added doxygen documentation to app_voicemail is
tremendously helpful, but I still just...hate this variable name. I think is_new_message
is more indicative of what its purpose is.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113213 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r113066 | mmichelson | 2008-04-07 11:12:30 -0500 (Mon, 07 Apr 2008) | 21 lines
Merged revisions 113065 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113065 | mmichelson | 2008-04-07 11:08:45 -0500 (Mon, 07 Apr 2008) | 13 lines
This fix prevents a deadlock that was experienced in chan_local. There was
deadlock prevention in place in chan_local, but it would not work in a specific
case because the channel was recursively locked. By unlocking the channel prior
to calling the generator's generate callback in ast_read_generator_actions(), we
prevent the recursive locking, and therefore the deadlock.
(closes issue #12307)
Reported by: callguy
Patches:
12307.patch uploaded by putnopvut (license 60)
Tested by: callguy
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113067 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r113013 | jpeeler | 2008-04-07 10:18:10 -0500 (Mon, 07 Apr 2008) | 15 lines
Merged revisions 113012 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113012 | jpeeler | 2008-04-07 10:16:44 -0500 (Mon, 07 Apr 2008) | 7 lines
(closes issue #12362)
(closes issue #12372)
Reported by: vinsik
Tested by: tecnoxarxa
This one line change makes an if inside a for loop (in realtime_peer) check all the ast_variables the loop was intending to test rather than just the first one.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113042 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r112653 | dhubbard | 2008-04-03 17:13:11 -0500 (Thu, 03 Apr 2008) | 1 line
add a Zaptel timer check to verify the timer is responding when Zaptel support is compiled into Asterisk and Zaptel drivers are loaded. This will help people not waste their valuable time debugging side effects.
........
r112656 | dhubbard | 2008-04-03 17:19:43 -0500 (Thu, 03 Apr 2008) | 1 line
satisfy buildbot
........
r112714 | dhubbard | 2008-04-03 19:57:33 -0500 (Thu, 03 Apr 2008) | 1 line
sleep long enough for the zaptel timer error message to display before exit
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@112715 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r112469 | mmichelson | 2008-04-02 12:36:49 -0500 (Wed, 02 Apr 2008) | 21 lines
Merged revisions 112468 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r112468 | mmichelson | 2008-04-02 12:36:04 -0500 (Wed, 02 Apr 2008) | 13 lines
Fix a race condition in the manager. It is possible that a new manager event
could be appended during a brief time when the manager is not waiting for input.
If an event comes during this period, we need to set an indicator that there is an
event pending so that the manager doesn't attempt to wait forever for an event that
already happened.
(closes issue #12354)
Reported by: bamby
Patches:
manager_race_condition.diff uploaded by bamby (license 430)
(comments added by me)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@112470 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r112431 | file | 2008-04-02 12:26:51 -0300 (Wed, 02 Apr 2008) | 7 lines
Since the SIP request structure gets reused multiple times with TCP handling we have to clear the debug state or else we will keep spitting out debug even after it has been turned off.
(closes issue #12169)
Reported by: pj
Patches:
12169-debugoff-2.diff uploaded by qwell (license 4)
Tested by: pj
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@112436 65c4cc65-6c06-0410-ace0-fbb531ad65f3
