ASTERISK-14543: [patch] app_background fails to reliably detect DTMF when echocan module is enabled

[Home]

Summary: ASTERISK-14543: [patch] app_background fails to reliably detect DTMF when echocan module is enabled

Reporter: Alec Davis (alecdavis) Labels:

Date Opened: 2009-12-19 21:31:41.000-0600 Date Closed: 2011-06-07 14:00:38

Priority: Major Regression? No

Status: Closed/Complete Components: Core/PBX

Versions: Frequency of
Occurrence

Related
Issues:

Environment: Attachments: ( 0) bug16473_channel_echocan_switch.diff.txt

Description: DTMF is sucessfully detected 100% of the time by disabling the echocan module by inserting the following line in /etc/modprobe.d/dahdi
options wct4xxp vpmsupport=0

Seems like app_background and other like applications need to disbale EC while it's waiting for DTMF digits.

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

Asterisk SVN-branch-1.6.1-r235424
libpri version: SVN-branch-1.4-r1374
DAHDI Version: SVN-branch-2.2-r7684 Echo Canceller: MG2

Comments: By: Alec Davis (alecdavis) 2009-12-20 10:41:42.000-0600

These are inbound calls from the ISDN into a TE220B - E1 mode, where an asterisk IVR is asking press 1 for Directory, 2 for Sales, 3 for Support etc.
By: Alec Davis (alecdavis) 2009-12-20 18:39:36.000-0600

uploaded bug16473_channel_echocan_switch.diff.txt

adds to 'echocan' parameter to function CHANNEL()

Workaround for our current echocan module issue, we need the echocan for speech
calls, but echocan messes with DTMF detection.

dialplan:<pre>
[ivr2-bdt-day]
exten => s,1,Verbose(0,'${CALLERID(num)}' IVR MAIN-DAY)
exten => s,n,Set(CHANNEL(echocan)=0)
exten => s,n,Background(silence/1)
exten => s,n,Background(bdt/mainbdt-day)
exten => s,n,Background(silence/5)
exten => s,n,Verbose(0,'${CALLERID(num)}' Nothing Pressed, Default to OPERATOR)
exten => s,n,Set(CHANNEL(echocan)=1)
exten => s,n,Dial(${TRUNK}/5066)</pre>
...

By: Leif Madsen (lmadsen) 2009-12-21 09:08:51.000-0600

Huh, neat solution :)
By: Leif Madsen (lmadsen) 2009-12-21 10:50:55.000-0600

Setting this to acknowledge, as this patch is not really the way to resolve this issue, as it does not fix the underlying issue, which, if this is happening, is a bug in the echocanceller code.
By: Leif Madsen (lmadsen) 2009-12-21 10:51:11.000-0600

Per IRC: <kpfleming> if the echocan interferes with DTMF detection then that's a bug in the echocan
By: Alec Davis (alecdavis) 2009-12-21 11:18:40.000-0600

Dec 22 06:16:28 astrid kernel: [24869551.561215] VPM450: echo cancellation for 64 channels
Dec 22 06:16:34 astrid kernel: [24869557.413249] VPM450: hardware DTMF disabled.
Dec 22 06:16:34 astrid kernel: [24869557.413253] VPM450: Present and operational servicing 2 span(s)
Dec 22 06:16:34 astrid kernel: [24869557.413257] Completed startup!
Dec 22 06:16:34 astrid kernel: [24869557.416551] About to enter startup!
Dec 22 06:16:34 astrid kernel: [24869557.416551] TE2XXP: Span 2 configured for CCS/HDB3/CRC4
Dec 22 06:16:34 astrid kernel: [24869557.417509] SPAN 2: Primary Sync Source
Dec 22 06:16:34 astrid kernel: [24869557.417510] Completed startup!
By: Alec Davis (alecdavis) 2009-12-21 13:21:05.000-0600

2 additonal tests conducted.

Test 1: same site as initially reported, swap out TE220P and VPM450 for spare units. Same issues DTMF detection issues.

Test 2: different site with same issues, with TE220P and VPM450, applied workaround patch to allow echocan switching on and off, fixes it there too.

By: Leif Madsen (lmadsen) 2009-12-21 14:12:44.000-0600

Closing as reporter is working with vendor to correct (not an open source issue).
By: Alec Davis (alecdavis) 2010-01-28 17:51:44.000-0600

added relaxdtmf in chan_dahdi.conf as suggested by vendor