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
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r51204 | russell | 2007-01-17 16:09:52 -0600 (Wed, 17 Jan 2007) | 4 lines
Instead of dividing the offset by 2 directly, make it more clear that the
offset is being scaled by the size of the elements in the buffer.
(Inspired by a discussing on the asterisk-dev list about this code)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51206 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r51087 | file | 2007-01-16 00:55:23 -0500 (Tue, 16 Jan 2007) | 10 lines
Merged revisions 51085 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r51085 | file | 2007-01-16 00:53:31 -0500 (Tue, 16 Jan 2007) | 2 lines
Add none as a valid callgroup/pickupgroup option. I consider it a bug that it would inherit it all the way down and not have any way to reset it to nothing - so that's why it is in 1.2. (issue #8296 reported by gkloepfer)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51090 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r49102 | kpfleming | 2007-01-01 17:34:35 -0600 (Mon, 01 Jan 2007) | 2 lines
check specifically for VLDTMF and transcoding support in the system's Zaptel installation, and make only the modules that need those features dependent on them (this will allow building the other Zaptel-using parts of Asterisk against older versions of Zaptel or those on other platforms that haven't caught up yet to the Linux version)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@49103 65c4cc65-6c06-0410-ace0-fbb531ad65f3
just failing to compile.
It seems like the proper way to do this would be in the configure script.
However, that wouldn't help existing checkouts unless we forced the configure
script to be executed after any code was changed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@48416 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r47391 | russell | 2006-11-09 16:26:27 -0500 (Thu, 09 Nov 2006) | 7 lines
Work around an issue that caused menuselect to display a bogus description for
app_voicemail and chan_zap. These modules use some preprocessor directives to
determine what it will report to Asterisk as its description. However, the way
we extract this information from the source files for menuselect is not smart
enough to figure this out.
(issue #8326, #8328)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@47392 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r46358 | russell | 2006-10-27 10:32:40 -0500 (Fri, 27 Oct 2006) | 5 lines
Instead of iterating all of the options once to look for jitterbuffer options,
and then again for everything else, move the processing of jitterbuffer
options into the main loop so that there are no erroneous messages about
ignoring unknown options. (issue #8226)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@46359 65c4cc65-6c06-0410-ace0-fbb531ad65f3