https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r51781 | russell | 2007-01-23 16:04:01 -0600 (Tue, 23 Jan 2007) | 6 lines
Fix some bugs in process_message(). The manager session lock needs to be held
when sending some sort of response, or calling one of the manager action
callbacks. This resolves an issue where people using the GUI would get random
crashes when they start clicking around a lot.
(issue #8711, reported and debugged by zandbelt)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51787 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r51755 | russell | 2007-01-23 15:52:52 -0600 (Tue, 23 Jan 2007) | 2 lines
Fix setting the default port of 8088 on 64-bit or big-endian machines.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51760 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r51750 | russell | 2007-01-23 15:33:15 -0600 (Tue, 23 Jan 2007) | 4 lines
When traversing the list of manager actions, the iterator needs to be
initialized to the list head *after* locking the list. Also, lock the actions
list in one place it is being accessed where it was not being done.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51751 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r51683 | murf | 2007-01-23 11:58:27 -0700 (Tue, 23 Jan 2007) | 1 line
via 8748 (callerid.c loses name when returning PRIVATE_NUMBER flag), the user suggested this mod, saying it would allow 'WITHHELD' to appear in the name field, which would be useful
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51684 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r51350 | qwell | 2007-01-20 00:53:49 -0600 (Sat, 20 Jan 2007) | 5 lines
Fix Italian numeral support in say.conf for "_[2-9]00" case.
"2131" would've translated to something along the lines of (pardon my..Italian {or lack thereof})
"duecentocentotrentuno", which makes no sense at all.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51351 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r51348 | qwell | 2007-01-20 00:16:06 -0600 (Sat, 20 Jan 2007) | 8 lines
Fix German language support in say.conf
Properly support 21, 31, 41, 51, 61, 71, 81, and 91.
einundzwanzig has the same format as zweiundzwanzig (as do all other "_ZX" spoken numerals)
Fix support for numbers in the 10,000,000 to 99,999,999 range.
Add support for numbers in the 100,000,000 to 999,999,999 range.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51349 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r51328 | russell | 2007-01-19 13:08:25 -0600 (Fri, 19 Jan 2007) | 5 lines
Fix VLDTMF support in chan_gtalk. AST_FRAME_DTMF and AST_FRAME_DTMF_END are
actually the same thing. So, a digit would have been interpreted incorrectly
here. Since the channel driver will always have the begin and end callbacks
called for a digit, only support the button-down and button-up messages.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51329 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r51311 | russell | 2007-01-19 11:49:38 -0600 (Fri, 19 Jan 2007) | 23 lines
Merge the changes from the /team/group/vldtmf_fixup branch.
The main bug being addressed here is a problem introduced when two SIP
channels using SIP INFO dtmf have their media directly bridged. So, when a
DTMF END frame comes into Asterisk from an incoming INFO message, Asterisk
would try to emulate a digit of some length by first sending a DTMF BEGIN
frame and sending a DTMF END later timed off of incoming audio. However,
since there was no audio coming in, the DTMF_END was never generated. This
caused DTMF based features to no longer work.
To fix this, the core now knows when a channel doesn't care about DTMF BEGIN
frames (such as a SIP channel sending INFO dtmf). If this is the case, then
Asterisk will not emulate a digit of some length, and will instead just pass
through the single DTMF END event.
Channel drivers also now get passed the length of the digit to their digit_end
callback. This improves SIP INFO support even further by enabling us to put
the real digit duration in the INFO message instead of a hard coded 250ms.
Also, for an incoming INFO message, the duration is read from the frame and
passed into the core instead of just getting ignored.
(issue #8597, maybe others...)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
AST_INLINE_API() is a macro that takes a block of code as an argument.
Using preprocessor #directives in the argument is not supported by all
compilers, and it is a bit of an obfuscation anyways, so avoid it.
As a workaround, define a macro that produces either its argument
or nothing, and use that instead of #ifdef/#endif within the
argument to AST_INLINE_API().
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51312 65c4cc65-6c06-0410-ace0-fbb531ad65f3
has been found so that 'cat' is non-NULL. This way, users.conf is only checked
when necessary. (issue #8852, akohlsmith, committed patch a bit different)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51296 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the location of the header files.
On passing, add a cast to insure -Werror clean compilation
on FreeBSD 6.x, where time_t does not match %ld
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51293 65c4cc65-6c06-0410-ace0-fbb531ad65f3
place, rather than repeating the check on every single file.
Changes to the individual files are coming.
The header file name has been suggested by kevin.
Approved by: kpfleming
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51290 65c4cc65-6c06-0410-ace0-fbb531ad65f3
do not work on FreeBSD - presumably they depend on some
auto* feature that is not installed by default.
I am not sure on what is a proper fix. In my local copy
i simply comment them out.
The AST_PROG_LD is a long standing isse, there were attempts
to fix it in the past but probably not enough has been copied
to acinclude.m4, and i had forgotten about it because i
commented out this call in configure.ac long ago
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51288 65c4cc65-6c06-0410-ace0-fbb531ad65f3