https://origsvn.digium.com/svn/asterisk/trunk
................
r173589 | mmichelson | 2009-02-05 12:34:06 -0600 (Thu, 05 Feb 2009) | 33 lines
Merged revisions 173559 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r173559 | mmichelson | 2009-02-05 11:34:33 -0600 (Thu, 05 Feb 2009) | 25 lines
Fix a problem where a channel pointer becomes invalid due to masquerading or hanging up.
app_mixmonitor runs its own thread to monitor the channel's activity and write the mixed
audio to a file. Since this thread runs independently of the channel, it is possible that
the mixmonitor thread's channel pointer will point to freed memory when the channel either
is masqueraded or hangs up (technically, both cases are hangups, but we need to handle the
cases slightly differently).
The solution for this is to employ a datastore, which has the nice benefit of allowing us
to hook into channel masquerades and hangups and update our pointer as necessary. If this
looks familiar, this same technique is employed in app_chanspy. app_chanspy is a bit more
involved since it does a lot more operations on the channel that is being spied upon.
app_mixmonitor does have an extra touch that app_chanspy doesn't have, though. Since there
is a thread race between the channel's thread and the mixmonitor thread on a hangup, we em-
ploy a condition-and-boolean combination to ensure that the channel thread finishes with
our structure before the mixmonitor thread attempts to free it. No crashes!
(closes issue #14374)
Reported by: aragon
Patches:
14374.patch uploaded by putnopvut (license 60)
Tested by: aragon, putnopvut
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@173591 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r172580 | twilson | 2009-01-30 15:29:12 -0600 (Fri, 30 Jan 2009) | 44 lines
Merged revisions 172517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@172636 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r172441 | tilghman | 2009-01-29 17:15:40 -0600 (Thu, 29 Jan 2009) | 16 lines
Merged revisions 172438 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172438 | tilghman | 2009-01-29 16:54:29 -0600 (Thu, 29 Jan 2009) | 9 lines
Lose the CAP_NET_ADMIN at every fork, instead of at startup. Otherwise, if
Asterisk runs as a non-root user and the administrator does a 'restart now',
Asterisk loses the ability to set QOS on packets.
(closes issue #14004)
Reported by: nemo
Patches:
20090105__bug14004.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@172504 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r172063 | murf | 2009-01-28 13:31:06 -0700 (Wed, 28 Jan 2009) | 52 lines
Merged revisions 172030 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172030 | murf | 2009-01-28 11:51:16 -0700 (Wed, 28 Jan 2009) | 46 lines
This patch fixes h-exten running misbehavior in manager-redirected
situations.
What it does:
1. A new Flag value is defined in include/asterisk/channel.h,
AST_FLAG_BRIDGE_HANGUP_DONT, which used as a messenge to the
bridge hangup exten code not to run the h-exten there (nor
publish the bridge cdr there). It will done at the pbx-loop
level instead.
2. In the manager Redirect code, I set this flag on the channel
if the channel has a non-null pbx pointer. I did the same for the
second (chan2) channel, which gets run if name2 is set...
and the first succeeds.
3. I restored the ending of the cdr for the pbx loop h-exten
running code. Don't know why it was removed in the first place.
4. The first attempt at the fix for this bug was to place code
directly in the async_goto routine, which was called from a
large number of places, and could affect a large number of
cases, so I tested that fix against a fair number of transfer
scenarios, both with and without the patch. In the process,
I saw that putting the fix in async_goto seemed not to affect
any of the blind or attended scenarios, but still, I was
was highly concerned that some other scenarios I had not tested
might be negatively impacted, so I refined the patch to
its current scope, and jmls tested both. In the process, tho,
I saw that blind xfers in one situation, when the one-touch
blind-xfer feature is used by the peer, we got strange
h-exten behavior. So, I inserted code to swap CDRs and
to set the HANGUP_DONT field, to get uniform behavior.
5. I added code to the bridge to obey the HANGUP_DONT flag,
skipping both publishing the bridge CDR, and running
the h-exten; they will be done at the pbx-loop (higher)
level instead.
6. I removed all the debug logs from the patch before committing.
7. I moved the AUTOLOOP set/reset in the h-exten code in res_features
so it's only done if the h-exten is going to be run. A very
minor performance improvement, but technically correct.
(closes issue #14241)
Reported by: jmls
Patches:
14241_redirect_no_bridgeCDR_or_h_exten_via_transfer uploaded by murf (license 17)
Tested by: murf, jmls
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@172067 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
................
r170148 | file | 2009-01-22 12:52:21 -0400 (Thu, 22 Jan 2009) | 11 lines
Merged revisions 170147 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r170147 | file | 2009-01-22 12:50:54 -0400 (Thu, 22 Jan 2009) | 4 lines
If we are unable to request a DAHDI pseudo channel and we are using the user introduction without review option make sure it gets unset so other code does not blindly assume a DAHDI pseudo channel exists.
(closes issue #14282)
Reported by: cheesegrits
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@170150 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r170047 | file | 2009-01-22 11:01:54 -0400 (Thu, 22 Jan 2009) | 4 lines
Clear the autoloop flag when parsing and setting the context/extension/priority to go back to. When the channel executes a PBX again we want it to start out at the point we explicitly say and at that point it will not yet be doing autoloop.
(closes issue #14304)
Reported by: jcovert
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@170049 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
........
r168705 | seanbright | 2009-01-15 10:33:18 -0500 (Thu, 15 Jan 2009) | 11 lines
Add a missing unlock and properly handle the 'maxusers' setting on MeetMe
conferences. We were using the 'user number' field to compare against the
maximum allowed users, which works assuming users with lower user numbers
didn't leave the conference.
(closes issue #14117)
Reported by: sergedevorop
Patches:
20090114__bug14117-2.diff.txt uploaded by seanbright (license 71)
Tested by: sergedevorop
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@168707 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
................
r168594 | twilson | 2009-01-13 20:00:40 -0600 (Tue, 13 Jan 2009) | 27 lines
Merged revisions 168593 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r168593 | twilson | 2009-01-13 19:27:18 -0600 (Tue, 13 Jan 2009) | 20 lines
Don't overflow when paging more than 128 extensions
The number of available slots for calls in app_page was hardcoded to 128.
Proper bounds checking was not in place to enforce this limit, so if more than
128 extensions were passed to the Page() app, Asterisk would crash. This patch
instead dynamically allocates memory for the ast_dial structures and removes
the (non-functional) arbitrary limit.
This issue would have special importance to anyone who is dynamically creating
the argument passed to the Page application and allowing more than 128
extensions to be added by an outside user via some external interface.
The patch posted by a_villacis was slightly modified for some coding guidelines
and other cleanups. Thanks, a_villacis!
(closes issue #14217)
Reported by: a_villacis
Patches:
20080912-asterisk-app_page-fix-buffer-overflow.patch uploaded by a (license 660)
Tested by: otherwiseguy
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@168596 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
................
r165890 | russell | 2008-12-19 09:05:09 -0600 (Fri, 19 Dec 2008) | 17 lines
Merged revisions 165889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r165889 | russell | 2008-12-19 09:03:02 -0600 (Fri, 19 Dec 2008) | 9 lines
Ensure that the chanspy datastore is fully initialized.
This patch resolved some random crash issues observed by a user on a BSD system
(closes issue #14111)
Reported by: ys
Patches:
app_chanspy.c.diff uploaded by ys (license 281)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@165892 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r165723 | russell | 2008-12-18 13:33:42 -0600 (Thu, 18 Dec 2008) | 14 lines
Remove the need for AST_PBX_KEEPALIVE with the GoSub option from Dial.
This is part of an effort to completely remove AST_PBX_KEEPALIVE and other
similar return codes from the source. While this usage was perfectly safe,
there are others that are problematic. Since we know ahead of time that
we do not want to PBX to destroy the channel, the PBX API has been changed
so that information can be provided as an argument, instead, thus removing
the need for the KEEPALIVE return value.
Further changes to get rid of KEEPALIVE and related code is being done by
murf. There is a patch up for that on review 29.
Review: http://reviewboard.digium.com/r/98/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@165728 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
........
r165142 | mmichelson | 2008-12-17 11:52:50 -0600 (Wed, 17 Dec 2008) | 10 lines
Use the create_vm_state_from_user function in a place where
it was not being used before. Also, I've moved the urgent
folder check in messagecount() up a bit so that the flow is
a bit better.
This was something I noticed while taking a look at issue
#13973, although I don't think this is the underlying cause
of the issue.
........
r165143 | mmichelson | 2008-12-17 11:53:37 -0600 (Wed, 17 Dec 2008) | 3 lines
And actually assign the function to a pointer...
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@165146 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r164877 | russell | 2008-12-16 15:12:49 -0600 (Tue, 16 Dec 2008) | 14 lines
Merged revisions 164876 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r164876 | russell | 2008-12-16 15:10:44 -0600 (Tue, 16 Dec 2008) | 6 lines
Do not dereference the channel if AST_PBX_KEEPALIVE has been returned.
This is a bug I noticed while looking at the code for app_macro. This return code
means that another thread has assumed ownership of the channel and it can no longer
be touched. (I hate this return code with a passion, by the way.)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@164879 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
................
r162291 | russell | 2008-12-09 14:59:54 -0600 (Tue, 09 Dec 2008) | 17 lines
Merged revisions 162286 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r162286 | russell | 2008-12-09 14:57:35 -0600 (Tue, 09 Dec 2008) | 9 lines
Fix an issue where callers on an incoming call on an SLA trunk would not hear ringback.
We need to make sure that we don't start writing audio to the trunk channel until we're
actually ready to answer it. Otherwise, the channel driver will treat it as inband
progress, even though all they are getting is silence.
(closes issue #12471)
Reported by: mthomasslo
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@162302 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r161493 | mmichelson | 2008-12-05 17:24:38 -0600 (Fri, 05 Dec 2008) | 8 lines
If the autoloop flag is set on a channel, then we need to
add 1 to the priority when checking if the extension exists. Otherwise,
gosubs will fail.
This was discovered when investigating an asterisk-users mailing list post
made by Gary Hawkins.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@161496 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r161349 | seanbright | 2008-12-05 10:56:15 -0500 (Fri, 05 Dec 2008) | 5 lines
When using IMAP_STORAGE, it's important to convert bare newlines (\n) in
emailbody and pagerbody to CR-LF so that the IMAP server doesn't spit out an
error. This was informally reported on #asterisk-dev a few weeks ago. Reviewed
by Mark M. on IRC.
........
r161350 | seanbright | 2008-12-05 11:04:36 -0500 (Fri, 05 Dec 2008) | 2 lines
Use ast_free() instead of free(), pointed out by eliel on IRC.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@161352 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
https://origsvn.digium.com/svn/asterisk/trunk
........
r159554 | mmichelson | 2008-11-26 13:57:11 -0600 (Wed, 26 Nov 2008) | 19 lines
Add some necessary hangup commands in the case that forwarding
a call fails
1) Hang up the original destination if the local channel cannot
be requested.
2) Hang up the local channel (in addition to the original destination)
if ast_call fails when calling the newly created local channel.
This prevents channels from sticking around forever in the
case of a botched call forward (e.g. to an extension which does not
exist).
(closes issue #13764)
Reported by: davidw
Patches:
13764_v2.patch uploaded by putnopvut (license 60)
Tested by: putnopvut, davidw
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@159561 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r158066 | mmichelson | 2008-11-20 11:39:06 -0600 (Thu, 20 Nov 2008) | 20 lines
Merged revisions 158053 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r158053 | mmichelson | 2008-11-20 11:33:06 -0600 (Thu, 20 Nov 2008) | 12 lines
Make sure to set the hangup cause on the calling channel in the case
that ast_call() fails. For incoming SIP channels, this was causing
us to send a 603 instead of a 486 when the call-limit was reached on
the destination channel.
(closes issue #13867)
Reported by: still_nsk
Patches:
13867.diff uploaded by putnopvut (license 60)
Tested by: blitzrage
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@158067 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r157706 | kpfleming | 2008-11-19 06:42:19 -0600 (Wed, 19 Nov 2008) | 5 lines
make some corrections to the ast_agi_register_multiple(), ast_agi_unregister_multiple() and ast_agi_fdprintf() API calls to be consistent with API guidelines
also, move UPGRADE.txt to UPGRADE-1.6.txt and make the new UPGRADE.txt contain information about upgrading between Asterisk 1.6 releases
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@157719 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r157562 | mmichelson | 2008-11-18 17:28:23 -0600 (Tue, 18 Nov 2008) | 11 lines
Fix the logic for when delete=yes when IMAP storage
is in use so that the message is deleted from both
local and IMAP storage.
(closes issue #13642)
Reported by: jaroth
Patches:
deleteyes.patch uploaded by jaroth (license 50)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@157563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r157366 | jpeeler | 2008-11-18 13:16:00 -0600 (Tue, 18 Nov 2008) | 14 lines
Merged revisions 157365 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r157365 | jpeeler | 2008-11-18 13:13:33 -0600 (Tue, 18 Nov 2008) | 6 lines
(closes issue #13899)
Reported by: akkornel
This fix is the result of a bug fix in ast_app_separate_args r124395. If an argument does not exist it should always be set to a null string rather than a null pointer.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@157367 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r157306 | mmichelson | 2008-11-18 12:31:08 -0600 (Tue, 18 Nov 2008) | 20 lines
Merged revisions 157305 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r157305 | mmichelson | 2008-11-18 12:25:55 -0600 (Tue, 18 Nov 2008) | 12 lines
Fix a crash in the end_bridge_callback of app_dial and
app_followme which would occur at the end of an attended
transfer. The error occurred because we initially stored
a pointer to an ast_channel which then was hung up due
to a masquerade.
This commit adds a "fixup" callback to the bridge_config
structure to allow for end_bridge_callback_data to be
changed in the case that a new channel pointer is needed
for the end_bridge_callback.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@157308 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r157253 | tilghman | 2008-11-17 16:25:06 -0600 (Mon, 17 Nov 2008) | 8 lines
Can't use items duplicated off the stack frame in an element returned from
a function: in these cases, we have to use the heap, or garbage will result.
(closes issue #13898)
Reported by: alecdavis
Patches:
20081114__bug13898__2.diff.txt uploaded by Corydon76 (license 14)
Tested by: alecdavis
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@157255 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r156817 | mmichelson | 2008-11-14 09:20:03 -0600 (Fri, 14 Nov 2008) | 18 lines
Merged revisions 156816 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r156816 | mmichelson | 2008-11-14 09:18:59 -0600 (Fri, 14 Nov 2008) | 10 lines
If the prompt to reenter a voicemail password timed out, it
resulted in the password not being saved, even if the input matched
what you gave when first prompted to enter a new password. This is
because the return value of ast_readstring was checked, but not checked
properly.
This bug was discovered by Jared Smith during an Asterisk training course.
Thanks for reporting it!
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@156819 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r156756 | tilghman | 2008-11-13 18:43:13 -0600 (Thu, 13 Nov 2008) | 13 lines
Merged revisions 156755 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r156755 | tilghman | 2008-11-13 18:41:37 -0600 (Thu, 13 Nov 2008) | 6 lines
ast_waitfordigit() requires that the channel be up, for no good logical
reason. This prevents While/EndWhile from working within the "h"
extension.
Reported by: jgalarneau (for ABE C.2)
Fixed by: me
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@156757 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r156228 | jpeeler | 2008-11-12 12:32:46 -0600 (Wed, 12 Nov 2008) | 16 lines
Merged revisions 156178 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r156178 | jpeeler | 2008-11-12 11:53:44 -0600 (Wed, 12 Nov 2008) | 8 lines
(closes issue #13173)
Reported by: pep
This change adds an announce_thread responsible for playing announcements to an existing conference. This allows all announcing to be immediately stopped if necessary but more importantly allows other threads that need to play something to not block. There are multiple benefits to this, but the actual bug is for solving the scenario for a channel to be unusable after hang up for the entire duration of the parting announcement. The parting announcement can be extremely long depending on what the user recorded upon joining the conference.
Reviewed by Russell on Review Board:
http://reviewboard.digium.com/r/25/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@156247 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r156169 | mmichelson | 2008-11-12 11:41:56 -0600 (Wed, 12 Nov 2008) | 15 lines
Merged revisions 156167 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r156167 | mmichelson | 2008-11-12 11:38:33 -0600 (Wed, 12 Nov 2008) | 7 lines
When doing some tests, I was having a crash at the end of every call
if an attended transfer occurred during the call. I traced the cause to
the CDR on one of the channels being NULL. murf suggested a check in
the end bridge callback to be sure the CDR is non-NULL before proceeding,
so that's what I'm adding.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@156171 65c4cc65-6c06-0410-ace0-fbb531ad65f3
------------------------------------------------------------------------
r153709 | kpfleming | 2008-11-02 17:34:39 -0600 (Sun, 02 Nov 2008) | 3 lines
instead of trying to forcibly load res_agi when app_stack is loaded (even if the administrator didn't want it loaded), use GCC weak symbols to determine whether it was loaded already or not; if it was loaded, then use it.
------------------------------------------------------------------------
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@153711 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r153181 | twilson | 2008-10-31 13:55:33 -0500 (Fri, 31 Oct 2008) | 5 lines
Recent CDR fixes moved execution of the 'h' exten into the bridging code, so variables that were set after ast_bridge_call was called would not show up in the 'h' exten. Added a callback function to handle setting variables, etc. from w/in the bridging code. Calls back into a nested function within the function calling ast_bridge_call
(closes issue #13793)
Reported by: greenfieldtech
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@153266 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r152646 | mmichelson | 2008-10-29 15:53:53 -0500 (Wed, 29 Oct 2008) | 9 lines
If there was no named defined in a voicemail.conf mailbox
entry, then app_directory would crash when attempting to
read that entry from the file. We now check for the NULL
or empty string properly so that there will be no crash.
(closes issue #13804)
Reported by: bluecrow76
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@152648 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r152605 | murf | 2008-10-28 23:47:13 -0600 (Tue, 28 Oct 2008) | 22 lines
Merged revisions 152538 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152538 | murf | 2008-10-28 23:19:04 -0600 (Tue, 28 Oct 2008) | 14 lines
A little documentation cross-ref between features and
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@152606 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r152536 | murf | 2008-10-28 23:01:00 -0600 (Tue, 28 Oct 2008) | 57 lines
Merged revisions 152535 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines
The magic trick to avoid this crash is not to
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.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@152537 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r152369 | tilghman | 2008-10-28 12:07:39 -0500 (Tue, 28 Oct 2008) | 15 lines
Merged revisions 152368 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152368 | tilghman | 2008-10-28 12:04:56 -0500 (Tue, 28 Oct 2008) | 8 lines
Reset all DIAL variables back to blank, in case Dial is called multiple times
per call (which could otherwise lead to inconsistent status reports).
(closes issue #13216)
Reported by: ruddy
Patches:
20081014__bug13216.diff.txt uploaded by Corydon76 (license 14)
Tested by: ruddy
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@152370 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r151371 | tilghman | 2008-10-21 10:20:50 -0500 (Tue, 21 Oct 2008) | 5 lines
Default file modes should always be full read and write, to allow the system
administrator to make the decision of what permissions will actually be given,
through the use of the process umask.
(Closes issue# 13751)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@151372 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r151101 | kpfleming | 2008-10-19 22:11:28 +0300 (Sun, 19 Oct 2008) | 13 lines
cleaup of the TCP/TLS socket API:
1) rename 'struct server_args' to 'struct ast_tcptls_session_args', to follow coding guidelines
2) make ast_make_file_from_fd() static and rename it to something that indicates what it really is for (again coding guidelines)
3) rename address variables inside 'struct ast_tcptls_session_args' to be more descriptive (dare i say it... coding guidelines)
4) change ast_tcptls_client_start() to use the new 'remote_address' field of the session args for the destination of the connection, and use the 'local_address' field to bind() the socket to the proper source address, if one is supplied
5) in chan_sip, ensure that we pass in the PP address we are bound to when creating outbound (client) connections, so that our connections will appear from the correct address
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@151135 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r149201 | mmichelson | 2008-10-14 17:41:13 -0500 (Tue, 14 Oct 2008) | 20 lines
Merged revisions 149200 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r149200 | mmichelson | 2008-10-14 17:40:42 -0500 (Tue, 14 Oct 2008) | 12 lines
Update the queue with the correct number of calls and
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@149203 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r148200 | seanbright | 2008-10-09 20:42:13 -0400 (Thu, 09 Oct 2008) | 12 lines
Don't include logger.h in asterisk.h by default as it is causing problems building
app_voicemail. Instead, include it where it is needed. This turned out to be a
relatively minor issue because other headers include logger.h as well.
Need to test -addons before merging this back to 1.6.0.
(closes issue #13605)
Reported by: tomo1657
Patches:
13605_seanbright.diff uploaded by seanbright (license 71)
Tested by: mmichelson
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@148240 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r148144 | mmichelson | 2008-10-09 18:30:47 -0500 (Thu, 09 Oct 2008) | 10 lines
Read the callerid in the correct order and make sure to
read the Urgent flag value from the IMAP headers.
(closes issue #13652)
Reported by: jaroth
Patches:
imapheaders.patch uploaded by jaroth (license 50)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@148151 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r147592 | tilghman | 2008-10-08 14:08:32 -0500 (Wed, 08 Oct 2008) | 8 lines
Correct a typo in the help; also, ensure that the date and time are correctly
set, if not specified in the message.
(Closes issue #13594, closes issue #13595)
Reported by: alecdavis
Patches:
20081001__bug13595.diff.txt uploaded by Corydon76 (license 14)
Tested by: alecdavis
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@147593 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r147050 | seanbright | 2008-10-07 08:01:36 -0400 (Tue, 07 Oct 2008) | 8 lines
Make sure to compare the correct number of characters when special-casing
our DAHDI operator mode stuff. Technically, it would work fine, as 'DAH'
is currently unique amongst our channel technologies, but as Jared points
out:
<@jsmith> Sure... as long as the technology starts whith DAH.... but
it could be DAHDOO!
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@147052 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r146802 | tilghman | 2008-10-06 16:09:05 -0500 (Mon, 06 Oct 2008) | 15 lines
Merged revisions 146799 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r146799 | tilghman | 2008-10-06 15:52:04 -0500 (Mon, 06 Oct 2008) | 8 lines
Dialplan functions should not actually return 0, unless they have modified the
workspace. To signal an error (and no change to the workspace), -1 should be
returned instead.
(closes issue #13340)
Reported by: kryptolus
Patches:
20080827__bug13340__2.diff.txt uploaded by Corydon76 (license 14)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@146838 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r144569 | murf | 2008-09-25 16:21:28 -0600 (Thu, 25 Sep 2008) | 14 lines
(closes issue #13557)
Reported by: nickpeirson
The user attached a patch, but the license is not yet
recorded. I took the liberty of finding and replacing
ALL index() calls with strchr() calls, and that
involves more than just main/pbx.c;
chan_oss, app_playback, func_cut also had calls
to index(), and I changed them out. 1.4 had no
references to index() at all.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@144578 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r142676 | murf | 2008-09-11 22:50:48 -0600 (Thu, 11 Sep 2008) | 40 lines
Merged revisions 142675 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142675 | murf | 2008-09-11 22:29:34 -0600 (Thu, 11 Sep 2008) | 29 lines
Tested by: sergee, murf, chris-mac, andrew, KNK
This is a "second attempt" to restore the previous "endbeforeh" behavior
in 1.4 and up. In order to capture information concerning all the
legs of transfers in all their infinite combinations, I was forced
to this particular solution by a chain of logical necessities, the
first being that I was not allowed to rewrite the CDR mechanism from
the ground up!
This change basically leaves the original machinery alone, which allows
IVR and local channel type situations to generate CDR's as normal, but
a channel flag can be set to suppress the normal running of the h exten.
That flag would be set by the code that runs the h exten from the
ast_bridge_call routine, to prevent the h exten from being run twice.
Also, a flag in the ast_bridge_config struct passed into ast_bridge_call
can be used to suppress the running of the h exten in that routine. This
would happen, for instance, if you use the 'g' option in the Dial app.
Running this routine 'early' allows not only the CDR() func to be used
in the h extension for reading CDR variables, but also allows them to
be modified before the CDR is posted to the backends.
While I dearly hope that this patch overcomes all problems, and
introduces no new problems, reality suggests that surely someone
will have problems. In this case, please re-open 13251 (or 13289),
and we'll see if we can't fix any remaining issues.
** trunk note: some code to suppress the h exten being run
from app_queue was added; for the 'continue' option available
only in trunk/1.6.x.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@142678 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r141998 | mmichelson | 2008-09-09 07:32:38 -0500 (Tue, 09 Sep 2008) | 7 lines
Use ast_debug for debug messages. I was wondering why debug
messages weren't showing up when I had set the debug level
high for just app_queue.c. It's because we were only checking
the global option_debug variable instead of using the awesome
macro which checks both the global and file-specific value
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@142001 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r140489 | mmichelson | 2008-08-29 12:47:17 -0500 (Fri, 29 Aug 2008) | 30 lines
Merged revisions 140488 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r140488 | mmichelson | 2008-08-29 12:34:17 -0500 (Fri, 29 Aug 2008) | 22 lines
After working on the ao2_containers branch, I noticed
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@140490 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r140422 | mmichelson | 2008-08-29 11:06:09 -0500 (Fri, 29 Aug 2008) | 20 lines
Merged revisions 140421 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r140421 | mmichelson | 2008-08-29 11:01:07 -0500 (Fri, 29 Aug 2008) | 12 lines
Add context checking when retrieving a vm_state.
This was causing a problem for people who had identically
named mailboxes in separate voicemail contexts.
This commit affects IMAP storage only.
(closes issue #13194)
Reported by: moliveras
Patches:
13194.patch uploaded by putnopvut (license 60)
Tested by: putnopvut, moliveras
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@140425 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r139627 | murf | 2008-08-22 16:03:13 -0600 (Fri, 22 Aug 2008) | 59 lines
Merged revisions 139347 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r139347 | murf | 2008-08-21 17:03:50 -0600 (Thu, 21 Aug 2008) | 47 lines
(closes issue #13251)
Reported by: sergee
Tested by: murf
THis is a bold move for a static release fix, but I wouldn't have
made it if I didn't feel confident (at least a *bit* confident)
that it wouldn't mess everyone up.
The reasoning goes something like this:
1. We simply cannot do anything with CDR's at the current point
(in pbx.c, after the __ast_pbx_run loop). It's way too late to
have any affect on the CDRs. The CDR is already posted and gone,
and the remnants have been cleared.
2. I was very much afraid that moving the running of the 'h'
extension down into the bridge code (where it would be now
practical to do it), would result in a lot more calls to the
'h' exten, so I implemented it as another exten under another
name, but found, to my pleasant surprise, that there was a
1:1 correspondence to the running of the 'h' exten in the
pbx_run loop, and the new spot at the end of the bridge.
So, I ifdef'd out the current 'h' loop, and moved it into
the bridge code. The only difference I can see is the stuff
about the AST_PBX_KEEPALIVE, and hopefully, if this
is still an important decision point, I can replicate it
if there are complaints. To be perfectly honest,
the KEEPALIVE situation is not totally clear to me,
and how it relates to a post-bridge situation is less
clear. I suspect the users will point out everything
in total clarity if this steps on anyone's toes!
3. I temporarily swap the bridge_cdr into the channel
before running the 'h' exten, which makes it possible
for users to edit the cdr before it goes out the door.
And, of course, with the endbeforehexten config var set,
the users can also get at the billsec/duration vals.
After the h exten finishes, the cdr is swapped back
and processing continues as normal.
Please, all who deal with CDR's, please test this version
of Asterisk, and file bug reports as appropriate!
........
I also made a little fix to the app_dial's 'e' option,
that is related to my updates.
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@139629 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r139215 | russell | 2008-08-20 17:16:36 -0500 (Wed, 20 Aug 2008) | 19 lines
Merged revisions 139213 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r139213 | russell | 2008-08-20 17:14:35 -0500 (Wed, 20 Aug 2008) | 11 lines
Fix a crash in the ChanSpy application. The issue here is that if you call
ChanSpy and specify a spy group, and sit in the application long enough looping
through the channel list, you will eventually run out of stack space and the
application with exit with a seg fault. The backtrace was always inside of
a harmless snprintf() call, so it was tricky to track down. However, it turned
out that the call to snprintf() was just the biggest stack consumer in this
code path, so it would always be the first one to hit the boundary.
(closes issue #13338)
Reported by: ruddy
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@139217 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r138887 | mmichelson | 2008-08-19 13:52:04 -0500 (Tue, 19 Aug 2008) | 31 lines
Merged revisions 138886 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r138886 | mmichelson | 2008-08-19 13:50:53 -0500 (Tue, 19 Aug 2008) | 23 lines
Add a lock and unlock prior to the destruction of the chanspy_ds
lock to ensure that no other threads still have it locked. While
this should not happen under normal circumstances, it appears that
if the spyer and spyee hang up at nearly the same time, the following
may occur.
1. ast_channel_free is called on the spyee's channel.
2. The chanspy datastore is removed from the spyee's channel in
ast_channel_free.
3. In the spyer's thread, the spyer attempts to remove and destroy the datastore
from the spyee channel, but the datastore has already been removed in step 2,
so the spyer continues in the code.
4. The spyee's thread continues and calls the datastore's destroy callback,
chanspy_ds_destroy. This involves locking the chanspy_ds.
5. Now the spyer attempts to destroy the chanspy_ds lock. The problem is that in step 4,
the spyee has locked this lock, meaning that the spyer is attempting to destroy a lock
which is currently locked by another thread.
The backtrace provided in issue #12969 supports the idea that this is possible
(and has even occurred). This commit does not close the issue, but should help
in preventing one type of crash associated with the use of app_chanspy.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@138888 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r138687 | mmichelson | 2008-08-18 15:04:10 -0500 (Mon, 18 Aug 2008) | 18 lines
Merged revisions 138685 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r138685 | mmichelson | 2008-08-18 15:01:14 -0500 (Mon, 18 Aug 2008) | 10 lines
Change the inequalities used in app_queue with regards
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@138689 65c4cc65-6c06-0410-ace0-fbb531ad65f3
trunk.
For an explanation of what "imap_consistency" is,
please see svn revision 134223 to the 1.4 branch.
Coincidentally, this also fixes a recent bug report
regarding the inability to save messages to the new
folder when using IMAP storage since they will would
be flagged as "seen" and not be recognized as new
messages.
(closes issue #13234)
Reported by: jaroth
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@136715 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r135799 | murf | 2008-08-05 17:13:20 -0600 (Tue, 05 Aug 2008) | 34 lines
(closes issue #12982)
Reported by: bcnit
Tested by: murf
I discovered that also, in the previous bug fixes and changes,
the cdr.conf 'unanswered' option is not being obeyed, so
I fixed this.
And, yes, there are two 'answer' times involved in this
scenario, and I would agree with you, that the first
answer time is the time that should appear in the CDR.
(the second 'answer' time is the time that the bridge
was begun).
I made the necessary adjustments, recording the first
answer time into the peer cdr, and then using that to
override the bridge cdr's value.
To get the 'unanswered' CDRs to appear, I purposely
output them, using the dial cmd to mark them as
DIALED (with a new flag), and outputting them if
they bear that flag, and you are in the right mode.
I also corrected one small mention of the Zap device
to equally consider the dahdi device.
I heavily tested 10-sec-wait macros in dial, and
without the macro call; I tested hangups while the
macro was running vs. letting the macro complete
and the bridge form. Looks OK. Removed all the
instrumentation and debug.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@135821 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Mark Michelson
Tilghman Lesher
Terry Wilson
Steve Murphy
Sean Bright
Joshua Colp
Russell Bryant
Olle Johansson
BJ Weschke
Jeff Peeler
Matthew Nicholson
Kevin P. Fleming
Jason Parker
Michiel van Baak