Cisco CallManager Features and Services Guide, Release 4.1(3)
Multilevel Precedence and Preemption

Table Of Contents

Multilevel Precedence and Preemption

Introducing MLPP

MLPP Terminology

Precedence

Executive Override Precedence Level

Executive Override Precedence Call Setup

Executive Override Precedence Calls Across the PRI 4ESS Interface

Preemption

Domain

Location-Based MLPP

MLPP Precedence Patterns

MLPP Indication Enabled

Precedence Call Setup

Alternate Party Diversion

MLPP Preemption Enabled

Receiving Preemption

Preemption Enabled

Preemption Details

User Access Preemption

User Access Channel Nonpreemptable

Common Network Facility Preemption

Location-Based Preemption

MLPP Announcements

Unauthorized Precedence Announcement

Blocked Precedence Announcement

Busy Station Not Equipped for Preemption

Announcements Over Intercluster Trunks

MLPP Numbering Plan Access Control for Precedence Patterns

MLPP Trunk Selection

MLPP Hierarchical Configuration

Service Parameter Special Trace Configuration

CDR Recording for Precedence Calls

Line Feature Interaction

Call Forward

Call Transfer

Shared Lines

Call Waiting

Call Preservation

Automated Alternate Routing

MGCP and PRI Protocol

MLPP Enhancements for Release 4.1

Secure Endpoints and Secure Communications

PRI 4ES UUIE-Based MLPP Interface to DRSN

Executive Override Precedence Level

Location-based MLPP

MLPP Over Intercluster Trunks

Interactions and Restrictions

Interactions

Restrictions

Installing and Activating MLPP

Configuring MLPP

MLPP Configuration Checklist

Setting the Enterprise Parameters for MLPP

Where to Find More Information


Multilevel Precedence and Preemption


The Multilevel Precedence and Preemption (MLPP) service allows properly validated users to place priority calls. If necessary, users can preempt lower priority phone calls.

Precedence designates the priority level that is associated with a call. Preemption designates the process of terminating lower precedence calls that are currently using the target device, so a call of higher precedence can be extended to or through the device.

An authenticated user can preempt calls either to targeted stations or through fully subscribed time-division-multiplexing (TDM) trunks. This capability assures high-ranking personnel of communication to critical organizations and personnel during network stress situations, such as a national emergency or degraded network situations.

This chapter covers the following topics:

Introducing MLPP

Interactions and Restrictions

Installing and Activating MLPP

Configuring MLPP

MLPP Configuration Checklist

Where to Find More Information

Introducing MLPP

The Multilevel Precedence and Preemption (MLPP) service allows placement of priority calls. Properly validated users can preempt lower priority phone calls with higher priority calls. An authenticated user can preempt calls either to targeted stations or through fully subscribed TDM trunks. This capability assures high-ranking personnel of communication to critical organizations and personnel during network stress situations, such as a national emergency or degraded network situations.

The following topics describe the MLPP service:

MLPP Terminology

Precedence

Executive Override Precedence Level

Preemption

Domain

Location-Based MLPP

MLPP Precedence Patterns

MLPP Indication Enabled

Precedence Call Setup

Alternate Party Diversion

MLPP Preemption Enabled

Preemption Details

MLPP Announcements

MLPP Numbering Plan Access Control for Precedence Patterns

MLPP Trunk Selection

MLPP Hierarchical Configuration

Service Parameter Special Trace Configuration

CDR Recording for Precedence Calls

Line Feature Interaction

Call Preservation

MGCP and PRI Protocol

MLPP Enhancements for Release 4.1

MLPP Terminology

The following terms apply to the MLPP service:

Call—All the associated connections and resources in the Architecture for Voice, Video and Integrated Data (AVVID) network.

Precedence—Priority level that is associated with a call.

Preemption—Process that terminates existing calls of lower precedence and extends a call of higher precedence to or through that target device.

Precedence call—A call with precedence level that is higher than the lowest level of precedence.

MLPP call—A call that has a precedence level established and is either being set up (that is, before alerting) or is set up.

Active call—A call that has the connection established and the calling and called parties are active on the call.

MLPP domain ID—The collection of devices and resources that are associated with an MLPP subscriber. When an MLPP subscriber that belongs to a particular domain places a precedence call to another MLPP subscriber that belongs to the same domain, MLPP service can preempt the existing call that the called MLPP subscriber is on for a higher precedence call. MLPP service availability does not go across different domains.

MLPP Indication Enabled device—In Cisco CallManager, a device for which the device and Cisco CallManager support precedence and preemption signaling procedures in the device control protocol and that is configured as such in the Cisco CallManager system.

MLPP Preemption Enabled device—In Cisco CallManager, a device for which the device and Cisco CallManager support preemption signaling procedures in the device control protocol and that is configured as such in the Cisco CallManager system. Cisco CallManager can initiate preemption on this interface.

Precedence

Precedence indicates the priority level that is associated with a call. Precedence assignment represents an ad hoc action in that the user may choose to apply or not to apply a precedence level to a call attempt. MLPP precedence does not relate to call admission control or enhanced emergency services (E911). Dedicated dial patterns in Cisco CallManager administration allow users to initiate an MLPP request. Configuration of the calling search space(s) (CSS) that is associated with the calling party (device, line, and so forth) controls a calling party's ability to dial a precedence pattern to attempt to originate a precedence call.

The Defense Switched Network (DSN) and Defense Red Switch Network (DRSN) designate the target system for initial MLPP deployment. You generally can apply mechanisms for assigning precedence levels to calls, however, in Cisco CallManager Administration to any dial plan by defining precedence dial patterns and calling search spaces that allow or restrict access to these patterns. In the DSN, a dial plan gets defined such that a precedence call is requested by using the string prefix NP, where P specifies the requested precedence level and N specifies the preconfigured MLPP access digit. Precedence priorities are as follows.

Executive Override

Flash Override

Flash

Immediate

Priority

Routine

Without specific invocation of precedence, the system processes a call by using normal call processing and call forwarding.

When a user profile is assigned to a phone, either as a default assignment or through extension mobility, the phone inherits the configuration of the assigned user, including any CSS that is associated with the user. The phone CSS can, however, override the user profile. Cisco CallManager assigns the precedence level that is associated with the dialed pattern to the call when a pattern match occurs. The system sets the call request as a precedence call with the assigned precedence level.

When a precedence call is offered to a destination, Cisco CallManager provides precedence indications to the source and destination of a precedence call, respectively, if either is MLPP Indication Enabled. For the source, this indication comprises a precedence ringback tone and display of the precedence level/domain of the call, if the device supports display. For the destination, the indication comprises a precedence ringer and display of the precedence level/domain of the call, if the device supports display.

Executive Override Precedence Level

Beginning with Release 4.1 of Cisco CallManager, the highest precedence level specifies the Executive Override precedence level. When the Executive Override precedence level preempts a lower precedence call, the Executive Override call can change its precedence level to Flash Override (next highest level), so a subsequent Executive Override call can preempt the first precedence call.

Preempting an Executive Override precedence call requires that the Executive Override Call Preemptable service parameter be set to True. If the service parameter is set to False, an Executive Override precedence call keeps its precedence level and cannot be preempted.

Figure 12-1 shows an example of two Executive Override precedence calls, one that can be preempted, and one that cannot be preempted.

Figure 12-1 Executive Override Precedence Calls Example

In the example, in Cisco CallManager cluster 1, the Executive Override Call Preemptable service parameter specifies False, whereas in Cisco CallManager cluster 2, the Executive Override Call Preemptable service parameter specifies True.

In the example, ONA makes an Executive Override precedence call to DNA from cluster 1 to cluster 2 through the T1 PRI 4ESS trunk. DNA answers, and the call connects.

In cluster 1, if ONB tries to call ONA by placing an Executive Override precedence call, ONB receives a Blocked Precedence Announcement (BPA) because Executive Override calls cannot be preempted in cluster 1. If ONB calls DNA by placing an Executive Override precedence call, the call between ONA and DNA gets preempted because Executive Override calls can be preempted in cluster 2. Likewise, if DNB calls DNA by placing an Executive Override precedence call, the subsequent Executive Override precedence call preempts the call between ONA and DNA.

Executive Override Precedence Call Setup

Figure 12-2 shows an example of the events that take place when an Executive Override precedence call gets placed.

Figure 12-2 Executive Override Precedence Call Setup

In the example, phone 1000 goes offhook and dials 9*1001. (Route pattern 9*XXXX setting specifies Executive Override.)

For the source, if this precedence call succeeds, Cisco CallManager signals Cisco IP Phone to play a ringback tone to the user. If Cisco IP Phone 1000 is MLPP Indication Enabled, precedence ringback tone plays. Otherwise, normal ringback tone plays.

If the precedence call cannot connect, a Blocked Precedence Announcement (BPA) plays if Cisco IP Phone 1000 is MLPP Indication Enabled. Otherwise, a normal reorder tone plays.

For the destination, if the Executive Override precedence call gets offered to Cisco IP Phone 1001 successfully, Cisco CallManager signals the destination to generate an audible ringer at the device. If Cisco IP Phone 1001 is MLPP Indication Enabled, a precedence ring plays. Otherwise, a normal ring plays.

Also, Cisco IP Phone 1001 displays precedence information (such as the Flash Override precedence call icon) if phone 1001 is MLPP Indication Enabled. Otherwise, no precedence information displays.

Executive Override Precedence Calls Across the PRI 4ESS Interface

Figure 12-3 shows an example of an Executive Override precedence call across the PRI 4ESS interface.

Figure 12-3 Executive Override Precedence Call Across the PRI 4ESS Interface

Cisco CallManager processes Executive Override precedence calls across the PRI 4ESS interface using the same method that it uses to process other precedence calls, except that the precedence level passes through PRI 4ESS UUIE.

The precedence information through UUIE is passed only when UUIE Status on the service parameter page is True and Passing Precedence Through UUIE is selected on the Gateway Configuration page.

Preemption

The preemption process terminates lower precedence calls that are currently using the target device, so a call of higher precedence can be extended to or through the device. Preemption includes the notification and acknowledgement of preempted users and the reservation of shared resources immediately after preemption and prior to call termination. Preemption can take one of the following forms, depending on which method is invoked:

User Access Channel Preemption—This type of preemption applies to phones and other end-user devices. In this type of preemption, if a called user access channel needs to be preempted, both the called party and the parties to which it is connected receive preemption notification, and the existing MLPP call gets cleared immediately. The called party must acknowledge the preemption before the higher precedence call completes. The called party then gets offered the new MLPP call. If the called party does not acknowledge the preemption, the higher precedence call does proceed after 30 seconds.

Common Network Facility Preemption—This type of preemption applies to trunks. This type of preemption means that the network resource is busy with calls, some of which are of lower precedence than the call that the calling party requests. One or more of these lower precedence calls gets preempted to complete the higher precedence call.


Note Ensure that all devices that a call uses to preempt an existing call are preemption enabled. Because it is not sufficient for the calling and called devices (phone) to be preemption enable, ensure that the gateways that are used for the call also are preemption enabled.


Domain

The MLPP domain subscription of the originating user determines the domain of the call and its connections. Only higher precedence calls in one domain can preempt connections that calls in the same domain are using.

Administrators enter domains in Cisco CallManager Administration as hexadecimal values of zero or greater.

Location-Based MLPP

Release 4.0 of Cisco CallManager included support for MLPP on Skinny Client Control Protocol phones and TDM (PRI/CAS) trunks. Beginning with Release 4.1, Cisco CallManager also supports MLPP on wide-area network (WAN) links. Location-based call admission control (CAC) manages WAN link bandwidth in Cisco CallManager. Enhanced locations take into account the precedence level of calls and preempt calls of lower precedence when necessary to accommodate higher precedence calls.

Enhancing locations mean that, when a precedence call arrives and not enough bandwidth can be found to connect the call to the destination location, Cisco CallManager finds the call or calls with the lowest precedence level and preempts the call(s) to make sufficient bandwidth available for a higher precedence call. If the bandwidth requirement still cannot be satisfied after going through the preemption procedure, the newly placed call fails.

Related Topic

Locations, Cisco CallManager System Guide

MLPP Precedence Patterns

To set up MLPP precedence patterns, access the Translation Pattern Configuration window in Cisco CallManager Administration where the following MLPP precedence patterns are available:

Executive override (highest)

Flash override

Flash

Immediate

Priority

Routine (lowest)

Default (means precedence level does not get changed)

Refer to the Translation Pattern Configuration section in the Cisco CallManager Administration Guide for details.

MLPP Indication Enabled

MLPP indication-enabled devices include the following characteristics:

MLPP indication-enabled devices can play preemption tones.

MLPP indication-enabled devices can receive MLPP preemption announcements that the announcement server generates.

MLPP indication-enabled devices can receive preemption.

To set up devices to enable MLPP indication, use the configuration window for each respective device. In the MLPP Indication field of each device, set the value to On.

Refer to the following topics for details of setting MLPP indication for devices:

Device Pool Configuration, Cisco CallManager Administration Guide

Gateway Configuration, Cisco CallManager Administration Guide

Cisco IP Phone Configuration, Cisco CallManager Administration Guide

Device Profile Configuration, Cisco CallManager Administration Guide

Device Profile Default Configuration, Cisco CallManager Administration Guide

Precedence Call Setup

The following sequence of events takes place during setup of a precedence call:

1. User goes off hook and dials a precedence call. The call pattern specifies NP-XXX, where N specifies the precedence access digit and P specifies the precedence level for the call.

2. The calling party receives the special precedence ringback and a precedence display while the call is processing.

3. The called party receives the special precedence ringer and a precedence display that indicates the precedence call.

Example

Party 1000 makes a precedence call to party 1001. To do so, party 1000 dials the precedence call pattern, such as 90-1001.

While the call processes, the calling party receives precedence ringback and precedence display on the calling Cisco IP Phone. After acknowledging the precedence call, the called party receives a precedence ringer (receives a special ring) and a precedence display on the called Cisco IP Phone.

Precedence Call Setup Across Intercluster Trunks

Figure 12-4 shows an example of a configuration that can be used to set up precedence calls over intercluster trunks. Because no precedence information element support exists over intercluster trunks, transmission of extra digits carries the precedence information. The dial plan must be set up appropriately on both clusters to accomplish transmission of the precedence information.

Figure 12-4 Precedence Call Setup Across Intercluster Trunks Example

In this example, 1000 dials 92-2000, which matches the appropriate precedence patterns on both clusters and sets up the precedence call.

Alternate Party Diversion

Alternate Party Diversion (APD) comprises a special type of call forwarding. If users are configured for APD, APD takes place when a precedence call is directed to a directory number (DN) that is busy or does not answer.

MLPP APD applies only to precedence calls. An MLPP APD call disables the DN Call Forward No Answer setting for precedence calls.

Precedence calls do not normally forward to voice-messaging system, as controlled by the value of the Use Standard VM Handling For Precedence Calls enterprise parameter. Refer to the "Setting the Enterprise Parameters for MLPP" section for details.

To set up APD, the administrator configures the Multilevel Precedence and Preemption Alternate Party Settings on the Directory Number Configuration window of the DN that is the target of an MLPP precedence call. Refer to the Cisco IP Phone Configuration section of the Cisco CallManager Administration Guide for details.

Example

Figure 12-5 illustrates the Alternate Party Diversion that takes place when a called party receives a precedence call and the party is configured for Alternate Party Diversion.

Figure 12-5 Alternate Party Diversion Example

In the example, a calling party placed a precedence call to party 1000. Called party 1000 has a Call Forward Busy (CFB) setting of 2000 and a Call Forward Alternate Party (CFAP) setting of 1001. The figure shows the CFB and CFAP settings for all other parties in this example.

When 1000 receives a precedence call but is busy, the call routes to party 2000. If party 2000 is also busy, the call routes to party 3000. If neither party 2000 nor party 3000 answers the call, however, the call routes to party 1001. That is, the call routes to the alternate party that is designated for the originally called party, not to the alternate parties that are designated for the Call Forward Busy parties that are associated with the originally called party.

Likewise, if party 1001 is busy and does not answer the call, the call forwards to party 5000. If party 5000 is busy, the call forwards to party 6000. If neither party 5000 nor party 6000 answers the call, however, the call forwards to party 1001's alternate party destination, which is party 1002. If party 1002 is busy or does not answer, the call forwards to party 1003, which is party 1002's alternate party designation.

MLPP Preemption Enabled

Enable MLPP preemption by explicitly configuring preemption-capable devices for preemption.

Receiving Preemption

A device that is preemption disabled (by setting the MLPP Preemption value to Disabled) can still receive precedence calls in an MLPP network, but the device itself does not get preempted. The preemption-disabled device can be connected to a call that gets preempted (at another device), in which case, the device receives preemption.

Preemption Enabled

Enable devices for preemption by setting the device MLPP Preemption value to either Forceful or Default. If the device MLPP Preemption value is set to Forceful, the system can preempt the device at its own interface. That is, the device can get preempted when a precedence call contends for the device resources.

If the device MLPP Preemption setting is Default, the device inherits its MLPP Preemption setting from its device pool. If the device's device pool MLPP Preemption setting is Forceful, or if the device pool MLPP Preemption setting is also Default but the MLPP Preemption Setting enterprise parameter value is Forceful Preemption, the device inherits preemption enabling.

To set up devices to enable MLPP preemption, use the configuration window for each respective device. In the MLPP Preemption field of each device, set the value to Forceful or Default.

Refer to the following topics for details of setting MLPP preemption for devices:

Device Pool Configuration, Cisco CallManager Administration Guide

Gateway Configuration, Cisco CallManager Administration Guide

Cisco IP Phone Configuration, Cisco CallManager Administration Guide

Device Profile Configuration, Cisco CallManager Administration Guide

Device Profile Default Configuration, Cisco CallManager Administration Guide

Preemption Details

The following types of preemption exist:

User Access Preemption

Common Network Facility Preemption

Location-based Preemption

User Access Preemption

User access preemption takes place when a user places a precedence call to a user that is already active on a lower level precedence call. Both calls are in the same MLPP domain. You can use this type of preemption for MLPP Indication Enabled phones that the Cisco Skinny Client Control Protocol controls in the Cisco CallManager MLPP system. Preemption occurs if a precedence call request is validated and if the requested precedence of the call is greater than the precedence of an existing call that is connected at the destination MLPP Preemption Enabled phone. Call processing uses a preemption tone to notify the connected parties of the preemption and releases the active call. When the called party acknowledges the preemption by hanging up, the called party gets offered the new MLPP call.

To understand the sequence of steps that takes place during user access preemption, see the following example.

Example

Figure 12-6 illustrates an example of user access preemption.

Figure 12-6 User Access Preemption Example

In the example of user access preemption, the following sequence of events takes place:

1. User 1000 places a precedence call of precedence level flash override to user 1001, who answers the call. In this example, user 1000 dials 90-1001 to place the precedence call.

2. User 1002 places a precedence call to user 1001 by dialing 9*-1001. This call is of precedence level Executive Override which represents a higher precedence call than the active precedence call.

3. While the call is directed to user 1001, the calling party receives precedence display (that is, flash override display, not executive override display), and the parties involved in the existing lower precedence call both receive preemption tones.

4. To complete preemption, the parties involved in the lower precedence call (users 1000 and 1001) hang up.

5. The higher level precedence call gets offered to user 1001, who receives a precedence ringer. The calling party, user 1002, receives precedence ringback.

Distinct preemption types take place in this instance. For the party that is not the destination of the higher precedence call, Preemption Not for Reuse takes place. Because preemption is not taking place at this interface, this device does not need to be preemption enabled. For the party that is the destination of the higher precedence call, Preemption for Reuse takes place. Because preemption does take place at this interface, ensure that this device is preemption enabled.

User Access Channel Nonpreemptable

You can configure an end-user device as MLPP Indication Enabled but not MLPP Preemption Enabled. In this case, a phone that can generate MLPP indications (using special preemption tones and ringers) does not have preemption procedures supported in its device control protocol in Cisco CallManager. The administrator can also disable preemption procedures for a phone even though Cisco CallManager Administration supports the procedures.

Historically, user access devices (phones) have limited or no mechanisms for handling multiple, simultaneous calls. Even with the Call Waiting feature, many phones and associated switches do not have a mechanism to allow the user to manage multiple calls simultaneously on the same line.

Cisco CallManager Administration effectively enhances the Call Waiting feature to provide this capability for users of Cisco IP Phones (model 794X and 796X series). These Cisco IP Phones include a user interface that gives the user adequate control of multiple, simultaneous calls when interfacing with the Cisco CallManager system. This enhanced functionality allows the Call Waiting feature to be applied to all precedence calls that are directed to these types of phones, even though the user may already be managing other calls. When the user receives a precedence call, the user at a destination phone can decide what to do with any existing calls instead of merely releasing the lower precedence call. For users of these devices, the Cisco CallManager administrator can configure devices as not MLPP Preemption Enabled to take advantage of this function in Cisco CallManager.

Common Network Facility Preemption

Common network facility preemption applies to network resources, such as trunks, in the MLPP system. When a common network facility gets preempted, all existing parties receive notification of the preemption, and the existing connection immediately gets disconnected. The new call gets set up by using the preempted facility in the normal manner without any special notification to the new called party. PRI and T1-CAS trunks on targeted MGCP gateway platforms support this type of preemption in Cisco CallManager.

Preemption occurs if a precedence call request is validated and if the requested precedence of the call is greater than the precedence of an existing call through the destination MLPP Preemption Enabled trunk and the trunk is completely busy (that is, cannot handle any more calls). Call processing identifies a call with lower precedence, notifies the connected parties of the preemption for the PRI trunk interface, reserves the channel for subsequent use, and drops the selected lower precedence call. The system uses the reserved channel to establish the connection through the gateway for the precedence call that caused preemption.

For the sequence of steps that takes place during common network facility preemption, see the following examples.

Example 1

Figure 12-7 illustrates an example of common network facility preemption.

Figure 12-7 Common Network Facility Preemption Example

In the example of common network facility preemption, the following sequence of events takes place:

1. User 1000 places a precedence call of precedence level Flash Override to user 2000, who answers the call. In this example, user 1000 dials 90-2000 to place the precedence call. The flash call of precedence level Flash Override specifies active.

The call uses a common network facility where the two gateways define a fully subscribed TDM trunk.

2. User 1001 next places a higher precedence (executive override) call to user 2001 by dialing 9*-2001. (Assume that the flash call represents the lowest precedence call over gateway A, and users 1000 and 1001 reside in the same MLPP domain.)

Preemption occurs at gateway A, which is preempted for reuse. Because preemption occurs at this interface, you must ensure that this device is preemption enabled. Gateway B also gets preempted for reuse, but the preemption does not occur at this interface, so this device does not need to be preemption enabled.

Users 1000 and 2000 both receive preemption tones. Because both devices are not preempted for reuse and preemption does not occur at these interfaces, you do not need to ensure that these devices are preemption enabled for the preemption to occur.

In this example, almost all events occur instantly. Parties do not need to hang up for common network facility preemption to occur.

Example 2

Figure 12-8 illustrates an example of common network facility preemption with the retry timer Trr. The retry timer Trr provides a mechanism, so if preemption is not successful on one channel, preemption gets retried on another channel. This timer applies only to TDM trunks.

Figure 12-8 Common Network Facility Preemption Example with Retry Timer Trr

In the example of common network facility preemption with the retry timer Trr, the following sequence of events takes place:

1. An incoming call with Flash Override precedence arrives at a PRI trunk device.

The incoming call causes preemption of channel 3, but a response does not occur within the time that the retry timer Trr specifies.

2. Retry timer Trr expires.

Channel 3 gets preempted.

3. This preemption causes a response, and the precedence call gets offered on channel 1.

Location-Based Preemption

The following examples illustrate location-based preemption.

Example 1

In the example that follows, the new call and the location-preempted call take place in different devices. See Figure 12-9 for an example of this type of location-based preemption.

Figure 12-9 Location-Based Preemption in Different Devices

This example illustrates the location-based preemption scenario. In the example, three locations exist:

Remote location 0 (RL0) with phone A and 160K of available bandwidth

Remote location 1 (RL1) with phones B and C and 80K of available bandwidth

Remote location 2 (RL2) with phone D and 240K of available bandwidth

The following sequence of events takes place:

1. A places a call to B with Priority precedence level, and the call becomes active. The available bandwidth specifies 80K in RL0, 0K in RL1, and 240K in RL2.

2. D calls C with Immediate precedence level. D's call preempts the call between A and B because RL1 is out of bandwidth and D's call has higher precedence.

3. The call between D and C completes. The available bandwidth specifies 160K in RL0, 0K in RL1, and 160K in RL2.

Example 2

In the example that follows, the new call and the location preempted call take place in the same device. See Figure 12-10 for an example of this type of location-based preemption.

Figure 12-10 Location-Based Preemption in the Same Device

This example illustrates the location-based preemption scenario. In the example, three locations exist:

Remote location 0 (RL0) with phone A and 160K of available bandwidth

Remote location 1 (RL1) with phone B and 80K of available bandwidth

Remote location 2 (RL2) with phone D and 240K of available bandwidth

The following sequence of events takes place:

1. A places a call to B with Priority precedence level, and the call becomes active. The available bandwidth specifies 80K in RL0, 0K in RL1, and 240K in RL2.

2. D calls B with Immediate precedence level. D's call preempts the call between A and B because RL1 is out of bandwidth and D's call has higher precedence.

3. B receives the preemption tone first, and the End call softkey displays.

4. B presses the End softkey, hangs up, or waits for timeout. The call from D to B gets offered to B. When the call from D to B completes, the available bandwidth specifies 160K in RL0, 0K in RL1, and 160K in RL2.

MLPP Announcements

Users who unsuccessfully attempt to place MLPP precedence calls receive various announcements that detail the reasons why a precedence call was blocked.

The following sections discuss specific MLPP announcements:

Unauthorized Precedence Announcement

Blocked Precedence Announcement

Busy Station Not Equipped for Preemption

Announcements Over Intercluster Trunks

The Supported Tones and Announcements topic in the Annunciator section of the Cisco CallManager System Guide discusses MLPP announcements. Refer to the Route Pattern Configuration and Translation Pattern Configuration sections in the Cisco CallManager Administration Guide for details of configuring the Precedence Level Exceeded condition that generates the Unauthorized Precedence Announcement.

Related Topics

Annunciator, Cisco CallManager System Guide

Annunciator Configuration, Cisco CallManager Administration Guide

Route Pattern Configuration, Cisco CallManager Administration Guide

Translation Pattern Configuration, Cisco CallManager Administration Guide

Unauthorized Precedence Announcement

Users receive an unauthorized precedence announcement when they attempt to make a call with a higher level of precedence than the highest precedence level that is authorized for their line. A user receives an unauthorized precedence announcement when the user dials a precedence call by using a calling pattern for which the user does not have authorization.

Cisco CallManager recognizes the Precedence Level Exceeded condition only if specific patterns or partitions are configured to block a call attempt that matches the pattern and that indicates the reason that the call is blocked.

To assign authorized calling patterns, access the Route Pattern/Hunt Pilot Configuration and the Translation Pattern Configuration windows in Cisco CallManager Administration. To configure the MLPP Precedence Level Exceeded condition, use the Route Option field of the Route Pattern/Hunt Pilot Configuration and Translation Pattern Configuration windows and choose the Block this pattern option in Cisco CallManager Administration. In the drop-down list box, choose Precedence Level Exceeded. Refer to the Route Pattern Configuration and Translation Pattern Configuration sections of the Cisco CallManager Administration Guide for details.

Example

Figure 12-11 illustrates an example of a user that receives an unauthorized precedence announcement.

Figure 12-11 Unauthorized Precedence Announcement Example

In the example, user 1002 dials 90 to start a precedence call. Nine (9) represents the precedence access digit, and zero (0) specifies the precedence level that the user attempts to use. Because this user is not authorized to make flash override precedence calls (calls of precedence level 0), the user receives an unauthorized precedence announcement.

Blocked Precedence Announcement

Users receive a blocked precedence announcement if the destination party for the precedence call is off hook, or if the destination party is busy with a precedence call of an equal or higher precedence and the destination party does not have the Call Waiting nor Call Forward features nor a designated party for alternate party diversion (APD), or due to a lack of a common network resource.

Example

Figure 12-12 provides an example of a blocked precedence announcement.

Figure 12-12 Blocked Precedence Announcement Example

In this example, user 1000 makes a precedence call to user 1001 by dialing 90-1001. Because user 1001 is either off hook or busy with a precedence call of equal or higher precedence level and user 1001 does not have Call Waiting nor Call Forward nor an alternate party that is designed for alternate party diversion, user 1000 receives a blocked precedence announcement.

Busy Station Not Equipped for Preemption

Users receive this announcement if the dialed number is nonpreemptable. That is, the dialed number registers as busy and has no call waiting, no call forwarding, and no alternate party designations.

Announcements Over Intercluster Trunks

Figure 12-13 illustrates an instance of an MLPP announcement that is streamed over an intercluster trunk.

Figure 12-13 MLPP Announcement Over an Intercluster Trunk Example

In the example, phones 1000 and 2000 reside on two clusters that an intercluster trunk connects. User 2000 does not have features such as calling waiting and call forwarding configured.

The following sequence of events takes place:

1. User 2000 goes off hook and starts to dial. (Status for User 2000 specifies originating busy and not preemptable.)

2. User 1000 then dials a precedence call over the intercluster trunk to user 2000. Because user 2000 is busy and is not preemptable, the call gets rejected.

3. Because user 1000 originated a precedence call, the call receives precedence treatment, and the announcement server on the remote cluster streams the appropriate Blocked Precedence Announcement (BPA) to 1000 with the switch name and the location of the cluster.

MLPP Numbering Plan Access Control for Precedence Patterns

MLPP uses the calling search spaces and partitions that are defined for users to authenticate and validate MLPP calls and provide access control for precedence patterns.

The maximum precedence of a user gets set at user configuration time. All MLPP-capable station devices get configured as either MLPP-enabled or MLPP-disabled. A device to which a user profile is applied inherits the precedence level of that user with respect to precedence calls that are initiated from that device. A device that has a default user assigned inherits a Routine precedence level for the default user.

Configuration of the calling search space(s) (CSS) that is associated with the calling party controls a user's ability to dial a precedence pattern (that is, to initiate a precedence call). Cisco CallManager does not provide for explicit configuration of an explicit maximum allowed precedence value.

The following example illustrates the differences in access to precedence calls for two users who try to place a priority-level precedence call to a third user.

Example

Figure 12-14 provides an example of MLPP numbering plan access control for precedence patterns.

Figure 12-14 MLPP Numbering Plan Access Control for Precedence Patterns Example

The table defines three users in this illustration:

User
Directory Number (DN)
Partition
Calling Search Space (CSS)

General

1000

Routine

Flash Override

Major

2000

Routine

Priority

Private

3000

Routine

Routine


The example shows the use of partitions and calling search spaces to limit access to precedence calls.

If private 3000 tries to place a precedence call by dialing the precedence pattern 93, the following events take place:

Call processing searches for private 3000's calling search space, which is the Routine CSS.

Within private 3000's Routine CSS, call processing finds the Block Priority partition.

In the Block Priority partition, call processing finds the pattern 93 and goes to translation pattern 93.

Translation pattern 93 determines that priority calls are blocked for this user (DN), and call processing issues an unauthorized precedence announcement (UPA).

If major 2000 places a precedence call by dialing the digits 931000, the following events take place:

Call processing searches for major 2000's calling search space, which is the Priority CSS.

Within major 2000's Priority CSS, call processing finds the Priority partition.

In the Priority partition, call processing finds the pattern 93.XXXX and goes to translation pattern 93.XXXX.

Translation pattern 93.XXXX determines that priority calls are authorized for this user (DN). Call processing therefore completes the Priority-level precedence call to user 1000, the general.

MLPP Trunk Selection

MLPP trunk selection entails hunting for available trunks by using route lists and route groups. In Cisco CallManager Administration, you can configure a route list and associated route group(s) to route calls to several gateways via a single dial pattern to find an available channel. Although a route list has many trunk resources to which the route list can route calls, the individual resources may spread across many gateways.

When no available trunk resource is identified in a collection of gateways (that is, a route list and route group configuration), Cisco CallManager attempts to initiate preemption of a lower level precedence shared resource in the collection. Two method exist for subsequently searching for a preemptable channel within a route list and route group configuration.

Method 1

Configure a route list and a separate route group for each available route (trunk interface). Designate one route group as the Direct route group and designate the other route groups as Alternate route groups. Add the Direct Route trunk interface (gateway) as the only member of the Direct route group. Add the Alternate Route gateways to the individual Alternate route groups. Associate the route groups with the route list, configuring the Direct route group as the first route group in the route list, and choose the Top Down distribution algorithm for each route group association.

Using this configuration, the Direct gateway in the Direct route group gets searched for an idle channel first. If no idle channel is found in the Direct gateway, the system initiates preemptive trunk selection for this Direct gateway as follows:

Call processing chooses the Direct route and offers the call to this gateway device to determine whether the gateway device can initiate preemption.

If the Direct gateway device rejects the precedence call request (that is, the gateway device cannot initiate preemption), choose the next route group in the route list as the current route. Continue this sequence until an idle channel is found on the current gateway, or until the current gateway device has initiated preemption, or until all gateway devices in the route list and route group collection are searched.

Method 2

Configure a route list and a single route group. Add trunk interfaces (gateways) to the route group and position the Direct Route gateway as the first gateway in the route group. Associate the route group with the route list and choose the Top Down distribution algorithm. With this configuration, the system searches all gateways in the route group for an idle channel first. If no idle channel is found in any gateway in the route group, preemptive trunk selection begins with the first gateway in the route group (that is, the Direct Route gateway) as follows:

Call processing chooses a current route from the collection on the basis of the distribution algorithm and offers the call to this gateway device to determine whether the gateway device can initiate preemption.

If the current gateway device rejects the precedence call request (that is, the gateway device cannot initiate preemption), call processing chooses the next gateway in the collection as the current route and continues this sequence until a gateway device initiates preemption or until all gateway devices in the route list and route group collection have been searched.

Example

The following example illustrates two methods for finding an available trunk device when an incoming flash-level precedence call seeks an available trunk device.

Figure 12-15 provides an example of MLPP trunk selection using route lists and route groups to hunt for an available trunk device.

Figure 12-15 MLPP Trunk Selection (Hunting) Example

In method 1, the following sequence of events takes place:

1. An incoming flash-level precedence call reaches route list RL and first goes to route group RG1, which directs the call to Trunk Device1, which is busy.

For Trunk Device1, calls must be of a higher precedence than flash to preempt calls that are using this device.

2. The call therefore seeks the next route group in route list RL, which is route group RG2. Route group RG2 contains Trunk Device2, which is also busy, but precedence calls of a precedence level higher than Priority can preempt Trunk Device2.

Because this call is a higher precedence call, the call preempts the existing call on Trunk Device2.

In method 2, the following sequence of events takes place:

1. An incoming flash-level precedence call reaches route list RL, which contains only one route group, RG1.

2. Route group RG1 contains three trunk devices.

Of the three trunk devices in RG1, Trunk Device1 and Trunk Device2 register as busy, so the system offers the call to Trunk Device3, which is available.

MLPP Hierarchical Configuration

MLPP settings for devices follow this hierarchy:

If a device MLPP Indication is set to Off, the device cannot send indication of MLPP calls. If the device MLPP Preemption is set to Disabled, the device cannot preempt calls. These settings override the device's device pool settings.

If a device MLPP Indication is set to On, the device can send indication of MLPP calls. If the device's MLPP Preemption is set to Forceful, the device can preempt calls. These settings override the device's device pool settings.

If a device's MLPP Indication is set to Default, the device inherits its ability to send indication of MLPP calls from the device's device pool. If the device MLPP Preemption is set to Default, the device inherits its ability to preempt calls from the device's device pool.

MLPP settings for device pools follow this hierarchy:

If a device pool MLPP Indication is set to Off, devices in the device pool cannot send indication of MLPP calls. If the device pool MLPP Preemption is set to Disabled, devices in the device pool cannot preempt calls. These settings override the MLPP enterprise parameter settings.

If a device pool MLPP Indication is set to On, devices in the device pool can send indication of MLPP calls. If the device pool MLPP Preemption is set to Forceful, devices in the device pool can preempt calls. These settings override the MLPP enterprise parameter settings.

If a device pool MLPP Indication is set to Default, the device inherits its ability to send indication of MLPP calls from the MLPP Indication Status enterprise parameter. If the device pool MLPP Preemption is set to Default, the device pool inherits its ability to preempt calls from the MLPP Preemption Setting enterprise parameter.

The MLPP Indication Status enterprise parameter defines the indication status of device pools and device pools in the enterprise, but nondefault settings for device pools and individual devices can override its value. The default value for this enterprise parameter specifies MLPP Indication turned off.

The MLPP Preemption Setting enterprise parameter defines the preemption ability for device pools and devices in the enterprise, but nondefault settings for device pools and individual devices can override its value. The default value for this enterprise parameter specifies No preemption allowed.

The MLPP Domain Identifier enterprise parameter specifies the MLPP domain. The MLPP service applies only to a domain; that is, only to the subscribers and the network and access resources that belong to a particular domain. Connections and resources that belong to a call from an MLPP subscriber get marked with a precedence level and an MLPP domain identifier. Only calls of higher precedence from MLPP users in the same domain can preempt lower precedence calls in the same domain.

Service Parameter Special Trace Configuration

MLPP issues a service parameter for tracing.

Refer to the Cisco CallManager Serviceability System Guide and the Cisco CallManager Serviceability Administration Guide for details.

CDR Recording for Precedence Calls

MLPP precedence calls generate call detail records (CDRs). The CDR identifies the precedence level of the precedence call.

The same precedence levels of the call legs generally apply. With transfer or conference calls, the precedence levels can differ; therefore, Cisco CallManager CDRs identify the precedence level of each leg of the call.

Cisco CallManager CDRs document the preemption value for preempted call terminations.

Refer to the Cisco CallManager Serviceability System Guide and the Cisco CallManager Serviceability Administration Guide for details.

Line Feature Interaction

MLPP interacts with line features as described in the following sections:

Call Forward

Call Transfer

Shared Lines

Call Waiting

Call Forward

MLPP interacts with the call forward features as described in the following list:

Call Forward Busy

You optionally can configure a preconfigured Precedence Alternate Party target for any MLPP-enabled station.

Cisco CallManager applies the Call Forward Busy feature to forward a precedence call in the usual manner prior to applying any Precedence Alternate Party Diversion procedures to the call.

If the incoming precedence call is of equal or lower precedence than the existing call, call processing invokes normal call-forwarding behavior.

If the destination station for a precedence call is nonpreemptable (that is, not MLPP-configured), call processing invokes call-forwarding behavior.

The system preserves precedence of calls across multiple forwarded calls.

If the incoming precedence call is of higher precedence than the existing call, preemption occurs. Both the preempted parties in the active call receive a continuous preemption tone until the station to which the precedence call is directed hangs up. After hanging up, the station to which the precedence call is directed receives precedence ringing. The destination station connects to the preempting call when the station goes off hook.

Call Forward No Answer

For calls of Priority precedence level and above, call processing preserves the precedence level of calls during the forwarding process and may preempt the forwarded-to user.

If an Alternate Party is configured for the destination of a precedence call, call processing diverts the precedence call to the Alternate Party after the Precedence Call Alternate Party timeout expires.

If no Alternate Party setting is configured for the destination of a precedence call, call processing diverts the precedence call to the Call Forward No Answer setting.

Normally, precedence calls route to users and not to the voice-messaging system. The administrator sets the Use Standard VM Handling For Precedence Calls enterprise parameter to avoid routing precedence calls to voice-messaging systems. Refer to the "Setting the Enterprise Parameters for MLPP" section for details.

Call Transfer

MLPP interacts with the call-transfer feature. For blind transfers and consult transfers, each connection of the transferred call, including the consult call, maintains the precedence that the connection was assigned when the call was established.

Shared Lines

MLPP interacts with shared lines. A shared-line appearance with a call on hold may be preempted to establish a higher precedence call to another terminal with the same directory number (DN). In this case, the original held call does not disconnect, and the precedence call connects. After the precedence call ends, the user may retrieve the original held call.

Call Waiting

MLPP interacts with the call-waiting feature as described in the following list:

When conflicts arise between call-waiting status and MLPP precedence calls due to the lack of network resources, the call gets preempted.

When a precedence call is offered to a destination station that is configured with call waiting, the following behaviors take place:

If the requested precedence is higher than the existing call precedence, the existing call gets preempted. If the destination user is nonpreemptable, call processing invokes normal call-waiting behavior and alerting. If the precedence call is of Priority precedence level or higher, the destination user receives precedence call-waiting tones and cadences.

If the requested precedence level is the same as the existing call precedence, call processing invokes normal call-waiting behavior. If the precedence call is of Routine precedence, call processing alerts the destination with standard call-waiting tones. If the precedence call is of Priority or higher precedence, call processing alerts the destination with precedence call-waiting tones.

If the requested precedence level is lower than the existing call precedence, call processing invokes normal call-waiting behavior. If the precedence call is of Routine precedence, call processing alerts the destination with standard call-waiting tones. If the precedence call is of Priority or higher precedence, call processing alerts the destination with precedence call-waiting tones.

When a device has more than one appearance, the destination user may place a lower precedence call on hold to acknowledge receipt of a higher precedence call. After the higher precedence call ends, the destination user may resume the held, lower precedence call.

Call Preservation

Any MGCP trunk call or connection that is preserved according to the Cisco CallManager Call Preservation feature preserves its precedence level and MLPP Domain after invoking the Call Preservation feature. After the device registers with Cisco CallManager, the system only preserves the preserved calls at the device layer in the Cisco CallManager system. As a result, the preserved calls gets treated as two disjointed half calls. If preemption does occur on these devices, only one leg can follow preemption protocol to the other leg. The system detects call termination only through closure of the RTP port.

Automated Alternate Routing

The Automated Alternate Routing (AAR) for Insufficient Bandwidth feature, an extension of AAR, provides a mechanism to automatically fall back to reroute a call through the Public Switched Telephone Network (PSTN) or other network by using an alternate number when the Cisco CallManager blocks the call due to insufficient location bandwidth. With this feature, the caller does not need to hang up and redial the called party.

If a precedence call attempt meets a condition that invokes the AAR service, the precedence call gets rerouted through the PSTN or other network as specified by the AAR configuration. Cisco CallManager handles the precedence nature of the call in the same manner as if the call originally had been routed through the PSTN or other network, based on the MLPP Indication Enabled and MLPP Preemption Enabled nature of the network interface through which the call is routed.

For details of configuring Automated Alternate Routing, refer to the Automated Alternate Routing Group Configuration section of the Cisco CallManager Administration Guide.

MGCP and PRI Protocol

MLPP supports Common Network Facility Preemption only for T1-CAS and T1-PRI (North American) interfaces on targeted Voice over IP gateways that Cisco CallManager controls by using MGCP protocol and that have been configured as MLPP Preemption Enabled.

MLPP Enhancements for Release 4.1

MLPP enhancements for Release 4.1 of Cisco CallManager include the following features:

Secure Endpoints and Secure Communications

PRI 4ES UUIE-Based MLPP Interface to DRSN

Executive Override Precedence Level

Location-based MLPP

MLPP Over Intercluster Trunks

Secure Endpoints and Secure Communications

The traditional Department of Defense (DOD) TDM network uses legacy analog secure telephone units (STUs) and BRI secure telephone equipment (STEs) as secure endpoints, which are critical for secure communication. The newly developed IP STE also requires support to reduce the need for legacy equipment. Cisco CallManager supports the Skinny Client Control Protocol for these devices. Modem relay provides secure communication and uses the V.150 protocol.

PRI 4ES UUIE-Based MLPP Interface to DRSN

Release 4.0 of Cisco CallManager offered MLPP for PRI interface that was developed according to the ANSI.619a specification to connect with Defense Switched Network (DSN) switches. Defense Red Switch Network (DRSN) switches do not support ANSI T1.619a-based MLPP but do support MLPP over the PRI 4ESS interface by using the UUIE. Release 4.1 of Cisco CallManager supports passing the MLPP information through the PRI 4ESS UUIE field.

Executive Override Precedence Level

Release 4.1 of Cisco CallManager changes the highest precedence level from Flash Override to Executive Override. Refer to the "Executive Override Precedence Level" section for details.

Location-based MLPP

Release 4.1 of Cisco CallManager enhances the Cisco CallManager location feature to support MLPP precedence and preemption. Refer to the "Location-Based MLPP" section for more information.

MLPP Over Intercluster Trunks

Release 4.1 of Cisco CallManager supports MLPP precedence and preemption over intercluster trunks. Dialed digits communicate the precedence level. The location call admission control mechanism controls preemption. Announcements and MLPP cause codes also become available across intercluster trunks.

Interactions and Restrictions

The following sections describe the interactions and restrictions for MLPP.

Interactions

Restrictions

Interactions

MLPP interacts with the following Cisco CallManager features as follows:

Extension Mobility—The MLPP service domain remains associated with a user device profile when a user logs in to a device by using extension mobility. The MLPP Indication and Preemption settings also propagate with extension mobility. If either the device or the device profile do not support MLPP, these settings do not propagate.

Immediate Divert—Immediate Divert diverts calls to voice-messaging mail boxes regardless of the type of call (for example, a precedence call). When Alternate Party Diversion (call precedence) is activated, Call Forward No Answer (CFNA) also gets deactivated.

IP Manager Assistant (IPMA)—MLPP interacts with IPMA as follows:

When IPMA handles an MLPP precedence call, IPMA preserves call precedence.

IPMA filters MLPP precedence calls in the same manner as it filters all other calls. The precedence of a call does not affect whether the call is filtered.

Because IPMA does not register the precedence of a call, it does not provide any additional indication of the precedence of a call on the assistant console.

Restrictions

The following restrictions apply to MLPP:

Common Network Facility Preemption support exists only for T1-CAS and T1-PRI (North American) interfaces on targeted Voice over IP gateways that Cisco CallManager controls by using MGCP protocol and that have been configured as MLPP Preemption Enabled.

User Access Channel support exists only for the following Cisco IP Phone models, which must be configured as MLPP Preemption Enabled:

Cisco 796X series IP Phone

Cisco 794X series IP Phone

IOS gateways support SCCP interface to CCM. Hence, they support BRI and analog phones which appear on the Cisco Call Manger as supported phone models.

Only MLPP Indication Enabled devices generate MLPP-related notifications, such as tones and ringers. If a precedence call terminates at a device that is not MLPP Indication Enabled, no precedence ringer gets applied. If a precedence call originates from a device that is not MLPP Indication Enabled, no precedence ringback tone gets applied. If a device that is not MLPP Indication Enabled is involved in a call that is preempted (that is, the other side of the call initiated preemption), no preemption tone gets applied to the device.

For phones, devices that are MLPP indication disabled (that is, MLPP Indication is set to Off) cannot be preempted.

For trunks, MLPP indication and preemption function independently.

Cisco CallManager does not support the Look Ahead for Busy (LFB) option.

Intercluster trunk MLPP carries precedence information through dialed digits. Domain information does not get preserved and must be configured per trunk for incoming calls.

729 Annex A is supported.

Various location bandwidth preemption limitations exist.

For the DRSN, CDRs represent precedence levels with values 0, 1, 2, 3, and 4 where 0 specifies Executive Override and 4 specifies Routine, as used in DSN. CDRs thus do not use the DRSN format.

Location preemption does not apply to video calls. In Cisco CallManager, audio bandwidth and video bandwidth get tracked separately. Video calls do not get preempted.

MLPP-enabled devices are not supported in line groups. As such, Cisco recommends the following guidelines:

MLPP-enabled devices should not be configured in a line group. Route groups, however, are supported. Both trunk selection and hunting methods are supported.

