HiddenOne

IP Telephony is something that every network administrator is going to run into at some point in time. Its many features really do help reduce costs across the board. Having a unified network that carries voice and other data services reduces cabling, equipment, and maintenance costs just to name a few. Even with the popularity of IP telephony there are many organizations out there they have yet to take the plunge. This further increases chances that you will find yourself working as part of a telephony project at some point.

If your company has a network with all Cisco devices and a Cisco IP telephony system has been chosen, everything seems straightforward. Cisco is going to make sure their products work well together; otherwise they’re going to have a tough time marketing their telephony system to current Cisco customers. Concerns arise when you have a mixed vendor environment. Will it work? How do the switches need to be configured?

If you have an HP Procurve based network, Procurve has you covered with their interoperability guides. These guides detail how to get phones from various vendors to work with Procurve networking equipment. The guides are very detailed covering configuration of the phones, the switching equipment, and even Call Manager (In the case of Cisco). Each section of the guide includes screen shots of any web interfaces as well as command prompt output you may encounter along the way.

If you are planning to run an IP telephony system on top of HP Procurve gear, these guides will be your source of knowledge more than a few times!

Thanks to “procurvehelp” on Twitter for posting a link to these documents!

Network jitter, or jitter, is the name given to a variation in the time delay between packet arrival. This concept is better explained using the illustration below.

In the above illustration, the gaps between each of the packets represent the time it takes for each packet to reach the destination. Jitter is shown by the uneven gaps between packets two and three, as well as three and four.

In a perfect world, every packet should arrive at a set amount of time after the preceding packet. In reality, there are many factors to take into consideration when jitter is experienced. Sometimes the cause of jitter is beyond your control, since issues may arise outside your network.

The effect Jitter has on network applications can vary. It is unlikely for a user surfing the internet to report a problem that is a result of jitter. Other real time services, such as VOIP, can experience serious problems related to jitter. Lucky for us, many vendors (including Cisco) build provisions into their routers that can compensate for jitter.

On Cisco routers, the playout delay buffer (PDB) is the mechanism that is used to compensate for jitter. The PDB stores the incoming packets and then sends them to the next destination as a steady stream. This buffering process is similar to that used with other real-time protocols such as those used for audio and video. The ultimate goal of the buffer is to negate any jitter by relaying the packets as a steady stream. An illustration of the packets before and after the playout delay buffer does its job is shown below.

The buffer can only compensate for packets that are delayed within a specified range. If packets start to arrive outside of the working range of the buffer, those packets are dropped. With VOIP a dropped packet can mean the loss of some of the audio, which can make part of a conversation seem choppy.

In a Cisco router, the playout delay buffer sends a steady stream of packets to the digital signal processors. The main job of the DSP is to convert the audio from digital to analog. A secondary function of the DSP is to compensate for missing packets. If a packet is missing, the DSP can make an educated guess as to the contents of the missing packet and insert that missing piece into the audio stream. The result is that the end user never hears a difference. The DSP can only compensate for a finite amount of dropped packets before the end users start to notice an effect on call quality.

Jitter can present some interesting problems, particularly when you are dealing with real-time services. Cisco has built some provisions into their routers to help counter some of the effects of jitter.

In the first part, I detailed how to get the CME basic and GUI files from your computer to your router. In this part of the series, I will detail how to enable the GUI as well as setting up authentication for the GUI interface.

Note: All commands should be issued in global configuration mode unless otherwise noted.

The first step is to enable the web (http) server on the router:

ip http server

Next, you need to tell the web server where to find the HTML files used by the GUI:

ip http path flash:

Finally, you need to tell the web server which form of authentication to use:

ip http authentication {aaa | enable | local | tacacs}

Below is a quick run down of the authentication methods.

• aaa – Use aaa login service.
• enable – Uses the enable password that is set on the router (This is the default authentication method).
• local – Uses a local username and password that is set on the router using the username command.
• tacacs – Uses a TACACS server.

Before you can access the CME GUI, you need to set an initial username and password for the administrator. The following commands will allow you to do this.

Enter telephony service configuration mode:

telephony-service

Set the GUI administrator username and password:

web admin system name username {password string | secret {0 | 5} string}

With the last command it is suggested that you use the secret 5 option, since it will encrypt the password using an MD5 hash.

Once you have completed all of these steps you should be able to access the CME GUI from a web broswer by navigating to http://xxx.xxx.xxx.xxx/ccme.html (relace xxx.xxx.xxx.xxx with the IP address of your router). You will be prompted for a username and password, which should be the one you just set with the web admin command.

Note: I had some problems with the GUI when viewing it with Firefox (2.0.0.14). It’s suggested that you used Internet Explorer.

This only covers a very small portion of CME configuration. I suggest that you consult the Cisco Unified Communications Manager Express Administrator’s Guide. It is very detailed and worth the time spent reading though it.

Over the past few days I have been installing Callmanager Express (CME) and the CME GUI on my newly aquired 2610XM. One thing that frustrated me before now was the lack of documentation on how to get started with the CME installation. My hopes are that this will provide people with enough information to get started.

Right now, I have only done a very basic configuration of CME. I do not have any IP Phones connected or anything. There will be further posts that will cover more advanced configuration topics.

There are a few things that you need in order to run CME. They are as follows:

1. An IOS version that has CME support (Use the Cisco Feature Navigator to see if your IOS supports CME).
2. CME basic files. This is related to the IOS version you have. The Cisco download page will tell you which CME basic file you should download for your version of IOS.
3. CME GUI files

Before proceeding, consult the CIsco CME Matrix. You can look at the version of CME you wish to run and the IOS version you wish to run it on. The matrix will tell you if it is possible to run that version of CME with the version of IOS you have. If you click on the specifications link for each version you will find the the minimum required DRAM and Flash needed to run CME.

The first step is to upgrade your IOS, if you need to. After that, you are ready to start uploading the CME files to Flash. This can be a bit tedious since there are so many files. After some suggestions from a member on Networking-Forums, I have found a process that saves you a bit of time.

1. Extract both the CME basic and CME GUI archives into a single folder on your computer.
2. Repackage the extracted files (except .tar files) into a new tar file (7-Zip is free and can create tar files in Windows). It is very important not to package other .tar files in this new archive, since tar files need to be individually uploaded and extracted on the router.
3. Use the following command to upload and extract each tar files you need (I usually start with the tar file I just created):

   archive tar /xtract tftp://xxx.xxx.xxx.xxx/file.tar flash:/

You should repeat the last step for each tar file you need. Some files you may not need, such as those for phones you will not be using, or one for the ACD feature.

That should be the basics of getting the needed files onto your router. In the second part I will detail how to enable the GUI interface and setup authentication for the interface.