Is anyone else running into issues with DASH's SBC changes from this past morning's maintenance window? We're experiencing two new issues. The first is a DTMF issue. We're seeing DASH send us RFC2833 DTMF over the SIP trunk but the MetaSwitch is not liking what the new DASH SBCs are sending. In turn the MetaSwitch is not sending DTMF on to the downstream customer. It sounds like RFC2833 negotiation between the MetaSwitch and their new SBC leaves only ulaw as an option which doesn't appear to agree with MetaSwitch. Thus no DTMF on towards the customer. We were moved back to the old SBC and the DTMF problem has been resolved for now. We've been told that this was an issue earlier with DASH and MetaSwitch and that it was resolved at a particular MetaSwitch customer's site. We're working back channels to try and figure out what that fix was. The second issue is with what initially appears as a no-way audio on calls to certain numbers at different customer sites. When you capture the traffic you realize that there is 2-way audio but it only contains comfort noise. DIDs don't seem to be affected. The only numbers chosen for this particular problem are the main numbers at the sites. The sites in question all use the same remote media gateway model on the MetaSwitch, have Edgemarc CPEs and Aastra phones. The lines are also configured for SIP forking with several phones on the same line. However it doesn't affect all of our customers configured in what appear to be the exact same way. Some work perfectly fine. What we're hearing from DASH is that their upstream is putting the call on-hold for some reason as soon as the receiving end picks up. Very strange. We're troubleshooting that one in the morning. Has anyone else run into issues with the migration to the new SBCs at DASH? Since we only had outgoing calls going over the new DASH SBCs and incoming on the old SBCs these problems weren't ever discovered in testing. Without that there really wasn't any testing done on our end. Thanks Justin
We have recently started using DASHCS SIP services through Atlanta. We are using Asterisk based gateways, using RFC2833 and G711/uLaw, and aren't having any trouble at this time. Can't really help with the Metaswitch, but our engineer did encounter some hiccups during the initial testing phase of the service turnup when testing/experimenting with DTMF options and alternate codecs. His conclusion was that, for our gateways, sticking with RFC2833 and G711/uLAW would provide the most reliable service, which it has. Jaimie -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Justin Shore Sent: Thursday, November 05, 2009 1:24 AM To: voiceops at voiceops.org Subject: [VoiceOps] DASH issues Is anyone else running into issues with DASH's SBC changes from this past morning's maintenance window? We're experiencing two new issues. The first is a DTMF issue. We're seeing DASH send us RFC2833 DTMF over the SIP trunk but the MetaSwitch is not liking what the new DASH SBCs are sending. In turn the MetaSwitch is not sending DTMF on to the downstream customer. It sounds like RFC2833 negotiation between the MetaSwitch and their new SBC leaves only ulaw as an option which doesn't appear to agree with MetaSwitch. Thus no DTMF on towards the customer. We were moved back to the old SBC and the DTMF problem has been resolved for now. We've been told that this was an issue earlier with DASH and MetaSwitch and that it was resolved at a particular MetaSwitch customer's site. We're working back channels to try and figure out what that fix was. The second issue is with what initially appears as a no-way audio on calls to certain numbers at different customer sites. When you capture the traffic you realize that there is 2-way audio but it only contains comfort noise. DIDs don't seem to be affected. The only numbers chosen for this particular problem are the main numbers at the sites. The sites in question all use the same remote media gateway model on the MetaSwitch, have Edgemarc CPEs and Aastra phones. The lines are also configured for SIP forking with several phones on the same line. However it doesn't affect all of our customers configured in what appear to be the exact same way. Some work perfectly fine. What we're hearing from DASH is that their upstream is putting the call on-hold for some reason as soon as the receiving end picks up. Very strange. We're troubleshooting that one in the morning. Has anyone else run into issues with the migration to the new SBCs at DASH? Since we only had outgoing calls going over the new DASH SBCs and incoming on the old SBCs these problems weren't ever discovered in testing. Without that there really wasn't any testing done on our end. Thanks Justin _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
participants (2)
-
jaimie＠featuretel.com -
justin＠justinshore.com