Multilevel Precedence and Preemption

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.

Configuration Checklist for MLPP

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.

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

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

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.

MLPP Terminology

•Call—A voice, video, or data connection between two or more users or network entities that is achieved by dialing digits or otherwise routing to a destination according to a predefined dialing plan.

•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—Specifies 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.

•Resource Priority Namespace Network Domain—Specifies SIP trunk behavior in the case of a precedence call and can preempt an existing call.The Resource Priority Namespace Network Domain in SIP signaling is similar to the ISDN precedence Information Element (IE) and ISDN User Part (ISUP) precedence parameters used in legacy TDM MLPP networks. The Resource Priority Namespace Network Domain is included on outbound calls and based on translation patterns or route patterns directing the call to the SIP trunk. For incoming calls the network domain is validated against the Resource Priority Namespace Network Domain List. If the network domain is not on the list, the call is rejected and a 417 message (unrecognizable) is returned.

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

•MLPP Preemption Enabled device—In Cisco Unified Communications Manager, a device for which the device and Cisco Unified Communications Manager support preemption signaling procedures in the device control protocol and that is configured as such in the Cisco Unified Communications Manager system. Cisco Unified Communications Manager 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 Unified Communications Manager 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 the ability of a calling party to dial a precedence pattern to attempt to originate a precedence call.

The Defense Switched Network (DSN) and the Defense Red Switched Network (DRSN) designate the target system for initial MLPP deployment. You generally can apply mechanisms for assigning precedence levels to calls, however, in Cisco Unified Communications Manager 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 Unified Communications Manager 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 Unified Communications Manager 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.

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 34-1 shows an example of two Executive Override precedence calls, one that can be preempted, and one that cannot be preempted.

Executive Override Precedence Calls Across the PRI 4ESS Interface

Cisco Unified Communications Manager processes Executive Override precedence calls across the PRI 4ESS interface by 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 gets passed only when UUIE Status on the service parameter window is True and Passing Precedence Through UUIE gets selected on the Gateway Configuration window.

PRI 4ES UUIE-Based MLPP Interface to DRSN

Cisco Unified Communications Manager now supports passing the MLPP information through the PRI 4ESS UUIE field. A previous release of Cisco Unified Communications Manager offered MLPP for PRI interface that was developed according to the ANSI T1.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.

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

An MLPP domain specifies a 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.

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.

Resource Priority Namespace Network Domain

The Resource Priority Namespace Network Domain enables the configuration of namespace domains for a Voice over Secured IP (VoSIP) network that uses SIP trunks. Cisco Unified Communications Manager prioritizes the SIP-signaled resources so that those resources can be used most effectively during emergencies and congestion of telephone circuits, IP bandwidth, and gateways. Endpoints receive the precedence and preemption information. It is based on RFC 4411 and RFC 4412.

The SIP signaling contains a resource-priority header. The resource-priority header is similar to the ISDN precedence Information Element (IE) and ISDN User Part (ISUP) precedence parameters used in legacy TDM MLPP networks. The resource-priority header is related to, but is different from the priority header in RFC 3261, Section 20.26.

The RFC 3261 priority header indicates the importance of SIP requests for the endpoint. For example, the header could indicate decisions about call routing to mobile devices and assistants and about call acceptance when the call destination is busy. The RFC 3261 priority header does not affect the usage of PSTN gateway or proxy resources.

In the RFC 3261 priority header, any value could be asserted but the Resource Priority header field in the namespace network domain is subject to authorization. The Resource Priority header field does not directly influence the forwarding behavior of IP routers or the use of communications resources such as packet forwarding priority.

The RFC 4411 and RFC 4412 resource-priority header in the outbound message is based on the translation or route patterns directing a call to the SIP trunk. Incoming calls are validated against a list of Resource Priority Namespace Network Domains if the calls are terminating to an endpoint configured in the Cisco Unified Communications Manager Administration.

The following messages include the Resource Priority header:

•INVITE

•UPDATE

•REFER

The following is an example of an INVITE message that has an resource priority header that specifies immediate priority (value of 4).

You can also add a default Resource Priority Namespace Network Domain to a SIP Profile to use when handling misconfigured incoming namespace network domains.

Note Digit analysis of translation and route patterns is supported.

The following supplementary services are supported:

•Precedence Call Waiting

•Call Transfer

•Call Forwarding

•Three-way Calling

The following headers, mapping, and queuing are not supported:

•Accept-Resource-Priority header.

•Inclusion of RP header in PRACK and ACK.

•Mapping of precedence levels between namespaces.

•Call queuing and other non-MLPP services.

Resource Priority Namespace Network Domain List

The Resource Priority Namespace Network Domain List contains acceptable network domains and is added to the SIP Profile. Incoming calls are compared to the list and processed if an acceptable network domain is in the list. If the incoming call is not valid, the call is rejected and an error response of 417 (Unknown) is sent to the calling party.

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 Unified Communications Manager 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.

MLPP Precedence Patterns

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

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 Unified 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 Unified IP Phone.

Precedence Call Setup Across Intercluster Trunks

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

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 Unified IP Phone Configuration section of the Cisco Unified Communications Manager Administration Guide for details.

Example

Figure 34-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 34-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 the alternate party destination of party 1001, which is party 1002. If party 1002 is busy or does not answer, the call forwards to party 1003, which is the s alternate party designation of party 1002.

MLPP Preemption Enabled

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 common device configuration. If the common device configuration MLPP Preemption setting for the device is Forceful, or if the common device configuration 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:

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 exist 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 Unified Communications Manager 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.

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, which is of precedence level Executive Override, 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 who are involved in the existing lower precedence call both receive preemption tones.

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

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 that are supported in its device control protocol in Cisco Unified Communications Manager. The administrator can also disable preemption procedures for a phone even though Cisco Unified Communications Manager 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 Unified Communications Manager Administration effectively enhances the Call Waiting feature to provide this capability for users of Cisco Unified IP Phones (794X and 796X series). These Cisco Unified IP Phones include a user interface that gives the user adequate control of multiple, simultaneous calls when interfacing with the Cisco Unified Communications Manager 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 Unified Communications Manager administrator can configure devices as not MLPP Preemption Enabled to take advantage of this function in Cisco Unified Communications Manager.

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 Unified Communications Manager.

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 34-7 illustrates an example of common network facility preemption.

Figure 34-7 Common Network Facility Preemption Example

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

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

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 34-9 for an example of this type of location-based preemption.

Figure 34-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. The D call preempts the call between A and B because RL1 is out of bandwidth and D 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 34-10 for an example of this type of location-based preemption.

Figure 34-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 call preempts the call between A and B because RL1 is out of bandwidth and D 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.

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 Unified Communications Manager 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.

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

Figure 34-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 34-12 provides an example of a blocked precedence announcement.

Figure 34-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 34-13 illustrates an instance of an MLPP announcement that is streamed over an intercluster trunk.

Figure 34-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 ability of a user to dial a precedence pattern (that is, to initiate a precedence call). Cisco Unified Communications Manager 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.

MLPP Trunk Selection

MLPP trunk selection entails hunting for available trunks by using route lists and route groups. In Cisco Unified Communications Manager 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 Unified Communications Manager attempts to initiate preemption of a lower level precedence shared resource in the collection. Two methods exist for subsequently searching for a preemptable channel within a route list and route group configuration.

Method 1

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.

Method 2

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.

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 34-15 provides an example of MLPP trunk selection that uses route lists and route groups to hunt for an available trunk device.

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.

In Method 2, 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 have 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.

MLPP Hierarchical Configuration

MLPP settings for devices follow this hierarchy:

•If MLPP Indication for a device 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 common device configuration settings for the device.

•If MLPP Indication for a device is set to On, the device can send indication of MLPP calls. If the MLPP Preemption for the device is set to Forceful, the device can preempt calls. These settings override the common device configuration settings for the device.

•If MLPP Indication for a device is set to Default, the device inherits its ability to send indication of MLPP calls from the common device configuration for the device. If the MLPP Preemption for a device is set to Default, the device inherits its ability to preempt calls from the common device configuration for the device.

MLPP settings for common device configurations follow this hierarchy:

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

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

•If a common device configuration 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 common device configuration MLPP Preemption is set to Default, the common device configuration inherits its ability to preempt calls from the MLPP Preemption Setting enterprise parameter.

The MLPP Indication Status enterprise parameter defines the indication status of common device configurations and common device configurations in the enterprise, but nondefault settings for common device configurations 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 common device configurations and devices in the enterprise, but nondefault settings for common device configurations 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 Unified Serviceability Administration Guide for details.

