IP Phone and Bandwidth Issue over WAN

[J2NoomSai_2]

We use IP phone at our branch office which talk to HQ's via 3T1 multilink. QoS is configured on both PTP routers and it's working fine on normal traffic. But when there is a spike (over75% bandiwdth) it effect the voice quality. What is the best practice to avoid that problem not to effect Voice traffic even though when there is a spike. We dont' have voice VALN setup though.

Thanks

[paolo bevilacqua]

Either your QoS is not configure properly, or it is not working correctly. Spikes in traffic should not affect voice quality.

[Nicholas Matthews]

Try applying this:

class-map voice

match protocol rtp audio

policy-map simple-voip

class voice

priority percent 60

class class-default

fair-queue

interface WAN 0/0

service-policy outbound simple-voip

-nick

[J2NoomSai_2]

What I have on our router is

class-map match-any CALL_SIGNALING

match ip dscp cs3

match ip dscp af31

class-map match-all VOICE

match ip dscp ef

!

!

policy-map WAN

class VOICE

priority percent 33

compress header ip rtp

class CALL_SIGNALING

bandwidth percent 1

class class-default

fair-queue

interface Multilink1

service-policy output WAN

Is that QoS proper configure?

[Nicholas Matthews]

That looks about right. I would check a few things:

1) That your packets are actually marked EF.

2) 'show policy map interface' doesn't show drops on the voice class. If so you need to increase your percentage.

hth,

nick

[J2NoomSai_2]

Thanks Nick for repling. I think so far qoS is ok. I might just increase percentage when there is a spike.

Class-map: VOICE (match-all)

151453587 packets, 18581102426 bytes

5 minute offered rate 488000 bps, drop rate 0 bps

Match: ip dscp ef (46)

Queueing

Strict Priority

Output Queue: Conversation 264

Bandwidth 33 (%)

Bandwidth 1528 (kbps) Burst 38200 (Bytes)

(pkts matched/bytes matched) 4169372/427211972

(total drops/bytes drops) 0/0

[Nicholas Matthews]

From this, it looks like it's not your QOS that is the problem.

Either you may be looking at it on the wrong side of the WAN connection, or something before or after this connection is dropping the packets. This looks clean.

-nick