issue #13363 (related to issue #6176). When a hangup occurs during a Macro
execution in earlier 1.4, the h extension would execute within the Macro
context, whereas it was always supposed to execute only within the main context
(where Macro was called). So this fix checks for an "h" extension in the
deepest macro context where a hangup occurred; if it exists, that "h" extension
executes, otherwise the main context "h" is executed.
(closes issue #14122)
Reported by: wetwired
Patches:
20090210__bug14122.diff.txt uploaded by Corydon76 (license 14)
Tested by: andrew
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@174885 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The new option is "imapvmshareid" which is an ID to tag multiple mailboxes
using the same IMAP storage location to function as one mailbox. This allows
all messages to be retrieved for any user in the group. The patch alters the
'X-Asterisk-VM-Extension' header that is responsible for matching voicemails
for a given user.
(closes issue #13673)
Reported by: howardwilkinson
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@173696 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@173692 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@173559 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@172517 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@172438 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@172030 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* 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.4@168628 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@168593 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@166093 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: tzafrir
Replace a bunch of if defined checks for Zaptel/DAHDI through several new defines in dahdi_compat.h. This removes a lot of code duplication. Example from bug:
#ifdef HAVE_ZAPTEL
fd = open("/dev/zap/pseudo", O_RDWR);
#else
fd = open("/dev/dahdi/pseudo", O_RDWR);
#endif
is replaced with:
fd = open(DAHDI_FILE_PSEUDO, O_RDRW);
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@165991 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@165889 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@164876 65c4cc65-6c06-0410-ace0-fbb531ad65f3
can better detect an exceptional case. This follows on to the changes made
in revision 156386. Related to issue #13851.
(closes issue #13974)
Reported by: paradise
Patches:
20081208__bug13974.diff.txt uploaded by Corydon76 (license 14)
Tested by: file, blitzrage, ZX81
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@164082 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@163080 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@162286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@158053 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@157365 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@157305 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@156816 65c4cc65-6c06-0410-ace0-fbb531ad65f3