CDR Recording for Precedence Calls

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

Line Feature Interaction

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 Unified Communications Manager 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 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 Unified Communications Manager Call Preservation feature preserves its precedence level and MLPP domain after invoking the Call Preservation feature. After the device registers with Cisco Unified Communications Manager, the system only preserves the preserved calls at the device layer in the Cisco Unified Communications Manager 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 Unified Communications Manager 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 Unified Communications Manager 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.

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 Unified Communications Manager controls by using MGCP protocol and that have been configured as MLPP Preemption Enabled.

Mapping MLPP Precedence to DSCP Values

Cisco Unified Communications Manager maps the MLPP precedence levels to the DSCP values in the ToS field of the IP Header to prioritize calls in an IP network. You can map the following precedence levels to DSCP values:

•Executive Override

•Flash Override

•Flash

•Immediate

•Priority

You must map the MLPP precedence levels to the DSCP values identically for every Cisco Unified Communications Manager cluster within your network.

To map MLPP precedence levels to DSCP values, choose the DSCP value that you want mapped to each precedence level in the Clusterwide Parameters (System-QoS) section of the service parameters. Click the Update button to save the changes.

MLPP Supplementary Services

Cisco Unified Communications Manager Administration provides support for the following MLPP supplementary services and entities:

The subsections that follow discuss each MLPP supplementary service. For each supplementary service, the discussion provides a description, configuration information and recommendations, and troubleshooting information.

MLPP Support for Multiple Appearance Lines

If an empty call appearance is available and the busy trigger is not exceeded, an incoming precedence call gets presented such that the active line receives the precedence call-waiting tone and the endpoint display shows the appropriate precedence bubbles. The incoming call does not cause precedence ringing. Instead, precedence call-waiting tone occurs on the active appearance.

If no empty call appearances are available and the called endpoint does not have call forwarding configured, a higher precedence inbound call will preempt a lower active or nonactive call appearance on the endpoint. In the case of a tie, the active appearance gets preempted.

If a nonactive (held) appearance gets preempted, the incoming call shows the appropriate precedence bubbles on the endpoint display, and the precedence call-waiting tone gets presented on the active call appearance. The other preempted user (the other end of the held call) receives call preemption tone.

If the active call appearance gets preempted, normal call preemption takes place (preemption tone gets presented on the active appearance and on the other party active line). Any existing, nonactive (held) call appearances remain unaffected and can be picked up at any time.

Configuration

For MLPP support for multiple appearance lines to function correctly, Cisco recommends the following configuration:

•Cisco recommends, but does not require, setting IP phones with max calls=4 and busy trigger=2.

•When interaction with MLPP supplementary services occurs, no support exists for assigning the same DN twice to the same station by using multiple partitions.

•Disable the Auto Line Select option for all IP phones because the highest precedence call may not get answered when multiple alerting calls are incoming.

Troubleshooting

If you use the CCM trace log (with detailed trace configured), you can tell how the preemption criteria was applied on any inbound call by searching for the whatToDo tag.

Call Forwarding

The Department of Defense (DoD) requires that no precedence calls get forwarded to off-net endpoints, such as mobile phones. Additionally, forwarded calls must retain the original precedence across multiple forwarding hops.

For Call Forward All (CFA) scenarios, precedence calls get routed to the MLPP Alternate Party (MAP) target of the original called party immediately. The CFA target does not get used for MLPP calls.

For Call Forward Busy (CFB) scenarios, precedence calls get forwarded to the configured CFB destination, subject to the hop count limits described in the "Restrictions" section and the state of open appearances on the called party endpoint.

For the Call Forward No Answer (CFNA) scenario, call processing attempts a single forward attempt (hop) to the CFNA target of the original called party. If that endpoint does not answer prior to the expiration of the No Answer timer, the call gets sent to the MAP target of the original called party.

Configuration

MLPP operation in the DoD requires that all MLPP endpoints have an MLPP Alternate Party (MAP) target directory number that is configured. The MAP typically specifies the attendant number and is used as a destination of last resort for forwarded MLPP calls.

If the endpoint does not follow the prescribed configuration when a MAP is needed, the MLPP call originator receives reorder tone, which indicates that the called party configuration does not include the required MAP configuration. This tone plays only if the call would have been directed to the attendant when no other forwarding options were available or configured.

