[asterisk-users] DTMF tones mid conversation

Thu Feb 26 11:08:25 CST 2009

Hi list,

I wonder if anyone is able to offer any [polite ;-)] words of wisdom??

I'm having the same problem too, with random DTMF heard during ISDN calls.  Am
running Asterisk 1.4.22 and mISDN 1.1.8. (kernel 2.6.18 CentOS)

Symptoms are on incoming and out outgoing ISDN calls, particularly to mobile
(cell) phones or those of a low quality/compressed audio.  I'm using a
Digium B410P (only using 1 port; ISDN 2e in TE mode) connected to the British Telecom PSTN at the NT.

I've changed my misdn-init.conf about many times (dtmfthreshold and recently
added dtmf to card= & restart) without any noticeable difference. 

misdn-init.conf:

card=1,0x4,dtmf

te_ptp=1

nt_ptp=2,3,4

option=1,master_clock

dsp_options=0

dtmfthreshold=2500

timer=1/etc/asterisk/misdn.conf:[general]
misdn_init=/etc/misdn-init.conf
debug=4
ntdebugflags=0
ntdebugfile=/var/log/misdn-nt.log
ntkeepcalls=no
tracefile=/var/log/asterisk/misdn.log
bridging=yes

stop_tone_after_first_digit=yes
append_digits2exten=yes

dynamic_crypt=no
crypt_prefix=**
crypt_keys=test,muh

[default]
context=default
language=en
musicclass=default
senddtmf=yes
far_alerting=yes
allowed_bearers=all
nationalprefix=0
internationalprefix=00
rxgain=0
txgain=0
te_choose_channel=no
pmp_l1_check=no
reject_cause=16
need_more_infos=yes
nttimeout=no
method=standard
overlapdial=no
dialplan=0
localdialplan=2
cpndialplan=0
early_bconnect=yes
incoming_early_audio=no
nodialtone=no
presentation=0
screen=0
echocancel=yes
jitterbuffer=4000
jitterbuffer_upper_threshold=0
hdlc=no
max_incoming=-1
max_outgoing=-1

[isdn]
ports=1
context=from-pstn

DTMF threshold in misdn-init look high doesn't it...  I'm not entirely sure what it
"should" be set to, to be honest..  (min-max values for tuning); have read max
value is 100, but others suggest it'll go higher - but what exactly is it
tuning the sensitivity value of specifically? (i.e. what is the threshold
value).  DTMF detection works well for *genuine* DTMF digits dialled over
the ISDN trunk, but mISDN/Asterisk still recognises them incorrectly at times
during calls (to/from cell phones).

I've also seen other posts refer to settings in Dahdi.conf (such as relaxdtmf)
- surely Dahdi doesn't have anything to do with this if I'm using chan_misdn??

As a side note, interestingly, some withheld calls present their incoming
caller ID as '0', others 'unknown'... Not got to the bottom of that one
either.  Anyway.. back on topic..

