We run a CCP center with MGCP some of our remote sites are having QOS issues (voicemail sounds garbaled to an outside caller, static, jitter, slowness response from the phone). I have configured Auto QOS on every switch port/trunk port, also configure LLQ on the edge MPLS router. When I do a show Policy-map int, I show my priority queue passing voice packets because I can see the packet count incrementing with no drops. Also, on some of our sites the MPLS circuit is usually 90-100 utilized through out parts of the day. I checked with our provider and our "gold" queue is passing traffic without drops as well. Does anyone have any ideas what else I can do to improve the quality of our voice network?
It is essential that your QoS policy conforms to that of your provider's.
You may be marking and classifying QoS accordingly with the LAN, however this may not correlate to your providers policy. Thus traffic maybe incorrectly queued.
For example, providers will typically be using PHB for DSCP marking, they will be using four distinct AF classes and an EF class.
Therefore you need to ensure that your voice and signalling are being marked correctly at your trust boundary, and secondly that your provider can identify packet matches for these classes within their policy.
If you are experiencing voice quality issues, ensure that you have not over provisioned your CUCM location bandwidth to that of your LLQ in your policy-map.
I do not suspect that this is your problem, as you stated there are no packet drops in your gold queue, providing EF is marked correctly. The same applies to your signalling.
Are you trusting CallManager/Unity switchports for DSCP?
Are you using priority queueing on your IP Phone switchports and between your trunk ports within you LAN if any, and trusting COS?
Do you have local PSTN break at your remote site, or only across the WAN through your central site?
Is it possible to forward your remote site gateway/LAN config?
Configure your CCM/Unity switchport configuration with auto-qos also, this will configure srr on the interface, and set the trust to dscp.
You should also trust DSCP on your L3 P2P interfaces not COS.
I have noticed that you are matching either DSCP or ACL. Once you have configured the appropriate trust on your L3 ports and you are still experiencing issues, I would recommend isolating any classification issues.
Therefore I would initially remove the match dscp from each class-map, and classify based on ACLs only. This will ensure that despite where your trust boundary is, all traffic will remarked.
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...