[asterisk-bugs] [Asterisk 0012658]: [patch] DTMF issues on Zap

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12658 
====================================================================== 
Reported By:                dimas
Assigned To:                russell
====================================================================== 
Project:                    Asterisk
Issue ID:                   12658
Category:                   Core/PBX
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 116466 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             05-15-2008 08:58 CDT
Last Modified:              06-18-2008 22:27 CDT
====================================================================== 
Summary:                    [patch] DTMF issues on Zap
Description: 
ohh. The long one.
replaces 11635 and 12592

I often have unreliable DTMF recognition on Zap channels. Research shown
that DSP works fine, and digits are read from the Zap driver correctly
almost 100% of time and corruption occurs later in the VLDTMF emulation
code.

So the problems I encountered:
1. There is a situation when DTMF emulation swaps digits. Scenario (user
presses 12 with short durations and short pause):

  A. ast_read is called by some application
  B. ast_read calls channel's read and gets DTMF_END(1)
  C. DTMF emulation is started and ast_read sets AST_FLAG_EMULATE_DTMF
flag and returns AST_FRAME_DTMF_BEGIN(1)
  D. application calls autoservice_start and AST_FLAG_END_DTMF_ONLY is set
on the channel
  E. autoservice thread calls ast_read
  F. eventually channel's technology diver returns DTMF_END(2).
  G. since AST_FLAG_END_DTMF_ONLY is set, ast_read passes DTMF_END(2) thru
ast_read returns DTMF_END(2). However it is still in the emulation mode!
  H. Eventually, emulation finishes and ast_read returns DTMF_END(1)

bottom line: 1 and 2 got swapped

Solution (one of, which I choosed) is to always queue DTMFs when we are
already in emulation mode. This fix immediately led to next issue:



2. when user quickly rolls over digits (1234) there can be a situation
when autoservice thread already read 12 and 34 are already queued into
channel's dtmfq but not yet read. Then when autoservice_stop "returns"
digits into channels readq, and they get processed by the VLDTMF emulation
code AGAIN - they will be queued to dtmfq. 

Result - 3412 will be read from the channel instead of 1234.

Solution: mark frames "returned" by autoservice and do NOT process them
again.

Major drawback: DTMFs which "passed thru" autoservice won't be re-emulated
so only DTMF_ENDs remain and no proper interval between them. In my case
when I mess with autoservice it is always an application terminates the
call so no worries - to my knowledge applications only need DTMF_END and
never BEGINs



3. The next problem is that the code at the beginning of ast_read which is
responsible for "injecting" deferred DTMF can inject content of dtmfq even
if there is non-empty readq (possible filled by just finished autoservice
which means they ae higher prioity).

Resul - again, swapped digits.

Solution: add additional check - do not inject digits from the dtmfq while
there is somethign in the channel's readq.


4. Finally AST_FLAG_EMULATE_DTMF is not always set when digit is added to
dtmfq. To make sure we ALWAYS queue when somethign is queued already, I
added "|| !ast_strlen_zero(chan->dtmfq)" to the conditions used to queue
DTMFs.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0011635 [patch] multiple issues with autoservice
====================================================================== 

---------------------------------------------------------------------- 
 bhfisher - 06-18-08 22:27  
---------------------------------------------------------------------- 
I think my problem might be related to this issue.  I my case the calls
come from a SIP provide and are bridged to an external IVR system using a
port on a TE410P.  I can listen to the sounds between asterisk and the IVR
system.  When a call arrives, the inband ANI and DTMF sound normal and are
recognized by the IVR system.  However, if the caller is to enter sound
DTMF info such as a phone number, the tones sound terrible, barely
recognizable as dtmf. Also, on calls that are bridge ZAP to ZAP work
properly.  I've applied the patch above and included some logs for calls
that worked and fails - The ones to DNIS 5682 failed.
I am using Asterisk 1.4.21
Let me know if you need anything else - The system is off-line at the
moment
Thanks, Bart 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-18-08 22:27  bhfisher       Note Added: 0088896                          
======================================================================