[cisco-voip] QoS help

Mon Mar 19 14:20:41 EDT 2012

stated alternatively, does any phone colocated with ccm have any issues with vq when using software media resources such as MTP or CFB?  stream statistics from the phone (ii, ??, qrt, or cmr records) would help quantify any anomalies in the RTP stream.  If your CMR records show consistent poor audio at that remote site then you have a much stronger pointer to the culprit.

On Mar 19, 2012, at 11:56 AM, Erick Wellnitz wrote:

CPU is bleow 20% on all nodes.  Network utilization isn't out of the ordinary either.

On Mon, Mar 19, 2012 at 10:26 AM, Wes Sisk <wsisk at cisco.com> wrote:
generally you should deplete mtp resources before voice quality impact. software MTP utilizes network I/O and CPU utilization. we've rarely seen VQ issues caused by sw mtp/cfg but it's not unheard of. if you're using sw media resources then verify the network interface for the CUCM server. 

On Mar 16, 2012, at 3:03 PM, Erick Wellnitz wrote:

This is unreal.  They tell me it's fixed and tested...but two hours later we get more complaints.

These guys have me starting to doubt myself.  CM software MTP wouldn't be causing QoS-like issues, would it?  What about if an SIP trunk with "MTP required" checked and we run out of media resources?  

On Fri, Mar 16, 2012 at 9:48 AM, Erick Wellnitz <ewellnitzvoip at gmail.com> wrote:
There was an incorrect QoS setting on a different switch on the remote end.  Problem solved.

I'll save my gripes about groups not talking to each other for another day.  ;)

On Thu, Mar 15, 2012 at 4:10 PM, Erick Wellnitz <ewellnitzvoip at gmail.com> wrote:
I'm not a LAN/Ethernet QoS guru by any means.  Our network group has control over QoS and I'm trying to get to the bottom of an issue we've seen routing calls over a sip trunk to a location using a 1gig Ethernet connection on a DWDM ring.  No firewall is present.  The configuration doesn't seem quite right to me for some reason.

Basically what we are doing is using an alternate PSTN gateway for toll free traffic until we get additional capacity added to handle the calls.  Users report garbled audio and an 'underwater' quality of the audio.  Getting information from the phone on call quality (jitter, etc) may not help because the calls complained about are to an external conference bridge via tol lfree number.

If this config checks out, I plan to ask the network team if they can capture some data for this particular link.

Here is the local end QoS config:

mls ip cef load-sharing full

mls netflow interface

mls qos map cos-dscp 0 8 16 24 32 46 48 56

mls qos

mls cef error action reset

interface GigabitEthernet3/43

description GIG 3/43

ip address X.X.X.X X.X.X.X

ip flow ingress

ip pim sparse-dense-mode

ip summary-address eigrp 1 X.X.X  X X.X.X.X

ip summary-address eigrp 1 X.X.X  X X.X.X.X

ip summary-address eigrp 1 X.X.X  X X.X.X.X

load-interval 30

wrr-queue bandwidth 30 40 30

wrr-queue queue-limit 40 30 15

wrr-queue threshold 2 60 80 100 100 100 100 100 100

wrr-queue threshold 3 60 80 100 100 100 100 100 100

wrr-queue random-detect min-threshold 1 40 60 80 80 80 80 80 80

wrr-queue random-detect max-threshold 1 70 80 100 100 100 100 100 100

no wrr-queue random-detect 2

no wrr-queue random-detect 3

wrr-queue cos-map 1 3 0

wrr-queue cos-map 2 1 1

wrr-queue cos-map 2 2 2

wrr-queue cos-map 2 3 4

wrr-queue cos-map 3 2 3

wrr-queue cos-map 3 3 6 7

mls qos trust dscp

Here is the remote end:

interface GigabitEthernet1/36

description GIGABIT E/NET 1/36

ip address X.X.X.X  X.X.X.X

ip flow ingress

ip pim sparse-dense-mode

load-interval 30

no wrr-queue random-detect 2

no wrr-queue random-detect 3

wrr-queue cos-map 1 3 0

wrr-queue cos-map 2 1 1

wrr-queue cos-map 2 2 2

wrr-queue cos-map 2 3 4

wrr-queue cos-map 3 2 3

wrr-queue cos-map 3 3 6 7

mls qos trust dscp

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20120319/9a4fae73/attachment.html>