<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='color:#1F497D'>Finally Solved!<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>I want to thank everyone who help with advice and/or contacts on this problem.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Here is an e-mail from AT&T about this problem.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'><i><span style='font-size:10.0pt'>Raghu and I have been working on this today – and we found that there almost certainly exists a ‘bug’ in the EVC/Nortel MSC (VSE MSC) causing this problem. This issue is being caused by any far end switch that responds to an incoming call with the optional ISUP_CPG (Call Progress) message that does not have the optional BCI parm included (Backwards Call Indicators). If the EVC MSC routes a call to a PSTN trunk group and sends an ISUP IAM to far end, far end sends ACM (Address Complete) and if they also send an ISUP_CPG that does not contain the BCI parm – this causes the MSC to reject any DTMF tone requests from the originating callers. This exact same issue was found in our MSC during a FFA (First Field Application) trial of the previous version of MSC software (uCore5) back in late 2013. We believe that our newest MSC software version (uCore15A) might be missing this bug fix and causing this problem – AGAIN. I have a HIGH PRIORITY case opened up with the MSC vendor that I will pursue with great diligence.<o:p></o:p></span></i></p><p class=MsoNormal style='margin-left:.5in'><i><span style='font-size:10.0pt'><o:p> </o:p></span></i></p><p class=MsoNormal style='margin-left:.5in'><i><span style='font-size:10.0pt'>SO – for now – the only way to fix this is to change the routing to not use this TYVLILXC50T02A1B trunk group. I will have more info on when we can expect a fix from the vendor – but best case scenario for that would be several WEEKS. <o:p></o:p></span></i></p><p class=MsoNormal style='margin-left:.5in'><i><span style='font-size:10.0pt'><o:p> </o:p></span></i></p><p class=MsoNormal style='margin-left:.5in'><i><span style='font-size:10.0pt'>I know this is NOT good news – BUT it is all I can offer up at this time. Thanks –<o:p></o:p></span></i></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>We had them route around the problem switch and our problem went away.  We’re using a Sangoma NSG SS7 gateway.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Thanks again everyone!<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Adam<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> VoiceOps [mailto:voiceops-bounces@voiceops.org] <b>On Behalf Of </b>Adam Vocks<br><b>Sent:</b> Wednesday, June 24, 2015 11:58 AM<br><b>To:</b> voiceops@voiceops.org<br><b>Subject:</b> [VoiceOps] AT&T Cellular - DTMF<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I’ve got an odd problem that someone might be able to point me in the right direction to get some help.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>AT&T cellular customer calls a number destined to our LRN.  Customer presses a digit on the phone, no DTMF audio ever comes across the trunk.  If that same customer calls a number with the same npa/nxx not destined for our LRN, DTMF audio comes across the trunk.  These calls are coming to us via SS7 trunks and the ILEC that these calls transit through has verified that both calls come in on the same trunks, one has DTMF audio, one does not.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>This problem started on Thursday morning.  Prior to Thursday morning, AT&T cellular calls were arriving to us via our FGD Tandem connection, now they are arriving via the local rate center switch.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I’ve talked to AT&T and attempted to put in a ticket on the DS3 that enters the ILEC, but they refused to do that because they said the DTMF would be audio and they would just pass it through.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Anyone have advice?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>AT&T (low level tech) states that the DTMF tones are generated at the phone and are in the audio stream the entire way.  Does anyone know if AT&T uses some sort out of band dtmf signaling?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks!<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Adam Vocks<o:p></o:p></p><p class=MsoNormal>CTI Fiber <o:p></o:p></p></div></body></html>