[Home]

Summary:ASTERISK-16760: DTMF tones fail DAHDI>DAHDI
Reporter:Sean Darcy (seandarcy)Labels:
Date Opened:2010-10-01 12:54:37Date Closed:
Priority:MajorRegression?No
Status:Open/NewComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) dtmf.outbound
( 1) inbound.raw
( 2) outbound.raw
Description:I have internal DAHDI lines and an external DAHDI PSTN for local calls and use SIP for ld calls. If I call locally (DAHDI > DAHDI) the dtmf tones are messed up. They seem to be doubled, that is a "1" becomes "11".

But on ld calls (DAHDI > SIP) dtmf works! And I tried calling a local number that didn't work over PSTN.




****** ADDITIONAL INFORMATION ******

Checked DTMF with this (from http://www.klaverstyn.com.au/wiki/index.php?title=DTMF_Echo_Test):

exten => 13,1,Wait(1)
exten => 13,n(again),Playback(beep)
exten => 13,n,Read(digito,,1)
exten => 13,n,SayDigits(${digito})
exten => 13,n,GoTo(again)
exten => 13,n,HangUp

And it works here. It's only using DAHDI for the outbound leg.

Do you know of any PSTN number I can use for an outside echo test?

Here's chan_dahdi.conf:


[trunkgroups]

[channels]
usecallerid=yes
callwaiting=no
usecallingpres=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=no
echotraining=yes
callgroup=0
pickupgroup=0

callprogress=yes
progzone=us
tonezone =0 ; 0 is US
jbenable = yes              ; Enables the use of a jitterbuffer

[home-phones]
context=internal      ; Uses the [internal] context in extensions.conf
group=0
dahdichan => 1,2

[pstn]
context=incoming-pstn-line  ; Incoming calls go to [incoming-pstn-line]
faxdetect=incoming
busydetect=yes
group=1
dahdichan => 4          ; PSTN attached to port 4
Comments:By: Shaun Ruffell (sruffell) 2010-10-01 15:25:24

seandarcy: Can you post the recordings from dahdi_monitor on your FXO port (or whatever DAHDI channel is actually going out to the PSTN)?
By: Sean Darcy (seandarcy) 2010-10-02 13:24:20

attaching dtmf.outbound, the output from:
dahdi_monitor 4 -f dtmf.outbound

The recording starts after I've dialed the call, while it is ringing. After the answer, I dialed, slowly, 4 1's, 4 2's and 4 3's. The called party is an automated attendant: 1 is for one extension, 2 for another, etc. It does not recognize any of the dtmf tones.
By: Shaun Ruffell (sruffell) 2010-10-02 17:06:23

I looked at the audio, and see what you mean.  I see that each DTMF appears to be about ~170ms in total length, and there are two ~35ms gaps in each digit.  What is also strange is that the first gap is completely silent.  I.e.  either it's not coming from an FXS port or something like DTMF mute is kicking in.

If it's not too much trouble, could you also take another two recordings (can just be a few DTMF digits), one being 'dahdi_monitor <fxs port> -r inbound.raw' at the same time 'dahdi_monitor 4 -t outbound.raw'?
By: Sean Darcy (seandarcy) 2010-10-03 11:03:45

Attaching the results of:
dahdi_monitor 1 -r  inbound.raw
dahdi_monitor 4 -t outbound.raw
By: Sean Darcy (seandarcy) 2010-10-03 11:06:30

inbound/outbound.raw files are recorded after the automated attendant answers. I dialed  1 2 3 1 2 3.
By: Shaun Ruffell (sruffell) 2010-10-03 13:25:08

Audio inbound looks correct.  When I line up the beginning of the first DTMF digit in the outbound recording with the inbound, I see it matches up perfectly (exact bit copy) and then in the middle of the digit are two 40ms periods of silence.    I'm wondering if what you're seeing is related to ASTERISK-15848 (not necessarily the adaptive part, but the jitter buffer in general).

Could you try disabling the jitter buffer and see if that changes the behavior?  If that has no impact, could you modify your dialplan such that the two dahdi channels can be bridged in the kernel (if they aren't already, which I don't think they are).  These wouldn't be a *fix* but would just help ascertain where the problem lies.


By: Sean Darcy (seandarcy) 2010-10-03 15:49:31

set jbenable = no. RestartedNo change.

I think the dahdi channels are bridged on the TDM400 card. Isn't that what native bridging means?:

   -- DAHDI/4-1 answered DAHDI/1-1
   -- Native bridging DAHDI/1-1 and DAHDI/4-1
   -- Native bridging DAHDI/1-1 and DAHDI/4-1
   -- Native bridging DAHDI/1-1 and DAHDI/4-1
   -- Native bridging DAHDI/1-1 and DAHDI/4-1
   -- Native bridging DAHDI/1-1 and DAHDI/4-1
   -- Hanging up on 'DAHDI/4-1'
   -- Hungup 'DAHDI/4-1'

How should I modify the dialplan to disable native bridging and bridge in the kernel?

BTW, I do know that bridging in the kernel works, at least to SIP, because DTMF over SIP works (calling the same number we're using here).
By: Sean Darcy (seandarcy) 2010-10-06 19:56:41

I'm not sure this is related to:

https://issues.asterisk.org/view.php?id=17066

1. no log messages when verbose = 3

2. dahdi => sip works

3. jbenable = no , same problem.

In fact, isn't this a dahdi-linux problem, not asterisk itself.  FWIW, I'm using dahdi-linux-2.4.0. (and same problem 1.6.14-rc1 and 1.8.0-rc2). If there's native bridging, does asterisk ever see the dtmf tones. Aren't these all handled in dahdi once the bridging is set up?
By: David Brillert (aragon) 2010-10-07 08:16:28

I don't understand the relationship to ASTERISK-15848 either.
I am also able to reproduce this problem and jitter buffer is disabled.
Technology is PRI.
Incoming channel forwarded to outgoing channel (bridged PRI B channels).
Call terminates on banking IVR and all DTMF is double digited making IVR usage impossible on forwarded call.
libpri 1.4.11
zaptel 1.4.12
Asterisk 1.4.35

Typical DTMF CLI output when caller dials 0 on IVR

[Apr 28 09:47:16] DTMF[8091]: channel.c:2387 __ast_read: DTMF begin '0'received on Zap/8-1
[Apr 28 09:47:16] DTMF[8091]: channel.c:2397 __ast_read: DTMF begin passthrough '0' on Zap/8-1
[Apr 28 09:47:16] DTMF[8091]: channel.c:2318 __ast_read: DTMF end '0' received on Zap/8-1, duration 80 ms
[Apr 28 09:47:16] DTMF[8091]: channel.c:2355 __ast_read: DTMF end accepted with begin '0' on Zap/8-1
[Apr 28 09:47:16] DTMF[8091]: channel.c:2371 __ast_read: DTMF end passthrough '0' on Zap/8-1
[Apr 28 09:47:16] DTMF[8093]: channel.c:2387 __ast_read: DTMF begin '0'received on Local/94165551234@tenant-outgoing-b99d,2
[Apr 28 09:47:16] DTMF[8093]: channel.c:2397 __ast_read: DTMF begin passthrough '0' on Local/94165551234@tenant-outgoing-b99d,2
[Apr 28 09:47:16] DTMF[8093]: channel.c:2318 __ast_read: DTMF end '0' received on Local/94165551234@tenant-outgoing-b99d,2, duration 100 ms
[Apr 28 09:47:16] DTMF[8093]: channel.c:2355 __ast_read: DTMF end accepted with begin '0' on Local/94165551234@tenant-outgoing-b99d,2
[Apr 28 09:47:16] DTMF[8093]: channel.c:2371 __ast_read: DTMF end passthrough '0

I have been watching progress of https://reviewboard.asterisk.org/r/625/ wondering if this might help solve this problem.  But this review may be 100% unrelated.


By: Russell Bryant (russell) 2010-10-12 14:35:39

For those experiencing the issues, do you have DTMF controlled features in Asterisk?  I'm wondering if Asterisk is detecting and muting inbound DTMF and then regenerating it.  When Asterisk does that, you usually get some of the first digit that bleeds through before Asterisk is able to start muting it.
By: David Brillert (aragon) 2010-10-12 15:01:57

I have lots of DTMF feature codes enabled in Asterisk.
However it looks to me like the 0 is being emulated twice.  Once by the incoming zap channel and once by the external zap channel and the caller has only pressed the 0 after the IVR answers the outgoing channel.