Summary:	ASTERISK-12547: RFC2833 mangled from Sonus when RTP stream passes through asterisk rather than being reinvited
Reporter:	Paul Timmins (ptimmins)	Labels:
Date Opened:	2008-08-09 17:00:44	Date Closed:	2011-06-07 14:08:07
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Interoperability
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) as5400-testcall.dump ( 1) as5400-testcall-1.4.11.dump ( 2) dtmfdebug.log ( 3) gblx-testcall.dump ( 4) gblx-testcall-1.4.dump
Description:	We were/are using 1.4.11. We connect to Global Crossing over SIP. They use Sonus softswitches. We use ulaw and rfc2833. We also use Cisco AS5400 gateways and Adtran Total Access 900 IADs. Under 1.4.11, RFC2833 DTMF passed through asterisk was properly replicated. When we upgraded (directly) to 1.4.21.2, asterisk began manipulating the DTMF such that when it went from Global, through asterisk, to the Cisco or Adtran gateways, the touchtones were mangled to the point they simply make a chirping silence noise. If canreinvite=yes is set, they work fine. However, that Global doesn't allow you to reinvite to arbitrary destinations, so this won't work as a long term solution. Attached is a copy of a working SIP+RTP stream going from Global to Asterisk, and from Asterisk to the as5400, as well as a copy of a failing one, as well as the dtmf debug.
Comments:	By: Paul Timmins (ptimmins) 2008-08-09 17:10:47 gblx-testcall = from Global to asterisk, 1.4.21.2 gblx-testcall-1.4 = from Global to asterisk, 1.4.11 as5400-testcall = from asterisk to as5400, 1.4.21.2 as5400-testcall-1.4 = from asterisk to as5400, 1.4.11 By: Paul Timmins (ptimmins) 2008-08-09 17:12:49 I also forgot to mention - the DTMF corruption is unidirectional. When the call is in progress, you can hear touchtones from the as5400 to the Sonus just fine. From the Sonus to the as5400 fails. By: Paul Timmins (ptimmins) 2008-08-09 17:14:31 Additionally, asterisk understands DTMF from both directions. We're able to navigate IVR trees and AGI applications just fine in both versions in both directions. By: Paul Timmins (ptimmins) 2008-08-14 20:31:31 what's going on with this? Anything? did I fill this out wrong? By: Paul Timmins (ptimmins) 2008-09-12 11:20:56 It's been a month - has anyone looked at this? By: Joshua C. Colp (jcolp) 2008-12-08 10:26:58.000-0600 I need to see your configuration from sip.conf for this plus complete console output. The RFC2833 digits are getting sent with a different timestamp/sequence number generation then the audio which is causing things to get screwed up... this should not happen if everything is going through the core as it is should for this so it may be some sort of weird configuration that is causing the two channels to Packet2Packet bridge when they should not. By: Paul Timmins (ptimmins) 2008-12-08 11:43:33.000-0600 I'll need a couple of weeks as I can better experiment with this in our lab and this bug was reported when we were experiencing the problem in production before we got the lab up. But I'll need a week or so to get the lab connected to the carrier with the sonus that was causing the issue. Just didn't want this to be closed for lack of response. By: Leif Madsen (lmadsen) 2009-02-04 13:24:59.000-0600 I think this thread on the asterisk-dev list may be related to this issue: http://lists.digium.com/pipermail/asterisk-dev/2009-February/036394.html By: Kristian Kielhofner (krisk84) 2009-02-05 01:29:16.000-0600 Your 2833 events and audio have different SSRCs (in addition to different timestamps and seq nos).  As file said, the only way to fix this up is to send DTMF events through the core. This could potentially lead to yet another Sonus issue.  See my post to asterisk-dev for more on that... At least you're using G.711u.  You have the option for inband! ;) By: Paul Timmins (ptimmins) 2009-02-05 12:07:50.000-0600 The weird part is that it works perfectly under 1.4.11 (where I'm currently stuck). Of course, it crashes randomly, and it might be related (often I get strings of: [Dec 23 12:59:15] WARNING[17311] app.c: No audio available on SIP/REDACTED-b4f7e2f8?? ) just before it stops responding. There's a general bug I've been finding in 1.4.11 where the sip stack hangs and it still sends RTP. I wonder if it's related. Either way it's 1.4.11 and sucks implicitly. But it's weird that it works here. By: Paul Timmins (ptimmins) 2009-03-02 16:47:59.000-0600 We were able to push this through our lab, then into production, and it's working great in 1.4.23.1. Thanks to whoever fixed this, it's been huge for us! :) By: Leif Madsen (lmadsen) 2009-03-02 16:49:46.000-0600 ptimmins: are you saying 1.4.23.1 allows RFC2833 to work with Sonus in your configuration? By: Paul Timmins (ptimmins) 2009-03-02 16:54:16.000-0600 That is what I am saying. It works perfectly now. By: Leif Madsen (lmadsen) 2009-03-02 17:07:18.000-0600 Very interesting... wonder if anyone else has found 1.4.23.1 has correct their Sonus issue? By: Paul Timmins (ptimmins) 2009-03-04 15:06:46.000-0600 I got the heads up from here to try it: http://blog.krisk.org/2009/01/heads-up.html By: Joshua C. Colp (jcolp) 2009-03-10 09:50:03 Closed as fixes already put into SVN fixes the scenario for the reporter.