Here's an excerpt from my asterisk 'full' log showing a random DTMF
digit.  This spurious digit was incorrectly recognised from voice: on a
mobile phone call (outgoing this time - yes could turn DTMF detection off on
the dial statement but doesn't help on incoming):

[Feb 26 13:47:38] VERBOSE[20051] logger.c:     -- Executing
[s at macro-dialout-trunk:26] Dial("SIP/101-09ff5c68",
"misdn/1/07xxxx")

[Feb 26 13:47:38] VERBOSE[20051] logger.c:     -- Called
1/07xxxx

[Feb 26 13:47:39] VERBOSE[20051] logger.c:     --
mISDN/1-u364 is proceeding passing it to SIP/101-09ff5c68

[Feb 26 13:47:43] VERBOSE[20051] logger.c:     --
mISDN/1-u365 is ringing

[Feb 26 13:47:46] VERBOSE[20051] logger.c:     --
mISDN/1-u365 answered SIP/101-09ff5c68

[Feb 26 13:49:14] DTMF[20051] channel.c: DTMF end '2' received on mISDN/1-u365,
duration 0 ms

[Feb 26 13:49:14] DTMF[20051] channel.c: DTMF begin emulation of '2' with
duration 100 queued on mISDN/1-u365

[Feb 26 13:49:14] DTMF[20051] channel.c: DTMF end emulation of '2' queued on
mISDN/1-u365

[Feb 26 13:50:54] DEBUG[20051] chan_misdn.c: misdn_hangup(mISDN/1-u365)

[Feb 26 13:50:54] VERBOSE[20051] logger.c:     -- Executing
[s at macro-hangupcall:11] Hangup("SIP/101-09ff5c68", "") in
new stack

Apologies for the trail of logs; just noticed this happening on my Asterisk
console on an incoming call from a mobile:

P[ 1]  --> * IND :      -1! (stop indication)
pid:168

P[ 1] * ANSWER:

P[ 1]  --> empty cad using dad

P[ 1] I SEND:CONNECT oad:07xxxxx dad:781890 pid:168

P[ 1]  --> channel:2 mode:TE cause:16 ocause:16 rad: cad:781890

P[ 1]  --> info_dad: onumplan:2 dnumplan:0 rnumplan:  cpnnumplan:0

P[ 1]  --> * Unknown Indication:20 pid:168

P[ 1] I IND :CONNECT_ACKNOWLEDGE  oad:07xxxx dad:78xxx pid:168
state:CONNECTED

P[ 1]  --> channel:2 mode:TE cause:16 ocause:16 rad: cad:781890

P[ 1]  --> info_dad: onumplan:2 dnumplan:0 rnumplan:  cpnnumplan:0

P[ 1] I IND :DTMF_TONE oad:07xxxx dad:78xxx pid:168 state:CONNECTED

P[ 1]  --> channel:2 mode:TE cause:16 ocause:16 rad: cad:781890

P[ 1]  --> info_dad: onumplan:2 dnumplan:0 rnumplan:  cpnnumplan:0

P[ 1]  --> DTMF:1

[Feb 26 16:41:47] DTMF[21144]: channel.c:2148 __ast_read: DTMF end '1' received
on mISDN/2-u397, duration 0 ms

[Feb 26 16:41:47] DTMF[21144]: channel.c:2184 __ast_read: DTMF begin emulation
of '1' with duration 100 queued on mISDN/2-u397

P[ 1]  --> * Unknown Indication:20 pid:168

P[ 1]  --> * Unknown Indication:20 pid:168

[Feb 26 16:41:47] DTMF[21144]: channel.c:2296 __ast_read: DTMF end emulation of
'1' queued on mISDN/2-u397

P[ 1]  --> * Unknown Indication:20 pid:168

P[ 1]  --> * Unknown Indication:20 pid:168

P[ 1] I IND :DISCONNECT oad:07xxxxx dad:78xxx pid:167 state:CONNECTED

P[ 1]  --> channel:1 mode:TE cause:16 ocause:16 rad: cad:78xxx

P[ 1]  --> info_dad: onumplan:2 dnumplan:0 rnumplan:  cpnnumplan:0

P[ 1]  --> queue_hangup

P[ 1] I SEND:RELEASE oad:07xxxxx dad:78xxx pid:167

P[ 1]  --> channel:1 mode:TE cause:16 ocause:-1 rad: cad:781890

P[ 1]  --> info_dad: onumplan:2 dnumplan:0 rnumplan:  cpnnumplan:0

...Unknown indication 20 of any relevance?

Is anyone able to confirm exactly whether mISDN's hardware DSP and driver is
responsible for detecting DTMF, or whether it's Asterisk analysing the inbound
audio?  Scanning the README.misdn (sourced separately) the chan_misdn
driver readme comments a feature as "DTMF Detection in HW+mISDNdsp (much
better than asterisks internal!)" - so surely DTMF is recognised and
passed on by mISDN to Asterisk.  The fact that the log messages prefixed
by P[ 1] are mISDN - I think I've answered my own question there...

Prior to going down the mISDN route, I looked at Dahdi as the Dahdi configs
mention native Dahdi B410P support.  But, the conclusion I came to
(although what I read didn't make it clear me) is that the readme was referring
to Dahdi B410P support in Ast 1.6, not 1.4.  That sound right?  Dahdi
readme:

"Installing the B410P drivers with mISDN

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

DAHDI includes the wcb4xxp driver for the B410P, however, support for the

B410P was historically provided by mISDN.  If you would like to use the
mISDN

driver with the B410P, please comment out the wcb4xxp line in
/etc/dahdi/modules.

This will prevent DAHDI from loading wcb4xxp which will conflict with the mISDN

driver."

Enough reading.. if you're still awake!  Any help would be very much appreciated.
Thank you,

Simon

> Date: Wed, 11 Feb 2009 14:58:58 +0000
> From: paulo.r.santos at sapo.pt
> To: asterisk-users at lists.digium.com
> Subject: Re: [asterisk-users] DTMF tones mid conversation
> 
> Andrew Thomas wrote:
> 
> > I seem to have a problem of intermittent DTMF tones being played during
> > a conversation.
> 
> I'm having the same problem, but in my case, it's every 1 minute and at 
> the start of the call.
> 
> I wonder if it has anything to do with echo cancellation.
> I've only noticed when using a Zap channel, but I'll run some more tests.
> 
> asterisk 1.4.17 / addons 1.4.7 / zaptel 1.4.12.1 / mISDN 1.1.8
> 
> Paulo Santos
> 
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users

_________________________________________________________________
Check out the new and improved services from Windows Live. Learn more! 
http://clk.atdmt.com/UKM/go/132630768/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20090226/61e9e33d/attachment.htm 