Thanks for the advise, I have not because in normal fire fighting fashion I've been juggled to another project temporarily. I'm hoping to get back out there this evening or over the weekend and I'll definitely give that a shot along with the other suggestions. TAC of course has me pulling sniffer traces because they think its a QOS issue which its obviously not or other non-7937 phones on the same switch are perfectly fine and phones and gateway are on the same vlan and there's very little traffic on the network as a whole. Thanks again for your assistance, I'll let you know how it turns out.<div>
<br></div><div><br><br><div class="gmail_quote">On Fri, Jan 8, 2010 at 8:41 AM, Matthew Linsemier <span dir="ltr"><<a href="mailto:mlinsemier@apassurance.com">mlinsemier@apassurance.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>
<font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">Ted,<br>
<br>
Did you ever try removing CDP on the port and then hard coding the VLAN on the 7937 phone through the admin portal? I think we did this based on a few bugs: CSCsu65069 and CSCsu47079 (even though it’s not for a 7937). It seemed to work for us. We only have one 7937 and it’s used for several conference calls a week via Meetingplace Express. <br>
<br>
Matt<div><div></div><div class="h5"><br>
<br>
<br>
On 1/5/10 12:39 PM, "Ted Nugent" <<a href="http://tednugent73@gmail.com" target="_blank">tednugent73@gmail.com</a>> wrote:<br>
<br>
</div></div></span></font><blockquote><font face="Calibri, Verdana, Helvetica, Arial"><div><div></div><div class="h5"><font size="1"><span style="font-size:8pt">I have a new customer install with 8 sccp 7937s and all of them are experiencing the same problem. Intermittently throughout the call they continue to lose voice for 5-10 seconds and then it clears back up for a few minutes and it occurs again. I can see on the web statistics for the phone that it appears to be losing packets (Rcvr Lost Packets 2483). This only appears to be occurring inbound to the device since the caller does not hear and audio issues. These devices are deployed throughout the company and all are experiencing the same issues at times. There are a couple bugs for g729 and g722 but we’re running g711 (g722 has been disabled clusterwide). They were experiencing the issue yesterday and I had the 7937 conference in a 7965 and the 7965 did not experience any voice issues so it’s not the call itself or callers phone. No other phones are experiencing the issues and I’ve upgrading the load from 1.3.3 to 1.3.4 and the problem still exists. Calls are hitting the PSTN via an MGCP controlled PRI however I’m not sure if that’s in play or not we have not been able to replicate the problem on internal calls but that’s not to say it’s not occurring because its intermittent.<br>
No Duplex Mismatches<br>
Cabling has been checked and device moved to new location with known good wiring<br>
CUCM 7.1.2.21900-5<br>
Any ideas?<br>
</span></font></div></div><span style="font-size:11pt"><br>
<br>
<hr align="CENTER" size="3" width="95%"></span></font><div class="im"><font size="2"><font face="Consolas, Courier New, Courier"><span style="font-size:10pt">_______________________________________________<br>
cisco-voip mailing list<br>
<a href="http://cisco-voip@puck.nether.net" target="_blank">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>
</span></font></font></div></blockquote><div class="im">
<p><font face="Arial" color="#808080" size="1">
</font></p><font face="Arial" color="#808080" size="1"><hr>
</font><p></p>
<p><font color="#808080"><font face="Arial" size="1">CONFIDENTIALITY STATEMENT<br>This
communication and any attachments are CONFIDENTIAL and may be protected by one
or more legal privileges. It is intended solely for the use of the addressee
identified above. If you are not the intended recipient, any use, disclosure,
copying or distribution of this communication is UNAUTHORIZED. Neither this
information block, the typed name of the sender, nor anything else in this
message is intended to constitute an electronic signature unless a specific
statement to the contrary is included in this message. If you have received this
communication in error, please immediately contact me and delete this
communication from your computer. Thank you.</font> </font></p>
<p><font color="#808080">
</font></p><font color="#808080"><hr>
</font><p></p>
</div></div>
</blockquote></div><br></div>