Recording MAC Address for Auto Registered CME Phones: CME Registration Made Easy!

CME has a concept of auto registration where, in fact in the default state, CME will allow (once some preliminary configuration parameters have been met) phones to register automatically. The catch is that the MAC address is not stored in the configuration file. If an ephone does not have a MAC address in the configuration, there's not much you can do with it. You can't assign buttons, phone types, or much anything else for that matter. CME spits back at you, asking you to configure a MAC address first. In the past, I've run "show ephone summary" to glean the MAC address of any registered ephones. Tonight, actually by mistake, I found that this is unnecessary. There's a much easier way, that can save you time and frustration.

First, lets look at "show ephone summary":

Click here to read the whole article

Cisco Unity Express QoS with CME

Configuring QoS between CUE and CME requires identification and re-marking of packets that match the following criteria:

  • Payload: RTP (i.e. UDP > 16384)
  • Signaling: SIP (TCP 5060)

CUE actually already marks RTP traffic as DSCP EF, and signaling (SIP) as DSCP AF31, however best practice dictates that we will make traffic on the service policy ingress. In fact, look at the access-list counters iterate when applied to the service-engine interface (this is before any QoS marking is applied - we simply apply an ACL to verify traffic characteristics):

CME#sh ip access-lists 115
Extended IP access list 115
10 permit ip host 192.168.255.98 any dscp af31 log (8 matches)
20 permit ip host 192.168.255.98 any ...

Click here to read the whole article

Impact of Configuring a DNS Domain Name on a Cisco CallManager

Configuring a new domain name on a CUCM server requires an immediate shutdown, since database replication has issues when the domain name is inconsistent, or has been recently configured. Take note: immediately after a domain is configured, the server will reset! You don't get asked again, so be prepared!!!

admin:set network domain ciscoccie.com
           *** W A R N I N G ***
Changing the networking domain name has no effect on the system
because DNS is disabled.


Continue (y/n)?y
           *** W A R N I N G ***
Adding/deleting or changing domain name on this server will break
database replication.
Once you have completed domain modification
on ...

Click here to read the whole article

Allowing More Time for Digit Entry with the SIP First Digit Entry Timer

The "first digit timer" controls the time between when a phone is taken off hook until the first digit is dialed. Increasing the timer gives users more time between going off-hook to enter digits to make a phone call. It is different to the T302 (inter-digit) timer. The "Off Hook to First Digit Timer" is configured under the SIP profile and applied to the physical IP handset. The default profile cannot be modified - the profile must be copied and then applied to specific phones.

The first digit timer comes into play whenever a new line is seized. For example:

Unauthorized SIP Messages and Authorization Failure in CME

Username configuration and authentication against the SIP registrar is absolutely critical in order for phones to register in CME when running SIP. Take a sample voice register pool configuration.

voice register pool 1
id mac 001B.D4A0.9BA0
type 7941
number 1 dn 1
dtmf-relay sip-notify
codec g711ulaw

Notice that a username has deliberately not been configured. Now, configure debug ccsip media. Observe the first message, where the IP phone attempts to regiser. CME responds with a 401 "Unauthorized" message, since authentication has failed.

======= IP Phone Registration Request =======

Jan 21 11:13:00.323: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Click here to read the whole article

Configuring CME for SIP to Allow Phones to Register

The command set using SIP is actually quite similar to SCCP - there are some subtle differences, mainly to do with entering the CME sub-configuration mode(s). This article considers the minimum steps to configure 2 x IP phones and enable calling from Phone A to Phone B.

Firstly, allow calls from SIP to SIP endpoints, and setup the SIP registrar.

voice service voip
  allow-connections sip to sip
  sip
   registrar server expires max 1200 min 300

Next, configure the global parameters; at a minimum, the following must be configured:

  1. Mode (CME)
  2. Maximum DN's (based on hardware platform - i.e. 192 in a 2821)
  3. Maximum pool, or IP phones (again, based on hardware platform)
  4. Specify ...

    Click here to read the whole article

Extension Mobility and Mismatched User Device Profiles

A user device profile (UDP) is configured, used for Extension Mobility, is created with a device type. When the user associated with the UDP logs in to a dissimilar IP phone, the default device profile and phone button template is applied. For example, if a 7961 profile is loaded on a 7941 phone, the default phone button template is applied.

In the following example, a 7975 UDP is created; the UDP contains:

  • 2 x lines (2505 and 2506)
  • 1 x speed dial

