Cisco Unified CallManager

One problem many engineers stumble upon is the routing of incoming calls which have their caller-id blocked.  In these cases, quite a few telcos send Anonymous instead of N/A as the Calling Party Number (the number that is calling us), instead of the typical N/A string:

By default, all CUCM versions from version 6 and above will automatically reject calls when Calling Party Number set to Anonymous, making it impossible for callers with hidden ID to successfully call the company.

Solutions To Stop CUCM From Rejecting Anonymous Caller-IDs

One solution is to request the Telco to replace the Anonymous Calling Party Number with a specific numeric string. Possibilities of this happening, are quite slim.

Another solution is to convert your MGCP Voice Gateway to H.323. This will allow the usage of translation patterns for all incoming calls, and manually changing Anonymous to whatever is required to ensure the call is not rejected.

The final solution is to dive into each Directory Number (DN) and un-tick the Reject Anonymous Calls option, under the Directory Number Settings section. The Reject Anonymous Calls feature is enabled by default and will cause CUCM to reject all anonymous incoming calls:

When done, simply click Save and your done! Simple - Fast and Effective!

Voice over IP (VoIP) is not just need of hour for most enterprises; it’s something their business depends on to a degree that without IP communications in place, their business processes and revenue streams will fall apart. In such case, it goes without saying; security of voice networks is one of the chief concerns when it comes to security of intellectual capital and customer data. More often than not, one of the first thoughts is how to secure the VoIP network itself which is leveraged by IP Telephony / Unified Communication (UC) applications.

So what is that may be the most commonly sought after yet elusive security control which plays an indispensable role in securing a VoIP network? Your guess is as good as mine, it is encryption! Now, you are well within your rights to ask why elusive? The simple answer is – where encryption can help you succeed and protect the privacy of communications, it can also be detrimental for various functions / organizations e.g. monitoring secure calls is not a trivial task and encrypting all endpoints has an impact on platform sizing and performance.

The use of authentication and encryption helps protect confidentiality and makes it harder for malicious insiders or outsiders from tampering with the signaling and media streams, the CUCME router, and IP phones. When the CUCME security features are enabled i.e. the media streams (SRTP) and call signaling (TLS), the communication between Cisco Unified IP phones and CUCME as well as Phones is encrypted as shown in figure 1:

Figure 1 - CUCME to Cisco IP Phone SRTP and TLS

Let’s go over some of the assumptions, requirements and caveats before we dwell further into CUCME security configuration.

Assumptions For CUCME Encryption

• It is assumed that CUCME is configured and operational (without security in place); this article only serves to elucidate the process of implementing authentication and encryption on the CUCME
• It must also be understood that authentication is an integral part of overall security construct when the discussion is around encryption since; authentication provides integrity whereas encryption provides privacy. 

Requirements For CUCME Encryption

• Enabling CUCME encryption requires Cisco IOS feature set Advanced Enterprise Services (adventerprisek9) or Advanced IP Services (advipservicesk9)

• CUCME version 4.2 or later is require to provide media encryption

• Supported platforms include 2800, 2900, 3200, 3800, and 3900 series routers

• Network Time Protocol (NTP) must be enabled to ensure the certificate dates are correct and to check validity of certificates

