Summary:	ASTERISK-08711: [branch] need more 'relaxed' RFC2833 handling to interop with TI-based SIP-adapters
Reporter:	AndrewZ (andrewz)	Labels:
Date Opened:	2007-02-01 08:39:27.000-0600	Date Closed:	2007-06-30 09:20:07
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/RTP
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) Asterisk_rfc2833_debug.txt ( 1) bad_rfc2833_decoded.txt
Description:	Some SIP-adapters like Linksys PAP2 ver.2, Linksys WRTP54G, Linksys WAG54GP2, Linksys RTP300, Vtech IP8100, Motorola VT2442, D-Link VTA-VR which are based on TI AR7 chipset are sending rfc2833 packets in a manner which is different from the other devices are using. As a result they are not recognized by Asterisk. Those adapters are not sending End of Event packets and Asterisk cannot handle this situation. ------------------------- Ethereal decode (bad example): RFC 2833 RTP Event    Event ID: DTMF Two 2 (2)    0... .... = End of Event: False    .0.. .... = Reserved: False    ..00 0011 = Volume: 3    Event Duration: 0 Asterisk output: [Jan 30 17:58:15] DTMF[29778]: channel.c:2148 __ast_read: DTMF begin '2' received on SIP/12-081ba2d8 [Jan 30 17:58:17] DTMF[29778]: channel.c:2148 __ast_read: DTMF begin '#' received on SIP/12-081ba2d8 --------------------------------------- Ethereal decode (good example): 3 packets like RFC 2833 RTP Event    Event ID: DTMF Two 2 (2)    0... .... = End of Event: False    .0.. .... = Reserved: False    ..00 0011 = Volume: 3    Event Duration: 0 followed by 3 packets like RFC 2833 RTP Event    Event ID: DTMF Two 2 (2)    1... .... = End of Event: True    .0.. .... = Reserved: False    ..00 0011 = Volume: 3    Event Duration: 0 Asterisk output: [Jan 30 18:11:37] DTMF[29833]: channel.c:2148 __ast_read: DTMF begin '2' received on SIP/11-081b68a0 [Jan 30 18:11:37] DTMF[29833]: channel.c:2128 __ast_read: DTMF end '2' received on SIP/11-081b68a0
Comments:	By: AndrewZ (andrewz) 2007-02-01 11:20:26.000-0600 This is not a duplicate! rfc2833 and INFO problems are different - In first case the 'end' packet is missing, in the 2nd - packet format is incorrect. Thank you. By: Olle Johansson (oej) 2007-02-01 15:26:51.000-0600 Moving this out of "SIP" category into "core/RTP" By: Russell Bryant (russell) 2007-02-02 00:06:21.000-0600 I'm sorry for closing this.  I read the summaries too quickly and they looked the same.  :) By: Russell Bryant (russell) 2007-02-02 00:08:38.000-0600 So, why is it that Asterisk has to account for their broken implementation?  Shouldn't this bug be reported to the people that made the thing that is broken? By: AndrewZ (andrewz) 2007-02-02 04:28:57.000-0600 I would not say this is "broken implementation", it's simply different. The same adapter works fine with another proxy like CGP just fine. That's why I used the term "feature" instead of "bug". It will be nice to have a feature to overcome this implementation. I don't think we can force all the vendors I mentioned at the begining to fix the code. Most of those devices are sold locked to Vonage and other providers. As soon as they are quite cheap people are buying them and get them unlocked. At the same time RFC2833 gives us some freedom: "Receiver implementations MAY use different algorithms to create tones, including the two described here...". Thank you. By: Joshua C. Colp (jcolp) 2007-02-02 11:46:15.000-0600 Please give the branch at http://svn.digium.com/svn/asterisk/team/file/issue_8963 a try - ensuring that rfc2833compensate is set to yes for your devices and see if it works. Thanks! By: AndrewZ (andrewz) 2007-02-02 12:42:02.000-0600 Thank you. This is the result: Segmentation fault (core dumped) By: AndrewZ (andrewz) 2007-02-02 13:52:56.000-0600 It was my fault, I forgot to remove the old modules. The problem with rfc2833 is solved ! I've checked with 2 different devices I have. Thank you!! By: AndrewZ (andrewz) 2007-02-18 09:51:25.000-0600 Hello Is there any chance that this feature will be incorporated into release brunch? Thanks By: Joshua C. Colp (jcolp) 2007-03-11 20:22:22 Put into 1.4 as of revision 58783 and trunk as of revision 58784. Just remember to enable compensation. By: AndrewZ (andrewz) 2007-06-03 13:43:32 Does not work in 1.4.4 Works fine with the same config files in trunk revision 66997. By: Joshua C. Colp (jcolp) 2007-06-04 06:37:29 Please try Asterisk 1.4 from subversion and provide debug information along with it if the issue is still there. By: AndrewZ (andrewz) 2007-06-04 08:05:44 Works fine with Asterisk SVN-branch-1.4-r66919. Thank you! By: Joshua C. Colp (jcolp) 2007-06-04 08:08:24 Fixed in subversion already long ago.