Posts Tagged ‘CallManager’

Cisco CallManager Vulnerabilities

Cisco announced this week that their Cisco Unified CallManager and Cisco Unified Presence Servers are vulnerable to remote attacks by using specially crafted ICMP and UDP packets. Cisco has already released patches for them, here.

CallManager servers, which process VoIP calls on a network, can be crashed by sending attack traffic to TCP ports 2000 or 2443 to the server; these ports are used by Cisco’s proprietary call control protocols ? Skinny Call Control Protocol (SCCP, or “Skinny”) and Secure SCCP. This vulnerability exists in CallManager versions 3.x, 4.x and 5.0 (CUCM 6.0, the latest version (announced this month), is not affected, nor is the Presence Server).

Cisco says CallManager and the Presence Server are affected by attacks involving floods of ICMP Echo Requests (pings), or specially crafted UDP packets. The ping-flood vulnerability, which affects only CallManager 5.0 and Presence Server 1.x, could be used to crash call-processing or presence services on the respective servers.

The UDP vulnerability affects the IPSec Manager Service on CallManager and Presence Server, which uses UDP Port 8500. With this less severe vulnerability, an attack could not stop calls from being placed or received on a Cisco VoIP network, but could cause the loss of some features, such as the ability to forward calls or deploy configuration changes to clusters of CallManager and Presence Servers. Source: Cisco VoIP and presence servers vulnerable to new attacks

If you don’t want to load the patches yet, you can block these things at your router on the outside connections to your networks.

Permit TCP Port 2000 (SCCP) and TCP Port 2443 (Secure SCCP) to CallManager systems only from VoIP endpoints.

ICMP Echo Requests, Type 8, should be blocked for CallManager and Presence Server systems (although this could affect network management applications and troubleshooting).

UDP Port 8500 for IPSec Manager should be permitted only between CallManager/Presence Server systems configured in a cluster deployment.

The Register says,

CallManager versions 3.3, 4.1, 4.2 and 5.0, as well as Presence Server version 1.0, are affected by a number of security bugs. The vulnerabilities involve unspecified errors in the handling of large amounts of ICMP Echo packets and within IPSec Manager service, both of which might be used to launch denial of service attacks against vulnerable Cisco Unified CallManager and Presence Server software installations.

A separate bug means that CallManager software PBX systems might be taken down by port scanning. Source: Cisco wraps up against VoIP DoS bugs

Be the first to comment - What do you think?  Posted by Jimmy Daniels - March 30, 2007 at 7:25 pm

Categories: Cisco, VoIP   Tags: , , , , ,

Cisco CallManager VOIP Tips

Here are some great CallManager Tips from a word document I found on Cisco’s site, here, I have posted some of the ones I needed here, hit the Word doc for the rest.

Time Synchronization – Time synchronization is simply making sure that all the participating CallManager servers and network devices have the same exact time.
All the CallManager servers can be time-synched using the Network Time Protocol (NTP). When you synchronize the time on all involved servers, all the trace files are time stamped the same. When trace files are collected for analysis, you can follow the true series of call processing events with accuracy.
In addition to CallManager servers, you should ensure all network devices such as switches, routers, and voice gateways are synchronized to the same time source as the CallManager servers. This ensures consistent timestamps regardless of which device you are looking at.

IP Phone Tips

IP Phone Won’t Register – Skinny client registration problems are usually caused by a misconfiguration on CallManager, the DHCP server, one or more network devices, or the IP phone itself. Follow these steps when you encounter an IP phone that doesn?t register properly with CallManager:

Step 1 Check for inline power issues.

Step 2 Check IP addressing and DHCP.

Step 3 Check for IP network connectivity.

Step 4 Check for Trivial File Transfer Protocol (TFTP) problems.

Step 5 Check for CallManager issues.

If you have checked for inline power issues and verified that the IP Phone has the correct information, but it still doesn?t register, you need to do some additional investigating. Here are some common reasons why registration fails at this point:

The CallManager service is not running.
The IP Phone can?t reach CallManager. Try to ping the IP Phone from the CallManager server it is trying to register. This will confirm bi-directional IP connectivity.
If NAT, firewalls, or access lists are in use, be sure to check there as well to make sure that traffic is not being blocked, thus preventing proper communication. Skinny devices use TCP port 2000 to register with CallManager.
If the IP Phone must resolve the CallManager name to register, a failure could occur if the DNS server is inaccessible or the DNS entry is incorrect. Generally it is a good idea not to rely on DNS at all. To use IP addresses instead of DNS names, configure the servers in the cluster by IP address in CallManager Administration (System > Server).
The IP Phone firmware load specified by CallManager is not in the TFTP path. If the IP Phone load currently running on the phone is not compatible with the CallManager the phone is trying to register to, the registration might fail. Ensure that the IP Phone is running the firmware version specified in CallManager Administration (System > Device Defaults).
If the IP Phone has never been entered into the CallManager database via CallManager Administration, CallManager does not allow that phone to register unless auto-registration is enabled. Auto-registration does not work unless it has available directory numbers to provide the registering IP Phone a DN. If the IP phone is not configured in CallManager Administration and auto-registration is not enabled or CallManager has run out of DNs, the phone displays ?Registration Rejected.?

Voice Quality Tips

Working with Low-Speed Links – Jitter is more likely to occur on low-speed links because even a single packet in the queue on a low-speed link can dramatically affect the amount of time a voice packet needs to wait in the queue before being transmitted. Jitter can be an even bigger problem if you do not have priority queuing (that is, Low Latency Queuing [LLQ]) enabled on your WAN connections or if you have it misconfigured. It is essential that voice traffic get absolute priority over any data traffic. For more information on using LLQ to prioritize voice samples over data, refer to the Cisco IP Telephony QoS Design Guide, available on (search for ?Cisco IP Telephony QoS Design Guide?) or at the following link: here.

