[asterisk-bugs] [Asterisk 0013053]: Called Party's inband DTMF removed almost entirely with overlapdial and non-native bridging
Asterisk Bug Tracker
noreply at bugs.digium.com
Thu Dec 11 16:24:58 CST 2008
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=13053
======================================================================
Reported By: Seb7
Assigned To: jpeeler
======================================================================
Project: Asterisk
Issue ID: 13053
Category: Channels/chan_dahdi
Reproducibility: always
Severity: minor
Priority: normal
Status: assigned
Asterisk Version: 1.4.19
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 2008-07-10 09:50 CDT
Last Modified: 2008-12-11 16:24 CST
======================================================================
Summary: Called Party's inband DTMF removed almost entirely
with overlapdial and non-native bridging
Description:
If you are using inband DTMF (tested on two Zap channels), and two bridged
channels are not bridged natively (e.g. because you are using MixMonitor),
and the incoming call used overlap dialing, and the Called Party tries
sending DTMF, you hear a blip and perhaps a few milliseconds of tone, but
not enough for the DTMF to be recognised by an application on the Calling
Party side. (Asterisk does not recognize the DTMF either). It is being
trimmed to within a millisecond of its life. Note, that the Calling Party's
DTMF is OK.
======================================================================
----------------------------------------------------------------------
(0096284) russell (administrator) - 2008-12-11 16:24
http://bugs.digium.com/view.php?id=13053#c96284
----------------------------------------------------------------------
I'm not sure that there is going to be anything we can do in this case.
When the call is not native bridged, and DTMF is going through the core,
this is how it is going to work. The inband DTMF detector listens for DTMF
and mutes it as soon as it detects the digit. Then, it passes it through
the core as a signaling frame in case it needs to be acted on. Then, it
will get regenerated in the technology specific method on other side of the
bridge if it gets passed along.
There will always be a little bit of the digit that leaks through.
Issue History
Date Modified Username Field Change
======================================================================
2008-12-11 16:24 russell Note Added: 0096284
======================================================================
More information about the asterisk-bugs
mailing list