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?
Solved! Go to Solution.
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 ?
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?
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!
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
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.
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!
With regards to prioritizing traffic in this manner, here is an article that can start you out.
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 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.
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:
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!
This may not answer your qtn but I hope the following URL will be of some use even if it helps you to understand the possible causes a bit better.
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