CCIE Voice Study

CME gives users the ability, if they are members of a hunt-group, to interactively login and logout of hunt groups. This is achieved in normal operation through the HLog key, or using Feature Access Codes (FAC). When operating in CME fallback (/SRST) mode, however, the options are somewhat reduced. This is because the HLog key doesn't seem to behave as it should - however don't despair, as there are other options!

The answer is dynamic hunt-groups and FAC. In order to provide users the ability to login and logout of hunt-groups, the following configuration elements should be observed:

• The system must first be configured for CME fallback
• The ephone-dn's must be defined, since the permission to dynamically join groups is defined under the ephone-dn
• The ...

  Click here to read the whole article

Power over Ethernet, and utilization planning against switch capacity is an important consideration for any IT department. In addition to being a useful tool for IT managers, inline power commands can be used in such a way that we can force a phone to reset from the switch device, without affecting normal operations of the port. This can be advantageous, for example, when a PC is connected to the network via the phone.

The power utilization for each Cisco IP phone can be found here. The 7945 and 7965s are missing from this list, however testing indicates that these are Class 3 devices that draw 12 Watts in normal operation.

Observe in the following ...

Click here to read the whole article

Call simulator (csim start) is an undocumented, extremely important tool and command in any Cisco voice engineer's arsenal. It allows debugging for call routing from voice gateways and CME devices. In this article, we examine some of the various resulting outputs of "csim start {number}".

The command "csim start {number}" is executed in enable mode on an IOS device (such as a voice gateway). It allows verification of dial-plan, routing configuration and, when used with ISDN, even carrier connectivity.

csim start is quite neat, in that it:

• bypasses class of restriction (COR).
• allows verification of dial-plan without worrying about superfluous elements like DTMF relay and codec selection.

csim start can only be executed on a device ...

Click here to read the whole article

An inter-cluster trunk is a H.323 connection between 2 x CallManager clusters. It is possible to configure the trunk under Gatekeeper control, or as a simple cluster-to-cluster connection. The obvious disadvantage of the latter being scalability, but realistically this would be suitable for many mid-size implementations.

Configuring an inter-cluster trunk can broken down, in its most basic form, to:

• Configuring the inter-cluster trunk
• Configuring a route pattern to force calls between the 2 clusters

This gets a little more tricky when using overlapping number ranges. Each site uses a site-prefix that allows calls to traverse between telephony networks. So, in the example below, Site A is using 1XXX, and Site B is using the same range. ...

Click here to read the whole article and view images

When a phone re-registers in SRST to the local gateway, it can take more than 2 minutes by default when connectivity is restored to CallManager before the IP phone unregisters from SRST and reregisters to Cisco Unified Communications Manager.

This interval is controlled by the Connection Monitor Duration. This value is set globally (Enterprise Parameters) and overridden at the Device Pool.

Take a simple SRST configuration.

call-manager-fallback
 ip source-address 172.16.1.1 port 2000
 max-ephones 52
 max-dn 192
 system message primary CUCM is down... Run away!

All that is required on the CallManager side is to configure an SRST reference, and assign that reference under the device pool. Once the link ...

Click here to read the whole article and view images

Locations dictate the maximum amount of bandwidth available for simultaneous calls originating from or destinated from a site. Locations, along with Regions, are the building blocks of Call Admission Control in CallManager.

• Locations; i.e. maximum bandwidth: applied to the Device (Phone, Gateway, etc.)
• Regions; i.e. codec selection: applied to the Device Pool

The relationship between Locations and Regions is important to understand because, when the bandwidth for a Location is exhausted, no further calls can be made (without AAR, of course). Additional calls receive a reorder tone and a message, "Not Enough Bandwidth" (see in the screen-shots below)

As a general principle:

• Always assign a location based on the network topology
• Choose ...

  Click here to read the whole article and view images

Integrating CME systems with and via CallManager, without a Gatekeeper, is relatively simple, although perhaps not scalable with large implementations. Assuming a contiguous and closed dial plan (i.e. CME system 1 has DN range 4XXXX, CME system 2 has DN range 7XXXX, CUCM has range 1XXXX), it is certainly achievable to connect each CME system to CallManager, and allow CallManager to be responsible for all call routing between systems.