• IOS CA to sign various certificates (on same router as that of CUCME or different router

Caveats For CUCME Encryption

• Secure three-way software conference is not supported therefore, while in conference, the call falls back to plain RTP. However, if a party drops from a three-party conference, the call between the remaining two parties returns to a secure state (if the two endpoints are configured for encryption)

• Media and signaling encryption requires the Cisco CTL client service

• Calls to Cisco Unity Express (CUE) do not support SRTP or TLS for media and signaling respectively

• Music on Hold (MOH) does not support encryption

• Modem relay and T.3 fax relay calls not support encryption

• Secure CUCME does not support Session Initiation Protocol (SIP) trunks and only H.323 trunks are supported (with IPSec for signaling protection)

With above in mind, let’s take a deep dive into the enablement of security (Encryption, Authentication) for Cisco Unified IP Phones on CUCME.

Enabling SRTP & TLS On CUCME For Endpoints

Alike any PKI hierarchy, enabling encryption (and authentication) on CUCME requires the use of a Certificate Authority (CA) server/process. CA can be configured on the same router on which CUCME application is running or it can be a different IOS router (dedicated to CA function in an organization). The major function of CA for CUCME security is to provide certificates, duration for which certificates are valid, and trust-relationship between different entities by virtue of certificates.

 Configuring IOS Certificate Authority (CA)

The following commands are required to configure the IOS CA. For the following example, we are enabling the CA on the same router as that of CUCME.

First we must ensure that the HTTP server on the router is enabled since, by default port 80 (TCP) will be used for granting certificates and for accepting certificate signing requests by IOS CA.

Now, we need to configure the CA process and enable CA process:

Finally define the CA trustpoint and define (globally) enrollment URL:

At this time, we are done with CA server definition. Next step is to start defining the various certificates which will be used for CUCME security processes (CME, TFTP, CAPF and so on).

Generate Certificates For Enabling Security

A number of certificates must be generated by creating a trustpoint and enrolling it with the CA for enabling various security processes on CUCME. Although CUCME supports leveraging a single trustpoint for all certificate functions, it is a leading practice recommendation to have different trust points for different certificate functions so, it is easier to manage different certificate expiry, revocation, regeneration and so on.

The different certificates required for SRTP and TLS are:

• CUCME
• TFTP
• CAPF
• SAST tokens

Creating a Certificate For CUCME, TFTP, CAPF, SAST1 & SAST2 Processes

Following commands outline the process to generate the certificate for the secure CME function:

The next step to creating the certificate is to authenticate and enroll the trust point with the Certificate Authority.

Note: Each of the command i.e. trustpoint authenticate and enroll provide interactive prompts. Extraneous output has been omitted

Authenticating CUCME trustpoint & Enrolling CUCM Trustpoint:

 Next, we define the other trsutpoints, authenticate and enroll them with Certificate Authority.

TFTP Trustpoint definition:

CUCME(config)# crypto pki trustpoint TFTP
CUCME(ca-trustpoint)# enrollment url http://10.10.10.1:80
CUCME(ca-trustpoint)# revocation-check none
CUCME(ca-trustpoint)# rsakeypair TFTP

 Authenticating and enrolling TFTP trustpoint:

CUCME(config)# crypto pki authenticate TFTP
<output omitted>
!
CUCME(config)# crypto pki enroll TFTP
<output omitted>

 CAPF Trustpoint definition:

CUCME(config)# crypto pki trustpoint CAPF
CUCME(ca-trustpoint)# enrollment url http://10.10.10.1:80
CUCME(ca-trustpoint)# revocation-check none
CUCME(ca-trustpoint)# rsakeypair CAPF

 Authenticating and enrolling CAPF trustpoint:

 SAST1 Trustpoint definition:

 Authenticating and enrolling SAST1 trustpoint:

CUCME(config)# crypto pki authenticate SAST1
<output omitted>
!
CUCME(config)# crypto pki enroll SAST1
<output omitted>

SAST2 Trustpoint definition:

CUCME(config)# crypto pki trustpoint SAST2
CUCME(ca-trustpoint)# enrollment url http://10.10.10.1:80
CUCME(ca-trustpoint)# revocation-check none
CUCME(ca-trustpoint)# rsakeypair SAST2

Authenticating and enrolling SAST2 trustpoint:

CUCME(config)# crypto pki authenticate SAST2
<output omitted>
!
CUCME(config)# crypto pki enroll SAST2
<output omitted>

Enabling CAPF server on CUCME
Alike CUCM, Certificate Authentication Proxy Function (CAPF) server is accountable for issuing CTL signed Locally Significant Certificates (LSC). Following commands enable CAPF server on CUCME.

CUCME(config)# capf-server
CUCME(config-capf-server)# trustpoint-label CUCME
CUCME(config-capf-server)# cert-enroll-trustpoint CA password 0 cisco123
CUCME(config-capf-server)# phone-key-size 1024
CUCME(config-capf-server)# port 3084
CUCME(config-capf-server)# auth-mode null-string
CUCME(config-capf-server)# source-addr 10.10.10.1

Invoking IOS CTL Client 
The final step, before an e-phone can be configured for encryption and authentication is to enable Certificate Trust List (CTL) client on CUCME. CTL client helps sign the list of servers which can be trusted by a Cisco IP Phone with the certificates generated earlier – CUCME, TFTP, CAPF and so on.

The IP Phone will download the CTL file via TFTP and store the file on the phone. This is analogous to CUCM CTL and CTL client must be configured explicitly on IOS leverage the various certificates.

Configuring Telephony-Service To Leverage Security

CUCME support configuring endpoints for SRTP (media) and TLS (signaling). Once, the aforementioned steps are concluded, CUCME needs to be configured to use the defined certificates for different functions. The following commands in telephony-service mode helps enable authenticated TFTP file transfer and TLS for signaling.

Configuring Endpoints (E-Phones) For Security

The final step is to configure the e-phones for security mode. Now, there are two ways to configure the e-phones for security mode. Those two ways are as follows:

• Configure e-phone (device) security at global mode for all supported phone models
• Configure e-phone (device) security mode on a device by device basis

Configuring Device Security at Global Level
To enable security at global level in CUCME for all Cisco IP Phones which support encryption and authentication, issue the following commands in global configuration mode:

Configuring Device Security per Device Basis
In certain cases, it may be required to apply encryption to some, authentication to other devices, and no security to the rest of the phones. In such case, for each e-phone commands can be entered at e-phone level, on phone by phone basis.

Following series of commands can issued to enable security on phone by phone basis:

CUCME(config)# ephone 110
CUCME(config-ephone)# mac-address 1234.1234.1234
CUCME(config-ephone)# device-security-mode [none | authenticated | encrypted]
CUCME(config-ephone)# cert-oper upgrade auth-mode null-string
CUCME(config-ephone)# reset

About the Author

Akhil Behl is a Solutions Architect with Cisco Advanced Services, focusing on Cisco Collaboration and Security Architectures. He leads collaboration and security projects worldwide for Cisco Advanced Services and the Collaborative Professional Services (CPS) portfolio. Prior to his current role, he spent ten years working in various roles at Linksys as a Technical Support Lead, as an Escalation Engineer at Cisco Technical Assistance Center (TAC), and as a Network Consulting Engineer in Cisco Advanced Services. Akhil has a bachelor of technology degree in electronics and telecommunications from IP University, India, and a master’s degree in business administration from Symbiosis Institute, India.

Summary

Cisco Unified Communications Manager Express (CUCME) is an indispensible component of Cisco’s UC Express portfolio and has CUCM like capabilities. Moreover, CUCME can provide enterprise wide security by empowering you to enable media and signaling encryption between CUCME and Phones. This article outlines the capabilities of CUCME to support encryption and authentication for phone calls and signaling. The process to enable and pull together CUCME security may seem daunting at first however; it is a onetime configuration and can go a long way in safeguarding an organization’s voice channels.

• Getting started
• Understanding your phone lines and buttons
• Using the keypad, buttons and menus
• Using the Cisco Attendant Console
• Connecting your IP phone to the network
• Updating firmware
• Phone functions (calling, volume, call-on-hold, live call, call pick-up, phone directories, call history lists, transfering calls and much more)
• Advanced phone functions (pairing SPA525 with bluetooth device, mobile phone battery and signal info on your SPA525, playing mp3 files, play lists and more)
• Configuring IP phone screen (contrast, brightness, wallpaper, screensaver)
• Viewing network information
• ...and much more!

Download your free copy by visiting the Firewall.cx Cisco Small Business Series Product Datasheet section.

• Getting the IP phones to work with the Cisco SPA900 IP PBX
• Network Configuration
• Determining and Upgrading your IP phone firmware
• Web-Based Configuration Utility - Allowing web-access to the IP phone
• Configuring Line Key (shares-lines, call appearance, access services, busy lamp, call-pickup, speed dials and much more)
• Customizing the IP phone (background image, screen save, LCD brightness, backlight settings)
• Enabling Call Features ( Caller ID Bocking Services, call-back service, call transfer, conferencing, do-not-disturb)
• Customizing phone softkeys
• Configuring ring tones
• Configuring audio settings
• Configuring Bluetooth (Cisco SPA525G / SPA525G2 only)
• Enabling SMS
• Configuring LDAP for Cisco SPA300 and SPA500 series IP phones
• Configuring SIP (Basic parameters, RTP parameters, SIP settings)
• Managing NAT Transversal with Cisco IP phones
• Configuring Security, Quality and Network Features
• Configuring VLAN settings
• Configuring Dial Plans (Digit Sequences, examples, off-hook timers and more)
• and much more!

To download the Cisco Small Business Administration Guide for Cisco SPA500 series IP phones, simply visit our new Cisco Small Business Series Product Datasheet download section.

• 7906 & 7911
• 7910
• 7912
• 7914
• 7915
• 7916
• 7920
• 7921
• 7925
• 7926
• 7931
• 7935
• 7936
• 7937
• 7940 & 7960
• 7941 & 7961
• 7942 & 7962
• 7945 & 7965
• 7970 & 7971
• 7975
• 7985
• 8941 & 8945
• 8961
• 9951
• 9971
• ATA-186
• ATA-187
• ATA-188

When initiating a factory reset procedure certain information from the IP phone is erased while other information is reset to its factory default value as shown in the list below:

 Information Erased:

• CTL File (Certificate Trust List)
• LSC File (Locally Significant Certificate)
• IP Phone Call History (Calls Received, Placed, Missed etc)
• Phone application

Information Reset to Default:

• User configuration settings (ring tone, screen brightness, sound levels etc)
• Network configuration settings

It is highly advisable to follow the firmware upgrade procedure in a non-working environment to ensure other phones are not affected (in case of an accidental IP phone reboot) and to avoid the freshly factory reset ip phones obtaining the working environment’s settings.

Things To Consider Before Factory Resetting Your Cisco IP Phone

When performing the factory reset procedure we are about to describe, it is important to keep in mind that the IP phone will lose all configuration files and phone applications. This means that it is necessary to have CallManager or CallManager Express setup so that the IP phone will be able to receive the new information (phone application and configuration) after the reset procedure is complete, otherwise it is most likely  that the IP phone will not be usable until this information is loaded on to it.

This preparation also happens to be the procedure for upgrading a Cisco IP phone firmware.

Performing the Factory Reset On Cisco 7940, 7960 IP Phones

Follow the steps below to successfully factory reset your Cisco 7940, 7960 IP phone:

1. Unplug the power cable from the ip phone and then plug it back in.
2. Immediately press and hold # and when the Headset, Mute and Speaker buttons begin to flash in sequence, release the # button.
3. At this point, you’ll notice the Headset, Mute and Speaker buttons flash in sequence, indicating that the ip phone is waiting for you to enter the reset sequence.
4. Press 123456789*0#  to begin the reset. If you accidently press a key within the sequence twice e.g 1123456789*0#, the ip phone will still accept the code and begin the reset. If an invalid key is pressed, the phone will continue its normal startup procedure.
5. Once the correct key sequence is entered, the ip phone will display the following prompt:  Keep network cfg? 1 = yes 2 = no 
6. To maintain the current network configuration settings for the phone when the phone resets, press 1. To reset the network configuration settings when the phone resets, press 2. If you press another key or do not respond to this prompt within 60 seconds, the phone continues with its normal startup process and does not reset. Otherwise, the phone goes through the factory reset process.

Performing The Factory Reset On Cisco 7941, 7961 IP Phones

Follow the steps below to successfully factory reset your Cisco 7941, 7961 IP phone:

1. Unplug the power cable from the ip phone and then plug it back in.
2. Immediately press and hold # and when the Headset, Mute and Speaker buttons begin to flash in sequence, release the # button.
3. At this point, you’ll notice the Headset, Mute and Speaker buttons flash in sequence, indicating that the ip phone is waiting for you to enter the reset sequence.
4. Press 123456789*0#  to begin the reset. If you accidently press a key within the sequence twice e.g 1123456789*0#, the ip phone will still accept the code and begin the reset. If an invalid key is pressed, the phone will continue its normal startup procedure.
5. Once the correct key sequence is entered the ip phone will display the following prompt and begins its reset process:  Upgrading

Performing The Factory Reset On Cisco 7942, 7962 IP Phones

Follow the steps below to successfully factory reset your Cisco 7942, 7962 IP phone:

1. Unplug the power cable from the phone and then plug it back in. The phone begins its power up cycle.
2. While the phone is powering up, and before the Speaker button flashes on and off, press and hold #. Continue to hold # until each line button flashes on and off in sequence in amber.
3. Release # and press 123456789*0#.

You can press a key twice in a row, but if you press the keys out of sequence, the factory reset will not take place.

After you press these keys, the line buttons on the phone flash red and the phone goes through the factory reset process.

Do not power down the phone until it completes the factory reset process and the main screen appears.

Performing The Factory Reset On Cisco 7920 Wireless IP Phone

To reset a Cisco 7920, the ip phone must be started in administration mode using the following steps:

1. Press the Menu softkey
2. Press * (star), # (hash) and * (star) again.
3. Press the Green phone key (used to answer a call) to open the administration mode.

Note: Power cycle the phone or press any of these keys while in the first level submenu and then press the Green phone key to hide the options:

• any key between 0 and 9
• * (star) key
• # (hash) key

Follow the steps below to successfully factory reset your Cisco 7920 IP phone:

1. Choose Menu > Phone Settings > Factory Default.
2. The phone displays the Restore to Default? message. Press the OK softkey. All settings are deleted.
3. Choose Menu > Network Config in order to reconfigure the network settings for your WLAN.

This completes the factory reset procedure for all Cisco 7940, 7941, 7942, 7960, 7961, 7962 and 7920 IP phones.

Upgrading your Cisco IP phone firmware is a very simple process, however special consideration must be taken into account when upgrading to the latest firmware.

If the Cisco Unified IP phone is currently running firmware earlier than 6.0(2) on and you want to upgrade to 8.x(x), you must first install an intervening 7.0(x) load to prevent upgrade failure.

Cisco recommends using the most recent 7.0(3) load as the intervening load to avoid lengthy upgrade times.

If the Cisco Unified IP phone is currently running firmware 6.0(2) to 7.0(2) and you want to upgrade to 8.x(x), you can do so directly. However, expect the upgrade to take twice as long as usual.

Step 1: Download The Correct Firmware

To download Cisco IP Phone firmware from Cisco.com, a valid Cisco CCO account is required. In most cases, the firmware file name is something similar to the following:  cmterm-7945_7965-sccp.9-2-1.tar.  From the file name, we can understand that this is firmware version 9.2.1, for Cisco 7945 and 7965 SCCP IP phones.

Step 2: Upload Firmware Files To CallManager Express Flash Storage

Next, the firmware must be uploaded and unpacked on our CME router. For this, we’ll need a TFTP server running on a workstation, plus access to the CME router.  From the CME prompt, we instruct the router to download the firmware and unpack it onto our CME flash:

When complete, the system’s flash should contain all 8 files as shown above.

Step 3: Configure The CallManager Express TFTP Server To Serve The Firmware Files & Setup DHCP Server (option 150)

Now we must configure CME’s tftp server to ‘serve’ these files so that the IP phones can request them.  This is done by adding the following commands to the router’s configuration:

We also must ensure there is a valid DHCP server running with option 150 set to CME’s IP address. When the IP phone boots up, it will look for a DHCP server that will provide it with an IP address, but also expect to find DHCP option 150 which designates the CME the phone should try to register with:

ip dhcp excluded-address 10.0.0.1  10.0.0.15
!
ip dhcp pool Firewall.cx
 network 10.0.0.0 255.255.255.0
 dns-server 10.0.0.1 8.8.8.8
 default-router 10.0.0.1
 option 150 ip 10.0.0.1

The above configuration excludes IP address ranges 10.0.0.1 to 10.0.0.15 from being handed out by the DHCP server. It also creates a DHCP scope named Firewall.cx and configures various self-explanatory parameters including the critical DHCP option 150, which represents the CME the IP phone should try to register to.

Step 4 – Configure CallManager Express To Use New Firmware Upon Next IP Phone Bootup

The final step involves configuring CME to use the new firmware and instruct IP phones to download it. This is done by issuing the following commands under the telephony-service section of CME:

The load command is followed by the phone type and associated firmware (.load) file. Notice we do not add the .loadof the filename at the end of the command.

The create cnf command instructs CME to recreate the XML files that will be used by the IP phones to download all necessary network parameters and force it to check its firmware and begin downloading the new one.

This completes our article on configuring Cisco CallManager Express for Cisco IP Phone Firmware upgrade.

Our example network assumes there is a direct connection between the two CallManager systems via leased line as shown in the diagram below:

Engineers who wish to establish a VPN connection instead (via Internet) can refer to the following popular VPN articles:

• Configuring Point-to-Point GRE VPN Tunnels on Cisco Routers
• Configuring Site to Site IPSec VPN Tunnel Between Cisco Routers

The above network diagram was designed using GNS3 in a simulated environment consisting of two CallManager clusters, one at the Headquarters (CUCM) with an IP Communicator client (CIPC_HQ) assigned with extension 2002 and at the remote branch we have a CallManager Express system with an IP Communicator client (CIPC_BR) with extension 5010.

To simplify things, our CME router is directly connected with the Headquarters router (CUCM_HQ), providing a path for us to reach the main CallManager (192.168.10.11).

While CallManager (Headquarters) requires a voice gateway to make and receive calls on the PSTN/ISDN network (Telco Providers), it is not a requirement for intra-site communication.

We assume no configuration exists on the CME router and basic configuration on CallManager.

Configuring CallManager Express or UC500 Series System

Following is the CallManager Express router configuration covering its LAN and WAN configuration:

The h323-gateway voip interface and h323-gateway voip bind srcaddr commands define the source interface and IP address for all h323 protocol communications and is necessary to ensure VoIP communication with CUCM.

Next, we enable the CallManager Express service and configure our single IP phone (IP Communicator) that will be used for our test:

The CallManager Express service is enabled via the telephony-service and the important ip source-address subcommand, which defines the source IP address of the CallManager Express system. In case the CME router has multiple interfaces connected to various networks (VLANs), we set the source IP address to be that of the Voice VLAN, so the CME router will use the correct interface (and therefore source IP address) to communicate with its clients (IP phones).

Finally, all that is left is to configure a dial-peer that would direct all calls to CallManager at our Headquarters. This is done by using dial-peers as shown below:

This dial-peer instructs CallManager Express to forward any calls made to any four digit number starting with 2, e.g. 2000, 2452, 2900 etc, to IP address 192.168.10.11, our headquarters CallManager.

Dial-peers are an essential ingredient to managing outgoing and incoming calls and will be covered in greater depth in another article.

This completes our CallManager Express configuration. We are now ready to move on to our CallManager configuration

Configuring CallManager (CUCM)

Configuring CallManager involves a number of easy-to-follow steps as outlined below. As shown in the network map, we've assigned extension number 2002 to the IP Communicator connected to the system. This phone will be accepting incoming calls from the remote CallManager Express system.

First step is to check that the Cisco CallManager and Cisco TFTP Server are activated. This can be done by visiting Cisco Unified Serviceability > Tools > Service Activation as shown below:

Here we will need to enable the mentioned CM Services by selecting them and clicking on Save.

If IP Communicator is not already connected and registered to CallManager, we can automate this process by going to Cisco Unified CM Administrator > System > Cisco Unified CM Configuration:

Here, uncheck the box Auto-registration Disabled on this Cisco Unified Communications Manager. This will allow any IP phone (CIPC - IP Communicator in our case) to register and automatically assign them an extension.  This is a very easy and painless method to register IP phones on a CallManager system.

Now to configure CIPC with extension 2002, we go to Device > Phones > Add New> Phone Type  and select Cisco IP Communicator.

Next, go to Device Name (Select the MAC address of CIPC), and for the field Softkey Template select Standard CIPC SCCP:

Scrolling down the page, you'll come across the SUBSCRIBE Calling Search Space field. Click on it and select Cisco IP Communicator:

Click on save then choose Directory Number Configuration, enter 2002 or desired extension then reset the phone to allow the successfuly registration of CIPC with CallManager:

Setting Up H.323 Gateway on CallManager

With the IP phone registered we now need to setup the H.323 gateway.

Setting up an H.323 gateway in CallManager is a straightforward process. From the main menu, select: Device > Gateways > Add New > Gateway Type  and select H.323 Gateway.

When selecting the H.323 Gateway, we need to provide a bit more information until it is usable by the system. 

In the field Device Name and Description, enter the IP address of the remote CME system, 192.168.20.1.

Next, click on the Device Pool field and select Default.  Finally cick on Save and Reset to have the changes take effect:

Configuring CallManager Route Group, Route List & Route Pattern

Our next step is to configure a Route Group, Route List and finally Route Pattern. This is a similar process to CME's dial-peer confguration but it's slightly more complicated in CallManager.

From the main menu, go to Call Routing > Route/Hunt > Route Group > Add New > Add Available Device and select the newly created H.323 Gateway. Click on Add To Route Group then click on save.

Now we go to Call Routing > Route/Hunt > Route List > Add New > Name, we used Route to 5xxx to help distinguish this route list. In the Cisco Unified Communication Manager Group drop-down option select Default then click on Save.

Right below we see the Route List Member Information section. Here we click on the Add Route Group button:

At the new screen select the Route Group field and choose WAN Devices-[NON-QSIG], then click on Save:

Finally we configure the Route Pattern. Go to Call Routing > Route/Hunt > Route Pattern > Add New > Route Pattern and enter 5XXX.  The pattern "5XXX" is similar to CallManager Express's "2..."  and will match any four digit number starting with 5.

Below, at the Gateway/Route List, select Route to 5xxx and uncheck Provide Outside Dial Tone. Finally, click on Save:

At this point CallManager has been configured to route all 5xxx extensions to the remote CallManager Express system and both systems should be able to communicate with each other.

About The Author

Mohammad Saeed is a guest writer on Firewall.cx,  freelancer and Video trainer, who loves working with Cisco techologies. As a CCNA & CCNP certified engineer, Mohammad works with small and medium size networking projects and helps students and network engineers to understand Cisco topics.

According to Cisco, when initiating a factory reset procedure certain information from the IP phone is erased while other information is reset to the factory default value, as shown in the list below:

Information Erased:

• CTL File (Certificate Trust List)
• LSC File (Locally Significant Certificate)
• IP Phone Call History (Calls Received, Placed, Missed etc)
• Phone application

Information Reset to Default:

• User configuration settings (ring tone, screen brightness, sound levels etc)
• Network configuration settings

It is highly advisable to follow the firmware upgrade procedure in a non-working environment to ensure other phones are not affected (in case of an accidental reboot), and to avoid the freshly factory reset ip phones obtaining the working environment’s settings.

Cisco IP phone SCCP firmware files version 9.2.1 for 7945, 7965 & 7975 IP phones (latest version at the time of writing this article) are available at our Cisco IP Phone & ATA Firmware Download section. For our example, we used version 9.1.1.

Firewall.cx readers can visit our free Cisco IP Phone & ATA Firmware Download section to freely download the latest available firmware for their Cisco IP phones.

Things To Consider Before Factory Resetting Your Cisco IP Phone

When performing the factory reset procedure we are about to describe it is important to keep in mind that the IP phone will lose all configuration files and phone application. This means that it is necessary to have CallManager or CallManager Express setup so that the IP phone will be able to receive the new information (phone application and configuration) after the reset procedure is complete, because it is likely the IP phone will not be usable until this information is loaded.

This preparation also happens to be the procedure for upgrading a Cisco IP phone firmware.

Configuring CallManager Express (CME) For IP Phone Firmware Upgrade

Upgrading your Cisco IP phone firmware is a very simple process. Special consideration must be taken into account when upgrading to the latest firmware.

If the Cisco Unified IP phone is currently running firmware earlier than 6.0(2) on and you want to upgrade to 8.x(x), you must first install an intervening 7.0(x) load to prevent upgrade failure.

Cisco recommends using the most recent 7.0(3) load as the intervening load to avoid lengthy upgrade times.

If the Cisco Unified IP phone is currently running firmware 6.0(2) to 7.0(2) and you want to upgrade to 8.x(x), you can do so directly. However, expect the upgrade to take twice as long.

Step 1 – Download the Appropriate Firmware

To download Cisco IP Phone firmware a valid Cisco CCO account is required. In most cases, the firmware file name is something similar to the following:  cmterm-7945_7965-sccp.9-1-1.tar.  From the file name, we can understand that this is firmware version 9.1.1, for Cisco 7945 and 7965 SCCP IP phones.

Step 2 – Upload Firmware to CallManager Express

Next, the firmware must be uploaded and unpacked on our CME router. For this, we’ll need a TFTP server running on a workstation, plus access to the CME router.  From the CME prompt we instruct the router to download the firmware and unpack it onto our CME flash:

When complete, the system’s flash will contain all 8 files extracted above.

Step 3 – Configure The CallManager Express TFTP server to serve these files & Setup DHCP Server (option 150)

Now we must configure CME’s tftp server to ‘serve’ these files so that the IP phones can request them.  This is done by adding the following commands to the router’s configuration:

We also need to ensure there is a valid DHCP server running with option 150 set to CME’s IP address. In our example, this is IP address 10.0.0.10. When the IP phone boots up, it will look for a DHCP server that will provide it with an IP address, but also expect to find DHCP option 150 which designates the CME the phone should try to register with:

The above configuration excludes IP address ranges 10.0.0.1 to 10.0.0.15 from being handed out by the DHCP server. It also creates a DHCP scope named Firewall.cx and configures various self-explanatory parameters including the critical DHCP option 150, which represents the CME the IP phone should try to register to.

Step 4 – Configure CallManager Express to use new Firmware on Next IP Phone Bootup

The final step involves configuring CME to use the new firmware and instruct IP phones to download it. This is done by issuing the following commands under the telephony-service section of CME:

The load command is followed by the phone type and associated firmware (.load) file. Notice we do not add the .loadof the filename at the end of the command.

The create cnf command instructs CME to recreate the XML files that will be used by the IP phone to download all necessary network parameters and force it to check its firmware and begin downloading the new one.

When our IP phone next reboots, it will download the latest firmware installed on the CME router and begin the upgrade process.

Performing the Factory Reset on Cisco 7945, 7965, 7975 IP Phone

Follow the steps below to successfully Factory reset your Cisco IP phone:

1. Unplug the power cable from the ip phone and then plug it back in.
2. While the phone is powering up, and before the Speaker button flashes on and off, press and hold the hash # key.
3. Continue to hold # until each line button (right of the LCD screen) flashes on and off in sequence in orange colour.
4. Now release the hash # key and type the following sequence 123456789*0#

After the sequence has been entered the line buttons on the phone flash orange, then green and the phone goes through the factory reset process. This process can take several minutes and the firmware of the IP Phone will be erased.

When complete, the IP phone will reboot and the bootloader will try to obtain an IP address via DHCP. The IP phone also expects the IP address (option 150) or the name (option 66) of the TFTP server to be delivered by the DHCP server. This is why these DHCP options are critical at this phase.

The phone then tries to obtain the appropriate termXX.default.loads file depending in its model:

• term75.default.loads - Cisco 7975
• term65.default.loads - Cisco 7965
• term45.default.loads - Cisco 7945

This "loads" file indicates all the files the IP phone has to download from the TFTP server to make up the device firmware. The IP phone should first obtain the “loads” file and then proceed with the individual files. Once complete, the IP phone will install the files and finally reboot

Below is a screenshot of our 7945 IP phone during the firmware upgrade process:

The IP phone should now be ready for use with the new IP phone firmware installed.  The firmware can be verified by going to the phone Settings / Model Information menu option, where the load file installed is shown:

This article explained how to perform a factory reset for Cisco IP phones 7975, 7965 & 7945 models. We saw what information is lost during the reset, how to configure Cisco CallManager Express TFTP Server so that the updated SCCP firmware is automatically loaded on the IP phones and how to verify the IP phone firmware after the upgrade is complete.

The ATA 186/188 provides two analog phone ports, allowing support for up to two analog phones and supports a number of features allowing an engineer to configure it according to the requirements and environment.

One neat feature is the ability to disable one of the two analog phone ports, something administrators might want to do if the second phone port is not used, providing an additional security measure.

On the other hand, a couple of second-hand ATA’s might fall into your hands and, upon testing, you may find out that only the phone port works – this doesn’t necessarily mean the second phone port is faulty!

When an ATA 186/188 registers on either CallManager or CallManager Express (CME), two MAC addresses appear in the device section.

Let’s take CME for example:

When an ATA 186/188 is registered with CUCM or CUCME, the system will show two new MAC addresses. The first is the actual MAC address of the ATA device. This represents Phone Port No.1.

The second MAC address is similar to the first but with a ‘01’ appended at the end. The whole MAC address is then shifted to the left by two positions, as shown in the above screenshot. This second MAC address represents Phone Port No.2.

When a phone port is disabled, for example port Phone 2, the second MAC address ending in ‘01’ will not register anymore. If removed from the CUCM/CME system, it will not appear again until it is enabled.

How to Enable – Disable Cisco ATA Phone Port No.1 or No.2

The first step is to try resetting the ATA to its factory default setting. This is fully covered in our ATA 186/188 Upgrade and Factory Reset article.

In many cases a factory reset might not prove to be that useful, in which case manual configuration of the ATA parameter SID is required. To do this, open a web browser and connect to the ATA using its address e.g http://192.168.135.5. From the web interface, select SCCP Parameters under the Change Configuration menu option.

At the presented page, Phone 1 and Phone 2 ports at the back of the ATA are represented by the SID0 and SID1 field respectively.

To enable a port, simply enter a dot “.” as a parameter, or “0” to disable it. Simple as that!

The screenshot below helps make this practice clearer:

Of course, it is always highly recommended to upgrade to the latest ATA firmware version to ensure stability and enhanced functionality of the Cisco ATA 186/188 device. The latest Cisco ATA 186/188 firmware is freely available in our Cisco Download section.

It’s unfortunate but true that, converged communication solutions are more often than not, deployed without much regard for the underlying security issues. In most cases, organizations tend to either ignore the security aspect of Unified Communication (UC) network’s security or underestimate the importance of the same. As a result a host of threats and attacks which used to be relevant to data networks now pester the voice implementation which leverages underlying data networks. Moreover, the existing security solutions which were designed for the data networks cannot adequately meet the new security challenges where voice meets data.

Unified Communications (UC) (Unified Communications is also referred to as IP Telephony) brings alongside a host of new security risks that cannot be resolved by existing security measures or solutions. While, UC risk mitigation strategies are just beginning to become known, UC threat mitigation entails significant costs or otherwise gets translated into cost of security that should be taken into account while designing the corporate UC security strategy. The first step to mitigate any risk is to know what your assets worth protecting are and what types of risks you should avert.

Let’s first understand the fundamentals of risk management.

UC Risk Management – Overview

Risk management is an art in itself as it spans multiple domains. Ideally, every asset in your UC network should be identified before going through risk management for your Cisco UC solution. This is important since it will identify what is most important to a business and where investment of time, manpower, and monetary resources will yield most favorable results. The assets that can be selected in a typical Cisco UC environment are (not limited to):

1. Cisco Unified Communications Manager (CUCM)
2. Cisco Unity Connection (CUC)
3. Cisco Unified Presence Server (CUPS)
4. Cisco Unified Communications Manager Express (CUCME)
5. Cisco Unity Express (CUE)
6. Cisco Voice Gateways
7. Cisco Unified IP Phones (wired, wireless, softphones)
8. Cisco Unified Border Element
9. Cisco Catalyst Switches
10. Cisco IOS Routers
11. Cisco Adaptive Security Appliance (ASA)

Once the elements of your Cisco UC solution are identified, it’s time to give them their risk ratings, based on your risk appetite.

Let’s start by defining risk.

Risk – is defined as probability of something going wrong when conducting business as usual and has a negative impact.

Now, while you may know that your call-control - CUCM for example - is not secure and can be compromised, you are essentially bearing a risk that a known or an unknown threat may be realized leading to realization of the risk. In other words, you are setting up your risk appetite. Risk appetite may be classified into 3 major categories:

• Risk aversion – Averting risks, adopting security where possible, high cost affair
• Risk bearing – knowing that the network could be attacked, still bearing risk, least cost affair
• Risk conforming – knowing that the network could be attacked, bearing risk to a minimal degree by implementing most critical security measures only, a balance between risk and cost

Next comes the risk rating, i.e. how you wish to rate the criticality of an element of Cisco UC solution to the operations of your network. For example, if CUCM is under attack, what will be the impact of the same on your network? Or, if an edge router is attacked, how do you expect the communication channels to be impacted?

Each application, device and endpoint should be given a risk rating which can be low, moderate or high. The Figure below depicts risk impact vs. likelihood.

Risk Impact vs. Likelihood (ratings)

Let’s now understand the threats that lurk around your UC solution and could possibly prove detrimental to the operations of a UC network.

The Risks & The Threats

There’s always bad guys out there waiting to impart damage to your UC infrastructure for their financial benefit, to prove their superiority to other hackers or just for fun’s sake.

The table below gives an overview of various threats and the possibility of these threats maturing i.e. risk realization as well as the probable impact on an organization’s operations. Please note that these are the most commonly seen threats:

 Let’s pay a closer visit to these threats and their risk bearings.

Eavesdropping – gives the attacker the ability to listen and record private phone conversation(s). An attacker can eavesdrop on VoIP conversations by disconnecting a VoIP phone from the wall outlet and plugging in a laptop with a softphone or packet capture software (such as Wire Shark) or by virtue of VLAN hopping attacks. Additionally, eavesdropping can be implemented using SIP proxy impersonation or registration hijacking. If this threat is realized, the risk of damage or disruption is high.

Identity Theft – Can happen at various OSI layers right from layer 2 through layer 7. Some examples are: MAC spoofing; IP spoofing; call-control / proxy / TFTP spoofing. There are freely available tools such as macmakeup, nemesis and so on which can help the attacker spoof an identity, in other words perform identity theft to trick the source or destination in a voice conversation to believe it is communicating with a legitimate person whilst it’s the attacker playing on behalf of a legitimate source. Now, a typical example of such an attack is when an attacker can spoof the MAC address of a victim’s machine and register his softphone. The attacker has the privilege equivalent to that of the victim and can conduct toll-fraud (explained later in this article) or extract information from the softphone’s web server to launch a flurry of attacks on the voice infrastructure. If this threat is realized, the risk of damage or disruption is moderate to high (depending on the privilege the attacker gains based of the victim’s profile).

Compromised Information / Loss of Information: Every business has some confidential information which, if exposed to its competitor or leaked on the internet, can prove detrimental for the business. Moreover, incorrect information passed to a destination entity can result in the business running into issues. An attacker can compromise the information in voice calls by injecting malformed packets, modifying the RTP packets, or by eavesdropping the call (discussed earlier). Packet injection or malformation attacks are difficult to detect unless an integrity method / algorithm is implemented. If this threat is realized, the risk of impact is high.

Toll fraud – This has been a classic issue since PBX days and continues to be a real nuisance in the VoIP world. An attacker finds a way to place an external call to the victim’s call-control and “hairpin” it into an outgoing call to an external destination. This could be performed using DISA, via voicemail, by a compromised IP Phone (such as a softphone), or by simply having an insider forward the calls to a desired international destination. This attack can land an organization with a skyrocketing bill in no time. The threat level of risk is high.

Denial of service – A DOS attack prevents use of the corporate UC systems, causing loss of business and productivity. An attacker can initiate a war dialer, remote dialing, or manually initiate an attack by launching multiple calls against a system.  This in turn overloads the system on call-control and depletes the bandwidth. The effect can range from legit users getting the busy tone when trying to dial any number, using voice mail or IVR to system bandwidth being filled by unwanted traffic. Level of risk for this type of threat is medium.

Spam over IP Telephony (SPIT) – equivalent to email spam on data networks. It’s unsolicited and unwanted bulk messages sent / broadcast to an enterprise network’s end‐users. This causes the enterprise user’s voicemail box to be full and the endpoint to be busy with unwanted calls. These high‐volume bulk calls are very difficult to trace and inherently cause fraud and privacy violations.

Call Hijacking – UC endpoints / devices can be hijacked through a variety of hacking techniques, such as registration hijacking and call redirection. Rogue endpoints can enable a hacker to use the organization’s communication systems without authenticating to the call-control. This can lead to toll fraud and disrupt communications. Also, rogue endpoints or wireless access controllers (WLC) or wireless access points (WAP) can serve as a back door for attackers to gain entry to legitimate network zones and compromise call-control, voice messaging, presence, and other services. Level of risk for this type of threat is medium to high.

Mitigating Risks

A golden saying in the world of security is – Security is only as strongest as the weakest link!

To ensure that your Cisco UC network is secure and can deter most threats while reducing the associated risks, a multi-level security construct is required. In other words, no single security solution can restrain all threats or risks; security at multiple levels within a network i.e. at endpoint, server, application, network, perimeter, and device level helps avert a host of threats.

It’s important to treat the development of a UC risk management program as a collaborative cross‐organizational project. Any actionable risk assessment needs: a comprehensive list of threats; feasibility of realization of each threat; a prioritization of mitigation actions for each of the potential threats. It’s most important that risks be managed and mitigated in line with corporate vision and continuity of essential operations when deploying UC systems.

Following are the leading practice recommendations to mitigate risks pertinent to various threats in a Cisco UC network:

• Implement adequate physical security to restrict access to VoIP components; Voice and Data traffic segregation at VLAN level and, if possible, at firewall zone level.

• Implement VoIP enabled firewall (application layer gateway) e.g. Cisco ASA.

• If voice VLAN is propagated to a remote location, implement firewall zoning to separate inside from outside traffic.

• Disable unused switch ports.

• Implement DHCP snooping, Dynamic ARP Inspection (DAI), and port security features on Cisco Catalyst switches.

• IP Phones located in public areas such as lobby, elevator, or hotel rooms, must be separated from employee/internal network by firewalls and ideally should have their own dedicated VLAN.

• Implement 802.1x based network access control (NAC) using EAP-TLS where possible.

• Implement scavenger QoS class for P2P and other unwanted traffic.

• Secure telephony signaling using TLS and media SRTP (Cisco CAPF).

• Encrypt signaling and media traffic for endpoints, gateways, trunks, and other ecosystem applications where possible.

• Establish dedicated IDS for voice VLAN for traffic within campus and from remote sites (SPAN, RSPAN)

• Secure voice messaging ports.

• Utilize Cisco Malicious Call Identification (MCID) to tag and list malicious calls.

• Implement a call accounting/reporting system such as CAR or third party billing software to view call activity on an ongoing basis.

• Implement strong password and PIN policies as well as OTP policies.

• Use the SSO available in Cisco UC applications to suppress fraudulent admission to network.

• Configure off-hours calling policies in line with the organization’s policies.

• Configure administrative group privilege restriction levels.

• Disable PSTN to PSTN trunk transfer.

• Enable ad-hoc conferencing conclusion on exit of the initiator.

• Harden IP Phones by disabling unused features and restricting settings access.

• Sporadically review system usage reports for abnormal traffic patterns or destinations.

• Use VPN to provide a secure conduit for communication with telecommuters/remote workers. V3PN, available in Cisco IOS routers and security appliances, enables encryption of voice, video, and data traffic using IPSec. SSL VPN can also be used from VPN Phones and SSL VPN client on PC’s with softphone.

• Enforce Antivirus (on Windows based servers) and Host Intrusion Prevention System (HIPS) on Windows and Linux based servers.

• The human factor cannot be ignored. Hence, train people in your organization about their responsibility for executing enterprise risk management in accordance with established directives and protocols.

Summary

In a nutshell, there is no one-size-fits-all when it comes to securing a Cisco UC network. No two networks are alike and organizations must examine UC security from a business perspective by defining their vision, goals, policies, and patterns of usage. It’s important that the security implemented is aligned with and in compliance with applicable laws and regulations, while being effective against business risks.

Moreover, a change in risk appetite must be observed when an organization’s priorities or business processes change. A multitude of the UC security risks can be resolved by applying existing ad-hoc security measures and solutions in a planned manner as listed in previous sections. The risk management solution approach is based on evaluating the following factors in order to minimize costs and maximize mitigation of risks:

• Business Impact of realization of a risk

• Compliance requirements

• Threat surface

• Budgetary constraints

This schema is depicted in the below figure:

Risk Management Specifics for Cisco UC

A successful UC risk management system or construct will ideally address all threats from realizing while minimizing business impact in compliance with laws and regulations, and is within budget such that the Total Cost of Ownership (TCO) decreases with time while Return on Investment (ROI) increases.

About The Author

Akhil Behl is a Senior Network Consultant with Cisco Advanced Services, focusing on Cisco Collaboration and Security architectures. He leads Collaboration and Security projects worldwide for Cisco Services and the Collaborative Professional Services (CPS) portfolio for the commercial segment. Prior to his current role, he spent 10 years working in various roles at Linksys, Cisco TAC, and Cisco AS. He holds CCIE (Voice and Security), PMP, ITIL, VMware VCP, and MCP certifications.

He has several research papers published to his credit in international journals including IEEE Xplore.

He is a prolific speaker and has contributed at prominent industry forums such as Interop, Enterprise Connect, Cloud Connect, Cloud Summit, Cisco SecCon, IT Expo, and Cisco Networkers. Akhil is also the author of Cisco Press title ‘Securing Cisco IP Telephony Networks’.

Read our exclusive interview of Akhil Behl and discover Akhil's troubleshooting techniques, guidelines in designing and securing VoIP networks, advantages and disadvantages of Cisco VoIP Telephony and much more: Interview: Akhil Behl Double CCIE (Voice & Security) #19564.

When purchased, Unity Express includes a few licenses for some services, such as voice ports for auto attendant, while other services like mailboxes are not included.  This policy forces companies requiring these services to purchase additional licenses from Cisco in order to activate or expand the system’s capacity.

A good example is the Unity Express voice mailbox service. When purchasing Unity Express, by default it does not include any mailboxes. 

While the Unity Express web interface allows the creation of voice mailboxes despite the fact no licenses are installed, you won’t be able to make use of them unless the appropriate number of licenses is installed.

When a caller is redirected to a user’s voice mailbox where the system does not have the necessary licenses installed, instead of hearing the called party’s voicemail prompting to leave a message, the following prompt is heard:

Voice mail system is unavailable, try again later, to talk to the operator, press zero.

Engineers and Administrators interested can read our popular articles covering the physical installation and initial setup of Unity Express on Cisco CallManager Express or Cisco Voice Gateways:

• Cisco Unity Express Installation & Setup - ISM-SRE-300-K9 & SM-SRE-700-K9 Installation – Part 1
• Cisco Unity Express Installation/Setup - Service Module & Initial Web Interface Configuration - Part 2

Installing & Verifying Unity Express Licenses – 4 Simple Steps

Installing Unity Express licenses is not all that complicated. We’ve broken down the process into four simple steps to make it as clear and simple as possible:

• Registering and Assigning your Product Authorization Key (PAK) number
• Obtaining the Correct UDI Product ID and Serial Number
• Installing the Software License on Unity Express
• Verifying Unity Express License Installation

No matter what type of license you have the installation process is the same. It is important to note that when installing multiple PAKs for a service they must be combined into a single license. For example, if you have purchased four packs of 5-user-mailbox licenses to support a total of 20 users, you must ensure these are combined into a single 20 mailbox license file and not four x 5-mailbox license files. If problems arise, Cisco support is always available to help resolve any licensing problem.

Before we begin the license installation process it is important to verify the existing licenses so we are sure of what we have already.

Verifying Existing Cisco Unity Express Licenses

Before considering purchasing licenses it is necessary to verify what is already installed. This is easily done by using the following command to view the currently installed licenses. Note that the License Type: Permanent from the command output is what we are looking for. This represents a permanent license, which is also the installed licenses:

Note: We’ve removed the rest of the command output to avoid redundant information.

License Type: Evaluation is, as the output indicates, evaluation licenses. These are not installed/purchased licenses and normally are limited to a 60 day trial period after which they expire and are disabled.

Another way to verify the installed licenses is to log into the Unity Express GUI interface and visit the Administration>Licenses section:

As both CLI output and GUI interface confirm, we currently have two VMIVR-PORT licenses installed. This license feature will allow up to two simultaneous calls to the autoattendant system or user voice mailbox service.

Register & Assign Your Cisco Product Authorization Key (PAK) Number

When purchasing a Unity Express license, you’ll receive it either as a hardcopy or electronically delivered license. The license contains an 11-digit Product Authorization Key number, also known as PAK. The PAK is basically your license, which needs to be associated with your Unity Express hardware. This process is done through the Cisco.com website. Once associated, the necessary license file will be delivered to you electronically and you’ll then need to install it on Unity Express.

To begin registration, visit  http://www.cisco.com/go/license.  A valid CCO account is required, so users without a CCO account will be required to register first. After the logon process is complete, we need to enter our 11-digit PAK number as shown in the screenshot below:

If more than one license PAK has been purchased for the same family product, for example 2 packs of 5-user mailbox license, then click on the Load More PAKs button and the page will provide additional fields to enter all purchased PAKs.

Since our example only contains a single PAK, we enter it and then click on Fulfil Single PAK.

The next page allows us to assign our PAK to our Unity Express hardware. Click the Quantity Available check-box to ensure all quantities are selected (one in our case) and below enter the UDI Product ID and Serial Number.

Note: The small arrow box on the right of the UDI Product ID field (shown in the screenshot below) will produce a pop-up window instructing to issue the “Show License UDI” CLI command in Unity Express, to obtain the correct Product ID and Serial Number, however, the information provided by the CLI prompt is misleading and can cause confusion.

 The next section covers how to obtain the correct UDI Product ID and Serial Number.

Obtaining The Correct UDI Product ID & Serial Number

From your router prompt, connect to the Unity Express CLI prompt and issue the show license udi command:

Note that, under the UDI column, the system shows ISM-SRE-300-K9:FOC162427RV – this is actually the UDI and serial number  (UDI:SERIAL_Number).  The UDI is everything before the semicolon (:).

So, UDI is ISM-SRE-300-K9 and the system serial number is FOC162427RV. If ISM-SRE-300-K9:FOC162427RV is entered in the UDI Product ID field, the system will not accept it.

Cisco does not mention how to distinguish the correct UDI from the output provided, this can cause frustration when trying to assign the PAK to the hardware.

Even the show version provides the same confusing result. Notice the UDI section:

Register & Assign Your Product Authorization Key (PAK) Number (continued)

After entering the UDI Product ID and Serial Number in the provided fields, press the Assign button to assign the PAK to the Unity Express hardware. The page will update and show Device, PAK and SKU assignment:

We are now ready to continue by clicking on the Next button.

The system now presents us with the final page where we enter our email address and confirm the end user. We must agree to the License terms before the license can be generated. When ready, click on the Get License button:

A pop up window confirms the license is being processed and will be emailed when complete. This takes a couple of seconds. There is also an option to download the license directly in case access to email is not possible:

A final confirmation window tells us the license is ready for download and has also been emailed to our registered address:

The license file name is somewhat long and contains the system’s serial number and a 17 digit number.

Installing The Software License On Unity Express

Unity Express licenses are installed via an FTP server. The FTP server will serve the license file and we’ll instruct Unity Express to fetch the license using the CLI prompt.

We assume an FTP server is up and running on a workstation and is accessible from Unity Express.

Now we need to log into Unity Express and issue the command so it can fetch the license and install it.

Note the command syntax is ftp://username:password@ftp_server_ip/licensefilename:

Verify Unity Express License Installation

Upon reboot, Unity Express will enable the newly installed license and it will be available for use. When the reboot completes, we can verify the license status using the show license status application command.

To make things a bit more interesting we created 10 voice mailboxes while installing a 5 user mailbox license. This means we had more mailboxes than our installed license allowed. Check out the result:

When dialing a user’s extension where voicemail was enabled, as explained earlier, instead of the standard greeting message we got the Cisco lady telling us : Voice mail system is unavailable, try again later, to talk to the operator, press zero.

After deleting the 5 additional mailboxes and issuing the show license status application command, we notice the voicemail service is now enabled:

Useful Unity Express License Show Commands

Following is a collection of useful commands that provide information on Unity Express’s license condition:

'show license status application'

The show license status application command displays the status of the license applications installed in Unity Express. The command accepts additional parameters such as: ivr, ports, timecardview, voicemail. By entering the command as shown, it will display information for all applications:

'show license all'

The show license all command displays the summary of all the licenses installed in your Unity Express system. The command has no additional parameters:

'show license in-use'

The show license in-use command displays information about the licenses that are in use on your Unity Express module. Again, there are no additional parameters for this command:

This concludes our Cisco Unity Express License Setup & Installation - Software Activation article.

With the rapid increase of the mobile phone market, customer requests for CallManager Express to support them are on the rise. In response, Cisco added support for Apple’s popular iPhone with CallManager Express v8.6 ( IOS 15.1(4)M ), but unfortunately did not include Android support, leaving millions of Android phone users in the dark. 

At the time Cisco Mobile 8.1 & 8.0 was available for iPhone users, allowing them to connect and make phone calls via CME just as any normal softphone client.  Cisco Mobile was later renamed Cisco Jabber.

Thankfully, with CallManager Express v9.1 ( IOS 15.2(4)M1 ), Cisco finally added support of the Jabber application for the Android operating system.  Both Cisco Jabber versions (Android and iPhone) use SIP as the communication protocol with CME. SCCP is not used. 

While CME 9.1 now supports both iPhone and Android phones, getting them to work is a different story.

This article will demonstrate how to configure your CallManager Express v9.1 to support Cisco Jabber for both iPhone and Android operating systems.

At the time of writing, the latest version of Cisco Jabber for iPhone is 9.0 (1) and 9.0.1.1911 for the Android operating system.

Cisco ISR 2800 Series CME – No Support for Jabber Android Users

On the 1^st of November 2010, Cisco announced its discontinuation of all 2800 series ISR routers and, as a result, will only provide minor software upgrades.

The latest IOS version available for the 2800 series is 15.1(4) which, according to our CME-IOS Matrix, supports CallManager Express v8.6.  

Since support for the Android operating system begins officially with v9.1, the 2800 series CME routers will only be able to support Cisco Jabber for iPhone.  Unfortunately no support for Android is available (yet) for this platform, and we don’t expect to see any in the near future.  

IT Managers and engineers who want to provide CME services to their Android Jabber users must upgrade to the 2900 series platform.

Cisco Jabber For Android – How To Overcome Bugs!

Jabber support for the Android operating system is very new on CME and as such, the Jabber version available in Google’s Play Store might not work properly. 

When we tested Cisco’s Jabber from the Google Play Store using our Samsung Galaxy SII (Model GT-I9100) running Ice-Cream Sandwich 4.0.4, it was not able to connect to our CME v9.1.  We tried the LAN Wi-Fi and even the GSM network (via Anyconnect VPN) but the application failed continuously to register and requested we check our Internet Calling settings.

After consulting with Cisco engineers around the globe, we discovered we had hit a bug on the Android version of Jabber, specific to some Samsung phones running Android 4.0.4. This was later confirmed with some HTC Android phones as well.

However, we managed to obtained an Engineering Special (ES) edition (as Cisco calls it) of Jabber, that overcomes the problems mentioned and works like a charm!  This ES Jabber release is not available through Google’s Play Store, nor from Cisco as a direct download.

Fortunately, Firewall.cx Android users can download the engineering special edition from our Cisco Tools and Applications section!

Configuring CallManager Express To Support Jabber For Android & iPhone

The configuration settings of CME are pretty much identical for both Android and iPhone operating systems.

Since Jabber for CME uses SIP as a communication protocol, it is mandatory to enable SIP registration on CME.  Enabling SIP registration requires special attention to ensure registration is only restricted to the local network or VPN users at most.

Opening SIP registration to public IP’s or untrusted networks is definitely not recommended as it could allow anyone to connect and register to the CallManager Express.

First step is to configure CME to allow calls from SIP to SIP endpoints and enable SIP registrar:

The ip address trusted list section is used to list remote client IP addresses which are not part of the local network. This will allow them to register with CME and place or receive calls.  If for example your Android or iPhone connects to the corporate LAN via VPN (AnyConnect VPN) and obtains an IP address on a different network/subnet from CME, it will be necessary to list the VPN IP address or VPN network pool for the phone to register. 

The control source-interface GigabitEthernet0/1 command ensures SIP uses GigabitEthernet 0/1 as the binding interface for all SIP communications. The interface’s IP address will show up as the source IP for all outgoing communications.  All incoming communications are expected to terminate to this interface as well.

Next step is to configure the voice register global section. This section holds key configuration elements for the correct operation of our CME SIP service.

Here we will specify various parameters including: Set SIP registrar to CME mode, source-address for phone registration,  maximum extensions (max-dn), maximum phones (max-pool), set authentication for phone registration and finally create configuration files for all phones (tftp-path, file text & create profile).

Now we can configure our phone extension using the voice register dn command and SIP phone with the voice register pool command:

voice register dn 5
number 778
name Chris-Android 778
label Chris-Android 778
!
voice register pool 1
registration-timer max 720 min 660
id mac 147D.C5AF.79B2
session-transport tcp
type Jabber-Android
number 1 dn 5
username chris password firewallcx
codec g729r8

While most commands are self-explanatory, we’ll focus on the most important:

number 778: This specifies the extension our SIP phone will have.

id mac 147D.C5AF.79B2. This is the Wi-Fi MAC address of our mobile phone. In our example, our Samsung Galaxy SII.

type Jabber-Android.  Here we specify the sip client type. It can either be CiscoMobile-iOS for Apple iPhone users or Jabber-Android for Android users.

codec g729r8: This specifies the codec that will be used for this client. It is possible to use g711ulaw or g711alaw, g722-64k, g729r8 and ilbc.  Each code has different bandwidth requirements and sound quality.  G729r8 and ilbc require 8 and 13kbps-15.2kbps respectively, while the others require 64kbps.  Don’t forget to add the IP overhead to these figures.

Note: When the SIP phone extensions and devices configurations are complete or altered, it is imperative we go to the voice register global section and issue the create profile command.  This ensures the appropriate configuration files on CME are created for our SIP devices.

Cisco Jabber For Android (both 4.0.4 & 2.3) Settings – Configuration Example

Connect to the Google Play Store and search for Cisco Jabber:

After downloading and installing Cisco Jabber for Android, launch the application and click on Begin Setup:

Next, in the Device ID field, enter the SEP+MAC address (Applications ->Settings->Wi-Fi-> Advanced Wi-Fi) without any spaces or dots. Now, enter your CME IP address in the Server Address field.

You can selectively enable Use mobile data network and Use noncorporate Wi-Fi options.  We always select Use noncorporate Wi-Fi only to ensure the GSM mobile network is not used (especially if your provider charges GSM data).

If necessary, enable Auto Start so that Cisco Jabber starts every time your phone restarts. Now click Verify to register with CallManager Express:

 After Cisco Jabber successfully registers with CME, we are presented with the main screen and dial pad:

Cisco Jabber For iPhone Settings – Configuration Example

First we need to verify our phone is connected to the corporate Wi-Fi network and is accessible from CME.

1. Launch Cisco Jabber and complete the setup wizard.
2. Enter the Device Name SEP, followed by your MAC address without any dots. e.g SEP147DC5AF79B2
3. Enter your CME IP address in the TFTP Server field. E.g 192.168.9.5
4. Turn ON SIP Digest Authentication and enter the username and password configured under the voice register pool section

Following is a screenshot of the complete settings on our iPhone:

 This concludes our Cisco CallManager Express (CME) Cisco Jabber for Android and iPhone configuration.

We've conveniently packed in one zip file CallManager Express GUI files for CCME v3.3, CCME v4.1.0.2, CCME v4.2, CCME v7.1.0.1, CCME v8, CCME v8.5 and CCME v8.6.

Please note that CCME GUI v8.8 and v9.0 contain bugs and are pretty much useless as no CCME modifications can be saved using these GUI versions, and therefore you are advised to use CCME v8.6 if the GUI interface is absolutely necessary.  For more information on these bugs, please visit our CCME v8.8 & v9.0 bug announcement. CCME GUI version 9.1 was not yet published at the time of this post.

Users can download CCME GUI files by visiting our Cisco Download section.

Step-by-step installation instructions for the CCME GUI are available at the following Firewall.cx articles:

1) CallManager Express GUI Software Installation & Configuration - Part 1
2) CallManager Express GUI Software Installation & Configuration - Part 2

Users who wish to check their IOS CCME version can use the show telephony-service command:

The table below illustrates the Cisco IOS releases, CallManager Express versioning and CallManager Express GUI version that should be used or installed on the device (router or UC500):

Users interested can also visit our Cisco VoIP/CCME - CallManager Section where they'll find more articles covering Cisco VoIP, CallManager, CallManager Express and Unity Express.

For the SRE-300, the module’s interface name is interface ISM0/0, whereas for the SM-SRE-700 it is service-module sm2/0. Both interfaces are GigabitEthernet, connected via each router’s internal bus.

The ISM-SRE-300-K9 module is configured with its own IP address and acts as a separate machine inside the router. Before we can begin configuring Unity Express, preinstalled by Cisco, we must configure IP connectivity with the router so we can then access the ISM-SRE-300-K9 module and initialize the Unity Express setup.

When physically installing an SRE module, CCME will automatically make two additional interfaces available in its configuration. For the ISM-SRE-300-K9, they are interface ISM0/0 and interface ISM0/1, whereas for the SM-SRE-700 they are interface SM2/0 and interface SM2/1.

First step is to configure IP connectivity between the router (CCME) and Unity Express. This is achieved by configuring interface ISM0/0 with an IP address (ISM-SRE-300-K9) or interface SM2/0 for the SM-SRE-700.

Our CCME router has two IP addresses, 192.168.9.5/24 (Data VLAN) and 192.168.10.5/24 (Voice VLAN). When configuring an IP address on Unity Express, there is the choice of assigning one part of the existing network(s) (192.168.9.0 or 192.168.10.0) or one that is on a completely different network. 

It is a common practice to configure Unity Express with an IP address that is part of the Voice VLAN, that is, 192.168.10.0/24 in our example:

In the above configuration commands, we’ve configured our Unity Express module with IP address 192.168.10.10 and a default-gateway of 192.168.10.5 (CCME’s Voice VLAN IP address), this is because the Unity Express module is physically connected to our router’s internal interfaces (ISM) and therefore must use one of the router’s IP interfaces as a default-gateway.

The ip unnumbered <interface> command allows the Cisco Unity Express module to use a network subnet IP address associated with a specific router egress port such as GigabitEthernet0/0.2. This configuration method requires a static route to the service-engine interface. The router interface associated with the Cisco Unity Express interface (GigabitEthernet 0/0.2) must be in an "up" state at all times for communication between the router and module.

At this point we should note that GigabitEthernet0/0 is configured as a trunk link with our switch. This configuration method is known as ‘Router on a Stick’ and allows all configured VLANs to pass through a single interface. For more information on this configuration method, please refer to our Router-on-a-Stick article.

Following is the configuration of our GigabitEthernet 0/0 interface:

Next step is to create a static route to Unity Express’s IP address via the internal service module (ISM0/0):

At this point, we should be able to ping Unity Express’s IP address:

CallManager Express - Telephony-Service Configuration

Next step is to configure our CallManager Express web-based administrator user (if not already configured), voicemail extension on CallManager Express, voicemail dial-peer and Message Waiting Indicator (MWI) extensions used to enable/disable the red light (message waiting indicator) on the IP phone when there is a message waiting in the user’s voice mailbox:

Now we must enable the IP http & http secure server and ensure the http access-lists (if any) allow the login of Unity Express’s IP address:

Failing to configure the above commands will result in the failure of Unity Express to log into the CallManager Express system and not able to complete the Unity Express initialization process. In our setup, network 192.168.9.0 is the Data VLAN, whereas host 192.168.10.10 is our Unity Express IP address.

Unity Express Module Administrator User Configuration

Final step involves login into the Unity Express CLI and creating the admin user to be used for the web-based initialization process that follows:

We are now ready to connect to Unity Express and begin the module’s initialization.

Unity Express Web Interface Initialization & Configuration

Open a web browser and enter the IP address of the Cisco Unity Express module, in our case this is 192.168.10.10. The Unity Express is yet to be initialized and therefore will only allow administrator login.

Using the username and password entered above, we log in to the Unity Express administration panel:

Upon logon, we need to select the appropriate Call Agent Integration from the drop-down menu, in our case Cisco Unified Communication Manager Express:

After the selection, the system will warn that it will delete Jtapi related configuration and reboot. Do not be alarmed and click on OK to continue:

If you’re connected to the unity express CLI, you’ll also be able to view the whole reboot process. Here is the session we captured during this reboot:

While Unity Express reboots, the GUI interface shows a messaging explaining that the system is reloading and will automatically try to reconnect once the reboot cycle is complete:

When the system is back online it is necessary to log back in using the Unity Express administrator account previously created (admin).

After the logon process is complete, we are presented with the CUCME Logon screen. This screen is to provide the credentials so that Unity Express can log on to the CCME and obtain user account configuration. This account is the same account created under the Telephony-Service section of CCME (shown previously). We can also provide the hostname or IP address of CCME. We selected the IP address of the Voice VLAN, 192.168.10.5:

In case of logon failure, Unity Express will present a pop-up window explaining that it failed to log on. In such a case, check the CCME web user under telephony-services and ensure the rest of the required commands are present.

As soon as Unity Express’s login to CCME is complete, it will present all users it finds and allow the administrator to associate the Primary Extension for each one. Here, you can also enable Mailbox creation, set a specific user as an Administrator or set CFNA/CFB (Call Forward No Answer / Call Forward Busy) so that incoming calls to the user are directed to his/her voicemail when not answered or busy:

Clicking on Next takes us to the Defaults page where default settings are configured for all new users and mailboxes created from now on. Ensure the System Default Language is set to English (in most cases) and take note of the Password & PIN Options.  The rest can be changed as required:

Next page coves the handling of calls to Unity Express. Here you set the Voice Mail Number. This same number should be configured under Telephony-Service in CallManager Express (covered earlier in this article). MWI ON/OFF should be automatically configured, if not, select the correct extensions configured.  SIP MWI should be left as default unless there is a reason to change it:

A final screen is presented where there is an option to finalize the configuration and save it to the Unity Express startup-config. Review as necessary and click on Finish to begin the process:

As the saving of the configuration is in progress, Unity Express executes a number of scripts in the background and makes the necessary modifications. An update of this progress is shown on the web browser screen:

Finally, Unity Express will present a summary of the setup and inform the administrator of all successes and failures:

In our example, Unity Express failed to create and allocate a voice mailbox to our user due to the absence of an active mailbox license.

Unity Express licensing will be covered in a separate article, along with more details and information.

This completes a two-part article covering the physical installation of ISM300 and SME700 Service Engine Ready modules with Unity Express 8.0.

Users interested can also visit our Cisco VoIP/CCME - CallManager Section where they'll find more articles covering Cisco VoIP, CallManager, CallManager Express and Unity Express.

Cisco Unity Express Hardware Platforms

Unity Express is offered on a variety of hardware platforms supporting the Cisco 2800, 3800, 2900 and 3900 series routers. Depending on the router and capacity required, Unity Express is available as a card that fits in an Advanced Integration Module (AIM) slot (2800, 3800 series), Internal Service Module (ISM) (2900, 3900 series), Network Module (NM-CUE-EC) for 3700, 2800 & 3800 series that support network modules, Enhanced Network Module (NME) for all 3700, 2800, 3800, and 2900, 3900 series routers supporting network modules and finally the newer Service Module (SM) supported only on ISRG2 routers (2900 and 3900 series), again that are able to accept network modules.

We were lucky to get our hands on two different Unity Express modules, the ISM-SRE-300-K9 installed on a Cisco 2911 CCME, and the larger SM-SRE-700-K9 installed into a Cisco 3945 CCME.

The following table shows the technical specifications of both ISM-SRE-300-K9 & SM-SRE-700-K9:

Meet The ISM-SRE-300-K9

While the configuration procedure for both modules is identical, physically there are many differences that cannot be overlooked.

The ISM-SRE-300 is the smallest internal module available for the newer ISRG2 routers but certainly does not hold back in performance or capabilities. With a whopping 100 mailbox support and up to 10 concurrent voice ports, its capable to deliver enterprise class services. 

As an ISM module, it is installed by opening the router’s lid and connecting it to the special ISM port located on the back left area of the main board or front right area, depending on which way the router is facing. On our Cisco 2911 ISR-G2 CallManager Express  router, we've marked the ISM connector yellow in the picture taken below:

In the picture above, we see our Cisco 2911 router, open and ready to accept the ISM module. Note that there is only one ISM connector on the main board, which means you can only install one ISM module.

With every ISM module, Cisco provides 4 hex metal M-F standoffs to be placed in the area circled in red.  To install the hex metal M-F standoffs, it is necessary to remove the factory screws, and replace them with the hex metal M-F standoffs. Finally, after the ISM-SRE-300 is in place and connected, use the screws to tighten the board against the hex metal standoffs.

This is what the 2911 router looks like inside, after the ISM-SRE-300 is firmly placed in its position and secured with the necessary screws:

We’ve also add a few more items, including a High-Density Packet Voice Video Digital Signal Processor Module (PVDM3-16) and three VIC2 cards used to connect to the public switching network (ISDN and PSTN Lines).

Meet The SM-SRE-700-K9

The SM-SRE-700-K9 is the big SM brother targeted for larger enterprises with support up to 500 mail boxes and expandable to 32 concurrent voice ports. Looking at the picture we took during the installation, it is evident we are talking about a whole server on a single board – the only thing missing is a VGA card!  The SM-SRE-700-K9 is capable of running VMware vSphere Hypervisor and host Windows machines running one or more Windows Server operating system!

The system’s hard disk drive is visible on the lower right area and next to it there is an empty slot ready to accept a second disk drive. On the left is the system’s DRAM – 4 GB in total (2x2GB) and we suspect the central processor is located to the right side of the DRAM memory as there’s a sticker right behind the empty hdd slot warning that the heat sink gets hot.

Installing the SM-SRE-700-K9 is a lot simpler as it does not require opening the router to access its mainboard. Simply locate an empty SM slot, remove the blank plate and insert the SM-SRE-700-K9 inside:

 Once neatly tucked in its place, we are ready to power up the Cisco 3945 router and being the setup.

 Next: The second part of our Unity Express installation guide.  Part-2 covers the initial configuration of CallManager Express, necessary to establish communication with the Unity Express module, IP configuration, initilization of the setup procedure plus much more.

The article provides step-by-step instructions with all necessary details and as always includes screenshots of the setup process.  Click here to read Part-2 of our Unity Express Setup/Installation.

On the other hand the CME GUI interface can also prove to be a big waist of time, that is, if your trying to install CME GUI versions 8.8 or 9.0.

Wondering why? 

Simply put, there is a massive bug in these two CME GUI versions that render the whole web interface useless.  We spent valuable time trying to troubleshoot a very weird problem: After installing and setting up the web interface, we couldn't make any changes to the ip phones, extensions or any functionality supported by the GUI interface!

When trying to save our changes, the system would return back to the main menu,  totally ignoring the changes and without saving anything!

After much frustration, trying different IOS images and GUI interfaces, we contacted Cisco so they could share some light and help us diagnose the problem.

To our surprise, the problem was a bug related issue which is yet to be fixed!  The only work-around, if you require a functional administrative web-interface, is to downgrade to CME IOS 151-4.M4 and GUI version 8.6.

The sad part of this story is that Cisco has failed to place any notice in their relevant download section, so engineers are downloading GUI files for CME versions 8.8 and 9.0, without any clue of what's to come!  As a result, thousands of cases have been opened with Cisco, all around the same problem.

The Bug ID assigned for this issue is CSCtz35753, but don't bother searching for more information on it, Cisco is not disclosing any information  at this point of time - it's top secret!

While purchasing one or two ATA devices might be acceptable for up to two or four analog phones, this quickly becomes a very expensive practice for any additional FXS ports. Thankfully, there is a cheaper solution – the Cisco Linksys SPA8000.

The Cisco SPA8000 is an 8-port IP Telephony Gateway that allows connections for up to eight analog telephones (provides 8 FXS ports) to an IP-based data network. What many engineers are not aware of is that the SPA8000 can also be configured to connect to Cisco's CallManager Express or Cisco UC500 series IP Telephony system, decreasing dramatically the cost per FXS analog port of your VoIP network.

The diagram above shows the physical connection of the solution. The SPA8000, just like any VoIP device, is configured and connected to a network switch and assigned to VLAN2, the Voice VLAN in our example. By doing so, the SPA8000 is able to communicate with CallManager Express using the SIP Protocol as shown below.  On the back of the SPA8000, we've connected simple analog phones to FXS ports provided. These phones can be placed in areas where there is no need for the more expensive Cisco IP Phones, usually public areas, production environments etc.  Note that these analog phone devices can also be wireless analog phones.

Upgrading The Cisco SPA8000 Firmware

We highly recommend upgrading the SPA8000 to the latest available firmware version. This practice usually provides new features and greater stability of the unit. This simple-to-follow process has been extensively covered in our Cisco SPA8000 Firmware Upgrade article.

Configuring The SPA8000 IP Address

To avoid network problems, it is important to ensure the SPA8000 is configured to be in the same network as the CallManager Express or UC500 – in other words, the same VLAN (Voice).  In the SPA8000 Network – WAN Status tab, always ensure the Connection Type is set to Static and appropriate IP Address, Gateway and DNS Server is provided:

Configuring The SPA8000 FXS Ports For SIP Registration With CallManager Express / UC500, UC520, UC540, UC560

On the main Voice configuration tab, the SPA8000 lines are configured on tabs L1 through L8.  To enable a line, for example L1 which corresponds to FXS port 1, click on the L1 tab and set Line Enable to YES:

 Next, we need to configure the following settings:

• Proxy:  IP Address of our CCME or UC500 series IP PBX
• Register: Enable registration of the line with CallManager Express or UC500
• Make/Ans Call Without Reg: Always force the line to be registered with CCME or UC500 to place or answer a call
• Display Name:  Caller ID for the extension. This is the Caller ID other extensions will see when we dial from this line
• User ID: The line’s extension number e.g 139
• Auth ID & Password:  Username and password combination for this line.  We use cisco / firewallcx
• Use Auth ID: Enable authentication for this line.

It is important to note that the same Auth ID & Password is used for all configured lines, that is, L1 though L8.

At this point, we have completed the SPA8000 configuration and are ready to move to CallManager Express or UC500 configuration.

Configuring CallManager Express & UC500 (UC520, UC540, UC560) SIP Registration For SPA8000

On the CallManager Express side, the SIP CME feature is used to register the SPA8000 as a generic SIP endpoint, allowing each configured line (on the SPA8000) to register with CCME.

First, we create a voice class codec that will define the voice codecs that can be used by CallManager Express and SPA8000:

Next, we enable the SIP registrar server on our CallManager Express:

CCME(config)# voice service voip
CCME(conf-voi-serv)# sip
CCME(conf-serv-sip)#  registrar server
CCME(conf-serv-sip)#  exit

Now we need to define the global voice register parameters:

CCME(config)# voice register global
CCME(config-register-global)# mode cme
CCME(config-register-global)# source-address 10.10.100.10 port 5060
CCME(config-register-global)# max-dn 10
CCME(config-register-global)# max-pool 10

The source IP Address used here is that of the CallManager Express or UC500 Voice VLAN interface.

Now configure the extension number for each FXS port on our SPA8000:

CCME(config)# voice register dn  1
CCME(config-register-dn)# number 139
CCME(config-register-dn)# no-reg
CCME(config-register-dn)# voice register dn  2
CCME(config-register-dn)# number 140
CCME(config-register-dn)# no-reg
CCME(config-register-dn)# voice register dn  3
CCME(config-register-dn)# number 141
CCME(config-register-dn)# no-reg
CCME(config-register-dn)# voice register dn  4
CCME(config-register-dn)# number 142
CCME(config-register-dn)# no-reg
CCME(config-register-dn)# voice register dn  5
CCME(config-register-dn)# number 143
CCME(config-register-dn)# no-reg
CCME(config-register-dn)# voice register dn  6
CCME(config-register-dn)# number 144
CCME(config-register-dn)# no-reg
CCME(config-register-dn)# voice register dn  7
CCME(config-register-dn)# number 145
CCME(config-register-dn)# no-reg
CCME(config-register-dn)# voice register dn  8
CCME(config-register-dn)# number 146
CCME(config-register-dn)# no-reg

Finally, we must create a registration pool for our SPA8000 lines. One pool only is required. Note that the MAC Address configured is that of our SPA8000:

CCME(config-register-dn)# voice register pool  1
CCME(config-register-pool)# id mac 687F.7459.85EC
CCME(config-register-pool)# number 1 dn 1
CCME(config-register-pool)# number 2 dn 2
CCME(config-register-pool)# number 3 dn 3
CCME(config-register-pool)# number 4 dn 4
CCME(config-register-pool)# number 5 dn 5
CCME(config-register-pool)# number 6 dn 6
CCME(config-register-pool)# number 7 dn 7
CCME(config-register-pool)# number 8 dn 8
CCME(config-register-pool)# dtmf-relay rtp-nte
CCME(config-register-pool)# voice-class codec 1
CCME(config-register-pool)# username cisco password firewallcx
CCME(config-register-pool)# no vad
The  number 1 dn 1 command configures the extension assigned to Line 1/FXS Port 1. Likewise, the number 2 dn 2 command configures the extension assigned to Line 2 /FXS Port 2and so on. Lastly, note the username and password combination used for all lines.

At this point, the configuration is complete and the SPA8000 should start registering its 8 lines to CallManager Express.

Directory numbers assigned to the SPA8000 (139 through 146 in our example) should not be assigned as directory numbers to other IP Phones.

If we pick up a Cisco IP Phone and dial extension 139, the analog phone connected to Line 1 on our SPA8000 should ring.

Allowing Direct Transfers To SPA8000 Extensions

When using the SPA8000 most engineers are faced with a common problem:  Incoming calls cannot be transferred to the extensions assigned to the SPA8000’s lines. 

For example, we have an incoming call answered by the receptionist.  The receptionist now needs to transfer the call to extension 139, so he presses the Transfer button and enters 139 and receives a beeping busy-signal, even though extension 139 is on-hook (not talking). 

This is because extensions 139 through 146 are not directly registered with the Cisco CallManager system using the SCCP  (Skinny) protocol as normal Cisco IP Phones usually are. Extensions 139 through 146 are registered via SIP Protocol and are handled differently.

To overcome the direct transfer limitation described, we need to instruct the CallManager Express to allow the transfer of calls to the extensions assigned to our SPA8000’s lines. 

The configuration below enables direct transfers to all SIP extensions configured in our example setup:

CCME(config)# telephony-service
CCME(config-telephony)# transfer-pattern 139
CCME(config-telephony)# transfer-pattern 140
CCME(config-telephony)# transfer-pattern 141
CCME(config-telephony)# transfer-pattern 142
CCME(config-telephony)# transfer-pattern 143
CCME(config-telephony)# transfer-pattern 144
CCME(config-telephony)# transfer-pattern 145
CCME(config-telephony)# transfer-pattern 1

This completes the configuration of CallManager Express and UC500 series IP PBX systems to allow the connection and registration of Cisco SPA8000 in order to provide a cheap alternative for analog FXS ports.

This article covers extensively the upgrade process of the Cisco SPA8000 firmware so it can run the latest available version.

Upgrading The Cisco Linksys SPA8000 Firmware

Before any configuration is performed on the Cisco SPA8000, it is important to proceed with the upgrade of its firmware,to the latest available version. At the time of writing the latest firmware was released 6.1.10 (001) dated 6^th May 2011 – Filename SPA8000_6.1.10.zip.  To save time and trouble, we’ve also made the firmware available at our Cisco Downloads section.

Upgrading the SPA8000 firmware is a very simple process. Download and unzip the provided file (2.13MB). Inside, we will find 3 files:

The spa8000-6-1-10-001.bin file is the firmware that will be loaded on to the SPA8000, the spa8000_rn_v6-1-10.pdf contains the release notes and upg-spa8000-6-1-10-001.exe is the firmware upgrade program.

At this point, we run the upg-spa8000-6-1-10-001.exe executable and are presented with a window similar to this one:

At this point, we enter the IP Address of the SPA8000 to be upgraded, in the provided field and click on OK. The application provides the ability to select a different source IP Address in case there are multiple network interface cards or multiple IP Addresses bound to the workstation. 

It is possible that a username and password will be requested by the program so it can log into the SPA8000, so we need to ensure this this information is available before the upgrade process begins.

Once the firmware upgrade has successfully completed, the SPA8000 will reboot, resetting the device to its default settings.  Note that the SPA8000 default IP Address will be 192.168.0.1, default username admin and no password.

As soon as the SPA8000 reboots with its new firmware, we can enter the web administration and configure the necessary IP Address, subnet mask, default gateway and DNS servers.

The screen below confirms the firmware upgrade and settings:

This concludes our article covering how to upgrade the firmware on a Cisco - Linksys SPA8000 device.

As noted, there are two different models, the Cisco ATA 186 & 188. One of the major differences between the two models is that the Cisco ATA 188 has two RJ-45 10/100Mbps Ethernet ports, whereas the Cisco ATA 186 has only a single 10Mbps Ethernet port. One of the ports on the Cisco ATA 188 is an uplink port (connects to the switch), and the other one is a data port, allowing you to connect another network device e.g workstation or network printer, just as you would do with a Cisco IP Phone that has two Ethernet ports e.g Cisco 7911G, 7945G e.t.c.

Both models have two FXS interfaces (shown above, on the right side behind each ATA) which are used to connect two standard analog telephones or fax machines. The Cisco ATA is connected to the network via an Ethernet interface (uplink port) and can be configured via DHCP or manually. The Cisco ATA needs a 5V DC external power supply to operate . It is important to add that the Cisco ATA 186 & 188 device does not support Inline Ethernet power or Power over Ethernet (PoE).

Upgrading the Cisco ATA 186 - 188 Firmware

As with most IP Phones and VoIP network devices, the Cisco ATA firmware should be periodically updated to the latest available version. This will help ensure smooth operation and most importantly, fix any bug issues that might be present in older firmware versions.

Upgrading the Cisco ATA firmware is a fairly straight-forward process and won't require too much effort, as long as all described steps are followed. At the time of writing this article, the latest available firmware for the Cisco ATA 186 - 188 is version 3.2(4) (file name ata_03_02_04_sccp_090202_a.zip ) with release date 23/2/2009.  For the purpose of this article, this image has been made available from our Cisco IP Phone & ATA Firmware Download Section section. It is important to note that the upgrade procedure is the same for the SCCP (Skinny Protocol), SIP and H.323 firmware.

Firstly download and upzip the file in a directory, preferably c:\ata .  The zip file contains 32 files of which two are the ones we are mostly interested in and these are:

- sata186us.exe 72Kb.   This executable will serve the firmware to the ATA, so it may upload and install it.
- ATA030204SCCP090202A.zup 273Kb.  This is the firmware file for the ATA device.

To begin, open a DOS prompt and switch to the directory where you have unzipped the downloaded zip file. We assume this is the C:\ata directory. Once there, run the sata186us.exe executable with the following parameters:

Note: To complete the ATA Firmware upgrade, we will require a analog phone connected to the Phone 1 port of the Cisco ATA device. The phone will be used later on to initiate the firmware upgrade.

This command will start the server and being serving the firmware file to any ATA that connects to it. The -any parameter will allow the upgrade even if the software version is less than or equal to those of the client box. The -d1 parameter sets the verbose level for debugging to 1 (out of 3). This is handy as the server will provide enough debug output to allow tracking of the process.

Once the above command is executed, the server will begin serving the firmware file to any ATA that requests it. The service runs (listens) on UDP port 8000 and the Data Stream (transfer of firmware) on UDP port 8500, so it is important these ports are not blocked by any firewall or antvirus system or else the upgrade will fail.

Following is the output when running the sata186us executable as shown above:

The most important areas have been highlighted for your attention. The server will automatically detect and display the workstation's IP address on which it will listen for incoming connections, followed by the ports used to listen and transfer the data stream (firmware).

At this point, we need to turn to the Cisco ATA device, pickup the headset and press the ATA button on the top. This button lights 'RED' when the handset goes to a 'offhook' status e.g the headset is picked up.  Once the red ATA button is pressed, type the sequence as shown and keep the headset to your ear:

Note that the 10*0*0*90 code represents our workstation's IP address, so this will need to be substituted with your own workstation's IP address.

As soon as this command is entered via the dialpad, the ATA will initiate the firmware transfer and proceed to its upgrade.  During this time, expect a debug on the screen, similar to the following:

The firmware transfer will not require more than 10-15 seconds at the most and once successful you will hear the annoucement "Upgrade Successful".  It's a great idea at this point to reboot the Cisco ATA device and let it boot with the new firmware.

Checking and Verifying the Cisco ATA 186 - 188 Firmware Version

To verify or find out your current ATA firmware version, simply follow these easy steps:

Resetting The Cisco ATA 186 - 188 Device To Factory Default

The Cisco ATA device offers a simple mechanisim to perform a factory default reset, wiping clean all configuration changes that might have been made through the web administrative interface.

To perform a factory reset of a Cisco ATA 186 - 188, follow the steps below:

1) Take the phone off hook.
2) The red button on the top of the ATA-186 / 188 will illuminate.
3) Press the illuminating red button on the ATA and dial 322873738#. (The numbers spell FACTRESET# on the telephone)
4) Voice prompt will ask you to dial * to save changes you have just made.
5) Press * on your phone's keypad.
6) Hang up the phone.

The Cisco ATA will now reset to its factory defaults.

One popular feature is the ability to change the IP Phone's background image for IP Phones with colour or black/white LCD displays. This feature helps give a new look to the IP phone and usually comes as a pleasant surprise by the end users.

IP Phone background images are files using the .png format and are stored on the router's flash memory in a special directory named 'Desktops'.

Cisco usually provides a .zip file for each CallManager Express version. This file contains IP Phone firmware, ringtones, GUI Interface and more (Links to the download pages can be found from our CCME GUI Software Installation & Configuration article). Within each CCME zip file, you'll find a file named 'backgrounds.tar' which contains total of 6 colour backgrounds to start you off with.

Firewall.cx has made the Cisco IP Phone 'backgrounds.tar' file & custom Firewall.cx background image, available in our Cisco IP Phone Software download section.

Following are thumbnails of the backgrounds provided by Cisco. These are the background images found in 'backgrounds.tar':

Below is the standard background image loaded on every 7945, 7965, 7970 & 7975 IP Phone:

Installing the background images is a straight forward process. All that's required is to extract the 'backgrounds.tar' file directly on to the router's flash and make them available to your IP phones via the router's TFTP server.

Step 1 - Extracting the Files on to the Router's Flash

Note that there must be a TFTP server running on the workstation from where the 'backgrounds.tar' will be uploaded and extracted to the router. Enter the command to extract the 'backgrounds.tar' file from the TFTP server, directly on to the router's flash. This will also create the directory structure in the .tar file:

Extraction of the 'backgrounds.tar' file will create a root 'Desktops' directory. Under this directory, three directories are created: 320x212x12, 320x216x16 & 320x212x16. The code-naming of these directories relate to the resolution of the images they contain (e.g 320x212) and colour resolution (e.g x12). As such, different IP Phones models will look into the appropriate directory to find image files suited for their LCD screen.

For example, a Cisco CP-7965 IP phone will automatically search in the Desktops/320x212x16/ directory for a list of image files.

In each directory (e.g 320x212x12) there are three type of files found:

1) imagename.png

2) TN-imagename.png

3) List.xml

It is very important to understand the purpose of each file. Please note that filenames are case-sensitive in the Cisco IOS.

• The imagename.png file is the image the IP phone will load when selected as a new background.
• The TN-imagename.png file is the thumbnail version of imagename.png. When a user selects the Background Images menu, he will be presented with the thumbnail version of available images. If the thumbnail file for a specific image does not exist, a portion of the full-resolution image will be displayed instead.
• The List.xml file is a xml file that contains the path and list of the available images and their thumbnails. The List.xml file can include up to 50 background images. The images are in the order that they appear in the Background Images menu on the phone.

For each image, the List.xml file contains one element type, called Image Item. The Image Item element includes the following two attributes:

a) Image. The path that specifies where the phone obtains the thumbnail image

b) URL. The location of the actual image file

Below is an example of the List.xml file, showing the location of the thumbnail and full resolution image of CampusNight.png:

The List.xml file is the same file for all three directories. If an additional background image is uploaded on to the system, you must edit the List.xml file and upload it to all three directories, overwriting the existing file.

Essentially all images are stored into one directory (usually Desktops/320x212x12) and all IP phones are directed to that directory through the List.xml files.

Step 2 - Serving The Files To Our IP Phones

Once the files are loaded on the CME router, it is necessary to enter the appropriate tftp-server commands to load List.xml and all .png files and make them available to the IP phones:

Inserting Custom Background Images

As in most cases, you would want to load your own custom images. For example, we created our own Firewall.cx background image and loaded it on to our IP phones.

Here's the necessary procedure and final result:

1) Create an .png image with dimensions 320x212. We did not bother creating the thumbnail version:

2) Edit the List.xml and append the newly created image:

3) Load the image into the 'Desktops/320x212x12/' directory.

R1# copy tftp flash://Desktops/320x212x12/
Address or name of remote host []? 10.0.0.10
 Source filename []? firewall-cx-logo.png
 Destination filename [/Desktops/320x212x12/firewall-cx-logo.png]? [hit enter]
Accessing tftp://10.0.0.10/firewall-cx-logo.png...
 Loading firewall-cx-logo.png from 10.0.0.10 (via FastEthernet0/0): !
 [OK - 34493 bytes]

34493 bytes copied in 0.792 secs (43552 bytes/sec)

4) Load the modified List.xml file into all three directories (320x212x12, 320x212x16 & 320x216x16), overwriting the existing file. We only show the process for one of the three directories:

5) Enter the appropriate tftp-server commands to load the new image file and make it available to the IP phones to download:

R1(config)# tftp-server flash:Desktops/320x212x12/firewall-cx-logo.png

We are now ready to load the new background image on to our IP phone by selecting Settings > UserPreferences > Background Images> .

Notice that the IP phone will show a thumbnail version which essentially is our background image - cropped. This is because we did not create a proper thumbnail version of the background image.

Once we select the new file and save our selection, the IP phone will display it. Below if the final result on our 7945G IP phone:

Firewall.cx has made the Cisco IP Phone 'backgrounds.tar' file & custom Firewall.cx background image, available in our Cisco IP Phone Software download section.

Be sure to install the backgrounds.tar file mentioned at the beginning of this article, to create the necessary directory structure on your router's flash.

Summary

In this article we explained how to install/load background images on Cisco IP phones. We examined the files involved and the procedure that needs to be followed to create and load custom background image files. Lastly, we also provide as a free download, our custom made Firewall.cx background image and Cisco's standard images.

Installing the CallManager Express GUI Files

As mentioned in our previous article CallManager Express GUI Software Installation & Configuration - Part 1, we'll be installing the file containing the basic CallManager GUI files. This is a common practice over the full version as free space on the system's flash is often a problem.

The 40MB .tar file (cme-basic-7.1.0.1.tar) should just about it on a system with a 128MB flash that already contains the Cisco IOS on it. While this file can be viewed using Winzip, it is intended to be extracted directly on to your CallManager platform using the CLI interface.

Using the necessary commands, the cme-full-7.1.0.1.tar file is extracted directly on to the device's flash memory. This means you must ensure you have enough free space on your router or UC500 flash, otherwise the extraction process will fail.

To extract the file, launch a TFTP server and ensure the file is accessible by the tftp server, then follow the below command:

The 'archive tar /xtract' command tells the router or UC500 to load the .tar file from our tftp server and extract it directly on to the router's flash. In total, our example had 132 files of which only 18 are the essential GUI files.

Opening the .tar file using Winzip and locating the files with the path 'gui\' will reveal the GUI related files:

In the worst-case scenario, if there is limited space on the CallManager Express flash memory, simply extract the files with the 'gui\' path and upload them individually in the root directory of your flash memory.

Once uploaded on the router's flash, next step is to enable the router's http server, configure the authentication method, so that the router uses its local user accounts for authentication, and finally create a local user account with privilege 15 access and lower the file privilege level required for file operations. The file privilege command is necessary, otherwise we might experience telephony_service_server_get_action url:/ccme.html errors without any web page loading:

Alternatively, for increased security, it is possible to specify a user that will only be used for the CallManager Express GUI interface. This user will not have any other type of access to the CCME router as it is not considered a 'local account':

When entering the password or secret, type 0 reflects a non-encrypted password where as type 5 reflects an encrypted password.

We are now ready to access the Cisco CallManager Express GUI Interface using the following URL: http://10.0.0.1/ccme.html. This example assumes that the CallManager Express system is on IP address 10.0.0.1.

When typing the URL in our web browser, the system will request for a username and password. We enter the credentials accordingly and are presented with the CallManager Express homepage:

From here, we are able to configure basic system parameters, ip phone devices, create and assign extensions, receive basic call reports and much more.

The scope of this article will cover as much as the basic system parameter since the rest will be covered in future articles.

The begin setting up the basic system parameters, select 'Configure > System Parameters'. This will load the system parameter page where a number of options are available:

The most important parameters are outlined below:

As the parameters are set, the data entered are translated into CLI commands and placed under the 'Telephony-service' section of the router's or UC's configuration.

Below is the 'Telephony-service' configuration from a working CCME system. Notice that there are a lot more commands entered than available from the web interface, however it is fairly easy to locate the ones covered with the GUI interface. In-depth analysis and configuration of the telephony-service will be covered on another article:

 Once complete, Cisco CallManager Express is ready to accept new IP phones and extensions.

As a last note, we should warn that Mozzila Firefox seems to have issues handing the javascript the GUI interface uses. This is especially evident when trying to assign extensions to physical IP phone buttons.

If you are using Mozzila Firefox and stumble into problems with the GUI interface, try switching to Internet Explorer - amazingly as it might sound, no problems have been encountered with it so far!

Summary

This article covered the Cisco CallManager Express GUI interface and how it relates to different IOS versions. We examined the CCME version contained in each IOS and where to obtain the necessary files.

We also saw the information contained in each CallManager Express specification page, how to select and download the appropriate CCME GUI files and what they contain.

Closing, we showed how to install the Cisco CallManager Express GUI files onto a Cisco router or UC500 series platform and provided the necessary commands required to get the GUI working. Basic system parameters were also covered, giving a view of the available options for Cisco CallManager Express.

CallManager Express's PBX functionality is built into the IOS that runs on all the above devices. When the router or UC500 series device loads the IOS, the administrator is able to start configuring VoIP services as required.

One of the most common questions regarding CallManager Express configuration is what methods are available to actually configure the product?

Depending on the platform, there are currently up to three different ways to configure CallManager Express, . If CallManager Express is running on a ISR router (2800, 3800, 2900 & 3900 series routers) users, have the GUI Web and Command Line Interface (CLI) at their disposal, where as users on the UC500 platform have also got the Cisco Configuration Assistance (CCA) tool - an application that installs and runs on a workstation and guides you through a step-by-step menu to easily setup your VoIP PBX.

The common methods amongst the two platforms (ISR & UC500) is the Cisco CallManager Express Graphical User Interface and CLI interface. This article will explain how to install and configure the Cisco CallManager Express GUI but also cover the most important configuration options offered by it.

Matching IOS & GUI Files

Engineers who have dealt with Cisco CallManager Express will have noticed that its version changes depending on the IOS version. As noted in our Cisco CallManager Express introduction page (INSERT LINK), the CallManager Express service is embedded inside the Cisco IOS. The newer IOS, the newer CallManager Express version you get.

Remember that up to IOS version 12.4.26, only the following IOS's have the CallManager Express capabilities embedded:

- SP Services
- Adv. IP Services
- Adv. Enterprise Services

As of the latest major IOS Version, 12.5.x, Cisco has replaced all previous IOS's with one-universal IOS that has all previous IOS version features (12.4), but requires you to purchase the correct activation key to enable the additional services you need.

For example, VoIP Services such as CallManager Express are covered under the Unified Communications (UC) license. Purchasing and installing the UC activation license, will enable these features.

The table below illustrates the Cisco IOS releases, CallManager Express versioning and CallManager Express GUI version that should be used or installed on the device (router or UC500):

It is evident that there is a wide range of version to select from and as a general thumb of rule, the latest is the best option.

From experience, most version are stable enough for a production environment, however version 12.4.22T is an extremely buggy IOS version, especially when VPN tunnels are involved. It's best to try and avoid it.

As soon as the IOS version running on the router is identified, you'll need to download and install the necessary CME software and phone firmware files from the Cisco Software Download center.

For example, assume IOS version 12.4.24 (SP Services, Adv. IP services or Adv.Enterprise version) is installed on the router, according to the above table, it contains CME version 7.1 and will therefore require the relavent GUI files.

To obtain and install these files, follow the relevant link on the column named 'Specifications Link'. This will load Cisco's page where you'll be able to find all necessary files for the CME version you require.

The Specifications Link page includes a wealth of information, that includes:

The Specifications Link page is extremely important as it can help you examine if you meet the requirements and save you a lot of time and trouble. It is strongly suggested the whole page is read, so the information contained is clearly understood.

When ready, click on the 'Cisco Software Download' link as shown below, to proceed with the download of the CME GUI files:

This link will take you directly to the Cisco download area. Bare in mind that this will require a CCO account and possibly an account with permissions to download this software, otherwise no access will be provided.

As shown, the download area contains files for all CME versions, but the system will take you directly to the one selected, for our example, version 7.1.

If there's a small difference in the version e.g 7.1.0.1 instead of 7.1.0.0, it doesn't really matter as its more likely to contain small bug fixes and shouldn't create any problems.

Notice that there are two similar files from which you can select. One named 'basic' and the other 'full'. The difference between each other is purely the amount of files included.

Here's the description for the 'Full Download':

CME 7.1 Full System Files for IOS 12.4(24)T releases. Includes MOH, Ringtones, 7970/71/75 Backgrounds, the following phone loads (7906/11, 7921/25, 7931, 7937, 7941/61, 7942/62, 7945/65, 7970/71, 7975) and updated GUI files for 12.4(24)T

And the 'Basic Download':

CME 7.1 basic system files for IOS 12.4(24)T releases, includes Basic Phone Loads (7906/11, 7921, 7937, 7941/61, 7942/62) with updated GUI for 12.4(24)T

Since the difference between the two is only 30Mb, it is suggested to always download the full version, regardless if required or not. It can be stored away just in case it is needed in the future. For this example, we will download both files, but install the one containing the basic system files.

To continue reading about the installation process of the Cisco CallManager Express GUI, please continue to Part 2 of our guide.

Understanding Ephone & Ephone-dn

The Cisco CallManager Express system consists of a router (or simply a 'box' for the UC 500 series) that serves as a voice gateway (PBX) and one or more VLANs that connect IP phones and phone devices to the router.

All type of PBXs consist of physical phones and their internal directory numbers (extensions). The same concept applies in CallManager Express. The physical phones are referred to as 'ephone' which stands for 'Ethernet Phone' and the directory numbers as 'ephone-dn' short for 'Ethernet Phone Directory Number':

An ephone can represent any type/model of physical phone available and supported by Cisco. CallManager Express will recognise a physical phone device from its ephone configuration which also contains the device's MAC address.

For example, a Cisco 7945 IP Phone with a MAC address of 0027.0D3F.30B8 represents the ephone. Directory number 32 assigned to this phone represents the ephone-dn number.

Directory numbers are assigned to line buttons on phones during configuration.

This means that each physical IP Phone must be configured as an ephone. Cisco CallManager Express will recognise the physical phone from its ephone configuration MAC Address parameter.

Configuring an IP Phone in CME is a straightforward process and involves the creation of an ephone and ephone-dn entry.

The ephone holds the phone's MAC Address and button configuation, while the ephone-dn the directory number assigned to the IP Phone.

In the example above, the ephone 1 configuration binds the phone's first button (button 1) to the ephone-dn 20. Since ephone-dn 20 has been configured with directory number 300, the IP Phone will be assigned directory number 300.

To ensure we understand this concept, consider the following example:

Using the same scenario we've created three ephone-dn entries, a total of three directory numbers. We would now like to assign Phone 1, directory number 380. All that is required is to map button 1 to the approriate ephone-dn that contains number 380, that is ephone-dn 22. To achieve this, we issue the button 1:22 command under the ephone 1 configuration. IP Phone 1 now has directory number 380!

VoIP Bandwidth - Codecs

VoIP calls, just as any other network resource, require bandwidth. The amount of bandwidth required per call is governed by the type of codec configured by the system. Cisco CME and UC500 series support a variety of different codecs, making the system extremely flexible to cover any requirement.

By default, the codec used by Call Manager Express and UC500 series, is G.711 which requires 64Kbps of bandwidth – the same amount of bandwidth used by telecommunication providers for one call. Note that 64Kbps is the data payload, this means when captured into an Ethernet packet, the total amount of bandwidth will be the data payload plus the IP packet overhead, bringing the total amount to 87.2 Kbps. This is the actual bandwidth required per call per phone on an Ethernet network.

The amount of 87.2 Kbps might not seem large for an Ethernet network, however, when we need to pass the call over a WAN network this changes completely. WAN networks require bandwidth-optimised applications and services and there is no exception for VoIP calls.

For this reason, when we are dealing with situations that require optimised bandwidth control, we switch to different codecs that have much smaller bandwidth requirements, essentially allowing us to conserve precious bandwidth and money. In these cases, the G.729 codec is usually preferred, requiring only 31.2 Kbps, a generous saving of 56Kbps! In practice, this means that you can squeeze almost three G.729 VoIP calls using the same amount of bandwidth required by one G.711 VoIP call!

Apart from the evident difference in bandwidth requirements for each codec, there is also a noticeable difference in the quality of the call, G.711 being far superior in comparison with the G.729. To help provide an example, the quality of a G.711 call is similar to that of a call made between two ISDN land lines whereas a good example of G.729 quality would be a call between two mobile phones.

Taking in consideration that the quality of mobile phone calls is acceptable to everyone today, not many would complain if they had the same quality between site-to-site calls.

Of course there are other codecs that require a different amount of bandwidth, however, the two most important and popular are the G.711 and G.729 codecs. These codecs can be further configured to change their bandwidth requirements, but that's a topic to be covered in the future.

Summary

This article covered the introduction to Cisco's Call Manager Express which runs on Cisco routers and UC 500 series appliances (including UC520, UC540 & UC560). Basic concepts of VoIP technologies were introduced along with some important configuration theory related to CME's operation. Users interested can also read our Cisco CallManager Express Basic Concepts - Part 1 article.

How CCME, UC500, UC520, UC540 & UC560 Work

Before we plunge into CME initialisation & configuration, we need to introduce a few concepts and become familiar with them.

Understanding how basic functions of CallManager Express operate is crucial for the correct configuration and operation of the system. As mentioned, the CME runs on the Cisco router and provides its services to the network. IP Phones connected to the network via a switch are used to handle incoming and outgoing calls.

Once power is on, the IP phones will boot up and register with the Cisco CallManager Express. If configured, the CallManager Express will provide an extension for each IP phone and is then able to set up or tear down calls to or from the IP phones. The IP phones and CallManager Express router use a proprietary protocol called Skinny Client Control Protocol (SCCP) to communicate.

Below is a diagram illustrating roughly what goes on when one IP phone dials another IP phone, both connected to the same CallManager Express.

When a call is placed between two IP phones under the control of CallManager Express, the SCCP protocol is used to set the call up. SCCP is also commonly known as the 'skinny' protocol. The SCCP protocol is not used between two IP phones, but only between the IP phone and the Cisco CME system.

Once the call is set up, the Realtime Transport Protocol (RTP) will be used to carry the audio stream. RTP is used to carry voice inside of IP packets. RTP is a common protocol that is used to carry time-sensitive traffic like voice and real-time video. RTP is carried inside of a UDP segment, which is then carried inside an IP packet.

When the telephone session between the two IP phones ends and they hang up, a signal will be sent from each IP phone to CME to inform the server of their new status.

Voice VLAN - Separating Data and Voice Traffic

Just like any network device IP phones generate traffic during a call. This is defined as Voice over IP, or VoIP traffic. VoIP traffic is extremely sensitive to network delays that occur from bottlenecks and unavailable bandwidth. If there is a lot of traffic on the network, chances are there will be problems with the voice stream between IP Phones and CME, voice cutting and jittering being the most common VoIP problems faced by networks.

To overcome these problems, Cisco always recommends to isolate the VoIP traffic from the data traffic no matter how large or small your network is. The isolation of VoIP traffic is accomplished by the creation of a separate VLAN marked as the 'Voice VLAN'. Cisco switches have built in mechanisms that will automatically identify and prioritise VoIP traffic. This type of design will ensure that VoIP packets will have higher priority than other packets, hence minimizing or eliminating the type of problems described.

If you are not familiar with the VLAN concept, you can read all about it in our VLAN section. It includes an in-depth analysis of the concept and contains diagrams to help the learning process.

To help get the picture, here is an example of a typical network that contains a Cisco CME router connected to the Internet and pstn network, along with a Cisco voice-capable switch (it is able to identify voice packets) with a couple of workstations and IP phones.

The concept is pretty straightforward, however, pay attention to how the Cisco CME router connects to the local network and how some IP phones connect to the network and workstations behind them. Due to the fact IP phones occupy a network port to connect to the local area network, Cisco has equipped most IP phones with a switch allowing a workstation to connect directly to the IP phone.

This method obviously has the advantage of cutting in half the required switchports for IP phones and workstations. In this scenario, the link from the switch to the IP phone is configured as a 'Trunk' link where as the link between the IP phone and workstation is configured as an 'Access' link.

Trunk links allow traffic from all VLANs to pass through them, whereas Access links allow only specific VLAN traffic. In our example, we have Access Links belonging to the Data VLAN (for the workstations) and also Voice VLAN (for the IP phones).

The general idea is that we use trunk links to the IP phone and from there an access link is provided for the network device, usually a workstation. If there is only one device connecting through one port, then this can also be configured as an access link assigned to the VLAN required.

The Cisco CallManager Express router almost always connects to the core switch via a trunk link, and has access to both Data and Voice VLANs as it should. Workstation traffic is routed to the Internet via the Data VLAN, whereas voice traffic is routed to the PSTN network via the Voice VLAN.

Router Interfaces - Voice Interfaces for CallManager Express

The Cisco CallManager Express system can act as the PSTN gateway as well as managing the IP phones. There are different types of connections to the PSTN including both digital, VoIP and analog connections. The type of connection used will be dependent on the density of connections needed, technology available in the region, cost of the connections and the interfaces present on the router.

The example below shows a Cisco 2801 router populated with 4 interfaces. Each interface is inserted into one of the available four slots and, once the router is powered up, if the IOS supports the interface installed it will automatically recognise it and provide the engineer access to the appropriate CLI commands so it can be configured.

At this point, it is important to mention that there are over 90 different interface cards that can be used on Cisco routers. The two main types of interfaces are the Data interfaces and Voice interfaces.

As the name implies 'data interfaces' terminate WAN connections used to transfer/route data, whereas 'voice interfaces' terminate analogue or digital voice networks such PSTN, ISDN or PRI (E1/T1) lines, all used to carry voice.

Data interface examples are ADSL, Serial and ISDN Data cards. Below is serial data interface card normaly used to terminate leased lines connecting remote company offices with their headquaters:

Voice interface examples are ISDN Voice cards, FXO (PSTN) and FXS cards. Below is a 4 port FXO card, used to terminate PSTN lines from the telco directly to the CCME router:

The Cisco 2801 router in our example is able to handle up to 4 different interfaces, a maximum of two can be Data interface cards. This allows the following combinations:

a) 2 Data interface cards + 2 Voice interface cards

b) 4 Voice interface cards

Understanding a router's capabilities, capacity and where each voice card is used is critical to the design of a VoIP network and selection of the CME router. Cisco provides extensive information on all routers and available cards making it a lot easier to build your configuration.

Unified Communications 500 Series (includes UC520, UC540 & UC560)

The Cisco Unified Communications 500 series is what many call a 'Cisco Swiss Army Knife'.

The UC500 series practically bridges a big gap for the Small-Medium Business market as the entry level before it was a Cisco router with CME enabled software.

The UC500 series is a small appliance that combines many functions into one compact design. Functions and services include:

The UC500 series runs on its own software which is identical to Cisco's Advanced Enterprise IOS running on Cisco routers. Configuration commands are identical to those of CME and therefore all examples analysed in our VoIP section can be applied to the Cisco UC500 series without a problem.

Summary

This article covered the introduction to Cisco's Call Manager Express - Part 1, which runs on Cisco routers and UC 500 series appliances (including UC520, UC540 & UC560). Basic concepts of VoIP technologies were introduced along with some important configuration theory related to CME's operation. Our next article continues with the CCME Basic Concepts - Part 2.

Popular vendors such as Siemens, Panasonic, Alcatel and many more who, until recently, did not offer VoIP solutions saw the new wave coming and produced solutions that would allow their systems to support VoIP. However, these 'hybrid' products are not pure VoIP and do not support expected VoIP PBX features such as SIP Trunking with global providers, codec selections, H.323 call signalling protocol and more.

While Cisco never produced analogue or digital PBXs (thank goodness!) they started off right with the latest technology, which is VoIP. Carrying decades of experience with the largest portion of the switching and routing market, Cisco Call Manager and Call Manager Express were born.

Cisco CallManager, now officially named 'Cisco Unified Communication Manager' or CUCM, is a server-based IP Telephony solution and currently Cisco's flagship VoIP product. Scalable to support thousands of IP Phones by clustering multiple CUCM servers together, it is the ultimate pure VoIP solution for enterprise customers.

Recognising the need to penetrate into smaller markets, Cisco came out with a smaller version, Cisco CallManager Express, also known as CCME or CME. The new offical name here is Cisco Unified Communication Manager Express (CUCME), however most people still call it by its older name, that is CCME.

Cisco CallManager Express (CME) is a fully capable IP Telephony solution able to handle from 24 Phones up to 450 Phones depending on the router model. Perhaps the best part of CME is that it runs on Cisco routers and does not require separate hardware as is the case for CME.

Assuming you have a Cisco router, running CME can be as simple as upgrading your IOS and possibly DRAM memory. From there on, depending on your requirements, you can configure and use it immediately or you might require an additional upgrade. CallManager Express is extremely flexible because it is modular.

Downloading CallManager Express and Identifying Different Versions

CME is a software based IP Telephony system embedded in the following more advanced Cisco IOS versions. The Cisco IOS new packages are as follows and the highlighted ones provide CME functionality:

1. IP Base
2. IP Voice
3. Enterprise Base
4. Advanced Security
5. SP Services
6. Advanced IP Services
7. Enterprise Services
8. Advanced Enterprise Services

All four highlighted editions contain a full version of CME capable of covering most companies VoIP requirements.

The above IOS packages stand for all IOS upto 12.4. From version 12.5, Cisco has introduced the concept of a 'Universal IOS' that features all services (1 to 8) but are activated with the appropriate license! With IOS 15 and above, you must have a UC (Unified Communications) license activated in order to use and configure Cisco CallManager Express or voice services.

Cisco CME GUI files available for download at our Cisco CallManager Express (CCME) GUI Administration Files download page.

CME versions is also quite simple to follow. Depending on the IOS version, your CME version will also change. The latest available version at the date of writing this article is version 14.1 which is present in IOS XE version 17.11.

Cisco's Unified CME, Unified SRST, and Cisco IOS Software Version Compatibility Matrix is available for download in our Cisco IP Phone & VoIP Devices Firmware - Software download section.

Cisco CME Hardware Requirements

CME's requirements depend on the product version and platform on which it will be installed.

For example, the latest v8.1 requirements for a Cisco 2811 router are 256MB DRAM and at least 128MB Flash memory. This will provide support for up to 35 IP Phones. A Cisco 2851 router will support up to 100 IP Phones, however, it will require 384MB DRAM accompanied by at least 128MB Flash memory.

Obviously the Cisco 2851 router is a much larger model and is able to support more IP Phones, hence the increased requirements in DRAM.

With the new 2900 ISR series routers the requirements are pretty much the same for all models. For example, a Cisco 2901 router will support up to 35 IP Phones and requires 512MB DRAM with 256MB Flash memory. The Cisco 2951 will support up to 150 IP Phones and requires exactly the same amount of DRAM and Flash memory (512/256).

The reason for this is because Cisco has recently changed its IOS strategy and now provide a 'Universal' IOS that has all features built in (e.g Firewalling, VoIP, VPN etc), however, it requires an activation code in order to enable different services and functions - this might sound a great idea, but most Cisco engineers do not agree with Cisco's tactic as it seriously limits the IOS features you are able to 'test' on your routers.

Generally, if you would like to try out Cisco CallManager Express, then version 7.1 (IOS version 12.4.(24)T ) is a great starting point as it contains numerous bug fixes and enhancements. This version is also able to run on older Cisco 1760 series routers and is not tied to the licensing restrictions Cisco has introduced with IOS version 15 and above.

If you would like to learn more about CallManager Express, you can visit our Cisco CallManager Express Basic Concepts - Part 1 article.

Summary

This article introduced the Cisco CallManager Express system and covered the hardware it runs on.  Articles that follow in the voice section deal with the analysis of CallManager Express and UC500 series IP PBx's (Including UC520, UC540 & UC560) and cover from simple configuration to complex setups for demanding customers.