diff options
| author | Russell Bryant <russell@russellbryant.com> | 2007-01-19 18:06:03 +0000 |
|---|---|---|
| committer | Russell Bryant <russell@russellbryant.com> | 2007-01-19 18:06:03 +0000 |
| commit | dcca8f345fa55b146fe6b0930df18b226809cc70 (patch) | |
| tree | 6fb863ed2b3e4abdc44db77e4e5cce3bed75c618 /.cleancount | |
| parent | 9d509eaf76a950825a1cd473d8c752cfa6b0c5a7 (diff) | |
Merged revisions 51311 via svnmerge from
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
Diffstat (limited to '.cleancount')
0 files changed, 0 insertions, 0 deletions