<div>Hey Steven,</div>
<div> </div>
<div>I ran into this same exact problem with Verizon and a customer of mine. What ended up fixing it was to go to 12.4.20T3 on the CUBE.</div>
<div>We tried the same command you just posted but it didnt help. After we went to that version of the IOS it worked.</div>
<div>The problem is on the Nortel switch being used by Verizon. It detects those tones and thinks it is a Fax call so it tries to switch over to FAX and sends the Codec renegotiation. </div>
<div>In my case it wasnt a fax call and the CUBE dropped the call due to that.</div>
<div>For some reason not really explained to me by Verizon that IOS has a fix in it provided by Cisco just for Verizon's use.</div>
<div> </div>
<div>Good luck,</div>
<div> </div>
<div>Joel P</div>
<div><br><br> </div>
<div class="gmail_quote">On Thu, Jan 28, 2010 at 10:13 AM, STEVEN CASPER <span dir="ltr"><<a href="mailto:SCASPER@mtb.com">SCASPER@mtb.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div style="MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<div>Having an interesting issue with a Verizon IP Trunk pilot, </div>
<div> </div>
<div>
<div> Users being disconnected when certain tones are heard on a call. We can recreate this problem anytime by playing the Blackberry default ringer while a call is in progress. According to Verizon they are set up for mid-call codec renegotiation when fax tone is heard on a call. The CUCM rejects the codec renegotiation and Verizon disconnects.</div>
<div>TAC provided an option for the CUBE which is supposed to pass the codec renegotiation rejection message from Call Manager to the Verizon SBC but this has had no effect on resolving the problem. </div>
<div> </div>
<div>
<div><span><font size="2" face="Arial">voice service voip</font></span></div>
<div><span><font size="2" face="Arial"> sip</font></span></div>
<div><span><font size="2" face="Arial"> header-passing error-passthru </font></span></div>
<div><span><font size="2" face="Arial"></font></span></div>
<div><span><font size="2" face="Arial"></font></span> </div>
<div><font size="2" face="Arial"><span>This error response applies to the following</span></font></div>
<div><font size="2" face="Arial"><span> 4xx - request failure responses</span></font></div>
<div><font size="2" face="Arial"><span> 5xx - server failure responses</span></font></div>
<div><font size="2" face="Arial"><span> 6xx - global failure responses</span></font></div>
<div><font size="2" face="Arial"><span></span></font> </div>
<div><font size="2" face="Arial"><span>This command should pass the error received along both call legs.</span></font></div>
<div><font size="2" face="Arial"><span></span></font> </div>
<div><font size="2" face="Arial"><span>While this could be useful feature at times I was wondering if anyone else has run into this and has a fix.</span></font></div>
<div><font size="2" face="Arial"><span></span></font> </div>
<div><font size="2" face="Arial"><span>Thanks,</span></font></div>
<div><font size="2" face="Arial"><span>Steve</span></font></div></div>
<div> </div>
<div> </div></div><pre>************************************
This email may contain privileged and/or confidential information that is intended solely for the use of the addressee. If you are not the intended recipient or entity, you are strictly prohibited from disclosing, copying, distributing or using any of the information contained in the transmission. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act. You may not directly or indirectly reuse or disclose such information for any purpose other than to provide the services for which you are receiving the information.
There are risks associated with the use of electronic transmission. The sender of this information does not control the method of transmittal or service providers and assumes no duty or obligation for the security, receipt, or third party interception of this transmission.
************************************
</pre></div><br>_______________________________________________<br>cisco-voip mailing list<br><a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div><br>