Features and Services Guide for Cisco Unified Communications Manager, Release 10.0(1)

MLPP Feature

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.

Note

Only SCCP phones support the Multilevel Precedence and Preemption (MLPP) feature. SIP phones do not support MLPP.

MLPP configuration and operation is slightly different for Assured Services SIP (AS-SIP) endpoints than for other MLPP endpoint devices. AS-SIP endpoints deliver the precedence level to the Unified CM via the resource-priority header. Other MLPP endpoints use the dialed number pattern to indicate the precedence level. Many examples throughout this chapter illustrate the use of MLPP using the dialed number to signal precedence. Please refer to the Assured Services SIP Endpoint section for an understanding of how these endpoints differ in their operation and configuration.

MLPP Terminology

The following terms apply to the MLPP service:

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.
Resource Priority Namespace Network Domain List - Specifies a list of configured Resource Priority Namespace Network Domains for validating incoming calls.
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.

Executive Override Precedence Level

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.

The following figure shows an example of two Executive Override precedence calls, one that can be preempted, and one that cannot be preempted.

Figure 1. Executive Override Precedence Calls Example

In the example, in Cisco Unified Communications Manager installation 1, the Executive Override Call Preemptable service parameter specifies False, whereas in Cisco Unified Communications Manager installation 2, the Executive Override Call Preemptable service parameter specifies True.

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

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

The following figure shows an example of the events that take place when an Executive Override precedence call gets placed.

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

For the source, if this precedence call succeeds, Cisco Unified Communications Manager signals Cisco Unified IP Phone to play a ringback tone to the user. If Cisco Unified 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 Unified 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 Unified IP Phone 1001 successfully, Cisco Unified Communications Manager signals the destination to generate an audible ringer at the device. If Cisco Unified IP Phone 1001 is MLPP Indication Enabled, a precedence ring plays. Otherwise, a normal ring plays.

Also, Cisco Unified 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

The following figure shows an example of an Executive Override precedence call across the PRI 4ESS interface.

Figure 3. Executive Override Precedence Call 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 User-to-User IE Status on the Service Parameter Configuration window is True and Passing Precedence Level 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.

Administrators enter domains in Cisco Unified Communications Manager Administration as hexadecimal values of zero or greater.

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

INVITE sip:6000@10.18.154.36:5060 SIP/2.0Via: SIP/2.0/TCP 10.18.154.44;
branch=z9hG4bK1636ee4aRemote-Party-ID: “Raleigh - 5001" <sip:5001@10.18.154.44>;
party=calling;screen=yes;privacy=offFrom: “Raleigh - 5001" <sip:5001@10.18.154.44>;
tag=936ad6ec-4d3c-4a42-a812-99ac56d972e1-14875646To: <sip:6000@10.18.154.36>Date: Mon, 
21 Mar 2005 14:39:21 GMTCall-ID: 1d13800-23e1dc99-4c-2c9a12ac@172.18.154.44Supported: 
100rel,timer,replacesRequire: resource-priorityMin-SE:  1800User-Agent: Cisco-CCM5.0Allow: 
INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFYCSeq: 
101 INVITEContact: <sip:5001@10.18.154.44:5060;transport=tcp>Expires: 180Allow-Events: 
presence, dialog, kpmlCall-Info:<sip:10.18.154.44:5060>;
method=”NOTIFY;Event=telephone-event;Duration=500”Resource-Priority: 
namespace.4Max-Forwards: 70Content-Type: application/sdpContent-Length: 
269v=0o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.18.154.44s=SIP Callc=IN IP4 10.18.154.45t=0 
0m=audio 19580 RTP/AVP 0 101a=rtpmap:0 PCMU/8000a=ptime:20a=rtpmap:
101 telephone-event/8000a=fmtp:101 0-15

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.

Location-Based MLPP

Cisco Unified Communications Manager supports MLPP on Skinny Client Control Protocol phones and TDM (PRI/CAS) trunks. Cisco Unified Communications Manager also supports MLPP on wide-area network (WAN) links. Location-based call admission control (CAC) manages WAN link bandwidth in Cisco Unified Communications Manager. 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 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.

Precedence-Based MLPP Preemption

Prior to release 8.6, Cisco Unified Communications Manager randomly chose calls to preempt that had lower precedence levels than the new request. If there are two existing calls with precedence levels of Routine and Priority and a Flash call comes in for that location, Cisco Unified Communications Manager might preempt the Routine call or the Priority call. With release 8.6 and later, Cisco Unified Communications Manager always preempts the Routine call before the Priority call.

Configuration of Nonpreemptable Numbers

With Release 10.0 and later it is possible to designate specific dialed numbers as nonpreemeptable.

To configure nonpreemptable numbers, create the transformation patterns with the MLPP Preemption Disabled check box checked and put them into partitions, import all such partitions into a CSS (for example, NonPreemptionCSS), and select the CSS in "Non-Preemption Pattern CSS" service parameter (System > Service Parameters).

Note

For Location based MLPP to work, you need to select the MLPP Exception Level service parameter.

The following are limitations to the nonpreemptable number feature:

For the nonpreemptable feature to work as expected in intercluster scenarios you must configure the same nonpreemptable numbers across all clusters. The nonpreemptable status is not signaled between CallManagers in different clusters.
In scenarios where incoming calls arrive via a MGCP T1 CAS trunk the calling party number is not available to Cisco Unified Communications Manager. Therefore, the calling party number cannot be checked for nonpreemptability.
In MGCP FXO scenarios, the calling party number information is provided to Cisco Unified Communications Manager after the call routing process begins. Therefore, the calling party number cannot be checked for nonpreemptability
In an Overlap Sending scenario only a few digits are collected before gateway selection occurs. All the remaining digits dialed are sent across the gateway for processing. Therefore Cisco Unified Communications Manager does not know the complete number that is dialed and can not check for the nonpreemptable status of the called party number.

CAC Call-State-Based MLPP Preemption

If two calls are in the same location, have the same precedence level, and are using the same media type (audio or video), Cisco Unified Communications Manager preempts the call that is in setup phase before selecting the call that has already completed.

Because location CAC counts bandwidth, when media is established, the bandwidth is being used, therefore, Cisco Unified Communications Manager considers the call setup to be completed.

