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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@219199 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@214704 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@214197 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@210916 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@208484 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@207363 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@204950 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@201460 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@201096 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@198887 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@198074 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@197145 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@194359 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@192354 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@191505 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@186987 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@186835 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@185774 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r184762 | kpfleming | 2009-03-27 14:10:32 -0500 (Fri, 27 Mar 2009) | 12 lines
Improve timing interface to remember which provider provided a timer
The ability to load/unload timing interfaces is nice, but it means that when a timer is allocated, it may come from provider A, but later provider B becomes the 'preferred' provider. If this happens, all timer API calls on the timer that was provided by provider A will actually be handed to provider B, which will say WTF and return an error.
This patch changes the timer API to include a pointer to the provider of the timer handle so that future operations on the timer will be forwarded to the proper provider.
(closes issue #14697)
Reported by: moy
Review: http://reviewboard.digium.com/r/211/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@184765 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@183067 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@182946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@182570 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@182527 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@182173 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@181426 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@180080 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@179744 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@179674 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@179611 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@179539 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@179464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r176708 | jpeeler | 2009-02-17 16:08:00 -0600 (Tue, 17 Feb 2009) | 23 lines
Merged revisions 176701 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r176701 | jpeeler | 2009-02-17 15:54:34 -0600 (Tue, 17 Feb 2009) | 17 lines
Modify bridging to properly evaluate DTMF after first warning is played
The main problem is currently if the Dial flag L is used with a warning sound,
DTMF is not evaluated after the first warning sound. To fix this, a flag has
been added in ast_generic_bridge for playing the warning which ensures that if
a scheduled warning is missed, multiple warrnings are not played back (due to a
feature evaluation or waiting for digits). ast_channel_bridge was modified to
store the nexteventts in the ast_bridge_config structure as that information
was lost every time ast_channel_bridge was reentered, causing a hangup due to
incorrect time calculations.
(closes issue #14315)
Reported by: tim_ringenbach
Reviewed on reviewboard:
http://reviewboard.digium.com/r/163/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@176711 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r176666 | russell | 2009-02-17 15:22:40 -0600 (Tue, 17 Feb 2009) | 16 lines
Update the timing API to have better support for multiple timing interfaces.
1) Add module use count handling so that timing modules can be unloaded.
2) Implement unload_module() functions for the timing interface modules.
3) Allow multiple timing modules to be loaded, and use the one with the
highest priority value.
4) Report which timing module is being use in the "timing test" CLI command.
(closes issue #14489)
Reported by: russell
Review: http://reviewboard.digium.com/r/162/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@176675 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@174947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r174844 | file | 2009-02-11 10:44:47 -0400 (Wed, 11 Feb 2009) | 10 lines
Tell the device state core a change happened when a channel is freed but not a specific state.
We need to do this because while we know that the freeing of the channel may cause something to become
not in use we do not know this for sure. There may be another channel that is still up which would cause
it to be in use.
(closes issue #13238)
Reported by: kowalma
Patches:
20090121__bug13238.diff.txt uploaded by Corydon76 (license 14)
Tested by: alecdavis
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@174846 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@170664 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@170395 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@166571 65c4cc65-6c06-0410-ace0-fbb531ad65f3
