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
Blindtransfer also was calling back the wrong channel when a timeout occurred.
This should be the last of these, as there are no more masq_park_announce calls
that aren't passing orig_chan_name
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@169868 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since we removed the AST_PBX_KEEPALIVE return value, we need to use masqueraded
parking, otherwise we will try to call ast_hangup() in __pbx_run() and in
do_parking_thread() and then promptly crash.
(closes issue #14215)
Reported by: waverly360
Tested by: otherwiseguy
(closes issue #14228)
Reported by: kobaz
Tested by: otherwiseguy
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@168716 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
The issue that was reported was about a case where a RINGING channel got
redirected to an extension to pick up a call from parking. Once the parked
call got taken out of parking, it heard silence until the other side answered.
Ideally, the caller that was parked would get a ringing indication. This patch
fixes this case so that the caller receives ringback once it comes out of
parking until the other side answers.
The fixes are:
- Make sure we remember that a channel was an outgoing channel when doing
a masquerade. This prevents an erroneous ast_answer() call on the channel,
which causes a bogus 200 OK to be sent in the case of SIP.
- Add some additional comments to explain related parts of code.
- Update the handling of the ast_channel visible_indication field. Storing
values that are not stateful is pointless. Control frames that are events
or commands should be ignored.
- When a bridge first starts, check to see if the peer channel needs to be
given ringing indication because the calling side is still ringing.
- Rework ast_indicate_data() a bit for the sake of readability.
(closes issue #13747)
Reported by: davidw
Tested by: russell
Review: http://reviewboard.digium.com/r/90/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@164201 65c4cc65-6c06-0410-ace0-fbb531ad65f3
a custom feature at a time. This was especially problematic when custom
features ran for any appreciable amount of time.
The fix turned out to be quite simple. The dynamic features are now stored
in a read/write list instead of a list using a mutex.
(closes issue #13478)
Reported by: neutrino88
Fix suggested by file
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@163092 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: clegall_proformatique
Ensure that moh_generate does not return prematurely before local_ast_moh_stop is called. Also, the sleep in mp3_spawn now only occurs for http locations since it seems to have been added originally only for failing media streams.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@162874 65c4cc65-6c06-0410-ace0-fbb531ad65f3
since this branch already had some printf format attributes, enable checking for them and tag functions that didn't have them
format attributes in a consistent way
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@159808 65c4cc65-6c06-0410-ace0-fbb531ad65f3
merging the fix into 1.6.0 and realized I missed
the code in the h-exten block, and didn't catch it
because my test case had the h-exten commented out.
So, this corrects the code I missed, as a
preventative against another crash report.
Tested with the h-exten defined, all is well.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@158603 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: mdu113
This one is totally my fault. The code doesn't even
create a bridge if the channel CDR has POST_DISABLED.
I didn't check for that at the end of the bridge.
Fixed with a few small insertions. Tested. Looks
good. No cdr generated, no crash, no unnecc. data
objects created either.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@158483 65c4cc65-6c06-0410-ace0-fbb531ad65f3
with this build system change, if (and only if) --enable-dev-mode was used and DONT_OPTIMIZE is turned on, when a source file is compiled it will actually be preprocessed (into a .i or .ii file), then compiled once with optimization (with the result sent to /dev/null) and again without optimization (but only if the first compile succeeded, of course).
while making these changes, i did some cleanup work in Makefile.rules to move commonly-used combinations of flag variables into their own variables, to make the file easier to read and maintain
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@157859 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
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@152535 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The problem was that if someone parked a call, the callee and caller would both get assigned the builtin transfer feature, which would not only be potentially giving someone the ability to transfer themselves when they shouldn't have it, but would also dissallow reinviting the media off of the call.
(closes issue #12854)
Reported by: davidw
Patches:
parkingfix4.diff.txt uploaded by otherwiseguy
Tested by: davidw, otherwiseguy
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@151763 65c4cc65-6c06-0410-ace0-fbb531ad65f3
bridge with peer completely GONE.
I moved the channel find call up to cover the
whole peer CDR reset code segment. This appears
to solve the crash without changing the logic
at all.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@150637 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: krisk84
Tested by: krisk84
This change prevents a call that is placed in the parkinglot to be picked up before the PBX is finished. If another extension dials the parking extension before the PBX thread has completed at minimum warnings will occur about the PBX not properly being terminated. At worst, a crash could occur.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@147941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@146799 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: dwagner
(closes issue #13584)
Reported by: dwagner
Tested by: murf, putnopvut
The thought occurred to me that the res= from the extension spawn
was ending up being returned from the bridge.
"Thou shalt not poison the return value". Made the change
and it appears to allow blind xfers to work as normal.
If I'm wrong, reopen the bugs. But it looks good to me!
Many thanks to putnopvut for helping me reproduce this!
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@146026 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: DougUDI
Tested by: murf
(closes issue #13490)
Reported by: seanbright
Tested by: murf
(closes issue #13467)
Reported by: edantie
Tested by: murf, edantie, DougUDI
This crash happens because we are unsafely handling old pointers.
The channel whose cdr is being handled, has been hung up and
destroyed already. I reorganized the code a bit, and tried not
to lose the fork-cdr-chain concepts of the previous code.
I now verify that the 'previous' channel (the channel we
had when the bridge was started), still exists, by looking it up
by name in the channel list. I also do not try to reset the
CDR's of channels involved in bridges.
Testing shows it solves the crash problem, and should not
negatively impact previous fixes involving CDR's generated
during/after blind transfers. (The reason we need to reset
the CDR's on the "beginning" channels in the first place).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@144066 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: mdu113
Patches:
bug13493.diff uploaded by jpeeler (license 325)
Tested by: mdu113
Changed park_call_full to hold the parkinglot lock a little longer, which protects the parkeduser struct from being freed out from underneath. Made sure that the parking extension is added to the parking context while holding the lock thereby ensuring that there are no spurious warnings from removal attempts when a hangup occurs while the parking lot is being announced.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@143270 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(closes issue #13425)
Reported by: mdu113
Patches:
bug13425.diff uploaded by jpeeler (license 325)
Tested by: mdu113
The main change here was to masquerade the channel if the channel that was to be parked was running a PBX on it. The PBX thread can then maintain full control of the channel (the zombie) as it expects to while allowing the parking thread full control of the real (parked) channel.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@143204 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@142675 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: mdu113
Well, fundamentally, the problems revealed in 13364 are
because of the ForkCDR call that is done before the dial.
When the bridge is in place, it's dealing with the first
(and wrong) cdr in the list.
So, I wrote a little func to zip down to the first non-locked
cdr in the chain, and thru-out the ast_bridge_call, these
results are used instead of raw chan->cdr and peer->cdr pointers.
This shouldn't affect anyone who isn't forking cdrs before a
dial, and should correct the cdr's of those that do.
So, this change ends up correcting the dstchannel
and userfield; the disposition was fixed by a previous
patch, it was OK coming into this problem.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@142575 65c4cc65-6c06-0410-ace0-fbb531ad65f3