The main considerations for integrating multiple CME are:

• Configure CME System 1 as per this article. Make sure that calls can be connected between CME System 1 and CallManager phones, in both direcitons
• Configure ...

  Click here to read the whole article

It may be desirable in certain circumstances to mask on-net callers with another number. In CUCM this is achieved using a combination of translation patterns and calling search spaces; in CME, the implementation of on-net masking is actually a little simpler to achieve.

Let's take a scenario: IP Phone A with DN 7001, wants to contact IP Phone B. IP Phone A is a member of a hunt-group with pilot 7002, and wants the pilot to be displayed whenever an on-net call is made. By configuring outgoing translation for the calling party under the ephone-dn, this is possible and, in fact, simple to achieve.

Observe the following rule:

translation-rule 2
 Rule 0 ^7001 7002

This translation rule is then applied to the ephone-dn:

Click here to read the whole article

Configuring a H.323 connection between CME and CallManager is just like configuring a H.323 connection between a Voice Gateway and CallManager. The fact that the Gateway is providing CME services is actually incidental - CallManager needs to know how to route calls to CME, and CME needs to know how to route calls to CallManager. Certain Directory Numbers will belong to CME, and certain Directory Numbers will belong to CallManager. When the number ranges overlap, a prefix can be used to route calls between systems.

The process to integrate CME and CallManager is as follows; first, on CallManager:

• Configure a new location and region for the CME site
• Configure the H.323 gateway, route-list and route-group
• Configure a route pattern for the CME ...

  Click here to read the whole article and view images

Cisco Unity Express has the ability to route calls to an Operator Extension on the behalf of users. There are a few different ways that the Operator extension is used by Unity Express:

