Jitter from Radvision MCU

[Mike Souders]

Running Radvision Invision MCU with Polycom FX endpoints and a few Tandberg 3000's. Recently moved to IP but am getting tons of jitter and can't seem to figure out why. Point to point calls are flawless. Running calls off the MCU at 384k. Mostly running Cisco routers and switches. Running VC on it's on VLAN. QOS enabled. Any suggestions would be very appreciated.

[ceg6vtc]

I'm not sure if you've remedied your problem or not, but here's my two cents. We have a rather small amount of bandwidth out here and I've noticed when we conduct conferences (MCU-30, Viewstation FX's, T-Berg 1000's) that one of two things affects it. The faster we connect, the more jitter we tend to get. On top of that, there are other applications competing for overall bandwidth. I've found that running an H.263 IP conference at 192K with 728 audio works just as well, if not better, than our 384K serial conferences.
For the second part about competing bandwidth: I hear my netork nazi's talk about QOS, QOS, and QOS. I've, personally, not noticed a difference on our network with or without.
To make my short story long, I would suggest checking which CODECS you're using (261, 263, 264, 711, 728, 729) and make sure you're using the best for the job. Also, slow and steady wins the race. Keeping the pace down has always made my conferences more stable.

But all that's just my two cents.

[trapehzoid]

if you are getting high jitter when QoS is enabled, I bet your QoS and its buffers need to be tweaked. Jitter is varience between packets.. if your QoS buffers are being hit on and off.. or peaked they could be giving an inconsistant stream, rather then a more steady stream.

[trapped]

You might also want to check the statistics on the local switch port to the MCU for errors. Speed/duplex mismatches can cause all sorts of problems. Depending on the switch you might find that forcing the MCU and switch to 100/full may help.

[Mike Souders]

I hard set all vc gear and they tell me that QOS is enabled. I am having these issues with both the Accord and Radvision systems. Networking keeps telling me that QOS is set. I'm thinking that it may be a bandwidth issue. We have rolled out Cisco IP telephony to a few of the offices now and it gets a higher priority. All of my MCU's and codecs are on their own VLAN. Any thoughts?

[trapped]

Did you also force the switch ports? If you only force the MCU, you can still have a duplex mismatch with the switch. Are you seeing any packet loss? You have QoS packet marking set on both the endpoints and the MCU?

[Mike Souders]

Everything is hard set to 100 FULL - Marking DSCP 46 - Audio and 34 - Video

Cisco Routers and Switches.

Experiencing Packet loss on the transmit end here in Phila. (Tandberg Endpoint) MCU is MGC-100 also in Phila on same VLAN.

Both transmit and receive packet loss in Palo Alto (Polycom FX)

What is really baffling is the packet loss in this building since the MCU and codec are on the same VLAN.

[trapped]

I was working with a customer yesterday and when we forced the speed/duplex only on the endpoint and not on the switch we experienced the same thing. I would double check the port settings on the switches. I have actually also seen cases with the RADVISION MCU where it is better to just go auto on both ends, so you might try that too. Your network folks should also be able to tell you if there are errors on the ports.

[Mike Souders]

Everything is hard set. Codecs/MCUs/Gateways/Switches.

Networking tells me no errors are showing up.

[Harvell]

Sounds like the QoS and the Codec is fine due to the point to point calls and the FX being on the same broadcast domain (VLAN) as the MCU... However the MCU's seem like they have problems either internally or on thier collision domain (network port of MCU to the switch) if the switch admin doesn't see any problems on the port and they are hard set then it's probably ok. If you want to ensure that it is not network at all then put a laptop with Plcms PVX trial version and a cross over cable directly into the network port and place a point to point call with the bridge and see if any errors happen. I have seen both MGC's and Rads show choppy video and video sync errors due to lack of processing power. How are you setting up the conferences? Are the endpoints showing packet loss and high jitter or does the video just look ugly?

[Glen Sykes]

Are you using the MVP module?

If so do you get jitter in voice switched (i.e. conferences that don't use the MVP) as well as CP conferences?

This might sound ludicrous, but I was once advised by Cisco TAC to fix the port speeds on everything but the MVP module, which they adviced to set to auto (and also the corresponding switch port, which should go without saying). I've had no problems at all when my devices are set in this config.

The other thing I'd suggest if you can lay hands on a couple of portable endpoints is place an MCU test call between 2 or 3 endpoints connected to the same switch as the MCU. If the call here is good, then it's likely to be either QoS or another WAN related issue.

Trapezhoid makes a good point, if there isn't enough bandwidth in the QoS queues, the 'overspill' of the video traffic into the best effort queue may be enough to introduce jitter.

[SteveO]

I had the same issues as Glen. Cisco advised setting the swith to auto/auto for the MVP car. Everything else hard set to 100/Full. We then saw issues with the MVP card and the MCU taking different paths in the cloud. When we traceroute the MVP and the MCU, one was traversing ATT and the other MCI. This was creating sync issues when the video arrived at the destination. Just something else to mention the network folks. We are currently running test on this very issue.

Try a voice-activated call and see if you have the same issues as a multipoint continous presence call.

[Mike Souders]

My MVP cards are set to auto per Radvision and Cisco recommendations. Every other piece is hard set on both ends. I am looking to get AGT in here to test my network using their Fathom appliance. MVP calls seem to work best. MP calls tend to freeze or not push video through (blue screen) to some of the sites until multiple retries and sometimes a reboot but that doesn't always work.

[trapehzoid]

any blue screens are from the endpoints.. not the MCU. Polycom viewstations show a blue screen when they don't have video to display.

[David Fourie]

You might have better results putting your VC voice and video to the same priority. Check you are not sharing another queue unexpectedly.

Try using 46 for both audio and video (if the queues are large enough) and check the diffserv tagging for all packets into and out of the MCU and end-points, aswell as into and out of the cloud.

Another thing to check would be to be sure that your packets are not being too heavily fragmented. So check your MTU settings on the bridge modules and end-point match eachother, and are under the MTU set on each router/switch. Try 1400 on your bridge as that is Tandberg's maximum (500 minumum) and their default.

Audio packet size can also effect jitter, on the audio stream at least. I use 40ms in my services as I only use G.722 and G.711 so 40ms fits in nicely.

Stick with hard setting all your ports to 100 Full.

cheers
dave