We do not want to do this (see bug below for details).
This makes it so that if a [ is found without a ], the entire config will fail, and nothing in it will be loaded.
Isue #10690.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@92696 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the channel which initiated the bridge was always assumed to have been the one
which activated the dynamic feature. This patch corrects this.
(closes issue #11529, reported and patched by nic_bellamy)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@92510 65c4cc65-6c06-0410-ace0-fbb531ad65f3
caller were ringing members (but not yet bridged) there could be available members
and waiting callers who would not get matched up. The member availability checker
was correctly determining the number of available members in this scenario, but
the queue itself did not parallelly reflect this status on the pending calls. This
commit corrects the issue.
(closes issue #11459, reported by equissoftware, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@92323 65c4cc65-6c06-0410-ace0-fbb531ad65f3
duplicate dialed numbers will be skipped, meaning the datastore isn't created. This means
that when we try to free it, there's a crash. This stops that crash from occurring.
(closes issue #11499, reported by slavon, patched by eliel)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@92202 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to reinvite each other in 1.4 and trunk.
This patch implements support for the 491 error code that
Asterisk 1.4 generates on situations where we get an
incoming INVITE and already has one in progress.
Thanks to mavetju for reporting and to Raj Jain for an
excellent explanation of the problem.
Patch by myself. Tested with 8 Asterisk servers connected
to each other in a training network.
Closes issue #10481
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@92158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the mutex attribute object marked as static. This means that multiple threads
initializing locks at the same time could step on each other and end up with
improperly initialized locks.
(found when tracking down locking issues related to issue #11080)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91828 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ironic as it gets in Asterisk programming land. Anyway, I spotted this bug while
trying to track down why systems are locking up and acting weird in issue #11080.
The mutex attribute object was marked as static in this function when it should
not have been.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91826 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to be locked.
* Document why we don't record Local channels in the dialed interfaces list.
* Remove the dialed variable as it isn't needed.
* Restructure some code for clarity and coding guidelines stuff
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91783 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to be locked.
* Document why we don't record Local channels in the dialed interfaces list.
* Handle memory allocation failure.
* Remove the dialed variable, as it wasn't actually needed.
* Tweak some formatting to conform to coding guidelines.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91780 65c4cc65-6c06-0410-ace0-fbb531ad65f3
queued up if autoservice gets a NULL return from ast_read().
* Make the process of queueing the hangup frame more efficient by putting the
frame where it is going to end up and avoiding some locking and extra memory
allocations and freeing.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91777 65c4cc65-6c06-0410-ace0-fbb531ad65f3
because a hangup actually causes a NULL frame to be received, not a hangup frame.
Queueing a hangup if we receive a NULL frame during autoservice corrects this problem
(closes issue #11467, reported by jmls, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91737 65c4cc65-6c06-0410-ace0-fbb531ad65f3
on every call into a queue. I'm not entirely sure about the logic in this part
of the code, so I want to look at it some more tomorrow. However, this makes
it safe and keeps it from crashing.
(closes issue #11486, reported by adamg, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91675 65c4cc65-6c06-0410-ace0-fbb531ad65f3
of crashing if a user had more than 256 messages in their voicemail. This patch kills two birds with
one stone by adding maxmsg support and also setting a hard limit on the number of messages at 255 so
that the crashes cannot happen.
(closes issue #11101, reported by Skavin, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
against older Asterisk 1.4 headers will now load properly with just a warning
indicating that they are old and may cause problems.
(patch by paravoid)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91501 65c4cc65-6c06-0410-ace0-fbb531ad65f3
provided. This was due to the fact that the answering channel did not have an extension
set, so ast_parseable_goto would fail. This fix eliminates the call to ast_parseable_goto
on the answering channel since it is a wasteful call. The answering channel and the calling
channel are both directed to the same extension and context, just different priorities, so
we can just copy the values from the calling channel to the answering channel and increment
the answering channel's priority.
(closes issue #11382, reported by jon, patch by me with correction by jon)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91273 65c4cc65-6c06-0410-ace0-fbb531ad65f3
a lock that we are waiting on for a mutex, not rwlocks. This should fix the
problem where people have reported "core show locks" crashing sometimes.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91074 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It turns out that the problem was the Mac version of the ast_atomic_fetchadd_int()
function. The Mac atomic add function returns the _new_ value, while this function
is supposed to return the old value. So, the crashes happened on unreferencing
objects. If the reference count was decreased to 1, ao2_ref() thought that it
had been decreased to zero, and called the destructor. However, there was still
an outstanding reference around.
(closes issue #11176)
(closes issue #11289)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91070 65c4cc65-6c06-0410-ace0-fbb531ad65f3
compiler is being used, then a warning will show up for any modules still using
the old name "private" instead of "_private".
(patch suggested by paravoid)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@91032 65c4cc65-6c06-0410-ace0-fbb531ad65f3
when looking up extensions. This code was added to handle the case where a
dialplan switch was in use that could block for a long time. However, the way
that I added it, it did this for all extension lookups. However, lookups in the
in-memory tree of extensions should _not_ take long enough to matter. So, move
the autoservice stuff to be only around executing a switch.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@90967 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@90735 65c4cc65-6c06-0410-ace0-fbb531ad65f3
