Interactive Hunt-Group Login in CME Fallback

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 on Cisco IP Phones

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

csim start: Using and Understanding

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

Inter-Cluster Trunks and Overlapping Directory Number Ranges

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

Improving SRST Re-Convergence Time

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

Static Locations and Call Admission Control in CUCM

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:

Connecting CME Systems Together via CallManager

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:

On-Net Masking Using Ephone-DN Translation in CME

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

Integrating Cisco CallManager 7.0 and CME using H.323

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:

Transferring Calls to Operator from CUE

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