Minimize Number of Calls to Preempt

For calls with the same precedence level, call state, and that use the same media type (audio or video), Cisco Unified Communications Manager attempts to minimize the number of calls to be preempted; that is, Cisco Unified Communications Manager selects a call with larger bandwidth, rather than several calls with less bandwidth.

Note

Cisco Unified Communications Manager always preempts calls with lower precedence levels if a call with a higher precedence level gets selected. This rule applies even when the higher precedence call can satisfy the required bandwidth.

Because each call connects two devices in different locations, each location could result in calls to be preempted. For example, in one location, a Flash call could be preempted while a Priority call is not preempted in the other location. For examples of preemption calls, see the Location-Based Preemption.

Preempt Video Calls When Allocating or Adjusting Bandwidth

Cisco Unified Communications Manager 8.6(1) and later preempts lower precedence video calls when allocating or adjusting video bandwidth for high priority calls if there is not enough bandwidth for the new request. When preempting a video call, Cisco Unified Communications Manager clears the call and plays a preemption tone to the party that is preempted.

Preempt Bandwidth Allocated for Annunciator or Music On Hold

Cisco Unified Communications Manager 8.6(1) and later preempts the bandwidth that is allocated for Annunciator and Music On Hold (MOH) when preempting calls. If media resource bandwidth is needed for a higher priority call, an entire call is cleared, rather than simply removing the Annunciator or MOH. When Annunciator or MOH is inserted into a call, such as to play music on hold or a ringback for MLPP Calls, preemption, or reorder tone, the media is streaming; therefore, Cisco Unified Communications Manager considers the call connected and preempts the call after all alerting calls with the same precedence level. However, when Annunciator or MOH is requested but not enough bandwidth is available at neither the media user location or the media resource location, the request for Annunciator or MOH fails and Cisco Unified Communications Manager does not preempt other calls for Annunciator or MOH.

As with all preempted calls, the bandwidth that is allocated for those calls is immediately released and then allocated for another call. When Annunciator is played for preemption tone, or any other tone that causes a call to disconnect, the tone continues to play for a short while even though the bandwidth has already released. That is, when Cisco Unified Communications Manager selects an Annunciator tone to be used for a preemption or reorder tone, the bandwidth might be over-subscribed (over-budget) for a short while before the call is completely cleared.

Enforce Maximum Bandwidth

Cisco Unified Communications Manager 8.6(1) and later enforces configured maximum bandwidth for locations, which can result in calls being cleared when a call is resumed or transferred. In addition, multiple calls could be cleared when new bandwidth requests occur and the bandwidth is over-subscribed. To enforce maximum bandwidth for locations, the service parameters Locations-based Maximum Bandwidth Enforcement Level for MLPP Calls and Locations-based MLPP Enable must be set to Strict Enforcement.

When the value for the Locations-based Maximum Bandwidth Enforcement Level for MLPP Calls service parameter is changed from Lenient to Strict, the result could be more calls than the maximum bandwidth that is allowed. However, Cisco Unified Communications Manager does not immediately preempt calls to bring the bandwidth within the allowed budget, but rather, when new bandwidth is requested for the same type of audio or video call. When the preemption occurs, one possible result is a large amount of difference between bandwidth usage and the maximum allowed.

When handling preemption in over-subscription situations, Cisco Unified Communications Manager considers all existing calls, beginning with the lowest precedence level. Although this preemption is triggered by a bandwidth request, the preempted call could have a higher precedence level than the requesting call.

The service parameter Locations-based Maximum Bandwidth Enforcement Level for MLPP Calls determines whether to restrict the bandwidth usage for a location to be within its configured maximum.

For more information about service parameters, see Location-Based Preemption in the Cisco Unified Communications Manager Administration Guide.

Preempt Audio Calls When Adjusting Bandwidth

Cisco Unified Communications Manager adjusts bandwidth for audio calls when bandwidth usage is changed after a call is presented to the called party, as in the case of called party answer, shared line hold and resume, transfer, and other feature interactions. Cisco Unified Communications Manager attempts to preempt other calls, if possible, but allows the new bandwidth request to proceed even when there is not enough bandwidth for the call to be preempted.

Note

If the service parameter Enforce Maximum Bandwidth for MLPP is set to True, the bandwidth request fails, which causes the call to be cleared. The requesting call is cleared as if it is preempted as any other location preemption with the same cause code and preemption tone.

Update Bandwidth After Joining Call Legs

Prior to Cisco Unified Communications Manager 8.6(1), real bandwidth usage was not reflected accurately. For example, when user B transferred user A and user C, the bandwidth that was reserved for the primary call (A and B) was allocated but the bandwidth reserved for the secondary call (B and C) was released.

Cisco Unified Communications Manager 8.6(1) and later updates bandwidth immediately after the Join operation, which reflects the correct bandwidth usage for calls. Updating bandwidth preserves the existing bandwidth that has been allocated to the two call legs. Once the media has connected, Cisco Unified Communications Manager adjusts to the correct bandwidth usage. That is, when the bandwidth is updated after the Join operation, one side of the call leg could have a bandwidth reservation for video and the other side for audio, which results in a call with two types of bandwidth reservation; however, the bandwidth is adjusted to the correct usage after the media connects.

Note

Because the update for bandwidth does not request additional bandwidth in either location, Cisco Unified Communications Manager does not preempt any calls.

Update Bandwidth When Redirecting a Call

This section provides examples that describe how bandwidth is reserved when redirecting a calling party and a called party to a new destination.

Redirect Calling Party to New Destination

When Cisco Unified Communications Manager redirects a calling party to a new destination, the bandwidth reserved for IP phone B is released when Cisco Unified Communications Manager attempts to reserve bandwidth for IP phone C.

If a reservation failure occurs for IP phone C, the bandwidth for IP phone B reallocated. If the A to B call is restored, as in the case of an divert failure, the bandwidth for the A to B call is reflected correctly.

If the A to B call is not restored, as in the case of a CFNA failure, the bandwidth for both IP phone A and IP phone B remains allocated even though IP phone B has stopped ringing. Bandwidth for both phones is released when IP Phone A disconnects the call.

Redirect Called Party to New Destination

