asterisk

Commit Graph

Author	SHA1	Message	Date
Terry Wilson	7164958d9d	Merged revisions 189465 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r189465 \| twilson \| 2009-04-20 16:10:27 -0500 (Mon, 20 Apr 2009) \| 2 lines Update CDR appropriately when AST_CAUSE_NO_ANSWER is set ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@189516 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Terry Wilson	f505cb43bf	Merged revisions 189463 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r189463 \| twilson \| 2009-04-20 16:00:52 -0500 (Mon, 20 Apr 2009) \| 2 lines Don't treat a NOANSWER like a CHANUNAVAIL ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@189495 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	fd833f14ed	Make the cancellation of the dial timeout on a call forward optional. This introduces the 'z' option to app_dial. With it set, a call forward will cancel any timeout originally set for this instance of the Dial application. AST-207 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@188544 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	df28954a84	Make sure tc is unlocked before calling ast_call since calling a Local channel could result in a deadlock. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187770 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	bd23adbc8a	Even more changes concerning r187426. Revised where locks are placed yet once again. ast_call() should not be called with a channel locked. could cause deadlock issues with local channels. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187673 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	e6052e79d0	More changes concerning r187426. Revised where locks are placed. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187556 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Jeff Peeler	de4af72f9f	Add ability for dialplan execution to continue when caller hangs up. The F option to app_dial has been modified to accept no parameters and perform the above functionality. I don't see anywhere else that is doing function overloading, but this really is the best place for this operation because: - It makes it close to the 'g' option in the argument list which provides similar functionality. - The existing code to support the current F option provides a very convienient location to add this new feature. (closes issue #12381) Reported by: michael-fig git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187491 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	19f381b484	Fixes deadlock caused by calling get_cid_name with chan locked. get_cid_name should not be called with a channel lock. get_cid_name calls ast_get_hint which eventually calls pbx_find_extension. pbx_find_extension starts and stops autoservice which should not be done with a channel lock, so get_cid_name should not be called with one. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187426 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	6f53ed4c67	This commit introduces COLP/CONP and Redirecting party information into Asterisk. The channel drivers which have been most heavily tested with these enhancements are chan_sip and chan_misdn. Further work is being done to add Q.SIG support and will be introduced in a later commit. chan_skinny has code added to it here, but according to user pj, the support on chan_skinny is not working as of now. This will be fixed in a later commit. A special thanks goes out to bugtracker user gareth for getting the ball rolling and providing the initial support for this work. Without his initial work on this, this would not have been nearly as painless as it was. This functionality has been tested by Digium's product quality department, as well as a customer site running thousands of calls every day. In addition, many many many many bugtracker users have tested this, too. (closes issue #8824) Reported by: gareth Review: http://reviewboard.digium.com/r/201 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@186525 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Joshua Colp	63de834395	Merge in the RTP engine API. This API provides a generic way for multiple RTP stacks to be integrated into Asterisk. Right now there is only one present, res_rtp_asterisk, which is the existing Asterisk RTP stack. Functionality wise this commit performs the same as previously. API documentation can be viewed in the rtp_engine.h header file. Review: http://reviewboard.digium.com/r/209/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@186078 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	9d3527bddf	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/trunk@183436 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	2764c2821f	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/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	e559cae4ec	Option to send DTMF when receiving PROGRESS status The D() option in app_dial is only able to send DTMF after the call has been answered. A progress option has been added to D() to allow DTMF to be sent upon receiving PROGRESS. This allows DTMF to be sent before the call is answered. (closes issue #12123) Reported by: VoipForces Patches: app_dial.c_patch_trunk_valid uploaded by VoipForces (license 419) dtmf_progress.patch uploaded by dvossel (license 671) Tested by: VoipForces, dvossel git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@182596 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Joshua Colp	499ca8de65	Fix crash when sleep and retries argument was not given to RetryDial application. (closes issue #14647) Reported by: sherpya git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@181612 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Joshua Colp	15090ba1df	Remove duplicate 'k' and 'K' Dial options. (closes issue #14601) Reported by: alecdavis Patches: app_dial.optionk.diff.txt uploaded by alecdavis (license 585) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@180120 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	47ebea6a8d	Fix 'd' option for app_dial and add new option to Answer application The 'd' option would not work for channel types which use RTP to transport DTMF digits. The only way to allow for this to work was to answer the channel if we saw that this option was enabled. I realized that this may cause issues with CDRs, specifically with giving false dispositions and answer times. I therefore modified ast_answer to take another parameter which would tell if the CDR should be marked answered. I also extended this to the Answer application so that the channel may be answered but not CDRified if desired. I also modified app_dictate and app_waitforsilence to only answer the channel if it is not already up, to help not allow for faulty CDR answer times. All of these changes are going into Asterisk trunk. For 1.6.0 and 1.6.1, however, all the changes except for the change to the Answer application will go in since we do not introduce new features into stable branches (closes issue #14164) Reported by: DennisD Patches: 14164.patch uploaded by putnopvut (license 60) Tested by: putnopvut Review: http://reviewboard.digium.com/r/145 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174945 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Steve Murphy	53d9b77898	This reverts the changes I made for 11583; will	17 years ago
Steve Murphy	c61e8a7865	This change allows the disconnect feature (as in "one-touch" in features.c) to be used within the dial app, before a call is bridged. Many thanks to sobomax for submitting this patch. Quoting from bug 11582: "So the goal of the patch was to use the user configured feature code during the call setup phase. The original ast_feature_interpret() function is not well suited for this purpose as it uses much call bridge specific data and doesn't separate a detection of feature from a feature handler call. So a new function ast_feature_detect() has been extracted off the ast_feature_interpret() function but keeping the original logic intact except some insignificant changes to locking. "Having created the ast_feature_detect() function the possibility to use feature detection in almost any place of the asterisk code. So a call to this function has been added to wait_for_answer() function of app_dial.so module. This code doesn't call the feature handler however and uses old call leg disconnect logic to make the changes as small and simple as possible to prevent unexpected problems. A disconnect feature currently is the only one supported during call setup as other features as call parking and call transfer don't make much sense during call setup. However if need in some of the features would arise it is much easier to implement as the infrastructure changes are already in place with this patch." I have cleaned up the patch somewhat, and verified that the existing functionality is not harmed, and that the new functionality works. Terry has committed his stuff, and there were no conflicts (see 14274). (closes issue #11583) Reported by: sobomax Patches: patch-apps__app_dial.c uploaded by sobomax (license 359) patch-include__asterisk__features.h uploaded by sobomax (license 359) patch-res__res_features.c uploaded by sobomax (license 359) enable-features-during-call-setup.diff uploaded by sobomax (license 359) 11583.newdiff uploaded by murf (license 17) enable-features-during-call-setup-1.diff uploaded by sobomax (license 359) 11583.latest-patch uploaded by murf (license 17) Tested by: sobomax, murf git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172890 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Terry Wilson	8d782f96b8	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/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Olle Johansson	7ecda45482	Fix "cancel answered elsewhere" through app_queue with members in chan_local. Also, implement a private cause code (as suggested by Tilghman). This works with chan_sip, but doesn't propagate through chan_local. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172318 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Joshua Colp	665bba38f1	Merged revisions 170568 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r170568 \| file \| 2009-01-23 15:06:54 -0400 (Fri, 23 Jan 2009) \| 4 lines When a call is forwarded stop any active indications. The new channel will provide an indication, if need be, itself. (closes issue #14310) Reported by: RadicAlish ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@170569 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Terry Wilson	c37aa68d77	Set peer context and exten values so MACRO_EXTEN and MACRO_CONTEXT will be set git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@167935 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	ff20b9116a	Update app_queue to deal with the removal of AST_PBX_KEEPALIVE When placing a call to a queue which ran a gosub on the member's channel, Asterisk would crash every time, stemming from the fact that the member's channel was being hung up unexpectedly when the Gosub completed. The necessary change was pretty much copied and pasted from app_dial's similar changes made last week. I also took the opportunity to change a LOG_DEBUG message in app_dial to use ast_debug. I am guessing this was due to a direct merge from 1.4 that was not corrected to use trunk's preferred syntax. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166861 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Steve Murphy	aa905e347e	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/trunk@166665 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Russell Bryant	50a25ac847	Remove the need for AST_PBX_KEEPALIVE with the GoSub option from Dial. This is part of an effort to completely remove AST_PBX_KEEPALIVE and other similar return codes from the source. While this usage was perfectly safe, there are others that are problematic. Since we know ahead of time that we do not want to PBX to destroy the channel, the PBX API has been changed so that information can be provided as an argument, instead, thus removing the need for the KEEPALIVE return value. Further changes to get rid of KEEPALIVE and related code is being done by murf. There is a patch up for that on review 29. Review: http://reviewboard.digium.com/r/98/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@165723 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	a53877b469	Add some safety measures when using gosub, especially when using the options for app_dial and app_queue to run a gosub when the call is answered. * Check for the existence of the gosub target in gosub_exec. If it is nonexistent, then this will cause errors when we attempt to actually run the gosub, including a definite memory leak and potential crashes. Return an error in this situation * Check the return value of pbx_exec in app_dial and app_queue before attempting to actually run the gosub routine. If there was an error, we should not attempt to run the gosub. * Change a '\|' to a ',' in app_queue. * Add some extra curly braces where they had been missing previously. (closes issue #13548) Reported by: fiddur git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@160626 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	5cf09591b0	Add some necessary hangup commands in the case that forwarding a call fails 1) Hang up the original destination if the local channel cannot be requested. 2) Hang up the local channel (in addition to the original destination) if ast_call fails when calling the newly created local channel. This prevents channels from sticking around forever in the case of a botched call forward (e.g. to an extension which does not exist). (closes issue #13764) Reported by: davidw Patches: 13764_v2.patch uploaded by putnopvut (license 60) Tested by: putnopvut, davidw git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@159554 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	7a554a7386	Merged revisions 158053 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r158053 \| mmichelson \| 2008-11-20 11:33:06 -0600 (Thu, 20 Nov 2008) \| 12 lines Make sure to set the hangup cause on the calling channel in the case that ast_call() fails. For incoming SIP channels, this was causing us to send a 603 instead of a 486 when the call-limit was reached on the destination channel. (closes issue #13867) Reported by: still_nsk Patches: 13867.diff uploaded by putnopvut (license 60) Tested by: blitzrage ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@158066 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	d91f1df3e0	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/trunk@157306 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Tilghman Lesher	1287486dbf	Can't use items duplicated off the stack frame in an element returned from a function: in these cases, we have to use the heap, or garbage will result. (closes issue #13898) Reported by: alecdavis Patches: 20081114__bug13898__2.diff.txt uploaded by Corydon76 (license 14) Tested by: alecdavis git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@157253 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Tilghman Lesher	10afda33c7	Merged revisions 156386 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r156386 \| tilghman \| 2008-11-12 15:18:57 -0600 (Wed, 12 Nov 2008) \| 5 lines When using call limits under 1 second, infinite call lengths are allowed, instead. (closes issue #13851) Reported by: ruddy ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@156388 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	a9e84c1e51	Merged revisions 156167 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r156167 \| mmichelson \| 2008-11-12 11:38:33 -0600 (Wed, 12 Nov 2008) \| 7 lines When doing some tests, I was having a crash at the end of every call if an attended transfer occurred during the call. I traced the cause to the CDR on one of the channels being NULL. murf suggested a check in the end bridge callback to be sure the CDR is non-NULL before proceeding, so that's what I'm adding. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@156169 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Sean Bright	9ef09ad1d4	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/trunk@155554 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Kevin P. Fleming	bd4eb070f3	bring over all the fixes for the warnings found by gcc 4.3.x from the 1.4 branch, and add the ones needed for all the new code here too git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@153616 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Russell Bryant	6f314f4d42	Fix various spelling and grammatical issues in documentation git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@153468 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Russell Bryant	5b168ee34b	Merge changes from team/group/appdocsxml This commit introduces the first phase of an effort to manage documentation of the interfaces in Asterisk in an XML format. Currently, a new format is available for applications and dialplan functions. A good number of conversions to the new format are also included. For more information, see the following message to asterisk-dev: http://lists.digium.com/pipermail/asterisk-dev/2008-October/034968.html git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@153365 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Terry Wilson	5fe37e47c6	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/trunk@153181 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Steve Murphy	d736ac2b19	Merged revisions 152538 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r152538 \| murf \| 2008-10-28 23:19:04 -0600 (Tue, 28 Oct 2008) \| 14 lines A little documentation cross-ref between features and dial and queue... I wasted some time (stupidly) trying to get the one-touch parking stuff working, because it didn't occur to me that I had to also have the corresponding options in the dial command! Duh! (In all this time, I never set this up before!) So, to keep some poor fool from suffering the same fate, I made the features.conf.sample file mention the corresponding opts in dial/queue; and the docs for dial/app specifically mention the corresponding decls in the feature.conf file. I hope this doesn't spoil some vast, eternal plan... ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152605 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Steve Murphy	6fad66dfb3	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/trunk@152536 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Tilghman Lesher	dd049d429d	Merged revisions 152368 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r152368 \| tilghman \| 2008-10-28 12:04:56 -0500 (Tue, 28 Oct 2008) \| 8 lines Reset all DIAL variables back to blank, in case Dial is called multiple times per call (which could otherwise lead to inconsistent status reports). (closes issue #13216) Reported by: ruddy Patches: 20081014__bug13216.diff.txt uploaded by Corydon76 (license 14) Tested by: ruddy ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@152369 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	dc36a357d2	When specifying an invalid timeout to Dial, take it to mean that no timeout is desired. (closes issue #13625) Reported by: atis git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@149279 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Sean Bright	d1f257ba53	Move the DAHDI-to-DAHDI operator mode check from app_dial into chan_dahdi so we don't have to hardcode anything. (closes issue #13636) Reported by: seanbright Patches: 13636.diff uploaded by seanbright (license 71) Reviewed by: russellb, putnopvut git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@147388 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Sean Bright	61664ec58b	Make sure to compare the correct number of characters when special-casing our DAHDI operator mode stuff. Technically, it would work fine, as 'DAH' is currently unique amongst our channel technologies, but as Jared points out: <@jsmith> Sure... as long as the technology starts whith DAH.... but it could be DAHDOO! git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@147050 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Tilghman Lesher	8fbee1307c	Repair IAXVAR implementation so that it works again (regression?) (closes issue #13354) Reported by: adomjan Patches: 20080828__bug13354.diff.txt uploaded by Corydon76 (license 14) 20080829__bug13354__1.6.0.diff.txt uploaded by Corydon76 (license 14) Tested by: Corydon76, adomjan git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@143031 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Steve Murphy	67f7ac0499	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/trunk@142676 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Steve Murphy	2488366a75	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/trunk@139627 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Sean Bright	3ffb39833b	More RSW merges. Everything from apps/ except for the big offenders app_voicemail and app_queue. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@137055 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Steve Murphy	5eaf8450d6	Merged revisions 135799 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r135799 \| murf \| 2008-08-05 17:13:20 -0600 (Tue, 05 Aug 2008) \| 34 lines (closes issue #12982) Reported by: bcnit Tested by: murf I discovered that also, in the previous bug fixes and changes, the cdr.conf 'unanswered' option is not being obeyed, so I fixed this. And, yes, there are two 'answer' times involved in this scenario, and I would agree with you, that the first answer time is the time that should appear in the CDR. (the second 'answer' time is the time that the bridge was begun). I made the necessary adjustments, recording the first answer time into the peer cdr, and then using that to override the bridge cdr's value. To get the 'unanswered' CDRs to appear, I purposely output them, using the dial cmd to mark them as DIALED (with a new flag), and outputting them if they bear that flag, and you are in the right mode. I also corrected one small mention of the Zap device to equally consider the dahdi device. I heavily tested 10-sec-wait macros in dial, and without the macro call; I tested hangups while the macro was running vs. letting the macro complete and the bridge form. Looks OK. Removed all the instrumentation and debug. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@135821 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Kevin P. Fleming	7df8b8b848	make datastore creation and destruction a generic API since it is not really channel related, and add the ability to add/find/remove datastores to manager sessions git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@135680 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	bd1bb0d0e2	Merged revisions 130792 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r130792 \| mmichelson \| 2008-07-14 12:50:21 -0500 (Mon, 14 Jul 2008) \| 8 lines Add a check to the CAN_EARLY_BRIDGE macro in app_dial to be sure there are no audiohooks present on the channels involved. This fixed a one-way audio situation I had in my test setup. I couldn't find any open issues that suggested one-way audio with regards to mixmonitor (or other audiohook) usage, though. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@130794 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago

1 2 3 4 5 ...

418 Commits (25cea89d90efca01c69f5749e4ee01b38b0c96b1)