[Home]

Summary:ASTERISK-10216: send_dtmf is call on chan_read() so theres no way to ignore dtmf in meetme
Reporter:Clod Patry (junky)Labels:
Date Opened:2007-09-01 11:19:08Date Closed:2011-06-07 14:08:23
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:with current trunk, when used with meetme with no F options
if you press a digit, that digits to spread across all the conf, which is really bad, since discussion are always interupted by a user pressing a dtmf.

The problem is that rtp.c::ast_rtp_read() is calling process_rfc2833() and that function is calling send_dtmf() directly.

I think when you specify no F in meetme, no dtmf at all should go thru the conf at all, so the conf stays clear for all others users and at this point, I dont see how we could handle it.

****** ADDITIONAL INFORMATION ******

even if you do:
--- apps/app_meetme.c   (revision 81330)
+++ apps/app_meetme.c   (working copy)
@@ -2195,6 +2195,12 @@
                                       default:
                                               break;
                                       }
+                               } else if ( f->frametype == AST_FRAME_DTMF_BEGIN ) {
+                                        ast_debug(2, "frame begin, ignoring it\n");
+                                } else if ( f->frametype == AST_FRAME_DTMF_END ) {
+                                        ast_debug(2, "frame end, ignoring it\n");
+                               } else if ( f-> frametype == AST_FRAME_DTMF ) {
+                                       ast_debug(2, "frame dtmf, ignoring it\n");
                               } else if (f->frametype == AST_FRAME_NULL) {
                                       /* Ignore NULL frames. It is perfectly normal to get these if the person is muted. */
                               } else {

in meetme, that will still beep for the end user.



current output:
[Sep  1 11:37:55] DEBUG[17508]: app_meetme.c:2203 conf_run: Got unrecognized frame on channel SIP/64.15.69.138-08333c38, f->frametype=12,f->subclass=53
[Sep  1 11:37:55] DEBUG[17508]: rtp.c:951 process_rfc2833: - RTP 2833 Event: 00000005 (len = 4)
[Sep  1 11:37:55] DEBUG[17508]: rtp.c:951 process_rfc2833: - RTP 2833 Event: 00000005 (len = 4)
[Sep  1 11:37:55] DEBUG[17508]: rtp.c:951 process_rfc2833: - RTP 2833 Event: 00000005 (len = 4)
[Sep  1 11:37:55] DEBUG[17508]: rtp.c:799 send_dtmf: Sending dtmf: 53 (5), at 64.15.69.138
[Sep  1 11:37:55] DEBUG[17508]: app_meetme.c:2203 conf_run: Got unrecognized frame on channel SIP/64.15.69.138-08333c38, f->frametype=1,f->subclass=53
[Sep  1 11:37:55] DEBUG[17508]: rtp.c:951 process_rfc2833: - RTP 2833 Event: 00000005 (len = 4)
[Sep  1 11:37:55] DEBUG[17508]: rtp.c:951 process_rfc2833: - RTP 2833 Event: 00000005 (len = 4)
[Sep  1 11:37:55] DEBUG[17508]: rtp.c:951 process_rfc2833: - RTP 2833 Event: 00000005 (len = 4)
[Sep  1 11:37:55] DEBUG[17508]: rtp.c:799 send_dtmf: Sending dtmf: 53 (5), at 64.15.69.138
[Sep  1 11:37:55] DEBUG[17508]: app_meetme.c:2203 conf_run: Got unrecognized frame on channel SIP/64.15.69.138-08333c38, f->frametype=12,f->subclass=53
[Sep  1 11:37:55] DEBUG[17508]: rtp.c:951 process_rfc2833: - RTP 2833 Event: 00000005 (len = 4)
[Sep  1 11:37:55] DEBUG[17508]: rtp.c:951 process_rfc2833: - RTP 2833 Event: 00000005 (len = 4)
[Sep  1 11:37:55] DEBUG[17508]: rtp.c:951 process_rfc2833: - RTP 2833 Event: 00000005 (len = 4)
[Sep  1 11:37:55] DEBUG[17508]: rtp.c:799 send_dtmf: Sending dtmf: 53 (5), at 64.15.69.138
[Sep  1 11:37:55] DEBUG[17508]: app_meetme.c:2203 conf_run: Got unrecognized frame on channel SIP/64.15.69.138-08333c38, f->frametype=1,f->subclass=53
[Sep  1 11:37:55] DEBUG[17508]: rtp.c:951 process_rfc2833: - RTP 2833 Event: 00000005 (len = 4)
[Sep  1 11:37:55] DEBUG[17508]: rtp.c:951 process_rfc2833: - RTP 2833 Event: 00000005 (len = 4)
Comments:By: Joshua C. Colp (jcolp) 2007-09-04 08:12:24

I just tested app_meetme with two of my phones here and pressing DTMF on each does not produce *any* DTMF tones (or partial tones). If it was being done as inband though it is certainly possible that part of one may get to the conference as audio, or if inband is not configured it is possible that they entire digit gets through.

As for send_dtmf it is an internal rtp.c function that produces an Asterisk frame to be passed into the Asterisk core for handling. What the core and current application do with the frame is up to them.
By: Joshua C. Colp (jcolp) 2007-09-11 09:51:10

After looking over this again I'm quite confident that no issue exists, and that DTMF is probably going as audio too. The DTMF is clearly shown dropped (the unrecognized frame messages).