355 Commits (cef5e9d4340f94de8801aaecfb004a080df8a68f)

Author	SHA1	Message	Date
Richard Mudgett	050a3c39ec	Merged revisions 305888 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r305888 | rmudgett | 2011-02-02 18:02:43 -0600 (Wed, 02 Feb 2011) | 8 lines Minor AST_FRAME_TEXT related issues. * Include the null terminator in the buffer length. When the frame is queued it is copied. If the null terminator is not part of the frame buffer length, the receiver could see garbage appended onto it. * Add channel lock protection with ast_sendtext(). * Fixed AMI SendText action ast_sendtext() return value check. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@305889 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Russell Bryant	0f8989a993	Merged revisions 303546 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r303546 | russell | 2011-01-24 14:32:21 -0600 (Mon, 24 Jan 2011) | 31 lines Fix channel redirect out of MeetMe() and other issues with channel softhangup. Mantis issue #18585 reports that a channel redirect out of MeetMe() stopped working properly. This issue includes a patch that resolves the issue by removing a call to ast_check_hangup() from app_meetme.c. I left that in my patch, as it doesn't need to be there. However, the rest of the patch fixes this problem with or without the change to app_meetme. The key difference between what happens before and after this patch is the effect of the END_OF_Q control frame. After END_OF_Q is hit in ast_read(), ast_read() will return NULL. With the ast_check_hangup() removed, app_meetme sees this which causes it to exit as intended. Checking ast_check_hangup() caused app_meetme to exit earlier in the process, and the target of the redirect saw the condition where ast_read() returned NULL. Removing ast_check_hangup() works around the issue in app_meetme, but doesn't solve the issue if another application did the same thing. There are also other edge cases where if an application finishes at the same time that a redirect happens, the target of the redirect will think that the channel hung up. So, I made some changes in pbx.c to resolve it at a deeper level. There are already places that unset the SOFTHANGUP_ASYNCGOTO flag in an attempt to abort the hangup process. My patch extends this to remove the END_OF_Q frame from the channel's read queue, making the "abort hangup" more complete. This same technique was used in every place where a softhangup flag was cleared. (closes issue #18585) Reported by: oej Tested by: oej, wedhorn, russell Review: https://reviewboard.asterisk.org/r/1082/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@303548 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Jeff Peeler	ac9c6a3692	Merged revisions 301502 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r301502 | jpeeler | 2011-01-12 12:10:42 -0600 (Wed, 12 Jan 2011) | 12 lines Fix CPU spike when pressing DTMF after agent login. The problem here is that DTMF was being continuously deferred and requeued since ast_safe_sleep is called in a loop. There are serveral other places in the code that sleeps and then loops in a similar fashion. Because of this fact I opted to not defer DTMF any more, which will not affect the original fix: https://reviewboard.asterisk.org/r/674 (closes issue #18130) Reported by: rgj ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@301503 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Jeff Peeler	645d18abb3	Merged revisions 297823 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r297823 | jpeeler | 2010-12-07 16:57:48 -0600 (Tue, 07 Dec 2010) | 12 lines Revert code that changed SSRC for DTMF. Some previous behavior was attempted to be restored, but mistakingly I did not realize that the previous behavior was incorrect. This fixes DTMF not being detected since DTMF shouldn't cause the SSRC to change. (related to issue #17404) (closes issue #18189) (closes issue #18352) Reported by: marcbou Tested by: cmbaker82 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@297824 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Russell Bryant	639b5c84c9	Merged revisions 296213 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r296213 | russell | 2010-11-24 17:26:43 -0600 (Wed, 24 Nov 2010) | 6 lines Make Asterisk less crashy. Since we might not put a new translation path on the channel, go ahead and set it to NULL right after destroying the old one to ensure we don't try to free an invalid translation path later on. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@296221 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Russell Bryant	272d665228	Merged revisions 296082 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r296082 | russell | 2010-11-24 14:22:32 -0600 (Wed, 24 Nov 2010) | 12 lines Fix false reporting of an error by set_format(). In the case that the native format was able to be changed to match the new requested format, the code proceeded to attempt to build a translation path, anyway. The result would be NULL, since no translation path is necessary and resulted in this function thinking an error has occurred. This case is now specifically caught and no attempt to build a translation path is attempted. Thanks to our automated tests and bamboo.asterisk.org for catching this problem and making a whole lot of noise when things started failing. :-) ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@296083 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Russell Bryant	5c520fdb04	Merged revisions 296000 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r296000 | russell | 2010-11-24 10:48:39 -0600 (Wed, 24 Nov 2010) | 38 lines Handle failures building translation paths more effectively. The problem scenario occurred on a heavily loaded system that was using the codec_dahdi module and exceeded the hardware transcoding capacity. The failure mode at that point was not good. The report came in to us as an Asterisk lock-up. The "core show locks" shows a ton of threads locked up (but no obvious deadlock). Upon deeper investigation, when the system is in this state, the CPU was maxed out. The CPU was being consumed by the Asterisk logger spewing messages on every audio frame for calls set up after transcoder capacity was reached. The purpose of this patch is to make Asterisk handle failures to create a translation path in a more graceful manner. If we can't translate, then the call just needs to be dropped, as it's not going to work. These are the changes: 1) In set_format() of channel.c (which is called by set_read_format() and set_write_format()), it was ignoring if ast_translator_build_path() failed and returned NULL. It now pays attention to that case and returns a result reflecting failure. With this change in place, the bridging code will immediately detect a failure and end the bridge instead of proceeding to try to bridge frames that can't be translated and making channel drivers freak out by sending them frames in a format they weren't expecting. 2) In ast_indicate_data() of channel.c, failure of ast_playtones_start() was ignored. It is now reflected in the return value of the function. This didn't turn out to have any affect on the bug, but seemed like a good change to leave in. 3) In app_dial(), when only sending a call to a single endpoint, it will attempt to do some bridging of its own of early audio. It uses make_compatible() when it's going to do this. However, it ignored failure from make compatible. So, even with the fix from #1, if there was early audio going through app_dial, there would still be a period of invalid frames passing through. After detecting failure here, Dial() exits. ABE-2658 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@296001 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Richard Mudgett	da2b2990bf	Merged revisions 295790 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r295790 | rmudgett | 2010-11-22 12:46:26 -0600 (Mon, 22 Nov 2010) | 46 lines The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call. To recreate the problem: 1) Party A calls Party B 2) Invoke CLI "channel redirect" command to redirect channel call leg associated with A. 3) All associated channels are hung up. Note that if the CLI command were done on the channel call leg associated with B it works. This regression was a result of the fix for issue #16946 (https://reviewboard.asterisk.org/r/740/). The regression affects all features that use an async goto to execute the dialplan because of an external event: Channel redirect, AMI redirect, SIP REFER, and FAX detection. The struct ast_channel._softhangup code is a mess. The variable is used for several purposes that do not necessarily result in the call being hung up. I have added doxygen comments to describe how the various _softhangup bits are used. I have corrected all the places where the variable was tested in a non-bit oriented manner. The primary fix is the new AST_CONTROL_END_OF_Q frame. It acts as a weak hangup request so the soft hangup requests that do not normally result in a hangup do not hangup. JIRA SWP-2470 JIRA SWP-2489 (closes issue #18171) Reported by: SantaFox (closes issue #18185) Reported by: kwemheuer (closes issue #18211) Reported by: zahir_koradia (closes issue #18230) Reported by: vmarrone (closes issue #18299) Reported by: mbrevda (closes issue #18322) Reported by: nerbos Review: https://reviewboard.asterisk.org/r/1013/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@295843 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Richard Mudgett	4fc933a2b7	Merged revisions 295280 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r295280 | rmudgett | 2010-11-16 16:52:06 -0600 (Tue, 16 Nov 2010) | 1 line Dead code elimination in channel.c:ast_channel_bridge() variable who. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@295281 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Jeff Peeler	b94c33af8c	Fix playback failure when using IAX with the timerfd module. ... To fix this issue the alert pipe will now be used when the timerfd module is in use. There appeared to be a race that was not solved by adding locking in the timerfd module, but needed to be there anyway. The race was between the timer being put in non-continuous mode in ast_read on the channel thread and the IAX frame scheduler queuing a frame which would enable continuous mode before the non-continuous mode event was read. This race for now is simply avoided. (closes issue #18110) Reported by: tpanton Tested by: tpanton I put tested by tpanton because it was tested on his hardware. Thanks for the remote access to debug this issue! git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@294277 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Terry Wilson	79beea2574	Merged revisions 291577 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r291577 | twilson | 2010-10-13 15:45:15 -0700 (Wed, 13 Oct 2010) | 21 lines Don't ignore frames that have been queued when softhangup'd When an outgoing call is answered and hung up by the far end *very* quickly, we may not read any frames and therefor end up with a call that displays the wrong disposition/DIALSTATUS. The reason is because ast_queue_hangup() immediately sets the _softhangup flag on the channel and then queues the HANGUP control frame, but __ast_read refuses to read any frames if ast_check_hangup() indicates that a hangup request has been made (which it will if _softhangup is set). So, we end up losing control frames. This change makes __ast_read continue to read frames even if a soft hangup has been requested. It queues a hangup frame to make sure that __ast_read() will still eventually return NULL. Much thanks to David Vossel for all of the reviews, discussion, and help! (closes issue #16946) Reported by: davidw Review: https://reviewboard.asterisk.org/r/740/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@291580 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Jason Parker	62a1a460e0	Merged revisions 289338 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r289338 | qwell | 2010-09-29 15:56:26 -0500 (Wed, 29 Sep 2010) | 8 lines Allow a manager originate to succeed on forwarded devices. The timeout to wait for an answer was being set to 0 when a device forwarded to another extension. We don't always need the timeout set like this, so make it an optional parameter, and don't use it in this case. ABE-2544 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@289339 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Matthew Nicholson	ddbf2ec579	Merged revisions 289177 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r289177 | mnicholson | 2010-09-29 10:03:27 -0500 (Wed, 29 Sep 2010) | 8 lines Set the caller id on CDRs when it is set on the parent channel. (closes issue #17569) Reported by: tbelder Patches: 17569.diff uploaded by tbelder (license 618) Tested by: tbelder ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@289178 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Brett Bryant	58018f3262	Merged revisions 289094 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r289094 | bbryant | 2010-09-28 14:10:19 -0400 (Tue, 28 Sep 2010) | 14 lines Fixes an issue with the Newchannel AMI event during the Masquerading process. Fixes an issue with the Newchannel AMI event during the Masquerading process, where no Newchannel AMI event was generated for the psuedo channel used during the masquerading process. (closes issue #17987) Reported by: RadicAlish Patches: newchannel.patch.txt uploaded by RadicAlish (license 1122) Tested by: RadicAlish Review: https://reviewboard.asterisk.org/r/937/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@289095 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Brett Bryant	263cc8a827	Merged revisions 288005 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r288005 | bbryant | 2010-09-21 15:43:46 -0400 (Tue, 21 Sep 2010) | 8 lines Add a check to fix a rare segmentation fault you'd get if ast_frdup couldn't allocate memory on the first frame being queued in ast_queue_frame. (closes issue #17882) Reported by: seanbright Tested by: seanbright ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@288006 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Alec L Davis	845f142cfb	ast_channel_masquerade: Avoid recursive masquerades. ... Check all 4 combinations of (original/clonechan) * (masq/masqr). Initially original->masq and clonechan->masqr were only checked. It's possible with multiple masq's planned - and not yet executed, that the 'original' chan could already have another masq'd into it - thus original->masqr would be set, that masqr would lost. Likewise for the clonechan->masq. (closes issue #16057;#17363) Reported by: amorsen;davidw,alecdavis Patches: based on bug16057.diff4.txt uploaded by alecdavis (license 585) Tested by: ramonpeek, davidw, alecdavis git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@287685 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Matthew Nicholson	967116d236	Merged revisions 286679 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r286679 | mnicholson | 2010-09-14 13:00:01 -0500 (Tue, 14 Sep 2010) | 7 lines Only drop duplicate answer frames if the channel is bridged. Back in r3710 ast_read() was modified to drop answer frames on channels that were in the UP state. This modification prevented bridges that were up before the answer from being broken and reestablished by an ANSWER control frame. That change also prevents pickup of channels called from the ast_dial framework from working properly. The ast_dial framework expects to see an ANSWER frame after dialing and the pickup code queues one but ast_read() drops it. This new change only drops ANSWER frames when the channel is bridged, allowing the answer queued by the pickup code to properly pass through ast_read() on to the ast_dial framework. ABE-2473 (related to issue #2342) ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@286681 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Jason Parker	63ff776f65	Merged revisions 285742 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r285742 | qwell | 2010-09-09 15:06:31 -0500 (Thu, 09 Sep 2010) | 9 lines Transmit silence when reading DTMF in ast_readstring. Otherwise, you could get issues with DTMF timeouts causing hangups. (closes issue #17370) Reported by: makoto Patches: channel-readstring-silence-generator.patch uploaded by makoto (license 38) ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@285744 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Terry Wilson	79d5f46e1c	Merged revisions 282430 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r282430 | twilson | 2010-08-16 12:06:37 -0500 (Mon, 16 Aug 2010) | 16 lines Send a SRCCHANGE indication when we masquerade Masquerading a channel means that the src of the audio is potentially changing, so send a SRCCHANGE so that RTP-based media streams can get a new SSRC generated to reflect the change. Original patch by addix (along with lots of testing--thanks!). (closes issue #17007) Reported by: addix Patches: 1001-reset-SSRC-original-channel.diff uploaded by addix (license 1006) srcchange.diff uploaded by twilson (license 396) Tested by: addix, twilson Review: https://reviewboard.asterisk.org/r/862/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@282467 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Jeff Peeler	ade6beaf93	Merged revisions 281911 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r281911 | jpeeler | 2010-08-11 22:00:14 -0500 (Wed, 11 Aug 2010) | 20 lines Ensure SSRC is changed when media source is changed to resolve audio delay. This change causes the SSRC to change right before the channels are bridged, which is what used to happen. It seems that fixes were made to attempt limiting SSRC changes, targeted mainly at sending DTMF. DTMF is not affecting the SSRC with this change. There are two other control frames sent in ast_channel_bridge that probably should also be changed to AST_CONTROL_SRCCHANGE as well, but I'm going to leave this change up to the discretion of resolving issue #17007. For reference - old review implementing new control frame SRCCHANGE: https://reviewboard.asterisk.org/r/540 (closes issue #17404) Reported by: sdolloff Patches: bug17404.patch uploaded by jpeeler (license 325) Tested by: sdolloff ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@281912 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	69f2056e38	Merged revisions 280448 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r280448 | dvossel | 2010-07-29 14:04:23 -0500 (Thu, 29 Jul 2010) | 12 lines fixes issue with translator frame not getting freed A translator frame even if it local storage so the translation path can be freed. This issue prevented g729 licenses from being freed up. (closes issue #17630) Reported by: manvirr Patches: encoder_fix.diff uploaded by dvossel (license 671) Tested by: manvirr, dvossel ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@280449 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	3043c8f34e	Merged revisions 279945 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r279945 | dvossel | 2010-07-27 15:33:40 -0500 (Tue, 27 Jul 2010) | 19 lines remove empty audiohook write list on channel If a channel has an audiohook write list created on it, that list stays on the channel until the channel is destroyed. There is no reason to keep that list on the channel if it becomes empty. If it is empty that just means we are doing needless translating for every ast_read and ast_write. This patch removes the audiohook list from the channel once it is detected to be empty on either a read or write. If a audiohook is added back to the channel after this list is destroyed, the list just gets recreated as if it never existed to begin with. (closes issue #17630) Reported by: manvirr Review: https://reviewboard.asterisk.org/r/799/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@279946 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	688639d98a	Merged revisions 278620 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r278620 | mmichelson | 2010-07-22 09:58:01 -0500 (Thu, 22 Jul 2010) | 19 lines Merged revisions 278618 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r278618 | mmichelson | 2010-07-22 09:55:04 -0500 (Thu, 22 Jul 2010) | 13 lines Allow PLC to function properly when channels use SLIN for audio. If a channel involved in a bridge was using SLIN audio, then translation paths were not guaranteed to be set up properly since in all likelihood the number of translation steps was only 1. This patch enforces the transcode_via_slin behavior if transcode_via_slin or generic_plc is enabled and one of the formats to make compatible is SLIN. AST-352 ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@278621 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Matthew Nicholson	bffc529741	Merged revisions 277250 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r277250 | mnicholson | 2010-07-16 12:30:39 -0500 (Fri, 16 Jul 2010) | 11 lines Merged revisions 277247 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r277247 | mnicholson | 2010-07-16 12:29:57 -0500 (Fri, 16 Jul 2010) | 4 lines For pass through DTMF tones, measure the actual duration between the begin and end packets on the wire. If it is detected to be less than AST_MIN_DTMF_DURATION, trigger dtmf emulation. AST-362 ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@277256 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Jeff Peeler	41af8a2fb7	Merged revisions 276653 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r276653 | jpeeler | 2010-07-15 08:51:11 -0500 (Thu, 15 Jul 2010) | 9 lines Merged revisions 276652 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r276652 | jpeeler | 2010-07-15 08:48:58 -0500 (Thu, 15 Jul 2010) | 2 lines In a perfect world, the frame source would never be NULL. In the meantime, don't crash when it is. ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@276654 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Jeff Peeler	db39bf5ed1	Merged revisions 275682 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r275682 | jpeeler | 2010-07-12 12:21:01 -0500 (Mon, 12 Jul 2010) | 18 lines Merged revisions 275665 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r275665 | jpeeler | 2010-07-12 11:58:39 -0500 (Mon, 12 Jul 2010) | 11 lines Change ast_write to not stop generator when called from ast_prod. For SIP channels configured with the progressinband option on, the ringback was being immediately stopped. This problem was due to ast_prod being moved for a deadlock fix in 259858. Prodding the channel after setting up the generator triggered the check in ast_write to stop the generator. The fix here should write the frame the same as was done before the call to ast_prod was moved. (closes issue #17372) Reported by: tech_admin ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@275706 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Tilghman Lesher	adc0bc43ed	Merged revisions 273058 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r273058 | tilghman | 2010-06-29 17:59:51 -0500 (Tue, 29 Jun 2010) | 11 lines Recorded merge of revisions 273057 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r273057 | tilghman | 2010-06-29 17:58:58 -0500 (Tue, 29 Jun 2010) | 4 lines _Really_ skip the channel... don't just retry for another 200 cycles. (Closes issue SWP-1652, ABE-2240) ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@273059 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	1b5178d113	Merged revisions 269822 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r269822 | mmichelson | 2010-06-10 14:34:03 -0500 (Thu, 10 Jun 2010) | 25 lines Merged revisions 269821 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r269821 | mmichelson | 2010-06-10 14:30:12 -0500 (Thu, 10 Jun 2010) | 19 lines Fix potential crash when writing raw SLIN audio on a PLC-enabled channel. The issue here was that the frame created when adjusting for PLC had no offset to its audio data. If this frame were translated to another format prior to being sent out an RTP socket, all went well because the translation code would put an appropriate offset into the frame. However, if the SLIN audio were not translated before being sent out the RTP socket, bad things would happen. Specifically, the ast_rtp_raw_write makes the assumption that the frame has at least enough of an offset that it can accommodate an RTP header. This was not the case. As such, data was being written prior to the allocation, likely corrupting the data the memory allocator had written. Thus when the time came to free the data, all hell broke loose. ....Well, Asterisk crashed at least. The fix was just what one would expect. Offset the data in the frame by a reasonable amount. The method I used is a bit odd since the data in the frame is 16 bit integers and not bytes. I left a big ol' comment about it. This can be improved on if someone is interested. I was more interested in getting the crash resolved. ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@269823 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	a7c719e376	Merged revisions 265273 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r265273 | dvossel | 2010-05-24 11:10:09 -0500 (Mon, 24 May 2010) | 2 lines fixes segfault when using generic plc ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@265364 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	9a124ea569	Merged revisions 264997 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r264997 | mmichelson | 2010-05-21 11:44:27 -0500 (Fri, 21 May 2010) | 38 lines Merged revisions 264996 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r264996 | mmichelson | 2010-05-21 11:28:34 -0500 (Fri, 21 May 2010) | 32 lines Allow ast_safe_sleep to defer specific frames until after the sleep has concluded. From reviewboard Background: A Digium customer discovered a somewhat odd bug. The setup is that parties A and B are bridged, and party A places party B on hold. While party B is listening to hold music, he mashes a bunch of DTMF. Party A takes party B off hold while this is happening, but party B continues to hear hold music. I could reproduce this about 1 in 5 times. The issue: When DTMF features are enabled and a user presses keys, the channel that the DTMF is streamed to is placed in an ast_safe_sleep for 100 ms, the duration of the emulated tone. If an AST_CONTROL_UNHOLD frame is read from the channel during the sleep, the frame is dropped. Thus the unhold indication is never made to the channel that was originally placed on hold. The fix: Originally, I discussed with Kevin possible ways of fixing the specific problem reported. However, we determined that the same type of problem could happen in other situations where ast_safe_sleep() is used. Using autoservice as a model, I modified ast_safe_sleep_conditional() to defer specific frame types so they can be re-queued once the sleep has finished. I made a common function for determining if a frame should be deferred so that there are not two identical switch blocks to maintain. Review: https://reviewboard.asterisk.org/r/674/ ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@264998 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	af727635c5	Merged revisions 264452 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r264452 | mmichelson | 2010-05-19 16:29:08 -0500 (Wed, 19 May 2010) | 86 lines Fix transcode_via_sln option with SIP calls and improve PLC usage. From reviewboard: The problem here is a bit complex, so try to bear with me... It was noticed by a Digium customer that generic PLC (as configured in codecs.conf) did not appear to actually be having any sort of benefit when packet loss was introduced on an RTP stream. I reproduced this issue myself by streaming a file across an RTP stream and dropping approx. 5% of the RTP packets. I saw no real difference between when PLC was enabled or disabled when using wireshark to analyze the RTP streams. After analyzing what was going on, it became clear that one of the problems faced was that when running my tests, the translation paths were being set up in such a way that PLC could not possibly work as expected. To illustrate, if packets are lost on channel A's read stream, then we expect that PLC will be applied to channel B's write stream. The problem is that generic PLC can only be done when there is a translation path that moves from some codec to SLINEAR. When I would run my tests, I found that every single time, read and write translation paths would be set up on channel A instead of channel B. There appeared to be no real way to predict which channel the translation paths would be set up on. This is where Kevin swooped in to let me know about the transcode_via_sln option in asterisk.conf. It is supposed to work by placing a read translation path on both channels from the channel's rawreadformat to SLINEAR. It also will place a write translation path on both channels from SLINEAR to the channel's rawwriteformat. Using this option allows one to predictably set up translation paths on all channels. There are two problems with this, though. First and foremost, the transcode_via_sln option did not appear to be working properly when I was placing a SIP call between two endpoints which did not share any common formats. Second, even if this option were to work, for PLC to be applied, there had to be a write translation path that would go from some format to SLINEAR. It would not work properly if the starting format of translation was SLINEAR. The one-line change presented in this review request in chan_sip.c fixed the first issue for me. The problem was that in sip_request_call, the jointcapability of the outbound channel was being set to the format passed to sip_request_call. This is nativeformats of the inbound channel. Because of this, when ast_channel_make_compatible was called by app_dial, both channels already had compatibly read and write formats. Thus, no translation path was set up at the time. My change is to set the jointcapability of the sip_pvt created during sip_request_call to the intersection of the inbound channel's nativeformats and the configured peer capability that we determined during the earlier call to create_addr. Doing this got the translation paths set up as expected when using transcode_via_sln. The changes presented in channel.c fixed the second issue for me. First and foremost, when Asterisk is started, we'll read codecs.conf to see the value of the genericplc option. If this option is set, and ast_write is called for a frame with no data, then we will attempt to fill in the missing samples for the frame. The implementation uses a channel datastore for maintaining the PLC state and for creating a buffer to store PLC samples in. Even when we receive a frame with data, we'll call plc_rx so that the PLC state will have knowledge of the previous voice frame, which it can use as a basis for when it comes time to actually do a PLC fill-in. So, reviewers, now I ask for your help. First off, there's the one line change in chan_sip that I have put in. Is it right? By my logic it seems correct, but I'm sure someone can tell me why it is not going to work. This is probably the change I'm least concerned about, though. What concerns me much more is the set of changes in channel.c. First off, am I even doing it right? When I run tests, I can clearly see that when PLC is activated, I see a significant increase in RTP traffic where I would expect it to be. However, in my humble opinion, the audio sounds kind of crappy whenever the PLC fill-in is done. It sounds worse to me than when no PLC is used at all. I need someone to review the logic I have used to be sure that I'm not misusing anything. As far as I can see my pointer arithmetic is correct, and my use of AST_FRIENDLY_OFFSET should be correct as well, but I'm sure someone can point out somewhere where I've done something incorrectly. As I was writing this review request up, I decided to give the code a test run under valgrind, and I find that for some reason, calls to plc_rx are causing some invalid reads. Apparently I'm reading past the end of a buffer somehow. I'll have to dig around a bit to see why that is the case. If it's obvious to someone reviewing, speak up! Finally, I have one other proposal that is not reflected in my code review. Since without transcode_via_sln set, one cannot predict or control where a translation path will be up, it seems to me that the current practice of using PLC only when transcoding to SLINEAR is not useful. I recommend that once it has been determined that the method used in this code review is correct and works as expected, then the code in translate.c that invokes PLC should be removed. Review: https://reviewboard.asterisk.org/r/622/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@264453 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Tilghman Lesher	13adbe00e8	Merged revisions 261095 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r261095 | tilghman | 2010-05-04 18:51:52 -0500 (Tue, 04 May 2010) | 18 lines Merged revisions 261093-261094 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r261093 | tilghman | 2010-05-04 18:36:53 -0500 (Tue, 04 May 2010) | 7 lines Protect against overflow, when calculating how long to wait for a frame. (closes issue #17128) Reported by: under Patches: d.diff uploaded by under (license 914) ........ r261094 | tilghman | 2010-05-04 18:47:08 -0500 (Tue, 04 May 2010) | 2 lines Add a tiny corner case to the previous commit ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@261098 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Matthew Nicholson	55993d7b13	Merged revisions 254450 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r254450 | kpfleming | 2010-03-25 10:27:31 -0500 (Thu, 25 Mar 2010) | 49 lines Improve handling of T.38 re-INVITEs that arrive before a T.38-capable application is executing on a channel. This patch addresses an issue found during working with end-users using res_fax. If an incoming call is answered in the dialplan, or jumps to the 'fax' extension due to reception of a CNG tone (with faxdetect enabled), and then the remote endpoint sends a T.38 re-INVITE, it is possible for the channel's T.38 state to be 'T38_STATE_NEGOTIATING' when the application starts up. Unfortunately, even if the application wants to use T.38, it can't respond to the peer's negotiation request, because the AST_CONTROL_T38_PARAMETERS control frame that chan_sip sent originally has been lost, and the application needs the content of that frame to be able to formulate a reply. This patch adds a new 'request' type to AST_CONTROL_T38_PARAMETERS, AST_T38_REQUEST_PARMS. If the application sends this request, chan_sip will re-send the original control frame (with AST_T38_REQUEST_NEGOTIATE as the request type), and the application can respond as normal. If this occurs within the five second timeout in chan_sip, the automatic cancellation of the peer reinvite will be stopped, and the application will 'own' the negotiation process from that point onwards. This also improves the code path in chan_sip to allow sip_indicate(), when called for AST_CONTROL_T38_PARAMETERS, to be able to return a non-zero response, which should have been in place before since the control frame *can* fail to be processed properly. It also modifies ast_indicate() to return whatever result the channel driver returned for this control frame, rather than converting all non-zero results into '-1'. Finally, the new request type intentionally returns a positive value, so that an application that sends AST_T38_REQUEST_PARMS can know for certain whether the channel driver accepted it and will be replying with a control frame of its own, or whether it was ignored (if the sip_indicate()/ast_indicate() path had properly supported failure responses before, this would not be necessary). This patch also modifies res_fax to take advantage of the new request. In addition, this patch makes sip_t38_abort() actually lock the private structure before doing its work... bad programmer, no donut. This patch also enhances chan_sip's 'faxdetect' support to allow triggering on T.38 re-INVITEs received as well as CNG tone detection. Review: https://reviewboard.asterisk.org/r/556/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@260884 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	d3aec99800	Merged revisions 259870 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r259870 | dvossel | 2010-04-28 16:20:03 -0500 (Wed, 28 Apr 2010) | 39 lines Merged revisions 259858 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r259858 | dvossel | 2010-04-28 16:16:03 -0500 (Wed, 28 Apr 2010) | 33 lines resolves deadlocks in chan_local Issue_1. In the local_hangup() 3 locks must be held at the same time... pvt, pvt->chan, and pvt->owner. Proper deadlock avoidance is done when the channel to hangup is the outbound chan_local channel, but when it is not the outbound channel we have an issue... We attempt to do deadlock avoidance only on the tech pvt, when both the tech pvt and the pvt->owner are locked coming into that loop. By never giving up the pvt->owner channel deadlock avoidance is not entirely possible. This patch resolves that by doing deadlock avoidance on both the pvt->owner and the pvt when trying to get the pvt->chan lock. Issue_2. ast_prod() is used in ast_activate_generator() to queue a frame on the channel and make the channel's read function get called. This function is used in ast_activate_generator() while the channel is locked, which mean's the channel will have a lock both from the generator code and the frame_queue code by the time it gets to chan_local.c's local_queue_frame code... local_queue_frame contains some of the same crazy deadlock avoidance that local_hangup requires, and this recursive lock prevents that deadlock avoidance from happening correctly. This patch removes ast_prod() from the channel lock so only one lock is held during the local_queue_frame function. (closes issue #17185) Reported by: schmoozecom Patches: issue_17185_v1.diff uploaded by dvossel (license 671) issue_17185_v2.diff uploaded by dvossel (license 671) Tested by: schmoozecom, GameGamer43 Review: https://reviewboard.asterisk.org/r/631/ ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@259899 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	4608dcaaa5	Merged revisions 259105 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r259105 | mmichelson | 2010-04-26 16:45:13 -0500 (Mon, 26 Apr 2010) | 9 lines Merged revisions 259104 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r259104 | mmichelson | 2010-04-26 16:44:43 -0500 (Mon, 26 Apr 2010) | 3 lines Let compilation succeed warning-free when DONT_OPTIMIZE is turned off. ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@259109 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	1cddd210c9	Merged revisions 259023 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r259023 | mmichelson | 2010-04-26 16:13:35 -0500 (Mon, 26 Apr 2010) | 19 lines Merged revisions 259018 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r259018 | mmichelson | 2010-04-26 16:03:08 -0500 (Mon, 26 Apr 2010) | 13 lines Prevent Newchannel manager events for dummy channels. No Newchannel manager event will be fired for channels that are allocated to not match a registered technology type. Thus bogus channels allocated solely for variable substitution or CDR operations do not result in a Newchannel event. (closes issue #16957) Reported by: atis Review: https://reviewboard.asterisk.org/r/601 ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@259103 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Matthew Nicholson	d0b77185dd	Merged revisions 258671,258675 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r258671 | mnicholson | 2010-04-22 16:57:59 -0500 (Thu, 22 Apr 2010) | 32 lines Merged revisions 193391,258670 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r193391 | mnicholson | 2009-05-08 16:01:25 -0500 (Fri, 08 May 2009) | 8 lines Set the proper disposition on originated calls. (closes issue #14167) Reported by: jpt Patches: call-file-missing-cdr2.diff uploaded by mnicholson (license 96) Tested by: dlotina, rmartinez, mnicholson ........ r258670 | mnicholson | 2010-04-22 16:49:07 -0500 (Thu, 22 Apr 2010) | 11 lines Fix broken CDR behavior. This change allows a CDR record previously marked with disposition ANSWERED to be set as BUSY or NO ANSWER. Additionally this change partially reverts r235635 and does not set the AST_CDR_FLAG_ORIGINATED flag on CDRs generated from ast_call(). To preserve proper CDR behavior, the AST_CDR_FLAG_DIALED flag is now cleared from all brige CDRs in ast_bridge_call(). (closes issue #16797) Reported by: VarnishedOtter Tested by: mnicholson ........ (closes issue #16222) Reported by: telles Tested by: mnicholson ................ r258675 | mnicholson | 2010-04-22 17:11:23 -0500 (Thu, 22 Apr 2010) | 2 lines Fix previous commit. ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@258676 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Russell Bryant	455aebd1bf	Merged revisions 256010 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r256010 | russell | 2010-04-02 18:30:58 -0500 (Fri, 02 Apr 2010) | 9 lines Merged revisions 256009 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r256009 | russell | 2010-04-02 18:30:15 -0500 (Fri, 02 Apr 2010) | 2 lines Remove extremely verbose debug message. ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@256013 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Jeff Peeler	5d69458b6c	Merged revisions 254050 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r254050 | jpeeler | 2010-03-23 16:17:23 -0500 (Tue, 23 Mar 2010) | 14 lines Exit native bridging early for greater timing accuracy with warnings This changes native bridging to break one millisecond early so that the more accurate timeval calculations done in the generic bridge can be performed using the bridge config. Currently the time between exiting native bridging slightly late can sometimes cause a large enough discrepancy for warnings to be missed. For the record, 1.4 does not attempt to native bridge at all when warnings are enabled. (closes issue #15815) Reported by: adomjan Review: https://reviewboard.asterisk.org/r/577/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@254068 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Terry Wilson	6bfb1fca95	Merged revisions 252089 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r252089 | twilson | 2010-03-12 16:04:51 -0600 (Fri, 12 Mar 2010) | 20 lines Only change the RTP ssrc when we see that it has changed This change basically reverts the change reviewed in https://reviewboard.asterisk.org/r/374/ and instead limits the updating of the RTP synchronization source to only those times when we detect that the other side of the conversation has changed the ssrc. The problem is that SRCUPDATE control frames are sent many times where we don't want a new ssrc, including whenever Asterisk has to send DTMF in a normal bridge. This is also not the first time that this mistake has been made. The initial implementation of the ast_rtp_new_source function also changed the ssrc--and then it was removed because of this same issue. Then, we put it back in again to fix a different issue. This patch attempts to only change the ssrc when we see that the other side of the conversation has changed the ssrc. It also renames some functions to make their purpose more clear. Review: https://reviewboard.asterisk.org/r/540/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@252137 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	24bdd13e6a	fixes merge error with Monitor calculation fix ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@246901 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	3ade195b8a	Merged revisions 246899 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r246899 | dvossel | 2010-02-16 11:07:41 -0600 (Tue, 16 Feb 2010) | 16 lines fixes sample rate conversion issue with Monitor application When using ast_seekstream with the read/write streams of a monitor, the number of samples we are seeking must be of the same rate as the stream or the jump calculation will be incorrect. This patch adds logic to correctly convert the number of samples to jump to the sample rate the read/write stream is using. For example, if the call is G722 (16khz) and the read/write stream is recording a 8khz wav, seeking 320 samples of 16khz audio is not the same as seeking 320 samples of 8khz audio when performing the ast_seekstream on the stream. ABE-2044 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@246900 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	85614277f8	Merged revisions 246546 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r246546 | dvossel | 2010-02-12 17:32:33 -0600 (Fri, 12 Feb 2010) | 21 lines Merged revisions 246545 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r246545 | dvossel | 2010-02-12 17:30:17 -0600 (Fri, 12 Feb 2010) | 16 lines lock channel during datastore removal On channel destruction the channel's datastores are removed and destroyed. Since there are public API calls to find and remove datastores on a channel, a lock should be held whenever datastores are removed and destroyed. This resolves a crash caused by a race condition in app_chanspy.c. (closes issue #16678) Reported by: tim_ringenbach Patches: datastore_destroy_race.diff uploaded by tim ringenbach (license 540) Tested by: dvossel ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@246547 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Jason Parker	94edab1f99	Fix some silly formatting that made my head hurt. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@246464 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Tilghman Lesher	47233bcba3	Merged revisions 244071 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r244071 | tilghman | 2010-02-01 11:53:39 -0600 (Mon, 01 Feb 2010) | 22 lines Merged revisions 244070 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r244070 | tilghman | 2010-02-01 11:46:31 -0600 (Mon, 01 Feb 2010) | 16 lines Revert previous chan_local fix (r236981) and fix instead by destroying expired frames in the queue. (closes issue #16525) Reported by: kobaz Patches: 20100126__issue16525.diff.txt uploaded by tilghman (license 14) 20100129__issue16525__1.6.0.diff.txt uploaded by tilghman (license 14) Tested by: kobaz, atis (closes issue #16581) Reported by: ZX81 (closes issue #16681) Reported by: alexr1 ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@244073 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Jeff Peeler	ca282be16d	Merged revisions 243266 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r243266 | jpeeler | 2010-01-26 12:20:55 -0600 (Tue, 26 Jan 2010) | 9 lines Merged revisions 243258 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r243258 | jpeeler | 2010-01-26 12:19:10 -0600 (Tue, 26 Jan 2010) | 2 lines Remove unnecessary code in ast_read as issue 16058 has been fully solved now. ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@243297 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	fb2a66d004	Merged revisions 239712 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r239712 | dvossel | 2010-01-13 10:31:14 -0600 (Wed, 13 Jan 2010) | 24 lines add silence gen to wait apps asterisk.conf's 'transmit_silence' option existed before this patch, but was limited to only generating silence while recording and sending DTMF. Now enabling the transmit_silence option generates silence during wait times as well. To achieve this, ast_safe_sleep has been modified to generate silence anytime no other generators are present and transmit_silence is enabled. Wait apps not using ast_safe_sleep now generate silence when transmit_silence is enabled as well. (closes issue #16524) Reported by: kobaz (closes issue #16523) Reported by: kobaz Tested by: dvossel Review: https://reviewboard.asterisk.org/r/456/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@239713 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Jeff Peeler	4f7c2bdf62	Merged revisions 235660 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r235660 | jpeeler | 2009-12-18 16:51:37 -0600 (Fri, 18 Dec 2009) | 55 lines Merged revisions 235635 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r235635 | jpeeler | 2009-12-18 16:29:51 -0600 (Fri, 18 Dec 2009) | 48 lines Correct CDR dispositions for BUSY/FAILED This patch is simple in that it reorders the disposition defines so that the fix for issue 12946 works properly (the default CDR disposition was changed to AST_CDR_NOANSWER). Also, the AST_CDR_FLAG_ORIGINATED flag was set in ast_call to ensure all CDR records are written. The side effects of CDR changes are scary, so I'm documenting the test cases performed to attempt to catch any regressions. The following tests were all performed using 1.4 rev 195881 vs head (235571) + patch: A calls B C calls B (busy) Hangup C Hangup A (Both SIP and features) A calls B A blind transfers to C Hangup C (Both SIP and features) A calls B A attended transfers to C Hangup C A calls B A attended transfers to C (SIP) C blind transfers to A (features) Hangup A All of the test scenario CDRs matched. The following tests were performed just with the patch to ensure proper operation (with unanswered=yes): exten =>s,1,Answer exten =>s,n,ResetCDR(w) exten =>s,n,ResetCDR(w) exten =>s,1,ResetCDR(w) exten =>s,n,ResetCDR(w) (closes issue #16180) Reported by: aatef Patches: bug16180.patch uploaded by jpeeler (license 325) ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@235665 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Russell Bryant	465653271a	Merged revisions 233100 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r233100 | russell | 2009-12-04 11:18:22 -0600 (Fri, 04 Dec 2009) | 14 lines Merged revisions 233092 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r233092 | russell | 2009-12-04 11:12:47 -0600 (Fri, 04 Dec 2009) | 7 lines Only do frame payload check for HOLD frames. This code was added for helping to debug the source of invalid HOLD frames. However, a side effect of this is that it will incorrectly report errors for frames that have an integer payload. Make the check for this block specific to the HOLD frame case. ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@233130 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Jeff Peeler	dfc33aa2d4	Merged revisions 231927 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r231927 | jpeeler | 2009-12-01 15:54:21 -0600 (Tue, 01 Dec 2009) | 19 lines Merged revisions 231911 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r231911 | jpeeler | 2009-12-01 15:29:31 -0600 (Tue, 01 Dec 2009) | 12 lines Fix crash with invalid frame data The crash was happening as a result of a frame containing an invalid data pointer, but was set with data length of zero. The few times the issue was reproduced it _seemed_ that the frame was queued properly, that is the data pointer was set to NULL. I never could reproduce the crash so as a last resort the crash has been fixed, but a check in __ast_read has been added to give as much information about the source of problematic frames in the future. (closes issue #16058) Reported by: atis ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@231930 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago