CCIE Voice Study

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

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

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

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

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

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

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

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