If you are seeing high amounts of jitter over a low-speed link, it?s quite likely that improperly configured LFI is the problem. This is assuming that you are not oversubscribing the WAN link with more voice traffic than what you are prioritizing with your QoS policy. For more information on how to configure LFI, refer to the Cisco IP Telephony QoS Design Guide.

Packet Drops

One common cause of drops in an Ethernet environment is a duplex mismatch. Check all the switch ports through which a given call must travel, and ensure that there are no alignment or frame check sequence (FCS) errors. Alignment and FCS errors are usually a sign of a duplex mismatch?that is, when one side of a connection is set to full duplex and the other is at half duplex. To check for duplex mismatches, look at each link between the two endpoints experiencing packet loss and check to make sure the speed and duplex settings match on either side. For more information about troubleshooting duplex mismatches, refer to the Cisco document ?Configuring and Troubleshooting Ethernet 10/100/1000Mb Half/Full Duplex Auto-Negotiation? at the following URL:

Troubleshooting Problems with One-Way or No-Way Audio

One-way audio and no audio at all (no-way audio) are problems that are fairly common during a new IP telephony network installation. The majority of these problems are caused by misconfigurations. For one-way audio problems, always pay attention to which direction the one-way audio is occurring. For no audio in either direction, the troubleshooting methodology is the same. You might need to repeat the procedure for each direction of audio, but more likely you will find the source of the problem when trying to troubleshoot one direction. There are various steps you can take to troubleshoot a one-way/no-way audio problem:

Verify bidirectional IP connectivity
If using an H.323 gateway, make sure you have voice rtp send-recv configured
Check for NAT or firewall restrictions

No Ringback on an IP Phone When Calling the PSTN

One common problem is lack of ringback tone when dialing out to the PSTN from an IP phone. The problem in this scenario is that CallManager automatically cuts through audio to the H.323 gateway as soon as the logical channel signaling is complete. The problem arises because the alerting message sent by the PSTN does not contain a progress indicator indicating that in-band information is available. Typically in an end-to-end ISDN environment, the end device is responsible for locally generating ringback upon receiving an alerting message. Unfortunately, CallManager does not operate this way. It relies on inband ringback when calling out an H.323 gateway. To fix this problem, configure progress_ind alert enable 8 under the POTS dial peer that gets matched for this call?s outbound call leg. For some reason, this command is hidden in some versions of Cisco IOS software, but if you enter it, the gateway accepts it, and it shows up in your configuration.

As soon as this is configured, Cisco IOS Software treats an alerting message as if it came in with a progress indicator of 8. A progress indicator of 8 means that in-band information is available, so the gateway cuts through audio upon receiving an alerting message. There are several other progress indicator values (detailed in Chapter 6 of Troubleshooting Cisco IP Telephony).

Gateway Tips

No Ringback on a PSTN Phone When Calling an IP Phone

When a Cisco IOS gateway receives a setup message without a progress indicator, it does not play ringback toward the PSTN. This is because the gateway assumes that the PSTN is end-to-end ISDN and therefore handles playing ringback to the originating device upon receiving the alerting message. If the network is not end-to-end ISDN, the setup message should arrive with a progress indicator of 3, indicating that the origination address is non-ISDN. In the case of a failure, the device on the PSTN does not send a progress indicator.

To resolve this problem, you need to configure the gateway to play ringback toward the PSTN regardless of the progress indicator in the setup message. To accomplish this, configure progress_ind setup enable 3 on the VoIP dial peer that is being matched for this inbound call. Note that even though you are trying to fix a problem with ringback on the POTS side, this parameter must be configured on the VoIP dial peer. If you have multiple VoIP dial peers that might be matched, be sure to put the command under all of them.

No Ringback When Transferring a Call

Another common ringback problem is the lack of ringback toward the PSTN user when an IP phone user transfers a call to another phone. The reason for this is a limitation of the H.323 protocol as it is implemented on the gateways and in Cisco IOS.

To get around this limitation, a solution is in place as of Cisco IOS Software Release 12.2(3) and later. This solution also requires CallManager 3.0(8) or later. To get it to work, make sure you are running the correct version of Cisco IOS Software, and make sure the ToSendH225UserInfoMsg service parameter is set to True. In CallManager 3.2(3) and later, this service parameter accepts a numeric value of 0, 1, or 2 instead of True or False.

These values mean the following:

0?Do not send any progress tone information.
1?Use the H225UserInfo message to send progress tone information.
2?Use the H225Info message to send progress tone information.

CallManager versions prior to 3.2(3) do not understand receiving these messages in the H225Info message, so for backward compatibility with CallManager clusters prior to 3.2(3), use a value of 1 (True). Otherwise, choose a value of 2. As long as you have met these conditions, you should get ringback on transfer.

Media Resource Tips

Out-of-Resource Conditions

One common reason for both conferencing and transcoding problems is a lack of DSP resources to perform the required function. This could occur either because you have run out of conference bridge or transcoder resources or because the device that requires the resource does not have any available in the MRGL it has been configured with.

Failures to allocate a media resource can be seen in CCM traces and are also logged in PerfMon and RTMT by the OutOfResources counters for Music on Hold, Transcoder, and Conference Bridge in the Cisco CallManager performance object.

1 comment - What do you think?  Posted by Jimmy Daniels - March 15, 2007 at 7:52 pm

Categories: Cisco, VoIP   Tags: , , , , , , ,