If an MLPP-enabled device is configured in a line group or route group, in the event of preemption, if the route list does not lock onto the device, the preempted call maybe rerouted to other devices in the route list or hunt list and preemption indication maybe returned only after no devices are able to receive the call.

Route lists can be configured to support either of two algorithms of trunk selection and hunting for precedence calls. In method 1, perform a preemptive search directly. In method 2, first perform a friendly search. If this search is not successful, perform a preemptive search. Method 2 requires two iterations through devices in a route list.

If route lists are configured for method 2, in certain scenarios involving line groups, route lists may seem to iterate through the devices twice for precedence calls.

Turning on MLPP Indication (at the enterprise parameter, device pool, or device level) disables normal Ring Setting behavior for the lines on a device, unless MLPP Indication is turned off (overridden) for the device.

Refer to the "Configuring MLPP" section for configuration details.

Installing and Activating MLPP

MLPP, a system feature, comes standard with Cisco CallManager software and does not require special installation.

Configuring MLPP

This section contains the following information:

MLPP Configuration Checklist

Setting the Enterprise Parameters for MLPP

MLPP Configuration Checklist

Table 12-1 provides a checklist to configure MLPP.

Table 12-1 MLPP Configuration Checklist 

Configuration Steps
Related procedures and topics

Step 1 

Configure a device pool for which associated devices can make MLPP calls.

Device Pool Configuration, Cisco CallManager Administration Guide

Step 2 

Set enterprise parameters to enable MLPP indication and preemption. If individual devices and devices in device pools have MLPP settings of Default, the MLLP-related enterprise parameters apply to these devices and device pools.

Setting the Enterprise Parameters for MLPP

Enterprise Parameters Configuration, Cisco CallManager Administration Guide

Step 3 

Configure partitions and Calling Search Spaces (CSS) that allow users (calling parties and their associated devices) to place precedence calls that use MLPP.

Partition Configuration, Cisco CallManager Administration Guide

Calling Search Space Configuration, Cisco CallManager Administration Guide

Step 4 

Configure route patterns/hunt pilots that specify MLPP precedence level and route options for MLPP calls.

Route Pattern Configuration, Cisco CallManager Administration Guide

Step 5 

Configure translation patterns that specify MLPP precedence level and route options for MLPP calls.

Translation Pattern Configuration, Cisco CallManager Administration Guide

Step 6 

Configure gateways that specify an MLPP domain for MLPP calls. The following gateway types apply:

Cisco AS-2 Gateway

Cisco AS-4 Gateway

Cisco AS-8 Gateway

Cisco AT-2 Gateway

Cisco AT-4 Gateway

Cisco AT-8 Gateway

Cisco Catalyst 6000 24 port FXS Gateway

Cisco Catalyst 6000 E1 VoIP Gateway

Cisco Catalyst 6000 T1 VoIP Gateway

Cisco DE-30+ Gateway

Cisco DT-24+ Gateway

H.323 Gateway

Note Some gateway types allow configuration of MLPP Indication and MLPP Preemption settings.

Gateway Configuration, Cisco CallManager Administration Guide

Step 7 

Configure Cisco IP Phones that specify an MLPP domain for MLPP calls.

Note Some phone types allow configuration of MLPP Indication and MLPP Preemption settings.

Cisco IP Phone Configuration, Cisco CallManager Administration Guide

Step 8 

Configure the directory number that will place an MLPP call.

Cisco IP Phone Configuration, Cisco CallManager Administration Guide

Step 9 

Configure the User Device Profile of the user that will make an MLPP call.

Device Profile Configuration, Cisco CallManager Administration Guide

Step 10 

Configure the Device Profile Default for devices that will make MLPP calls.

Device Profile Default Configuration, Cisco CallManager Administration Guide

Step 11 

Notify users that the MLPP service is available.

Refer to the phone documentation for instructions on how users access MLPP features on their Cisco IP Phone.

Setting the Enterprise Parameters for MLPP

Cisco CallManager provides the following enterprise parameters that apply to MLPP. Set the MLPP-related enterprise parameters as indicated to allow MLPP service.

MLPP Domain Identifier—Default specifies zero (0). Set this parameter to define a domain. Because MLPP service applies to a domain, Cisco CallManager only marks connections and resources that belong to calls from MLPP users in a given domain with a precedence level. Cisco CallManager can preempt only lower precedence calls from MLPP users in the same domain.


Note You must reset all devices for a change to this parameter to take effect.


MLPP Indication Status—Default specifies MLPP Indication turned off. This parameter specifies whether devices use MLPP tones and special displays to indicate MLPP precedence calls. To enable MLPP indication across the enterprise, set this parameter to MLPP Indication turned on.


Note You must reset all devices for a change to this parameter to take effect.


MLPP Preemption Setting—Default specifies No preemption allowed. This parameter determines whether devices should apply preemption and preemption signaling (such as preemption tones) to accommodate higher precedence calls. To enable MLPP preemption across the enterprise, set this parameter to Forceful Preemption.


Note You must reset all devices for a change to this parameter to take effect.


Precedence Alternate Party Timeout—Default specifies 30 seconds. In a precedence call, if the called party subscribes to alternate party diversion, this timer indicates the seconds after which Cisco CallManager will divert the call to the alternate party if the called party does not acknowledge preemption or does not answer a precedence call.

Use Standard VM Handling For Precedence Calls—Default specifies False. This parameter determines whether a precedence call will forward to the voice-messaging system. If the parameter is set to False, precedence calls do not forward to the voice-messaging system. If the parameter is set to True, precedence calls forward to the voice-messaging system. For MLPP, the recommended setting for this parameter is False, as users, not the voice-messaging system, should always answer precedence calls.

For more information about enterprise parameters, refer to the Enterprise Parameters Configuration chapter of the Cisco CallManager Administration Guide.

Where to Find More Information

Related Topics

Call Admission Control, Cisco CallManager System Guide

Device Pool Configuration, Cisco CallManager Administration Guide

Enterprise Parameters Configuration, Cisco CallManager Administration Guide

Automated Alternate Routing Group Configuration, Cisco CallManager Administration Guide

Partition Configuration, Cisco CallManager Administration Guide

Calling Search Space Configuration, Cisco CallManager Administration Guide

Route Pattern Configuration, Cisco CallManager Administration Guide

Translation Pattern Configuration, Cisco CallManager Administration Guide

Annunciator, Cisco CallManager System Guide

Annunciator Configuration, Cisco CallManager Administration Guide

Gateway Configuration, Cisco CallManager Administration Guide

Trunk Configuration, Cisco CallManager Administration Guide

Cisco IP Phone Configuration, Cisco CallManager Administration Guide

Device Profile Configuration, Cisco CallManager Administration Guide

Device Profile Default Configuration, Cisco CallManager Administration Guide

Additional Cisco Documentation

Cisco CallManager Serviceability System Guide

Cisco CallManager Serviceability Administration Guide

Cisco IP Phone Administration Guide for Cisco CallManager, Cisco IP Phone Models 7960G and 7940G