The initial configuration of the Default Device Profile uses a Phone Button Template of "Standard 7941 SCCP" (1 Line, 1 SD). Observe the behaviour when the user logs in to a 7941 IP phone. The 1st line and 1st Speed Dial are displayed on the 7941 IP Phone.

The Default Device Profile ...

Click here to read the whole article and view images

Using BAT to Subscribe Phones to Extension Mobility

The Bulk Administration Tool is a powerful weapon in any Cisco IP Telephony Engineer's arsenal. In this article we look at a step-by-step guide to enabling Extension Mobility on IP phones that have already been deployed, and are known by CUCM.

Prerequisites:

  • Phones configured in CUCM
  • Extension Mobility service enabled on at least 1 CUCM in the cluster
  • Extension Mobility service configured in CUCM

BAT allows a query to be run and services dynamically added, based on a pre-configured Phone Template. In other words, we can subscribe to Services under the Phone Template, and then reference the template with a BAT query. The first step, then, is to create a Phone Template. When using the Phone Template solely for the purpose ...

Click here to read the whole article and view images

Configuring and Verifying Basic Presence in CME

Cisco Communications Manager Express (CME) provides the ability for presence capabilities, permitting users to monitor the busy status of other local users. Presence allows users to subscribe to change in the line status of phones in the Cisco Unified CME system. This article walks through configuring the CME system with a single presence subscription, and details the steps for verification.

In CME, configuring presence requires:

  1. Enabling presence globally
  2. Allowing a DN to be monitored (watched)
  3. Configuring a busy-lamp speed dial on watcher's phone
  4. (Optionally) Allowing monitoring from the call lists (corporate directory, missed calls, etc.)

The minimum configuration required to configure basic Presence is as follows.

Click here to read the whole article

Guide to Configuring Auto Attendant in CUE with Editor Express

Cisco Unity Express (CUE) offers an integrated script editor that allows an administrator to easily create fully functioning auto attendant scripts using a convenient web interface. This article covers the requirements and process for setting up an Auto Attendant in CUE, followed by a step-by-step guide.

The process to configure an Auto Attendant in CUE is:

  1. Prepare the voice prompts. These must adhere to the following Cisco standards:
    • G711Mu Law
    • 8 Khz
    • 8 bit
    • Mono
  2. Upload the voice prompts to CUE
  3. Use Editor Express (the integrate script editing web GUI client) to create the auto attendant script
  4. Create a new IVR application
  5. Configure a dial-peer on CME to route calls to the IVR ...

    Click here to read the whole article and view images

CDR Accounting in CME Using Gateway Accounting

Gateway accounting provides a useful method in CME to gather Call Detail Records (CDRs) to determine if, when, by who, to whom and how long calls are made. This article provides an end-to-end guide to outputting CDRs in Cisco CME to a SYSLOG server. CDRs can be output in CME to:

  1. A SYSLOG server (or to local buffer)
  2. An FTP server
  3. A local flie
  4. A RADIUS server

In order to logs CDRs to a SYSLOG server, the following configuration tasks must be performed:

  • SYSLOG server operational and on the network
  • CME router configured to log to SYSLOG server
  • CME router configured for gateway accounting to SYSLOG

The relevant configuration, including SYSLOG commands, is as follows.

Click here to read the whole article and view images

Upgrading Phone Loads in CME

There are certain times when the phone load must be individually upgraded in CME. For example, lets say you are upgrading the CME system and want to upgrade the phone loads in advance. Or, there is a problem with a phone load, and TAC recommends you upgrade the load but not the whole device. Its always useful to know how to upgrade an individual phone load if required.

First, download the new phone load. This is the ZIP package available, according to phone model, here: http://www.cisco.com/kobayashi/sw-center/index.shtml (you will need a valid service contract!). The CME package comes as a tar ball that can be conveniently copied to the CME router, and then unarchived locally... No such luck with ...

Click here to read the whole article

Basic Intercom Configuration in Cisco Unified Communications Server 7.0

Intercom is a hybrid combination of a traditional line and speed dial. One user calls the intercom line of another user, and the line auto-answers with one-way audio (known as "whisper"). The recipient can acknowledge the whispered call to initiate two-way conversation.

The process for setting up an intercom line between two phones is:

  1. Configure the partition for the Intercom line(s). This step creates a partition and auto generates a CSS. Select Call Routing >> Intercom >> Intercom Route Partition
  2. Configure directory numbers for the intercom lines - the auto-generated CSS can be used, or a new CSS created; I'd personally just use the auto-generate CSS, and do in the example below. Importantly, the Default Activated Device is the actual physical device upon ...

    Click here to read the whole article and view images

