<div>I have looked over all of the interfaces for slips and errors and everything looks clean. We are the ISP for the customer so I have access to both the CPE side and the PE side. In this scenario the the data T1 on the IAD recieves clock from the line. The IAD PRI is set to clock source internal. The PBX is set to clock source line.</div>
<div> </div>
<div>If there is a method to picking IOS, I havent learned it. Our requirements for these devices are pretty basic. Any ipvoice feature set should meet our requirements.. Does anyone have a preferred IOS version for voice or specifically 2431 IAD's. </div>
<div> </div>
<div>Thanks,</div>
<div> </div>
<div>Jeff<br></div>
<div class="gmail_quote">On Wed, May 6, 2009 at 4:23 PM, Jason Aarons (US) <span dir="ltr"><<a href="mailto:jason.aarons@us.didata.com">jason.aarons@us.didata.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div lang="EN-US" vlink="purple" link="blue">
<div>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d">All your questions are around layer1, a show controller or show service-module would indicate if clocking or timing or other layer1 issues. You have to look at both sides. Your side may be clean but the other side dirty.</span></p>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d"> </span></p>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d">Usually a TTC T-Berd with Y-Cable in the middle would help with analysis. You can even listen in to troubleshoot. You can rent T-Berd for a month for less than $250 from Renfro Test Equipment (Google).</span></p>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d"> </span></p>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d">Other answers inline</span></p>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d"> </span></p>
<div style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
<p><b><span style="FONT-SIZE: 10pt">From:</span></b><span style="FONT-SIZE: 10pt"> <a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank">cisco-voip-bounces@puck.nether.net</a> [mailto:<a href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank">cisco-voip-bounces@puck.nether.net</a>] <b>On Behalf Of </b>Jeff Anderson<br>
<b>Sent:</b> Wednesday, May 06, 2009 5:00 PM<br><b>To:</b> <a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br><b>Subject:</b> [cisco-voip] Special considerations for IAD or PRInetwork-emulation on Cisco hardware...</span></p>
</div>
<div class="im">
<p> </p>
<div>
<p>I have a couple of customers who are experiencing poor audio using an IAD to connect their PBX to our h.323 PSTN GW.</p></div>
<div>
<p> </p></div>
<div>
<p>Basic Layout.</p></div>
<div>
<p> </p></div>
<div>
<p>Customer PBX PRI > IAD PRI (Network-emulate) converted to VoIP > MPLS enabled T1 > Core > AS5850 (VoIP converted to TDM) > PSTN.</p></div>
<div>
<p> </p></div>
<div>
<p>The customer reports that poor audio is experienced inbound into their PBX. They say their outbound audio is okay. This doesnt happen on every call but we do have more than one customer reporting the issue.</p></div>
<div>
<p> </p></div>
<div>
<p>The audio can be described anywhere from echo, cutting out or distorted audio. The problem has also been reported by users who have 38xx series gateways so i dont think the problem is IAD specific. The AS5850 is a shared device used by many different customers, the majority of which connect using Cisco IP phones and this demographic of customers are not reporting the problem.</p>
</div>
<div>
<p> </p></div>
<div>
<p>I have done packet captures on the AS5850 and there is no packet loss reported, the packets arrive in sequence and the jitter is very low.</p></div>
<div>
<p> </p></div>
<div>
<p>In my testing, I have found double-talk to cause the far end audio (AS5850) to cut-out. All the packets arrive but they contain a payload value of 7F. Some improvement can be made to this condition by disabling non-linear progression. </p>
</div>
<div>
<p> </p></div>
<div>
<p> </p></div>
<div>
<p> </p></div>
<div>
<p>My questions for the community are related to experiences or lessons learned from using PRI network emulate.</p></div>
<div>
<p> </p></div>
<div>
<p>Can there be too many echo cancellers in the call flow? (i.e. Customer PBX UC500 with Cisco PRI, IAD PRI, AS5850 PRI all with echo cancellers)</p></div></div>
<div>
<p> <span style="COLOR: #1f497d">They are usually local link significant. Bad DSP micro code can cause the issues you are reporting. I’ve done PCM captures that were good yet the DSP turned out to be bad.</span></p>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d"> </span></p></div>
<div>
<div class="im">
<p>Does the cable length command have any bearing on voice quality?</p></div>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d">I haven’t seen the cable length command fix quality issues</span></p></div>
<div>
<p> </p></div>
<div>
<div class="im">
<p>Are there any special commands i should enter when connecting back to back wth a T1 cable (echo-cancel coverage, nlp, etc)?</p></div>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d">Who is clocking? Network vs user side? Clock slips, line code violations, etc would create the problems you describe</span></p></div>
<div>
<p> </p></div>
<div>
<div class="im">
<p>Is a 2 pair sheilded T1 cable necessary for the PRI back to back connection of less than 20 ft?</p></div>
<p><span style="FONT-SIZE: 11pt; COLOR: #1f497d">I always use shielded T1, who knows when EMF will be present? A 1 ft cable wrapped around a ballast would be bad..</span></p></div>
<div class="im">
<div>
<p> </p></div>
<div>
<p> </p></div>
<div>
<p>Any insight or suggestions would be greatly appreciated. </p></div>
<div>
<p> </p></div>
<div>
<p>Thanks,</p></div>
<div>
<p> </p></div>
<div>
<p>Jeff </p></div>
<div>
<p> </p></div>
<div>
<p> </p></div></div></div></div>
<div>
<p>
<hr size="1">
<p></p>
<p><strong>Disclaimer: This e-mail communication and any attachments may contain confidential and privileged information and is for use by the designated addressee(s) named above only. If you are not the intended addressee, you are hereby notified that you have received this communication in error and that any use or reproduction of this email or its contents is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. </strong></p>
</p></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>