videoconferencing QOS

[rvincent]

My customer is doing video conferencing with PictureTel 960 & 680 series units across a pt-to-pt T-1 link. He is using 768K of the T-1, via 2600 routers, for his data traffic.

The picture quality becomes choppy when anyone moves. He claims there is "mimimal" data traffic but I would still like to put QOS on his routers. Can someone tell me which form of QOS would be best to use.

thanks

Rob

[s-dean]

Hi,

you can try with custom queue:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_c/qc

prt2/qcdcq.htm

I don't know if you have other better choices.

Or you can also try with priority queueing.

Bye

Stefano

[psavaete]

Rob,

I've seen that behaviour many times before. It's definitly a bandwidth/performance problem. Have you also checked the CPU load of the 2600 on the moment of these symptoms. A T-1 is hardly capable of handling a 768K call as there is no room for 'bursts' when updating a full screen, nor for the header (and other) overhead. Have you checked what the actual LAN bandwidth is during the problem; When updating full screens during movement large VC data packets are send over which also may get stuck in the queue after small 'normal' data traffic. I would recommend to lower the VC to 512K or 384 and see if the problems stay. QoS will help, but I doubt that it will solve all your problems. I recommend priority queueing. Use the QoS of the VC terminals (IP Precendence 4). Depending on the switches used in the network you can reclassify the stream (to IP precendence 4 or DSCP AF41) and change the TOS.(delay) Use the Proxy/GK to make sure that only the VC stream gets in the priority queue. Using multiple queues is beneficial for the delay sensitive applications. LLQ is good. Note: do not forget to provision your PQ 20% higher than the actual VC Data rate

regards

Philip

[rvincent]

Philip:

The VC is running at 384K. They have adjusted it to every optional setting down to 64K with no change to quality. I am going to set priority queuing using the ip addresses of the servers via an access list rather than the ip precedence. Do you see any problem with that ?

Customer removed his LAN from the router and ran the VC with no change to quality so problem may not be QOS related. I'm noticing many errors on his T1 link so problem may be there.

Rob

[aglowack]

The best method is to classify the traffic on the PictureTel unit (IP Prec.4), create a priority queue on the router for traffic marked with IP Prec 4, and provision the correct amount of bandwidth. If your call data rate is 768k you should plan on adding about 15-18% for IP overhead. You will need to take into account that other "non authorized" video units can get into the PQ if the packets are marked with IP Prec 4 and that will cause major problems for the authorized user.

Building the queue is one thing, but if you can't deny access to that queue once the provisioned bandwidth is used you have accomplished nothing. With gatekeeper bandwidth controls and use of the proxy for secure queue access this is easily accomplished.

[zabriskis]

I am an SE with Polycom / PictureTel. If you are on a pure Cisco network and have implemented RSVP I woudl suggest you upgrade to the latest software on the PictureTel systems, 3.0, since they support RSVP. For the 680 it is available on the support web site (support.picturetel.com) for the 900 it is an OS upgrade to Windows 2000 and requires a CD and license. Contact your reseller for that.

The other option is to implement Cisco MCM on the network that prioritizes H.323 traffic on a network. The only caution with that is it uses a proxy and the Cisco proxy strips the iPower CAPS exchange (known issue and being worked on) so you do not get any of the iPower features. Thus right now RSVP is better.