[asterisk-bugs] [Asterisk 0010624]: send_dtmf is call on chan_read() so theres no way to ignore dtmf in meetme

[noreply at bugs.digium.com]

The following issue has been RESOLVED. 
====================================================================== 
http://bugs.digium.com/view.php?id=10624 
====================================================================== 
Reported By:                junky
Assigned To:                file
====================================================================== 
Project:                    Asterisk
Issue ID:                   10624
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     resolved
Asterisk Version:           1.4.11  
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 81330 
Disclaimer on File?:        N/A 
Request Review:              
Resolution:                 no change required
Fixed in Version:           
====================================================================== 
Date Submitted:             09-01-2007 11:19 CDT
Last Modified:              09-11-2007 09:51 CDT
====================================================================== 
Summary:                    send_dtmf is call on chan_read() so theres no way to
ignore dtmf in meetme
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.
====================================================================== 

---------------------------------------------------------------------- 
 file - 09-11-07 09:51  
---------------------------------------------------------------------- 
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). 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
09-11-07 09:51  file           Status                   feedback => resolved
09-11-07 09:51  file           Resolution               open => no change
required
09-11-07 09:51  file           Assigned To               => file            
09-11-07 09:51  file           Note Added: 0070318                          
======================================================================