[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 10:01:33 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 10:01 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0096204) Seb7 (reporter) - 2008-12-11 10:01
 http://bugs.digium.com/view.php?id=13053#c96204 
---------------------------------------------------------------------- 
Well, my dial plan is basically visible from the log above, but as far as I
can deduce from what is now commented out in the config, this was the dial
plan I used:

[outbound]
exten => _020.,1,NoOp(Inbound call for relay to Outbound call.
CHANNEL(transfercapability) is ${CHANNEL(transfercapability)}.)
exten => _020.,n,NoOp(CALLERID is ${CALLERID}. CALLERID(name) is
${CALLERID(name)}. CALLERID(num) is ${CALLERID(num)}. CALLINGPRES is
${CALLINGPRES}.)
exten => _020.,n(record),MixMonitor(SebTest-${UNIQUEID}.WAV|b)
exten => _020.,n(justdial),Dial(Zap/g2/MyMobileNumberCensored)

zapata.conf - this is my best guess as to what the config the box from
which the log was taken had, but it certainly had overlapdial on on span 1
(inbound call); I can't remember about span 2 (outbound call):

[channels]
switchtype=national
resetinterval = never 
rxwink=300						
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
rxgain=0.0
txgain=0.0
group=1
callgroup=1
pickupgroup=1

immediate=no

 group = 1
 context=outbound
 signalling = pri_cpe
 overlapdial=yes
; overlapdial=no
 channel => 1-15,17-31
 
 group = 2
; context=default
 signalling = pri_cpe
; overlapdial=yes
 overlapdial=no
 channel => 32-39
 channel => 40-46,48-62


I think it is important that the equipment that sends the call into span 1
also uses overlapdialing (but I can't remember for sure). What phone and
equipment did you have originating the call in your test? I think, in my
log above, I used an analog phone connected to some non-asterisk gear. This
gear was connected to Asterisk via PRI, but with overlapdialing enabled on
the 'gear' (sending) side - otherwise, even though overlap dialing is
enabled on the receiving side, the call set-up is still sent enbloc (I
think). Then asterisk sent out the call again on span 2 into a British
Telecom PRI span to my GSM mobile phone, which is where I was sending the
DTMF. When I took out the MixMonitor or switched off overlapdialing I could
hear decent length tones coming through to the originating phone, but
otherwise hardly anything.

Maybe you could post, or attach, your log file from your test so we can
compare the two? 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-12-11 10:01 Seb7           Note Added: 0096204                          
======================================================================




More information about the asterisk-bugs mailing list