1. After a message is sent to a Subscriber, the caller has the option to press Hash (#) for further options. If options 1 (Standard delivery) or 2 (Urgent delivery) are selected, after the call is transferred, the caller is transferred to the Operator
2. As part of the default auto attendant, 0 can be selected (the zero-out number can be changed)
3. While listening to a personal greeting, the caller can press "0" to be transferred to the zero-out number. If this is not set under the voicemail mailbox configuration, the default system value is used

The global operator ...

Click here to read the whole article

When the hunt options for a hunt-group are exhausted (i.e., no members answer), to ensure calls are not lost it is often desirable to send calls to voicemail. The question becomes, then, where are calls delivered? In Cisco Unity Connection and Cisco Unity its possible to use Alternate Extensions (for example), but what about CUE? Although it is possible to create a subscriber specifically for voicemail for subscribers, this does limit flexibility of the solution. A better option is to use a General Delivery Mailbox (GDM). One caveat of using a GDM is that MWI notification is not available, not even to group members, however this limitation should be considered in the context of the solution. What you can do to work around this limitation is configure message notification from the GDM to ...

Click here to read the whole article

Call Pickup Group Notifications (Audio/Visual) only operate within a directory number's own group. Associated Call Pickup Groups do not trigger a notification event. For example, lets say:

• Phone A and Phone B have diretory numbers in the same call pickup group (Pickup group 1)
• Phone C is in a call pickup group with Phone D (Pickup group 2)
• Pickup group 1 has Pickup group 2 as an associated call pickup group
• If Phone E calls phone C, either Phone A or Phone B can use the "OPickup" button to pickup the call
  • Phone D receives the Call Pickup Group Notification
  • Phones A and B receive no Notification; they have no way of knowing that Phone C was ringing without the convenience of physical proximity

Associated ...

Click here to read the whole article and view images

Under the Hunt Group Pilot number configuration (Call Routing > Route/Hunt > Hunt Pilot), forwarding options for call delivery in No Answer and Busy scenarios are set. In many situations, it is desirable for an administrator to control where a call is delivered in forwaded scenarios - for example, to voicemail, or to an overflow destination. In some situations, however, users may require or request control over how calls are overflowed. Say a small hunt group of 3 users needs to forward calls to a mobile device during a team meeting - this can be achieved using Personal Preferences.

In the Hunt Group Pilot configuration, under Hunt Forward Settings, "Use Personal Preferences" can be ticked for either/or both Forward Hunt No Answer and Forward Hunt Busy. The only caveat is that ...

Click here to read the whole article and view images

The codec between phones is controlled by the Region setting, which is applied to the Device Pool and in turn the physical IP phone device. Regions are the logical and physical building blocks of the network. Each WAN site, particularly where bandwidth is at a premium, should be represented as a separate Region. Codecs are applied on Region-to-Region relations; so, for example, Remote-A to HQ. Note that codec selection must only be selected in one direction - CallManager automatically applies the converse rule.

The concept of regions is closely integrated with Locations (which control the maximum bandwidth allowed for voice calls to a site). Once a Region is created, it must be applied to the appropriate Device Pool.

To change the codec used between 2 Regions, browse to System ...

Click here to read the whole article and view images

Live Record provides the ability for IP phone users to interactively record phone conversations. Messages are delivered as voicemail messages to the party who initiates the Live Record function. A 2-party conversation or an ad-hoc conference can be recorded. An audible notification alerts participants that the conversation is being recorded (this is controlled by Cisco Unity Express).

Live Record is available when CME is integrated with Cisco Unity Express.

The following configuration tasks must be completed to enable Live Record:

• The Live Record pilot must be configured on CME under telephony-service
• The LiveRcd softkey must be assigned to an ephone template for the "connected" state, and the template in turn assigned to ephones
• The ...

  Click here to read the whole article and view images

Broadcast messages are notifications sent to all users of the telephony system. The recipients hear the message immediately after logging in to their voice mailboxes. The recipients cannot interrupt the message with any DTMF key.

Once a user is allowed to send broadcast messages, the option appears when the user logs into VoiceView Express. Broadcast messages can not be sent any other way than with VoiceView Express. Messages are recorded on the IP phone, have the start and end time set within the VoiceView interface, and are sent from the one convenient interface. The user doesn't absolutely need to set start and end time - if the message is sent immediately using the VoiceView Express TUI, the system default lifetime for a broadcast message is used (this is configurable), and ...

Click here to read the whole article and view images

VoiceView Express is a powerful tool providing a telephone-based interface for end users to manage their voicemail services. Beyond simple management of a user's inbox and Greetings management, VoiceView Express is the only interface available for a user to create and send broadcast messages. VoiceView Express is actually quite a nice interface - far better and more user friendly, I would suggest, than navigating Unity prompts. I could certainly imagine users preferring to use VoiceView Express for voicemail management.

VoiceView Express is enabled by default, however there are a few configuration tasks must be undertaken on the CME side to enable the service for users. These tasks are as follows:

• The Services URL must be configured under telephony-service. The Services ...

  Click here to read the whole article and view images

The CUE initialization wizard is handy, and certainly provides an administrator an easy way to configure a system quickly; however it is not absolutely essential to run the Wizard for CUE to operate correctly. It is also very useful to know how to configure CUE integration manually since, on first login, if the initialization wizard is not run, it is not possible to re-run the wizard (unless you factory reset, of course, which will take time!). This article walks through the minimum configuration required to integrate CUE with CME using only the CLI.

The steps required are:

• Define the SIP proxy server IP addres (i.e. the CME gateway)
• Define the voicemail application and associated a SIP trigger; in other words, the voicemail pilot
• (Optional) ...

  Click here to read the whole article

CME provides quite a powerful phone-based User Interface to end users, giving the ability to:

• Access ancillary services via the CME service URL
• Use extension mobility to login and logout of devices
• Modify speed dial buttons
• Change speed dials configured on the physical device
• Reset the device

The interface to configure speed dials is convenient and easy to use - I'd even say it's easier than giving end users access to the CME self-service web-based GUI, in fact! The phone user interface is accessed via the SERVICES button on the IP phone (the big "World" key). Note that users can only modify speed dials that have already been assigned. So, in the following example, 2 speed dials are available to ...

Click here to read the whole article

The Local Directory function of an IP phone operating in a CME environment, accessed via Directories > Corporate Directory, relies on HTTP services provided by the CME router. Security best practice typically dictates the HTTP be disabled, so ensure it is enabled before proceeding or troubleshooting. The Local Directory uses the "Name" configuration, along with the ephone-dn, to populate entries. In addition, as administrator you can add entries for lookup by all staff.

In the example below, we configure the Directory to list by Lastname first, enable the local directory and add 2 entries. Note also James and Sam's ephone-dn configuration.

ip http server
!
telephony-service
 directory last-name-first
 service local-directory
 directory ...

Click here to read the whole article

Cisco Unity Express (CUE) provides a fantastic interface which administrators and telephony users can utilize to interactively manage the voicemail system. Of particular interest is the ability to automatically record voice prompts. All prompts must have the following format to be played successfully by CUE:

• G.711 u-law
• 8 kHz
• 8 bit
• Mono

Rather than record the prompts using specialized sound editing tool (like Goldwave, or Adobe Audition), a far better alternative is to use the embedded and integrated recording tool offered by CUE. The quality of the recordings and playback is far superior to .wav files (and is the recommended method by Cisco!)

Prompts are recorded using the Administration via Telephone (AvT) interface. This interface ...

Click here to read the whole article and view images

Unlike in Cisco Communications Manager, in Cisco Communications Manager Express (CME), the DND softkey is immediately available to users. DND is part of the standard softkey template assigned to all ephones. To restrict access to DND, a custom softkey configuration must be defined under an ephone-template, which in turn must is applied to ephones.

ephone-template 1
 softkeys idle Redial Newcall Cfwdall Pickup Gpickup
softkeys ringing Answer
! notice the dnd key is removed
!
ephone 3
 ephone-template 1
!

Restricting DND access to ephones therefore requires:

• Defining a new ephone-template with the DND removed from softkey state(s); DND appears, by default, under both ...

  Click here to read the whole article

Cisco's Real-Time Monitoring Tool (RTMT) is well known (or should be!) as a highly effective tool for troubleshooting. This article considers the steps required to use RTMT to troubleshoot and identify TFTP events in the Cisco Unified Communications Manager (CUCM) environment.

The steps required to setup and use RTMT for TFTP service monitoring are:

• Download RTMT from the CallManager (you must download the exact version appropriate for your servers)
• Configure the appropriate level of logging for the TFTP service
• Open RTMT and verify, in real-time, TFTP events

If the exact filenames are of interest, then the logging level must be Significant or higher.

In the example shown below, observe the behaviour of a 7961 IP phone as a user ...

Click here to read the whole article and view images

Pinless login allows subscribers, such as individual users, to simply access their voice messages without unnecessarily entering PIN information. This could be particularly useful, for example, in user scenarios where users are particularly prone to forgetting passwords, or when a group mailbox is shared amongst multiple users, and it is not practical to require users to login - particularly when the password can be changed, or easily lost. Pinless login provides a useful solution to some frustrating user-centric problems.

This article configures pinless login for a single subscriber. Typically this would be tested by simply dialling the voicemail pilot from the subscriber's phone; we get a little more technical, and review the trace debug logs to verify pinless login is successful. ...

Click here to read the whole article

Configuring a new user (subscriber) in Cisco Unity Express involves creating the user in CUE, assigning phone numbers, and allocating space for the voice mailbox. An additional optional but recommended step is to set Call-Forward options in CME (or CCM, as the case may be).

The following example creates a new user, Steve, with extension 7001. Notice that we assign an E164 phone number as well as the 4-digit extension. The reason for this is explained here: http://www.ccievoicestudy.com/Cisco/VoIP/Impact_of_Dial-plan_Pattern_and_E164_aliases_for_CUE_and_CME_integration/. This step is optional, of course, if a dial-plan pattern has not ...

Click here to read the whole article

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

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

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

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:

• When the receiver is taken off-hook
• When the speaker button is pressed
• When "Transfer" is pressed and the party performing the transfer searches for the destination party (for example, ...

  Click here to read the whole article and view images

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

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

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

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

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

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

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

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

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

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

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 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 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.

• During Business Hours: The receptionist has a 2-line phone, both lines of which are members of a hunt-group with pilot 3333.
• After Hours: Calls ...

  Click here to read the whole article and view images

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

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

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

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

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 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

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

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

Restoring a CUE module back to factory defaults isn't as easy as simply erasing startup-configuration and reloading. You need to take CUE offline, then explicitly perform a factory reset. The "erase startup-configuration" command only, from what I can tell, removes specific system configuration parameters (NTP is one setting that is removed); users, mailboxes and administrator credentials are only removed through factory default. Factory default also allows the initialization wizard to be run upon reload.

se-192-168-255-98.localdomain# offline
!!!WARNING!!!: If you are going offline to do a backup, it is recommended
that you save the current running configuration using the 'write' command,
prior to going to the offline ...

Click here to read the whole article

Dynamic Hunt Groups are a fantastic concept in CME that allow members of the telephone system to interactively join a hunt-group. To setup a dynamic hunt-group:

1. Define at least one member of a hunt-group with a wildcard (*)
2. Individually permit each ephone-dn that should be allowed to interactively join the hunt-group
3. Configure the system to allow feature access codes

The following configuration allows 2 x locally configured numbers to interactively join a hunt-group on the system using the standard FAC codes: *3 to join the group, and #3 to leave.

!
ephone-dn 1
  number 1000
  ephone-hunt login
!
ephone-dn 2
  number 1001
  ephone-hunt login
!

Click here to read the whole article

The Cisco literature has a lot of information about best practice for enabling the CME GUI (like enabling AAA). While all good, the following is an absolute bare minimum in getting the CME GUI up and running.

1. Download the CME GUI files for 7.0.1 from here http://www.cisco.com/cgi-bin/tablebuild.pl/ip-iostsp (you will need a valid service contract). Ensure you download the right GUI version, or you may have strange results.
2. FTP or TFTP the files to the CME router, and extract the tar ball
3. Enable the HTTP server on the CME router
4. Define a web administrator under telephony-service
5. Access the CME GUI at http://your-ip-address/ccme.html

The following configuration provides ...

Click here to read the whole article

The minimum configuration to enable the CUE module for use by your IP phones involves:

• configuring IP addressing on the service-engine; and
• if you are using IP unnumbered (as is often the case), configuring a static IP route so that the Cisco CME router can route traffic towards the CUE module.

The static route installation is the bit I almost always fail to remember!

!
interface Service-Engine1/0
 ip unnumbered GigabitEthernet0/0
 service-module ip address 192.168.255.98 255.255.255.0
 service-module ip default-gateway 192.168.255.99
!
ip route 192.168.255.98 255.255.255.255 service-Engine 1/0
!

Once the configuration has been applied, you can session to the service module from the locally ...

Click here to read the whole article

The default in Cisco CME is to permit auto registration - this allows ephones to automatically register wih the CME router. While this might make initial configuration simple, it presents both a security risk and a lack of control for the configuring engineer.

Auto registration can be disabled through the explicit prevention of auto registration under telephony service:

telephony service
  no auto-reg-ephone

To verify attempted (and failed) registrations, the IOS command "show ephone attempted-registrations" can be used:

CME_ROUTER#sh ephone attempted-registrations
Attempting Mac address:
Num Mac Address DateTime DeviceType
-----------------------------------------------------------------------------

Click here to read the whole article

Since multicast is used for the streaming of MoH locally (for on-net calls) from the Cisco CME device, we can use both telephony troubleshooting and IP multicast troubleshooting commands to verify and troubleshoot MoH. Firstly, observe the behaviour of multicast group 239.0.0.1 below.

The following output of "show ip mroute" is from a steady-state - there are no calls currently on hold. Observe that group 239.0.0.1 specifies Gig0/0 as an outgoing interface, however traffic is pruned, and will therefore not be sent until an IGMP request is received downstream.

CME_ROUTER#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,

Click here to read the whole article

The multicast MoH command under telephony service can be a cause for confusion. This command forces the Cisco CME device to generate multicast Music on Hold on the interfaces specified after the "route" argument.

The route argument is only required if the SCCP address bound under telephony service is different to the interface outbound towards the IP phones. This would be common, for example, if a loopback interface is used instead of the physical Ethernet interface.

When the outbound interface is also the SCCP source IP address:

telephony-service
  multicast moh 239.0.0.1 port 16834

When a loopback interface is used as the SCCP source IP address (for example, L0 = 172.16.1.1 and GigabitEthernet0/0 = 192.168.1.1):

telephony-service

Click here to read the whole article

In CME, by default when 2 x on-net callers dial one another and one party initiates a hold, the party holding will not receive music on hold. This can be resolved by using Multicast Music on Hold. When using Multicast MoH, the CME router will transmit the audio stream on the physical IP interfaces of the specified router. Under the multicast command (in telephony-service), if the SCCP bound address under telephony-service is not the physical interface (for example, if a loopback is used), the outbound interface towards the IP phones must be specified. If they are not on the next directed subnet, multicast routing must be enabled and PIM dense or sparse mode.

telephony-services
  moh music-on-hold.au
  multicast moh 239.1.1.10 port 16384 ...

Click here to read the whole article

The following provides a guideline to enabling basic hardware conferencing in CME. There are additional options that can be tweaked, however the following is enough to get you off the ground. This will create the DSP farm and associate to the CME device for usage. Then, you'll need to create the ephone-dn's for meet-me and ad hoc conferencing. In the example below, a single ad hoc conference is configured for illustrative purposes.

1. Prepare the DSP farm and services on the voice-card
2. Configure SCCP parameters for the related application (in this instance, conferencing)
3. Create the SCCP group and define the associate parameters, such as registration ID
4. Create the dspfarm profile group for conferencing
5. Enable the Skinny Client Control Protocol (SCCP)
6. Under ...

   Click here to read the whole article

The minimum elements required to enable a phone to register with a Cisco Unified Communications Manager Express (CME) device are as follows:

1. Configure basic IP addressing and ensure routing between Phone subnet(s) and CME source IP address (ideally a loopback)
2. Configure a valid time source on the router, or setup the router as an NTP master (stratum doesn't matter)
3. Initialize CME using the command 'telephony-service'
4. Configure a valid source-address under telephony service. I recommend using a loopback address, for the same reason you'd use a loopback as the router ID for a routing protocol (virtual loopback addresses are not reliant on environmental conditions).
5. Create CNF files under telephony-service
6. Configure a maximum number of ephones ...

   Click here to read the whole article

Under System => Enterprise Parameters, change the service URL to use IP address (if not using DNS - which is unlikely in the lab, unless the router is providing DNS functions!). Otherwise the phone displays a Host Not Found error. Ensure that a phone is subscribed to at least one service, or pressing services returns a no services configured error.

Click here to read the whole article

When DN ranges overlap between sites, numbers can be prefixed with a site code using translation patterns. i.e., lets say Site A uses 1XXX and Site B also uses 1XXX. To allow both sites to be members of the same CUCM cluster, the following steps can be taken:

1. Create 2 x new partitions for each set of numbers; i.e. Site A and Site B
2. Place the DNs for each site into its own local partition
3. Assign the appropriate CSS to either the line or the phone. Ensure that the Partition for Site B does not exist in the CSS for Site A, and vice-versa
4. Create a translation pattern in each Partition to allow inter-site calling

The translation pattern must have the following characteristics:

• [Site-Code].[Range] i.e. 91.XXXX
• Set with a CSS of the target ...

  Click here to read the whole article and view images

To enable DND visual display for BLF assigned to speed-dials, specify True for BLF Status Depicts DND (CallManager Service Parameters, System - Presence group). This applies both to line appearances and directory listings (if BLF on call lists is configured). The default configuration is that BLF does not display DND status.

Click here to read the whole article and view images

When the privacy button is configured with a phone enabled for privacy, shared line privacy can be interactively enabled or disabled by the user. When the phone has privacy disabled, this button has no effect.

Click here to read the whole article

1. Create a Partition (Call Routing > Class of Control > Partition). Name the partition something like PT-PLAR-DN#)
2. Create a Calling Search Space (Call Routing > Class of Control > CSS). Add the partition created in step # 1
3. Create a translation pattern (Call Routing > Translation Pattern).
   • Translation Pattern: Blank
   • Partition: Per step # 1
   • CSS: Per step # 2
   • Called Party Transformation Mask: DN automatically dialed
4. Assign phones or lines to PLAR CSS

Click here to read the whole article and view images

To enable Barge (not cBarge, which uses conference resources), the built-in bridge must be enabled. This is set globally (CallManager Service parameters) and overriden at the phone. The default is for the built-in bridge to be disabled.

From a user perspective, to activate the remote-in-use state, when a shared line is in use on Phone A, the line on Phone B will indicate that a call is in place. Assuming Single-line Barge or Single-line cBarge are disabled, pressing the shared line on Phone B activates the Remote in Use state (the default Single Line Barge setting is Off). Barge can then be selected. Privacy is important - if Privacy is enabled on Phone A, Barge can not be enabled.

Single line barge is controlled using CallManager Service Parameter, Single Button Barge/CBarge ...

Click here to read the whole article

The Privacy button allows the end user to toggle privacy on and off. If privacy is on, the Barge and cBarge keys can never be used, since the Remote-in-Use state cannot be selected. If the Phone Privacy setting is On (default), the Privacy button should be assigned to a phone button template if Barge is required, which in turn is assigned to a device (or UDP).

Click here to read the whole article and view images

When CallManager translates a number, the Dialed number displayed on the user's phone is translated according to rules on the translation pattern. By setting the Always Display Original Dialed Number parameter to True (in Service Parameters > CallManager > Device - General), the number displayed to the end user will always be the number dialed.

One particular application of this function is Manager/Assistant scenarios. Consider the scenario where the Assistant shares a line with the Manager, and the Manager has a private line on which to receive transferred calls. In this situation, if the Assistant fields a call for the manager and transfers the call to the Manager's private line, normally the private line would be visible to the Calling Party - the private line, is therefore, no ...

Click here to read the whole article and view images

The CSS for auto registration is set under the Device Pool (System > Device Pool > Default). Note that this setting only affects the phone - the line CSS does not inherit the CSS; this must be set manually. The logical AND applied to the line and phone means that line doesn't necessarily need to be set.

Click here to read the whole article and view images

Hold reversion notifies a user who has placed a call on hold that the call is still on hold. Hold reversion is a Clusterwide parameter, defined under the Call Manager service in Service Parameters.

To remind a user after 5 seconds, and then every 15 seconds thereafter, set Hold Reversion Duration to 5, and Hold Reversion Notification Interval to 15.

Click here to read the whole article and view images

Using translation patterns it is possible to mask DN A when it calls DN B so that it appears as DN C.

• Configure a translation pattern to match the number of digits used in the dial plan (i.e. 4 digits is XXXX)
• Configure the translation pattern in the CSS assigned to DN A
• Configure the "Calling Party Transform Mask" as the DN of Phone C
• Configure the CSS on the translation pattern with a CSS that includes DN B. Important: ensure DN B does not appear in the CSS of DN A, since this would be a most specific match (i.e. "1234" is more specific than "1XXX"); if this is the case, the translation pattern will never be matched, and the non-translated number will therefore be passed to the called party.

Note that Calling Name is still presented, ...

Click here to read the whole article and view images

BLF for Call Lists is controlled by the Enterprise Parameter "BLF for Call Lists" (default is false)

This parameter allows users to review BLF status for extensions in the call lists (per Presence group status rules). The SUBSCRIBE CSS on the Phone must be set (or under the user for EM). This allows users to get the same information in the Directories Lists, accessed via the Phone UI, as if a BLF was setup on the phone, or under the EM profile.

Click here to read the whole article

To setup basic BLF speed-dial on a fixed phone (no Extension Mobility):

• Assign the lines and phones to the Standard Presence Group (auto reg phones are assigned to this group by default)
• Assign the phones, or users when using EM, to a SUBSCRIBE Calling Search Space which includes the DN of the monitored extension (only the phone or EM user performing the monitoring matters; the monitored phone SUBSCRIBE CSS has no impact).
• Assign a BLF Speed Dial to one of the phones
• Reset

Et voila, the BLF speed dial is setup from Phone A to Phone B. Next is Directory-based BLF and Presence Authorization (intra- and inter-cluster).

Click here to read the whole article

Certificate Authority Proxy Function: Using the Manufacturer Installed Certificate

Note: You must ensure that the Cisco CTL Client is installed before proceeding with CAPF.

Certificate Authority Proxy Function must be enabled on the Publisher (Serviceability).

1. Activate the CAPF service on the Publisher
2. Find the phones in Device > Phones that should be enabled to use Authorization
3. Identify the desired phone
   1. Set Certificate Operation to "Install/Upgrade"
   2. Select a key size (512, 1024 or 2048) - recommend 512 in the lab, to reduce key generation times
4. Save and Reset

Debugging :: Set log size in Serviceability, Security Services, CAPF; Gather logs in RTMT

Click here to read the whole article