When redirecting a called party, Cisco Unified Communications Manager reserves double bandwidth for the original called party before ringing the new destination. If there is not enough bandwidth for the doubled reservation, the redirect operation fails. In Cisco Unified Communications Manager 8.6(1) and later, Cisco Unified Communications Manager reuses the original called party’s bandwidth reservation (IP phone B) when reserving bandwidth for the new called party. However, for the redirect action to be successful, if IP phone A and IP phone D are in the same location, Cisco Unified Communications Manager requires bandwidth for both phones.

If the reservation for the new destination for Phone D fails, the existing bandwidth reserved for the original called party is reallocated. When the call for the original called and calling party is restored, the bandwidth reservation for the calling party and the original called party remains.

If the reservation for the e new destination fails and the original A to B call is not restored, the bandwidth for both IP phone A and IP phone B is released.

MLPP Over Intercluster Trunks

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

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:

Executive override (highest)
Flash override
Flash
Immediate
Priority
Routine (lowest)
Default (means precedence level does not get changed)

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

See the Cisco Unified Communications Manager Administration Guide for details of setting MLPP indication for devices.

Precedence Call Setup

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

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.
The calling party receives the special precedence ringback and a precedence display while the call is processing.
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

The following figure 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.

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. See the Set the Enterprise Parameters for MLPP 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. See the Cisco Unified Communications Manager Administration Guide for details.

Example

The following figure 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.

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

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

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

See the Cisco Unified Communications Manager Administration Guide 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.

Example

The following figure illustrates an example of user access preemption.

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

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.
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.
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.
To complete preemption, the parties who are involved in the lower precedence call (users 1000 and 1001) hang up.
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 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 7940, 7942, 7945, 7960, 7962, 7965, and 7975). 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

The following figure illustrates an example of common network facility preemption.

Figure 9. Common Network Facility Preemption Example

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

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

The following figure 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 10. 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:

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.
Retry timer Trr expires.

Channel 3 gets preempted.
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 the following figure for an example of this type of location-based preemption.

Figure 11. 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:

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.
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.
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 the following figure for an example of this type of location-based preemption.

Figure 12. 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:

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.
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.
B receives the preemption tone first, and the End call softkey displays.
B presses the EndCall 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.

Example 3

The following example describes basic MLPP preemption on precedence level.

The following calls are present in a location:

Executive Override:

Call 1 at 80 kbps
Call 2 at 8 kbps

Flash Override:

Call 3 at 8 kbps
Call 4 at 8 kbps

Flash:

Call5 at 8 kbps
Call6 at 8 kbps

Immediate:

Call 7 at 8 kbps
Call 8 at 8 kbps

Priority:

Call 9 at 8 kbps
Call 10 at 8 kbps

Routine:

Call 11 at 8 kbps
Call 12 at 8 kbps

No more bandwidth is available at this location.

A new Executive Override call that requires 80 kbps bandwidth in this location is attempted. In this case, calls 3 through 12 are preempted.

Example 4

The following example describes how Cisco Unified Communications Manager preempts multiple lower priority calls and a single higher priority call.

The following calls are present in a location:

Executive Override:

Flash Override:

Flash:

Call 1 at 80 kbps
Call 2 at 8 kbps

Immediate:

Call 3 at 8 kbps
Call 4 at 8 kbps
Call 5 at 8 kbps
Call 6 at 8 kbps
Call 7 at 8 kbps
Call 8 at 8 kbps

Priority:

Call 9 at 8 kbps
Call 10 at 8 kbps

Routine:

Call 11 at 8 kbps

No more bandwidth is available at this location.

A new Executive Override call that requires 80 kbps bandwidth in this location is attempted. In this case, Cisco Unified Communications Manager preempts calls 2 through 11 due to call 2 having sufficient bandwidth available, while call 1 has more than enough bandwidth.

Example 5

The following example describes how Cisco Unified Communications Manager preempts an Executive Override or lower priority call before other calls.

The following calls are present in a location:

Executive Override:

Call 1 at 80 kbps
Call 2 at 8 kbps

Flash Override:

Call 3 at 80 kbps
Call 4 at 8 kbps

Flash:

Call 5 at 8 kbps
Call 6 at 8 kbps

Immediate:

Call 7 at 8 kbps
Call 8 at 8 kbps

Priority:

Call 9 at 8 kbps
Call 10 at 8 kbps

Routine:

Call 11 at 8 kbps

No more bandwidth is available at this location.

A new Executive Override call that requires 80 kbps bandwidth in this location is attempted. In this case, Cisco Unified Communications Manager preempts call 3 and calls 5 through 11.

Example 6

The following example describes how Cisco Unified Communications Manager preempts the maximum possible bandwidth with the minimum required amount.

The following calls are present in a location:

Flash:

Call 3 at 80 kbps
Call 4 at 8 kbps
Call 5 at 8 kbps
Call 6 at 8 kbps

No more bandwidth is available at this location.

A new Executive Override call that requires 8 kbps bandwidth in this location is attempted. In this case, Cisco Unified Communications Manager preempts one of calls 4, 5, or 6.

Example 7

The following example describes preemption due to precedence level.

Configuration

The total audio bandwidth in location (LOC-BR1) is 100 kbps

The region codec specifies a maximum audio bit rate as 64 kbps

IP phone A and IP phone B are in location Hub None and IP phone X and IP phone Y are in location LOC-BR1.

IP phone A (location Hub None) calls IP phone X (location LOC-BR1). The call is made with an Routine precedence level. Because sufficient audio bandwidth is available in LOC-BR1, the call begins alerting IP phone X and is answered.
IP phone B (location Hub None) calls IP phone Y (location LOC-BR1). The call is made with an Priority precedence level.
Because insufficient bandwidth is available to complete the second call and the second call is made at a higher priority than the first call, the first call is preempted.
The call between IP phone B and IP phone Y completes and the call between IP phone A and IP phone X is cleared.

Example 8

The following example describes no preemption for an Executive Override call.

Configuration

The total audio bandwidth in location (LOC-BR1) is 100 kbps

The region codec specifies a maximum audio bit rate as 64 kbps

The service parameter Executive Override Call Preemptable is set to False.

IP phone A and IP phone B are in location Hub None and IP phone X and IP phone Y are in location LOC-BR1.

IP phone A (location Hub None) calls IP phone X (location LOC-BR1). The call is made with an Executive Override precedence level. Because sufficient audio bandwidth is available in LOC-BR1, the call begins alerting IP phone X and is answered.
IP phone B (location Hub None) calls IP phone Y (location LOC-BR1). The call is made with an Executive Override precedence level.
Because insufficient bandwidth is available to complete the second call, it is rejected.
The call between IP phone B and IP phone Y is rejected.

Example 9

The following example describes the preemption for an Executive Override call.

Configuration

The total audio bandwidth in location (LOC-BR1) is 100 kbps

The region codec specifies a maximum audio bit rate as 64 kbps

The service parameter Executive Override Call Preemptable is set to True.

IP phone A and IP phone B are in location Hub None and IP phone X and IP phone Y are in location LOC-BR1.

IP phone A (location Hub None) calls IP phone X (location LOC-BR1). The call is made with an Executive Override precedence level. Because insufficient audio bandwidth is available in LOC-BR1, the call begins alerting IP phone X and is answered.
IP phone B (location Hub None) calls IP phone Y (location LOC-BR1). The call is made with an Executive Override precedence level.
Because insufficient bandwidth is available to complete the second call and the Executive Override Call Pre-emptable service parameter is set to True, the first call is preempted.
The call between IP phone B and IP phone Y completes and the call between IP phone A and IP phone X is cleared.

Example 10

The following example describes how Cisco Unified Communications Manager selects call preemption based on bandwidth.

Configuration

The total audio bandwidth in location (LOC-BR1) is 140 kbps

The region codec specifies a maximum audio bit rate as 64 kbps

LOC-BR1 contains the following calls:

Call 1 with a Flash Override precedence level, which is connected and using 80 kbps (G.711) in LOC-BR1
Call 2 with a precedence level of Flash Override, which is connected and using 80 kbps (G.711) in LOC-BR1
Call 3 with a precedence level of Flash Override, which is connected and using 80 kbps (G.711) in LOC-BR1

IP phone B is in location Hub None and IP phone Y is in location LOC-BR1.

IP phone B (location Hub None) calls IP phone Y location LOC-BR1). The call is made with a precedence level of Executive Override and the region specifies 64 kbps audio bit rate.
Because there is insufficient bandwidth available to complete call, call 3 is preempted.
The call between IP phone B and IP phone Y completes.

Example 11

The following example describes how Cisco Unified Communications Manager does not preempt calls if sufficient bandwidth cannot be acquired.

Configuration

The total audio bandwidth in location (LOC-BR1) is 140 kbps

The region codec specifies a maximum audio bit rate as 64 kbps

LOC-BR1 contains the following calls:

Call 1 with a Flash Override precedence level, which is connected and using 80 kbps (G.711) in LOC-BR1
Call 2 with a precedence level of Flash, which is connected and using 24 kbps (G.729) in LOC-BR1
Call 3 with a precedence level of Flash, which is connected and using 16 kbps (G.728) in LOC-BR1

IP phone B is in location Hub None and IP phone Y is in location LOC-BR1.

IP phone B (location Hub None) calls IP phone Y location LOC-BR1). The call is made with a precedence level of Flash Override and the region specifies 64 kbps audio bit rate.
Because there is insufficient bandwidth available to complete call and none of the calls can be preempted, the call between IP phone B and IP phone Y is rejected.

Example 12

The following example describes how Cisco Unified Communications Manager preempts only the required amount of bandwidth wherever possible.

Configuration

The total audio bandwidth in location (LOC-BR1) is 140 kbps

The region codec specifies a maximum audio bit rate as 64 kbps

LOC-BR1 contains the following calls:

Call 1 with a Flash precedence level, which is connected and using 80 kbps (G.711) in LOC-BR1
Call 2 with a precedence level of Flash, which is connected and using 24 kbps (G.729) in LOC-BR1
Call 3 with a precedence level of Flash, which is connected and using 16 kbps (G.728) in LOC-BR1

IP phone B is in location Hub None and IP phone Y is in location LOC-BR1.

IP phone B (location Hub None) calls IP phone Y location LOC-BR1). The call is made with a precedence level of Flash Override and the region specifies 24 kbps audio bit rate.
Because there is insufficient bandwidth available to complete call 2 is preempted.
The call between IP phone B and IP phone Y completes.

Example 13

The following example describes how Cisco Unified Communications Manager preempts the minimum number of calls when all calls are alerting.

Configuration

The total audio bandwidth in location (LOC-BR1) is 140 kbps

The region codec specifies a maximum audio bit rate as 64 kbps

LOC-BR1 contains the following calls:

Call 1 with a Flash precedence level, which is alerting and using 24 kbps (G.729) in LOC-BR1
Call 2 with a precedence level of Flash, which is alerting and using 16 kbps (G.728) in LOC-BR1
Call 3 with a precedence level of Flash, which is alerting and using 80 kbps (G.711) in LOC-BR1

IP phone B is in location Hub None and IP phone Y is in location LOC-BR1.

IP phone B (location Hub None) calls IP phone Y location LOC-BR1). The call is made with a precedence level of Flash Override and the region specifies 24 kbps audio bit rate.
Because there is insufficient bandwidth available to complete call 1 is preempted.
The call between IP phone B and IP phone Y completes.

Example 14

The following example describes how Cisco Unified Communications Manager preempts alerting calls before connected calls at the same precedence level.

Configuration

The total audio bandwidth in location (LOC-BR1) is 140 kbps

The region codec specifies a maximum audio bit rate as 64 kbps

LOC-BR1 contains the following calls:

Call 1 with a Flash precedence level, which is connected and using 80 kbps (G.711) in LOC-BR1
Call 2 with a precedence level of Flash, which is alerting and using 16 kbps (G.728) in LOC-BR1
Call 3 with a precedence level of Flash, which is alerting and is alerting and using 16 kbps (G.728) in LOC-BR1

IP phone B is in location Hub None and IP phone Y is in location LOC-BR1.

IP phone B (location Hub None) calls IP phone Y location LOC-BR1). The call is made with a precedence level of Flash Override and the region specifies 24 kbps audio bit rate.
Because there is insufficient bandwidth available to complete call 2 and call 3 are preempted.
The call between IP phone B and IP phone Y completes.

Example 15

