The following table provides definitions of terms that are related to Cisco Unified Mobility.

Types of Session Handoff

Two-touch Session Handoff - In this type, no Unified Communications client proximity detection logic gets used; all devices under the same user ring and first one to accept gets the call.

This section provides a list of Cisco Unified Mobility features that administrators configure by using Cisco Unified Communications Manager Administration.

The following features, which were originally part of Cisco Unified MobilityManager, now reside in Cisco Unified Communications Manager:

• Cisco Unified Mobility - This feature enables users to manage business calls by using a single phone number to pick up in-progress calls on the desk phone and the mobile phone.

• Desktop Call Pickup - Users can switch between desk phone and mobile phone during an active call without losing the connection. Based on the needs of the moment, they can take advantage of the reliability of the wired office phone or the mobility of the mobile phone.

• Send Call to Mobile Phone(s) - Users access this feature on the IP phone via the Mobility softkey. The feature triggers a remote destination pickup, which allows the user to move an active mobility call from the user desk phone to a configured remote destination phone.

• Mobile Voice Access - This feature extends Cisco Unified Mobility capabilities by providing an interactive voice response (IVR) system to initiate two-stage dialed calls through the enterprise and activate or deactivate Cisco Unified Mobility capabilities

• Access List - Users can restrict the set of callers that cause a designated remote destination to ring on an incoming call (allowed access list) or for which the remote destinations do not ring on an incoming call (blocked access list). Each remote destination represents a mobile or other phone that can be configured to accept transfers from the desk phone for the user.

Cisco Unified Communications Manager supports the following Cisco Unified Mobility features:

• Midcall Enterprise Feature Access Support Using DTMF - You can configure DTMF feature codes as service parameters: enterprise hold (default equals *81), enterprise exclusive hold (default equals *82), resume (default equals *83), transfer (default equal *84), and conference (default equals *85).

  Note

  *81 specifies enterprise hold. When invoked, enterprise hold allows the user to resume the call on the desk phone. *82 specifies enterprise exclusive hold. When invoked, enterprise exclusive hold does not provide the ability to resume the call on the desk phone. If a mobility call that is on enterprise hold disconnects in this state, the user can resume the call on the desk phone. Alternatively, if a mobility call that is on enterprise exclusive hold disconnects in this state, the user cannot resume the call on the desk phone.

• Two-stage Dialing - Be aware that enterprise features are available with two-stage dialing for smartphones. Two-stage dialing allows smartphones to make outgoing calls through Cisco Unified Communications Manager if the smartphone is in business mode. The smartphone dials the Enterprise Feature Access number for Cisco Unified Communications Manager and then dials the destination number.

• Dual-mode Phone Support - Cisco Unified Mobility supports dual-mode phones.

• Manual Handoff of Calls on a Dual-mode Phone - Dual-mode devices offer an option to manually hand off calls from the PSTN to WLAN and vice versa.

• Time-of-Day Access - When the Cisco Unified Mobility feature is enabled, calls get extended to remote destinations if the associated DN is called based on time-of-day-access-based configuration.

• Directed Call Park via DTMF - This feature allows a mobile phone user to park a call by transferring the parked party to a park code, so the call can be retrieved later. The feature combines the standard Cisco Unified Communications Manager Directed Call Park feature with the DTMF feature. Support of the Directed Call Park via DTMF feature leverages the Midcall Enterprise Transfer feature.

• SIP URI Dialing - This feature supports SIP URI as an additional type of remote destination for Cisco Unified Mobility.

• Intelligent Session Control - This feature modifies the behavior of outgoing calls placed from the enterprise directly to mobile phones and anchors such calls to the user desktop number. (Prior to the implementation of this feature, if an enterprise user made a direct call to a mobile phone, the call was treated like a normal outgoing PSTN call: the call got directed to the mobile phone only, the call was not anchored to the user desk phone, and the mobile user could not invoke any mobility features.) During such calls, the user can invoke mobility features such as midcall features and Session Handoff from the user mobile phone.

• Session Handoff - This feature leverages the existing Cisco Unified Communications Manager experience by allowing the user to move voice, video, and meeting sessions and conversations between different Unified Communications clients, such as Cisco Unified Personal Communicator (running on a PC in Softphone as well as CTI control mode), Cisco Unified Mobile Communicator (running on a mobile phone), and Cisco Unified IP Phone Series 9900 and legacy phones that are running SIP.

  The conversation can be moved from mobile phone to any other Unified Communications client. All devices that the user owns and that share the same line ring or show a toast, and the call gets answered by whichever device picks it up first. Upon answer, all the other shared-line devices enter Remote in Use mode.

  Note that the only client that can actually hand off a session (because it is the only client that has an anchored DTMF path back to Cisco Unified Communications Manager) is Cisco Unified Mobile Communicator. Neither Cisco Unified Personal Communicator nor 9900 series Cisco Unified IP Phones can initiate a session handoff. These devices can, however, handle an incoming session handoff.

Cisco Unified Mobility allows flexible management of enterprise and mobile phone communications and provides these additional features and benefits:

• Simultaneous desktop ringing - Incoming calls ring simultaneously on the IP phone extension and the designated mobile handset. When the user answers one line, the unanswered line automatically stops ringing. Users can choose the preferred device each time that a call comes in.

• Single enterprise voice mailbox - The enterprise voice mailbox can serve as single, consolidated voice mailbox for all business, including calls to the desktop or configured remote devices. Incoming callers have a predictable means of contacting employees, and users can check multiple voice-messaging systems in less time.

• System remote access - A mobile phone for the user can initiate calls as if it were a local IP PBX extension. User-initiated calls can take advantage of local voice gateways and WAN trunking, and the enterprise can track employee call initiation.

• Caller ID - The system preserves and displays caller ID on all calls. Users can take advantage of Cisco Unified Mobility with no loss of expected IP phone features.

• Remote on/off control - User can turn Cisco Unified Mobility feature. See Cisco Unified Mobility for details.

• Call tracing - The system logs detailed Cisco Unified Mobility calls and provides information to help the enterprise optimize trunk usage and debug connection problems.

• Security and privacy for Cisco Unified Mobility calls - During an active Cisco Unified Mobility call, the associated desktop IP phone remains secured. The system removes access to the call from the desktop as soon as the mobile connection becomes active, which prevents the possibility of an unauthorized person listening in on the call that is bridged to the mobile phone.

• Client Matter Codes (CMC) and Forced Authorization Codes (FAC) - You can manage call access and accounting. CMCs assist with call accounting and billing for billable clients. FACs regulate the types of calls that certain users can place and force the user to enter a valid authorization code before the call is established.

• IPv6 support - Cisco Unified Communications Manager supports IPv6 addressing from mobile phones. For information about how to configure IPv6 in Cisco Unified Communications Manager, see "IPv6 for Cisco Unified Communications Manager" in the Cisco Unified Communications Manager Features and Services Guide.

• Session persistency - Mobile users can roam between different networks (e.g. Wi-Fi, VPN over 3G/4G) without having to re-register with Cisco Unified Communications Manager. This feature allows users to maintain registration with Cisco Unified Communications Manager in the case of network connectivity loss, allows users to transit calls from one network to another without call drops, and prevents the loss of SIP-based subscription status while users are roaming.

Cisco Unified Mobility allows users to answer incoming calls on the desk phone or mobile phone, and to pick up in-progress calls on the desk phone or mobile phone without losing the connection.

Note

You can use any mobile phone, including Code Division Multiple Access (CDMA) and Global System for Mobile Communications (GSM) phones, for Cisco Unified Mobility and Mobile Voice Access. In some cases, however, you may need to modify timer settings in Cisco Unified Communications Manager to ensure compatibility. See the About Remote Destination Setup.

Methods for Enabling and Disabling Cisco Unified Mobility

The following methods are available for enabling and disabling the Cisco Unified Mobility feature. This list provides the methods that are available to the administrator and to end users.

• Cisco Unified Communications Manager Administration windows. Menu path specifies Device > Phone, then configure the Mobility Identity of the Cisco Unified Mobile Communicator by checking the Enable Cisco Unified Mobility check box (to enable Cisco Unified Mobility) or by unchecking this check box (to disable Cisco Unified Mobility).

• Desk phone by using the Mobility softkey. To configure, use these menu options:

  • Device > Phone, and specify the Mobility softkey template in the Softkey Template field.

  • Device > Phone, and assign the same mobility user ID on the remote destination profile as the desk phone owner user ID.

• Mobile phone by using Mobile Voice Access (uses IVR prompts; 2 to enable or 3 to disable)

• Mobile phone by using Enterprise Feature Access (after PIN entry, 2 to enable or 3 to disable). The sequence specifies <PIN>#2# or <PIN>#3#.

• Cisco Unified Mobile Communicator client: The client offers the mobile user the option to change the user Cisco Unified Mobility status. See Enable or Disable Cisco Unified Mobility From Mobile Phone for details.

Cisco Unified Mobility Status

If at least one configured remote destination for a user is enabled for Cisco Unified Mobility, the user desk phone displays Cisco Unified Mobility as Enabled.

RDNIS/Diversion Header

The RDNIS/diversion header for Cisco Unified Mobility enhances this Cisco Unified Mobility feature to include the RDNIS or diversion header information on the forked call to the mobile device. Service providers and customers use the RDNIS for correct billing of end users who make Cisco Unified Mobility Cisco Unified Mobility calls.

For Cisco Unified Mobility calls, the Service Providers use the RDNIS/diversion header to authorize and allow calls to originate from the enterprise, even if the caller ID does not belong to the enterprise Direct Inward Dial (DID) range.

Example RDNIS/Diversion Header Use Case

Consider a user that has the following setup:

Desk phone number specifies 89012345.

Enterprise number specifies 4089012345.

Remote destination number specifies 4088810001.

User gets a call on desk phone number (89012345) that causes the remote destination (4088810001) to ring as well.

If the user gets a call from a nonenterprise number (5101234567) on the enterprise number (4089012345), the user desk phone (89012345) rings, and the call gets extended to the remote destination (4088810001) as well.

Prior to the implementation of the RDNIS/diversion header capability, the fields populated as follows:

Calling Party Number (From header in case of SIP): 5101234567

Called Party Number (To header in case of SIP): 4088810001

After implementation of the RDNIS/diversion header capability, the Calling Party Number and Called Party Number fields populate as before, but the following additional field gets populated as specified:

Redirect Party Number (Diversion Header in case of SIP): 4089012345

Thus, the RDNIS/diversion header specifies the enterprise number that is associated with the remote destination.

Configuration of RDNIS/Diversion Header in Cisco Unified Communications Manager Administration

To enable the RDNIS/diversion header capability for Cisco Unified Mobility calls, ensure the following configuration takes place in Cisco Unified Communications Manager Administration:

All gateways and trunks must specify that the Redirecting Number IE Delivery — Outbound check box gets checked.

In Cisco Unified Communications Manager Administration, you can find this check box by following the following menu paths:

• For H.323 and MGCP gateways, execute Device > Gateway and find the gateway that you need to configure. In the Call Routing Information - Outbound calls pane, ensure that the Redirecting Number IE Delivery - Outbound check box gets checked. For T1/E1 gateways, check the Redirecting Number IE Delivery - Outbound check box in the PRI Protocol Type Information pane.

• For SIP trunks, execute Device > Trunk and find the SIP trunk that you need to configure. In the Outbound Calls pane, ensure that the Redirecting Diversion Header Delivery - Outbound check box gets checked.

Use Case Scenarios for Cisco Unified Mobility

See the Use Case Scenarios for Cisco Unified Mobility for the use case scenarios that Cisco Unified Communications Manager supports with this feature.

User can perform desktop call pickup on in-progress mobility calls either by hanging up the call on the mobile phone or by putting the mobility call on hold with the midcall hold feature. When hanging up or ending the call at the mobile phone, the user can then resume the call on the desk phone within 10 seconds (default). When the remote destination hangs up, Cisco Unified Communications Manager puts the associated desk phone in Hold state, which allows the user to resume the call by pressing the Resume softkey. The Maximum Wait Time for Desk Pickup setting on the End User Configuration window determines the amount of time the call remains on hold after the hang-up at the remote destination. The default specifies 10000 milliseconds (10 seconds).

Alternatively, the user can also perform desktop call pickup by placing the call on the mobile phone on enterprise hold with the midcall hold feature (*81) and then resuming the call on the desk phone. When Cisco Unified Communications Manager receives the *81, Cisco Unified Communications Manager places the associated desk phone in a Hold state so the user can resume the call. Note that with this method, the Maximum Wait Time for Desk Pickup timer does not apply to the hold state and the call gets held indefinitely until the user resumes the call.

Users can perform remote destination pickup on in-progress mobility calls by using the Send Call to Mobile Phone feature. To do so, users press the Mobility softkey on the desk phone and select Send Call to Mobile Phone, which generates calls to all of the remote destinations that are configured. Users can then answer this call at the desired remote destination and continue the call.

When a desk phone invokes the Send Call to Mobile Phone feature and the remote destination specifies a dual-mode smartphone, the following behavior results:

• If the dual-mode smartphone is registered to Wi-Fi, the call is sent to the device on the Wi-Fi side.

• If the dual-mode smartphone is not registered to Wi-Fi, the call is sent to the device on the cellular side.

Mobile Voice Access extends Cisco Unified Mobility capabilities by allowing users to originate a call from a remote destination such as a mobile phone as if dialing from the desk phone. A remote destination represents a phone that is designated as available for Cisco Unified Mobility answer and pickup. The user dials Mobile Voice Access from the remote destination. The system prompts the user for the PIN that is assigned to the user in Cisco Unified Communications Manager. After being authenticated, the user can make a call by using the same dialing methods that would be available if the user originated the call from the enterprise desk phone.

When Mobile Voice Access is called, the system prompts the user for the originating phone number in addition to the PIN if any of the following statements is true:

• The number from which the user is calling does not represent one of the remote destinations for the user.

• The user or the carrier for the user blocks the number (shown as "Unknown Number").

• The number does not get accurately matched in the Cisco Unified Communications Manager database; for example, if the number is 510-666-9999, but it is listed as 666-9999 in the database, or the number is 408-999-6666, but it is entered as 1-408-999-6666 in the database.

• Mobile Voice Access gets configured in hairpin mode. (When Mobile Voice Access that is configured in hairpin mode is used, users who are calling the system do not get identified automatically by their caller ID. Instead, users must manually enter their remote destination number prior to entering their PIN number.)

If the user incorrectly enters any requested information (such as mobile phone number or PIN) three times in a row, the Mobile Voice Access call can disconnect, and the system will lock out the user for a period of time. (The credential information for the user controls the allowed number of login attempts.)

Note

Mobile Voice Access uses the first locale that displays in the Selected Locales pane in the Mobile Voice Access window in Cisco Unified Communications Manager Administration (Media Resources > Mobile Voice Access) when the IVR is used. For example, if English United States displays first in the Selected Locales pane, the Cisco Unified Mobility user receives English when the IVR is used during a call.

See the Use Case Scenarios for Mobile Voice Access for the use case scenarios that Cisco Unified Communications Manager supports with this feature.

Users can leverage enterprise media resources and capabilities by invoking midcall features. DTMF digits that are relayed from the remote destination in-band in the audio path and then relayed out-of-band from the enterprise gateway to Cisco Unified Communications Manager invoke midcall features. When Cisco Unified Communications Manager receives the DTMF digits, appropriate midcall features get facilitated based on the DTMF digit sequence. Such features include adding or remove call legs for transferred or conferenced calls, as well as invoking media resources like music on hold for held calls and conference bridges as required.

The feature access codes that are configured within Cisco Unified Communications Manager under Service Parameters determine the midcall feature DTMF code sequences.

The user can originate calls from the remote destination phone through the enterprise by leveraging the enterprise telephony infrastructure. Two-stage dialing provides the following benefits:

• The ability to make calls through the enterprise, which leads to centralized billing and call detail records. This ability provides the potential for cost savings by ensuring that international calls get billed to the enterprise rather than to the mobile or cellular plan. However, this capability does not eliminate normal per-minute local/long-distance charges at the mobile phone.

• The ability to mask the mobile phone number from the far-end or dialed phone. Instead of sending the mobile number to the called party, the user enterprise number gets sent to the called party during a two-stage dialed call. This method effectively masks the user mobile number and ensures that returned calls get anchored in the enterprise.

An access list determines whether a call should be extended to a remote destination that is enabled for the Cisco Unified Mobility feature. With the addition of time-based control, the Time-of-Day Access feature adds time as another determination factor. The feature allows administrators and users to determine whether a call should reach a remote destination based on the time of day when the call is received.

For calls to remote destinations, the Time-of-Day Access feature adds a ring schedule and associates the ring schedule with an access list to determine the time-of-day access settings for a remote destination.

The provisioning process includes provisioning the following entities:

• Access lists

• Remote destinations (configuring a ring schedule and associating the ring schedule with an access list for a remote destination)

As an extension to the existing access list feature, ensure the Time-of-Day Access feature is accessible to end users of Cisco Unified Communications Manager. Therefore, you can provision the feature through use of both Cisco Unified Communications Manager Administration (by administrators) and Cisco Unified Communications Self Care Portal (by end users).

Use case scenarios are provided for the time-of-day access feature with Cisco Unified Mobility, including migration considerations when migrating from a release of Cisco Unified Communications Manager prior to Release 7.0(x) or later.

A user can park an existing call by using DTMF digits. Using Directed Call Park from the mobile phone, a user parks a call and inputs a unique mobility user park code. The user can subsequently retrieve the call with the code or have someone else retrieve the call with the code. This feature proves useful for certain vertical markets that require different departments or users to pick up calls.

When a user is in the enterprise and picks up a call on their mobile phone, they may want to pick the call up on a Cisco Unified IP Phone in a conference room or desk where the DN is not visible. The user can park the call and pick up the parked call with only their code.

When the mobile phone user is on an active call, the user can park the call by transferring the parked party to the park code that the system administrator configures and assigns to the user. The dialing sequence resembles the DTMF transfer sequence, except that a preconfigured parking code replaces the transfer number.

Example of Directed Call Park via DTMF - Parking the Call

In the following example, *82 specifies enterprise exclusive hold, *84 specifies transfer, the pin specifies 12345, and the call park code specifies 3215. The following actions take place from the mobile phone:

1. Dial *82 (to put the call on enterprise exclusive hold).

2. If necessary, put the mobile phone call on Hold, depending on the mobile phone model.

3. Make a new call to the Enterprise Feature Access DID.

Note	This same DID gets used for the Enterprise Feature Access two-stage dialing feature. Configure this DID with the Call Routing > Mobility > Enterprise Feature Access Configuration menu option.

1. After the call connects, dial the following field-and-digit sequence: <PIN>#*84#<Park Code>#*84#

2. For example, if the PIN specifies 12345 and park code specifies 3215, the digit sequence would be 12345#*84#3215#*84#

Cisco Unified Communications Manager puts the parked party on hold.

Note	The caller ID of the mobile phone must get passed to the enterprise and must match a configured remote destination when the user dials the Enterprise Feature Access DID to invoke this feature. If no caller ID exists or no caller ID match occurs, the user cannot invoke this feature.

After Cisco Unified Communications Manager receives the dialed park code digit, the digit analysis engine verifies whether the dialed park code digits are valid. If so, the Directed Call Park feature intercepts the park code and verifies whether the park code is available. If the dialed park code is valid and available, the parking party receives the ringback tone, and the secondary call terminates to a Cisco Unified Communications Manager generic device that associates with the selected park code. The generic device automatically answers and place the parking party on hold with music on hold (MOH) or tone on hold. The last *84 completes the transfer of the parked party to the Cisco Unified Communications Manager generic device that associates with the selected park code. After the transfer completes, the parked party receives the MOH or tone on hold, and the parked party gets parked on this selected park code and waits for retrieval.

If another user is already using the user-specified park code, Directed Call Park feature logic in Cisco Unified Communications Manager rejects that selected park code. The user gets to select another park code.

If the user-specified park code is not valid, Cisco Unified Communications Manager plays reorder tone to the parking party.

For the Directed Call Park feature, be aware that the park code and code range are configurable throughout the system. Every Cisco Unified Communications Manager server in the system shares the park code and code range.

Example of Directed Call Park via DTMF - Retrieving the Parked Call

When a user attempts to retrieve the parked call, the user can go off hook on another mobile phone, and the user must use two-stage dialing to dial a digit string that contains the Directed Call Park retrieval prefix digits (for example, 22) plus the park code/code range (for example, 3215). The following sequence of events takes place:

1. Dial Enterprise Feature DID on mobile phone.

2. Upon connection, dial the following field-and-digit sequence to retrieve the parked call:

3. <PIN>#1#<Retrieval Prefix><Park Number>#

4. In our example, the full sequence specifies 12345#1#223215# to retrieve the parked call.

Just like the existing Call Park feature, if the call does not get retrieved on time, the parked call reverts back to the phone number that is associated with the parking party by default.

If a shared line is configured for the phone line of the parking party, all phones that are associated with the shared line will ring. In addition, the dPark feature allows the administrator to configure a call park reversion number in the Directed Call Park Configuration window, so if the call park reversion number is configured, the non-retrieved call reverts to this number, instead of to the parking party number.

See the Use Case Scenarios for Directed Call Park via DTMF for the use case scenarios that Cisco Unified Communications Manager supports with this feature.

This feature supports Session Initiation Protocol (SIP) Universal Resource Identifier (URI) as an additional type of remote destination for Cisco Unified Mobility. When the DN is called, Cisco Unified Communications Manager extends the call to a SIP trunk that digit analysis selects with this SIP URI in the To: header.

This feature only allows routing that is based only on the domain name, not based on the full SIP URI.

When a remote destination of this type is configured, other Cisco Unified Mobility features, such as two-stage dialing, transformation to DN number when calling into Cisco Unified Communications Manager, Interactive Voice Response (IVR) support, caller ID match, or DTMF transfer and conferencing, do not get supported.

SIP URI Administration Details

The SIP URI dialing feature entails a relaxation of the business rules to allow the entry of a URI in the Destination Number field of the Remote Destination Configuration window. (From the Cisco Unified Communications Manager Administration menu bar, choose the Device > Remote Destination menu option.)

An additional requirement for this feature specifies that a SIP route pattern that matches the configured URI domain must be configured for the feature to work. To configure a SIP route pattern, from the Cisco Unified Communications Manager Administration menu bar, choose the Call Routing > SIP Route Pattern menu option.

SIP URI Example

For a remote destination, the SIP URI user@corporation.com gets configured. A SIP route pattern that specifies corporation.com must also get configured for the SIP URI remote destination to resolve correctly.

This feature modifies the behavior of outgoing calls placed from the enterprise directly to mobile phones and anchors such calls to the user desktop number. (Prior to the implementation of this feature, if an enterprise user made a direct call to a mobile phone, the call was treated like a normal outgoing PSTN call: the call got directed to the mobile phone only and the mobile user could not invoke any mobility features.)

An outgoing call from the enterprise to a remote destination exhibits the following behavior:

• Mobile user can use DTMF to invoke midcall features, such as Hold, Resume, Transfer, and Conference.

• Mobile user can hang up the call from the mobile phone and pick the call up from the user desk phone.

• A direct call to a remote destination from the enterprise gets anchored to the user desk phone; and the time-of-day access, Do Not Disturb, and Delay Before Ringing settings that are configured in the associated remote destination profile get ignored. The direct call goes immediately to the mobile user.

• Direct calls to remote destinations behave similarly to calls incoming to Cisco Unified Communications Manager from mobile users. Mobile users have access to the following mobility features:

  • Midcall features (Hold, Resume, Transfer, Conference)

  • Session Handoff

  • Call anchoring

Feature Configuration

Basic configuration of the Intelligent Session Control feature requires that the administrator configure the value of the Reroute Remote Destination Calls to Enterprise Number service parameter as True.

Note	For IP Multimedia Subsystem (IMS), ensure that the Cisco Unified Mobility feature is enabled in the Remote Destination Configuration window, or by using one of the other methods prescribed for enabling Cisco Unified Mobility, before implementing Intelligent Session Control call processing.

To access the Reroute Remote Destination Calls to Enterprise Number service parameter, execute System > Service Parameters in Cisco Unified Communications Manager Administration. In the Service Parameter Configuration window that displays, specify a server and the Cisco CallManager service. The following service parameters are found in the Clusterwide Parameters (Feature - Reroute Remote Destination Calls to Enterprise Number) pane:

• Reroute Remote Destination Calls to Enterprise Number - To enable the feature, specify the value for this service parameter as True. When this parameter is enabled, all outgoing calls to a remote destination get anchored in the enterprise number with which the remote destination associates.

• Log Mobile Number in CDR for Rerouted RD Calls - This service parameter determines whether to log the mobile number or the enterprise number in the call detail record (CDR) when outgoing calls to the remote destination get anchored. If set to False, the enterprise number gets logged. If set to True, the mobile number gets logged.

• Ignore Call Forward All on Enterprise DN - This service parameter determines whether to ignore the call forward all (CFA) setting that is configured on the enterprise number when outgoing calls to the remote destination get anchored. If set to True, the CFA gets ignored; if set to False, the CFA setting gets applied.

The following service parameters, found in the Clusterwide Parameters (System - Mobility) pane, also affect the behavior of the Intelligent Session Control feature:

• Matching Caller ID with Remote Destination - If this service parameter is set to Complete Match, all digits of the calling number must match for the call to connect to the remote destination. If this service parameter is set to Partial Match, partial matches are allowed and the Number of Digits for Caller ID Partial Match service parameter applies.

• Number of Digits for Caller ID Partial Match - The number of digits that this service parameter specifies applies to partial matches if the Matching Caller ID with Remote Destination service parameter is set to Partial Match.

Note	For each service parameter, click the service parameter name in Cisco Unified Communications Manager Administration for a complete definition of that service parameter.

Use case scenarios are provided for the Intelligent Session Control feature with Cisco Unified Mobility.

Additional Call Processing Details for Intelligent Session Control

If more than one line is configured for the matching remote destination profile for the dialed number, Cisco Unified Communications Manager uses the first matched line to route the call. Because the direct call to mobile number gets matched against the enterprise number, all enterprise number intercepts are honored, including Call Intercept on enterprise number when Call Intercept gets supported for enterprise number. The forward all intercept on enterprise number gets ignored based on the service parameter, Ignore Forward All on Enterprise DN. If this service parameter is set to true, Cisco Unified Communications Manager ignores forward all intercept on enterprise number and still directs the call to the mobile phone. If this service parameter is set to false, Cisco Unified Communications Manager still enables CFA setting on enterprise number and, if configured, sends the call to CFA destination.

This feature does not anchor direct calls to mobile number if the call to mobile number gets sent via an overlap-sending-enabled trunk or gateway. In this case, the call to mobile number does not get anchored.

See the limitations topic for additional restrictions that apply to this feature.

Troubleshooting the Intelligent Session Control Feature

Perform the following checks if the Intelligent Session Control feature does not function as expected:

• Ensure that the Intelligent Session Control is set to True in the Service Parameter Configuration window.

• Ensure that the Cisco Unified Mobility feature is enabled in the Remote Destination Configuration window, or by using one of the other methods prescribed for enabling Cisco Unified Mobility, before implementing Intelligent Session Control call processing for IP Multimedia Subsystem.

• Ensure that the caller ID matches the remote destination number as specified by the Matching Caller ID with Remote Destination setting (either complete match or partial match).

• Ensure that a trace line such as the following prints in the Cisco Unified Communications Manager SSI log after the number gets dialed:

  10/14/2008 15:09:26.507 CCM|Digit analysis: getDaRes - Remote Destination [9725782583]|*^*^*

• Ensure that the enterprise number Line Association check box is checked in the Remote Destination Configuration window (Device > Remote Destination).

• Ensure that the route pattern partition is part of the calling search space (CSS) that is configured as Rerouting CSS in the Remote Destination Profile Configuration window (Device > Device Settings > Remote Destination Profile).

The complete Session Handoff feature can move a single call, a conference, and session collaboration among mobile phone, PC, and desk phone. Session Handoff enables a user to move conversations from user mobile phone to user desk phone. Two-touch Session Handoff uses two user inputs: one at the initiating party to hand off and the other at the terminating party to accept.

The major benefit of the Session Handoff feature over Desktop Pickup is that the original conversation can be continued until the handed off call gets answered.

Configuration of the Session Handoff feature entails configuration of specific service parameters and configuration of the mobile device that will hand off calls.

Session Handoff Service Parameters

To configure service parameters in Cisco Unified Communications Manager Administration, choose the System > Service Parameters menu option. From the Server drop-down list box, choose a server. From the Service drop-down list box, choose the Cisco CallManager service.

The following service parameters must be configured to enable the Session Handoff feature:

• Session Handoff Alerting Timer - This service parameter, found in the Clusterwide Parameters (Device - General) pane, determines the length of time that the session handoff call alerts. The default value specifies 10 seconds, and valid values range from 1 to 999 seconds.

• Enterprise Feature Access Code for Session Handoff - This service parameter, found in the Clusterwide Parameters (System - Mobility) pane, specifies the DTMF feature code to trigger session handoff. The default value specifies *74.

For additional details about these service parameters, click the name of the service parameter in the Service Parameter Configuration window in Cisco Unified Communications Manager Administration, which provides a hyperlink to a complete definition of the service parameter.

Mobility Device Configuration for Session Handoff Feature

Perform the following configuration for the mobility device to enable the Session Handoff feature:

• Configure the directory number in remote destination profile and the desk phone shared line so that line-level directory number and partition match.

• Assign the same mobility user ID on the remote destination profile as the desk phone owner user ID to allow session handoff.

• To configure the Session Handoff feature for basic Cisco Unified Mobility users, the User ID field setting in the Remote Destination Configuration window should match the Owner User ID field on the (desk) phone configuration window.

• To configure the Session Handoff feature for Cisco Unified Mobile Communicator users, both the Owner User ID and the Mobility User ID fields in the Cisco Unified Mobile Communicator device configuration window must match the Owner User ID field on the desk phone configuration window.

Impact of Session Handoff on Other Features

When the user hands off a call, a new call gets presented on the desk phone. While the desk phone is flashing, the following features do not get triggered on the desk phone for the call that was handed off:

• iDivert

• Call Forward All

• DND

• Call Forwarding

If the user hands off a call and does not answer from the desk phone within the time that the Session Handoff Alerting Timer service parameter specifies, the existing Remote In Use state on the desk phone gets lost.

Thus, the desk phone loses shared-line functionality following session handoff. The user cannot perform midcall features for that call, such as Hold from Mobile (using *81) and Resume from desk, or desk pickup. The user can hand off the call again, however, to resume it from the desk phone.

Troubleshooting Information for Session Handoff Feature

If a call that is handed off from a mobile phone does not flash the desk phone, perform the following checks:

• Check whether Owner User ID for the desk phone matches the User ID of Remote Destination Profile.

• In service parameters, check whether Enable Enterprise Feature Access is set to True; also, check whether other DTMF features (Hold [*81], Resume [*83]) are working.

• Check the Session Handoff DTMF code (default specifies *74) and Session Handoff Alerting Timer (default specifies 10 seconds) values.

Session Persistency enhances the mobile user experience while roaming. Session Persistency allows mobile users with supported mobile devices to do the following:

• Roam between different networks (e.g. Wi-Fi, VPN over 3G/4G) without having to re-register with Cisco Unified Communications Manager.

• Maintain the SIP-based subscription status with Cisco Unified Communications Manager while roaming between different networks.

• Maintain registration with Cisco Unified Communications Manager in the case of network connectivity loss.

• Seamlessly transit both active and held calls from one network to another without call drops.

To facilitate connectivity during roaming between networks, Session Persistency allows dynamic IP address/port change via keep-alive registration to facilitate connectivity during roaming between networks. In addition, the feature includes a configurable TCP reconnect timer, which must be enabled at the product level, to allow mobile users to remain connected in case of a temporary network connectivity loss or roaming. The timer is in effect only when the mobile device tears down the original TCP connection explicitly.

To leverage the Session Persistency feature, mobile devices must comply with Cisco-defined SIP interfaces.

TCP Reconnect Timer Configuration

If the TCP reconnect timer has been enabled at the product level, you can configure the timer by setting a value for the Time to Wait for Seamless Reconnect After TCP Drop or Roaming field from any of the following configuration windows:

• Phone Configuration window

• Common Phone Profile window

• Enterprise Phone Configuration window

If a device that shares the same user identification and is associated with a Hunt Group, signs out of the Hunt Group, then SNR calls are not sent out to the associated mobile device.

Cisco Unified Communications Manager 9.0 extends the Log Out of Hunt Groups capability onto your mobile device. This allows it to function in the same way as your desk phone. When you use the Hlog softkey via your mobile client to Log Out of the Hunt Group, you no longer receive calls placed to the Hunt Pilot.

Cisco Unified Communications Manager 9.0 provides TLS/SRTP support for dual-mode smart phones. TLS establishes the same secure and reliable data transfer mode for mobile phones as for IP phones, and SRTP encrypts voice conversations.

The following topics detail the interactions between Cisco Unified Mobility and other Cisco Unified Communications Manager components:

Auto Call Pickup

Cisco Unified Mobility interacts with auto call pickup based on the service parameter selection. When the Auto Call Pickup Enabled service parameter is set to True, end users need only to press the PickUp softkey to pick up a call.

If the Auto Call Pickup Enabled service parameter is set to False, end users need to press the PickUp, GPickUp, or OPickUp softkey and then the Answer softkey.

Auto Call Pickup Example

Phone A, phone B (Cisco Unified Mobility subscriber), and phone C belong to the Engineering group; phone D, phone E, and phone F belong to the Accounting group.

Phone D calls phone A in the Engineering Group. Phone A rings, and phone B and phone C in the group receive pickup notice.

If Auto Call Pickup is enabled, press the PickUp softkey from phone B to use Cisco Unified Mobility features later on.

If Auto Call Pickup is not enabled, press PickUp softkey from phone B, which causes the remote destinations that are associated with phone B to ring. Press the Answer softkey on phone B, which causes the remote destinations to stop ringing. The user can subsequently perform mobile-phone pickup and desktop call pickup.

Automatic Alternate Routing

Prior to the implementation of this interaction, if a desk phone was configured for Automatic Alternate Routing (AAR) and the desk phone was configured with a mobile phone as a remote destination, the AAR feature did not get triggered for calls to the remote destination if the out-of-bandwidth condition applied.

Cisco Unified Mobility now supports Automatic Alternate Routing (AAR) as follows:

• If a rejection occurs due to lack of bandwidth for the location-based service, the rejection triggers AAR for any device that is configured for AAR.

• If a rejection occurs based on Resource Reservation Protocol (RSVP), however, AAR does not get triggered for calls to remote destinations.

Extend and Connect

The Extend and Connect feature allows users to answer incoming calls on any of their Cisco Unified IP phones or remote destination phones under the control of Cisco Jabber for desktop. However, connected (active) calls cannot be moved between their Cisco Unified IP phone and their remote phone. So one gains application control over the remote phone, but loses mobility features such as being able to move the call back to a Cisco Unified IP phone. This feature requires configuration of CTI Remote Devices.

The Unified Mobility feature allows users to answer incoming calls to their enterprise extension on either their Cisco Unified IP phones or any remote destinations, such as a mobile phone, a home phone, or a hotel phone, etc. Users can move active calls between their Cisco Unified IP phone and their mobile phone without losing the connection. This feature requires configuration of Remote Destination Profiles.

Cisco Jabber for mobile provides telephony, availability, IM, and collaboration in a single integrated smart client. In addition, it also integrates with the native smartphone to provide the entire Cisco Unified Mobility feature set. This combination allows users to communicate seamlessly from their mobile devices when they transit between networks (Wi-Fi or cellular). The intelligence built into the mobility solution, dynamically enables different features as the network changes, eliminating the need for user intervention or preconfiguration (for example, DVO support).

Both of these mobility solutions allow users to communicate as if they are within the enterprise, increasing their reachability and providing the active user the flexibility to a move a call to another device or network once they have changed their location.

Users who need the capabilities of both Unified Mobility and Extend and Connect may configure the same remote destination on the Remote Device Profile and CTI Remote Device types when the Owner ID of both device types is the same. This allows Cisco Mobility features to be used concurrently with Extend & Connect.

Note	The ability to configure the same remote destination on both device types is supported using Cisco Unified Communications Manager Release 10 or later.

For more information, see the "Extend and Connect" chapter.

External Call Control

If external call control is configured, as described in the External Call Control chapter, Cisco Unified Communications Manager honors the route decision from the adjunct route server for the following Cisco Unified Mobility features:

• Cisco Unified Mobility

• Mobile Voice Access

• Enterprise Feature Access

• Dial-via-Office Reverse Callback

• Dial-via-Office Forward

Tip

To invoke Mobile Voice Access or Enterprise Feature Access, the end user must dial a feature directory number that is configured in Cisco Unified Communications Manager Administration. When the Cisco Unified Communications Manager receives the call, Cisco Unified Communications Manager does not invoke external call control because the called number, in this case, is the feature DN. After the call is anchored, the Cisco Unified Communications Manager asks for user authentication, and the user enters the number for the target party. When Cisco Unified Communications Manager tries to extend the call to the target party, external call control gets invoked, and Cisco Unified Communications Manager sends a call routing query to the adjunct route server to determine how to handle the call.

Cisco Unified Communications Manager does not send a routing query for the following Cisco Unified Mobility features:

• Cell pickup

• Desk pickup

• Session handoff

Intelligent Session Control and Session Handoff

For direct calls to remote destinations that get anchored to the enterprise number, the mobile user can invoke the Session Handoff feature and mobile user can hand off the call to the desk phone.

Note	For IP Multimedia Subsystem, ensure that the Cisco Unified Mobility feature is enabled in the Remote Destination Configuration window, or by using one of the other methods prescribed for enabling Cisco Unified Mobility, before implementing Intelligent Session Control call processing.

Licensing

Cisco Unified Mobility uses licensing. Checking the Enable Mobility check box in the End User Configuration window triggers licensing to consume device license units (DLUs) for Cisco Unified Mobility; the number of licenses that get consumed depends on whether you assign an adjunct device to the end user specifically for Cisco Unified Mobility. For specific information on how licensing works with Cisco Unified Mobility, see the Cisco Unified Communications Manager Features and Services Guide.

Local Route Groups

For Single Number Reach calls to a remote destination, the device pool of the originating calling party determines the selection of the Standard Local Route Group.

Cisco Unified Mobility and SIP Trunks with Cisco Unified Border Element

Cisco Unified Mobility supports the Cisco Unified Mobility feature without midcall features over SIP trunks with Cisco Unified Border Element (CUBE).

Number of Supported Calls

Each remote destination supports a maximum of two active calls. For Cisco Unified Mobility, each remote destination supports a maximum of two active calls via Cisco Unified Communications Manager. Using the Enterprise Feature Access directory number (DID number) to transfer or conference with DTMF counts as one call. When a Cisco Unified Mobility user receives a call while the user has two active calls for the remote destination or while the user is using DTMF to transfer/conference a call from the remote destination, the received call does not reach the remote destination and instead goes to the enterprise voice mail; that is, if Call Forward No Answer (CFNA) is configured or if the call is not answered on a shared line.

Cisco Unified Mobility enforces the following limitations in operating with other Cisco Unified Communications Manager components.

Call Anchoring

Call anchoring, which is performed based on caller ID, is supported only from calls from registered single-mode or dual-mode phones.

Call Forwarding

You do not need to configure settings for Call Forward Unregistered if the end user has configured remote destinations. Appropriate call forwarding is handled as part of the Cisco Unified Mobility process.

Call Queuing

Cisco Unified Communications Manager does not support Call Queuing with Cisco Unified Mobility.

Cisco Unified IP Phones 7940 and 7960 That Are Running SIP

When running SIP, Cisco Unified IP Phones 7940 and 7960 do not support the Remote-In-Use state and therefore cannot support Desktop Call Pickup.

For these phones, if the mobile phone user hangs up a call that the Cisco Unified IP Phone 7940 or 7960 that is running SIP extended to the mobile phone, the calling party hears music on hold for 10 seconds (as configured by the Maximum Wait Time for Desk Pickup field for the remote-destination end user) and then the call drops. Because the Desktop Call Pickup feature is not supported for these phones when they are running as SIP devices, the user desk phone does not display the Resume softkey, so the user cannot pick up the call on the desk phone.

Cisco recommends that you configure Cisco Unified IP Phones 7940 and 7960 to run SCCP for users that are enabled for Cisco Unified Mobility.

Conferencing

Users cannot initiate a meet-me conference as conference controller by using Mobile Voice Access, but they can join a meet-me conference.

If an existing conference call is initiated from a shared-line IP phone or dual-mode phone or smartphone that is a remote destination, no new conference party can be added to the existing conference after the call is sent to a mobile phone or a dual-mode handoff action occurs. To permit the addition of new conference parties, use the Advanced Ad Hoc Conference Enabled service parameter.

Dialing + Character from Mobile Phones

Users can dial a + sign through Dual-Tone Multifrequency (DTMF) on a mobile phone to specify the international escape character.

Cisco Unified Mobility does not support + dialing through DTMF for IVR to make an outgoing call from a mobile phone to an enterprise IP phone for which the directory number contains the + character.

Cisco Unified Mobility does not support + dialing through DTMF for two-stage dialing to make an outgoing call from a mobile phone to an enterprise IP phone for which the directory number contains the + character.

For more information about configuring the international escape character in Cisco Unified Communications Manager Administration, see the Cisco Unified Communications Manager System Guide.

DND on the Desk Phone and Direct Calls to Remote Destination

If Do Not Disturb (DND) is enabled on a desk phone, the desk phone cannot be placed in the Remote In Use state and the call does not get anchored when:

• DND is enabled with the Call Reject option.

• DND is activated by pressing the DND softkey on the desk phone.

If DND is enabled with the Ring Off option, however, the call does get anchored.

Dual-Mode Handoff and Caller ID

Dual-mode handoff requires that caller ID be available in the cellular network.

Dual-Mode Phones and Call Anchoring

Dual-mode phones (Cisco Unified Mobility Advantage and dual-mode phones that are running SCCP or SIP) that are configured as remote destinations cannot anchor calls.

Dual-Mode Phones and CTI Applications

While a dual-mode phone is in Wi-Fi enterprise mode, no CTI applications control it nor monitor it.

The In Use Remote indicator for dual-mode phones on a shared line call in the WLAN disappear if the dual-mode phone goes out of WLAN range.

Dual-Mode Phones and Desktop Call Pickup

The Desktop Call Pickup feature does not apply to the following mobile phone models:

• Nokia 902iL and Nokia 906iL dual-mode phones that are running SIP

• Nokia S60 dual-mode phones that are running SCCP

For these phone models, if the mobile phone user hangs up a call, the calling party hears music on hold for 10 seconds (as configured by the Maximum Wait Time for Desk Pickup field for the remote destination end user) and then the call drops. Because the Desktop Call Pickup feature is not supported for these phone models, the user desk phone does not display the Resume softkey, so the user cannot pick up the call on the desk phone.

Dual-Mode Phones That Are Running SIP and Registration Period

For dual-mode phones that are running SIP, Cisco Unified Communications Manager determines the registration period by using the value in the Timer Register Expires (seconds) field of the SIP profile that associates with the phone, not the value that the SIP Station KeepAlive Interval service parameter specifies.

Enterprise Features From Cellular Networks

Enterprise features from cellular networks require out-of-band DTMF.

Note

When using intercluster DNs as remote destinations for an IP phone over a SIP trunk (either intercluster trunk or gateway), check the Require DTMF Reception check box when configuring the IP phone. This allows DTMF digits to be received out of band, which is crucial for Enterprise Feature Access midcall features.

Enterprise Features in the Global System for Mobile Communications (GSM) That Is Using DTMF

Availability of enterprise features in the Global System for Mobile communications (GSM) that are using DTMF depends on the features that are supported in the third-party smartphones.

Gateways and Ports

Both H.323 and SIP VoIP gateways are supported for Mobile Voice Access.

Cisco Unified Mobility features do not get supported for T1 CAS, FXO, FXS and BRI.

IPv6 Support When Used with Cisco Unified Mobility Advantage

Cisco Unified Mobility does not support IPv6 for mobile clients that are using Cisco Unified Mobility Advantage to connect to Cisco Unified Communications Manager for Dial via office or midcall features. Cisco Unified Mobility Advantage does not support IPv6 addresses.

iPhone-Based Cisco Jabber VoIP Calls

Cisco Mobile devices can support Voice over IP (VoIP) and Dial via Office (DVO) calling schemes, but iPhone-based Cisco Jabber supports only VoIP calls.

Note	The Android-based Cisco Jabber client supports both VoIP and DVO.

Jabber Devices are Registered Devices

When initially configured, Jabber devices count as registered devices. These devices increase the count of registered devices in a node, set by the Maximum Number of Registered Devices service parameter.

Maximum Wait Timer for Desktop Call Pickup Is Not Applied If User Presses Hold DTMF

If a user presses the *81 DTMF code from a remote destination (either a smartphone or any other phone) to put a call on hold, the user desk phone displays the Resume softkey. However, the desk phone does not apply a timer for Desktop Call Pickup. The Resume key continues to display even after the timeout that is configured for the end user to pick up the call elapses and the call is not dropped.

Instead, users should hang up the call on the remote phone, which triggers the desk phone to apply the timer for desktop call pickup. (Use the Maximum Wait Time for Desk Pickup field on the End User Configuration window to change this setting.)

Cisco Unified Mobility Support Restrictions

The Cisco Unified Mobility feature is supported only for Primary Rate Interface (PRI) public switched telephone network (PSTN) connections.

For SIP trunks, Cisco Unified Mobility is supported over IOS gateways or intercluster trunks.

Multilevel Precedence and Preemption (MLPP)

Cisco Unified Mobility does not work with Multilevel Precedence and Preemption (MLPP). If a call is preempted with MLPP, Cisco Unified Mobility features are disabled for that call.

Multiple-Node Cluster Environment

In a multiple-node cluster environment, if the Cisco Unified Communications Manager publisher server is unreachable, any changes that end users make to turn Cisco Unified Mobility off or on by way of Mobile Voice Access or two-stage dialing do not get saved.

Overlap Sending

Overlap sending patterns are not supported for the Intelligent Session Control feature.

QSIG

Mobility does not support QSIG.

QSIG Path Replacement

QSIG (Q Signaling) path replacement is not supported.

Remote Destination Profiles

When you configure a directory number that is associated with a remote destination profile, you must use only ASCII characters in the Display (Internal Caller ID) field on the Directory Number Configuration window.

Remote Destinations

Ensure remote destinations are Time Division Multiplex (TDM) devices. You cannot configure IP phones within a Cisco Unified Communications Manager system as remote destinations.

Ensure remote destinations specify PSTN numbers or numbers across ICT trunks.

Remote destinations cannot resume calls that Cisco Unified IP Phones put on hold.

Service Parameters

Enterprise feature access service parameters apply to standard phones and smartphones; however, smartphones generally use one-touch keys to send the appropriate codes. Administrators must configure any smartphones that will be used with Cisco Unified Mobility to use either the default codes for enterprise feature access or the codes that are specified in the smartphone documentation.

Session Handoff Feature

The following limitations apply to the Session Handoff feature:

• Session Handoff can take place only from mobile phone to desk phone. For session handoff from desk phone to mobile phone, the current Remote Destination Pickup method specifies that you must use Send Call to Mobile Phone.

• Only audio call session handoff is supported.

SIP URI and Direct Calls to Remote Destination

The Intelligent Session Control feature does not support direct URI dialing. Therefore, calls that are made to a SIP URI cannot be anchored to an enterprise number.

Video Calls

Cisco Unified Mobility services do not extend to video calls. A video call that is received at the desk phone cannot be picked up on the mobile phone.

After remote destination profiles and access lists are created, you can enter individual remote destinations and assign each to a profile. Each remote destination represents a mobile or other phone that can be configured to perform remote destination pickup (accept transfers from the desk phone of the user) and accept incoming Cisco Unified Mobility calls that come from the system as a result of the line that is shared with the desk phone.

After you save a new remote destination, the Association Information pane displays, which lists the desk phone numbers that have been assigned to the remote destination profile. You can click a link to open the associated Directory Number Information window.

This section describes how to access remote destination records by opening the Remote Destination Configuration window. You can also open an existing or new record in the Remote Destination Profile Configuration window by clicking the Add a New Remote Destination link at the bottom of the remote destination profile.

In Unified Communications Manager, use the Device > Remote Destination menu path to configure remote destinations.

Remote destinations represent phones that are available for Cisco Unified Mobility answer and pickup, plus locations that are used to reach Mobile Voice Access. Remote destinations may include any of the following devices:

• Single-mode mobile (cellular) phones

• Smartphones

• Dual-mode phones

• Enterprise IP phones that are not in the same cluster as the desk phone

• Home phone numbers in the PSTN.

Tips About Configuring Remote Destinations

End users can create their own remote destinations in the Cisco Unified Communications Self Care Portal. For information about how to perform this task, see the user guide for the phone model.

Be aware that the appropriate timer settings in the following table may be service-provider-specific. If difficulties in transferring calls by using the default timer settings occur, you may need to adjust the settings to be compatible with the service provider for the remote destination phone.

Check the Line Association check boxes for the desk phones that will be used with this remote destination. You must perform this step for Cisco Unified Mobility to work.

Note	This step requires that a directory number has already been configured on the remote destination profile with which the remote destination associates.

Tips About Deleting Remote Destinations

To find out which items are using the remote destination, choose Dependency Records from the Related Links drop-down list box that is on the Remote Destination Configuration window. If the dependency records are not enabled for the system, the dependency records summary window displays a message.

Cisco Unified Communications Manager allows service providers to provide base PBX-extension features such as enterprise dialing, SNR, single VM, call move, and mid-call features via the trunk without a smart client on the mobile. Basic mobile features such as Single Number Reach, Deskphone pickup, Send Call to Mobile, Mobile Voice Access and Mid-call DTMF features are supported. Extension dialing is supported if it is implemented in the network and the network is integrated with Cisco Unified Communications Manager. These features can be provided by any type of trunk.

With previous versions of Cisco Unified Communications Manager, service providers used the Remote Destination feature to deliver network-based FMC including the enterprise dialing/DVO feature without a client. This version allows for a new device type called Carrier-Integrated Mobile to deliver network-based FMC via the trunk or gateway.

When configuring the new device type Carrier-Integrated Mobile, set the Owner User ID value to the mobile user identity. The mobile user identity does not appear on the configuration page. Only end users with mobility enabled will appear in the Owner User ID drop-down on the end user page. Only one line (DN) can be associated with an FMC device. Users should associate a mobile identity with the FMC. This can be done on the FMC device configuration page after the device has been added. For calls to be extended to the number of the mobile identity, users must enable Cisco Unified Mobility on the Mobile Identity window.

Cisco Unified Communications Manager can be configured in the Ring All Shared Lines service parameter so that the shared-line is rung when mobile DN is dialed.

Note

The Reroute Remote Destination Calls to Enterprise Number feature must be enabled for Ring All Shared Lines to take effect. Reroute Remote Destination Calls to Enterprise Number is disabled by default. IMS shared lines will ring solely based on the value of the Ring All Shared Lines parameter. In previous versions of Cisco Unified Communications Manager, IMS shared lines rang based on the value of Reroute Remote Destination Calls to Enterprise Number.

You can also migrate from the Remote Destination feature used in previous versions to this new device type.

Cisco Unified Communications Manager 8.5 and earlier versions, required that Application Dial Rules be configured locally on the client side for VoIP calls and separately in Cisco Unified Communications Manager for DVO calls. To simplify configuration for both VoIP and DVO calls, Cisco Unified Communications Manager 8.6(1) allows Application Dial Rule configuration to apply to DVO as well as VoIP calls, so that there is no separate client configuration required. This allows mobile users to make calls with both the enterprise dial plan or service provider dial plan regardless of the transports and provides a consistent way to manage dial plans. When a client makes a call in either VOIP or DVO mode, the same rule applies. Mobility uses the Application Dial Rules in such a way that the client can dial a 10-digit number in VoIP mode to call an external number as it does in DVO mode.

Note	VoIP mode is applicable to only SIP based mobile clients using enbloc dialing and cannot be applied to SCCP based mobile clients using overlap dialing.

This feature uses existing Application Dial Rule configuration and Mobility is treated as an application. For more information about Dial Rules, see the Cisco Unified Communications Manager System Guide. For more information about Application Dial Rule configuration, see the Cisco Unified Communications Manager Administration Guide.

Application Dial rules are shared by all applications. Ensure that the Application Dial rules you configure for Mobility do not conflict with Application Dial rules shared among other applications.

The following table provides definitions of terms that are related to Cisco Unified Mobility with Cisco Mobile VoiP Clients.

This section provides a list of Cisco Unified Mobility features that are available to mobile phone users when the Cisco Mobile VoiP Client has been configured. This material discusses configuration within Cisco Unified Communications Manager Administration.

The following entities and features require configuration of Cisco Unified Mobility in Cisco Unified Communications Manager Administration:

• Direct connection from Cisco Unified Communications Manager to mobile client without proxy server - This feature provides server-side support for Cisco Mobile VoiP Clients to connect to Cisco Unified Communications Manager directly and thus eliminate Cisco Unified Mobility Advantage in the deployment. Cisco Unified Communications Manager adjusts to support direct connection with the Cisco Mobile VoiP Client.

• DVO Optimization Settings for Toll Reduction - This feature supports a pre-configured policy to determine which mobile origination call (DVO-R or DVO-F) yields the least cost to the enterprise; this determination is typically based on locations. Administrators assign a profile based on the user location and any other available information. Least cost routing negotiates with Cisco Unified Communications Manager to determine whether DVO-R or DVO-F generates the least cost, then chooses the less costly method for making the call.

• Enable/Disable Cisco Unified Mobility From Mobile Phone - This feature allows the Cisco Mobile VoiP Client to change the Cisco Unified Mobility status dynamically and keep the Cisco Unified Mobility Status between Cisco Unified Communications Manager and the client in sync. This feature provides the flexibility to the end user: the end user can change the user Cisco Unified Mobility status from the user mobile phone, not just from the GUI website.

The following features, which were originally part of Cisco Unified MobilityManager, now reside in Cisco Unified Communications Manager:

• Cisco Unified Mobility

• Desktop Call Pickup

• Access List

Cisco Unified Communications Manager also supports the following Cisco Unified Mobility features:

• Midcall Enterprise Feature Support Using DTMF

• Dual-mode Phone Support

• Manual Handoff of Calls on a Dual-mode Phone

• Time-of-Day Access

• Directed Call Park via DTMF

• SIP URI Dialing

See topics related to the benefits of Cisco Unified Mobility features for a discussion of other benefits of Cisco Unified Mobility features, such as simultaneous desktop ringing, single enterprise voice mailbox, system remote access, caller ID, remote on/off control, call tracing, security and privacy for Cisco Unified Mobility calls, and smartphone support.

Registration between the Cisco Mobile VoiP Client and Cisco Unified Communications Manager takes place over a separate TCP port. (The shared or pooled connection that was used by the Cisco Unified Mobility Advantage server is not used.) Keepalive messages between the Cisco Mobile VoiP Client and Cisco Unified Communications Manager remain the same as those passed between Cisco Unified Communications Manager and Cisco Unified Mobility Advantage. Cisco Mobile VoiP Client registration with Cisco Unified Communications Manager introduces no new alarms, and registration takes place over the SIP channel.

If the client is running on the iPhone and the Cisco Mobile VoiP Client is unable to complete the SIP dialog, the Cisco Unified Communications Manager retains the PSTN call. (The PSTN call does not drop even if the SIP stat times out.) For example, if Cisco Unified Communications Manager does not receive an ACK message after it sends a 200 OK message, the PSTN call gets retained.

Limitation for Direct Connection From Cisco Unified Communications Manager to Mobile Client

This feature specifies the following limitation:

• If the SIP dialog between Cisco Unified Communications Manager and the Cisco Mobile VoiP Client is not complete, the dialog cannot be used for further midcall feature invocations. The user can, however, invoke midcall features through the DTMF interface.

This feature supports a pre-configured policy to determine which mobile origination call (DVO-R or DVO-F) yields the least cost to the enterprise; this determination is typically based on locations. This feature benefits the mobile user by allowing the user to find the least cost when making a mobile call. The DNIS pool provides a list of Direct Inward Dialing (DID) numbers so that the user, if roaming, can choose a non-international number for the mobile call. Least cost routing negotiates with Cisco Unified Communications Manager to determine whether DVO-R or DVO-F generates the least cost, then chooses the less costly method for making the call.

Reasons for Least Cost Routing and DNIS Pool

The following reasons make this feature desirable:

• Administrator can decide upon the DVO call type, DVO-F or DVO-R, for least cost call routing. In certain regions and with certain service providers, DVO-F can be more economical for mobile users; in other regions, DVO-R can be more economical. For example, in regions where incoming calls are free for mobile phone users, configuring a DVO-R call for mobile phone users achieves least cost call routing.

• Scalability - Multiple users in a given region can use a single mobility profile, which comprises region, service provider, location, and so forth. Here, "users" refers to the clients under actual end users. The administrator does not need to create a mobility profile for each end user.

• Single DID within a cluster for all DVO-F calls - For such DVO-F calls, the client makes an incoming call to Cisco Unified Communications Manager by using a particular DID.

• Multisite cluster - For a multisite cluster, a client in cluster A (such as the UK) uses the DID of cluster B (such as San Jose) for DVO-F calls, which incurs costs.

• DVO-R - Trunk allows calls that originate from a local DID. At times, when a client makes an outgoing DVO-R call, the client trunk may not allow an outgoing call if the caller ID does not lie in a specific range. For example, if a UK client invokes DVO-R, the callback call from the trunk at the San Jose cluster shows 408. When this call reaches the UK, the service provider trunk may not recognize the 408 and therefore not allow the call. Therefore, the caller IDs need to specify the local identifiable values.

Characteristics of DVO Optimization Settings for Toll Reduction

This feature involves the use of mobility profiles, which the administrator configures by using the Call Routing > Mobility > Mobility Profile menu path in Cisco Unified Communications Manager Administration. See the Mobility Profile Configuration for additional details about mobility profiles.

The DVO Optimization Settings for Toll Reduction feature does not change the alternate callback mechanism that DVO-R calls use: the client continues to control alternate callback.

Limitation of DVO Optimization Settings for Toll Reduction

The DVO Optimization Settings for Toll Reduction feature specifies the following limitation:

• Least Cost Routing (LCR) rules are applied after application dial rules. Called party transformations and call forward scenarios do not get considered for LCR.

The Cisco Mobile VoiP Client can update its Cisco Unified Mobility status directly.