aboutsummaryrefslogtreecommitdiffstats
path: root/main/channel.c
AgeCommit message (Collapse)AuthorFilesLines
2009-11-09Merged revisions 228897 via svnmerge from lmadsen1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r228897 | lmadsen | 2009-11-09 09:38:38 -0600 (Mon, 09 Nov 2009) | 14 lines Merged revisions 228896 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r228896 | lmadsen | 2009-11-09 09:37:43 -0600 (Mon, 09 Nov 2009) | 6 lines Update WARNING message. Update a WARNING message to give a suggested fix when encountered. (closes issue #16198) Reported by: atis Tested by: atis ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@228898 f38db490-d61c-443f-a65b-d21fe96a405b
2009-11-06Merged revisions 228693 via svnmerge from dvossel1-2/+10
https://origsvn.digium.com/svn/asterisk/trunk ................ r228693 | dvossel | 2009-11-06 16:35:44 -0600 (Fri, 06 Nov 2009) | 16 lines Merged revisions 228692 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r228692 | dvossel | 2009-11-06 16:33:27 -0600 (Fri, 06 Nov 2009) | 9 lines fixes audiohook write crash occuring in chan_spy whisper mode. After writing to the audiohook list in ast_write(), frames were being freed incorrectly. Under certain conditions this resulted in a double free crash. (closes issue #16133) Reported by: wetwired ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@228696 f38db490-d61c-443f-a65b-d21fe96a405b
2009-10-09Merged revisions 223273 via svnmerge from mnicholson1-1/+5
https://origsvn.digium.com/svn/asterisk/trunk ................ r223273 | mnicholson | 2009-10-09 13:34:08 -0500 (Fri, 09 Oct 2009) | 14 lines Merged revisions 223225 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r223225 | mnicholson | 2009-10-09 13:20:11 -0500 (Fri, 09 Oct 2009) | 8 lines Signal timeouts by returning AST_CONTROL_RINGING when originating calls. (closes issue #15104) Reported by: nblasgen Patches: manager-timeout1.diff uploaded by mnicholson (license 96) Tested by: nblasgen, mnicholson ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@223276 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-30Merged revisions 221201 via svnmerge from tilghman1-5/+2
https://origsvn.digium.com/svn/asterisk/trunk ................ r221201 | tilghman | 2009-09-30 11:56:42 -0500 (Wed, 30 Sep 2009) | 14 lines Merged revisions 221200 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r221200 | tilghman | 2009-09-30 11:55:21 -0500 (Wed, 30 Sep 2009) | 7 lines Avoid a potential NULL dereference. (closes issue #15865) Reported by: kobaz Patches: 20090915__issue15865.diff.txt uploaded by tilghman (license 14) Tested by: kobaz ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@221202 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-17Merged revisions 219139 via svnmerge from mnicholson1-8/+25
https://origsvn.digium.com/svn/asterisk/trunk ................ r219139 | mnicholson | 2009-09-17 10:18:01 -0500 (Thu, 17 Sep 2009) | 17 lines Merged revisions 219136 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r219136 | mnicholson | 2009-09-17 09:58:39 -0500 (Thu, 17 Sep 2009) | 10 lines Prevent a potential race condition and crash when hanging up a channel by removing the channel from the channel list before begining channel tear down. This fix may potentially cause problems with CDR backends that access the channel a CDR is associated with via the channel list. This fix makes the channel unavabile at the time when the CDR backend is invoked. This has been documented in include/asterisk/cdr.h. (closes issue #15316) Reported by: vmarrone Tested by: mnicholson Review: https://reviewboard.asterisk.org/r/362/ ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@219198 f38db490-d61c-443f-a65b-d21fe96a405b
2009-08-28Merged revisions 214702 via svnmerge from tilghman1-4/+4
https://origsvn.digium.com/svn/asterisk/trunk ................ r214702 | tilghman | 2009-08-28 15:14:39 -0500 (Fri, 28 Aug 2009) | 15 lines Merged revisions 214701 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r214701 | tilghman | 2009-08-28 15:13:32 -0500 (Fri, 28 Aug 2009) | 8 lines Modify comment to be a bit more accurate. We have kept this comment around long enough, that it's pretty clear that we're keeping the code, because changing the code would require a pretty fundamental architectural shift. We've also taken criticism in some quarters, because it was believed that it was referring to the code being nasty. No, the code isn't nasty, just the operation itself is rather odd. Fixed for eternity (probably not). ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@214703 f38db490-d61c-443f-a65b-d21fe96a405b
2009-08-26Merged revisions 214195 via svnmerge from dvossel1-2/+25
https://origsvn.digium.com/svn/asterisk/trunk ................ r214195 | dvossel | 2009-08-26 11:38:53 -0500 (Wed, 26 Aug 2009) | 25 lines Merged revisions 214194 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r214194 | dvossel | 2009-08-26 11:36:42 -0500 (Wed, 26 Aug 2009) | 19 lines ast_write() ignores ast_audiohook_write() results In ast_write(), if a channel has a list of audiohooks, those lists are written to and the resulting frame is what ast_write() should continue with. The problem was the returned audiohook frame was not being handled at all, and the original frame passed into it did not contain the mixed audio, so essentially audio was being lost. One result of this was chan_spy's whisper mode no longer worked. To complicate the issue, frames passed into ast_write may either be a single frame, or a list of frames. So, as the list of frames is processed in the audiohook_write, the returned frames had to be added to a new list. (closes issue #15660) Reported by: corruptor Tested by: dvossel ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@214198 f38db490-d61c-443f-a65b-d21fe96a405b
2009-08-10AST-2009-005tilghman1-2/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@211551 f38db490-d61c-443f-a65b-d21fe96a405b
2009-08-06Merged revisions 210914 via svnmerge from tilghman1-0/+2
https://origsvn.digium.com/svn/asterisk/trunk ................ r210914 | tilghman | 2009-08-06 16:46:01 -0500 (Thu, 06 Aug 2009) | 14 lines Merged revisions 210913 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r210913 | tilghman | 2009-08-06 16:45:01 -0500 (Thu, 06 Aug 2009) | 7 lines Because channel information can be accessed outside of the channel thread, we must lock the channel prior to modifying it. (closes issue #15397) Reported by: caspy Patches: 20090714__issue15397.diff.txt uploaded by tilghman (license 14) Tested by: caspy ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@210915 f38db490-d61c-443f-a65b-d21fe96a405b
2009-07-23Merged revisions 208464 via svnmerge from kpfleming1-4/+5
https://origsvn.digium.com/svn/asterisk/trunk ........ r208464 | kpfleming | 2009-07-23 16:57:24 -0500 (Thu, 23 Jul 2009) | 46 lines Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@208468 f38db490-d61c-443f-a65b-d21fe96a405b
2009-07-20Merged revisions 207361 via svnmerge from russell1-6/+11
https://origsvn.digium.com/svn/asterisk/trunk ................ r207361 | russell | 2009-07-20 11:36:15 -0500 (Mon, 20 Jul 2009) | 16 lines Merged revisions 207360 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r207360 | russell | 2009-07-20 11:26:24 -0500 (Mon, 20 Jul 2009) | 9 lines Only do the chan->fdno check in ast_read() in a developer build. I changed this check to only happen in a dev-mode build. I also added a comment explaining what is going on. I also made it so that detection of this situation does not affect ast_read() operation. (closes issue #14723) Reported by: seadweller ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@207362 f38db490-d61c-443f-a65b-d21fe96a405b
2009-07-06Merged revisions 204948 via svnmerge from kpfleming1-3/+10
https://origsvn.digium.com/svn/asterisk/trunk ........ r204948 | kpfleming | 2009-07-06 08:38:29 -0500 (Mon, 06 Jul 2009) | 7 lines Improve handling of AST_CONTROL_T38 and AST_CONTROL_T38_PARAMETERS for non-T.38-capable channels. This change allows applications that request T.38 negotiation on a channel that does not support it to get the proper indication that it is not supported, rather than thinking that negotiation was started when it was not. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@204949 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-26Merged revisions 203699 via svnmerge from file1-0/+3
https://origsvn.digium.com/svn/asterisk/trunk ........ r203699 | file | 2009-06-26 16:27:24 -0300 (Fri, 26 Jun 2009) | 2 lines Improve T.38 negotiation by exchanging session parameters between application and channel. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@203701 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-22Merged revisions 202497 via svnmerge from russell1-14/+24
https://origsvn.digium.com/svn/asterisk/trunk ................ r202497 | russell | 2009-06-22 15:11:04 -0500 (Mon, 22 Jun 2009) | 11 lines Merged revisions 202496 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r202496 | russell | 2009-06-22 15:08:53 -0500 (Mon, 22 Jun 2009) | 4 lines Report CallerID change during a masquerade. Reported by: markster ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@202498 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-17Merged revisions 201458 via svnmerge from mmichelson1-1/+5
https://origsvn.digium.com/svn/asterisk/trunk ................ r201458 | mmichelson | 2009-06-17 15:04:12 -0500 (Wed, 17 Jun 2009) | 15 lines Merged revisions 201450 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r201450 | mmichelson | 2009-06-17 14:59:31 -0500 (Wed, 17 Jun 2009) | 9 lines Change the datastore traversal in ast_do_masquerade to use a safe list traversal. It is possible for datastore fixup functions to remove the datastore from the list and free it. In particular, the queue_transfer_fixup in app_queue does this. While I don't yet know of this causing any crashes, it certainly could. Found while discussing a separate issue with Brian Degenhardt. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@201459 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-16Merged revisions 201056,201090 via svnmerge from kpfleming1-76/+159
https://origsvn.digium.com/svn/asterisk/trunk ................ r201056 | kpfleming | 2009-06-16 13:54:30 -0500 (Tue, 16 Jun 2009) | 18 lines Merged revisions 200991 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r200991 | kpfleming | 2009-06-16 12:05:38 -0500 (Tue, 16 Jun 2009) | 11 lines Improve support for media paths that can generate multiple frames at once. There are various media paths in Asterisk (codec translators and UDPTL, primarily) that can generate more than one frame to be generated when the application calling them expects only a single frame. This patch addresses a number of those cases, at least the primary ones to solve the known problems. In addition it removes the broken TRACE_FRAMES support, fixes a number of bugs in various frame-related API functions, and cleans up various code paths affected by these changes. https://reviewboard.asterisk.org/r/175/ ........ ................ r201090 | kpfleming | 2009-06-16 14:27:12 -0500 (Tue, 16 Jun 2009) | 5 lines Another minor fix to compiler attribute checking. Defaulting to 'static' for the function scope was bad... so remove it. ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@201093 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-12Merged revisions 200361 via svnmerge from mmichelson1-0/+10
https://origsvn.digium.com/svn/asterisk/trunk ................ r200361 | mmichelson | 2009-06-12 14:07:51 -0500 (Fri, 12 Jun 2009) | 16 lines Merged revisions 200360 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r200360 | mmichelson | 2009-06-12 14:06:41 -0500 (Fri, 12 Jun 2009) | 10 lines Suppress a warning message and give a better return code when generating inband ringing after a call is answered. (closes issue #15158) Reported by: madkins Patches: 15158.patch uploaded by mmichelson (license 60) Tested by: madkins ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@200362 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-03Merged revisions 198856 via svnmerge from dvossel1-5/+93
https://origsvn.digium.com/svn/asterisk/trunk ........ r198856 | dvossel | 2009-06-02 16:17:49 -0500 (Tue, 02 Jun 2009) | 10 lines Generic call forward api, ast_call_forward() The function ast_call_forward() forwards a call to an extension specified in an ast_channel's call_forward string. After an ast_channel is called, if the channel's call_forward string is set this function can be used to forward the call to a new channel and terminate the original one. I have included this api call in both channel.c's ast_request_and_dial() and feature.c's feature_request_and_dial(). App_dial and app_queue already contain call forward logic specific for their application and options. (closes issue #13630) Reported by: festr Review: https://reviewboard.asterisk.org/r/271/ ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@198889 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-29Merged revisions 198072 via svnmerge from mnicholson1-0/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r198072 | mnicholson | 2009-05-29 14:04:24 -0500 (Fri, 29 May 2009) | 21 lines Merged revisions 198068 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r198068 | mnicholson | 2009-05-29 13:53:01 -0500 (Fri, 29 May 2009) | 15 lines Use AST_CDR_NOANSWER instead of AST_CDR_NULL as the default CDR disposition. This change also involves the addition of an AST_CDR_FLAG_ORIGINATED flag that is used on originated channels to distinguish: them from dialed channels. (closes issue #12946) Reported by: meral Patches: null-cdr2.diff uploaded by mnicholson (license 96) Tested by: mnicholson, dbrooks (closes issue #15122) Reported by: sum Tested by: sum ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@198073 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-27Fix broken attended transfersjpeeler1-5/+6
The bridge was terminating immediately after the attended transfer was completed. The problem was because upon reentering ast_channel_bridge nexteventts was checked to see if it was set and if so could possibly return AST_BRIDGE_COMPLETE. (closes issue #15183) Reported by: andrebarbosa Tested by: andrebarbosa, tootai, loloski git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@197126 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-13Recorded merge of revisions 194357 via svnmerge from mmichelson1-1/+0
https://origsvn.digium.com/svn/asterisk/trunk ................ r194357 | mmichelson | 2009-05-13 14:42:51 -0500 (Wed, 13 May 2009) | 18 lines Blocked revisions 194356 via svnmerge ........ r194356 | mmichelson | 2009-05-13 14:41:44 -0500 (Wed, 13 May 2009) | 13 lines Remove an extraneous unlocking operation from ast_channel_free. In the case that we could not remove the desired channel from the list of channels, there was an extra call to unlock the channel list. Since we unlock the list later on in the function anyway, this results in the list being unlocked twice yet only being locked once. (closes issue #15098) Reported by: tim_ringenbach Patches: remove_extra_unlock.diff uploaded by tim (license 540) ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@194358 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-05Merged revisions 192318 via svnmerge from kpfleming1-7/+66
https://origsvn.digium.com/svn/asterisk/trunk ........ r192318 | kpfleming | 2009-05-05 12:34:19 +0200 (Tue, 05 May 2009) | 5 lines Properly account for memory allocated for channels and datastores As in previous commits, when channels are allocated (with ast_channel_alloc) or datastores are allocated (with ast_datastore_alloc) properly account for the memory being owned by the caller, instead of the allocator function itself. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@192353 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-01Merged revisions 191489 via svnmerge from jpeeler1-1/+20
https://origsvn.digium.com/svn/asterisk/trunk ................ r191489 | jpeeler | 2009-05-01 13:09:23 -0500 (Fri, 01 May 2009) | 15 lines Merged revisions 191488 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r191488 | jpeeler | 2009-05-01 12:40:46 -0500 (Fri, 01 May 2009) | 9 lines Fix DTMF not being sent to other side after a partial feature match This fixes a regression from commit 176701. The issue was that ast_generic_bridge never exited after the feature digit timeout had elapsed, which prevented the queued DTMF from being sent to the other side. This issue was reported to me directly. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@191499 f38db490-d61c-443f-a65b-d21fe96a405b
2009-04-20Merged revisions 189278 via svnmerge from mmichelson1-7/+7
https://origsvn.digium.com/svn/asterisk/trunk ................ r189278 | mmichelson | 2009-04-20 09:05:27 -0500 (Mon, 20 Apr 2009) | 18 lines Merged revisions 189277 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r189277 | mmichelson | 2009-04-20 09:04:41 -0500 (Mon, 20 Apr 2009) | 12 lines Move the check for chan->fdno == -1 to after the zombie/hangup check. Many users were finding that their hung up channels were staying up and causing 100% CPU usage. (issue #14723) Reported by: seadweller Patches: 14723_1-4-tip.patch uploaded by mmichelson (license 60) Tested by: falves11, bamby ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@189279 f38db490-d61c-443f-a65b-d21fe96a405b
2009-04-08Merged revisions 186985 via svnmerge from mmichelson1-6/+10
https://origsvn.digium.com/svn/asterisk/trunk ................ r186985 | mmichelson | 2009-04-08 10:27:41 -0500 (Wed, 08 Apr 2009) | 30 lines Merged revisions 186984 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r186984 | mmichelson | 2009-04-08 10:26:46 -0500 (Wed, 08 Apr 2009) | 24 lines Make a couple of changes with regards to a new message printed in ast_read(). "ast_read() called with no recorded file descriptor" is a new message added after a bug was discovered. Unfortunately, it seems there are a bunch of places that potentially make such calls to ast_read() and trigger this error message to be displayed. This commit does two things to help to make this message appear less. First, the message has been downgraded to a debug level message if dev mode is not enabled. The message means a lot more to developers than it does to end users, and so developers should take an effort to be sure to call ast_read only when a channel is ready to be read from. However, since this doesn't actually cause an error in operation and is not something a user can easily fix, we should not spam their console with these messages. Second, the message has been moved to after the check for any pending masquerades. ast_read() being called with no recorded file descriptor should not interfere with a masquerade taking place. This could be seen as a simple way of resolving issue #14723. However, I still want to try to clear out the existing ways of triggering this message, since I feel that would be a better resolution for the issue. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@186986 f38db490-d61c-443f-a65b-d21fe96a405b
2009-04-07Merged revisions 186833 via svnmerge from mmichelson1-0/+3
https://origsvn.digium.com/svn/asterisk/trunk ................ r186833 | mmichelson | 2009-04-07 18:50:56 -0500 (Tue, 07 Apr 2009) | 15 lines Merged revisions 186832 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r186832 | mmichelson | 2009-04-07 18:49:49 -0500 (Tue, 07 Apr 2009) | 8 lines Set the AST_FEATURE_WARNING_ACTIVE flag when a p2p bridge returns AST_BRIDGE_RETRY. Without this flag set, warning sounds will not be properly played to either party of the bridge. (closes issue #14845) Reported by: adomjan ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@186834 f38db490-d61c-443f-a65b-d21fe96a405b
2009-04-01Merged revisions 185772 via svnmerge from russell1-0/+7
https://origsvn.digium.com/svn/asterisk/trunk ................ r185772 | russell | 2009-04-01 08:48:26 -0500 (Wed, 01 Apr 2009) | 14 lines Merged revisions 185771 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r185771 | russell | 2009-04-01 08:47:30 -0500 (Wed, 01 Apr 2009) | 6 lines Fix a case where DTMF could bypass audiohooks. This change fixes a situation where an audiohook that wants DTMF would not actually get it. This is in the code path where we end DTMF digit length emulation while handling a NULL frame. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@185773 f38db490-d61c-443f-a65b-d21fe96a405b
2009-03-18Merged revisions 183057 via svnmerge from file1-0/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r183057 | file | 2009-03-18 19:22:56 -0300 (Wed, 18 Mar 2009) | 6 lines Fix an issue where a T38 control frame would get dropped. If two channels were bridged together using a generic bridge the T38 control frame would get passed up instead of being indicated on the other channel. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@183066 f38db490-d61c-443f-a65b-d21fe96a405b
2009-03-18Merged revisions 182847 via svnmerge from russell1-2/+2
https://origsvn.digium.com/svn/asterisk/trunk ................ r182847 | russell | 2009-03-17 21:28:55 -0500 (Tue, 17 Mar 2009) | 52 lines Merged revisions 182810 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r182810 | russell | 2009-03-17 21:09:13 -0500 (Tue, 17 Mar 2009) | 44 lines Fix cases where the internal poll() was not being used when it needed to be. We have seen a number of problems caused by poll() not working properly on Mac OSX. If you search around, you'll find a number of references to using select() instead of poll() to work around these issues. In Asterisk, we've had poll.c which implements poll() using select() internally. However, we were still getting reports of problems. vadim investigated a bit and realized that at least on his system, even though we were compiling in poll.o, the system poll() was still being used. So, the primary purpose of this patch is to ensure that we're using the internal poll() when we want it to be used. The changes are: 1) Remove logic for when internal poll should be used from the Makefile. Instead, put it in the configure script. The logic in the configure script is the same as it was in the Makefile. Ideally, we would have a functionality test for the problem, but that's not actually possible, since we would have to be able to run an application on the _target_ system to test poll() behavior. 2) Always include poll.o in the build, but it will be empty if AST_POLL_COMPAT is not defined. 3) Change uses of poll() throughout the source tree to ast_poll(). I feel that it is good practice to give the API call a new name when we are changing its behavior and not using the system version directly in all cases. So, normally, ast_poll() is just redefined to poll(). On systems where AST_POLL_COMPAT is defined, ast_poll() is redefined to ast_internal_poll(). 4) Change poll() in main/poll.c to be ast_internal_poll(). It's worth noting that any code that still uses poll() directly will work fine (if they worked fine before). So, for example, out of tree modules that are using poll() will not stop working or anything. However, for modules to work properly on Mac OSX, ast_poll() needs to be used. (closes issue #13404) Reported by: agalbraith Tested by: russell, vadim http://reviewboard.digium.com/r/198/ ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@182945 f38db490-d61c-443f-a65b-d21fe96a405b
2009-03-17Merged revisions 182553 via svnmerge from russell1-3/+2
https://origsvn.digium.com/svn/asterisk/trunk ........ r182553 | russell | 2009-03-17 10:22:12 -0500 (Tue, 17 Mar 2009) | 5 lines Tweak the handling of the frame list inside of ast_answer(). This does not change any behavior, but moves the frames from the local frame list back to the channel read queue using an O(n) algorithm instead of O(n^2). ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@182569 f38db490-d61c-443f-a65b-d21fe96a405b
2009-03-17Merged revisions 182530 via svnmerge from kpfleming1-1/+2
https://origsvn.digium.com/svn/asterisk/trunk ........ r182530 | kpfleming | 2009-03-17 09:59:33 -0500 (Tue, 17 Mar 2009) | 2 lines correct logic flaw in ast_answer() changes in r182525 ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@182532 f38db490-d61c-443f-a65b-d21fe96a405b
2009-03-17Merged revisions 182525 via svnmerge from kpfleming1-33/+96
https://origsvn.digium.com/svn/asterisk/trunk ........ r182525 | kpfleming | 2009-03-17 09:38:11 -0500 (Tue, 17 Mar 2009) | 11 lines Improve behavior of ast_answer() to not lose incoming frames ast_answer(), when supplied a delay before returning to the caller, use ast_safe_sleep() to implement the delay. Unfortunately during this time any incoming frames are discarded, which is problematic for T.38 re-INVITES and other sorts of channel operations. When a delay is not passed to ast_answer(), it still delays for up to 500 milliseconds, waiting for media to arrive. Again, though, it discards any control frames, or non-voice media frames. This patch rectifies this situation, by storing all incoming frames during the delay period on a list, and then requeuing them onto the channel before returning to the caller. http://reviewboard.digium.com/r/196/ ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@182526 f38db490-d61c-443f-a65b-d21fe96a405b
2009-03-16Merged revisions 182171 via svnmerge from file1-0/+5
https://origsvn.digium.com/svn/asterisk/trunk ........ r182171 | file | 2009-03-16 10:58:24 -0300 (Mon, 16 Mar 2009) | 7 lines Fix a memory leak in the ast_answer / __ast_answer API call. For a channel that is not yet answered this API call will wait until a voice frame is received on the channel before returning. It does this by waiting for frames on the channel and reading them in. The frames read in were not freed when they should have been. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@182172 f38db490-d61c-443f-a65b-d21fe96a405b
2009-03-11Merged revisions 181428 via svnmerge from russell1-8/+17
https://origsvn.digium.com/svn/asterisk/trunk ........ r181428 | russell | 2009-03-11 17:14:55 -0500 (Wed, 11 Mar 2009) | 2 lines Make handling of the BRIDGEPVTCALLID variable thread-safe. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@181429 f38db490-d61c-443f-a65b-d21fe96a405b
2009-03-11Merged revisions 181424 via svnmerge from russell1-14/+31
https://origsvn.digium.com/svn/asterisk/trunk ................ r181424 | russell | 2009-03-11 16:49:29 -0500 (Wed, 11 Mar 2009) | 17 lines Merged revisions 181423 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r181423 | russell | 2009-03-11 16:42:58 -0500 (Wed, 11 Mar 2009) | 9 lines Make code that updates BRIDGEPEER variable thread-safe. It is not safe to read the name field of an ast_channel without the channel locked. This patch fixes some places in channel.c where this was being done, and lead to crashes related to masquerades. (closes issue #14623) Reported by: guillecabeza ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@181425 f38db490-d61c-443f-a65b-d21fe96a405b
2009-03-03Merged revisions 180032 via svnmerge from dvossel1-8/+13
https://origsvn.digium.com/svn/asterisk/trunk ........ r180032 | dvossel | 2009-03-03 17:21:18 -0600 (Tue, 03 Mar 2009) | 14 lines app_read does not break from prompt loop with user terminated empty string In app.c, ast_app_getdata is called to stream the prompts and receive DTMF input. If ast_app_getdata() receives an empty string caused by the user inputing the end of string character, in this case '#', it should break from the prompt loop and return to app_read, but instead it cycles through all the prompts. I've added a return value for this special case in ast_readstring() which uses an enum I've delcared in apps.h. This enum is now used as a return value for ast_app_getdata(). (closes issue #14279) Reported by: Marquis Patches: fix_app_read.patch uploaded by Marquis (license 32) read-ampersanmd.patch2 uploaded by dvossel (license 671) Tested by: Marquis, dvossel Review: http://reviewboard.digium.com/r/177/ ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@180078 f38db490-d61c-443f-a65b-d21fe96a405b
2009-03-03Merged revisions 179742 via svnmerge from russell1-1/+4
https://origsvn.digium.com/svn/asterisk/trunk ................ r179742 | russell | 2009-03-03 10:47:28 -0600 (Tue, 03 Mar 2009) | 14 lines Merged revisions 179741 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r179741 | russell | 2009-03-03 10:45:46 -0600 (Tue, 03 Mar 2009) | 6 lines Ensure chan->fdno always gets reset to -1 after handling a channel fd event. Since setting fdno to -1 had to be moved, a couple of other code paths that do process an fd event return early and do not pass through the code path where it was moved to. So, set it to -1 in a few other places, too. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@179743 f38db490-d61c-443f-a65b-d21fe96a405b
2009-03-03Merged revisions 179672 via svnmerge from file1-6/+6
https://origsvn.digium.com/svn/asterisk/trunk ................ r179672 | file | 2009-03-03 10:40:04 -0400 (Tue, 03 Mar 2009) | 10 lines Merged revisions 179671 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r179671 | file | 2009-03-03 10:38:09 -0400 (Tue, 03 Mar 2009) | 3 lines Move where fdno is set to the default value to *after* the read callback of the channel driver is called. We have to do this as the underlying channel driver may need the fdno value to determine what to read. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@179673 f38db490-d61c-443f-a65b-d21fe96a405b
2009-03-03Merged revisions 179609 via svnmerge from russell1-0/+12
https://origsvn.digium.com/svn/asterisk/trunk ................ r179609 | russell | 2009-03-03 07:54:41 -0600 (Tue, 03 Mar 2009) | 17 lines Merged revisions 179608 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r179608 | russell | 2009-03-03 07:53:52 -0600 (Tue, 03 Mar 2009) | 9 lines Make it easier to detect an improper call to ast_read(). When you call ast_waitfor() on a channel, the index into the channel fds array that holds the file descriptor that poll() determines has input available is stored in fdno. This patch clears out this value after a call to ast_read() and also reports errors if ast_read() is called without an fdno set. From a discussion on the asterisk-dev list. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@179610 f38db490-d61c-443f-a65b-d21fe96a405b
2009-03-03Merged revisions 179537 via svnmerge from jpeeler1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r179537 | jpeeler | 2009-03-02 18:01:51 -0600 (Mon, 02 Mar 2009) | 21 lines Merged revisions 179536 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r179536 | jpeeler | 2009-03-02 17:54:39 -0600 (Mon, 02 Mar 2009) | 15 lines Fix bridging regression from commit 176701 This fixes a bad regression where the bridge would exit after an attended transfer was made. The problem was due to nexteventts getting set after the masquerade which caused the bridge to return AST_BRIDGE_COMPLETE. (closes issue #14315) Reported by: tim_ringenbach ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@179538 f38db490-d61c-443f-a65b-d21fe96a405b
2009-03-02Merged revisions 179462 via svnmerge from russell1-1/+3
https://origsvn.digium.com/svn/asterisk/trunk ................ r179462 | russell | 2009-03-02 17:00:30 -0600 (Mon, 02 Mar 2009) | 16 lines Merged revisions 179461 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r179461 | russell | 2009-03-02 16:58:18 -0600 (Mon, 02 Mar 2009) | 8 lines Ensure that only one thread is calling ast_settimeout() on a channel at a time. For example, with an IAX2 channel, you can have both the channel thread and the chan_iax2 processing threads calling this function, and doing so twice at the same time is a bad thing. (Found in a debugging session with dvossel and mmichelson) ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@179463 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-17Merged revisions 176708 via svnmerge from jpeeler1-14/+22
https://origsvn.digium.com/svn/asterisk/trunk ................ r176708 | jpeeler | 2009-02-17 16:08:00 -0600 (Tue, 17 Feb 2009) | 23 lines Merged revisions 176701 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r176701 | jpeeler | 2009-02-17 15:54:34 -0600 (Tue, 17 Feb 2009) | 17 lines Modify bridging to properly evaluate DTMF after first warning is played The main problem is currently if the Dial flag L is used with a warning sound, DTMF is not evaluated after the first warning sound. To fix this, a flag has been added in ast_generic_bridge for playing the warning which ensures that if a scheduled warning is missed, multiple warrnings are not played back (due to a feature evaluation or waiting for digits). ast_channel_bridge was modified to store the nexteventts in the ast_bridge_config structure as that information was lost every time ast_channel_bridge was reentered, causing a hangup due to incorrect time calculations. (closes issue #14315) Reported by: tim_ringenbach Reviewed on reviewboard: http://reviewboard.digium.com/r/163/ ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@176710 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-11Merged revisions 174945 via svnmerge from mmichelson1-3/+11
https://origsvn.digium.com/svn/asterisk/trunk ........ r174945 | mmichelson | 2009-02-11 16:41:01 -0600 (Wed, 11 Feb 2009) | 29 lines 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: http://svn.digium.com/svn/asterisk/branches/1.6.0@174946 f38db490-d61c-443f-a65b-d21fe96a405b
2009-01-23Merged revisions 170652 via svnmerge from file1-0/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r170652 | file | 2009-01-23 16:18:05 -0400 (Fri, 23 Jan 2009) | 11 lines Merged revisions 170648 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r170648 | file | 2009-01-23 16:16:39 -0400 (Fri, 23 Jan 2009) | 4 lines When a channel is answered make sure any indications currently playing stop. Usually the phone would do this but if the channel was already answered then they are being generated by Asterisk and we darn well need to stop them. (closes issue #14249) Reported by: RadicAlish ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@170659 f38db490-d61c-443f-a65b-d21fe96a405b
2009-01-23Merged revisions 170393 via svnmerge from mmichelson1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r170393 | mmichelson | 2009-01-23 09:44:27 -0600 (Fri, 23 Jan 2009) | 36 lines Merged revisions 170392 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r170392 | mmichelson | 2009-01-23 09:40:39 -0600 (Fri, 23 Jan 2009) | 28 lines Fix broken call pickup There was a subtle change in ast_do_masquerade which resulted in failed attempts to pickup calls. The problem was that the value of the AST_FLAG_OUTGOING flag was copied from the clone to the original channel. In the case of call pickup, this meant that the AST_FLAG_OUTGOING flag ended up being cleared on the channel that was attempting to execute the pickup. Because this flag was not set, when ast_read came across an answer frame, it ignored it. The result of this was that the calling channel was never properly answered. This fix changes the behavior in ast_do_masquerade to set the flags on the original channel to the union of the flags on the clone channel. This way, if the AST_FLAG_OUTGOING flag is set on either of the two channels involved in the masquerade, the resulting channel will have the flag set as well. (closes issue #14206) Reported by: francesco_r Patches: 14206.patch uploaded by putnopvut (license 60) Tested by: francesco_r, aragon, putnopvut ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@170394 f38db490-d61c-443f-a65b-d21fe96a405b
2009-01-13Merged revisions 168562 via svnmerge from russell1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r168562 | russell | 2009-01-13 13:22:13 -0600 (Tue, 13 Jan 2009) | 10 lines Merged revisions 168561 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r168561 | russell | 2009-01-13 13:13:05 -0600 (Tue, 13 Jan 2009) | 2 lines Revert unnecessary indications API change from rev 122314 ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@168564 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-23Merged revisions 166569 via svnmerge from mmichelson1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r166569 | mmichelson | 2008-12-23 09:17:54 -0600 (Tue, 23 Dec 2008) | 20 lines Merged revisions 166568 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r166568 | mmichelson | 2008-12-23 09:16:26 -0600 (Tue, 23 Dec 2008) | 12 lines Fix a crash resulting from a datastore with inheritance but no duplicate callback The fix for this is to simply set the newly created datastore's data pointer to NULL if it is inherited but has no duplicate callback. (closes issue #14113) Reported by: francesco_r Patches: 14113.patch uploaded by putnopvut (license 60) Tested by: francesco_r ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@166570 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-23Merged revisions 166533 via svnmerge from tilghman1-1/+4
https://origsvn.digium.com/svn/asterisk/trunk ................ r166533 | tilghman | 2008-12-22 22:32:15 -0600 (Mon, 22 Dec 2008) | 11 lines Merged revisions 166509 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r166509 | tilghman | 2008-12-22 22:05:25 -0600 (Mon, 22 Dec 2008) | 4 lines Use the integer form of condition for integer comparisons. (closes issue #14127) Reported by: andrew ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@166534 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-19Merged revisions 166092,166095 via svnmerge from mmichelson1-2/+2
https://origsvn.digium.com/svn/asterisk/trunk ........ r166092 | mmichelson | 2008-12-19 16:26:16 -0600 (Fri, 19 Dec 2008) | 28 lines Adding a new dialplan function AUDIOHOOK_INHERIT This function is being added as a method to allow for an audiohook to move to a new channel during a channel masquerade. The most obvious use for such a facility is for MixMonitor when a transfer is performed. Prior to the addition of this functionality, if a channel running MixMonitor was transferred by another party, then the recording would stop once the transfer had completed. By using AUDIOHOOK_INHERIT, you can make MixMonitor continue recording the call even after the transfer has completed. It has also been determined that since this is seen by most as a bug fix and is not an invasive change, this functionality will also be backported to 1.4 and merged into the 1.6.0 branches, even though they are feature-frozen. (closes issue #13538) Reported by: mbit Patches: 13538.patch uploaded by putnopvut (license 60) Tested by: putnopvut Review: http://reviewboard.digium.com/r/102/ ........ r166095 | mmichelson | 2008-12-19 16:40:57 -0600 (Fri, 19 Dec 2008) | 5 lines Remove the verbatim tag from the author line I could have sworn I already did that before, though... ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@166097 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-15Merged revisions 164203 via svnmerge from russell1-50/+120
https://origsvn.digium.com/svn/asterisk/trunk ................ r164203 | russell | 2008-12-15 08:40:24 -0600 (Mon, 15 Dec 2008) | 39 lines Merged revisions 164201 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r164201 | russell | 2008-12-15 08:31:37 -0600 (Mon, 15 Dec 2008) | 31 lines Handle a case where a call can be bridged to a channel that is still ringing. The issue that was reported was about a case where a RINGING channel got redirected to an extension to pick up a call from parking. Once the parked call got taken out of parking, it heard silence until the other side answered. Ideally, the caller that was parked would get a ringing indication. This patch fixes this case so that the caller receives ringback once it comes out of parking until the other side answers. The fixes are: - Make sure we remember that a channel was an outgoing channel when doing a masquerade. This prevents an erroneous ast_answer() call on the channel, which causes a bogus 200 OK to be sent in the case of SIP. - Add some additional comments to explain related parts of code. - Update the handling of the ast_channel visible_indication field. Storing values that are not stateful is pointless. Control frames that are events or commands should be ignored. - When a bridge first starts, check to see if the peer channel needs to be given ringing indication because the calling side is still ringing. - Rework ast_indicate_data() a bit for the sake of readability. (closes issue #13747) Reported by: davidw Tested by: russell Review: http://reviewboard.digium.com/r/90/ ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@164279 f38db490-d61c-443f-a65b-d21fe96a405b
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-21 10:34:33 +0000