The following example describes how Cisco Unified Communications Manager preempts a lower priority call before a higher priority call.

Configuration

The total audio bandwidth in location (LOC-BR1) is 140 kbps

The region codec specifies a maximum audio bit rate as 64 kbps

LOC-BR1 contains the following calls:

Call 1 with a Flash Override precedence level, which is connected and using 80 kbps (G.711) in LOC-BR1
Call 2 with a precedence level of Flash, which is connected and using 16 kbps (G.728) in LOC-BR1
Call 3 with a precedence level of Flash, which is connected and is alerting and using 16 kbps (G.728) in LOC-BR1
Call 4 with a precedence level of Flash, which is alerting and using 16 kbps (G.728) in LOC-BR1

IP phone B is in location Hub None and IP phone Y is in location LOC-BR1.

IP phone B (location Hub None) calls IP phone Y location LOC-BR1). The call is made with a precedence level of Executive Override and the region specifies 24 kbps audio bit rate.
Because there is insufficient bandwidth available to complete call 3 and call 4 are preempted.
The call between IP phone B and IP phone Y completes.

Example 16

The following example describes a call that is receiving music on hold that is considered to be at the original precedence.

Configuration

The total audio bandwidth in location (LOC-BR1) is 140 kbps

The region codec specifies a maximum audio bit rate as 64 kbps

LOC-BR1 contains the following calls:

Call 1 with a Flash precedence level, which is currently receiving music on hold (location LOC-BR1) and uses 80 kbps (G.711) in LOC-BR1
Call 2 with a precedence level of Flash, which is connected and using 16 kbps (G.728) in LOC-BR1
Call 3 with a precedence level of Flash, which is connected and using 16 kbps (G.728) in LOC-BR1

IP phone B is in location Hub None and IP phone Y is in location LOC-BR1.

IP phone B (location Hub None) calls IP phone Y (location LOC-BR1). The call is made with a precedence level of Flash and the region specifies 24 kbps audio bit rate.
Because there is insufficient bandwidth available to complete the call and no calls can be preempted, the call between IP phone B and IP phone Y is rejected.

Example 17

The following example describes a call that is receiving music on hold being preempted due to a preemption on the location of MOH.

Configuration

The total audio bandwidth in location (LOC-BR1) is 100 kbps

LOC-BR1 contains the following calls:

Call 1 with a Flash precedence level, which is currently receiving music on hold (location LOC-BR1) and uses 80 kbps (G.711) in LOC-BR1
Call 2 with a precedence level of Flash Override, which is connected and using 16 kbps (G.728) in LOC-BR1

A new call, with an Executive Override precedence level, is attempted from a different location to LOC-BR1, which requires 80 kbps.

Because there is insufficient bandwidth available in LOC-BR1, call 1 is preempted due to preemption on the MOH location. The initial pre-MOH call is also preempted.

Note

MOH and Annunciator insertion never preempts another call even if the call has a lower priority.

Example 18

The following example describes an insertion of the ringback tone failing due to insufficient bandwidth

Configuration

The total audio bandwidth in location (LOC-BR1) is 100 kbps

LOC-BR1 contains the following calls:

Call 1 with a Flash precedence level, which currently uses 80 kbps (G.711) in LOC-BR1
Call 2 with a precedence level of Flash Override, which is connecting and using 16 kbps (G.728) in LOC-BR1

A new call, with a Flash precedence level, is attempted from LOC-BR1 that requires an annunciator to be inserted in LOC-BR1 to play a ringback tone.

Because there is insufficient bandwidth available, the request is rejected and Annunciator is not inserted.

Example 19

The following example describes a preemption tone, which is played by the annunciator, being preempted because of insufficient bandwidth.

Configuration

The total audio bandwidth in location (LOC-BR1) is 120 kbps

LOC-BR1 contains the following calls:

Call 1 with a Flash precedence level, which currently uses Annunciator (location LOC-BR1) for a preemption tone and uses 80 kbps (G.711) in LOC-BR1
Call 2 with a precedence level of Flash Override, which is connecting and using 16 kbps (G.728) in LOC-BR1
Call 3 with a precedence level of Flash, which is connecting and using 16 kbps (G.728) in LOC-BR1

A new call is attempted from LOC-BR1 to a different location. The call requires 80 kbps (G.711) and uses a Flash Override precedence level.

Because there is insufficient bandwidth available in LOC-BR1, Call 1, which is receiving a preemption tone, is selected and preempted (terminating the preemption tone playback).

Example 20

The following example describes a preemption tone, which is played by the annunciator, being preempted because of insufficient bandwidth.

Configuration

The total audio bandwidth in location (LOC-BR1) is 120 kbps

LOC-BR1 contains the following calls:

Call 1 with a Flash precedence level, which currently uses Annunciator (location LOC-BR1) for a preemption tone and uses 80 kbps (G.711) in LOC-BR1
Call 2 with a precedence level of Flash Override, which is alerting and using 16 kbps (G.728) in LOC-BR1
Call 3 with a precedence level of Flash, which is alerting and using 16 kbps (G.728) in LOC-BR1

A new call is attempted from LOC-BR1 to a different location. The call requires 80 kbps (G.711) and uses a Flash Override precedence level.

Because there is insufficient bandwidth available in LOC-BR1, Call 3, which is alerting, is preempted and call 1, which is receiving a preemption tone, continues to play the tone.

Example 21

The following example describes preemption in both the originating and terminating locations.

Configuration

The total audio bandwidth in location (LOC-BR1) is 140 kbps

The total audio bandwidth in location (LOC-BR2) is 140 kbps

The following calls exist in the system:

Call 1 with a regular precedence from LOC-BR1 to LOC-BR2 by using 80 kbps
A new call is attempted with a Flash priority precedence level from LOC-BR1 to LOC-BR2 that requires 80 kbps

Call 1 is preempted and the new call is allowed.

Example 22

In the example, 384 K of bandwidth is required for the video call. Location A has a maximum of 500 K available video bandwidth and 500 K available audio bandwidth.

The SIP trunk is in cluster 1 in location A.

The following sequence of events takes place:

IP phone A makes a video call to IP phone B via the SIP trunk with Priority precedence level. Call is answered and the video is established.
IP phone C makes a video call to IP phone D via the SIP trunk with Flash precedence level.
While reserving bandwidth for the video call for C to D, the C to D call preempts the A to B call because the A to B call has a lower precedence and there is not enough bandwidth for the A to B call at location A in cluster 1 because the C to D call requires 384 K of bandwidth.
The A to B call gets cleared.

Example 23

In the example, 384 K of bandwidth is required for the video call. Location A has a maximum of 500 K available video bandwidth and 500 K available audio bandwidth.

The SIP trunk is in cluster 1 in location A.

The following sequence of events takes place:

IP phone A makes a call to IP phone B via the SIP trunk with Priority precedence level.
IP phone C makes a call to IP phone D via the SIP trunk with Flash precedence level.
Media for audio establishes successfully for both calls.
The A to B call gets escalated to video by IP phone B. The video connection establishes successfully.
The C to D call gets escalated to video by IP phone D. While the media connects for video for C to D, the A to B call gets preempted because it has a lower precedence than C to D and there is not enough bandwidth in location A for the A to B call to be maintained.
The C to D video call establishes successfully.

Example 24

In the example, 768 K of bandwidth is required for the new video call and 384 K is reserved for the existing video call. Location A has a maximum of 400 K available video bandwidth and 400 K available audio bandwidth.

The SIP trunk is in location A.

The following sequence of events takes place:

IP phone A makes a call to IP phone B via the SIP trunk with Priority precedence level.
IP phone C makes a call to IP phone D via the SIP trunk with Flash precedence level.
Media for audio establishes successfully for both calls.
The A to B call gets escalated to video by IP phone B. The video connection establishes successfully.
The C to D call gets escalated to video by IP phone D. While the media connects for video for C to D, the A to B call does not get preempted because there is still not enough bandwidth allowed for the C to D video call.
Flow control occurs and the call between C and D gets set up as an audio call.

Note

The audio bandwidth gets released while attempting to escalate to video. Flow control occurs when preemption is not possible. If audio bandwidth is not available at this point, the audio bandwidth is oversubscribed.

Example 25

In the example, 384 K of bandwidth is required for the new video call and 384 K is reserved for the existing video call. Location A has a maximum of 384 K available video bandwidth and 300 K available audio bandwidth.

The SIP trunk is in location A.

The following sequence of events takes place:

IP phone A makes a call to IP phone B via the SIP trunk with Priority precedence level.
IP phone C makes a call to IP phone D via the SIP trunk with Priority precedence level.
Media for audio establishes successfully for both calls.
The A to B call gets escalated to video by IP phone B. The video connection establishes successfully.
The C to D call gets escalated to video by IP phone D. While the media connects for video for C to D, the A to B call does not get preempted because it has the same precedence level as the C to D call.
There is not enough bandwidth for the C to D video call; therefore, flow control occurs and the call between C and D gets set up as an audio call.

Example 26

In the example, 384 K of bandwidth is required for the video call. Location A has a maximum of 200 K available video bandwidth and 200 K available audio bandwidth.

The SIP trunk is in location A.

The following sequence of events takes place:

IP phone A makes a call to IP phone B via the SIP trunk with Priority precedence level.
Media for audio establishes successfully.
The A to B call gets escalated to video by IP phone B. While the media connects for video for A to B, there is not enough bandwidth for the A to B video call and there are no calls to preempt. Flow control occurs and the call between A and B gets set up as an audio call.

Example 27

In the example, 384 K of bandwidth is required for each video call. In the example, two locations exist:

Location A
Location B

Location A has a maximum of 1500 K available video bandwidth and 400 K available audio bandwidth.

Location B has a maximum of 400 K available video bandwidth and 400 K available audio bandwidth.

IP phones A, C, and F are in cluster 1.

IP phones B and D are in location A in cluster 2.

IP phone B has a shared line B1 in location B in cluster 2.

IP phone E is in location B in cluster 2.

The following sequence of events takes place:

IP phone A makes a video call to IP phone B via the SIP trunk with a flash precedence level. The call gets answered and video establishes successfully. IP phone C makes a video call to IP phone D via the SIP trunk with a priority precedence level.
The C to D and A to B video calls are active.
IP phone F makes a video call over the SIP trunk to IP phone E with a priority precedence level. The video call between F and E is active.
IP phone B holds the call and the video for the A t B call stops.
B1 (the shared line) resumes the call with a flash precedence level.
The F to E call gets preempted because it has a lower precedence level than the A to B1 call. The F to E call gets cleared.
The A to B1 call is active.

Example 28

In the example, 384 K of bandwidth is required for each video call. Location A has a maximum of 500 K available video bandwidth and 500 K available audio bandwidth.

IP phone A, C, and E are in location A.

The following sequence of events takes place:

IP phone A makes an audio call to IP phone B via the SIP trunk with a priority precedence level. The call gets answered and the A to B audio call is active.
IP phone C makes a video call to IP phone D via the SIP trunk with a priority precedence level.
The C to D call is active.
IP phone A transfers the call to IP phone E (flash call).
IP phone E answers the call. IP phone A completes the transfer and the B to E video call gets set up (precedence level of flash).
The C to D call gets preempted.
The B to E video call is active.

Example 29

In the example, 384 K of bandwidth is required for each video call. Location A has a maximum of 500 K available video bandwidth and 500 K available audio bandwidth.

IP phone A, C, and E are in location A.

The following sequence of events takes place:

IP phone A makes an audio call to IP phone B via the SIP trunk with a priority precedence level. The call gets answered and the A to B audio call is active.
IP phone C makes a video call to IP phone D via the SIP trunk with a priority precedence level.
The C to D call is active.
IP phone A transfers the call to IP phone E (flash call).
IP phone E answers the call. IP phone A completes the transfer and the B to E video call gets set up (precedence level of flash).
The C to D call gets preempted.
The B to E video call is active.

Example 30

In the example, 384 K of bandwidth is required for each video call. Location A has a maximum of 800 K available video bandwidth and 500 K available audio bandwidth.

IP phone A, C, and E are in location A.

The following sequence of events takes place:

IP phone A makes a Priority video call to IP phone B. IP phone B answers the call and video is established.
IP phone C makes a Flash video call to IP phone D. IP phone D answers the call and video is established.
IP phone A places the A to B call on hold. The bandwidth is not yet released for the video pool for the A to B video call.
IP phone E makes a Flash video call to IP phone F.
The A to B call is preempted because there is not enough bandwidth in location A.
The E to F video call is active.

Example 31

The following sequence of events takes place:

IP phone A calls IP phone B and IP phone B answers the call.
IP phone B consult transfers to IP phone C.
IP phone B completes the transfer.

Configuration

The Location-based Maximum Bandwidth Enforcement Level for MLPP Calls service parameter is set to Strict and the Location Based MLPP Pre-emption service parameter is set to True.

The call between location 1 (Loc1) and location 2 (Loc2) requires 80 K

The call between location 2 (Loc2) and location 3 (Loc3) requires 24 K

The call between location 1 (Loc1) and location 3 (Loc3) requires 80 K


Location	Total Available Bandwidth
Loc1	160 K
Loc2	160 K
Loc3	24 K

After step 1, the bandwidth that is required for the call between IP phone A and IP phone C is 80 K but only 24 K is available. Cisco Unified Communications Manager 8.6(1) and later clears the call if the Location-based Maximum Bandwidth Enforcement Level for MLPP Calls service parameter is set to Strict and the Location Based MLPP Pre-emption service parameter is set to True.

Example 32

The following example describes multiple calls that are preempted but the new call fails.

Configuration

The total audio bandwidth in location (LOC-BR1) is 140 kbps

The region codec specifies a maximum audio bit rate as 64 kbps

LOC-BR1 contains the following calls:

Call 1 has a precedence level of Flash, which is alerting and using 24 kbps (G.729) in LOC-BR1

Call 2 has a precedence level of Flash, which is alerting and using 16 kbps (G.728) in LOC-BR1

Call 3 has a precedence level of Flash, which is alerting and using 80 kbps (G.711) in LOC-BR1

IP phone B is in location hub None and IP phone Y is in location LOC-BR1.

The following sequence of events takes place:

The audio bandwidth in location LOC-BR1 is changed to 10 kbps.
IP phone B attempts to call IP phone Y.
Because the audio bandwidth in LOC-BR1 is oversubscribed, call 1 through call 3 are preempted.
After the preemption, because there is not sufficient bandwidth to complete the new call between IP phone B and IP phone &, the new call is also rejected.

Note

The new call may also be a routine precedence call. In this case, a routine precedence call preempts multiple calls with a higher precedence level and the preemption tone is played.

Example 33

The following example describes multiple calls that are preempted and the new call succeeds.

Configuration

The total audio bandwidth in location (LOC-BR1) is 140 kbps

The region codec specifies a maximum audio bit rate as 64 kbps

LOC-BR1 contains the following calls:

Call 1 has a precedence level of Flash, which is alerting and using 24 kbps (G.729) in LOC-BR1

Call 2 has a precedence level of Flash, which is alerting and using 16 kbps (G.728) in LOC-BR1

Call 3 has a precedence level of Flash, which is alerting and using 80 kbps (G.711) in LOC-BR1

IP phone B is in location hub None and IP phone Y is in location LOC-BR1.

The following sequence of events takes place:

The audio bandwidth in location LOC-BR1 is changed to 80 kbps.
IP phone B attempts to call IP phone Y, with an Executive Override precedence level.
Because audio bandwidth in LOC-BR1 is oversubscribed, call 3 is preempted.
After the preemption, because sufficient bandwidth is not available to complete the new call between IP phone B and IP phone Y, calls 1 and 2 are preempted.
The new call is allowed to go through.

MLPP Announcements

This section discusses specific 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.

To assign authorized calling patterns, access the Route Pattern/Hunt Pilot Configuration and the Translation Pattern Configuration windows in Cisco Unified Communications Manager 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 Unified Communications Manager Administration. In the drop-down list box, choose Precedence Level Exceeded. See the Cisco Unified Communications Manager Administration Guide for details.

Example

The following figure illustrates an example of a user that receives an unauthorized precedence announcement.

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

The following figure provides an example of a blocked precedence announcement.

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

The following figure illustrates an instance of an MLPP announcement that is streamed over an intercluster trunk.

Figure 30. 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:

User 2000 goes off hook and starts to dial. (Status for User 2000 specifies originating busy and not preemptable.)
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.
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.

Secured or Encrypted Announcements and Music On Hold

Cisco Unified Communications Manager 8.6(1) and later supports Secure Real-Time Protocol (SRTP) for Annunciator and Music On Hold (MOH). When an announcement or MOH plays to a user, Cisco Unified Communications Manager checks the security capabilities of the Annunciator and MOH and the user’s device. If all devices support SRTP, the announcement or MOH media is encrypted prior to streaming to the user’s device and a secure locked icon displays on the Cisco Unified IP Phone.

For examples that describe how the locked icon displays when secured and unsecured announcements are inserted for precedence calls, see Announcements Over Intercluster Trunks. For examples that describe how the locked icon displays when secured and unsecured MOH media is inserted for precedence calls, see Music On Hold

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.

Note

The exception for this usage is AS-SIP endpoints. AS-SIP does not signal precedence using dialed digits and has a separate protocol mechanism for establishing precedence authorization. This section applies to all MLPP devices except AS-SIP phones.

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.

Example

The following figure provides an example of MLPP numbering plan access control for precedence patterns.

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 calling search space for private 3000, which is the Routine CSS.
Within Routine CSS of private 3000, 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 calling search space for major 2000, which is the Priority CSS.
Within Priority CSS for major 2000, 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 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.

The following figure provides an example of MLPP trunk selection that uses route lists and route groups to hunt for an available trunk device.

Figure 32. MLPP Trunk Selection (Hunting) Example

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

An incoming flash-level precedence call reaches route list RL, which contains only one route group, RG1.
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.

In Method 2, the following sequence of events takes place:
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.
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.

See the Cisco Unified 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 Unified Communications Manager CDRs identify the precedence level of each leg of the call.

Cisco Unified Communications Manager CDRs document the preemption value for preempted call terminations.

See the Cisco Unified Serviceability Administration Guide for details.

Line Feature Interaction

