https://origsvn.digium.com/svn/asterisk/trunk
................
r239839 | jpeeler | 2010-01-13 13:48:16 -0600 (Wed, 13 Jan 2010) | 18 lines
Merged revisions 239838 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r239838 | jpeeler | 2010-01-13 13:43:33 -0600 (Wed, 13 Jan 2010) | 11 lines
Fix regression for timed out parked call returning to caller
This issue seems to have been exposed by the fix in 160390 whereby using a
masquerade prevented a crash. The new channel used in the masquerade was
not copying the macro information from the old channel.
(closes issue #15459)
Reported by: djrodman
Patches:
patch_15459.txt uploaded by mnick (license )
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@239842 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r238134 | jpeeler | 2010-01-06 13:05:06 -0600 (Wed, 06 Jan 2010) | 10 lines
Fix channel name comparison for bridge application.
The channel name comparison was not comparing the whole string and therefore
if one channel name was a substring of the other, the bridge would fail.
(closes issue #16528)
Reported by: telecos82
Patches:
res_features_r236843.diff uploaded by telecos82 (license 687)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@238135 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r231095 | jpeeler | 2009-11-24 12:50:36 -0600 (Tue, 24 Nov 2009) | 11 lines
Fix erroneous hangup extension execution
ast_spawn_extension behaves differently from 1.4 in that hangups and extensions
that do not exist do not return an error, whereas in 1.6 it does. This is now
taken into account so that the AST_FLAG_BRIDGE_HANGUP_RUN flag gets set
properly.
(closes issue #16106)
Reported by: ajohnson
Tested by: ajohnson
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@231096 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r230628 | mnicholson | 2009-11-20 15:01:10 -0600 (Fri, 20 Nov 2009) | 15 lines
Merged revisions 230627 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r230627 | mnicholson | 2009-11-20 14:53:06 -0600 (Fri, 20 Nov 2009) | 8 lines
Copy the peer CDR's userfield to the bridge CDR if it exists. This is necessary for the recordagentcalls option in chan_agent to store the recorded file name in the bridge CDR.
(closes issue #14590)
Reported by: msetim
Patches:
queue_agent_userfield.patch uploaded by Laureano (license 265)
Tested by: Laureano, mnicholson
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@230631 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r203376 | russell | 2009-06-25 16:04:55 -0500 (Thu, 25 Jun 2009) | 16 lines
Merged revisions 203375 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r203375 | russell | 2009-06-25 16:02:18 -0500 (Thu, 25 Jun 2009) | 9 lines
Fix a case where CDR answer time could be before the start time involving parking.
(closes issue #13794)
Reported by: davidw
Patches:
13794.patch uploaded by murf (license 17)
13794.patch.160 uploaded by murf (license 17)
Tested by: murf, dbrooks
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@203377 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r201829 | tilghman | 2009-06-18 19:43:41 -0500 (Thu, 18 Jun 2009) | 13 lines
Merged revisions 201828 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r201828 | tilghman | 2009-06-18 19:40:41 -0500 (Thu, 18 Jun 2009) | 6 lines
If the "h" extension fails, give it another chance in main/pbx.c.
If the "h" extension fails, give it another chance in main/pbx.c, when it
returns from the bridge code. Fixes an issue where the "h" extension may
occasionally not fire, when a Dial is executed from a Macro.
Debugged in #asterisk with user tompaw.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@201830 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r198856 | dvossel | 2009-06-02 16:17:49 -0500 (Tue, 02 Jun 2009) | 10 lines
Generic call forward api, ast_call_forward()
The function ast_call_forward() forwards a call to an extension specified in an ast_channel's call_forward string. After an ast_channel is called, if the channel's call_forward string is set this function can be used to forward the call to a new channel and terminate the original one. I have included this api call in both channel.c's ast_request_and_dial() and feature.c's feature_request_and_dial(). App_dial and app_queue already contain call forward logic specific for their application and options.
(closes issue #13630)
Reported by: festr
Review: https://reviewboard.asterisk.org/r/271/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@198889 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r192861 | jpeeler | 2009-05-06 17:17:27 -0500 (Wed, 06 May 2009) | 17 lines
Merged revisions 192858 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r192858 | jpeeler | 2009-05-06 17:15:19 -0500 (Wed, 06 May 2009) | 10 lines
Make ParkedCall application stop execution of the dialplan after hang up
Just changed park_exec to always return non-zero. I really wasn't entirely sure
at first if this was a bug. Decided it was since it would be surprising when
not using ParkedCall in the dialplan to hang up and have dialplan execution
continue.
(closes issue #14555)
Reported by: francesco_r
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@192865 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r192462 | file | 2009-05-05 15:23:58 -0300 (Tue, 05 May 2009) | 15 lines
Merged revisions 192454 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r192454 | file | 2009-05-05 15:22:27 -0300 (Tue, 05 May 2009) | 8 lines
Fix an incorrect assumption that certain values on the channel will always exist when they may not.
The CDR code involved with bridges wrongly assumed that the currently executing application and data
values will always exist. It is possible for this to be false when call forwarding is involved.
(closes issue #14984)
Reported by: gincantalupo
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@192467 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Don't set the orig_chan_name in masq_park_call when the announcement is to be
played. This change was copied from all the other working 1.6 branches.
(closes issue #14863)
Reported by: noahisaac
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@190829 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r183436 | dvossel | 2009-03-19 15:30:39 -0500 (Thu, 19 Mar 2009) | 13 lines
Merged revisions 183386 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183386 | dvossel | 2009-03-19 14:40:07 -0500 (Thu, 19 Mar 2009) | 6 lines
Cleaning up a few things in detect disconnect patch
Initialized ast_call_feature in detect_disconnect to avoid accessing uninitialized memory. Cleaned up /param tags in features.h. No longer send dynamic features in ast_feature_detect.
issue #11583
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@183437 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r183172 | dvossel | 2009-03-19 11:28:33 -0500 (Thu, 19 Mar 2009) | 20 lines
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@183199 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r182525 | kpfleming | 2009-03-17 09:38:11 -0500 (Tue, 17 Mar 2009) | 11 lines
Improve behavior of ast_answer() to not lose incoming frames
ast_answer(), when supplied a delay before returning to the caller, use ast_safe_sleep() to implement the delay. Unfortunately during this time any incoming frames are discarded, which is problematic for T.38 re-INVITES and other sorts of channel operations.
When a delay is not passed to ast_answer(), it still delays for up to 500 milliseconds, waiting for media to arrive. Again, though, it discards any control frames, or non-voice media frames.
This patch rectifies this situation, by storing all incoming frames during the delay period on a list, and then requeuing them onto the channel before returning to the caller.
http://reviewboard.digium.com/r/196/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@182526 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r182029 | mmichelson | 2009-03-13 12:26:43 -0500 (Fri, 13 Mar 2009) | 41 lines
Merged revisions 181990 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r181990 | mmichelson | 2009-03-13 12:12:32 -0500 (Fri, 13 Mar 2009) | 35 lines
Check the DYNAMIC_FEATURES of both the chan and peer when interpreting DTMF.
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.6.0@182064 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r179841 | file | 2009-03-03 14:28:46 -0400 (Tue, 03 Mar 2009) | 16 lines
Merged revisions 179840 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r179840 | file | 2009-03-03 14:27:09 -0400 (Tue, 03 Mar 2009) | 9 lines
Do not assume that the bridge_cdr is still attached to the channel when the 'h' exten is finished executing.
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.6.0@179842 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r178986 | murf | 2009-02-26 20:45:58 -0700 (Thu, 26 Feb 2009) | 26 lines
Merged revisions 178956 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
In this case, it's just a matter of reducing the default timeouts from 2000
to 1000 msec, as the max def feature digit timeout is no longer halved.
........
r178956 | murf | 2009-02-26 14:27:32 -0700 (Thu, 26 Feb 2009) | 18 lines
This change moves the default feature digit timeout to 1000 ms from the previous default of 500.
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.6.0@178987 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r178828 | murf | 2009-02-26 10:22:11 -0700 (Thu, 26 Feb 2009) | 34 lines
Merged revisions 178804 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r178804 | murf | 2009-02-26 10:09:03 -0700 (Thu, 26 Feb 2009) | 28 lines
This patch prevents the feature detection timeout from being cut in half.
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.6.0@178866 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r177226 | dvossel | 2009-02-18 16:51:38 -0600 (Wed, 18 Feb 2009) | 9 lines
Locking issue in action_bridge and bridge_exec
action_bridge() and bridge_exec() both search for the channels to bridge to, and then immediately drop the lock. Instead, they should hold the lock until the masquerade is complete. This will guarantee the channel remains and prevent any other weirdness from occurring. In action_bridge() some more weirdness comes into play. Both channels are needlessly locked at the same time and perform the exact same logic. It makes sense from a coding organizational standpoint, but could cause a theoretical deadlock so I split the code up. There is an issue associated with this, but since its a rather complicated thing to reproduce I'm not certain this alone will close it.
issue# 14296
Review: http://reviewboard.digium.com/r/167/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@177227 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r176708 | jpeeler | 2009-02-17 16:08:00 -0600 (Tue, 17 Feb 2009) | 23 lines
Merged revisions 176701 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r176701 | jpeeler | 2009-02-17 15:54:34 -0600 (Tue, 17 Feb 2009) | 17 lines
Modify bridging to properly evaluate DTMF after first warning is played
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.6.0@176710 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r175298 | jpeeler | 2009-02-12 14:48:56 -0600 (Thu, 12 Feb 2009) | 15 lines
Merged revisions 175294 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r175294 | jpeeler | 2009-02-12 14:34:36 -0600 (Thu, 12 Feb 2009) | 9 lines
Fix ParkedCall event information for From field in the case of a blind transfer
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.6.0@175299 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r175188 | jpeeler | 2009-02-12 12:00:11 -0600 (Thu, 12 Feb 2009) | 12 lines
Merged revisions 175187 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r175187 | jpeeler | 2009-02-12 11:57:10 -0600 (Thu, 12 Feb 2009) | 6 lines
Fix crash in event of failed attempt to transfer to parking
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.6.0@175189 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r173500 | jpeeler | 2009-02-04 15:17:53 -0600 (Wed, 04 Feb 2009) | 23 lines
Merged revisions 173211 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r173211 | jpeeler | 2009-02-03 15:57:01 -0600 (Tue, 03 Feb 2009) | 17 lines
Parking attempts made to one end of a bridge no longer will hang up due to a
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.6.0@173546 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.0@172635 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.0@172065 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r169510 | twilson | 2009-01-20 13:22:24 -0600 (Tue, 20 Jan 2009) | 7 lines
Make a proper builtin attended transfer to parking work
This is an ugly hack from 1.4 that allows the timeout callback from a parked
call to use the right channel name for the callback when the park is done with
a builtin attended transfer (that isn't completed early). This hasn't ever
worked in trunk and no one has complained yet, so eh.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@169541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r168941 | twilson | 2009-01-16 16:16:23 -0600 (Fri, 16 Jan 2009) | 19 lines
Merged revisions 168716 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r168716 | twilson | 2009-01-15 12:22:49 -0600 (Thu, 15 Jan 2009) | 12 lines
Convert call to park_call_full to masq_park_call_announce
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.6.0@168980 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
Due to non-symmetrical updating, I had some fairly
interesting conflicts to straighten out in this
release. The changes were such that I was compelled
to run thru all the same tests as trunk, which turned
up some problems, which I fixed.
................
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.0@166729 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r164203 | russell | 2008-12-15 08:40:24 -0600 (Mon, 15 Dec 2008) | 39 lines
Merged revisions 164201 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r164201 | russell | 2008-12-15 08:31:37 -0600 (Mon, 15 Dec 2008) | 31 lines
Handle a case where a call can be bridged to a channel that is still ringing.
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.6.0@164279 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r163094 | russell | 2008-12-11 11:06:16 -0600 (Thu, 11 Dec 2008) | 19 lines
Merged revisions 163092 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r163092 | russell | 2008-12-11 10:54:51 -0600 (Thu, 11 Dec 2008) | 11 lines
Fix an issue that made it so you could only have a single caller executing
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.6.0@163095 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r147518 | file | 2008-10-08 09:53:51 -0500 (Wed, 08 Oct 2008) | 9 lines
Merged revisions 147517 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r147517 | file | 2008-10-08 11:51:42 -0300 (Wed, 08 Oct 2008) | 2 lines
If we receive DTMF make sure that the state of the speech structure goes back to being not ready. (issue #LUMENVOX-8)
........
................
r147689 | kpfleming | 2008-10-08 17:26:55 -0500 (Wed, 08 Oct 2008) | 9 lines
Merged revisions 147681 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r147681 | kpfleming | 2008-10-08 17:22:09 -0500 (Wed, 08 Oct 2008) | 3 lines
when parsing a text configuration option, ensure that the buffer on the stack is actually large enough to hold the legal values of that option, and also ensure that sscanf() knows to stop parsing if it would overrun the buffer (without these changes, specifying "buffers=...,immediate" would overflow the buffer on the stack, and could not have worked as expected)
........
................
r148000 | tilghman | 2008-10-09 14:39:34 -0500 (Thu, 09 Oct 2008) | 11 lines
Merged revisions 147997 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r147997 | tilghman | 2008-10-09 14:38:33 -0500 (Thu, 09 Oct 2008) | 4 lines
When blank, callerid name and number should display "unknown caller" in voicemail
emails.
(Closes issue #13643)
........
................
r148112 | mmichelson | 2008-10-09 18:15:33 -0500 (Thu, 09 Oct 2008) | 26 lines
Merged revisions 146026 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r146026 | murf | 2008-10-03 12:12:54 -0500 (Fri, 03 Oct 2008) | 18 lines
(closes issue #13579)
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!
........
................
r148268 | tilghman | 2008-10-10 11:31:31 -0500 (Fri, 10 Oct 2008) | 14 lines
Merged revisions 148257 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r148257 | tilghman | 2008-10-10 11:25:31 -0500 (Fri, 10 Oct 2008) | 7 lines
User not notified of temporary greeting, if ODBC storage is in use.
(closes issue #13659)
Reported by: moliveras
Patches:
20081009__bug13659.diff.txt uploaded by Corydon76 (license 14)
Tested by: moliveras
........
................
r148917 | tilghman | 2008-10-14 12:46:48 -0500 (Tue, 14 Oct 2008) | 11 lines
Merged revisions 148916 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r148916 | tilghman | 2008-10-14 12:41:08 -0500 (Tue, 14 Oct 2008) | 4 lines
Ensure that mail headers are 7-bit clean, even when UTF-8 characters are used
in headers like 'Subject' and 'To'.
Closes AST-107.
........
................
r148988 | tilghman | 2008-10-14 14:03:44 -0500 (Tue, 14 Oct 2008) | 9 lines
Merged revisions 148987 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r148987 | tilghman | 2008-10-14 14:03:08 -0500 (Tue, 14 Oct 2008) | 2 lines
Some compilers warn, some don't. Fixing.
........
................
r149062 | tilghman | 2008-10-14 15:16:48 -0500 (Tue, 14 Oct 2008) | 13 lines
Merged revisions 149061 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r149061 | tilghman | 2008-10-14 15:09:06 -0500 (Tue, 14 Oct 2008) | 6 lines
Check correct values in the return of ast_waitfor(); also, get rid of a
possible memory leak.
(closes issue #13658)
Reported by: explidous
Patch by: me
........
................
r149131 | mmichelson | 2008-10-14 16:08:48 -0500 (Tue, 14 Oct 2008) | 15 lines
Merged revisions 149130 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r149130 | mmichelson | 2008-10-14 15:49:02 -0500 (Tue, 14 Oct 2008) | 7 lines
Don't allow reserved characters to be used in register
lines in sip.conf.
(closes issue #13570)
Reported by: putnopvut
........
................
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)
........
................
r149205 | mmichelson | 2008-10-14 18:04:44 -0500 (Tue, 14 Oct 2008) | 20 lines
Merged revisions 149204 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r149204 | mmichelson | 2008-10-14 18:00:01 -0500 (Tue, 14 Oct 2008) | 12 lines
Add a tolerance period for sync-triggered audiohooks
so that if packetization of audio is close (but not equal)
we don't end up flushing the audiohooks over small
inconsistencies in synchronization.
Related to issue #13005, and solves the issue
for most people who were experiencing the problem.
However, a small number of people are still experiencing
the problem on long calls, so I am not closing
the issue yet
........
................
r149208 | mmichelson | 2008-10-14 18:15:04 -0500 (Tue, 14 Oct 2008) | 17 lines
Merged revisions 149207 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r149207 | mmichelson | 2008-10-14 18:10:26 -0500 (Tue, 14 Oct 2008) | 9 lines
Call register_peer_exten even in the case that the peer's
IP/port does not change.
(closes issue #13309)
Reported by: dimas
Patches:
v2-13309.patch uploaded by dimas (license 88)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@160387 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r159818 | kpfleming | 2008-11-29 11:57:39 -0600 (Sat, 29 Nov 2008) | 18 lines
incorporates r159808 from branches/1.4:
------------------------------------------------------------------------
r159808 | kpfleming | 2008-11-29 10:58:29 -0600 (Sat, 29 Nov 2008) | 7 lines
update dev-mode compiler flags to match the ones used by default on Ubuntu Intrepid, so all developers will see the same warnings and errors
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
------------------------------------------------------------------------
in addition:
move some format attributes from main/utils.c to the header files they belong in, and fix up references to the relevant functions based on new compiler warnings
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@159855 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r158484 | murf | 2008-11-21 14:47:16 -0700 (Fri, 21 Nov 2008) | 19 lines
Merged revisions 158483 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r158483 | murf | 2008-11-21 14:19:47 -0700 (Fri, 21 Nov 2008) | 11 lines
(closes issue #13871)
Reported by: mdu113
This one is totally my fault. The code doesn't even
create a bridge CDR 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.6.0@158545 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.0@157307 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.0@153265 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r145606 | mmichelson | 2008-10-01 17:23:50 -0500 (Wed, 01 Oct 2008) | 11 lines
Okay, this should really do it now. While I did manage
to fix blind transfers with my last commit here, I also
caused an unwanted side-effect. That is, only the first
priority of the 'h' extension would be executed when
a blind transfer occurred instead of all priorities.
Essentially, my last commit corrected the return value
of ast_bridge_call. However, the implementation still
was not 100% correct. Now it is.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@145607 65c4cc65-6c06-0410-ace0-fbb531ad65f3
