Summary:	ASTERISK-08758: rtp.c not properly setting outbound DTMF payload type
Reporter:	Curt Moore (jcmoore)	Labels:
Date Opened:	2007-02-08 16:03:05.000-0600	Date Closed:	2007-04-08 19:20:24
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/RTP
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) messages_output.txt ( 1) rtp_rfc2833_dtmf_fix_patch.txt ( 2) sip_peers.txt
Description:	If 2 SIP friends are configured to use RFC2833 as their DTMF mode and the media is being proxied through Asterisk, DTMF is not always sent outbound as RFC2833, the codec will change in mid stream from G729 to ULAW.  This was observed when one of the friends send early media and both are set to use g729. ****** ADDITIONAL INFORMATION ****** I'm not an expert on rtp.c but from what I can tell, in this instance, we do not send a digit begin frame for the DTMF message by calling ast_rtp_senddigit_begin().  Apparently this is legitimate as the sip_tech_info struct purposely does not include a send_digit_begin callback. Since rtp->send_payload is set in the end of ast_rtp_senddigit_begin(), and we do not call ast_rtp_senddigit_begin(), it is not set when we call ast_rtp_senddigit_end().  Since rtp->send_payload is not set, or set to 0, when we write the RTP stream, we use the format which corresponds with 0, ULAW instead of 101, DTMF event.  This causes the stream to change from the native format of G729 to ULAW when trying to send the DTMF events. Attached is a patch which seems to have corrected this in my environment.
Comments:	By: Joshua C. Colp (jcolp) 2007-02-08 18:35:39.000-0600 Can you provide console output? I'm more concerned that begin is not getting called when it should be. By: Joshua C. Colp (jcolp) 2007-04-08 19:20:24 Due to more RFC2833 changes this should be fixed.