This section describes how MLPP interacts with line features.

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 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. See the Set the Enterprise Parameters for MLPP 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 a Routine precedence call is offered to a destination station that already has active calls that are configured with call waiting, normal call waiting is activated if the existing call count is less than the busy trigger.
When a non-routine precedence call is offered to a destination station that already has an active call that is configured with call waiting, precedence call waiting is activated if the existing call count is less than the busy trigger and any of the following conditions exist:
- The device supports visual call appearances and has an open appearance.
- The device supports two non-visual call appearances and has an open appearance, and the precedence of the new call is equal to or lower than the existing call.
- The device has an open appearance (visual or non-visual) and the device is non-preemptable.
When a non-routine precedence call is offered to a destination station that already has an active call that is configured with call waiting, an existing lower-precedence call is preempted if the existing call count is equal to or greater than the busy trigger.

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.

For details of configuring Automated Alternate Routing, see the Cisco Unified Communications Manager 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 Unified Communications Manager controls by using MGCP protocol and that have been configured as MLPP Preemption Enabled.

Secure Endpoints and Secure Communications

The 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 IP STE also requires support to reduce the need for legacy equipment. Cisco Unified Communications Manager supports the Skinny Client Control Protocol for these devices. Modem relay provides secure communication and uses either the legacy V.150 or V.150.1 MER (Minimal Essential Requirements) protocol.

Note

If you want a trunk to support V.150.1 Modem over IP (MOIP) calls, you must enable the V150 (subset) check box in Cisco Unified Communications Manager Administration for digital access PRI/T1 port configuration on the gateway. You must also enable the MDSTE package on the gateway by using the mgcp package-capability mdste-package CLI configuration command. For more information, refer to the Cisco Unified Communications Manager Administration Guide.

Map 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 Save button to save the changes.

The DSCP values that you configure are also applicable to the SCCP phones.

Procedure

Step 1

Choose Enterprise Parameter > MLPP Parameters and set the MLPP indication status to MLPP Indication On.

Step 2

For SCCP phones, choose Phone Configuration > MLPP Information > MLPP Indication and set to MLPP Indication On.

If MLPP indication is not set to On in the preceding cases, then the DSCP value corresponding to DSCP for audio calls will be used.

The following table summarizes the list of Media Resource devices and their support for DSCP tagging based on MLPP Precedence:

Table 1. List of Media Resource Devices and their Support for DSCP Tagging based on MLPP Precedence
Media Resource Type Name	Software Based Resource Type Supported	Hardware (IOS Gateway) Based Resource Type Supported
Media Termination Point	Yes	Yes
Music on Hold	Yes	No
Annunciator	Yes	NA
Transcoder	NA	Yes
Audio Conference Bridge	Yes	Yes¹
Video Conference Bridge²	NA	Yes³

¹ Cisco IOS Enhanced Conference Bridge

² DSCP tagging is supported only for audio conferences using Video Conference Bridge

³ Radvision CUVC

MLPP precedence calls involving the devices mentioned use the DSCP values configured in the service parameter page for the corresponding MLPP precedence.

Step 1	Start Cisco Unified Reporting by using any of the methods that follow. The system uses the Cisco Tomcat service to authenticate users before allowing access to the web application. You can access the application by choosing Cisco Unified Reporting in the Navigation menu in Cisco Unified Communications Manager Administration and clicking Go. by choosing File > Cisco Unified Reporting at the Cisco Unified Real Time Monitoring Tool (RTMT) menu. by entering https://<server name or IP address>:8443/cucreports/ and then entering your authorized username and password.
Step 2	Click System Reports in the navigation bar.
Step 3	In the list of reports that displays in the left column, click the Unified CM Phone Feature List option.
Step 4	Click the Generate a new report link to generate a new report, or click the Unified CM Phone Feature List link if a report already exists.
Step 5	To generate a report of all IP Phones that support call precedence for MLPP, choose these settings from the respective drop-down list boxes and click the Submit button: Product: All Feature: Call Precedence (for MLPP) The List Features pane displays a list of all devices that support the MLPP feature. You can click on the Up and Down arrows next to the column headers (Product or Protocol) to sort the list.
Step 6	To generate a report of all IP Phones that support call preemption for MLPP, choose these settings from the respective drop-down list boxes and click the Submit button: Product: All Feature: Call Pre-emption (for MLPP) The List Features pane displays a list of all devices that support the MLPP feature. You can click on the Up and Down arrows next to the column headers (Product or Protocol) to sort the list.

Bias-Free Language

Results

Chapter: Multilevel Precedence and Preemption

Multilevel Precedence and Preemption

Configure MLPP

Procedure

MLPP Feature

MLPP Terminology

Precedence

Executive Override Precedence Level

Executive Override Precedence Call Setup

Executive Override Precedence Calls Across the PRI 4ESS Interface

PRI 4ES UUIE-Based MLPP Interface to DRSN

Preemption

Domain

Resource Priority Namespace Network Domain

Resource Priority Namespace Network Domain List

Location-Based MLPP

Precedence-Based MLPP Preemption

Configuration of Nonpreemptable Numbers

CAC Call-State-Based MLPP Preemption

Minimize Number of Calls to Preempt

Preempt Video Calls When Allocating or Adjusting Bandwidth

Preempt Bandwidth Allocated for Annunciator or Music On Hold

Enforce Maximum Bandwidth

Preempt Audio Calls When Adjusting Bandwidth

Update Bandwidth After Joining Call Legs

Update Bandwidth When Redirecting a Call

Redirect Calling Party to New Destination

Redirect Called Party to New Destination

MLPP Over Intercluster Trunks

MLPP Precedence Patterns

MLPP Indication Enabled

Precedence Call Setup

Example

Precedence Call Setup Across Intercluster Trunks

Alternate Party Diversion

Example

MLPP Preemption Enabled

Receive Preemption

Preemption Enabled

Preemption Details

User Access Preemption

Example

User Access Channel Nonpreemptable

Common Network Facility Preemption

Example 1

Example 2

Location-Based Preemption

Example 1

Example 2

Example 3

Example 4

Example 5

Example 6

Example 7

Configuration

Example 8

Configuration

Example 9

Configuration

Example 10

Configuration

Example 11

Configuration

Example 12

Configuration

Example 13

Configuration

Example 14

Configuration

Example 15

Configuration

Example 16

Configuration

Example 17

Configuration

Example 18

Configuration