[asterisk-bugs] [Asterisk 0014491]: [patch] DTMF blips at end of recordings in __ast_play_and_record()

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=14491 
====================================================================== 
Reported By:                asbestoshead
Assigned To:                jpeeler
====================================================================== 
Project:                    Asterisk
Issue ID:                   14491
Category:                   Applications/General
Reproducibility:            always
Severity:                   tweak
Priority:                   normal
Status:                     assigned
Target Version:             1.6.0.12
Asterisk Version:           Older 1.6.0 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-02-17 10:39 CST
Last Modified:              2009-07-24 15:00 CDT
====================================================================== 
Summary:                    [patch] DTMF blips at end of recordings in
__ast_play_and_record()
Description: 
When using a channel with real in-band DTMF (e.g. Dahdi), voicemail
greetings and other recordings have remnants of the DTMF tone left at the
end. Usually it's about 5-15ms of DTMF before the Dahdi DTMF detector
kicked in, and sometimes there's an additional 5ms at the end of the tone.

The attached patch stops recording on button DOWN, not button UP; it also
trims the last 400ms from the recording in the case where it was terminated
by DTMF. I'm not 100% happy with this, but it seems to completely get rid
of noisy blips at the end of recordings a little over 50% (*) of the time,
and I haven't heard complaints about it truncating too much. I'm sort of
looking for feedback more than anything.

The patch is against 1.6.0-beta9, but it applies cleanly to 1.6.0.5.

(*) 24 out of 43 users who changed their greetings since I applied the
patch. Some of them might have retried if they heard the blip, but most
probably wouldn't notice. I didn't notice, until it was pointed out to me
-- and since then it's all I can hear :)
====================================================================== 

---------------------------------------------------------------------- 
 (0108207) asbestoshead (reporter) - 2009-07-24 15:00
 https://issues.asterisk.org/view.php?id=14491#c108207 
---------------------------------------------------------------------- 
Hi, thanks for the feedback.

lmadsen: I can't say for sure as I'm stuck on an earlier beta until
CONNECTED_LINE support makes it into a release. Looking at the code, I
think it would still be an issue. I see that __ast_play_and_record() has
some changes for the case where the recording is NOT ended with DTMF, to
fix *duration. The patch here might need to be updated to do the same, but
either way, the new code probably has the same problem.

dimas: Yes, it looks like the comment in the patch is wrong, I'm trimming
400 ms. I think there can be a long bounce period when the user mashes '#'
before the software DTMF detector kicks in (on another Asterisk instance,
with a Dahdi channel). There is also some click noise from the buttons on
some phones before the DTMF is generated. I admit I wasn't very scientific
about it, but 400 ms gave decent results.

Your suggestion to record the time DTMF_BEGIN was received, then wait for
DTMF_END, is probably the right way to do it, although I would still cut
400 ms.

jpeeler: I probably won't have a chance to update the patch anytime soon,
but if you would like me to test anything for you, I can. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-07-24 15:00 asbestoshead   Note Added: 0108207                          
======================================================================