QoS for VoIP

Answered Question
Jul 15th, 2007

My customer has 2821's and 2811's in a WAN connecting 4 offices with IPSec VPN's over internet T1 lines. They just installed a new NEC phone system that routes calls between offices across the data network. The routers have PVDM2-16 cards installed. QoS is enabled for rtp & rtcp with priority queuing. The call quality is very poor. What am I missing?

I have this problem too.
0 votes
Correct Answer by shikamarunara about 9 years 4 months ago

Mitchell,

Can you post your QOS config for both ends? If your traffic is going over a secure circuit there are special issues to consider since the packets are encrypted and can't be categorized by QOS rules.

-Shikamaru

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Paolo Bevilacqua Mon, 07/16/2007 - 13:43

Hi,

the thing is that over the internet, QoS is not guaranteed ever. Is the quality constantly bad ?

Are they sending much data traffic ? Is the show "show policy interface" demonstrating that QoS is working ?How the NEC system is connected to router ?

mitchell.smith Mon, 07/16/2007 - 21:07

Hi,

Thanks for your help. The call quality is alays bad and this VPN is sending only about 200,000 packets of data per day. The NEC system connects into the switch with 2 ethernet patch cables and the switch connects to the router. I did the "show policy-map interface serial0/0/0" command and it shows no packets with the protocol rtp being handled and it shows only 600 with protocol h323 being handled. I am using these settings:

Protocol= rtp audio, queuing = priority, bandwidth = 21%, DSCP = ef

Protocol = rtcp, h323, queuing = priority, bandwidth = 15%, DSCP = cs3

These values for DSCP are the default, should this be OK? Is the bandwidth high enough?

Thanks!

Correct Answer
shikamarunara Mon, 07/23/2007 - 09:50

Mitchell,

Can you post your QOS config for both ends? If your traffic is going over a secure circuit there are special issues to consider since the packets are encrypted and can't be categorized by QOS rules.

-Shikamaru

mitchell.smith Mon, 07/23/2007 - 11:42

Hi Shikamaru,

Thank you for your help. The traffic, data and voice, is traveling over an IPSec VPN between sites. It does seem the router is not recognizing the rtp and rtcp packets as such. I have attached the QoS config for both ends. Please let me know what you think!

Mitchell

shikamarunara Mon, 07/23/2007 - 12:20

Mitchell,

I'm not sure that I would create my class and policy maps like this (I think it can be done a little neater and make your life easier.) I would make something closer to this;

class-map match-all Voice-RTP

match access-group 100

class-map match-all Voice-Control

match access-group 101

!

policy-map voipqos

class Voice-RTP

priority 1000

class voice-control

bandwidth 16

class class-default

fair-queue

!

access-list 100 permit ip any any precedence critical

access-list 100 permit ip any any dscp ef

access-list 100 permit udp any any range 16384 32776

access-list 101 permit tcp any any range 2000 2002

access-list 101 permit tcp any any eq 2428

access-list 101 permit udp any any eq 2427

access-list 101 permit tcp any any eq 1720

You can define new class and policy maps for the other traffic, but unless you really need to, I'd abstain and keep it in the default class. Focus on how much bandwidth you want to allocate to your voice payload and control traffic ("1000" and "16" in the above example.) Also, the above example makes use of access lists (which seems to be popular in these situations.) You don't need the class map to refer to access lists and can configure the traffic identification within the ssame class map. Like I mentioned, if your voice and data traffic is encrypted before it reaches the QOS'd endpoint, it won't be prioritized because it can't be identified.

I noticed from your output, hoever, that you have multilink groups. This is a BIG deal and you should have packet interleaving configured for those groups. If you don't, you will hear an enoying "clicking" sound on remote site calls.

-Shikamaru

mitchell.smith Mon, 07/23/2007 - 14:12

Shikamaru,

Thanks, this looks like a much cleaner way to do the QoS. I have 2 questions: How do I keep the voice traffic from being encrypted before it has a chance to be prioritized? How do I configure packet interleaving on my multilink groups?

Thanks for all your help!

Mitchell

shikamarunara Mon, 07/23/2007 - 14:21

Mitch,

With regards to prioritizing traffic in this manner, here is an article that can start you out.

http://cisco.com/en/US/products/hw/routers/ps221/products_white_paper09186a00800c69a8.shtml

It does some basic explaining and the method you use to address this issue depends on your set up. Personally, I would start by applying QOS before it hits the VPN tunnel, however this may not be technically correct. It's a good start and, for your particular situation, I would think it would be very easy to implement.

Interleaving is an easier issue to approach. The syntax is straight-forward and applied on the multi-link group. Usually it looks like this;

ppp multilink

ppp multilink interleave

ppp multilink group 1

ppp multilink fragment delay 20

I would look for an article on packet interleaving on cisco.com, there may be other settings that you will need to implement.

-Shikamaru

mitchell.smith Sat, 07/28/2007 - 07:48

Shikanaru,

Thank you again for all your help, the issue is now resolved. Your information on multilink and QoS were both implemented with success. The final piece of the puzzle was a command that must be part of the crypto map as follows:

qos pre-classify

This command forces QoS to be applied before encryption which is vital to the thing working.

Thank you again for taking the time to help us less knowledgeable techs!

Mitchell

nwkotze Mon, 07/30/2007 - 05:05

NEC phone system use G711, 80kbps 50pps.

Can you change to G729 8kbps 50pps.

And Enable Data and RTP Compression using an Compression AIM and an VPN AIM

mitchell.smith Mon, 07/30/2007 - 05:54

Thanks for your post, however the issue has been resolved and no additional changes are needed.

Actions

This Discussion