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.
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
! Voice strict priority class providing priority for 45% of WAN/pvc bandwidth
! Voice control class providing queuing for 10% of WAN/pvc bandwidth
! Data mission-critical class providing queuing for 20% of WAN/pvc bandwidth
! Default class providing queuing for remaining 25% of WAN/pvc bandwidth
! Main WAN interface
no ip address
! Enables frame-relay traffic-shaping
frame-relay lmi-type cisco
interface Serial0/0.1 point-to-point
ip address 10.98.1.194 255.255.255.252
frame-relay interface-dlci 202
! Apply Frame-relay traffic shaping map-class
! 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:
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...