This patch allows for attended transfers to be logged in the
queue_log the same way that blind transfers have always been.
It was decided by popular opinion on the asterisk-dev mailing
list that this should be backported to 1.4. Thanks to everyone
who gave an opinion.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@125530 65c4cc65-6c06-0410-ace0-fbb531ad65f3
information for realtime queues instead of giving up-to-date
info. Now realtime is queried for the latest and greatest in
queue info.
(closes issue #12858)
Reported by: bcnit
Patches:
queue_show.patch uploaded by putnopvut (license 60)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@125476 65c4cc65-6c06-0410-ace0-fbb531ad65f3
app_queue does not use "boxcar" filtering as the comments
say. The term "boxcar" means that the number of samples used
to calculate stays constant, with new samples replacing the
oldest ones. The queue holdtime calculation uses all holdtime
samples collected since the queue was loaded, so the comment
has been changed to be accurate.
(closes issue #12781)
Reported by: davidw
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@123274 65c4cc65-6c06-0410-ace0-fbb531ad65f3
a queue member. There was too much of an opportunity for the member
to hang up (either during a delay, announcement, or overly long
agi) between the time that he answered the phone and the time when
he actually was bridged with the caller. The consequence of this
was that if the member hung up in that interval, then proper
abandonment details would not be noted in the queue log if the caller
were to hang up at any point after the member hangup.
(closes issue #12561)
Reported by: ablackthorn
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@115320 65c4cc65-6c06-0410-ace0-fbb531ad65f3
and macroexten fields. This is needed because if macros are daisy-chained, the incorrect
context and extension are placed on the new channel. I also added locking to the channel prior
to accessing these variables as noted in trunk's janitor project file.
(closes issue #12549)
Reported by: darren1713
Patches:
app_queue.c.macroextenpatch uploaded by darren1713 (license 116)
(with modifications from me)
Tested by: putnopvut
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@114848 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Additionally, don't try to (re)set options when they have empty values in realtime (all unset columns would have an empty value).
(closes issue #12445)
Reported by: atis
Patches:
12445-autofill.diff uploaded by qwell (license 4)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@114133 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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).
(closes issue #12359)
Reported by: pguido
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@114112 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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 :)
(closes issue #12127)
Reported by: atis
Patches:
12127v3.patch uploaded by putnopvut (license 60)
Tested by: atis, jvandal
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@109713 65c4cc65-6c06-0410-ace0-fbb531ad65f3
"dead" realtime queue. Since from the user's perspective, the queue
does exist, we shouldn't tell them we couldn't find the queue. Instead
since it is a dead queue, report a 0 waiting count
This issue was brought up on IRC by jmls
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@103956 65c4cc65-6c06-0410-ace0-fbb531ad65f3
for a caller to go out of turn if autofill were enabled and callers ahead in the queue were attempting
to call a member. This change fixes this.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@101216 65c4cc65-6c06-0410-ace0-fbb531ad65f3
if a user either removes or comments one of these options and reloads their queues, the
option will not reset to its default, instead maintaining the value from prior to the
reload.
Thanks to John Bigelow for pointing this error out to me.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@98733 65c4cc65-6c06-0410-ace0-fbb531ad65f3
used (which also happen to be some the biggest/ugliest functions too) to document first. I'm pretty
new to doxygen so criticism is welcome.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@97304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
answer during the specified timeout period. Prior to this change, there was a small chance
that the member name recorded in this case would be blank. Also prior to this change, if using
the ringall strategy, if no one answered the call during the specified timeout, the member name
listed in the queue log would randomly be one of the members that was rung.
(closes issue #11498, reported and tested by hloubser, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@95890 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a queue uses the ringall strategy, it was possible through unfortunate coincidence for a single member at a given penalty level to
make app_queue think that all members at that penalty level were unavailable and cause the members at the
next penalty level to be rung. With this patch, we will only move to the next penalty level if ALL the members
at a given penalty level are unreachable.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@95095 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I wonder if Asterisk can run at all without res_features. My guess is that
there's propably a lot of more modules and the core that depends on it.
Reported by: caio1982
(closes issue #11574)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@93182 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 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
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
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
change, I added some code to set pointers to NULL after they were unreferenced.
This pointed out that in this place, the object was unreferenced before the
code was done using it. So, move the unref down a little bit.
(crash reported by jmls on IRC)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@90470 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Now, it automatically increases the reference count to reflect the reference
that is now held by the container.
This was done to be more consistent with ao2_unlink(), which automatically
releases the reference held by the container. It also makes it so it is
no longer possible for a pointer to be invalid after ao2_link() returns.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@90348 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1) Due to some signed vs. unsigned silliness, setting 'eventwhencalled' to
'vars' or 'yes' did exactly the same thing. Thus the sign change of the
ast_true call.
2) The vars2manager function overwrote a \n for every channel variable it parsed, resulting
in bizarre output for the channel variables. This patch remedies this.
(related to issue #11385, however I'm not sure if this will actually be enough to close it)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89837 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A huge thanks go to lvl- for patiently providing the necessary valgrind output
that was necessary to finding this problem of memory corruption.
Reported by: lvl-
Patch by: tilghman
Closes issue #11174
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@89093 65c4cc65-6c06-0410-ace0-fbb531ad65f3
since the code attempts to set the strategy to -1 if you specify a bogus strategy.
While this isn't a huge issue in 1.4, it could be a problem for someone who, say, tries
to use the roundrobin strategy in trunk (despite all the deprecation warnings in 1.4).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@86202 65c4cc65-6c06-0410-ace0-fbb531ad65f3
interesting (read nasty) situations. This patch clears up the issue by making
only dynamic queue members removable via dynamic methods.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@85958 65c4cc65-6c06-0410-ace0-fbb531ad65f3
change. I changed this a while ago in trunk for performance reasons. However,
bug 8407 points out that it is actually a race condition, causing device state
changes to get processed in random order. So, I backported my changes from
trunk to 1.4.
(closes issue #8407, patch provided by tim_ringenbach, committed patch by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@85717 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk will log a warning message letting the user know that one was already defined with that
name and is it skipping all further instances. This also will work for realtime queues but in order
for that to happen, the user would have to trigger a perfectly timed reload as a realtime queue is being
looked up, which is highly unlikely (but taken care of nonetheless).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@82326 65c4cc65-6c06-0410-ace0-fbb531ad65f3
from being reallocated every time the queue is accessed.
I also removed a debug message I had accidentally left in on a previous commit.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@82274 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When building the outgoing list in try_calling(), a member reference is stored
in each outgoing entry. However, when this list got destroyed, the reference
was not released.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@82263 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to 'mem_iter' so that when refcounted queues are merged into trunk, there will be
little confusion regarding iterator names, especially when a queue and member iterator
are used in the same function.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@82252 65c4cc65-6c06-0410-ace0-fbb531ad65f3
a realtime queue had callers waiting in it, then the queue would be removed from the queue list, but it would
not actually be freed (in fact, a debug message warning about a memory leak would come up). With this patch,
reloads do not touch realtime queues at all.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81416 65c4cc65-6c06-0410-ace0-fbb531ad65f3
streaming functions will report it. Secondly, not all non-zero returns from play_file mean that the announce file
wasn't found. Positive return values simply mean that a digit was pressed (most likely to skip through the announcement).
(closes issue #10612, reported and patched by dimas)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81397 65c4cc65-6c06-0410-ace0-fbb531ad65f3
changes in the realtime engine.
(issue #10424, reported by irroot, patch by me)
This patch creates a new function called update_realtime_member_field, which is a generic
function which will allow any one field of a realtime queue member to be updated. This patch
only uses this function to update the paused status of a queue member, but it lays the foundation
for persisting the state of a realtime member the same way that static members' state is maintained
when using the persistentmembers setting
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81349 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(closes issue 10541, reported by Alric, patched by me)
The REALLY nice things about this patch is that queue members now have a "realtime" field
which will be true if the member is a realtime member. This means we can check this value
prior to certain processing if it should ONLY be done for realtime members.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81340 65c4cc65-6c06-0410-ace0-fbb531ad65f3
locked, and then each individual queue is locked. Under the right circumstances, this could deadlock. As such, I have unlocked
the individual queue before locking the queue list, and then locked the queue back after the queue list is unlocked.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@81158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
thinking the 'n' option was in use.
(closes issue #10320, reported by jfitzgibbon, patched by me, tested by blitzrage and me)
Thank you blitzrage for all the testing you've done lately with queues! It's much appreciated!
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77854 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes an issue where if a caller calls into a queue where no one is logged in, they would wait forever even if a member
logged in at some point.
(closes issue #10346, reported by and tested by blitzrage, patched by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@77852 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This makes it so that the 'n' option for Queue() can act properly depending on which strategy is used. If the strategy is
roundrobin, rrmemory, or ringall, we want to ring each phone once before moving on in the dialplan. However, if any other strategy is
used, we will only ring one phone since it cannot be guaranteed that a different phone will ring on subsequent attempts to ring a phone.
As a side effect of this, the QUEUE_MEMBER_COUNT dialplan function now just reads the membercount variable instead of traversing through
the member list to figure out how many members there are.
Special thanks to blitzrage for helping to test this out.
(closes issue #10127, reported by bcnit, patched by me, tested by blitzrage)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@76801 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Mark Michelson
Jeff Peeler
Tilghman Lesher
Jason Parker
Joshua Colp
Olle Johansson
Russell Bryant
Kevin P. Fleming
BJ Weschke