asterisk

Commit Graph

Author	SHA1	Message	Date
Terry Wilson	de2bff02a1	Channel is masqueraded, don't keep alive git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@160411 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Terry Wilson	cedbee5b75	A situation like A calls B, A builtin_atxfers B to C, C parks B would lead to a crash. Thanks to file for telling me how to fix it! (closes issue #13854) Reported by: Adam Lee Tested by: otherwiseguy git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@160390 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Kevin P. Fleming	50515ed372	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 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@159808 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Steve Murphy	890386410a	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.4@158603 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Steve Murphy	596f31a1a1	(closes issue #13871 ) Reported by: mdu113 This one is totally my fault. The code doesn't even create a bridge if the channel CDR has POST_DISABLED. I didn't check for that at the end of the bridge. Fixed with a few small insertions. Tested. Looks good. No cdr generated, no crash, no unnecc. data objects created either. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@158483 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Kevin P. Fleming	187f6d485a	the gcc optimizer frequently finds broken code (use of uninitalized variables, unreachable code, etc.), which is good. however, developers usually compile with the optimizer turned off, because if they need to debug the resulting code, optimized code makes that process very difficult. this means that we get code changes committed that weren't adequately checked over for these sorts of problems. with this build system change, if (and only if) --enable-dev-mode was used and DONT_OPTIMIZE is turned on, when a source file is compiled it will actually be preprocessed (into a .i or .ii file), then compiled once with optimization (with the result sent to /dev/null) and again without optimization (but only if the first compile succeeded, of course). while making these changes, i did some cleanup work in Makefile.rules to move commonly-used combinations of flag variables into their own variables, to make the file easier to read and maintain git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@157859 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	3429c9de5e	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.4@157305 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Sean Bright	f2ecc4c80e	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.4@155553 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Kevin P. Fleming	18df35a2c1	somehow missed a bunch of gcc 4.3.x warnings in this branch on the first pass git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@153823 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Kevin P. Fleming	add5ff5b05	fix a bunch of potential problems found by gcc 4.3.x, primarily bare strings being passed to printf()-like functions and ignored results from read()/write() and friends git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@153337 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Terry Wilson	705d6f3742	Add end_bridge_callback for app_follome and add AUTOLOOP flag to res_features git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@153270 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Terry Wilson	6280e04736	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.4@153095 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Steve Murphy	961bc7e758	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. If you get AST_PBX_KEEPALIVE, then don't touch the channel pointer. If you get AST_PBX_NO_HANGUP_PEER, or AST_PBX_NO_HANGUP_PEER_PARKED, then don't touch the peer pointer. Updated the several places where the results from a bridge were not being properly obeyed, and fixed some code I had introduced so that the results of the bridge were not overridden (in trunk). All the places that previously tested for AST_PBX_NO_HANGUP_PEER now have to check for both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED. I tested this against the 4 common parking scenarios: 1. A calls B; B answers; A parks B; B hangs up while A is getting the parking slot announcement, immediately after being put on hold. 2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but before the park times out. 3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold. 4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out. No crash. I also ran the scenarios above against valgrind, and accesses looked good. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@152535 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Terry Wilson	3f6d4154b8	Backport fix from 1.6.0 that allows you to set parkedcalltransfers=no\|caller\|callee\|both, but default to both which would be the equivalent of the existing behaviour. The problem was that if someone parked a call, the callee and caller would both get assigned the builtin transfer feature, which would not only be potentially giving someone the ability to transfer themselves when they shouldn't have it, but would also dissallow reinviting the media off of the call. (closes issue #12854) Reported by: davidw Patches: parkingfix4.diff.txt uploaded by otherwiseguy Tested by: davidw, otherwiseguy git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@151763 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Steve Murphy	8f30902385	Interesting crash. In this case, you exit the	17 years ago
Jeff Peeler	b1da541a92	(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.4@147941 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Tilghman Lesher	93ef1ee4ef	Dialplan functions should not actually return 0, unless they have modified the workspace. To signal an error (and no change to the workspace), -1 should be returned instead. (closes issue #13340) Reported by: kryptolus Patches: 20080827__bug13340__2.diff.txt uploaded by Corydon76 (license 14) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@146799 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	fc2e08f823	(closes issue #13425 ) Reported by: mdu113 Tested by: mdu113 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.4@146129 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	b161b2df6e	(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.4@146026 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Tilghman Lesher	1178fb0bc4	Some sanity checks that may have led to prior crashes, found by codefreeze-lap (murf) on IRC. Also some cleanup of incorrectly-used constants. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@145751 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	ee2d2f2cae	(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.4@144066 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	5d6a7c270b	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.4@143475 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	407b16efd7	(closes issue #13493 ) Reported by: mdu113 Patches: bug13493.diff uploaded by jpeeler (license 325) Tested by: mdu113 Changed park_call_full to hold the parkinglot lock a little longer, which protects the parkeduser struct from being freed out from underneath. Made sure that the parking extension is added to the parking context while holding the lock thereby ensuring that there are no spurious warnings from removal attempts when a hangup occurs while the parking lot is being announced. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@143270 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	a3289918e3	(closes issue #13465 ) (closes issue #13425) Reported by: mdu113 Patches: bug13425.diff uploaded by jpeeler (license 325) Tested by: mdu113 The main change here was to masquerade the channel if the channel that was to be parked was running a PBX on it. The PBX thread can then maintain full control of the channel (the zombie) as it expects to while allowing the parking thread full control of the real (parked) channel. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@143204 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	eccd14d7f0	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. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@142675 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	aa58c91fbe	(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.4@142575 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	dca52e11c5	(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.4@142474 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Russell Bryant	5730a3169a	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.4@142063 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Tilghman Lesher	0e8f3075bc	Reverting behavior change (AGI should not exit non-zero on SUCCESS) (closes issue #13434) Reported by: francesco_r git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@141503 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	1c8fff43ad	(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.4@141028 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	271e1a4acf	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.4@139764 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	d0f001accc	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.4@139635 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	3bb4f66a30	(closes issue #13251 )	18 years ago
Tilghman Lesher	9d294cd934	Deallocate database connection handle on disconnect, as we allocate another one on connect. (closes issue #13271) Reported by: dveiga git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@137138 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	ee8adb313e	(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/branches/1.4@135799 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	08450d1a93	(closes issue #11849 ) Reported by: greyvoip Tested by: murf OK, a few days of debugging, a bunch of instrumentation in chan_sip, main/channel.c, main/pbx.c, etc. and 5 solid notebook pages of notes later, I have made the small tweek necc. to get the start time right on the second CDR when: A Calls B B answ. A hits Xfer button on sip phone, A dials C and hits the OK button, A hangs up C answers ringing phone B and C converse B and/or C hangs up But does not harm the scenario where: A Calls B B answ. B hits xfer button on sip phone, B dials C and hits the OK button, B hangs up C answers ringing phone A and C converse A and/or C hangs up The difference in start times on the second CDR is because of a Masquerade on the B channel when the xfer number is sent. It ends up replacing the CDR on the B channel with a duplicate, which ends up getting tossed out. We keep a pointer to the first CDR, and update that after the bridge closes. But, only if the CDR has changed. I hope this change is specific enough not to muck up any current CDR-based apps. In my defence, I assert that the previous information was wrong, and this change fixes it, and possibly other similar scenarios. I wonder if I should be doing the same thing for the channel, as I did for the peer, but I can't think of a scenario this might affect. I leave it, then, as an exersize for the users, to find the scenario where the chan's CDR changes and loses the proper start time. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@134883 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Tilghman Lesher	0dff9821d6	launch_netscript sometimes returns -1, which fails to set AGISTATUS. Map failure to -1, so that AGISTATUS is always set. (closes issue #13199) Reported by: smw1218 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@134480 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Brett Bryant	5d4058b41a	Fix a bug in blind transfers where the BLINDTRANSFER variable isn't always set to the other end of the blind transfer. (closes issue #12586) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@131915 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Tilghman Lesher	74c78a9e3a	Oops git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@129741 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	e9f5152eba	The CDRfix4/5/6 omnibus cdr fixes. (closes issue #10927) Reported by: murf Tested by: murf, deeperror (closes issue #12907) Reported by: falves11 Tested by: murf, falves11 (closes issue #11849) Reported by: greyvoip As to 11849, I think these changes fix the core problems brought up in that bug, but perhaps not the more global problems created by the limitations of CDR's themselves not being oriented around transfers. Reopen if necc, but bug reports are not the best medium for enhancement discussions. We need to start a second-generation CDR standardization effort to cover transfers. (closes issue #11093) Reported by: rossbeer Tested by: greyvoip, murf git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@127663 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	a2266547c6	fixed dahdi compatability header from assuming either dahdi or zaptel is installed (may not have either) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@122663 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Terry Wilson	e128c2a314	This should fix the behavior of the 'T' dial feature being passed incorrectly to the transferee when builtin_atxfers are used. Also, doing a builtin_atxfer to parking was broken and is fixed here as well. (closes issue #11898) Reported by: sergee Tested by: otherwiseguy git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@122589 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	f9818af8dd	Adds DAHDI support alongside Zaptel. DAHDI usage favored, but all Zap stuff should continue working. Release announcement to follow. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@122314 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	0c0a5cdc73	(closes issue #12193 ) Reported by: davidw Patch by: Corydon76, modified by me to work properly with ParkAndAnnounce app git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@122208 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Terry Wilson	c340004d76	Backport fix for 11520--for some reason I didn't do this back in February when I patched for trunk. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@121992 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Philippe Sultan	d9ad9cc1e4	Ignore appended resource when comparing JIDs. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@120675 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Russell Bryant	dae683eb3f	It turns out that searching on the forwarding station isn't very useful for most people, so pull in the changes that allow searching for SMDI messages based on other components of the SMDI message. Also, update the SMDI documentation. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@120671 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Philippe Sultan	59410a3f01	Do not link the guest account with any configured XMPP client (in jabber.conf). The actual connection is made when a call comes in Asterisk. Fix the ast_aji_get_client function that was not able to retrieve an XMPP client from its JID. (closes issue #12085) Reported by: junky Tested by: phsultan git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@119740 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Joshua Colp	b5ac40e980	Use the right pthread lock and condition when waiting. (closes issue #12664) Reported by: tomo1657 Patches: res_smdi.c.patch uploaded by tomo1657 (license 484) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@117135 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Tilghman Lesher	01f5aee7ac	Avoid zombies when the channel exits before the AGI. (closes issue #12648) Reported by: gkloepfer Patches: 20080514__bug12648.diff.txt uploaded by Corydon76 (license 14) Tested by: gkloepfer git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@116466 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago

1 2 3 4 5 ...

842 Commits (8a7982c1ff7a5014fc0c23512025b29e00a0f4c8)