| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
At times, the "Member" field was not specified during the event.
It's there now.
(closes issue #15638)
Reported by: elbriga
Patches:
patchAppQueueAgentComplete.diff uploaded by elbriga (license 482)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@266004 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
restores the behavior prior to r258670.
(closes issue #17334)
Reported by: jvandal
Patches:
queue-cdr-fixes1.diff uploaded by mnicholson (license 96)
Tested by: aragon, jvandal
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@265610 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This also fixes a documentation mistake in file.h that made my original attempt
to correct this problem not work correctly.
(closes issue #17061)
Reported by: RoadKill
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@265089 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the queue cannot place calls.
(closes issue #16834)
Reported by: kebl0155
Patches:
app_queue_no_autofill.v1.patch uploaded by kebl0155 (license 356)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@247168 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #16677)
Reported by: tim_ringenbach
Patches:
app_queue_use_weight_deadlock.diff uploaded by tim ringenbach (license 540)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@246115 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
am leaving the review closed as the change was pointless.
(issue #16488)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@243691 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #16488)
Reported by: syspert
Patches:
soundfilelen.pacth-2 uploaded by syspert (license 938)
Review: https://reviewboard.asterisk.org/r/475/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@243570 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #16369)
Reported by: vrban
Patches:
queue_issue_1.4.diff uploaded by dvossel (license 671)
Tested by: dvossel
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@232444 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
In app_queue, it is possible for a call_queue to be destroyed
while another object still holds a pointer to it. This patch
converts call_queue objects to ao2 objects allowing them to be
ref counted. This makes it safe for the queue_ent object in
queue_exec() to reference it's parent call_queue even after it
has left the queue.
(closes issue #15686)
Reported by: Hatrix
Patches:
v2_queue_ao2.diff uploaded by dvossel (license 671)
Tested by: dvossel, aragon
Review: https://reviewboard.asterisk.org/r/427/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@231437 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@223550 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
See Mantis issue for details of what prompted this change.
Additional notes:
This patch changes the ao2_iterator API in two ways: F_AO2I_DONTLOCK
has become an enum instead of a macro, with a name that fits our
naming policy; also, it is now necessary to call
ao2_iterator_destroy() on any iterator that has been
created. Currently this only releases the reference to the container
being iterated, but in the future this could also release other
resources used by the iterator, if the iterator implementation changes
to use additional resources.
(closes issue #15987)
Reported by: kpfleming
Review: https://reviewboard.asterisk.org/r/383/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@222152 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
answer.
(Fixes AST-228)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@217989 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
The additional checks prevent generation of false TRANSFER events in certain situations.
(closes issue #14536)
Reported by: aragon
Patches:
queue-log-xfer-fix1.diff uploaded by mnicholson (license 96)
Tested by: aragon, mnicholson
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@211953 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@211528 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This is a partial revert of revision 82590, which was an attempted cleanup,
but in reality, it broke QUEUE_MEMBER_LIST, which has always been intended
as a method by which component interfaces could be queried from the queue.
Membername isn't useful here, because that field cannot be used to obtain
further information about the member. See the documentation on
QUEUE_MEMBER_LIST, RemoveQueueMember, QUEUE_MEMBER_PENALTY, and the various
AMI commands which take a member argument for further justification.
(closes issue #15664)
Reported by: rain
Patches:
app_queue-queue_member_list.diff uploaded by rain (license 327)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@211038 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
I know what some of you are thinking: "UGH! Mark, why are you using
ast_strdup and ast_free for the string when you can just use ast_strdupa
and let the memory free itself?! Have the bats been chewing on your brain
again?"
Based on past experiences, I don't like using ast_strdupa inside a loop.
It's a good way to potentially exhaust stack space. Also, since this only
happens when reloading queues, I don't think that heap allocations and
frees are going to be a huge problem.
(closes issue #15559)
Reported by: amorsen
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@208622 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
If a caller were to hang up while a periodic announcement or position
were being said, the return value for those functions would incorrectly
indicate that the caller was still in the queue. With these changes,
the problem does not occur.
(closes issue #14631)
Reported by: latinsud
Patches:
queue_announce_ghost_call2.diff uploaded by latinsud (license 745)
(with small modification from me)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@205349 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
command.
This change relates to r184980, which was a backport of the state interface
changes to app_queue from trunk. trunk and all of the 1.6.x branches are not
affected.
'queue add member' allows for specifying an interface to use for device state
when adding a queue member via CLI, but the validation code was not properly
updated to reflect this optional argument.
(closes issue #15198)
Reported by: loloski
Patches:
05272009_app_queue.diff uploaded by seanbright (license 71)
Tested by: loloski
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@197024 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
situations.
This involves setting a proper cdr disposition coresponding to the given
failure condition and ensuring the proper information is stored in the cdr
record.
(closes issue #13691)
Reported by: dferrer
Tested by: mnicholson
(closes issue #13637)
Reported by: atis
Tested by: atis
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@194028 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
According to Kevin, it is unspecified as to whether a variable defined inside
a block is allocated once by the compiler or for each pass through the block
(loops being the only interesting case), so just define these before we get
into our loop to be sure.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@191422 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
A user reported via #asterisk that with very long lists of members, a crash
occurs in ast_strdupa, so just use a single buffer and ast_copy_string instead
of stack allocating copys of each interface name.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@191041 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14796)
Reported by: pida
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@185599 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Issue #14359 was fixed between the time that I posted the review of the backport
of the state interface change for 1.4. This merges the changes from that issue
back into 1.4.
(closes issue #14359)
Reported by: francesco_r
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@185298 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
inappropriately blocked.
(This is copied and pasted from the review request I made for this patch)
Asterisk has some odd behavior when queue weights are used. The current logic used when
potentially calling a queue member is:
If the member we are going to call is part of another queue and _that other queue has any
callers in it_ and has a higher weight than the queue we are calling from, then don't try
to contact that member. The issue here is what I have marked with underscores. If the
higher-weighted queue has any callers in it at all, then the queue member will be unreachable
from the lower-weighted queue. This has the potential to be really really bad if using a
queue strategy, such as leastrecent or fewestcalls, with the potential to call the same
member repeatedly.
The fix proposed by garychen on issue 13220 is very simple and, as far as I can see, works
well for this situation. With this set of changes, the logic used becomes:
If the member we are going to call is part of another queue, the other queue has a higher
weight than the queue we are calling from, and the higher weight queue has at least as many
callers as available members, then do not try to contact the queue member. If the higher
weighted queue has fewer callers than available members, then there is no reason to deny
the call to this member since the other queue can afford to spare a member.
Since the fix involved writing a generic function for determining the number of available
members in the queue, I also modified the is_our_turn function to make use of the new
num_available_members function to determine if it is our turn to try calling a member. There
is one small behavior change. Before writing this patch, if you had autofill disabled, then
if you were the head caller in a queue, you would automatically be told that it was your
turn to try calling a member. This did not take into account whether there were actually any
queue members available to take the call. Now we actually make sure there is at least one
member available to take the call if autofill is disabled.
(closes issue #13220)
Reported by: garychen
Review: http://reviewboard.digium.com/r/202/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@185031 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
After several issues raised on the Asterisk bugtracker against
the 1.4 branch were determined to be fixable with the state interface
change available in the 1.6.X series, it finally came time to just
suck it up and backport the change.
For a detailed explanation of what this change entails, the original
trunk commit for this feature may be found here:
http://svn.digium.com/view/asterisk?view=revision&revision=97203
In addition, the details for the use of this change to fix the problems
stated in issue #12970 may be found in the review request I made for
this change. It is linked below.
(closes issue #12970)
Reported by: edugs15
Review: http://reviewboard.digium.com/r/116
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@184980 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
It had always been possible to explicitly specify a "blank"
value for a sound file in queues.conf and have no sound played
back. The problem with this is that it would result in some ugly
CLI warnings from file.c.
This commit introduces a check when playing a file in app_queue
to see if the name of the file is zero-length and return early if
that is the case. Also, the ability to specify the blank sound
files in queues.conf is now mentioned more clearly in queues.conf.sample
(closes issue #14227)
Reported by: caspy
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@180006 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Specifically, this patch prevents us from autopausing members when
we receive a busy or congestion frame from them.
(closes issue #14376)
Reported by: fiddur
Patches:
14376.patch uploaded by putnopvut (license 60)
Tested by: fiddur
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@173692 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
* 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
|
