Need help!

[dctturbo]

We have starting testing VC between two cities over IP. We are experiencing severe packet loss going one way and none going the other way. Has any one else experienced this? We are using two Polycom Viewstation FX's over a 10 meg network. Any ideas?

[tom9933]

If this isn’t a dedicated link for VC then this is very common behavior. Also are you conferencing over the public internet? Generally you will see that the receive side on one of the sites is very bad (losing a lot of packets) due to congestion from desktop users downloading from servers. Implementing some sort of quality of service will generally help this but the best idea is to first determine where the congestion is coming from. Have you looked at the status of the routers? Also have you looked at the trace route data between the two codecs? In addition another thing to check is that the port speeds on the codec and switch match. In other words both the codec and the switch are 10 half.

[dctturbo]

Thanks for the help! The VC is running on a backbone network and not over the public internet. Our network guys are trying to find exactly where the packets are dropping off. Thanks for the tip on Codec setting I will check that out.

[Gary Miyakawa]

Couple of things I would look at...

What speed do you see the drops ?? For IP, often slower is better if you are having packet loss.

Also, I don't know what kind of Switches are you using (ethernet wise) but have the IT folks check to see if you are getting errors from them trying to retrain for speed(10/100) or Duplex (Half/Full).. Often, these are set to Auto negociate and sometimes, the two don't talk nice and during that re-negociation, there can be packet loss.

You could also try a 1400 byte ping from each side to see if you see some loss.. That sometimes will help (by pinging to each "hop" between you and the far end).

Let us know how it goes !

Gary Miyakawa

[Skylark]

Allso check if there are any Hubs on the network that the signal travels throug and replace them with switches.

[Glen Sykes]

It is always good practice to fix port speeds on both the VC system and the switch that it is attached to for exactly the reasons mentioned above. Autonegotiation, expecially with 10/full (this was never actually fully standardised beleive it or not) can be a dodgy affair, and it becomes highly apparent in VC's where packet loss means a little more than a percieved slow connection (as it would look to say someone browsing a web site).

glen

[tom9933]

Yes I agree there definitely seem to be some problems with the various vendors when it comes to auto-negation. Now having said that, we run a Cisco house and auto-negotiation works great with the 5500 and 3500 switches. The only problems we’ve seen were with some of the older 10 base-T 3Com NICs and the (early bios) Intel 815 motherboards with integrated 10/100 NIC. Surprisingly the codecs seem to play nicer then most.

[dctturbo]

Thanks to everyone who replied. It seems our VC project exposed a bigger problem within the network. There were problems with mismatched switch settings plus they found a device that was broadcasting data and bogging down the network. (It's funny someone hadn't noticed this before) Once the problems were fixed we were in business. Thanks again.

[Glen Sykes]

I see this quite a lot, VC exposes a lot of network issues that previously get overlooked due to the nature of the traffic. It's ironic that once upon a time network managers were resistive to H.323 as it would 'clog up the network' yet after implementation their networks run much faster because of the problems we unearth when implementing H.323!

C'est la vie!