Summary:	ASTERISK-11670: [patch] Support for RFC2833 DTMF for dumb SIP proxies
Reporter:	Andriy I Pylypenko (bamby)	Labels:
Date Opened:	2008-03-18 03:25:30	Date Closed:	2008-12-08 13:48:40.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/NewFeature
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) force_dtmf.diff
Description:	My recent upgrade from asterisk 1.2 to 1.4 brought in a problem. Let me describe my setup. Calls from Asterisk are coming through the dumb SIP proxy that doesn't announce the support for the RFC2833 telephone-event but relays all the RTP packets regardless of RTP payload type so remote IVRs can receive the DTMFs. The Asterisk 1.4 handles this situation more correctly than 1.2, it drops the telephone-events if peer didn't announce support for them in SDP. But the problem is that this dumb SIP proxy cannot be neither avoided nor fixed. I've added a couple of configuration options that helps to recover the previous behavior and also allows an administrator to choose the payload type value for the telephone-event payload. I believe I'm not alone with this problem so IMO this feature would be helpful for some people.
Comments:	By: snuffy (snuffy) 2008-07-26 20:50:26 any updates on this? By: Leif Madsen (lmadsen) 2008-12-05 09:43:48.000-0600 Reassigning this issue in the hopes it can get moved forward. Looks like it could be a useful feature, and the code doesn't look too complicated... By: Terry Wilson (twilson) 2008-12-05 13:48:05.000-0600 1.4 has been around for quite a while, and people haven't been cursing this behavior yet.  I'm not sure if this warrants inclusion or not--especially since we try to avoid adding new features to 1.4.  I'm also a bit confused by a "dumb SIP proxy" that is relaying RTP and also must be modifying the phones' SDP since they should be sending that they understand rfc2833 dtmf.  This sounds like a pretty specific set of circumstances that I don't think would affect too many users. By: Andriy I Pylypenko (bamby) 2008-12-08 01:28:02.000-0600 I agree that this behavior is quite uncommon, especially in a small production environments. Such problem can happen most likely in relatively big installations where old expensive equipment is present and cannot be easily changed or repaired. Anyway this patch doesn't bring any changes to mainstream functionality but adds relatively small and easy optional feature. By: Terry Wilson (twilson) 2008-12-08 12:47:38.000-0600 The problem is, I don't think anyone else has or will run into the problem.  Whatever "dumb sip proxy" is there, is clearly doing something wrong by stripping out the ability of the phones on the other side and the vendor needs to fix it.  The possibility of more than one vendor making this mistake seems pretty small to me. By: Leif Madsen (lmadsen) 2008-12-08 13:48:39.000-0600 Thank you for the contribution to Asterisk as we appreciate it, but since this functionality would affect so few people, I don't think it makes sense to support this in-tree. So for now I'm going to close this issue and ask you to support this patch for your configuration out of tree.