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

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

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

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

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

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

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

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

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

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

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

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

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