<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2963" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=100155323-16082006><FONT face=Arial
color=#0000ff size=2>if you have a spare system laying around, add a second NIC
to it plug that system into the switch in the closet where the 7936
exists..</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=100155323-16082006><FONT face=Arial
color=#0000ff size=2>span the 36 port to the second card on the switch to the
second NIC on the monitor box.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=100155323-16082006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=100155323-16082006><FONT face=Arial
color=#0000ff size=2>then using Ethereal you can almost play back the
packets..</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=100155323-16082006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=100155323-16082006><FONT face=Arial
color=#0000ff size=2>I had a similiar issue on another vendor's IPT and we found
that the packets were leaving with the wrong QOS and getting
dropped....</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=100155323-16082006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=100155323-16082006><FONT face=Arial
color=#0000ff size=2>make sure it is not a layer 2 issue
also....</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=100155323-16082006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=100155323-16082006><FONT face=Arial
color=#0000ff size=2>Later,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=100155323-16082006><FONT face=Arial
color=#0000ff size=2>J</FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> cisco-voip-bounces@puck.nether.net
[mailto:cisco-voip-bounces@puck.nether.net] <B>On Behalf Of </B>Jonathan
Charles<BR><B>Sent:</B> Wednesday, August 16, 2006 2:55 PM<BR><B>To:</B> Ryan
LaTorre<BR><B>Cc:</B> cisco-voip@puck.nether.net<BR><B>Subject:</B> Re:
[cisco-voip] Best practices for a 7936?<BR></FONT><BR></DIV>
<DIV></DIV>Yeah, since the 7935/36 are not made by Cisco, they tend to not do
CDP very well.<BR><BR>I have found that they have a great tendency to pickup an
IP on the data VLAN if the switchport is not configured explicitly as an access
port on the voice vlan. <BR><BR>It just simplifies
everything.<BR><BR><BR>Jonathan<BR><BR>
<DIV><SPAN class=gmail_quote>On 8/16/06, <B class=gmail_sendername>Ryan
LaTorre</B> <<A
href="mailto:rlatorre@unislumin.com">rlatorre@unislumin.com</A> >
wrote:</SPAN>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"><BR>Going
back a little while to firmware 3.3(5) or so, I also experienced <BR>one-way
audio in some cases. What worked for me was to remove the<BR>access
vlan/voice vlan configuration on the switchport and configure<BR>just a
standard access port on the voice vlan.<BR><BR>-Ryan<BR><BR>-----Original
Message----- <BR>From: <A
href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A><BR>[mailto:<A
href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A>]
On Behalf Of Robert <BR>Kulagowski<BR>Sent: Wednesday, August 16, 2006 1:48
PM<BR>To: <A
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Subject:
[cisco-voip] Best practices for a 7936?<BR><BR>I've got a site where 7936's
seem to have one-way audio issues; after a <BR>call is made, the other side
can hear outbound audio, but we can't hear<BR>them.<BR><BR>The 7936's are
running 3.3(11), which is the latest firmware.<BR><BR>Looking at the forums on
Cisco, some solutions were 1) Hardcode the IP <BR>address on the
phone, since there appear to be issues when the DHCP<BR>server
reboots 2) Hardcode the speed and duplex on the phone
and the<BR>switchport to 100/FDX.<BR><BR>Of course it only fails when there's
a critical call that needs to <BR>happen, and our solution is to reboot the
phone, but that's not viable<BR>long term. And once we get to this
point, where the phone is only<BR>working one-way, calling TAC so they can
troubleshoot why it's happening<BR>is a non-starter, because the conference
call _has_ to happen.<BR><BR>Anyone else experiencing these issues with
7936's?<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">https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>Attention:<BR><BR>Privileged/Confidential
Information may be contained in this message. Disclosure to any
person other than the named recipient is unauthorized. If you are
not the intended recipient, please delete all copies of this information and
kindly notify the sender by reply email. Opinions, conclusions and
other information in this message that do not relate to the official business
of UNIS LUMIN Inc. shall be understood as neither given nor endorsed by
it. UNIS LUMIN Inc. and any of its subsidiaries reserve the right
to monitor all e-mail communications through its networks. Thank
you. <BR><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">https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR></BLOCKQUOTE></DIV><BR></BODY></HTML>