https://origsvn.digium.com/svn/asterisk/trunk
........
r237920 | dvossel | 2010-01-05 17:08:50 -0600 (Tue, 05 Jan 2010) | 16 lines
fixes holdtime playback issue in app_queue
When reporting hold time, the number of seconds should be mod 60.
Otherwise audio playback could be something like "2 minutes 123 seconds"
rather than "2 minutes 3 seconds".
Also, the "minute" sound file is missing, so for the moment until
that file can be created the "minutes" file is used instead.
(closes issue #16168)
Reported by: nickilo
Patches:
patch-unified-trunk-rev-222176 uploaded by nickilo (license )
Tested by: nickilo, wonderg
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@237922 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r231556 | dvossel | 2009-11-30 12:55:07 -0600 (Mon, 30 Nov 2009) | 11 lines
app_queue crashes randomly, often during call-transfers
This patch adds a ref to the queue_ent object's parent call_queue
in queue_exec() so the call_queue won't be destroyed
while the the queue_ent still holds a pointer to it.
(closes issue 0015686)
Tested by: dvossel, aragon
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@231559 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r222176 | kpfleming | 2009-10-05 20:24:24 -0500 (Mon, 05 Oct 2009) | 27 lines
Recorded merge of revisions 222152 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r222152 | kpfleming | 2009-10-05 20:16:36 -0500 (Mon, 05 Oct 2009) | 20 lines
Fix ao2_iterator API to hold references to containers being iterated.
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@222186 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r211040 | tilghman | 2009-08-07 13:17:41 -0500 (Fri, 07 Aug 2009) | 21 lines
Merged revisions 211038 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r211038 | tilghman | 2009-08-07 13:16:28 -0500 (Fri, 07 Aug 2009) | 14 lines
QUEUE_MEMBER_LIST _really_ wants the interface name, not the membername.
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@211047 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r208622 | mmichelson | 2009-07-24 14:24:28 -0500 (Fri, 24 Jul 2009) | 16 lines
Don't impose an arbitrary limit on member lines in queues.conf
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@208661 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r205350 | mmichelson | 2009-07-08 14:26:55 -0500 (Wed, 08 Jul 2009) | 20 lines
Merged revisions 205349 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r205349 | mmichelson | 2009-07-08 14:26:13 -0500 (Wed, 08 Jul 2009) | 14 lines
Prevent phantom calls to queue members.
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@205352 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.
(Related to revision 191041 in branches/1.4)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@191454 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r188032 | mmichelson | 2009-04-13 09:17:56 -0500 (Mon, 13 Apr 2009) | 6 lines
Set all queue variables on both the caller and member channels.
This allows for the variables to be accessed if a member macro is run.
Thanks to Grigoriy Puzankin for bringing this up on the -dev list.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@188038 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r185072 | mmichelson | 2009-03-30 11:26:48 -0500 (Mon, 30 Mar 2009) | 45 lines
Merged revisions 185031 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r185031 | mmichelson | 2009-03-30 11:17:35 -0500 (Mon, 30 Mar 2009) | 39 lines
Fix queue weight behavior so that calls in low-weight queues are not 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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@185088 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r183244 | mmichelson | 2009-03-19 13:10:34 -0500 (Thu, 19 Mar 2009) | 16 lines
Fix a memory leak associated with queues.
For every attempt that app_queue made to place an outbound call to a queue member,
we would allocate a queue_end_bridge structure. When the bridge for the call had
completed, we would free the structure. Unfortunately not all call attempts actually
end up bridged to a member, so we need to be more selective of when to allocate
the structure. With this change, the allocation occurs in an area where we can
guarantee that the call will be bridged.
(closes issue #14680)
Reported by: caspy
Patches:
14680.patch uploaded by mmichelson (license 60)
Tested by: caspy
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@183246 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r180007 | mmichelson | 2009-03-03 16:49:07 -0600 (Tue, 03 Mar 2009) | 22 lines
Merged revisions 180006 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r180006 | mmichelson | 2009-03-03 16:48:18 -0600 (Tue, 03 Mar 2009) | 17 lines
Clarify some documentation of queues.conf.sample
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@180009 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r176557 | russell | 2009-02-17 11:33:38 -0600 (Tue, 17 Feb 2009) | 12 lines
Fix a race condition that caused device states to become incorrect for hints.
The problem here is that the hint processing code was subscribed to the wrong
event type. So, it started processing state for a hint too soon, before the
device state cache had been updated.
Also, fix a similar bug in app_queue, as it was also subscribed to the wrong
event type.
(closes issue #14461)
Reported by: alecdavis
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@176559 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r174948 | mmichelson | 2009-02-11 17:03:08 -0600 (Wed, 11 Feb 2009) | 20 lines
Fix odd "thank you" sound playing behavior in app_queue.c
If someone has configured the queue to play an position or holdtime
announcement, then it is odd and potentially unexpected to hear a
"Thank you for your patience" sound when no position or holdtime
was actually announced.
This fixes the announcement so that the "thanks" sound is only played
in the case that a position or holdtime was actually announced.
There is a way that the "thank you" sound can be played without a
position or holdtime, and that is to set announce-frequency to a value
but keep announce-position and announce-holdtime both turned off.
(closes issue #14227)
Reported by: caspy
Patches:
14227_v3.patch uploaded by putnopvut (license 60)
Tested by: caspy
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@174950 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r173693 | mmichelson | 2009-02-05 14:30:45 -0600 (Thu, 05 Feb 2009) | 20 lines
Merged revisions 173692 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r173692 | mmichelson | 2009-02-05 14:29:09 -0600 (Thu, 05 Feb 2009) | 12 lines
Fix situations where queue members could be autopaused unexpectedly
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@173695 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r171618 | mmichelson | 2009-01-27 13:30:54 -0600 (Tue, 27 Jan 2009) | 24 lines
Fix queue crashes that would occur after the calling channel was masqueraded.
The data passed to the end_bridge_callback was assumed to be data which was
still stack'd. The problem was that with some call features, attended transfers
in particular, a new bridge thread is started once the feature completes, meaning
that when the end_bridge_callback is called, the end_bridge_callback_data was
invalid.
To fix this problem, there are two measures taken
1. Instead of pointing to stacked data, we now used heap-allocated data for
passing to the end_bridge_callback in app_queue
2. Since bridges can end multiple times on a single logical call, we wait until
the final bridge is broken to actually set any queue variables. This is accomplished
through reference-counting and the use of an end_bridge_callback_data_fixup function
in app_queue.c
(closes issue #14260)
Reported by: ccesario
Patches:
14260.patch uploaded by putnopvut (license 60)
Tested by: ccesario
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@171620 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r169611 | mmichelson | 2009-01-20 18:33:32 -0600 (Tue, 20 Jan 2009) | 22 lines
Fix device state parsing issues for channel names with multiple slashes
The fix being applied is a bit different for trunk and the 1.6.X branches.
For trunk, we only wish to strip off the characters beyond the second slash
if the channel is a Local channel (i.e. we are removing the /n from the device
name). Other channel technologies with multiple slashes (e.g. DAHDI) need the
information after the second slash in order to get the proper device state
information.
In addition to this fix, the 1.6.X branches are receiving a much more important
fix as well. The problem in 1.6.X is that the member's device name was being directly
changed instead of having a copy changed. This meant that we would strip off the
second slash and trailing characters and then leave the member's device name like
that permanently thereafter.
(closes issue #14014)
Reported by: kebl0155
Patches:
14014_number2.patch uploaded by putnopvut (license 60)
Tested by: kebl0155
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@169613 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r168629 | mmichelson | 2009-01-14 18:14:17 -0600 (Wed, 14 Jan 2009) | 24 lines
Merged revisions 168628 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r168628 | mmichelson | 2009-01-14 18:11:01 -0600 (Wed, 14 Jan 2009) | 16 lines
Fix some crashes from bad datastore handling in app_queue.c
* 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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@168631 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r166861 | mmichelson | 2008-12-29 12:04:52 -0600 (Mon, 29 Dec 2008) | 14 lines
Update app_queue to deal with the removal of AST_PBX_KEEPALIVE
When placing a call to a queue which ran a gosub on the member's
channel, Asterisk would crash every time, stemming from the fact
that the member's channel was being hung up unexpectedly when the
Gosub completed. The necessary change was pretty much copied and
pasted from app_dial's similar changes made last week.
I also took the opportunity to change a LOG_DEBUG message in
app_dial to use ast_debug. I am guessing this was due to a direct
merge from 1.4 that was not corrected to use trunk's preferred
syntax.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@166863 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
This merged from trunk with no conflicts. I tested
mostly the 'tired' cases, and for the most part
ignored the tests for reconnecting and dialing in
to fetch a parked call, after the first case.
................
r166665 | murf | 2008-12-23 11:13:49 -0700 (Tue, 23 Dec 2008) | 153 lines
Merged revisions 166093 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
In order to merge this 1.4 patch into trunk,
I had to resolve some conflicts and wait for
Russell to make some changes to res_agi.
I re-ran all the tests; 39 calls in all, and
made fairly careful notes and comparisons: I
don't want this to blow up some aspect of
asterisk; I completely removed the KEEPALIVE
from the pbx.h decls. The first 3 scenarios
involving feature park; feature xfer to 700;
hookflash park to Park() app call all behave
the same, don't appear to leave hung channels,
and no crashes.
........
r166093 | murf | 2008-12-19 15:30:32 -0700 (Fri, 19 Dec 2008) | 131 lines
This merges the masqpark branch into 1.4
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@166730 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r165318 | mmichelson | 2008-12-17 15:17:20 -0600 (Wed, 17 Dec 2008) | 15 lines
Merged revisions 165255 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r165255 | mmichelson | 2008-12-17 14:51:38 -0600 (Wed, 17 Dec 2008) | 7 lines
Fix some memory leaks found while looking at how realtime
configs are handled.
Also cleaned up some coding guidelines violations in app_realtime.c,
mostly related to spacing
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@165324 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r164268 | mmichelson | 2008-12-15 10:10:43 -0600 (Mon, 15 Dec 2008) | 17 lines
Fix up a few issues with regards to queues
* Fix reference counting used in the __queues_show function
* Add code to be sure that the "queue show" command does not
print information for a realtime queue which has been deleted
from the backend
* Add a missing unref to the realtime queue loading function for
the case where a queue is in the module's container but has been
deleted from the realtime backend
(closes issue #14033)
Reported by: cristiandimache
Patches:
14033.patch uploaded by putnopvut (license 60)
Tested by: cristiandimache
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@164273 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r163873 | twilson | 2008-12-12 17:48:26 -0600 (Fri, 12 Dec 2008) | 6 lines
When using realtime queues, app_queue wasn't updating the strategy if it was changed in the realtime backend. This patch resolves the issue for almost all situations. It is currently not supported to switch to the linear strategy via realtime since the ao2_container for members will have been set to have multiple buckets and therefore the members would be unordered.
(closes issue #14034)
Reported by: cristiandimache
Tested by: otherwiseguy, cristiandimache
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@163875 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r163081 | mmichelson | 2008-12-11 10:33:16 -0600 (Thu, 11 Dec 2008) | 22 lines
Merged revisions 163080 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r163080 | mmichelson | 2008-12-11 10:24:43 -0600 (Thu, 11 Dec 2008) | 14 lines
Fix a potential crash due to unsafe datastore handling.
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@163083 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r160626 | mmichelson | 2008-12-03 12:37:46 -0600 (Wed, 03 Dec 2008) | 16 lines
Add some safety measures when using gosub, especially when using the options
for app_dial and app_queue to run a gosub when the call is answered.
* Check for the existence of the gosub target in gosub_exec. If it is nonexistent,
then this will cause errors when we attempt to actually run the gosub, including
a definite memory leak and potential crashes. Return an error in this situation
* Check the return value of pbx_exec in app_dial and app_queue before attempting
to actually run the gosub routine. If there was an error, we should not attempt
to run the gosub.
* Change a '|' to a ',' in app_queue.
* Add some extra curly braces where they had been missing previously.
(closes issue #13548)
Reported by: fiddur
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@160628 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r160555 | mmichelson | 2008-12-03 11:07:09 -0600 (Wed, 03 Dec 2008) | 11 lines
When investigating issue #13548, I found that gosub
handling in app_queue was just completely wrong, mostly
because the channel operations being performed were being
done on the incorrect channel.
With this set of changes, a gosub will correctly run on
the answering queue member's channel. There are still crash
issues which occur if there are dialplan syntax errors, so
I cannot yet close the referenced issue.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@160557 65c4cc65-6c06-0410-ace0-fbb531ad65f3
