Dynamic features defined in the applicationmap section of features.conf allow
one to specify whether the caller, callee, or both have the ability to use the
feature. The documentation in the features.conf.sample file could be interpreted
to mean that one only needs to set the DYNAMIC_FEATURES channel variable on the
calling channel in order to allow for the callee to be able to use the features
which he should have permission to use. However, the DYNAMIC_FEATURES variable
would only be read from the channel of the participant that pressed the DTMF
sequence to activate the feature. The result of this was that the callee was
unable to use dynamic features unless the dialplan writer had taken measures
to be sure that the DYNAMIC_FEATURES variable was set on the callee's channel.
This commit changes the behavior of ast_feature_interpret to concatenate the
values of DYNAMIC_FEATURES from both parties involved in the bridge. The features
themselves determine who has permission to use them, so there is no reason to believe
that one side of the bridge could gain the ability to perform an action that they
should not have the ability to perform.
Kevin Fleming pointed out on the asterisk-users list that the typical way that this
was worked around in the past was by setting _DYNAMIC_FEATURES on the calling channel
so that the value would be inherited by the called channel. While this works, the
documentation alone is not enough to figure out why this is necessary for the callee
to be able to use dynamic features. In this particular case, changing the code to match
the documentation is safe, easy, and will generally make things easier for people for
future installations.
This bug was originally reported on the asterisk-users list by David Ruggles.
(closes issue #14657)
Reported by: mmichelson
Patches:
14657.patch uploaded by mmichelson (license 60)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@181990 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The main problem here was that cstdlib was undefining free thereby causing the
proper debug macros to not be used. ast_h323.cxx has been changed to call
ast_free instead to avoid the issue. Because using the ast prefix calls are
a better choice, ast_free_ptr is the new wrapper for free to pass to functions.
Also, a little bit of clean up was done to avoid the debug macros intentionally
being redefined.
(closes issue #13593)
Reported by: pj
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@181133 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It is possible for a masquerade operation to occur when the 'h' exten is operating. This operation moves
the CDR records around causing the bridge_cdr to no longer exist on the channel where it is expected to.
We can not safely modify it afterwards because of this, so don't even try.
(closes issue #14564)
Reported by: meric
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@179840 65c4cc65-6c06-0410-ace0-fbb531ad65f3
As per bug 14515, a dev discussion arrived at a "mediated concensus"
of a default feature digit timeout of 1.0 sec. Some voted for 1300;
ctooley thought 1500 for distracted phone users in phone booths;
kpfleming put his foot down at 1.0 sec.
Users who found the previous default max delay of 250 msec perfect,
are welcome to override the new default. Notice that I said that
250 msec was the default; wait a minute, you might say, the config
file said it was 500 msec!; well, because of the bug fix for 14515,
we found that 500 msec was actually enforcing a max of 250. The bug
fix would restore 500 msec, but we felt even that was a bit tight
for most users... 2000 msec was pushed earlier by mmichelson, so
that reduces to 1000 msec after the bug fix. Enjoy!
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@178956 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Because the ast_channel_bridge() call will return 0 and pass
a frame pointer for both DTMF_BEGIN and DTMF_END, the feature_timer
field in hte config struct is getting decremented twice, which
effectively cuts the digittimeout in half. I added conditions
to the if statement to only let DTMF_END frames to flow thru,
which solved the problem. Also, when the frame pointer is null,
let control flow thru-- this usually happens on timeouts. I added
a comment to the code to explain what's going on and why.
Many thanks to sodom for reporting this problem. Personnally, it always seemed
like something was wrong with the featuredigittimeout, but I never
could quite decide what... and was too busy to investigate.
This bug forced the issue, and now we know.
Sodom had other issues in 14515, but I couldn't reproduce them. If
he still has problems, and wants to get them solved, he is welcome
to reopen 14515.
(closes issue #14515)
Reported by: sodom
Patches:
14515.patch uploaded by murf (license 17)
Tested by: murf, sodom
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@178804 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The main problem is currently if the Dial flag L is used with a warning sound,
DTMF is not evaluated after the first warning sound. To fix this, a flag has
been added in ast_generic_bridge for playing the warning which ensures that if
a scheduled warning is missed, multiple warrnings are not played back (due to a
feature evaluation or waiting for digits). ast_channel_bridge was modified to
store the nexteventts in the ast_bridge_config structure as that information
was lost every time ast_channel_bridge was reentered, causing a hangup due to
incorrect time calculations.
(closes issue #14315)
Reported by: tim_ringenbach
Reviewed on reviewboard:
http://reviewboard.digium.com/r/163/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@176701 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the parker information can not be obtained from the peer, try and see if
the BLINDTRANSFER channel variable has been set. Previously, a blind transfer
to the ParkAndAnnounce app would return nothing for the From.
Closes AST-189
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@175294 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The peer may not necessarily exist, such as in the case of a transfer to
ParkAndAnnounce. In this case don't try to play a sound to it.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@175187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
parking failure.
Parking attempts made using either one-touch, or doing either a blind or
assisted transfer to the parking extension now keep up the bridge instead of
hanging up the attempted parked party. Normal causes for the parking attempt
to fail includes the specific specified extension (via PARKINGEXTEN) not being
available or if all the parking spaces are currently in use. To avoid having
to reverse a masquerade park_space_reserve was made to provide foresight if
a parking attempt will succeed and if so reserve the parking space.
(closes issue #13494)
Reported by: mdu113
Reviewed by Russell: http://reviewboard.digium.com/r/133/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@173211 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
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
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
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
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
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
Reported by: krtorio
I made a small change to the code that handles local channel situations.
In that code, I copy the answer time from the peer cdr, to the bridge_cdr,
but I wasn't also copying the disposition from the peer cdr.
So, Now I copy the disposition, and I've tested against
these cases:
1. phone 1 never answers the phone; no cdr is generated at all.
this should show up as a manager command failure or something.
2. phone 2 never answers. CDR is generated, says NO ANSWER
3. phone 2 is busy. CDR is generated, says BUSY
4. phone 2 answers: CDR is generated, times are correct; disposition
is ANSWERED, which is correct. The start time is the time that
the manager dialed the first phone. The answer time is the time
the second phone picks up.
I purposely left the cid and src fields blank; since this call really
originates from the manager, there is no 'easy' data to put in these
fields. If you feel strongly that these fields should be filled in,
re-open this bug and I'll dig further.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@142474 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fixes multiple parking problems:
Crash when executing a park on an extension dialed by AGI due to not returning the proper return code.
Crash when using a builtin feature that was a subset of a enabled dynamic feature.
Crash due to always hanging up the peer despite the fact that the peer was supposed to be parked.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@141028 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I merged them into trunk, so I'm coming back to clean up.
And, in the process, I found an error in the code I added
to trunk and 1.6.x, that I'll fix using this patch also.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@139635 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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!
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@139347 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@135799 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: greyvoip
Tested by: murf
OK, a few days of debugging, a bunch of instrumentation
in chan_sip, main/channel.c, main/pbx.c, etc. and 5 solid
notebook pages of notes later, I have made the small
tweek necc. to get the start time right on the second
CDR when:
A Calls B
B answ.
A hits Xfer button on sip phone,
A dials C and hits the OK button,
A hangs up
C answers ringing phone
B and C converse
B and/or C hangs up
But does not harm the scenario where:
A Calls B
B answ.
B hits xfer button on sip phone,
B dials C and hits the OK button,
B hangs up
C answers ringing phone
A and C converse
A and/or C hangs up
The difference in start times on the second CDR is because
of a Masquerade on the B channel when the xfer number is
sent. It ends up replacing the CDR on the B channel with
a duplicate, which ends up getting tossed out. We keep
a pointer to the first CDR, and update *that* after the
bridge closes. But, only if the CDR has changed.
I hope this change is specific enough not to muck
up any current CDR-based apps. In my defence, I
assert that the previous information was wrong,
and this change fixes it, and possibly other
similar scenarios.
I wonder if I should be doing the same thing
for the channel, as I did for the peer, but
I can't think of a scenario this might affect.
I leave it, then, as an exersize for the users,
to find the scenario where the chan's CDR
changes and loses the proper start time.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@134883 65c4cc65-6c06-0410-ace0-fbb531ad65f3
