[Home]

Summary:ASTERISK-18339: Regression: Loss of DTMF signals through asterisk
Reporter:Andy Ortlieb (andyortlieb)Labels:
Date Opened:2011-08-24 08:26:35Date Closed:2011-09-14 10:34:42
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Core/Channels
Versions:1.6.2.18 1.6.2.20 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Debian 5, i386, asterisk 1.6.2.18Attachments:
Description:We are running Asterisk 1.6.2.18.  This issue persists in 1.6.2.20 as well.  The issue does not affect 1.6.2.16 and earlier.

We took it upon ourselves to revert a change made in January of 2011 (Asterisk's SVN revision 301503) that changes the way DTMF frames are being deferred and queued.  Apparently the original change was meant to prevent a spike in CPU usage after an agent logs into a queue.  That is of course a pretty serious problem, but far less serious than unreliable DTMF transmissions.  

Without this change to main/channel.c, DTMF signals that are sent to asterisk too quickly are far less likely to be relayed to the other end of the call.  This affects calling out to other IVRs, it affects calling in to a local IVR, you can even hear the difference between two SIP endpoints.   When dialing slowly, there's a much better chance of all DTMF signals being passed through.

It may be a better plan for the Asterisk developers to review what's happening when agents log on, rather than fixing that issue in channel.c which has more repercussions.

main/channel.c
{noformat}
1374a1375
>       case AST_FRAME_DTMF_END:
1381d1381
<       case AST_FRAME_DTMF_END:
{noformat}


Just for reference, this change was applied to the following function:

{noformat}
int ast_is_deferrable_frame(const struct ast_frame *frame)
{
   /* Do not add a default entry in this switch statement.  Each new
    * frame type should be addressed directly as to whether it should
    * be queued up or not.
    */
   switch (frame->frametype) {
   case AST_FRAME_DTMF_END:
   case AST_FRAME_CONTROL:
   case AST_FRAME_TEXT:
   case AST_FRAME_IMAGE:
   case AST_FRAME_HTML:
       return 1;

   case AST_FRAME_DTMF_BEGIN:
   case AST_FRAME_VOICE:
   case AST_FRAME_VIDEO:
   case AST_FRAME_NULL:
   case AST_FRAME_IAX:
   case AST_FRAME_CNG:
   case AST_FRAME_MODEM:
       return 0;
   }
   return 0;
}
{noformat}
Comments:By: Leif Madsen (lmadsen) 2011-08-30 14:01:00.306-0500

Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions.  After testing with Asterisk 1.8, if you find this problem has not been resolved, please open a new issue against Asterisk 1.8.


By: Leif Madsen (lmadsen) 2011-09-14 10:34:37.490-0500

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.  Further information can be found at http://www.asterisk.org/developers/bug-guidelines