|Summary:||ASTERISK-08591: RFC2833 DTMF "Zero" missing inner RTP packets|
|Date Opened:||2007-01-16 17:27:57.000-0600||Date Closed:||2007-01-16 18:26:41.000-0600|
|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.