Summary:	ASTERISK-10932: MeetMe conferences don't forward DTMF from SIP clients
Reporter:	Michael FIG (michael-fig)	Labels:
Date Opened:	2007-11-29 16:32:57.000-0600	Date Closed:	2011-06-07 14:02:40
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_meetme
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asterisk-1.4.14-meetme.diff ( 1) asterisk-meetme-dtmf-sip.txt
Description:	I'm using a MeetMe conference to connect an outbound call (over either SIP or a Zap channel) with a SIP internal agent.  I've turned on DTMF forwarding for both users, but when I hit DTMF on any SIP client, it isn't forwarded to the other end (the background noise is interrupted for dead air for the duration of the keypress). The reason I marked this as "major" is that my internal agents cannot navigate voice menus on the outbound call, which is a big problem for us, since many of the businesses we call have voice menus. ****** ADDITIONAL INFORMATION ****** I tested this with both X-Lite and a Grandstream GXP-2000 as the SIP client, and a Sangoma T1 card as the Zap channel. The MeetMe commands I used were: outbound: MeetMe(700|1dFqx) agent: MeetMe(700|1AdpFq) The attached SIP trace (asterisk-meetme-dtmf-sip.txt) shows a session in which the outbound call is to SIP/528, and then I try hitting "5555..." on the keypad. Thanks!
Comments:	By: Olle Johansson (oej) 2007-12-16 03:45:53.000-0600 Is this still a problem? /Housekeeping By: Michael FIG (michael-fig) 2007-12-17 11:40:45.000-0600 Yes, this was still a problem, but I found out what was causing it and worked around it.  The problem is that our SIP phones were only sending AST_FRAME_DTMF_END, not AST_FRAME_DTMF_BEGIN for their DTMF events. The attached patch has a workaround (but it's probably not ideal) that made app_meetme forge an AST_FRAME_DTMF_BEGIN frame if the end frame was sent without a corresponding begin.  It works for me just fine. By: Dmitry Andrianov (dimas) 2008-02-20 17:56:11.000-0600 It looks like a second half of your patch does not change anything really - just moves code back and forth and changes formatting a bit. Anyway this is one more reason of doing VDTMF emulation/normalization in ast_write instead of ast_read. This is the question I emailed -dev  list (attn: Russell) yesterday. Asterisk core should handle this situation not particular application. I could try creating a patch to move emulation from ast_read to ast_write if there is no objections on the approach. By: Tilghman Lesher (tilghman) 2008-02-25 17:35:19.000-0600 michael-fig:  have you tried turning on rfc2833compensate=yes in sip.conf, for your SIP users/peers?  That should emulate the sending of DTMF begin events properly. By: Michael FIG (michael-fig) 2008-03-05 16:56:00.000-0600 Corydon76: Does rfc2833compensate=yes ever do anything bad?  The one advantage of my current hack is that it doesn't screw anything up even if the SIP client sends both begin and end events, and it adds the begin events if they don't exist. I couldn't find a definitive answer from some Googling and reading of asterisk-1.4.17/configs/sip.conf If it is only this setting that fixes the problem, my apologies for reporting a bug when there is none. By: Jason Parker (jparker) 2008-04-01 16:52:52 You did not answer the question Corydon76 asked... Seeing as there hasn't been any further response here, I will assume that the setting fixed the issue. Please reopen if that is not the case.