you complete the transfer before the announcement of the parking spot finishes,
then the channel being parked will hear the remainder of the announcement.
These changes make it so that will not happen anymore.
Basically, res_features sets a flag on the channel is playing the announcement
to so that the file streaming core knows that it needs to watch out for a
channel masquerade, and if it occurs, to abort the announcement.
(closes BE-182)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81599 65c4cc65-6c06-0410-ace0-fbb531ad65f3
after we already looked it up by name. This causes broken behavior if there is
more than one feature defined with the same digit pattern.
(closes issue #10539, reported by bungalow, patch by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@80573 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the peers and users are being stored in a linked list, that they go in the
list in the same order that the older code used. This is necessary to maintain
the behavior of which peers and users get matched when traversing the container.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@80497 65c4cc65-6c06-0410-ace0-fbb531ad65f3
implies that is possible to miss an object or see an object twice while
iterating. After looking through the code and talking with mmichelson, I have
documented the exact conditions under which this can happen (which are rare and
harmless in most cases).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@80426 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This set of changes fixes problems with the handling of iax2_user and iax2_peer
objects. It was very possible for a thread to still hold a reference to one of
these objects while a reload operation tries to delete them. The fix here is to
ensure that all references to these objects are tracked so that they can't go away
while still in use.
To accomplish this, I used the astobj2 reference counted object model. This
code has been in one of Luigi Rizzo's branches for a long time and was primarily
developed by one of his students, Marta Carbone. I wanted to go ahead and bring
this in to 1.4 because there are other problems similar to the ones fixed by these
changes, so we might as well go ahead and use the new astobj if we're going to go
through all of the work necessary to fix the problems.
As a nice side benefit of these changes, peer and user handling got more efficient.
Using astobj2 lets us not hold the container lock for peers or users nearly as long
while iterating. Also, by changing a define at the top of chan_iax2.c, the objects
will be distributed in a hash table, drastically increasing lookup speed in these
containers, which will have a very big impact on systems that have a large number of
users or peers.
The use of the hash table will be made the default in trunk. It is not the default
in 1.4 because it changes the behavior slightly. Previously, since peers and users
were stored in memory in the same order they were specified in the configuration file,
you could influence peer and user matching order based on the order they are specified
in the configuration. The hash table does not guarantee any order in the container,
so this behavior will be going away. It just means that you have to be a little
more careful ensuring that peers and users are matched explicitly and not forcing
chan_iax2 to have to guess which user is the right one based on secret, host, and
access list settings, instead of simply using the username.
If you have any questions, feel free to ask on the asterisk-dev list.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@80362 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Caused by fix for issue 9938.
I basically took the code that existed before 9938 was fixed, and
copied it into a new function - ast_unescape_semicolon
There should be very few places this will be needed (pbx_config
does NOT need this (see issue 9938 for details))
Issue 10430, patch by me, with help/ideas from murf (thanks murf).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@79904 65c4cc65-6c06-0410-ace0-fbb531ad65f3
track mutexes unless they were declared using AST_MUTEX_DEFINE_STATIC. Locks
initialized with ast_mutex_init() were not tracked. It should work now.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@78995 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Now matches are made on both the IP address and port number, or if the insecure setting is set to "port" then just match on the
IP address.
In order to accomplish this, I also added a new API call, ast_category_root, which returns the first variable of an ast_category struct
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@78103 65c4cc65-6c06-0410-ace0-fbb531ad65f3
with DEBUG_THREADS enabled and provide the following:
* This will keep track of which locks are held by which thread as well as
which lock a thread is waiting for in a thread-local data structure. A
reference to this structure is available on the stack in the dummy_start()
function, which is the common entry point for all threads. This information
can be easily retrieved using gdb if you switch to the dummy_start() stack
frame of any thread and print the contents of the lock_info variable.
* All of the thread-local structures for keeping track of this lock information
are also stored in a list so that the information can be dumped to the CLI
using the "core show locks" CLI command. This introduces a little bit of a
performance hit as it requires additional underlying locking operations
inside of every lock/unlock on an ast_mutex. However, the benefits of
having this information available at the CLI is huge, especially considering
this is only done in DEBUG_THREADS mode. It means that in most cases where
we debug deadlocks, we no longer have to request access to the machine to
analyze the contents of ast_mutex_t structures. We can now just ask them
to get the output of "core show locks", which gives us all of the information
we needed in most cases.
I also had to make some additional changes to astmm.c to make this work when
both MALLOC_DEBUG and DEBUG_THREADS are enabled. I disabled tracking of one
of the locks in astmm.c because it gets used inside the replacement memory
allocation routines, and the lock tracking code allocates memory. This caused
infinite recursion.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@78095 65c4cc65-6c06-0410-ace0-fbb531ad65f3
still can't build *_odbc.so!", check for ltdl directly, instead of just listing
it as another library to include in the unixodbc check in the configure script.
This also makes ltdl show up as a dependency in menuselect so people know what
to go install. (related to issue #9989, patch by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@69702 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Due to a bug in the iksemel library, this will not work if you are using GTLS
in the connection. That's being investigated. If you figure out a way to handle
that without us having to patch iksemel, let us know in the bug report. Thanks.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@67993 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r67715 | russell | 2007-06-06 11:40:51 -0500 (Wed, 06 Jun 2007) | 5 lines
We have some bug reports showing crashes due to a double free of a channel.
Add a sanity check to ast_channel_free() to make sure we don't go on trying
to free a channel that wasn't found in the channel list.
(issue #8850, and others...)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@67716 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Every time I tried to go debug it by adding some debug output, the behavior
would change. It turns out I wasn't crazy. I had the following piece of code:
if (remove)
AST_LIST_REMOVE_CURRENT(...);
Well, AST_LIST_REMOVE_CURRENT was not wrapped in braces, so my conditional
statement didn't do much good at all. It always ran at least all of the
macro minus the first statement, so I was seeing list entries magically
disappear when they weren't supposed to.
After many hours of debugging, I have come to this extremely irritating fix. :)
(issues #9581, #9497)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@67492 65c4cc65-6c06-0410-ace0-fbb531ad65f3
all of the modules. "stop now" is considered a non-graceful shutdown and will
not go through this process.
(issue #9804, reported by chrisost, patch by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@67308 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r65172 | murf | 2007-05-18 14:56:20 -0600 (Fri, 18 May 2007) | 1 line
This update will fix the situation that occurs as described by 9717, where when several targets are specified for a dial, if any one them reports FAIL, the whole call gets FAIL, even though others were ringing OK. I rearranged the priorities, so that a new disposition, NULL, is at the lowest level, and the disposition get init'd to NULL. Then, next up is FAIL, and next up is BUSY, then NOANSWER, then ANSWERED. All the related set routines will only do so if the disposition value to be set to is greater than what's already there. This gives the intended effect. So, if all the targets are busy, you'd get BUSY for the call disposition. If all get BUSY, but one, and that one rings is not answered, you get NOANSWER. If by some freak of nature, the NULL value doesn't get overridden, then the disp2str routine will report NOANSWER as before.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@65200 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the asterisk-dev mailing list. I changed the enforced minimum length of a
digit from 100ms to 80ms. Furthermore, I made it now enforce a gap of 45ms in
between digits. These values are not configurable in a configuration file
right now, but they can be easily changed near the top of main/channel.c.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@61781 65c4cc65-6c06-0410-ace0-fbb531ad65f3