Example

The following example describes a forwarding case. First, the MLPP call rings (3001 calls 3003 at Flash Override precedence level) with the CFNA timer set to 5 seconds. After the timer expires, the call gets redirected to the original called party CFNA target, which is 3004. During the process, the call retains its precedence level, 1, which designates Flash Override.

Three-Way Calling

•Each connection of a three-way call must maintain its original precedence level.

•The phone that performs the split operation of the three-way call uses the higher precedence level of the two calls when different precedence levels are involved.

Cisco Unified Communications Manager MLPP also includes preemption of conference bridge resources. If a conference bridge is saturated with calls, individual streams get preempted when setup of a new higher precedence three-way call occurs.

Use the Cisco Unified Communications Manager IP Voice Media Streaming App to service three-way calls. Do not use the IOS DSP farm to service conference calls because the IOS DSP farm does not address MLPP support.

Preemption occurs across a single bridge only.

MLPP three-way calls do not interoperate with the conference chaining features that were added in Release 4.2 of Cisco Unified Communications Manager.

Example 1

This example discusses a three-way call among A, B, and C. A called B at Priority 4; then, A called C at Priority 2 (Flash) and started the conference. The conference now proceeds as active with three participants: A at Flash precedence level, B at Priority precedence level, and C at Flash precedence level. When C hangs up, A and B get joined together in a normal call. A must get downgraded from Flash to Priority.

Example 2

In this example, a conference call preempts an existing conference call. The max streams value on the conference bridge was set to 3 to saturate the bridge. The first three-way call gets established among parties A, B, and C at Routine precedence level (5). Phone D then establishes a three-way call with parties E and F at Flash precedence level (2).

Call Transfer

When a switch initiates a call transfer between two segments that have the same precedence level, the segments should maintain the precedence level upon transfer. When a call transfer is made between call segments that are at different precedence levels, the switch that initiates the transfer marks the connection at the higher precedence level of the two segments.

Cisco Unified Communications Manager supports this requirement by upgrading the precedence level of a call leg that is involved in a transfer operation. For example, party A calls party B with Priority precedence level. Party B then initiates a transfer to C and dials the Flash precedence digits when dialing. When the transfer completes, the precedence level of party A gets upgraded from Priority to Flash.

Note The precedence level upgrade does not work over a trunk device such as an intercluster trunk (ICT) or PRI trunk.

Configuration

The MLPP transfer service entails no configuration requirements. The feature gets enabled automatically when MLPP is enabled, and the phones support the Transfer softkey.

Call Pickup

Cisco Unified Communications Manager adds the criteria of highest precedence to the call pickup algorithm, including the following requirements:

•If a call pickup group has more than one party in an unanswered condition and the unanswered parties are at different precedence levels, a call pickup attempt in that group retrieves the highest precedence call first.

• If multiple calls of equal precedence are ringing simultaneously, a call pickup attempt in that group retrieves the longest ringing call first.

•If multiple calls are ringing at directory number (DN) A, a user that picks up a call from DN A by using the Directed Call Park feature will be connected to the incoming call of highest precedence, assuming that the user is configured to use the Directed Call Park feature to pick up calls from DN A.

Configuration

The Call Pickup for MLPP capability introduces no special configuration considerations; however, MLPP calls do not support other group pickup.

Hunt Pilots and Hunt Lists

Cisco Unified Communications Manager includes modifications to the previous implementation of the hunt pilot feature. The following aspects of MLPP interaction with hunt pilots changed:

•Normal hunt algorithm logic occurs until all lines in the hunt group are busy.

•When all lines are busy, the lowest precedence call gets selected for preemption.

•When preemption occurs, the normal line group No Answer timer continues. When this timer expires, the next lowest precedence call in the hunt group gets selected for preemption.

MLPP gets implemented for the following hunt algorithms:

•Top down

•Longest idle time

•Circular

Preemption can still occur when the broadcast algorithm is in use. Cisco does not provide explicit support for the broadcast algorithm.

Cisco Unified Communications Manager allows configuration of multiple line groups for a hunt group. The current implementation supports only a single line group under a hunt group. Preemption still occurs when multiple line groups are configured, but the lowest precedence call may not get selected for preemption when more than one line group was configured for a hunt group.

