Summary:ASTERISK-08591: RFC2833 DTMF "Zero" missing inner RTP packets
Reporter:edgreenberg (edgreenberg)Labels:
Date Opened:2007-01-16 17:27:57.000-0600Date Closed:2007-01-16 18:26:41.000-0600
Versions:Frequency of
Environment:Attachments:( 0) rtp-dtmf-fix0.patch
Description:When rtp.c sends an rfc2833 digit, it now sends the start, a series of continuations, and a triple set of ends. (Thanks, Olle!)

rtp.c uses the digit being sent as an indicator of whether we are (still) sending.  This fails when the digit is a zero, since the zero is interpreted as false.

The attached patch to rtp.c implements a new boolean and separates the digit from the sending flag.

Once this is patched in, zeros look the same as all other digits.
Comments:By: Jason Parker (jparker) 2007-01-16 17:52:26.000-0600

Doesn't it use '0' and not 0?  ie; a string representation, and not the numeric value of 0.  Digits 'A', 'B', 'C', 'D' wouldn't be possible otherwise.

By: edgreenberg (edgreenberg) 2007-01-16 18:06:57.000-0600

One would have thought, but read this code snippet from rtp.c:ast_rtp_senddigit_begin():

       if ((digit <= '9') && (digit >= '0'))
               digit -= '0';

So by the time we get to
       rtp->send_digit = digit;
it's a real live zero.

By: Jason Parker (jparker) 2007-01-16 18:26:40.000-0600

Fixed in svn branch 1.4 and trunk in revisions 51170 and 51171.