05-04-2009 08:15 PM - edited 03-21-2019 01:04 AM
I have a UC500 with SIP trunk. I have intermitent voice qualtity problems in the form of broken speech, typically on the far end.
The SIP trunk provider claims the issue is not with him and points to widely varying ping times from his server to my UC500.
The ISP claims he can ping the cable modem consistantly in less that 70ms while the UC500 takes 100-800ms. The ISP will not reveal the IP address of the cable modem (Linksys CM100) so I cannot test this for my self.
The network consists of one phone one PC and one wireless cam so it seems an overloaded connection issue.
How can I find out why my router is doing this?
Thanks!
Solved! Go to Solution.
05-06-2009 01:28 PM
Shaping is definitely kicking in. It would be great if you could try applying the bottom policy map directly (no shaping) to the WAN interface and conduct the same test. Happy to hear we are making progress...
Marcos
05-06-2009 02:45 PM
Thanks Marcos.
I will try applying the bottom policy map directly tomorrow when someone is back at the office for me to test the voiec call with.
Progress is good!...
05-07-2009 12:40 PM
Marcos - anyone:
how do I unattach a policy map to an output/
UC520(config-if)#service-policy output Bottom_Class
Policy map Top_Class is already attached
UC520(config-if)#
thanks,
Matthew
05-07-2009 12:51 PM
You first negate the existing command under the interface (use the "no" keyword in front the command).
Marcos
05-06-2009 10:03 AM
I can see by your 'show policy' that you are not matching any packets against the class maps. I have noticed on my UC520 as well that it does not match packets based on the DSCP value. Can anyone shed some light on this?
In the example config Marcos gave you:
! QoS settings:
class-map match-any VoIP
match ip dscp ef
!
class-map match-any Signaling
match ip dscp cs3
match ip dscp af31
!
Change to:
class-map match-any VoIP
match ip dscp ef
match protocol rtp audio
!
class-map match-any Signaling
match ip dscp cs3
match ip dscp af31
match protocol sip
!
You should then see matches in your 'show policy' command against the 'protocol' statements.
05-06-2009 10:22 AM
thanks cmonks.
I will ask Marcos about this and try it too.
Thanks,
Matthew
05-06-2009 10:43 AM
If there's no congestion, traffic shaping won't kick in. What you are seeing is normal.
Marcos
05-06-2009 11:49 AM
See my policy, there are hits against the protocol matching, but not the dscp matching. DSCP matching doesnt seem to be working on the UC520.
MCC-UC520#sh policy-map int fa0/0
FastEthernet0/0
Service-policy output: shape
Class-map: class-default (match-any)
1994284 packets, 1015310850 bytes
5 minute offered rate 133000 bps, drop rate 0 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/2990/0
(pkts output/bytes output) 1991062/1011190744
shape (average) cir 2000000, bc 8000, be 8000
target shape rate 2000000
Service-policy : queue
queue stats for all priority classes:
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 613607/131272150
Class-map: rtp (match-any)
613607 packets, 131260600 bytes
5 minute offered rate 85000 bps, drop rate 0 bps
Match: ip dscp ef (46)
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol rtp audio
613607 packets, 131260600 bytes
5 minute rate 85000 bps
Priority: 30% (600 kbps), burst bytes 15000, b/w exceed drops: 0
Class-map: sip (match-any)
221 packets, 141573 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp cs3 (24)
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol sip
221 packets, 141573 bytes
5 minute rate 0 bps
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 221/150855
bandwidth 5% (100 kbps)
Class-map: class-default (match-any)
1380457 packets, 883908891 bytes
5 minute offered rate 45000 bps, drop rate 0 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops/flowdrops) 0/2990/0/2990
(pkts output/bytes output) 1377234/879767739
Fair-queue: per-flow queue limit 16
05-06-2009 12:31 PM
Or, are the DSCP values only matched durring congestion?
Here is the output from another system with the same config.
sh policy-map int fa0/0
FastEthernet0/0
Service-policy output: SHAPE
Class-map: class-default (match-any)
3732539 packets, 902484534 bytes
5 minute offered rate 171000 bps, drop rate 0 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/1349/0
(pkts output/bytes output) 3727415/901582275
shape (average) cir 2000000, bc 8000, be 8000
target shape rate 2000000
Service-policy : QUEUE
queue stats for all priority classes:
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 1995547/429891306
Class-map: RTP (match-any)
1995547 packets, 429891306 bytes
5 minute offered rate 129000 bps, drop rate 0 bps
Match: ip dscp ef (46)
391571 packets, 86723722 bytes
5 minute rate 0 bps
Match: protocol rtp audio
1603976 packets, 343167584 bytes
5 minute rate 121000 bps
Priority: 40% (800 kbps), burst bytes 20000, b/w exceed drops: 0
Class-map: SIP (match-any)
1143 packets, 720201 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp cs3 (24)
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol sip
1143 packets, 720201 bytes
5 minute rate 0 bps
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 1143/768207
bandwidth 5% (100 kbps)
Class-map: class-default (match-any)
1735850 packets, 471873295 bytes
5 minute offered rate 44000 bps, drop rate 0 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops/flowdrops) 0/1349/0/1340
(pkts output/bytes output) 1730725/470922762
Fair-queue: per-flow queue limit 16
05-06-2009 12:50 PM
I did some more digging, and starting with 12.4(11)T what you are seeing is expected behavior. It is documented by:
CSCsr39679 Nested class-maps not displaying individual filter level stats
Thanks for insisting here. I wasn't aware of this change of behavior. Notice this is purely cosmetic and does not affect functionality. I know it doesn't help when troubleshooting, but like I said, this is by design.
Thanks a lot,
Marcos
05-05-2009 09:15 AM
Steve,
Yes I am in a BYOB situation.
The ISP is a cable company but does not offer voice in my area and apparently does not offer an SLA type product.
However, the ISP network is very lightly loaded - a grand total of 15 cusotmers.
Again the ISP claims low latency to the cable modem, the problem lies with cable modem to UC500 or the UC500 and associated network.
The CPU is not overloaded as show by an earlier post.
Matthew
05-05-2009 03:13 PM
Hi There,
Is it possible if you can supply some Tracert to various locations? It would be good to see if there is network congestion on your carriers network.
Also if possible provide us with a trace to your SIP provider, it might indicate how many hops it is taking to get to them, ideally you would be best suited being with someone that peers with your carrier so that way the distance of travel is not very far, but i appreciate that this can not happen in the majority of cases.
Cheers,
David.
05-06-2009 10:49 AM
Thanks for the Reply David.
I can't trace through the carrier network but I can trace to the SP's server which is clear over in Washington, DC and I am in Idaho.
Good test to make when I select another SIP trunk SP.
Thanks,
Matthew
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide