We have Polycom Video conferencing equipment that supports IP Precedence. We also have Cisco 1720 routers that are connected to an IP VPN WAN over Qwest. Each site has a full T1 Bandwidth to all the other sites on the WAN. We are having HUGE performance issues with 4 or 5 sites on an IP video call. We have set the IP Precedence to 5 on the VC equipment as well as on the Incoming Serial and outgoing Ethernet interfaces on all the routers.
Here is essentially what we did on all the routers:
First create a standard IP access list (in config mode):
access-list 10 permit 10.10.1.4
access-list 10 permit 10.1.9.14
access-list 10 permit 192.168.222.99
access-list 10 permit 10.2.7.109
access-list 10 permit 192.168.133.143
access-list 10 permit 192.168.222.11
access-list 10 permit 10.13.10.136
route-map ipprec permit 10
match IP address 10
set IP precedence 5
ip policy route-map ipprec
ip policy route-map ipprec
But we still have horrible performance. Incoming video frame rates of 1-10 per second. Choppy audio, etc. Any ideas? I can't imagine the server software is causing this much of a problem, and the average Round Trip delay on the Qwest network is at max 150MS. I appreciate any input!
IP Prec alone does not guarantee QoS for video confernecing. IP Prec interacts with protocols on your routing platforms to prioritize certain traffic through queues in the face of network congestion. So while you may have set such on your routers, there is no telling what your SP may have done across their network. You need to speak with your SP about an SLA. Video quality is a function of throughput, packet loss, jitter, latency, etc... So while end-end delay may be no more that 150ms as you describe, if the other variables are not up to minimal standards, you will see performance hits on your video.
Well, I just checked our SLA and this is what is says:
"Qwest's goal is to maintain an average roundtrip POP-to-POP (e.g. VPN Edge Gateway to VPN Edge Gatweway) on-network delay of 75 milliseconds."
I should also point out that this is an SLA for the month. i.e. they are saying that the average delay of 75 millisceonds is based on monthly performance of all the POP-to-POP trunks throughout the month.
If your confident that your network service provider is giving you acceptable performance levels, one last point to check is NIC speed negotiation on your VC units. There is a known issue with some VC endpoints that cannot properly negotiate NIC settings (i.e., 10 vs. 100, half vs. full-duplex). This may cause horrible video performance even on a clean network. Manually setting the NIC or switch port to a specific setting should clear the issue up. Hope this helps...
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...