Auto Registration Phone Protocol: SIP or SCCP

The default auto registration protocol allows an administrator the ability to control whether auto registered phones use a SIP or SCCP phone load. In preparation for the lab, particularly since we're all space and resource limited, changing between SIP and SCCP relatively quickly is vital. I find changing the auto registration protocol and then deleting the phones gives me the ability to quickly test protocol-specific features, such as SIP dial-rule, and SCCP PLAR.

Cisco Unified Communications Manager 7.x provides both the SCCP and SIP phone loads for most phones. The determinant in whether a phone uses either phone load (and therefore protocol) depends on how the administrator has initially entered the phone into CUCM - either manually, or automatically (according to the auto ...

Click here to read the whole article and view images

Impact of Dial-plan Pattern and E164 aliases for CUE and CME integration

One common trap that I've seen in configuring Cisco Unity Express with CME is that after voicemail integration is completed, as part of the integration with the PSTN (which usually comes later), E164 extension mapping for CLI presentation is enabled using the command "dial-plan pattern". The caveat is that this command changes the way that numbers are presented to CUE. Although this will not impact the ability for people to leave messages, it does mean that users can not simply press "Messages" on their phone to retrieve voicemail. This is because CUE no longer recognizes the CLI of the calling party. Instead of hearing "enter your password", users hear the request "enter your ID". This phenomenon has structured troubleshooting and identification steps, and a simple remedy.

In ...

Click here to read the whole article

Live Record (Cisco Unity Express) Configuration, Debugging and Verification

Live-record is a great little feature available when integrating CUE and CME; a feature that does not exist natively with CUCM. As long as the "Live Record" softkey button is assigned to a users' ephone, and the user is a valid CUE user with a mailbox, they will be able to interactively record voice conversations. The recorded conversations are stored as a message in the users mailbox. CUE periodically beeps to alert participants that the call is still being recording - this is required under certain national legislations (such as Australia).

For live-record to work correctly, conferencing must be configured and working correclty. Verify that ad hoc conferences work before proceeding with live-record. The process to enable and use Live Record is:

  1. Ensure ad hoc ...

    Click here to read the whole article

Time of Day Routing in Cisco Unified Communications Manager 7.0

Time-of-day routing allows an administrator to control call routing based on a predefined schedule. Time periods are assigned to time schedules, which are in turn assigned to partitions. Route patterns and translation patterns are then assigned to partitions, and inherit the time-of-day routing properties of their partitions.

This feature would be useful, for example, in environments where unapproved personnel could gain access to IP phones with elevated privileges. In the following example, we use time-of-day routing to make decisions concerning the routing of calls to reception.

Configuring and Using Directed Call Park

Directed Call Park provides a mechanism for telephony users to predictably place a call in a targeted park slot. When combined with park reversion to a specified DN, and busy-lamp for direct call park, there are some neat tricks and customizations that can be performed around call park.

Using directed call park is a little different to "traditional" call park which is initiated using a soft-key; with directed call park:

  • To park a call: Perform a blind transfer to the call park DN
  • To retrieve a call: Dial a prefix + the call park DN

From a configuration perspective, directed call park requires:

  1. Defining a DN or DN range for Directed Call Park. Note that although wild cards can be used (such as "80XX"), if you ...

    Click here to read the whole article and view images

Security Policies for User Passwords and Pin Numbers in Cisco UCM

User-specific security parameters such as PIN number length (for Extension Mobility), password complexity and aging (i.e. for CCM User access) are applied in CUCM on a per-user basis using credential policies. The policies are defined under "User Management" ==> "Credential Policy", and assigned under "User Management" ==> "End Users".

The security parameters and enforcement levels available to the administrator are quite granular: in the example below, the following characteristics are set:

  • minimum PIN length of 5 digits
  • require a complex (i.e. non-trivial) sequence of digits
  • disable EM login after 3 successive failures

This new security policy is applied on a per-credential, per-user basis. The credentials are now assigned under end user configuration. ...

Click here to read the whole article and view images

Using the Bulk Administration Tool to update User Device Profiles

Updating UDPs in BAT involves overwriting certain configuration parameters (as required) using a very similar method to inserting UDPs from scratch.

In the Cisco Unified Communications Manager ccmadmin page, under Bulk Administration Tools, the option is available to add a new CSV file under "Target" UDP ==> "Transaction Type" Update UDPs CSV file. The only catch is that you can't reference this file anywhere; or, at least, you can reference it under Insert UDPs, but it doesn't seem to do anything.

To update existing UDPs, the process which I have followed is:

  1. Export the current UDP records to CSV
  2. Download the generated file
  3. Using Excel (or notepad, for the die-hards), identify the records of interest, and update the fields
  4. Massage the CSV so that ...

    Click here to read the whole article and view images

Message Waiting Indication (MWI) explained: CUE and CME

Integrating Cisco Unity Express with Cisco Communications Manager Express gives an administrator granular control of Message Waiting Indication (MWI) capabilities on a per-subscriber basis. There are essentially 2 ways that MWI can be enabled between CME and CUE, and 3 configuration methods:

  1. SIP MWI (SUBSCRIBE/NOTIFY MWI)
  2. SIP MWI (Unsolicited); either
    1. explicitly configured under the sip-ua sub-configuration,
    2. or implicitly configured when MWI capabilities are assigned to ephone-dn's, using the legacy "outcall" method

In the SUBSCRIBE/NOTIFY method of MWI, a SIP UA (i.e. the IP phone) subscribes to the voice-mail server, thereby requesting notification of mailbox status. Unsolicited notification does not require IP phones to subscribe ...

Click here to read the whole article

Integrating Cisco Unity Express 3.x with Cisco Unified Communications Manager Express 7.0

Important considerations for integration between Cisco CME and CUE:

  1. IP connectivity must be enabled between CME and CUE
  2. G711Mu Law must be used, since Unity Express does not support any other codecs

To enable communication between Cisco Communications Manager Express and Cisco Unity Express, a dial-peer must be configured in CME. The following configuration provides the requirements on the CME side for CUE voicemail integration. The voicemail pilot is defined, and one DN configured to forward calls to voicemail in CFB and CFNA scenarios (note that the CUE initialization wizard does this anyway, so strictly speaking it is not absolutely necessary). In this example, 8888 is used as the pilot. Typically, the pilot number should not be part of the in-dial ...

Click here to read the whole article

Integrating Cisco Unity Express 3.x with Cisco Unified Communications Manager 7.0

Integrating Cisco Unity Express for use with Cisco Unified Communications Manager involves preparing the CUCM, then either running the initialization wizard via the CUE web GUI , or manually configuring CUE via the CLI. This article uses the web GUI for initial configuration.

For the purpose of this article, we will use a single site - a future article will discuss the impact of regions and transcoding (since CUE only uses G.711Mu law), and SRST. This article is purely concerned with integration of CUE with CUCM.

  1. Prepare CUCM. This involves creating the CTI ports, CTI route point (for the voicemail pilot, and any ancillary applications, such as Auto Attendant), creating the application user and associating to the CTI ports/RPs and, the optional but highly recommended step ...

    Click here to read the whole article and view images

Changing Application Mode of Cisco Unity Express from CCM to CCME

Cisco Unity Express, as a software application, is heavily reliant on licenses in order to determine which features are available to the network administrator. This includes integration to the call control engine, whether that be CCM or CME. When an NM-CUE first comes out of the box, it may not be licensed for the correct system - the initialization wizard can be run with the wrong system, and although integration could be completed (I have seen one such installation where this was done), the results will be less than ideal in production. The correct license should always be applied. I also know on the first time I had a module licensed for the wrong version, I freaked - I went down the path of upgrading software, which in retrospect was clearly incorrect... The key to integrating CUE with ...

Click here to read the whole article

Step-by-Step Cisco Web Dialer Guide

Like many of us I'm quite curious by nature, and when I saw a few references to Web Dialer in Cisco documentation (most notably the Features and Services Guide), my curiosity was aroused. Cisco Web Dialer is sort of a simplified Remote Call Control (or RCC, for those familiar with CUPS and OCS integration). Essentially it allows an end user the ability to CTI control their telephony device. In a single cluster environment, getting Web Dialer to work is surprisingly simple; here's how:

  1. Enable the Web Dialer Service in Cisco Unified Serviceability
  2. Configure the Webdialer servlet (or the Web Dialer Service parameters in Service Parameter Configuration). In a single cluster environment the Application Dial Rules and the List of Webdialer Servlets are not used, and the other ...

    Click here to read the whole article and view images