Configuration

Hunt pilots and hunt lists require the following configuration:

•Configure only one hunt list in the hunt group. Preemption only happens across the first group in the list.

•Set all hunt group options to Try next member, do not go to next group. This includes the options for No Answer, Busy, and Not Available.

•Set the hunt group algorithm to Top Down, Circular, or Longest Idle Time. Cisco does not provide support for the Broadcast algorithm.

Note If the user chooses to invoke the Cancel Call Waiting feature while making a call, this overrides the Precedence Call Waiting settings for just that call. The Cancel Call Waiting settings apply only on the phone from which it is invoked, and have no affect on the phones calling it.For more information on the Cancel Call Waiting feature, refer to the Cisco Unified Communications Manager Administration Guide.

•Allow Call Waiting During an In-Progress Outbound Analog Call Service Parameter—A new service parameter is added to Cisco Unified Communications Manager. This parameter determines whether Cisco Unified Communications Manager allows an inbound call to be presented to a call-waiting-enabled SCCP gateway analog phone, when the analog phone is involved in an outbound call but may be unable to play the call waiting tone. The analog phone may not be able to play the call waiting tone until the outbound call gets to the alerting or connected state. Valid values can specify True or False:

–True—The call-waiting-eligible analog phone is presented with the inbound call regardless of the phone's ability to play call waiting tone, and the standard call answer time limit applies.

–False—Cisco Unified Communications Manager treats this as a normal analog line appearance reaching its Busy Trigger call limit; this treatment could involve forwarding actions, tones, or any other features applicable to the trigger.

Note For information on working with service parameters, refer to the "Configuring Service Parameters for a Service on a Server" section in Cisco Unified Communications Manager Administration Guide.

Interactions and Restrictions

The following sections describe the interactions and restrictions for MLPP.

Interactions

MLPP interacts with the following Cisco Unified Communications Manager features as follows:

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

•Supplementary Services—MLPP interacts with multiple line appearances, call transfer, call forwarding, three-way calling, call pickup, and hunt pilots as documented in the "MLPP Supplementary Services" section and the subsections that describe the interaction with each service.

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 Unified Communications Manager controls by using MGCP protocol and that have been configured as MLPP Preemption Enabled.

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

•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 Unified Communications Manager 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 Unified Communications Manager, 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 may be rerouted to other devices in the route/hunt list and preemption indication may be 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, common device configuration, or device level) disables normal Ring Setting behavior for the lines on a device, unless MLPP Indication is turned off (overridden) for the device.

•Supplementary Services—MLPP support for supplementary services specifies the following restrictions:

–The current MLPP design addresses only the basic Call Pickup feature and Group Call Pickup feature, not Other Group Pickup. Support for the Directed Call Pickup feature functions as described in the "Call Pickup" section.

–Call Forward All (CFA) support for inbound MLPP calls always forwards the call to the MLPP Alternate Party (MAP) target of the called party, if the MAP target has been configured. In the event of an incorrect configuration (that is, if no MAP target is specified), the call gets rejected, and the calling party receives reorder tone.

–Call Forward No Answer (CFNA) support for inbound MLPP calls forwards the call once to a CFNA target. After the first hop, if the call remains unanswered, the call gets sent to the MAP target of the original called party, if the MAP target has been configured. In the event of an incorrect configuration (that is, if no MAP target is specified), the call gets rejected, and the calling party receives reorder tone.

–Call Forward Busy (CFB) support for inbound MLPP calls forwards the call up to the maximum number that has been configured for forwarding hops. If the maximum hop count gets reached, the call gets sent to the MAP target of the original called party, if the MAP target has been configured. In the event of an incorrect configuration (that is, no MAP target is specified), the call gets rejected, and the calling party receives reorder tone.

–For hunt pilot support, the hunt group algorithm must specify Longest Idle Time, Top Down, or Circular. Ensure the hunt group options for busy treatment, no answer treatment, and unregistered treatment are set to Try next member, do not go to next group. Preemption only occurs across a single hunt group.

Configuring MLPP

Setting the Enterprise Parameters for MLPP

Cisco Unified Communications Manager 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 Unified Communications Manager only marks connections and resources that belong to calls from MLPP users in a given domain with a precedence level. Cisco Unified Communications Manager 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.

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 Unified Communications Manager 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.