|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|
|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 220.127.116.11, 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, 18.104.22.168
gblx-testcall-1.4 = from Global to asterisk, 1.4.11
as5400-testcall = from asterisk to as5400, 22.214.171.124
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:
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 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 126.96.36.199. 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 188.8.131.52 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 184.108.40.206 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:
By: Joshua C. Colp (jcolp) 2009-03-10 09:50:03
Closed as fixes already put into SVN fixes the scenario for the reporter.