Scenario is we have installed Call managers at Delhi (Rohini) Location it is central location for all over India through WAN link, the issue i am facing is we have installed IP Phones in Okhla (delhi) which is connected through WAN to the call managers in Rohini.The problem is when a call made from rohini to Okhla IP phone then Okhla guy is able hear voice through IP phone but at rohini side Voice is clipping..(voice is not clear)
we have checked there is no issue with the bandwidth also n/w is also clear (no firewall restrictions)......What it is....can anybody help????
But i have found one more thing that whenever i am pinging my server (call managers) from okha through WAN i am getting ping response b/w 85% and 90% but if i ping any other application server from okhla i m getting 100% response .So this could be an issue......
It could be an issue but remember that call setup traffic (SCCP on TCP port 2000) goes from phone to server and call payload traffic (RTP on UDP ports between 16384 and 32768) flows directly between phones. If you are hearing clipping then it suggests a problem with payload rather than signalling.
It would be a good idea to resolve the server PING issue first though. I would start by checking that the server and switch to which it connects have matching speed and duplex settings.
If you are running a Linux version of CUCM (6x or higher), the irregularity in ping response is actually normal. We have observed this on numerous systems. Pings from the same LAN are all acknowledged and you'll see 100% response. However, pings over WAN, VPN, etc (i.e., another network/subnet/etc) will occassionally be dropped. This is discussed in the SRND I believe as it is essentially a mechanism used to avoid a remote DoS attack.
You have to approach this issue by trying to determine the scope (harken back to James' original reply, +5 James). From your OP, you said that when two phones are talking to each other, one phone has good audio while the other does not. Taking this in the most literal sense means that either something is wrong with the phone exhibiting the issue or the network path from the remote party to the phone where the clipping is present.
To determine Scope, you have to look for common patterns:
1. Is the issue only one phone? If so, the issue is that particular phone. Maybe the handset, cord, something silly or something bad like a corrupt DSP. It could also be the switch port the phone is connected to. Check for interface errors, check duplexity, check speed.
2. If it is more than one phone:
- Is it all phones in one site?
- Is it just one model of phone?
- Is it just phones on a particular switch?
- Is it just phones on a particular switch module?
It would also be a good idea to understand time and frequency of the issues in question.
In regards to the "ping" timeouts from the CUCM. Hailey brings up a good point (+5 to the H man) in that you cannot rely on ping to give you an idea of what to expect from call signaling or RTP media. IOW, if QoS is setup correctly the pings from your CUCM nodes to a remote, non-voice node would be best effort, while signaling and media use a higher priority traffic class. The SRND recommends that you use the closest network device to the CUCM nodes for any ICMP testing. Using extended ping commands you can also force a type of service (using 3 and 5 will map you to the appropriate DSCP values if you are following Cisco best practices).
That being said, I wouldn't go to this nebulous ping testing and qos checking level just yet. Check your physical layer first. If the issue is impacting one phone. Look at the phone, the cables, the handset, and the switch port. If it is more than one phone and you can localize to an area on your network. Look at the uplink(s) from this portion of the network and the next layer 2 and/or layer 3 hop in the network. If the issue is one-way only, you may want to look at fiber connections between devices. While copper connections could exhibit the same issue, it is much easier for one of the fiber strands to be damaged in some way.
Check interface counters on all inter-switch/inter-device connections. You are looking for line errors. If your environment is small, this will be quick. If it is large, you may want to look at network management tools and/or sed/awk/etc..
If the physical layer pans out, then start looking at your QoS. Check the config first. 9 out of 10 times the config is just wrong and it is easier to look than to checks statisics and then look. Once you look and find the config is straight, then start looking for queue drops.
With the little info we have so far, I am leaning to physical layer issue of some type.
I'm not able to access my old voice mail messages all of a sudden. The recording says something like 'the message is currently not available'. This has never happened before in all the years I have been using this system. I have t...
If you have 2 ISR routers, one acting as Failover, do we need to have both the same number of SRST licenses on the 2 routers?
No. You will only need the SRST licenses on the primary router. Because this feature...