Jason Parker [Tue, 15 Apr 2008 16:18:08 +0000 (16:18 +0000)]
Allow autofill to work in the general section of queues.conf.
Additionally, don't try to (re)set options when they have empty values in realtime (all unset columns would have an empty value).
Mark Michelson [Mon, 14 Apr 2008 17:41:03 +0000 (17:41 +0000)]
Increase the retry count when attempting to show channels. This apparently
cleared an issue someone was seeing when attempting to show channels when
the load was high.
(closes issue #11667)
Reported by: falves11
Patches:
11677.txt uploaded by russell (license 2)
Tested by: falves11
Mark Michelson [Mon, 14 Apr 2008 16:24:22 +0000 (16:24 +0000)]
If the datastore has been moved to another channel due to a masquerade, then
freeing the datastore here causes an eventual double free when the new channel
hangs up. We should only free the datastore if we were able to successfully remove
it from the channel we are referencing (i.e. the datastore was not moved).
Mark Michelson [Mon, 14 Apr 2008 14:58:02 +0000 (14:58 +0000)]
Save a local copy of the generate callback prior to unlocking the channel in
case the generate callback goes NULL on us after the channel is unlocked. Thanks
to Russell for pointing this need out to me.
Don't change the SSRC when a new source comes into play, this might happen quite often and depending on the remote side... they might not like this.
(closes issue #12353)
Reported by: dimas
Terry Wilson [Fri, 11 Apr 2008 22:32:51 +0000 (22:32 +0000)]
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.
Create the directory where name recordings will go if it does not exist.
(closes issue #12311)
Reported by: rkeene
Patches:
12311-mkdir.diff uploaded by qwell (license 4)
Don't add custom URI options if they don't exist OR they are empty.
(closes issue #12407)
Reported by: homesick
Patches:
uri_options-1.4.diff uploaded by homesick (license 91)
Mark Michelson [Wed, 9 Apr 2008 20:54:31 +0000 (20:54 +0000)]
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.
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.
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
Mark Michelson [Tue, 8 Apr 2008 19:07:38 +0000 (19:07 +0000)]
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.
Move check for still-bridged channels out a little further, to avoid possible
deadlocks. (Closes issue #12252)
Reported by: callguy
Patches:
20080319__bug12252.diff.txt uploaded by Corydon76 (license 14)
Tested by: callguy
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
Jeff Peeler [Mon, 7 Apr 2008 21:34:45 +0000 (21:34 +0000)]
(closes issue #12362) [redo of 113012]
This fixes a for loop (in realtime_peer) to check all the ast_variables the loop was intending to test rather than just the first one. The change exposed the problem of calling memcpy on a NULL pointer, in this case the passed in sockaddr_in struct which is now checked.
Mark Michelson [Mon, 7 Apr 2008 16:08:45 +0000 (16:08 +0000)]
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.
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.
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.
Mark Michelson [Wed, 2 Apr 2008 17:36:04 +0000 (17:36 +0000)]
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)
Disable Packet2Packet bridging when we need to feed DTMF frames into the core. Some implementations do not like how we switch between things.
(closes issue #12212)
Reported by: bamby
Do not pass audio until the remote side has indicated they are providing early media, or if the channel has been answered.
(closes issue #11823)
Reported by: SDamm
Mark Michelson [Tue, 1 Apr 2008 17:21:21 +0000 (17:21 +0000)]
Initialize the __res_state structure used for dns purposes
to all 0's prior to using it. This is due to valgrind's complaints
on issue #12284 as well as an excerpt found in "Description" portion
of the online man page found here:
Ensure that we do not exceed the hold's maximum size with a single frame.
(closes issue #12047)
Reported by: fabianoheringer
Tested by: fabianoheringer
Note: While I did write this patch, I would not have found this if fossil
had not reported and fixed issue #12253. A huge thanks to him for helping
to (indirectly) find the problem here.
Tilghman Lesher [Thu, 27 Mar 2008 19:23:12 +0000 (19:23 +0000)]
For FreeBSD, at least, the ifa_addr element could be NULL.
(closes issue #12300)
Reported by: festr
Patches:
acl.c.patch uploaded by festr (license 443)
Steve Murphy [Thu, 27 Mar 2008 13:03:28 +0000 (13:03 +0000)]
These small documentation updates made in response to a query in
asterisk-users, where a user was using Playback, but needed the
features of Background, and had no idea that Background existed,
or that it might provide the features he needed. I thought the
best way to avert these kinds of queries was to provide "See Also"
references in all three of "Background", "Playback", "WaitExten".
Perhaps a project to do this with all related apps is in order.
These changes will set a channel variable ~~EXTEN~~ just before generating code
for a switch, with the value of ${EXTEN}. The exten is marked as having a switch,
and ever after that, till the end of the exten, we substitute any ${EXTEN}
with ${~~EXTEN~~} instead in application arguments; (and the ${EXTEN: also).
The reason for this, is that because switches are coded using
separate extensions to provide pattern matching, and
jumping to/from these switch extensions messes up the ${EXTEN} value,
which blows the minds of users.
Jason Parker [Wed, 26 Mar 2008 23:26:33 +0000 (23:26 +0000)]
Remove excessive smoother optimization that was causing audio glitches (small "pops")
after (about 200ms later) an "incorrectly" sized frame was received.
While it would be very nice to keep this as optimized as possible, it makes no sense
for the smoother to be dropping random bits of audio like this. Isn't that the
whole point of a smoother?
Mark Michelson [Wed, 26 Mar 2008 19:22:16 +0000 (19:22 +0000)]
Add a lock to the vm_state structure and use the lock around mail_open calls
to prevent concurrent access of the same mailstream. This, along with trunk's
ability to configure TCP timeouts for IMAP storage will help to prevent
crashes and hangs when using voicemail with IMAP storage.
Joshua Colp [Wed, 26 Mar 2008 18:41:29 +0000 (18:41 +0000)]
Make sure that full video frames are sent whenever the 15 bit timestamp rolls over.
(closes issue #11923)
Reported by: mihai
Patches:
asterisk-fullvideo.patch uploaded by mihai (license 94)
due to licensing restrictions, we cannot distribute the source code for iLBC encoding and decoding... so remove it, and add instructions on how the user can obtain it themselves
Jeff Peeler [Tue, 25 Mar 2008 20:03:13 +0000 (20:03 +0000)]
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.
Mark Michelson [Tue, 25 Mar 2008 15:40:33 +0000 (15:40 +0000)]
When reverting a commit, I accidentally left in this bit which was an experiment
to see what would happen. It passed the compile test, and I didn't notice I had
left this change in too.
Joshua Colp [Tue, 25 Mar 2008 14:37:35 +0000 (14:37 +0000)]
Add an option (transmit_silence) which transmits silence during both Record() and DTMF generation. The reason this is an option is that in order to transmit silence we have to setup a translation path. This may not be needed/wanted in all cases.
(closes issue #10058)
Reported by: tracinet
Mark Michelson [Mon, 24 Mar 2008 19:17:41 +0000 (19:17 +0000)]
This is a revert for revision 108288. The reason is that that revision
was not for an actual bug fix per se, and so it really should not have been in 1.4 in
the first place. Plus, people who compile with DO_CRASH are more likely
to encounter a crash due to this change. While I think the usage of DO_CRASH
in ast_sched_del is a bit absurd, this sort of change is beyond the scope of 1.4
and should be done instead in a developer branch based on trunk
so that all scheduler functions are fixed at once.
I also am reverting the change to trunk and 1.6 since they also suffer from
the DO_CRASH potential.
Russell Bryant [Thu, 20 Mar 2008 23:13:56 +0000 (23:13 +0000)]
Shorten the ast_waitfor() timeout from 500 ms to 50 ms in the autoservice thread.
This really should not make a difference except in very rare cases. That case would
be that all of the channels in autoservice are not generating any frames. In that
case, this change reduces the potential amount of time that a thread waits in
ast_autoservice_stop() for the autoservice thread to wrap back around to the beginning
of its loop.
Russell Bryant [Thu, 20 Mar 2008 21:54:58 +0000 (21:54 +0000)]
Merged revisions 110335 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r110335 | russell | 2008-03-20 16:53:27 -0500 (Thu, 20 Mar 2008) | 6 lines
Fix some very broken code that was introduced in 1.2.26 as a part of the security
fix. The dnsmgr is not appropriate here. The dnsmgr takes a pointer to an address
structure that a background thread continuously updates. However, in these cases,
a stack variable was passed. That means that the dnsmgr thread would be continuously
writing to bogus memory.
Joshua Colp [Wed, 19 Mar 2008 19:11:33 +0000 (19:11 +0000)]
Add sanity checking for position resuming. We *have* to make sure that the position does not exceed the total number of files present, and we have to make sure that the position's filename is the same as previous. These values can change if a music class is reloaded and give unpredictable behavior.
(closes issue #11663)
Reported by: junky
Joshua Colp [Wed, 19 Mar 2008 18:20:28 +0000 (18:20 +0000)]
Make sure that the mark bit does not incorrectly cause video frame timestamps to be calculated as if they are audio frames.
(closes issue #11429)
Reported by: sperreault
Patches:
11429-frametype.diff uploaded by qwell (license 4)
I didn't give tzafrir very much time to test this, but if he does
still have remaining issues, he is welcome to
re-open this bug, and we'll do what is called for.
I reproduced the problem, and tested the fix, so I hope I
am not jumping by just going ahead and committing the fix.
The problem was with what file_save does with templates;
firstly, it tended to print out multiple options:
[my_category](!)(templateref)
instead of
[my_category](!,templateref)
which is fixed by this patch.
Nextly, the code to suppress output of duplicate declarations
that would occur because the reader copies inherited declarations
down the hierarchy, was not working. Thus:
[template](!,master-template)
mastervar = bar
tvar = value
[cat](template)
mastervar = bar
tvar = value
catvar = val
This has been fixed. Since the config reader 'explodes' inherited
vars into the category, users may, in certain circumstances, see
output different from what they originally entered, but it should
be both correct and equivalent.
Mark Michelson [Tue, 18 Mar 2008 20:52:15 +0000 (20:52 +0000)]
This patch makes it so that all queue member status changes are handled through device state
code. This removes several problems people were seeing where their queue members would get into
an "unknown" state. Huge props go to atis on this one since he was the one who found the code
section that was causing the problem and proposed the solution. I just wrote what he suggested :)
Steve Murphy [Tue, 18 Mar 2008 06:37:15 +0000 (06:37 +0000)]
(closes issue #11903)
Reported by: atis
Many thanks to atis for spotting this problem and reporting it.
The fix was to straighten out how items are placed on and removed
from the file stack. Regressions as well as the provided test case
helped to straighten out all code paths. valgrind was used to make
sure all memory allocated was freed.
Sorry for not solving this earlier. I got distracted.
Added the ntest23 regression test, which is mainly a copy of ntest22,
but with a few juicy errors thrown in, to replicate the kind of
error that atis spotted.
Mark Michelson [Mon, 17 Mar 2008 22:05:49 +0000 (22:05 +0000)]
Fix a logic flaw in the code that stores lock info which is displayed
via the "core show locks" command. The idea behind this section of code was
to remove the previous lock from the list if it was a trylock that had failed.
Unfortunately, instead of checking the status of the previous lock, we were referencing
the index immediately following the previous lock in the lock_info->locks array.
The result of this problem, under the right circumstances, was that the lock which
we currently in the process of attempting to acquire could "overwrite" the previous lock
which was acquired. While this does not in any way affect typical operation, it *could*
lead to misleading "core show locks" output.
Joshua Colp [Mon, 17 Mar 2008 16:24:29 +0000 (16:24 +0000)]
200 OKs in response to a reinvite need to be sent reliably. If the remote side does not receive one the dialog will be torn down.
(closes issue #12208)
Reported by: atrash