[Home]

Summary:ASTERISK-17364: [regression] Incoming DTMF on PRI channel is mis-interpreted causing logins to voicemail main to fail authentication
Reporter:David Brillert (aragon)Labels:
Date Opened:2011-02-07 13:17:20.000-0600Date Closed:2011-04-12 13:05:32
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Core/Channels
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) Asterisk_1.4.35_voicemail_main_PRI_working_debug.txt
( 1) voicemail_main_local_debug.txt
( 2) voicemail_main_PRI_debug.txt
Description:External user calls to PRI span is answered with voicemail main application and enters correct extension number and password combination but Asterisk rejects the authentication.


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

Installed 1.4 r306120

Three traces attached with debug, DTMF, RTP
'Asterisk 1.4.35 voicemail main PRI working debug.txt' shows a working example on older 1.4.35 Asterisk version.

'voicemail main local debug.txt' shows a working example on r306120 using SIP extension calling to voicemail main.

'voicemail main PRI debug.txt' is the CLI trace of the failure of voicemail login on inbound PRI channel.

All three examples use the same dial plan and extension number and voicemail password.  Only the incoming PRI channel fails to provide proper authentication.
Comments:By: Leif Madsen (lmadsen) 2011-02-07 13:32:38.000-0600

What version of DAHDI are you using? What revision of Asterisk does this stop working on? If you revert to a specific revision does it start working again?
By: Alec Davis (alecdavis) 2011-02-07 13:40:50.000-0600

from chan_dahdi.conf, may help

; If you are having trouble with DTMF detection, you can relax the DTMF
; detection parameters.  Relaxing them may make the DTMF detector more likely
; to have "talkoff" where DTMF is detected when it shouldn't be.
;
;relaxdtmf=yes
By: David Brillert (aragon) 2011-02-07 13:41:34.000-0600

Leif:  This is a clear regression and has nothing to do with Dahdi as far as I know.  Since the problem only occurs on PRI channels I opened the report under chan_dahdi because I have no idea what is really going on here.  I have Zaptel 1.4.12.1 installed and do not have to change the Zaptel installation to reproduce the issue; I only have to upgrade Asterisk. I will try and pin down the revision which caused this regression.


By: David Brillert (aragon) 2011-02-07 13:42:07.000-0600

thanks alecdavis but relaxdtmf is already enabled.

I'm tracking down the revision now.
By: David Brillert (aragon) 2011-02-08 08:01:30.000-0600

I have tracked down the bad revision by checking out current svn and using svn update -r command to isolate.

Revision 301502 - Directory Listing
Modified Wed Jan 12 18:10:42 2011 UTC (3 weeks, 5 days ago) by jpeeler

Fix CPU spike when pressing DTMF after agent login.

The problem here is that DTMF was being continuously deferred and requeued
since ast_safe_sleep is called in a loop. There are serveral other places in the
code that sleeps and then loops in a similar fashion. Because of this fact I
opted to not defer DTMF any more, which will not affect the original fix:

https://reviewboard.asterisk.org/r/674

(closes issue ASTERISK-16804)
Reported by: rgj
By: David Brillert (aragon) 2011-02-08 08:02:37.000-0600

This problem is 100% reproducible in my lab on r301502 or higher.
By: David Brillert (aragon) 2011-02-08 08:46:23.000-0600

The category of this ticket should probably be moved to main/channel.c
By: David Brillert (aragon) 2011-02-09 15:22:04.000-0600

I just tried SVN-branch-1.4-r306972 and I have the same problem there.
The easiest way to fix for me is:
http://svn.digium.com/svn/asterisk/branches/1.4/
do the svn checkout as usual
cd 1.4
then ... svn update -r 300924

Of course this means I cannot update to 1.4.40rc1 or higher since the regression r301502 made it into 1.4.40rc1
By: rsw686 (rsw686) 2011-02-09 22:24:01.000-0600

I have a similar unrecognized DTMF issue that stems from issue 18130, which includes r301502, on Asterisk 1.8 with Exchange UM. Reverting the patch resolves the unrecognized DTMF for me as well.
By: David Brillert (aragon) 2011-02-16 08:35:35.000-0600

In the debug attachment voicemail main PRI debug.txt you see the bad DTMF result.
The digits pressed on keypad don't match digits processed:
user digits dialed = 6010#
password digits dialed = 60106010#
[2011-02-07 13:53:26]     -- Incorrect password '61600' for user '610' (context = default)

So it is clear that not only are digits duplicated but they are processed in the wrong order and some appear to be ignored.


By: David Brillert (aragon) 2011-02-18 08:15:30.000-0600

What can I do to move this along?
Is there more testing required or more debug required?
I see that 1.4.40rc3 is released and this regression is still committed.
If this regression is not fixed prior to 1.4.40 GA I think this will be very bad.
I will certainly not be able use 1.4.40 with this regression.
I can reproduce this problem 100% of the time with 1.4 SVN, 1.4.40rc1, rc2, rc3
IMHO this is a blocker.
By: David Brillert (aragon) 2011-02-18 14:19:21.000-0600

I ran into another scenario here which is affected by DTMF poisoning.
All incoming calls via PRI to IVR fail to reach dialed extension.
AA answers with prompt>user dials local extension>call fails because DTMF is not interpretted (invalid extension).
All incoming calls to IVR via PRI fail to route properly!
By: David Brillert (aragon) 2011-03-10 15:51:34.000-0600

I have had to downgrade all Asterisk deployments because of this issue.
Now I am forced to use 1.4.39-1
Any chance of some feedback from a developer?
By: David Brillert (aragon) 2011-03-22 10:10:39

I have now tested 1.4 SVN r311203
It appears that this issue is fixed in r311203
If I had to guess which revision fixed the problem it would be:

Revision 310888 - Directory Listing
Modified Wed Mar 16 16:58:42 2011 UTC (5 days, 22 hours ago) by twilson

Don't delay DTMF in core bridge while listening for DTMF features

My bug report can now be closed.
By: rsw686 (rsw686) 2011-03-22 23:54:56

That solved it for me as well, specifically revision 310902 for 1.8.
By: Richard Mudgett (rmudgett) 2011-04-12 13:05:31

Closing as reporter has reported that another fix also took care of this issue.