[asterisk-bugs] [Asterisk 0011489]: During call setup signalling asterisk does not offer telephone-event (rfc2833) anymore

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11489 
====================================================================== 
Reported By:                macbrody
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11489
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   block
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.15  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!): 91736 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             12-07-2007 07:36 CST
Last Modified:              12-10-2007 09:58 CST
====================================================================== 
Summary:                    During call setup signalling asterisk does not offer
telephone-event (rfc2833) anymore
Description: 
What happened:
As of asterisk-1.4.15 (tested trunk too) asterisk, when
connected to a peer via sip trunk does not recognize dtmf
anymore (same config worked with 1.4.13).

What I found:
During signalling negotiation at call setup in the sdp body,
asterisk does not offer the rtpmap: telephone-event anymore,
even if I configure dtmfmode=rfc2833.

Therefore the other end will not send any rfc2833 specific rtp events.

====================================================================== 

---------------------------------------------------------------------- 
 file - 12-10-07 09:58  
---------------------------------------------------------------------- 
Yes, the old stuff was broken. RFC2833 was never in the INVITE to begin
with, it was something else with the same payload but the code mistakenly
thought it was RFC2833 and happily negotiated it. While the old stuff
actually worked in your scenario, it was the fact it was broken that made
it work. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
12-10-07 09:58  file           Note Added: 0075133                          
======================================================================