| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* The queue_transfer_fixup function was searching for and removing
the datastore from the incorrect channel, so this was fixed.
* Most datastore operations regarding the queue_transfer datastore
were being done without the channel locked, so proper channel locking
was added, too.
(closes issue #14086)
Reported by: ZX81
Patches:
14086v2.patch uploaded by putnopvut (license 60)
Tested by: ZX81, festr
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168628 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
These changes eliminate the need for (and use of)
the KEEPALIVE return code in res_features.c;
There are other places that use this result code
for similar purposes at a higher level, these appear
to be left alone in 1.4, but attacked in trunk.
The reason these changes are being made in 1.4, is
that parking ends a channel's life, in some situations,
and the code in the bridge (and some other places),
was not checking the result code properly, and dereferencing
the channel pointer, which could lead to memory corruption
and crashes.
Calling the masq_park function eliminates this danger
in higher levels.
A series of previous commits have replaced some parking calls
with masq_park, but this patch puts them ALL to rest,
(except one, purposely left alone because a masquerade
is done anyway), and gets rid of the code that tests
the KEEPALIVE result, and the NOHANGUP_PEER result codes.
While bug 13820 inspired this work, this patch does
not solve all the problems mentioned there.
I have tested this patch (again) to make sure I have
not introduced regressions.
Crashes that occurred when a parked party hung up
while the parking party was listening to the numbers
of the parking stall being assigned, is eliminated.
These are the cases where parking code may be activated:
1. Feature one touch (eg. *3)
2. Feature blind xfer to parking lot (eg ##700)
3. Run Park() app from dialplan (eg sip xfer to 700)
(eg. dahdi hookflash xfer to 700)
4. Run Park via manager.
The interesting testing cases for parking are:
I. A calls B, A parks B
a. B hangs up while A is getting the numbers announced.
b. B hangs up after A gets the announcement, but
before the parking time expires
c. B waits, time expires, A is redialed,
A answers, B and A are connected, after
which, B hangs up.
d. C picks up B while still in parking lot.
II. A calls B, B parks A
a. A hangs up while B is getting the numbers announced.
b. A hangs up after B gets the announcement, but
before the parking time expires
c. A waits, time expires, B is redialed,
B answers, A and B are connected, after
which, A hangs up.
d. C picks up A while still in parking lot.
Testing this throroughly involves acting all the permutations
of I and II, in situations 1,2,3, and 4.
Since I added a few more changes (ALL references to KEEPALIVE in the bridge
code eliimated (I missed one earlier), I retested
most of the above cases, and no crashes.
H-extension weirdness.
Current h-extension execution is not completely
correct for several of the cases.
For the case where A calls B, and A parks B, the
'h' exten is run on A's channel as soon as the park
is accomplished. This is expected behavior.
But when A calls B, and B parks A, this will be
current behavior:
After B parks A, B is hung up by the system, and
the 'h' (hangup) exten gets run, but the channel
mentioned will be a derivative of A's...
Thus, if A is DAHDI/1, and B is DAHDI/2,
the h-extension will be run on channel
Parked/DAHDI/1-1<ZOMBIE>, and the
start/answer/end info will be those
relating to Channel A.
And, in the case where A is reconnected to
B after the park time expires, when both parties
hang up after the joyful reunion, no h-exten
will be run at all.
In the case where C picks up A from the
parking lot, when either A or C hang up,
the h-exten will be run for the C channel.
CDR's are a separate issue, and not addressed
here.
As to WHY this strange behavior occurs,
the answer lies in the procedure followed
to accomplish handing over the channel
to the parking manager thread. This procedure
is called masquerading. In the process,
a duplicate copy of the channel is created,
and most of the active data is given to the
new copy. The original channel gets its name
changed to XXX<ZOMBIE> and keeps the PBX
information for the sake of the original
thread (preserving its role as a call
originator, if it had this role to begin
with), while the new channel is without
this info and becomes a call target (a
"peer").
In this case, the parking lot manager
thread is handed the new (masqueraded)
channel. It will not run an h-exten
on the channel if it hangs up while
in the parking lot. The h exten will
be run on the original channel instead,
in the original thread, after the bridge
completes.
See bug 13820 for our intentions as
to how to clean up the h exten behavior.
Review: http://reviewboard.digium.com/r/29/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@166093 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
configs are handled.
Also cleaned up some coding guidelines violations in app_realtime.c,
mostly related to spacing
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@165255 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
FreeBSD 32-bit build.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@163084 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This patch also contains a conversion from using long to time_t
for representing times for a queue, as well as some whitespace
fixes.
(closes issue #14060)
Reported by: nivek
Patches:
datastore_fixup.patch.corrected uploaded by nivek (license 636)
with slight modification from me
Tested by: nivek
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@163080 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
completely unrelated commit. Thanks to Theo Belder
on the Asterisk-dev list for pointing this out.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@158306 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
dial and queue... I wasted some time (stupidly) trying
to get the one-touch parking stuff working, because it
didn't occur to me that I had to also have the corresponding
options in the dial command! Duh! (In all this time, I never
set this up before!)
So, to keep some poor fool from suffering the same fate,
I made the features.conf.sample file mention the corresponding
opts in dial/queue; and the docs for dial/app specifically
mention the corresponding decls in the feature.conf file.
I hope this doesn't spoil some vast, eternal plan...
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@152538 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@152535 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
whether the call was completed within the service level
when a transfer takes place. This way, we do not "break"
the leastrecent and fewestcalls strategies by not logging
a call until after the transferred call has ended.
(closes issue #13395)
Reported by: Marquis
Patches:
app_queue.c.transfer.patch uploaded by Marquis (license 32)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@149200 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
something a bit strange. In all cases where we provide
a callback function to ao2_container_alloc, the callback
function would only return 0 or CMP_MATCH. After inspecting
the ao2_callback() code carefully, I found that if you're
only looking for one specific item, then you should return
CMP_MATCH | CMP_STOP. Otherwise, astobj2 will continue
traversing the current bucket until the end searching for
more matches.
In cases like chan_iax2 where in 1.4, all the peers are
shoved into a single bucket, this makes for potentially
terrible performance since the entire bucket will be
traversed even if the peer is one of the first ones come
across in the bucket.
All the changes I have made were for cases where the
callback function defined was passed to ao2_container_alloc
so that calls to ao2_find could find a unique instance
of whatever object was being stored in the container.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@140488 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
to timeouts from being strict to non-strict for more
accuracy.
(closes issue #13239)
Reported by: atis
Patches:
app_queue_timeouts_v2.patch uploaded by atis (license 242)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@138685 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12916)
Reported by: sgenyuk
Patches:
app_queue.patch.txt uploaded by neutrino88 (license 297)
Tested by: sgenyuk, aragon
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@136488 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
command once on an unload
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@136238 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
targeting areas where an unknown and potentially
long time has just elapsed. Also added a check
to try_calling() to return early if the timeout
has elapsed instead of potentially setting a negative
timeout for the call (thus making it have *no* timeout
at all).
(closes issue #13186)
Reported by: miquel_cabrespina
Patches:
13186.diff uploaded by putnopvut (license 60)
Tested by: miquel_cabrespina
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@134758 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Sept 12 last year). It was moved then to prevent a memory leak.
Since then, the same memory leak recurred and was fixed in a
better way.
Now it has been found that the placement of this init_queue
call can cause problems if a realtime queue has values changed
to an empty string. The problem is that the default value
for that queue parameter would not be set.
(closes issue #13084)
Reported by: elbriga
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@131369 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
that means. :P
(Thanks Russell!)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@131357 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
is removed from the calling channel once the caller
is finished in the queue. This could have weird con-
sequences when dialing local queue members when multiple
transfers occur on a single call.
Also fixed a memory leak that would occur when an
attended transfer occurred from a queue member.
(closes issue #13047)
Reported by: festr
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@131299 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
so that it can easily be associated with a queue member's name. This helps
so that the appropriate queue member can be removed or paused since the
interface is required, not the member's name.
(closes issue #12783)
Reported by: davevg
Patches:
app_queue.diff uploaded by davevg (license 209) with small mod from me
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@125585 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@125530 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@125476 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@123274 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
should continue working. Release announcement to follow.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@122314 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
set to "once."
(closes issue #12842)
Reported by: ramonpeek
Patches:
patch001.diff uploaded by ramonpeek (license 266)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@122311 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the queue member.
Thanks to Russell, who pointed this out.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@120513 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
not the name, since the interface is what is expected for the command.
(closes issue #12783)
Reported by: davevg
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@120285 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
all members were logged out OR paused, then it (incorrectly) let callers join
the queue.
(closes issue #12451)
Reported by: davidw
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@119404 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@115320 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
channel's macrocontext
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: http://svn.digium.com/svn/asterisk/branches/1.4@114848 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
was being truncated two characters. This patch corrects the
problem.
(closes issue #12493)
Reported by: davidw
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114628 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@114133 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@114112 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12349)
Reported by: johnlange
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@112393 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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 :)
(closes issue #12127)
Reported by: atis
Patches:
12127v3.patch uploaded by putnopvut (license 60)
Tested by: atis, jvandal
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@109713 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
number of available members to call if ringinuse is set to yes.
Thanks to jmls who brought this issue up on IRC
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105059 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
"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: http://svn.digium.com/svn/asterisk/branches/1.4@103956 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
to explicitly state the locking order necessary inside app_queue.
(closes issue #11862)
Reported by: flujan
Patches:
11862.patch uploaded by putnopvut (license 60)
Tested by: flujan
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@103120 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
possible
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: http://svn.digium.com/svn/asterisk/branches/1.4@101216 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@101035 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
unpause a queue member
fails.
Fixes BE-366, thanks to John Bigelow for writing the patch.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@100973 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@98737 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@98734 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
necessary because
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: http://svn.digium.com/svn/asterisk/branches/1.4@98733 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@97575 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@97308 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
most common functions
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: http://svn.digium.com/svn/asterisk/branches/1.4@97304 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@97206 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #11700)
Reported by: jbauer
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@97093 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
otherwise the result is that
multiple members can have the same name, since the variable was not reset on each iteration of the loop.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@96102 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
does not
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: http://svn.digium.com/svn/asterisk/branches/1.4@95890 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
small setup.
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: http://svn.digium.com/svn/asterisk/branches/1.4@95095 f38db490-d61c-443f-a65b-d21fe96a405b
|
