https://origsvn.digium.com/svn/asterisk/trunk
................
r114084 | twilson | 2008-04-11 17:48:52 -0500 (Fri, 11 Apr 2008) | 15 lines
Merged revisions 114083 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114083 | twilson | 2008-04-11 17:32:51 -0500 (Fri, 11 Apr 2008) | 7 lines
Several places in the code called find_callno() (which releases the lock on the pvt structure) and then immediately locked the call and did things with it. Unfortunately, the call can disappear between the find_callno and the lock, causing Bad Stuff(tm) to happen.
Added find_callno_locked() function to return the callno withtout unlocking for instances that it is needed.
(issue #12400)
Reported by: ztel
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114087 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r114080 | twilson | 2008-04-11 17:23:34 -0500 (Fri, 11 Apr 2008) | 2 lines
Make sure that ${LINE} is set even if linenumber is not set in users.conf
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114081 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r114067 | twilson | 2008-04-11 16:04:46 -0500 (Fri, 11 Apr 2008) | 3 lines
Fix the fact that global_variables 1) weren't being updated on reload (thanks for the report, Doug), and 2) weren't actually being appended to the list of profile variables because build_profile was called before the list was populated. Also needed to free the contents returned by load_file().
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114068 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r114049 | file | 2008-04-10 17:28:40 -0300 (Thu, 10 Apr 2008) | 2 lines
A 'b' option has been added which causes chan_local to return the actual channel that is behind it when queried. This is useful for transfer scenarios as the actual channel will be transferred, not the Local channel. If you have been using Local channels as queue members and having issues when the agent did a blind transfer this option may solve the issue.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114050 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r113928 | mmichelson | 2008-04-09 15:56:14 -0500 (Wed, 09 Apr 2008) | 16 lines
Merged revisions 113927 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113927 | mmichelson | 2008-04-09 15:54:31 -0500 (Wed, 09 Apr 2008) | 8 lines
We need to set the persistant_route [sic] parameter for the sip_pvt
during the initial INVITE, no matter if we're building the route set from
an INVITE request or response.
(closes issue #12391)
Reported by: benjaminbohlmann
Tested by: benjaminbohlmann
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113929 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r113875 | tilghman | 2008-04-09 14:00:40 -0500 (Wed, 09 Apr 2008) | 12 lines
Merged revisions 113874 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113874 | tilghman | 2008-04-09 13:57:33 -0500 (Wed, 09 Apr 2008) | 4 lines
If the [csv] section does not exist in cdr.conf, then an unload/load sequence
is needed to correct the problem. Track whether the load succeeded with a
variable, so we can fix this with a simple reload event, instead.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113876 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
