| Summary: | ASTERISK-08591: RFC2833 DTMF "Zero" missing inner RTP packets | ||
| Reporter: | edgreenberg (edgreenberg) | Labels: | |
| Date Opened: | 2007-01-16 17:27:57.000-0600 | Date Closed: | 2007-01-16 18:26:41.000-0600 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Core/RTP |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| 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. | ||