video has jerky motion

[bphelps]

I've got a client who installed some VCON units. They conference over a WAN which is two sites with frame relay T1s to the internet. There is a VPN tunnel performing GRE through IPSEC that the video goes through. Regular office traffic and voice over ip traffic traverse this link also. The voice sounds great and office traffic appears unaffected. Video traffic is jerky. I've assigned the video traffic a share of the priority queue used by the voice.

When I decrease the bandwidth from 512 kbps to 128 kbps there is no noticable correlative diminishing of jerkiness.

I am seeing a fragmentation error on one of the routers, and it only occurs when the video is being used. Unfortunately I don't have the exact error to post as an example. Regardless, the jerkiness is visible on both VDON units.

I suspect that fragmentation or packet order issues are a problem since bandwidth doesn't seem to play into the picture. This problem occurs even if no one else is in either office.

[scottmac]

Try reducing the MTU. The additional overhead of the encryption, coupled with the fact that most encryptions don't tolerate fragmantation well may be causing you to drop frames (can't frag? drop the frame).

Most video codecs send variable length information, depending on the amount of motion ... some packets/frames may be small ("talking head") or fairly large (complete image change).

By reducing the maximum size of the packet/frame, you keep it within a size that can be passed without fragmentation.

Good Luck

Scott

[william.su]

The jerkiness keeps staying there no matter there's a motion or not.

[dmitry]

First of all, make sure that during the encryption of GRE you are not getting the IPSec traffic fragmented. If it is the case then the remote router that decrypts traffic would first send the IPSec fragments to the CPU (process switching) to reassemble the IPSEC packets and only then starts decrypting them. This problem is most noticeable when you are using a hardware encryption but with software encryption it will cause additional work for CPU to reassemble the packets. The way to avoid this is to make sure that the packets are fragmented before getting into the GRE tunnel, so the remote video unit and not the remote router can take care of the reassembly: lower the IP MTU size on GRE interface to around 1420 from the default 1476 (usually the video endpoints do not set DF bit but if it is not the case, apply a policy-map on the ethernet intf to reset the DF - even with policy applied the traffic should stay on fast switching path, if not change to the IP route-cache policy on the Ethernet/GRE). The ideal case would be avoiding the fragmentation at all, the Tandbergs with latest SW can set the MTU size of video traffic they generate, I'm not sure about VCON.

I had another problem when the endpoint itself had difficulties reassembling the packets (Accord video bridge), so in this case it would accept only unfragmented packets, all the fragments would be dropped and you will get jerky image

[sachon]

Video "jerkiness" not associated with b/w issues usually results from excess jitter in the which may overrun jitter buffers that may exist in video endpoints. Source could be serialization delay in your topology - Cisco recommends running video on FR ports at 768k or higher only - or latency that results from encryption you are running.