Age | Commit message (Collapse) | Author | Files | Lines |
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r183172 | dvossel | 2009-03-19 11:28:33 -0500 (Thu, 19 Mar 2009) | 20 lines
Merged revisions 183126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@183198 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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.1@183067 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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.1@182946 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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.1@182570 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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.1@182533 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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.1@182527 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r182450 | tilghman | 2009-03-17 00:51:54 -0500 (Tue, 17 Mar 2009) | 14 lines
Merged revisions 182449 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r182449 | tilghman | 2009-03-17 00:50:52 -0500 (Tue, 17 Mar 2009) | 7 lines
Fix race in astdb
The underlying db1 implementation does not fully isolate the pages retrieved
from astdb, so the lock protecting accesses needs to be extended until the
copy from the shared memory structure is done.
(closes issue #14682)
Reported by: makoto
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@182452 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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.1@182173 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r182029 | mmichelson | 2009-03-13 12:26:43 -0500 (Fri, 13 Mar 2009) | 41 lines
Merged revisions 181990 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r181990 | mmichelson | 2009-03-13 12:12:32 -0500 (Fri, 13 Mar 2009) | 35 lines
Check the DYNAMIC_FEATURES of both the chan and peer when interpreting DTMF.
Dynamic features defined in the applicationmap section of features.conf allow
one to specify whether the caller, callee, or both have the ability to use the
feature. The documentation in the features.conf.sample file could be interpreted
to mean that one only needs to set the DYNAMIC_FEATURES channel variable on the
calling channel in order to allow for the callee to be able to use the features
which he should have permission to use. However, the DYNAMIC_FEATURES variable
would only be read from the channel of the participant that pressed the DTMF
sequence to activate the feature. The result of this was that the callee was
unable to use dynamic features unless the dialplan writer had taken measures
to be sure that the DYNAMIC_FEATURES variable was set on the callee's channel.
This commit changes the behavior of ast_feature_interpret to concatenate the
values of DYNAMIC_FEATURES from both parties involved in the bridge. The features
themselves determine who has permission to use them, so there is no reason to believe
that one side of the bridge could gain the ability to perform an action that they
should not have the ability to perform.
Kevin Fleming pointed out on the asterisk-users list that the typical way that this
was worked around in the past was by setting _DYNAMIC_FEATURES on the calling channel
so that the value would be inherited by the called channel. While this works, the
documentation alone is not enough to figure out why this is necessary for the callee
to be able to use dynamic features. In this particular case, changing the code to match
the documentation is safe, easy, and will generally make things easier for people for
future installations.
This bug was originally reported on the asterisk-users list by David Ruggles.
(closes issue #14657)
Reported by: mmichelson
Patches:
14657.patch uploaded by mmichelson (license 60)
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@182068 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r181731 | tilghman | 2009-03-12 12:32:13 -0500 (Thu, 12 Mar 2009) | 9 lines
Adjust translation table column widths based upon the translation times.
Previously, only 5 columns were displayed, and if a translation time exceeded
99,999 useconds, it would be displayed as 0, instead of its actual time.
(closes issue #14532)
Reported by: pj
Patches:
20090311__bug14532.diff.txt uploaded by tilghman (license 14)
Tested by: pj
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@181733 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r181465 | russell | 2009-03-11 17:25:57 -0500 (Wed, 11 Mar 2009) | 2 lines
Make handling of the BRIDGE_PLAY_SOUND variable thread-safe.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@181474 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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.1@181430 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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.1@181426 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r181135 | jpeeler | 2009-03-10 23:06:44 -0500 (Tue, 10 Mar 2009) | 20 lines
Fix malloc debug macros to work properly with h323.
The main problem here was that cstdlib was undefining free thereby causing the
proper debug macros to not be used. ast_h323.cxx has been changed to call
ast_free instead to avoid the issue.
A few other issues were addressed:
- There were a few instances of functions improperly passing ast_free instead
of ast_free_ptr.
- Some clean up was done to avoid the debug macros intentionally being redefined.
(copied below from Kevin's commit, appreciate the help)
- disable astmm.h from doing anything when STANDALONE is defined, which is used
by the tools in the utils/ directory that use parts of Asterisk header files in
hackish ways; also ensure that utils/extconf.c and utils/conf2ael.c are
compiled with STANDALONE defined.
(closes issue #13593)
Reported by: pj
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@181199 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r180800 | file | 2009-03-10 11:40:38 -0300 (Tue, 10 Mar 2009) | 5 lines
Reset the thread local string buffer when handling the UserEvent action.
(closes issue #14593)
Reported by: JimDickenson
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@180802 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r180719 | jpeeler | 2009-03-09 15:58:17 -0500 (Mon, 09 Mar 2009) | 16 lines
Add Doxygen documentation for API changes from 1.6.0 to 1.6.1
Copied from my review board description:
This is a continuation of the API changes documentation started for describing
changes between releases. Most of the API changes were pretty simple needing
only to be brought to attention via the new "Asterisk API Changes" list.
However, if you see anything that needs further explanation feel free to
supplement what is there. The current method of documenting is to add (in the
header file): \version <ver number> <description of changes> and then to add
the function to the change list in doxyref.h on the AstAPIChanges page. I also
made sure all the functions that were newly added were tagged with \since
1.6.1. I think this is a good habit to start both for the historical aspect as
well as for the future ability to easily add a "New Asterisk API" page.
Review: http://reviewboard.digium.com/r/190/
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@180740 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r180534 | dvossel | 2009-03-06 11:26:38 -0600 (Fri, 06 Mar 2009) | 15 lines
Merged revisions 180532 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r180532 | dvossel | 2009-03-06 11:19:55 -0600 (Fri, 06 Mar 2009) | 9 lines
Fix handling of backreferences for ENUM lookups
enum.c did not handle regex backtraces correctly. The '\1' in the regex is a backreference that requires a pattern match to be inserted. The way the code used to work is that it would find the backreference and insert the entire input string minus the '+'. This is incorrect. The regexec() function takes in a variable called pmatch which is an array of structs containing the start and end indexes for each backreference substring. The original code actually passed the pmatch array pointer into regexec but never did anything with it. Now when a backtrace is found, the backtrace number is looked up in the pmatch array and the correct substring is inserted.
(closes issue #14576)
Reported by: chris-mac
Review: http://reviewboard.digium.com/r/187/
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@180537 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r180373 | kpfleming | 2009-03-05 12:29:38 -0600 (Thu, 05 Mar 2009) | 15 lines
Merged revisions 180372 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r180372 | kpfleming | 2009-03-05 12:22:16 -0600 (Thu, 05 Mar 2009) | 9 lines
Fix problems when RTP packet frame size is changed
During some code analysis, I found that calling ast_rtp_codec_setpref() on an ast_rtp session does not work as expected; it does not adjust the smoother that may on the RTP session, in fact it summarily drops it, even if it has data in it, even if the current format's framing size has not changed. This is not good.
This patch changes this behavior, so that if the packetization size for the current format changes, any existing smoother is safely updated to use the new size, and if no smoother was present, one is created. A new API call for smoothers, ast_smoother_reconfigure(), was required to implement these changes.
Review: http://reviewboard.digium.com/r/184/
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@180378 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r180195 | file | 2009-03-04 15:24:59 -0400 (Wed, 04 Mar 2009) | 11 lines
Merged revisions 180194 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r180194 | file | 2009-03-04 15:22:50 -0400 (Wed, 04 Mar 2009) | 4 lines
Look for the number in a callerid string starting from the end. This way a value using <> can exist in the name portion.
(issue #AST-194)
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@180197 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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.1@180080 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r179973 | murf | 2009-03-03 15:12:02 -0700 (Tue, 03 Mar 2009) | 33 lines
Merged revisions 179807 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
I had some work to do to port these changes to trunk; the
check_expr stuff hasn't been updated here for quite some
time, it appears. I added some more tests to the check_expr2
suite. I had to play around with the makefile a bit, etc.
I added STANDALONE2 #ifdefs to ast_expr2.y so as not to
conflict structure with aelparse.
........
r179807 | murf | 2009-03-03 11:11:34 -0700 (Tue, 03 Mar 2009) | 19 lines
These changes allow AEL to better check ${} constructs within $[...], that are concatenated with text.
I modified and added rules in ast_expr2.fl to better handle
the concatenations.
I added some default routines to ast_expr2.y so the standalone would
compile. It also looks like I haven't run this thru bison since 2.1, so
it's good to get this updated.
The Makefile has comments added now for check_expr2 and check_expr to
explain what they are for, and how to run them.
The testexpr2s stuff has been removed, in favor of check_expr2.
expr2.testinput has been updated to include the two expressions
that inspired these changes (from mcnobody on #asterisk this morning)
The regression has been run and all looks well.
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@180077 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r179841 | file | 2009-03-03 14:28:46 -0400 (Tue, 03 Mar 2009) | 16 lines
Merged revisions 179840 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r179840 | file | 2009-03-03 14:27:09 -0400 (Tue, 03 Mar 2009) | 9 lines
Do not assume that the bridge_cdr is still attached to the channel when the 'h' exten is finished executing.
It is possible for a masquerade operation to occur when the 'h' exten is operating. This operation moves
the CDR records around causing the bridge_cdr to no longer exist on the channel where it is expected to.
We can not safely modify it afterwards because of this, so don't even try.
(closes issue #14564)
Reported by: meric
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@179843 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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.1@179744 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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.1@179674 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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.1@179611 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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.1@179539 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r179469 | tilghman | 2009-03-02 17:10:18 -0600 (Mon, 02 Mar 2009) | 17 lines
Merged revisions 179468 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r179468 | tilghman | 2009-03-02 17:09:01 -0600 (Mon, 02 Mar 2009) | 10 lines
When ending a recording with silence detection, remember to reduce the duration.
The end of the recording is correspondingly trimmed, but the duration was not
trimmed by the number of seconds trimmed, so the saved duration was necessarily
longer than the actual soundfile duration.
(closes issue #14406)
Reported by: sasargen
Patches:
20090226__bug14406.diff.txt uploaded by tilghman (license 14)
Tested by: sasargen
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@179471 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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.1@179464 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r179396 | qwell | 2009-03-02 14:16:51 -0600 (Mon, 02 Mar 2009) | 9 lines
Merged revisions 179395 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r179395 | qwell | 2009-03-02 14:14:57 -0600 (Mon, 02 Mar 2009) | 1 line
Remove several silly warnings in editline. One about a broken preprocessor directive, and another about strlcpy/strlcat.
(closes issue #14264)
Reported by: dimas
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@179407 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r179291 | file | 2009-03-02 10:13:45 -0400 (Mon, 02 Mar 2009) | 7 lines
Fix issue where changing the volume of both directions of audio did not work.
(closes issue #14574)
Reported by: KNK
Patches:
audiohook_volume_fix.diff uploaded by KNK (license 545)
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@179293 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r178986 | murf | 2009-02-26 20:45:58 -0700 (Thu, 26 Feb 2009) | 26 lines
Merged revisions 178956 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
In this case, it's just a matter of reducing the default timeouts from 2000
to 1000 msec, as the max def feature digit timeout is no longer halved.
........
r178956 | murf | 2009-02-26 14:27:32 -0700 (Thu, 26 Feb 2009) | 18 lines
This change moves the default feature digit timeout to 1000 ms from the previous default of 500.
As per bug 14515, a dev discussion arrived at a "mediated concensus"
of a default feature digit timeout of 1.0 sec. Some voted for 1300;
ctooley thought 1500 for distracted phone users in phone booths;
kpfleming put his foot down at 1.0 sec.
Users who found the previous default max delay of 250 msec perfect,
are welcome to override the new default. Notice that I said that
250 msec was the default; wait a minute, you might say, the config
file said it was 500 msec!; well, because of the bug fix for 14515,
we found that 500 msec was actually enforcing a max of 250. The bug
fix would restore 500 msec, but we felt even that was a bit tight
for most users... 2000 msec was pushed earlier by mmichelson, so
that reduces to 1000 msec after the bug fix. Enjoy!
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@178988 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r178828 | murf | 2009-02-26 10:22:11 -0700 (Thu, 26 Feb 2009) | 34 lines
Merged revisions 178804 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r178804 | murf | 2009-02-26 10:09:03 -0700 (Thu, 26 Feb 2009) | 28 lines
This patch prevents the feature detection timeout from being cut in half.
Because the ast_channel_bridge() call will return 0 and pass
a frame pointer for both DTMF_BEGIN and DTMF_END, the feature_timer
field in hte config struct is getting decremented twice, which
effectively cuts the digittimeout in half. I added conditions
to the if statement to only let DTMF_END frames to flow thru,
which solved the problem. Also, when the frame pointer is null,
let control flow thru-- this usually happens on timeouts. I added
a comment to the code to explain what's going on and why.
Many thanks to sodom for reporting this problem. Personnally, it always seemed
like something was wrong with the featuredigittimeout, but I never
could quite decide what... and was too busy to investigate.
This bug forced the issue, and now we know.
Sodom had other issues in 14515, but I couldn't reproduce them. If
he still has problems, and wants to get them solved, he is welcome
to reopen 14515.
(closes issue #14515)
Reported by: sodom
Patches:
14515.patch uploaded by murf (license 17)
Tested by: murf, sodom
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@178869 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r178801 | file | 2009-02-26 12:42:36 -0400 (Thu, 26 Feb 2009) | 5 lines
Fix an issue where the timer for file playback would not be stopped if DAHDI was not installed.
(closes issue #14541)
Reported by: grant
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@178803 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r178509 | russell | 2009-02-25 06:45:30 -0600 (Wed, 25 Feb 2009) | 10 lines
Merged revisions 178508 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r178508 | russell | 2009-02-25 06:43:36 -0600 (Wed, 25 Feb 2009) | 2 lines
Update the copyright year for the main page of the doxygen documentation.
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@178511 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r178381 | tilghman | 2009-02-24 14:52:44 -0600 (Tue, 24 Feb 2009) | 2 lines
Apparently, a void cast doesn't override warn_unused_result.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@178383 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r178374 | russell | 2009-02-24 14:39:57 -0600 (Tue, 24 Feb 2009) | 14 lines
Merged revisions 178373 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r178373 | russell | 2009-02-24 14:36:19 -0600 (Tue, 24 Feb 2009) | 6 lines
Only set dtmfcount on BEGIN, and ensure it gets reset to 0 properly.
(issue #14460)
Reported by: moliveras
Tested by: russell
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@178379 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r178375 | tilghman | 2009-02-24 14:40:02 -0600 (Tue, 24 Feb 2009) | 2 lines
The 3 possible errors with pipe(2) are all impossible in this situation.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@178377 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r178342 | tilghman | 2009-02-24 14:06:48 -0600 (Tue, 24 Feb 2009) | 2 lines
Use a SIGPIPE to kill the process, instead of depending upon the astcanary process being inherited by init.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@178344 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r178142 | russell | 2009-02-23 17:11:37 -0600 (Mon, 23 Feb 2009) | 22 lines
Merged revisions 178141 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r178141 | russell | 2009-02-23 17:09:01 -0600 (Mon, 23 Feb 2009) | 14 lines
Fix infinite DTMF when a BEGIN is received without an END.
This commit is related to rev 175124 of 1.4 where a previous attempt was made
to fix this problem. The problem with the previous patch was that the inserted
code needed to go _before_ setting the lastrxts to the current timestamp.
Because those were the same, the dtmfcount variable was never decremented, and
so the END was never sent.
In passing, I removed the dtmfsamples variable which was completed unused. I
also removed a redundant setting of the lastrxts variable.
(closes issue #14460)
Reported by: moliveras
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@178172 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r177787 | tilghman | 2009-02-20 17:02:35 -0600 (Fri, 20 Feb 2009) | 16 lines
Merged revisions 177786 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r177786 | tilghman | 2009-02-20 16:59:52 -0600 (Fri, 20 Feb 2009) | 9 lines
Don't print the CR-NL combination when we aren't outputting to the manager.
An embedded CR-NL in a CLI command screws up several AMI parsers that don't
expect to see that combination in the middle of output.
(Closes issue #14305)
Reported by: martins
Patch by: tilghman
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@177789 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r177664 | tilghman | 2009-02-20 11:29:51 -0600 (Fri, 20 Feb 2009) | 8 lines
Allow semicolons to be escaped, when passing arguments to the System command.
(closes issue #14231)
Reported by: jcovert
Patches:
20090113__bug14231__2.diff.txt uploaded by Corydon76 (license 14)
corrected_20090113__bug14231__2.diff.txt uploaded by jcovert (license 551)
Tested by: jcovert
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@177761 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
................
r177595 | murf | 2009-02-19 16:56:50 -0700 (Thu, 19 Feb 2009) | 32 lines
Merged revisions 177540 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
Trunk was already pretty 8-bit clean; but I'm still
removing the --full from the flex command so everything
is uniform.
........
r177540 | murf | 2009-02-19 15:51:37 -0700 (Thu, 19 Feb 2009) | 21 lines
This patch fixes a problem with 8-bit input to the ast_expr2 scanner.
The real culprit was the --full argument to flex
in the Makefile! This causes a 7-bit scanner to be
generated.
I reviewed the rules and found one rule where I needed
to specifically include 8-bit chars for a token.
I tested against the text supplied by ibercom, and
all looks very well.
This has been there a surprisingly long time!
(closes issue #14498)
Reported by: ibercom
Patches:
14498.patch uploaded by murf (license 17)
Tested by: murf
........
................
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@177623 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r177356 | jpeeler | 2009-02-19 09:56:31 -0600 (Thu, 19 Feb 2009) | 4 lines
Fix mismerge from revision 176708 pointed out by Kaloyan Kovachev on the
asterisk-dev mailing list. Thanks!
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@177358 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r177229 | kpfleming | 2009-02-18 17:09:58 -0600 (Wed, 18 Feb 2009) | 3 lines
fix two very minor bugs: if anyone ever uses SLINEAR16 as a format in RTP, ensure that the samples are byte-swapped to network order if needed. also, when a smoother is operating on a format that has a sample rate other than 8000 samples per second, use the proper sample rate for computing delivery timestamps.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@177230 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r177226 | dvossel | 2009-02-18 16:51:38 -0600 (Wed, 18 Feb 2009) | 9 lines
Locking issue in action_bridge and bridge_exec
action_bridge() and bridge_exec() both search for the channels to bridge to, and then immediately drop the lock. Instead, they should hold the lock until the masquerade is complete. This will guarantee the channel remains and prevent any other weirdness from occurring. In action_bridge() some more weirdness comes into play. Both channels are needlessly locked at the same time and perform the exact same logic. It makes sense from a coding organizational standpoint, but could cause a theoretical deadlock so I split the code up. There is an issue associated with this, but since its a rather complicated thing to reproduce I'm not certain this alone will close it.
issue# 14296
Review: http://reviewboard.digium.com/r/167/
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@177228 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r177035 | dbailey | 2009-02-18 11:24:07 -0600 (Wed, 18 Feb 2009) | 2 lines
Fixed error where a check for an zero length, terminated string was needed.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@177037 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r176948 | dbailey | 2009-02-18 10:09:12 -0600 (Wed, 18 Feb 2009) | 2 lines
Need to take into account the \0 terminator of the old string to determine the amount available.
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@176962 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r176943 | murf | 2009-02-18 08:35:26 -0700 (Wed, 18 Feb 2009) | 45 lines
This patch fixes merge_contexts_and_delete so it does not deadlock when hints are present.
Reason: when I re-engineered the merge_and_delete func to
reduce its lock time, I failed to notice that the
functions it calls still also do locking as before.
This leads to deadlocks on dialplan reloads, when
there are actually living, subscribed hints registered
in the system.
While the reporter come across this problem while using
AEL, I might note that these deadlocks should also happen
if extensions.conf were used.
Here I added these routines to pbx.c:
ast_add_extension_nolock
add_pri_lockopt
ast_add_extension2_lockopt
find_context
add_hint_nolock
All of the above routines are static and restricted
to be used only within pbx.c, and more specifically
within the merge_contexts_and_delete routine.
They are pretty much the same as their counterparts
except they don't lock contexts or hints.
Most of them now do the real work of their
name-alike, with optional locking via extra arguments,
and are called by their name-alike. The goal was to
have the original functions so they would behave
exactly as before.
Both PJ and I tested these fixes, and the deadlocking
problem is no longer encountered.
(closes issue #14357)
Reported by: pj
Patches:
14357.diff uploaded by murf (license 17)
Tested by: pj, murf
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@176946 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/trunk
........
r176901 | russell | 2009-02-18 00:00:40 -0600 (Wed, 18 Feb 2009) | 9 lines
Fix a number of incorrect uses of strncpy().
The big problem here is that the 3rd argument provided in these uses of strncpy()
did not reserve a byte for the null terminator, leaving the potential for writing
one byte past the end of the buffer.
Aside from this, there were coding guidelines violations with regards to spacing,
as well as hard coded lengths being used instead of sizeof().
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@176903 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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.1@176711 f38db490-d61c-443f-a65b-d21fe96a405b
|