[asterisk-users] chan_dahdi.c, dtmfmute, rtp.c

[David]

Hello,

I am searching for a DTMF issue on my setup ( 2 years and counting ), 
and I am wondering why rtp.c has code to mute DTMF ( the rtp->dtmfmute 
variable ), but this same mechanism does not exist in dahdi.

I am sending a DTMF over SIP w/ RTP & RFC2833 to the asterisk box with 
the dahdi card. The dahdi card sends it out on the PRI line. Trouble is, 
the DTMF is echoed back and the echo canceller doesn't catch it. So 
asterisk thinks there is a an inbound DTMF happening :

[2011-06-02 21:05:41.847] DEBUG[1333] rtp.c: - RTP 2833 Event: 00000004 
(len = 4)
[2011-06-02 21:05:41.847] DEBUG[1333] rtp.c: Sending dtmf: 52 (4), at 
192.168.1.5
[2011-06-02 21:05:41.847] DTMF[1333] channel.c: DTMF begin '4' received 
on SIP/siptest-0000000c
[2011-06-02 21:05:41.847] DTMF[1333] channel.c: DTMF begin passthrough 
'4' on SIP/siptest-0000000c
[2011-06-02 21:05:41.847] DEBUG[1333] chan_dahdi.c: Started VLDTMF digit '4'
[2011-06-02 21:05:41.847] DEBUG[1333] rtp.c: - RTP 2833 Event: 00000004 
(len = 4)
[2011-06-02 21:05:41.960] DEBUG[1333] chan_dahdi.c: Exception on 66, 
channel 50
[2011-06-02 21:05:41.960] DEBUG[1333] chan_dahdi.c: Got event Event 
131124(131124) on channel 50 (index 0)
[2011-06-02 21:05:41.960] DEBUG[1333] chan_dahdi.c: DTMF Down '4'
[2011-06-02 21:05:41.960] DTMF[1333] channel.c: DTMF begin '4' received 
on DAHDI/50-1
[2011-06-02 21:05:41.960] DTMF[1333] channel.c: DTMF begin passthrough 
'4' on DAHDI/50-1

I looked through rtp.c and see code that handles this in the case of rtp 
to rtp, it says "Ignore potential DTMF echo...".

I also looked at chan_dahdi.c the only way to ignore DTMF is with 
disable_dtmf_detect() which seems to be used when Native bridging, so 
it's not what I am looking for.

I found the chan->dtmf_tv variable in channel.c which specifies a gap 
between DTMF, but it requires 45 milliseconds, in theis case the echo is 
113 milliseconds later, and on a different channel, so that doesn't drop 
the duplicate DTMF.

How can I tell asterisk that the DTMF coming back is an echo and not a 
new DTMF ? The problem I am having is that later on, the echoed DTMF is 
causing real DTMF's from the user to be "Ignored potential DTMF 
echo...". It's got it backwards. It's deteching the echo as a real DTMF 
and the real dtmf as echo.

I tried both mg2 and oslec echo canceller, I saw no difference between 
the two.

What is the next step in debugging this issue ?

David