90 Commits (44cbe738829a7d9bcf665fea6be173c052d3bdb2)

Author	SHA1	Message	Date
Jeff Peeler	1a446ca100	Merged revisions 177356 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r177356 | jpeeler | 2009-02-19 09:56:31 -0600 (Thu, 19 Feb 2009) | 4 lines Fix mismerge from revision 176708 pointed out by Kaloyan Kovachev on the asterisk-dev mailing list. Thanks! ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@177358 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
David Vossel	6e8806e23a	Merged revisions 177226 via svnmerge from ... 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.1@177228 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	22dafa5396	Merged revisions 176708 via svnmerge from ... 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.1@176711 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	ab4aba0fb5	Merged revisions 175298 via svnmerge from ... 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.1@175300 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	63240311a8	Merged revisions 175188 via svnmerge from ... 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.1@175190 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	709a359e6b	Merged revisions 173500 via svnmerge from ... 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.1@173505 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Terry Wilson	8024a0df33	Merged revisions 173067 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r173067 | twilson | 2009-02-02 17:57:25 -0600 (Mon, 02 Feb 2009) | 9 lines Merged revisions 173066 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r173066 | twilson | 2009-02-02 17:48:06 -0600 (Mon, 02 Feb 2009) | 2 lines Fix a feature inheritance bug I added after code review ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@173069 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Terry Wilson	ef566503d3	Merged revisions 172580 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r172580 | twilson | 2009-01-30 15:29:12 -0600 (Fri, 30 Jan 2009) | 44 lines Merged revisions 172517 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines Fix feature inheritance with builtin features When using builtin features like parking and transfers, the AST_FEATURE_* flags would not be set correctly for all instances when either performing a builtin attended transfer, or parking a call and getting the timeout callback. Also, there was no way on a per-call basis to specify what features someone should have on picking up a parked call (since that doesn't involve the Dial() command). There was a global option for setting whether or not all users who pickup a parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT, AUTOMON, or PARKCALL. This patch: 1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the dialplan or with setvar in channels that support it. This variable can be set to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the equivalent dial options), to set what features should be activated on this channel. The patch moves the setting of the features datastores into the bridging code instead of app_dial to help facilitate this. 2) adds global options parkedcallparking, parkedcallhangup, and parkedcallrecording to be similar to the parkedcalltransfers option for globally setting features. 3) has builtin_atxfer call builtin_parkcall if being transfered to the parking extension since tracking everything through multiple masquerades, etc. is difficult and error-prone 4) attempts to fix all cases of return calls from parking and completed builtin transfers not having the correct permissions (closes issue #14274) Reported by: aragon Patches: fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396) Tested by: aragon, otherwiseguy Review http://reviewboard.digium.com/r/138/ ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@172636 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	dfb881fadf	Merged revisions 172063 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r172063 | murf | 2009-01-28 13:31:06 -0700 (Wed, 28 Jan 2009) | 52 lines Merged revisions 172030 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r172030 | murf | 2009-01-28 11:51:16 -0700 (Wed, 28 Jan 2009) | 46 lines This patch fixes h-exten running misbehavior in manager-redirected situations. What it does: 1. A new Flag value is defined in include/asterisk/channel.h, AST_FLAG_BRIDGE_HANGUP_DONT, which used as a messenge to the bridge hangup exten code not to run the h-exten there (nor publish the bridge cdr there). It will done at the pbx-loop level instead. 2. In the manager Redirect code, I set this flag on the channel if the channel has a non-null pbx pointer. I did the same for the second (chan2) channel, which gets run if name2 is set... and the first succeeds. 3. I restored the ending of the cdr for the pbx loop h-exten running code. Don't know why it was removed in the first place. 4. The first attempt at the fix for this bug was to place code directly in the async_goto routine, which was called from a large number of places, and could affect a large number of cases, so I tested that fix against a fair number of transfer scenarios, both with and without the patch. In the process, I saw that putting the fix in async_goto seemed not to affect any of the blind or attended scenarios, but still, I was was highly concerned that some other scenarios I had not tested might be negatively impacted, so I refined the patch to its current scope, and jmls tested both. In the process, tho, I saw that blind xfers in one situation, when the one-touch blind-xfer feature is used by the peer, we got strange h-exten behavior. So, I inserted code to swap CDRs and to set the HANGUP_DONT field, to get uniform behavior. 5. I added code to the bridge to obey the HANGUP_DONT flag, skipping both publishing the bridge CDR, and running the h-exten; they will be done at the pbx-loop (higher) level instead. 6. I removed all the debug logs from the patch before committing. 7. I moved the AUTOLOOP set/reset in the h-exten code in res_features so it's only done if the h-exten is going to be run. A very minor performance improvement, but technically correct. (closes issue #14241) Reported by: jmls Patches: 14241_redirect_no_bridgeCDR_or_h_exten_via_transfer uploaded by murf (license 17) Tested by: murf, jmls ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@172067 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Terry Wilson	44f7d9e631	Merged revisions 169510 via svnmerge from ... 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.1@169554 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Terry Wilson	18c4a532b4	Merged revisions 169486 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r169486 | twilson | 2009-01-20 12:48:14 -0600 (Tue, 20 Jan 2009) | 13 lines Merged revisions 169485 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r169485 | twilson | 2009-01-20 12:40:56 -0600 (Tue, 20 Jan 2009) | 6 lines Don't play audio to the channel if we've masqueraded (closes issue #14066) Reported by: bluefox Tested by: otherwiseguy, bluefox ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@169488 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Terry Wilson	1739c1e13b	Merged revisions 168941 via svnmerge from ... 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.1@168981 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	a7aeaf341b	Merged revisions 166665 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk This merged from trunk with no conflicts. I tested mostly the 'tired' cases, and for the most part ignored the tests for reconnecting and dialing in to fetch a parked call, after the first case. ................ r166665 | murf | 2008-12-23 11:13:49 -0700 (Tue, 23 Dec 2008) | 153 lines Merged revisions 166093 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 In order to merge this 1.4 patch into trunk, I had to resolve some conflicts and wait for Russell to make some changes to res_agi. I re-ran all the tests; 39 calls in all, and made fairly careful notes and comparisons: I don't want this to blow up some aspect of asterisk; I completely removed the KEEPALIVE from the pbx.h decls. The first 3 scenarios involving feature park; feature xfer to 700; hookflash park to Park() app call all behave the same, don't appear to leave hung channels, and no crashes. ........ r166093 | murf | 2008-12-19 15:30:32 -0700 (Fri, 19 Dec 2008) | 131 lines This merges the masqpark branch into 1.4 These changes eliminate the need for (and use of) the KEEPALIVE return code in res_features.c; There are other places that use this result code for similar purposes at a higher level, these appear to be left alone in 1.4, but attacked in trunk. The reason these changes are being made in 1.4, is that parking ends a channel's life, in some situations, and the code in the bridge (and some other places), was not checking the result code properly, and dereferencing the channel pointer, which could lead to memory corruption and crashes. Calling the masq_park function eliminates this danger in higher levels. A series of previous commits have replaced some parking calls with masq_park, but this patch puts them ALL to rest, (except one, purposely left alone because a masquerade is done anyway), and gets rid of the code that tests the KEEPALIVE result, and the NOHANGUP_PEER result codes. While bug 13820 inspired this work, this patch does not solve all the problems mentioned there. I have tested this patch (again) to make sure I have not introduced regressions. Crashes that occurred when a parked party hung up while the parking party was listening to the numbers of the parking stall being assigned, is eliminated. These are the cases where parking code may be activated: 1. Feature one touch (eg. *3) 2. Feature blind xfer to parking lot (eg ##700) 3. Run Park() app from dialplan (eg sip xfer to 700) (eg. dahdi hookflash xfer to 700) 4. Run Park via manager. The interesting testing cases for parking are: I. A calls B, A parks B a. B hangs up while A is getting the numbers announced. b. B hangs up after A gets the announcement, but before the parking time expires c. B waits, time expires, A is redialed, A answers, B and A are connected, after which, B hangs up. d. C picks up B while still in parking lot. II. A calls B, B parks A a. A hangs up while B is getting the numbers announced. b. A hangs up after B gets the announcement, but before the parking time expires c. A waits, time expires, B is redialed, B answers, A and B are connected, after which, A hangs up. d. C picks up A while still in parking lot. Testing this throroughly involves acting all the permutations of I and II, in situations 1,2,3, and 4. Since I added a few more changes (ALL references to KEEPALIVE in the bridge code eliimated (I missed one earlier), I retested most of the above cases, and no crashes. H-extension weirdness. Current h-extension execution is not completely correct for several of the cases. For the case where A calls B, and A parks B, the 'h' exten is run on A's channel as soon as the park is accomplished. This is expected behavior. But when A calls B, and B parks A, this will be current behavior: After B parks A, B is hung up by the system, and the 'h' (hangup) exten gets run, but the channel mentioned will be a derivative of A's... Thus, if A is DAHDI/1, and B is DAHDI/2, the h-extension will be run on channel Parked/DAHDI/1-1<ZOMBIE>, and the start/answer/end info will be those relating to Channel A. And, in the case where A is reconnected to B after the park time expires, when both parties hang up after the joyful reunion, no h-exten will be run at all. In the case where C picks up A from the parking lot, when either A or C hang up, the h-exten will be run for the C channel. CDR's are a separate issue, and not addressed here. As to WHY this strange behavior occurs, the answer lies in the procedure followed to accomplish handing over the channel to the parking manager thread. This procedure is called masquerading. In the process, a duplicate copy of the channel is created, and most of the active data is given to the new copy. The original channel gets its name changed to XXX<ZOMBIE> and keeps the PBX information for the sake of the original thread (preserving its role as a call originator, if it had this role to begin with), while the new channel is without this info and becomes a call target (a "peer"). In this case, the parking lot manager thread is handed the new (masqueraded) channel. It will not run an h-exten on the channel if it hangs up while in the parking lot. The h exten will be run on the original channel instead, in the original thread, after the bridge completes. See bug 13820 for our intentions as to how to clean up the h exten behavior. Review: http://reviewboard.digium.com/r/29/ ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@166730 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Russell Bryant	e74bc96b7b	Merged revisions 164203 via svnmerge from ... 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.1@164300 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Russell Bryant	221462c7a1	Merged revisions 163094 via svnmerge from ... 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.1@163100 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Kevin P. Fleming	c3347e79a5	Merged revisions 159818 via svnmerge from ... 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.1@159851 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	3e54351b7c	Merged revisions 159402 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r159402 | jpeeler | 2008-11-25 21:18:01 -0600 (Tue, 25 Nov 2008) | 3 lines Always parse arguments in park_call_exec so that app_args is valid. This prevents a crash when executing Park from the dialplan with no arguments. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@159403 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	5a79383039	Merged revisions 158606 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r158606 | murf | 2008-11-21 16:40:46 -0700 (Fri, 21 Nov 2008) | 19 lines Merged revisions 158603 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r158603 | murf | 2008-11-21 16:14:50 -0700 (Fri, 21 Nov 2008) | 11 lines In reference to the fix made for 13871, I was 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.6.1@158607 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	06a5a0234f	Merged revisions 158484 via svnmerge from ... 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.1@158572 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Mark Michelson	892f98a1e6	Merged revisions 157306 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r157306 | mmichelson | 2008-11-18 12:31:08 -0600 (Tue, 18 Nov 2008) | 20 lines Merged revisions 157305 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r157305 | mmichelson | 2008-11-18 12:25:55 -0600 (Tue, 18 Nov 2008) | 12 lines Fix a crash in the end_bridge_callback of app_dial and app_followme which would occur at the end of an attended transfer. The error occurred because we initially stored a pointer to an ast_channel which then was hung up due to a masquerade. This commit adds a "fixup" callback to the bridge_config structure to allow for end_bridge_callback_data to be changed in the case that a new channel pointer is needed for the end_bridge_callback. ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@157308 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Russell Bryant	6266c668bc	Merged revisions 157041 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r157041 | russell | 2008-11-14 22:25:57 -0600 (Fri, 14 Nov 2008) | 3 lines Fix a few more places where the case insensitive hash should be used since the comparison is case insensitive. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@157042 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Sean Bright	839cb83ea3	Merged revisions 155554 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r155554 | seanbright | 2008-11-08 20:27:00 -0500 (Sat, 08 Nov 2008) | 14 lines Merged revisions 155553 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r155553 | seanbright | 2008-11-08 20:08:07 -0500 (Sat, 08 Nov 2008) | 6 lines Use static functions here instead of nested ones. This requires a small change to the ast_bridge_config struct as well. To understand the reason for this change, see the following post: http://gcc.gnu.org/ml/gcc-help/2008-11/msg00049.html ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@155556 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Terry Wilson	239f1d53bc	Merged revisions 153181 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r153181 | twilson | 2008-10-31 13:55:33 -0500 (Fri, 31 Oct 2008) | 5 lines Recent CDR fixes moved execution of the 'h' exten into the bridging code, so variables that were set after ast_bridge_call was called would not show up in the 'h' exten. Added a callback function to handle setting variables, etc. from w/in the bridging code. Calls back into a nested function within the function calling ast_bridge_call (closes issue #13793) Reported by: greenfieldtech ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@153266 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	f1da1c3957	Merged revisions 152536 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r152536 | murf | 2008-10-28 23:01:00 -0600 (Tue, 28 Oct 2008) | 57 lines Merged revisions 152535 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines The magic trick to avoid this crash is not to try to find the channel by name in the list, which is slow and resource consuming, but rather to pay attention to the result codes from the ast_bridge_call, to which I added the AST_PBX_NO_HANGUP_PEER_PARKED value, which now are returned when a channel is parked. Why? because CDR's aren't generated via parking, so nothing is needed, but if a transfer occurred, there are critical things I need. If you get AST_PBX_KEEPALIVE, then don't touch the channel pointer. If you get AST_PBX_NO_HANGUP_PEER, or AST_PBX_NO_HANGUP_PEER_PARKED, then don't touch the peer pointer. Updated the several places where the results from a bridge were not being properly obeyed, and fixed some code I had introduced so that the results of the bridge were not overridden (in trunk). All the places that previously tested for AST_PBX_NO_HANGUP_PEER now have to check for both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED. I tested this against the 4 common parking scenarios: 1. A calls B; B answers; A parks B; B hangs up while A is getting the parking slot announcement, immediately after being put on hold. 2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but before the park times out. 3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold. 4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out. No crash. I also ran the scenarios above against valgrind, and accesses looked good. ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@152537 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Mark Michelson	49ea791733	Merged revisions 148112 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ 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! ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@148115 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	7bb1b2746b	Merged revisions 147952 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r147952 | jpeeler | 2008-10-09 14:27:32 -0500 (Thu, 09 Oct 2008) | 6 lines (closes issue #13139) 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.6.1@147957 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	550b71bbd8	Merged revisions 147146 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r147146 | jpeeler | 2008-10-07 11:04:45 -0500 (Tue, 07 Oct 2008) | 3 lines Explicitly setting these fields to NULL was done because I wasn't sure if they would be NULL otherwise. Since they will be set automatically, removing. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@147147 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	595d37e746	Merged revisions 146923 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r146923 | jpeeler | 2008-10-06 18:08:21 -0500 (Mon, 06 Oct 2008) | 3 lines Similar to r143204, masquerade the channel in the case of Park being called from AGI. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@146924 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	cd1a30c6c7	Merged revisions 146883 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r146883 | jpeeler | 2008-10-06 17:26:25 -0500 (Mon, 06 Oct 2008) | 12 lines This commit squashes together three commits because the wrong approach was originally used. (One of the commits was only one line.) 1) r143204: 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. 2) r143270: 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. 3) r143475: (the one liner) compare peer and chan instead of looking at the parked user (pu), which could have possibly already have been freed by the parking thread ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@146886 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	2fb8519c52	Merged revisions 146877 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r146877 | jpeeler | 2008-10-06 17:08:40 -0500 (Mon, 06 Oct 2008) | 1 line fix some comment placement ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@146878 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	2917e91db4	Merged revisions 146875 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r146875 | jpeeler | 2008-10-06 17:03:01 -0500 (Mon, 06 Oct 2008) | 5 lines Explicitly set args in park_call_exec NULL so in the case of no options being passed in, there is no garbage attempted to be used. Also, do not set args to unknown value again if there are no options passed in. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@146876 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	2e5cc80ba4	Merged revisions 146242 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r146242 | jpeeler | 2008-10-03 17:40:59 -0500 (Fri, 03 Oct 2008) | 1 line remove superfluous reference counting operations in manage_parkinglot since ao2_interator_next increments the ref count automatically ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@146243 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Mark Michelson	10258dd023	Merged revisions 145606 via svnmerge from ... 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.1@145609 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Mark Michelson	52b6762417	Merged revisions 145579 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r145579 | mmichelson | 2008-10-01 16:33:11 -0500 (Wed, 01 Oct 2008) | 4 lines if (!(x) == 0) is the same as if (x). ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@145584 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Mark Michelson	a7da5b2e76	Merged revisions 145553 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r145553 | mmichelson | 2008-10-01 16:06:26 -0500 (Wed, 01 Oct 2008) | 13 lines The logic surrounding the return value of ast_spawn_extension within ast_bridge_call was reversed. This problem was observed when a blind transfer placed from the callee channel of a test call failed. While the problem I am solving here is exactly the same as what was reported in issue #13584, the difference is that this fix I am applying is trunk-only. Issue #13584 was reported against the 1.4 branch, and my tests of 1.4's blind transfers appear to work fine. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@145557 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	98d269e5cd	Merged revisions 144067 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r144067 | murf | 2008-09-23 10:52:32 -0600 (Tue, 23 Sep 2008) | 37 lines Merged revisions 144066 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r144066 | murf | 2008-09-23 10:41:49 -0600 (Tue, 23 Sep 2008) | 29 lines (closes issue #13489) 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.6.1@144069 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	bc73329607	Merged revisions 142676 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r142676 | murf | 2008-09-11 22:50:48 -0600 (Thu, 11 Sep 2008) | 40 lines Merged revisions 142675 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r142675 | murf | 2008-09-11 22:29:34 -0600 (Thu, 11 Sep 2008) | 29 lines Tested by: sergee, murf, chris-mac, andrew, KNK This is a "second attempt" to restore the previous "endbeforeh" behavior in 1.4 and up. In order to capture information concerning all the legs of transfers in all their infinite combinations, I was forced to this particular solution by a chain of logical necessities, the first being that I was not allowed to rewrite the CDR mechanism from the ground up! This change basically leaves the original machinery alone, which allows IVR and local channel type situations to generate CDR's as normal, but a channel flag can be set to suppress the normal running of the h exten. That flag would be set by the code that runs the h exten from the ast_bridge_call routine, to prevent the h exten from being run twice. Also, a flag in the ast_bridge_config struct passed into ast_bridge_call can be used to suppress the running of the h exten in that routine. This would happen, for instance, if you use the 'g' option in the Dial app. Running this routine 'early' allows not only the CDR() func to be used in the h extension for reading CDR variables, but also allows them to be modified before the CDR is posted to the backends. While I dearly hope that this patch overcomes all problems, and introduces no new problems, reality suggests that surely someone will have problems. In this case, please re-open 13251 (or 13289), and we'll see if we can't fix any remaining issues. ** trunk note: some code to suppress the h exten being run from app_queue was added; for the 'continue' option available only in trunk/1.6.x. ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@142678 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	a026a6583e	Merged revisions 142576 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r142576 | murf | 2008-09-11 17:12:53 -0600 (Thu, 11 Sep 2008) | 28 lines Merged revisions 142575 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r142575 | murf | 2008-09-11 16:55:49 -0600 (Thu, 11 Sep 2008) | 20 lines (closes issue #13364) 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.6.1@142632 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	d4f3056049	Merged revisions 142475 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r142475 | murf | 2008-09-10 16:11:27 -0600 (Wed, 10 Sep 2008) | 38 lines Merged revisions 142474 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r142474 | murf | 2008-09-10 15:58:17 -0600 (Wed, 10 Sep 2008) | 30 lines (closes issue #12318) 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.6.1@142478 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Russell Bryant	e13c43f1a6	Merged revisions 142064 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r142064 | russell | 2008-09-09 10:44:10 -0500 (Tue, 09 Sep 2008) | 13 lines Merged revisions 142063 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r142063 | russell | 2008-09-09 10:40:24 -0500 (Tue, 09 Sep 2008) | 5 lines Ensure that the stored CDR reference is still valid after the bridge before poking at it. Also, keep the channel locked while messing with this CDR. (fixes crashes reported in issue #13409) ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@142066 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	2a02fcceff	Merged revisions 141039 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r141039 | jpeeler | 2008-09-04 12:27:56 -0500 (Thu, 04 Sep 2008) | 15 lines Merged revisions 141028 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r141028 | jpeeler | 2008-09-04 12:00:29 -0500 (Thu, 04 Sep 2008) | 7 lines (closes issue #11979) 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.6.1@141042 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	f86752e905	Merged revisions 140491 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r140491 | jpeeler | 2008-08-29 12:53:32 -0500 (Fri, 29 Aug 2008) | 2 lines Added the option s to the Park application which will silence the announcement of the parking space number. Also, fixes the bug of just clearing the flags instead of actually parsing the arguments to Park. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@140492 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Mark Michelson	6ed6a5ae29	Merged revisions 140489 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r140489 | mmichelson | 2008-08-29 12:47:17 -0500 (Fri, 29 Aug 2008) | 30 lines Merged revisions 140488 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r140488 | mmichelson | 2008-08-29 12:34:17 -0500 (Fri, 29 Aug 2008) | 22 lines After working on the ao2_containers branch, I noticed something a bit strange. In all cases where we provide a callback function to ao2_container_alloc, the callback function would only return 0 or CMP_MATCH. After inspecting the ao2_callback() code carefully, I found that if you're only looking for one specific item, then you should return CMP_MATCH | CMP_STOP. Otherwise, astobj2 will continue traversing the current bucket until the end searching for more matches. In cases like chan_iax2 where in 1.4, all the peers are shoved into a single bucket, this makes for potentially terrible performance since the entire bucket will be traversed even if the peer is one of the first ones come across in the bucket. All the changes I have made were for cases where the callback function defined was passed to ao2_container_alloc so that calls to ao2_find could find a unique instance of whatever object was being stored in the container. ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@140490 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	dfe7bf451a	Merged revisions 139770 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r139770 | murf | 2008-08-25 09:54:18 -0600 (Mon, 25 Aug 2008) | 17 lines Merged revisions 139764 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r139764 | murf | 2008-08-25 09:33:14 -0600 (Mon, 25 Aug 2008) | 9 lines This patch reverts the changes made via 139347, and 139635, as users are seeing adverse difference. I will un-close 13251. Back to the drawing board/ concept/ beginning/ whatever! ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@139778 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	37d5dcdfa9	Merged revisions 139662 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r139662 | murf | 2008-08-22 16:32:35 -0600 (Fri, 22 Aug 2008) | 14 lines Merged revisions 139635 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r139635 | murf | 2008-08-22 16:24:02 -0600 (Fri, 22 Aug 2008) | 6 lines I found some problems with the code I committed earlier, when 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.6.1@139674 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	41138ad333	Merged revisions 139627 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r139627 | murf | 2008-08-22 16:03:13 -0600 (Fri, 22 Aug 2008) | 59 lines Merged revisions 139347 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r139347 | murf | 2008-08-21 17:03:50 -0600 (Thu, 21 Aug 2008) | 47 lines (closes issue #13251) Reported by: sergee Tested by: murf THis is a bold move for a static release fix, but I wouldn't have made it if I didn't feel confident (at least a *bit* confident) that it wouldn't mess everyone up. The reasoning goes something like this: 1. We simply cannot do anything with CDR's at the current point (in pbx.c, after the __ast_pbx_run loop). It's way too late to have any affect on the CDRs. The CDR is already posted and gone, and the remnants have been cleared. 2. I was very much afraid that moving the running of the 'h' extension down into the bridge code (where it would be now practical to do it), would result in a lot more calls to the 'h' exten, so I implemented it as another exten under another name, but found, to my pleasant surprise, that there was a 1:1 correspondence to the running of the 'h' exten in the pbx_run loop, and the new spot at the end of the bridge. So, I ifdef'd out the current 'h' loop, and moved it into the bridge code. The only difference I can see is the stuff about the AST_PBX_KEEPALIVE, and hopefully, if this is still an important decision point, I can replicate it if there are complaints. To be perfectly honest, the KEEPALIVE situation is not totally clear to me, and how it relates to a post-bridge situation is less clear. I suspect the users will point out everything in total clarity if this steps on anyone's toes! 3. I temporarily swap the bridge_cdr into the channel before running the 'h' exten, which makes it possible for users to edit the cdr before it goes out the door. And, of course, with the endbeforehexten config var set, the users can also get at the billsec/duration vals. After the h exten finishes, the cdr is swapped back and processing continues as normal. Please, all who deal with CDR's, please test this version of Asterisk, and file bug reports as appropriate! ........ I also made a little fix to the app_dial's 'e' option, that is related to my updates. ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@139629 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	13a4d48c7c	Merged revisions 139622 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r139622 | jpeeler | 2008-08-22 16:52:20 -0500 (Fri, 22 Aug 2008) | 1 line remove extra comma typo ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@139623 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Mark Michelson	bb9dfd155c	Merged revisions 139558 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r139558 | mmichelson | 2008-08-22 15:02:35 -0500 (Fri, 22 Aug 2008) | 9 lines Add missing unique id to ParkedCallGiveUp and ParkedCallTimeOut manager events (closes issue #13358) Reported by: srt Patches: 13358_parking_events.diff uploaded by srt (license 378) ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@139560 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Sean Bright	c36bdfdf33	Merged revisions 138482 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r138482 | seanbright | 2008-08-17 10:12:11 -0400 (Sun, 17 Aug 2008) | 6 lines Move Uniqueid to the end of the event for those that rely on the position of the name/value pairs, pointed out by snuffy-home on #asterisk-commits. For those of you who rely on the position of name/value pairs in manager events... stop... that is why associative arrays were invented. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@138498 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Sean Bright	b41cc8891a	Merged revisions 138479 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r138479 | seanbright | 2008-08-17 09:51:08 -0400 (Sun, 17 Aug 2008) | 7 lines Add Uniqueid header to ParkedCall manager event. (closes issue #13323) Reported by: srt Patches: 13323_unique_id_for_parkedcalls_event.diff uploaded by srt (license 378) ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@138481 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago