Configuring Cisco Unified CM Groups

CUCM groups are used for redundancy and call process load balancing using a prioritized list of CUCM primary, secondary and tertiary (backup) servers. When a device attempts to register to the primary server that may be unavailable, the device tries to register to the next secondary backup servers, if this secondary server is also unavailable the device tries the tertiary server (three CUCM servers can be listed).

Each device pool has one CUCM group assigned to it. The video shows two CUCM servers configured as backups of each other, the CUCM7PUB group has 192.168.199.10 as the primary the 192.168.199.11 as the secondary, and the CUCM7SUB has 192.168.199.11 as the primary and 192.168.199.10 as the secondary.



Note : CUCM disables autoregistration by default. Enabling autoregistration carries a security risk in that "rogue" phones can automatically register with CUCM. You should enable autoregistration only for brief periods when you want to perform bulk phone adds.

Before enabling auto-registration a protocol should be selected, such as SCCP or SIP, this is done in System > Enterprise Parameters > Auto Registration Phone Protocol



Auto-registration can be enabled by CUCM groups from System > Cisco Unified CM Group, when auto-registration is enabled on a CUCM group, the previous groups auto-registration is automatically disabled.



Auto-registration can be enabled on a specific CUCM (this server needs to be a member of the CUCM group that is configure for auto-registration) from System > Cisco Unified CM, here you must select a starting and and ending DN range, this automatically disables the "Auto-registration Disabled on this Cisco Unified Communications Manager" checkbox and enable auto-registration.

CUCM LDAP Trace Using Real-Time Monitoring Tool (RTMT)

The Real-Time Monitoring Tool (RTMT) is a client-side application from can be downloaded from CUCM Plugins. RTMT uses HTTPS and TCP to monitor CUCM system performance, device status device discovery, CTI applications, and voice messaging ports.

Traces can be activated from CUCM Servieability, RTMT is used to view the results. Even when RTMT is not running as an application, tasks such as alarm and performance monitoring updates continue to take function on the server in the background.

The following shows a trace on the DirSync service which is used for LDAP integration.



Traces need to be disabled when no longer required.

Basic Phone Configuration, Elements and Relationship

Basic endpoint configuration for IP Phones are are as follows:

• Phone NTP Reference (SIP)
• Date/Time Group
• Presence Group
  
• Device Pool (Cisco Unified CM Group, Regions and Locations)
• Common Device Configuration
  
• Security Profile
• Softkey Templates
• Phone Button Templates

Phone NTP Reference
The Phone NTP Reference is configured to ensure that SIP (Session Initiation Protocol) phones get their date and time from the NTP server from the NTP server. If the NTP server is not reachable the SIP phone uses the 200 OK response date header from the REGISTER message for the date and time. SCCP phones get their date and time information from the SCCP messages.

Date/Time Group
Devices connected to CUCM can be configured with different time zones, these time zones are configured in the Date/Time Group which then get applied to a Device Pool. One Date/Time Group can be assigned to one Device Pool and that Device Pool is assigned to one device. By default a CMLocal Date/Time Group is configured automatically at time of installation, this group is part of the system and should not be renamed.

Regions
Maximum bandwidth for audio and video calls are specified using Regions. The audio codec determines the type of compression and the maximum amount of bandwidth that is used per audio call and the video call bandwidth comprises the sum of the audio bandwidth and video bandwidth but does not include overhead. Note: The G.711 audio codec is used by default.

Locations
The implementation of call admission control (CAC) is used to regulate audio and video availability by limiting the amount of bandwidth available for audio and video calls for a location.

Device Pool
Device and location information and other device characteristics are defined using Device Pools, these are common hardware setting that are assigned to IP Phones.

Common Device Configuration
Common Device Configuration is similar to Device Pools but they are user related, such settings are Softkey Templates, Music On Hold and Locales.

Cisco Unified CM Group
CUCM Groups are used for redundancy and call process load balancing using a prioritized list of CUCM primary, secondary and tertiary (backup) servers. When a device attempts to register to the primary server that maybe unavailable the device tries to register to the next secondary backup servers, if this secondary server is also unavailable the device tries the tertiary server (three CUCM servers can be listed).

Security Profile
All devices need to be assigned a security profile. Security profiles included settings like device security mode, Certificate Authority Proxy Function (CAPF) settings, digest authentication settings (SIP only) and encrypted configuration file settings. Default none-secure profiles are configured during the installation on CUCM.

Softkey Templates
Allows CUCM administrators to configure softkey templates options according to the devices intended roles and or applications.

Phone Button Templates
Allow for the configuration of common button templates types such as Speed Dials, Lines, Privacy, Service URL, Speed Dial BLF and Call Park BLF.


Elements Involved in Configuring an IP Phone
Note: Some of these elements can applied to multiple locations, such as the 'Locations', they can be applied at the Device Pool as well as the phone configuration. In this case the phone configuration would have priority over the Device Pool configuration.

CUCM Initial Configuration - LDAP Integration

There are two types of user accounts in CUCM, they are:

• End Users: There account are associated with pyhsical people and are used for interactive logins (they can be end user or CUCM administrator depending on the user groups and roles assisted to these accounts).
• Application Users: All application users are associated with CUCM applications and or feature such as Cisco Attendant Console and Cisco Unified Contact Center Express. These accounts do not have interactive logins, they are only used for internal communication between applications.

LDAP is used so that end users and administrators are able to authenticate using corporate directory, thus allowing single logon functionality and also allows for contact lookups by using the Directories button on the Cisco IP Phone.

CUCM supports two types of LDAP integration for end users:
Note: Application user accounts are stored in the local database and are always managed from CUCM.

• LDAP synchronization: (uses a service called DirSync) using this method end users can not be added or deleted from within CUCM (user management is done using LDAP), all user and organizational data associated with the end user is managed in LDAP and synchronized the CUCM. Note: End user passwords and CUCM settings are stored locally and not in LDAP.
  
• LDAP authentication: using this method end user passwords are no longer stored locally in CUCM but in LDAP. End user accounts need to be created individually in CUCM for authentication to work, these accounts need to be identical in LDAP and CUCM (there is a possibility for user error creating these accounts, therefore it is recommened that LDAP synchronization and authenticationbe used).

Best Practices for LDAP Integration :

• Create a dedicated account on the LDAP server with administrative rights for the OU (this need to read all user objects).
• The password for this account should be set to never expire.
• Use IP addresses and remove DNS reliance.
• Multiple LDAP servers removes the single point of failure.
• Query the Active Directory Global Catalog server (faster response time).
  
• The LDAP connection between the LDAP server and CUCM should use Secure LDAP, this needs to be enabled on the LDAP and CUCM servers. (How to enable LDAP over SSL with a third-party certification authority)
  

Configuring LDAP Integration with synchronization and authentication:

1. Create the LDAP user account and assign administrative permissions
2. Active the DirSync service
3. Configure the LDAP system
4. Configure the LDAP directory (cn=, ou=, dc=)
   
5. Configure the LDAP authentication (cn=, ou=, dc=)

Note: Final notes to take into consideration:

1. LDAP users need to have First Name, Surname Name and Password fields populated.
2. In IE 7 you can not have both the https://cucm-ipaddress/ccmadmin page and https://cucm-ipaddress/ccmuser in the same browser.
3. Before the end user can login with their credentials the user should be added in UserGroup- Standard CCM End Users via "Add end users to Group"

Adding multiple users to the Standard CCM End Users can be done through the User Groups:




Additional reference link: Configuring Cisco Unified Communication Manager Directory Integration

CUCM Initial Configuration - Checking Service Parameters

After installing CUCM, some initial configuration steps need to be done before deploying endpoints, they are as follows:

1. Configure network settings
2. Verify network and feature services
3. Configure Enterprise Paraeters
4. Configure Service Parameters

Point 4. Checking Service Parameters
Service parameters are used to define settings for a specific service that was enabled by activating Feature Services. These default parameter values should be verified and or modified before registering endpoints.

Some of the most import service parameters are:

• T302 timer - Reducing this default value reduces the interdigit timer for variable length number, basically shorter post-dial delay. (See how this can be done on CUCME IOS).
  
• CDR and CMR - Used for call reporting, accounting and billing.
  
• CUCM Extension Mobility maximum login time - Logs user out of extension mobility regardless of idle timer on device.

These parameter values can be found if you goto System > Service Parameters

CUCM Initial Configuration - Enabling Feature Services

After installing CUCM, some initial configuration steps need to be done before deploying endpoints, they are as follows:

1. Configure network settings
2. Verify network and feature services
3. Configure Enterprise Paraeters
4. Configure Service Parameters

Point 2. Enabling Feature Services
Note: Network Services are required for CUCM to run, these services are automatically started after installation and can not be activated or deactivated, but the can be stopped, started and restarted.

Feature Services enable certain application such at TFTP, DHCP, Call Processing and Serviceability Reports. These services must be activated manually from CUCM Serviceability > Service Activation, these service can be activated, deactivates, stopped, started and restarted.

Forcing Database Replication in CUCM

Since the release of CUCM 6.x, subscriber servers in a cluster are now able to make read and minor write changes to the IDS (Informix Dynamic Server) database, the writes are for special applications such as user-facing features (Call Forward All, MWI, Privacy Enable/Disable, etc).

Therefor when a WAN connection is restored after an outage, these features need to be replicated to the publisher, this process normally happen automatically but in some rare cases manual reset or repair may be required. This is performed using utils dbreplication repair all or utils dbreplication reset all at the CLI (the CLI can be accessed via console or SSH, Telnet is not supported due to security reasons).

Command Line Interface Reference Guide for Cisco Unified Communications Solutions Release 7.0(1) -- Updated 3/4/2009

CUCM Initial Configuration - Configuring NTP Settings for CUCM7

After installing CUCM, some initial configuration steps need to be done before deploying endpoints, they are as follows:

1. Configure network settings
2. Verify network and feature services
3. Configure Enterprise Paraeters
4. Configure Service Parameters

Point 1. Configuring NTP Settings for CUCM7
It is extremely important that all network devices have accurate time information, as the system time for CUCM is relevant to the following:

• Cisco IP Phones
• Call Detail Records (CDR)
  
• Call Management Records (CMR)
• Alarms and Event Logs
• Some CUCM feature , e.g. time-of-day routing

The following shows how to enable a NTP reference server for CUCM (this is different to Date/Time Groups, as they define time zones for devices that register to CUCM) and is done from CUCM OS Administration, Settings > NTP Servers:

CUCM Initial Configuration - Removing DNS reliance in CUCM7

After installing CUCM, some initial configuration steps need to be done before deploying endpoints, they are as follows:

1. Configure network settings
2. Verify network and feature services
3. Configure Enterprise Paraeters
4. Configure Service Parameters

Point 1. Removing DNS reliance in CUCM7
CUCM can either use IP addresses or name to refer to other IP devices in application settings. In general, and due to the additional point of failure or configuration errors of the DNS server, the recommendation is not to use DNS with CUCM.

The following video shows how to remove DNS reliance in CUCM7:

H.225 timeout establish delay

H.225 (which is a subset of h323 and is used for call setup) has a 15 second default timeout before trying to establish a call to the PSTN. This can be modified using voice classes, as shown in the following commands:

voice class h323 tag

h225 timeout tcp establish seconds

The configuration is as follows:

voice class h323 1

h225 timeout establish 2

Apply it the dial-peer as follows:

dial-peer voice 100 voip

voice-class h323 1

Phone Firmware Files

Phone firmware files provide code to enable phone displays and operations. These files are specialized for each phone type and protocol, SIP or SCCP, and are periodically revised. The appropriate phone firmware files for the types of phones, protocol being used, and Cisco Unified CME version at your site.

Early versions of Cisco phone firmware for SCCP and SIP IP phones had filenames as follows:

• SCCP firmware—P003xxyy.bin
• SIP firmware—P0S3xxyy.bin

In both bases, x represents the major version, and y represented the minor version. The third character represents the protocol, "0" for SCCP or "S" for SIP.

In later versions, the following conventions are used:

• SCCP firmware—P003xxyyzzww, where x represents the major version, y represents the major subversion, z represents the maintenance version, and w represents the maintenance subversion.
• SIP firmware—P0S3-xx-y-zz, where x represents the major version, y represents the minor version, and z represents the subversions.
• The third character in a filename—Represents the protocol, "0" for SCCP or "S" for SIP.

For Java-based IP phones, such as the Cisco Unified IP Phone 7911, 7941, 7941GE, 7961, 796GE, 7970, and 7971, the firmware consists of multiple files including JAR and tone files. All of the firmware files for each phone type must be downloaded the TFTP server before they can be downloaded to the phone.

The following example shows a list of phone firmware files that are installed in flash memory for the Cisco Unified IP Phone 7911:

tftp-server flash:SCCP11.7-2-1-0S.loads
tftp-server flash:term06.default.loads
tftp-server flash:term11.default.loads
tftp-server flash:cvm11.7-2-0-66.sbn
tftp-server flash:jar11.7-2-0-66.sbn
tftp-server flash:dsp11.1-0-0-73.sbn
tftp-server flash:apps11.1-0-0-72.sbn
tftp-server flash:cnu11.3-0-0-81.sbn

However, you only specify the filename for the image file when configuring Cisco Unified CME. For Java-based IP phones, the following naming conventions are used for image files:

• SCCP firmware—TERMnn.xx-y-z-ww or SCCPnn.xx-y-zz-ww, where n represents the phone type, x represents the major version, y represents the major subversion, z represents the maintenance version, and w represents the maintenance subversion.

The following example shows how to configure Cisco Unified CME so that the Cisco Unified IP Phone 7911 can download the appropriate SCCP firmware from flash memory:

Router(config)#telephony-service
Router(config-telephony)#load 7911 SCCP11.7-2-1-0S

CCIE Voice Lab

I have decided to start working towards getting my CCVP, starting with CVOICE and with the intention on achieving CCIE Voice. I have put together a CCIE Voice lab at home which I will be working on in parallel during my study for CCVP. More to come...

Power over Ethernet on Cisco IP Phones Power Requirements

Power over Ethernet (PoE) is the ability to deliver 48 VDC of power over the same copper cable as Ethernet.

Different Cisco IP Phone types require varying power requirements to power the phones, the following lists those power requirements. CP-7902G (6.3W)

• CP-7905G (6.3W)
• CP-7910-SW (6.3W)
• CP-7910G (6.3W)
• CP-7912G (6.3W)
• CP-7940G (6.3W)
• CP-7960G (6.3W)
• CP-7906G (5W) (Class 2)
• CP-7911G (5W) (Class 2)
• CP-7941G (6.3W) (Class 2)
• CP-7941G-GE (12.9W) (Class 3)
• CP-7961G (6.3W) (Class 2)
• CP-7961G-GE (12.9W) (Class 3)
• CP-7970G (10.25W) (Class 3)
• CP-7971-G-GE (15.4W) (Class 3)
• CP-7985G (12.55W) (Class 0, Not full brightness)
• IEEE 802.3af Device - Class 0 (15.4W)
• IEEE 802.3af Device - Class 1 (4W)
• IEEE 802.3af Device - Class 2 (7W)
• IEEE 802.3af Device - Class 3 (15.4W)

Understanding Dial Plans

This provides and overview of the Cisco Dial Plans:

Dial Plan Component	Cisco IOS Gateway	Cisco Unified Communication Manager
Endpoint addressing	POTS dial peers for FXS ports and ephone-dn if using UCME/SRST	DN
Call routing and path selection	Dial peers	Route patterns, route groups, route lists, translation patterns, partitions, and calling search spaces
Digit manipulation	Voice translation profiles prefix, digit-strip, forward-digits, and num-exp	Translation patterns, route patterns, and route lists
Calling privileges	COR and COR lists	Partitions, calling search spaces, and FACs
Calling coverage	Dial peers, hunt groups, and call applications	Line groups, hunt lists, and hunt pilots

This information about the PSTN Dial Plan Requirements:

PSTN Requirements	Dial Plan Components
Inbound call routing	· Call routing and path selection for inbound PSTN dial peer to outbound VoIP or local dial peer · Digit manipulation to transform inbound DNIS to endpoints
Outbound call routing	· Call routing and path selection for inbound VoIP or local dial peer to outbound PSTN dial peer · Digit manipulation to transform outbound DNIS to PSTN requirements
Correct ANI presentation	· Digit manipulation to transform ANI meet PSTN requirements