Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

VoIP over FR prblem

I have lately implemented VoIP over FR with the

following configuration:

Main Site: Which has Cisco2620, IOS ver 12.2(8)T4, 16Flash/64DRAM and has 2Mbps link with Two pvc's. Site 1 : Which had Cisco 2610, IOS ver 12.0(22), 16Flash/64DRAM and has 2Mbps link with one PVC connected to the main site. Site 2 : Which had Cisco 2610, IOS ver 12.0(22), 16Flash/64DRAM and has 128Kbps link with one PVC connected to the main site. All sites has FXS ports installed.

First i have done the configuration by using config maker, with a correct dial plan and found that i have an unknown sounds comes out when i dial any phone to any other.

I tried to apply QoS to the connections but i have two strange issues:

First: When i tried to use the sub-interface command which is ip rtp reserve 16384 16383 32 on the 2620 router it came back to me with an error says IP RTP: Not enough bandwidth: available 0 needed 32. which i did not find it on any cisco documentation.

Second: As stated at a lot of Cisco documents that i have to lower the mtu for better voice quality, i did so but whenever i hear nothing at all.

On all cases i have just something like (PLA PLA PLA PLA) coming on the channel although the dial plan is correct and my colleges could hear the phone ringing on other sides.

Also, i have another thing that does not look right to me, which is that if i raised the mtu to a value more than 960, the connection drops.

Can you help me solving this situation, i need your help as soon as you can.

And Also if you have a sample of such a configuration that you can provide me with, please send it to me.

Cisco Employee

Re: VoIP over FR prblem

You've got a number of issues at play here:

1. You're going to want to use Frame-Relay Traffic Shaping to ensure that you aren't dropping any packets in the WAN cloud/WAN switches.

2. You should be using LLQ (Low Latency Queuing with CBWFQ). This is the preferable way to configure WAN QOS for Voice. I don't believe this available in 12.0(22), which you are running at your remote sites. So "ip rtp reserve..." is the way to go. I suspect you are getting the "Not enough bandwidth" because you've oversubscribed the link. Ensure that you have specified the "bandwidth" command under all main and sub-interfaces--ip rtp reserve takes these bandwidth settings into account when being configured. Also, you can only "reserve" up to 75% of the WAN bandwidth (unless you use the "max-reserved-bandwidth" command -- NOT recommended!)

3. I strongly advise that you don't adjust MTU values on your WAN. This should only be done in very special cases. Instead, you should do Frame-relay fragmentation and interleaving (FRF.12). This not only ensures that you won't get small voice packets queued behind bigger data packets, but also ensures that data and voice packets are interleaved ensuring voice doesn't incur large amounts of delay. Again, I assume that 12.0(22) doesn't support FRF.12, so you may have to stick with adjusting MTU. If so, ensure that you have the MTU configured the same on each end of the WAN link.

I've included some pertinent configuration pieces below (! indicate explanatory comments). Note this is for a single 512K pvc:


! Class-map to match mission-critical data marked with IP precedence 2

class-map match-all mission-critical

match ip precedence 2

class-map match-all control

! Class-map to match Voice control traffic marked with IP precedence 3

match ip precedence 3

class-map match-all voice

! Class-map to match Voice RTP traffic marked with IP precedence 5

match ip precedence 5

policy-map llq-remote-512k

! Voice strict priority class providing priority for 45% of WAN/pvc bandwidth

class voice

priority 218

! Voice control class providing queuing for 10% of WAN/pvc bandwidth

class control

bandwidth 49

! Data mission-critical class providing queuing for 20% of WAN/pvc bandwidth

class mission-critical

bandwidth 97

! Default class providing queuing for remaining 25% of WAN/pvc bandwidth

class class-default


! Main WAN interface

interface Serial0/0

no ip address

encapsulation frame-relay

! Enables frame-relay traffic-shaping

frame-relay traffic-shaping

frame-relay lmi-type cisco

interface Serial0/0.1 point-to-point

bandwidth 512

ip address

frame-relay interface-dlci 202

! Apply Frame-relay traffic shaping map-class

class remote-512k

! The following map-class provides Frame-relay traffic shaping, fragmentation, and LLQ/CBWFQ and is attached to the Frame-relay pvc(s)

! via the "class " command under the DLCI (see above).

map-class frame-relay remote-512k

! Traffic-shaping to 95% of actual CIR--in this case 512000. Both CIR and MINCIR are shaped to this

frame-relay cir 486400

frame-relay bc 1000

frame-relay be 0

frame-relay mincir 486400

! FRF.12 Frame-relay fragmentation and interleaving

frame-relay fragment 640

no frame-relay adaptive-shaping

! Applies LLQ/CBWFQ service-policy for output traffic to the frame-relay traffic-shaping map class

service-policy output llq-remote-512k


Remember that the above should be configured on both sides of your WAN link to ensure proper operation.

For more information on QOS design for Frame-relay WAN links, checkout: