oscillating and incorrect data. Additionally, the RTT would sometimes report
negative values due to incorrect calculations.
(issue #9601, patch from davetroy)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@65842 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I realize that there are other ways to get this,
but we really don't need to just show it in plain text so easily.
Issue 9273, patch by junky
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@63982 65c4cc65-6c06-0410-ace0-fbb531ad65f3
either because the Challenge action was never issued, or some other reason,
give a proper error message and return an error instead of claiming that the
user wasn't found.
(reported by jsmith on IRC)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@63886 65c4cc65-6c06-0410-ace0-fbb531ad65f3
code in that if a channel does not have a send_digit_begin() callback, it only
cares about DTMF END events. (pointed out by Michael Neuhauser on the
asterisk-dev list)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@63612 65c4cc65-6c06-0410-ace0-fbb531ad65f3
send_digit_begin() callback. Checking the END_DTMF_ONLY flag was the
wrong thing to do, because that flag indicates that a *bridged* channel
only wants DTMF END events coming from this channel.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@63608 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This set of changes came from a debugging session I had with Dwayne Hubbard.
When he called into his home FXO, ran the Echo application, and pressed a
digit, the digit would be echoed back and would never end. This is fixed,
along with a couple other little improvements.
* When chan_zap is in the middle of playing a digit to a channel, it feeds
back null frames, not voice frames. So, I have modified ast_read to check
the timing on emulated DTMF when it receives null frames, in addition to
where it was doing this on voice frames.
* Make a tweak to setting the duration on emulated DTMF digits. If there was
no duration specified, it set it to be the minimum, instead of the default.
* Instead of timing the emulated digits off of the number of samples in audio
frames that pass through, just use time values. Now there is no code in this
section that assumes 8kHz audio.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@62942 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fix some issues related to generating inband DTMF. There are two changes here:
1) The list of DTMF tones in the senddigit_begin() function explicitly
specified 100ms of the tone followed by 100ms of silence. This really
broke things with the way that Asterisk now wants complete control
over when the digit begins and ends. So, regardless of what Asterisk
really wanted to do, this was going to play out the tone at the length it
wanted to. This caused various problems like DTMF translation to inband to
be extremely unreliable.
The list of tones has been changed so that the correct DTMF tone is played
indefinitely until Asterisk tells it to stop.
2) ast_write() had to be modified to let a DTMF_END frame get processed even
when a generator is present. This is how the tone will finally get stopped.
(issues #8944, #9250, #9348, maybe others. Thanks to mdu113 from #8944 for
the testing and feedback!)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@62789 65c4cc65-6c06-0410-ace0-fbb531ad65f3
don't even bother creating a temporary bogus channel, since that is only for
allowing certain functions to operate on the variables as if they were on a
channel. Most importantly, this fixes a crash.
(issue #9613, reported by callguy, fixed by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@62171 65c4cc65-6c06-0410-ace0-fbb531ad65f3
the asterisk-dev mailing list. I changed the enforced minimum length of a
digit from 100ms to 80ms. Furthermore, I made it now enforce a gap of 45ms in
between digits. These values are not configurable in a configuration file
right now, but they can be easily changed near the top of main/channel.c.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@61781 65c4cc65-6c06-0410-ace0-fbb531ad65f3
will get notified of these changes even when an owner channel is not provided.
This isn't from a specific bug report, it's just something I noticed while
poking around.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@61774 65c4cc65-6c06-0410-ace0-fbb531ad65f3
channel. So, this little hack lets them work in places where a channel doesn't
exist, such as within DUNDi configuration.
(issue #9465, reported and patched by Corydon76, testing by blitzrage)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@61765 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Per comment from Dave Troy:
This adds back in some simple typecasting I had in an earlier version
which I realize now may be breaking things.
Issue #9554.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@61707 65c4cc65-6c06-0410-ace0-fbb531ad65f3
However, after much discussion, it has been decided that adding this to 1.4 is
not in the best interests of the project. It has been removed here, but will
remain in trunk.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@61220 65c4cc65-6c06-0410-ace0-fbb531ad65f3
