Cisco Unified Communications SRND Based on Cisco Unified Communications Manager 6.x
Cisco Mobility Applications
Downloads: This chapterpdf (PDF - 0.96MB) The complete bookPDF (PDF - 17.73MB) | Feedback

Cisco Mobility Applications

Table Of Contents

Cisco Mobility Applications

What's New in This Chapter

Cisco Unified Mobility

Mobile Connect

Mobile Connect Phone Support

Unified CM Service Parameters for Mobile Connect

Mobile Connect Functionality

Desk Phone Pickup

Remote Destination Phone Pickup

Mid-Call Features

Single Enterprise Voicemail Box

Enabling and Disabling Mobile Connect

Access Lists for Allowing or Blocking Mobile Connect Calls

Mobile Connect Architecture

Mobile Connect Redundancy

Unified CM Server Redundancy

PSTN Gateway Redundancy

Mobile Voice Access and Enterprise Feature Access

Mobile Voice Access and Enterprise Feature Access Phone Support

Unified CM Services and Service Parameters for Mobile Voice Access and Enterprise Feature Access

Unified CM Service for Mobile Voice Access

Unified CM Service Parameters for Mobile Voice Access and Enterprise Feature Access

Mobile Voice Access IVR VoiceXML Gateway URL

Mobile Voice Access Functionality

Mobile Voice Access Using Hairpinning

Enterprise Feature Access with Two-Stage Dialing Functionality

Desk and Remote Destination Phone Pickup

Enabling and Disabling Mobile Connect

Mobile Voice Access and Enterprise Feature Access Number Blocking

Remote Destination Configuration and Caller ID Matching

Mobile Voice Access and Enterprise Feature Access Architecture

Mobile Voice Access and Enterprise Feature Access Redundancy

Unified Mobility Design Considerations

Dial Plan Considerations for Cisco Unified Mobility

Remote Destination Profile Configuration

Automatic Caller ID Matching and Enterprise Call Anchoring

Caller ID Transformations

Maintaining and Troubleshooting Unified Mobility

Guidelines and Restrictions for Unified Mobility

Cisco Unified Mobility Performance and Capacity

Design Recommendations for Deploying Unified Mobility

Cisco Unified Mobile Communicator

Cisco Unified Mobile Communicator Phone Support and Data Plan Requirements

Cisco Unified Mobile Communicator Service and System Parameters

Cisco Unified Mobile Communicator Architecture

Cisco Unified Mobile Communicator Features and Functionality

LDAP Directory

Cisco Unified CM

Cisco Unity

Cisco Unified MeetingPlace and MeetingPlace Express

Microsoft Exchange

Secure Text Messaging and Presence

Cisco Unified Mobile Communicator Redundancy

Cisco Unified Mobile Communicator Performance and Capacity


Cisco Mobility Applications


Last revised on: July 15, 2009

 

Cisco mobility applications provide the ability to deliver the features and functionality of the enterprise IP communications environment to mobile workers wherever they might be. Mobility users can handle calls to their enterprise directory number, not only on their desk phone, but also on one or more remote phones. Mobility users can also make calls from a remote phone as if they are dialing inside the enterprise. In addition, mobility users can take advantage of enterprise features such as hold, transfer, and conference as well as enterprise applications such as voicemail, conferencing, and presence on their mobile phones. This ensures continued productivity for users even when they are traveling outside the organization.

Mobility functionality delivered within the Cisco Unified Communications solution is provided via Cisco Unified Communications Manager (Unified CM) and can be used in conjunction with the Cisco Unified Mobile Communicator application.

Cisco Unified Mobility provides the following mobility application functionality:

Mobile Connect

Mobile Connect, also known as Single Number Reach, provides Cisco Unified Communications users with the ability to be reached via a single enterprise phone number that rings on both their IP desk phone and their cellular phone simultaneously. Mobile Connect users can pick up an incoming call on either their desk or cellular phones and at any point can move the in-progress call from one of these phones to the other without interruption.

Mid-Call Features

Mid-call features allow a user to invoke hold, resume, transfer, and conference features from their mobile phone during in-progress mobility calls. These features are invoked via the mobile phone keypad and take advantage of enterprise media resources such as music on hold and conference bridges.

Single Enterprise Voicemail Box

Single Enterprise Voicemail Box ensures that any unanswered calls made to the user's enterprise number and extended to the user's mobile phone will end up in the enterprise voicemail system rather than a mobile voicemail system. This provides a single consolidated voicemail box for all business calls and eliminates the need for users to check multiple voicemail systems for messages.

Mobile Voice Access and Enterprise Feature Access with two-stage dialing

Mobile Voice Access and Enterprise Feature Access with two-stage dialing provide mobile users with the ability to make calls from their mobile phones as if they were calling from their enterprise IP desk phones. These features provide a cost savings in terms of toll charges for long distance or international calls, and they provide the enterprise with an easy way to track phone calls made by users via a uniform and centrally located set of call detail records. Furthermore, these features provide the ability to mask a user's mobile phone number when sending the outbound caller ID. Instead, the user's enterprise number is sent as the caller ID. This ensures that returned calls to the user are made to the enterprise number, thus resulting in enterprise call anchoring.

The Cisco Unified Mobile Communicator application includes a Smart Phone mobile client that provides enterprise Unified Communications features on a user's mobile phone through the use of a back-hauled data channel. The data channel is sent via the service provider data service over the Internet and is terminated at the Cisco Unified Mobility Advantage Proxy server and forwarded on to the Unified Mobility Advantage Enterprise server, which interfaces with various applications and components within the enterprise Unified Communications infrastructure. The PSTN is utilized for voice services.

Enterprise applications and features that can be integrated with the Cisco Unified Mobile Communicator application include:

LDAP directory with Microsoft Active Directory 2000 or 2003 for user authentication and directory lookups.

Voicemail with Cisco Unity for message waiting indication and visual navigation of the user's enterprise voicemail box.

Conferencing and collaboration with Cisco Unified MeetingPlace and MeetingPlace Express for receiving conference notifications.

Presence services allowing exchange of presence information between Cisco Unified Mobile Communicator clients

Enterprise call log integration with Cisco Unified Communications Manager (Unified CM) for receiving call history logs from the user's desk phone.

Messaging for sending and receiving text messages with other Cisco Unified Mobile Communicator clients.

In addition to providing the ability to integrate with various enterprise unified communications applications, Cisco Unified Mobile Communicator mobile clients can be integrated with Unified Mobility to take advantage of these various features including Mobile Connect, Mobile Voice Access, and Single Enterprise Voicemail Box.

The various applications and features discussed in this chapter apply to all Cisco Unified Communications deployment models unless otherwise noted.

This chapter begins with a discussion of Unified Mobility features, functionality, and design and deployment considerations. Given the various benefits of Unified Mobility and the fact that Cisco Unified Mobile Communicator can be integrated to take advantage of the features provided, this discussion paves the way for examination of Cisco Unified Mobile Communicator. This examination includes a discussion of architecture, functionality and design and deployment implications for the following mobility applications and features:

Cisco Unified Mobility

Mobile Connect

Mobile Voice Access and Enterprise Feature Access

Unified Mobility Design Considerations

Cisco Unified Mobile Communicator

What's New in This Chapter

Table 25-1 lists the topics that are new in this chapter or that have changed significantly from previous releases of this document.

 

Table 25-1 New or Changed Information Since the Previous Release of This Document 

New or Revised Topic
Described in:

Access lists for allowing or blocking Mobile Connect calls

Access Lists for Allowing or Blocking Mobile Connect Calls

Cisco Unified Communications Sizing Tool

Cisco Unified Mobility Performance and Capacity

Cisco Unified Mobile Communicator architecture description

Cisco Unified Mobile Communicator Architecture

Cisco Unified Mobile Communicator features and functionality

Cisco Unified Mobile Communicator Features and Functionality

Cisco Unified Mobile Communicator redundancy considerations

Cisco Unified Mobile Communicator Redundancy

Cisco Unified Mobility Advantage scalability

Cisco Unified Mobile Communicator Performance and Capacity

Design recommendations for deploying Unified Mobility, including discussion on minimizing PSTN utilization for Unified Mobility.

Design Recommendations for Deploying Unified Mobility

Enabling and disabling Mobile Connect

Enabling and Disabling Mobile Connect

Maintaining and troubleshooting Unified Mobility

Maintaining and Troubleshooting Unified Mobility

Support for Redirected Dialed Number Identification Service (RDNIS) or SIP Diversion Header for Mobile Connect calls

Design Recommendations for Deploying Unified Mobility


Cisco Unified Mobility

Cisco Unified Mobility refers to the native mobility functionality within the Cisco Unified Communications Manager (Unified CM) and includes the Mobile Connect, Mobile Voice Access, and Enterprise Feature Access features.

Unified Mobility functionality depends on the appropriate configuration of Unified CM. For this reason, it is important to understand the nature of this configuration as well as the logical components.

Figure 25-1 illustrates the configuration requirements for Unified Mobility. First, as for all users, a mobility user's enterprise phone is configured with appropriate line-level settings such as directory number, partition, and calling search space. In addition, the device-level settings of the enterprise phone include parameters such as device pool, common device configuration, calling search space, media resource group list, and user and network hold audio sources. All of these line and device settings on the user's enterprise phone affect the call routing and music on hold (MoH) behavior for incoming and outgoing calls.

Next, a remote destination profile must be configured for each mobility user in order for them to take advantage of Unified Mobility features. The remote destination profile is configured at the line level with the same directory number, partition, and calling search space as the user's enterprise phone. This results in a shared line between the remote destination profile and the enterprise phone. The remote destination profile configuration includes device pool, calling search space, rerouting calling search space, and user and network hold audio source parameters. The remote destination profile should be thought of as a virtual phone whose configuration mirrors the user's line-level enterprise phone settings, but whose profile-level configuration combined with the line-level settings determines the call routing and MoH behavior that the user's remote destination phone will inherit. The user's enterprise directory number, which is shared between the remote destination profile and the enterprise phone, allows calls to that number to be extended to the user's remote destination.

Figure 25-1 Cisco Unified Mobility Configuration Architecture

As further shown in Figure 25-1, a mobility user can have one or more remote destinations configured and associated with their remote destination profile. A remote destination represents a single PSTN phone number where a user can be reached. A user can have up to 10 remote destinations defined. Call routing timers can be configured for each remote destination to adjust the amount of time a call will be extended to a particular remote phone, as well as the amount of time to wait before extending the call and the amount of time that must pass before a call can be answered at the remote phone. Mobility users can also configure filters for each remote destination to allow or deny calls from certain phone numbers to be extended to that remote phone.

Mobile Connect

The Mobile Connect feature allows an incoming call to an enterprise user to be offered to the user's IP desk phone as well as up to 10 configurable remote destinations. Typically a user's remote destination is their mobile or cellular telephone. Once the call is offered to both the desktop and remote destination phone(s), the user can answer at any of those phones. Upon answering the call on one of the remote destination phones or on the IP desk phone, the user has the option to hand off or pick up the call on the other phone.

Mobile Connect Phone Support

Mobile Connect is supported on any of the following phone models:

Cisco Unified IP Phone 7906G

Cisco Unified IP Phone 7911G

Cisco Unified IP Phones 7941G, 7941G-GE, 7942G, and 7945G

Cisco Unified IP Phones 7961G, 7961G-GE, 7962G, and 7965G

Cisco Unified IP Phones 7970G, 7971G-GE, and 7975G

All phones listed above support Mobile Connect remote destination pickup via the Mobility softkey, with both Skinny Client Control Protocol (SCCP) and Session Initiation Protocol (SIP).

The following phones support Mobile Connect with SCCP only:

Cisco Unified IP Phone 7905G

Cisco Unified Wireless IP Phones 7921G and 7925G

Cisco Unified IP Phone 7931G

Cisco Unified IP Phone 7940G

Cisco Unified IP Phone 7960G

Mobile Connect calls that are answered at a remote destination phone can be handed off to any of the IP phone models listed above, regardless of remote destination phone type, because pickup at the IP desk phone requires only that the user hang up the remote destination phone. All pickup functionality in these scenarios is handled by Unified CM and the enterprise PSTN gateway that handled the outgoing call to the remote destination.


Note The Cisco Unified IP Phones 7905G, 7912G, 7912G-A, 7940G, and 7960G running SIP and the Cisco Unified IP Phones 7912G and 7912G-A running SCCP can be used with Mobile Connect to allow incoming calls to ring at both the desk phone and the remote destination phone. However, once the call is answered, desk phone pickup or remote destination phone pickup is not possible.


Unified CM Service Parameters for Mobile Connect

The following items represent a partial list of Unified CM service parameters for the Cisco CallManager service that are related to Mobile Connect functionality:

Enterprise Feature Access Code for Hold (Default value: *81)

This parameter indicates the feature access code used for the hold mid-call feature. This code is either manually keyed by the user or programmed as a key on a Smart Phone. This code is sent as a DTMF sequence from the remote destination phone back to the enterprise gateway and is relayed to Unified CM.

Enterprise Feature Access Code for Exclusive Hold (Default value: *82)

This parameter indicates the feature access code used for the exclusive hold mid-call feature. When exclusive hold is invoked at the remote destination phone, the call cannot be picked up or resumed at the user's desk phone. This code is either manually keyed by the user or programmed as a key on a Smart Phone. This code is sent as a DTMF sequence from the remote destination phone back to the enterprise gateway and is relayed to Unified CM.

Enterprise Feature Access Code for Resume (Default value: *83)

This parameter indicates the feature access code used for the resume mid-call feature. This code is either manually keyed by the user or programmed as a key on a Smart Phone. This code is sent as a DTMF sequence from the remote destination phone back to the enterprise gateway and is relayed to Unified CM.

Enterprise Feature Access Code for Transfer (Default value: *84)

This parameter indicates the feature access code used for the transfer mid-call feature. This code is either manually keyed by the user or programmed as a key on a Smart Phone. This code is sent as a DTMF sequence from the remote destination phone back to the enterprise gateway and is relayed to Unified CM.

Enterprise Feature Access Code for Conference (Default value: *85)

This parameter indicates the feature access code used for the conference mid-call feature. This code is either manually keyed by the user or programmed as a key on a Smart Phone. This code is sent as a DTMF sequence from the remote destination phone back to the enterprise gateway and is relayed to Unified CM.

Smart Mobile Phone Interdigit Timer (Default value: 500 ms)

This parameter specifies the interdigit timeout in milliseconds for mid-call feature access code entry when using a Smart Phone client on the remote destination phone. If this timer expires before the next digit is sent, the mid-call feature will fail. This parameter affects all remote destination phones that are configured at the Remote Destination configuration screen with the Smart Client Installed box checked.

Non-Smart Mobile Phone Interdigit Timer (Default value: 2000 ms)

This parameter specifies the interdigit timeout in milliseconds for mid-call feature access code entry when the remote destination is not a Smart Phone. If this timer expires before the next digit is sent, the mid-call feature will fail. This parameter affects only those remote destination phones that are configured at the Remote Destination configuration screen with the Smart Client Installed box unchecked. This longer interdigit timeout provides additional time between key presses in order to support manual key presses by the user.

Inbound Calling Search Space for Remote Destination (Default value: Trunk or Gateway Inbound Calling Search Space)

This parameter is available in Cisco Unified Communications Manager Release 6.1 and later 6.x releases. This parameter determines the nature of inbound call routing for calls coming into the enterprise from configured remote destination phones. By default, the inbound calling search space (CSS) of the PSTN gateway or trunk on which the call is coming in will be used to route the inbound call. If the value of this parameter is set to Remote Destination Profile + Line Calling Search Space, the Remote Destination Profile CSS (in combination with the line CSS) will be used to route the inbound call. This parameter has no affect on inbound call routing from non-remote destination phones.

Enable Enterprise Feature Access (Default value: False)

This parameter determines whether Enterprise Feature Access is enabled for the system. This parameter must be set to True in order for users to invoke mid-call features such as hold, resume, and transfer from remote destination phones as well as to use the two-stage dialing feature.

Mobile Connect Functionality

Figure 25-2 illustrates a basic Mobile Connect call flow. In this example, Phone A on the PSTN calls a Mobile Connect user's enterprise directory number (DN) 408-555-1234 (step 1). The call comes into the enterprise PSTN gateway and is extended via Unified CM to the IP phone with DN 408-555-1234 (step 2), and this phone begins to ring. The call is also extended to the user's Remote Destination Profile, which shares the same DN (step 3). In turn, a call is placed to the remote destination associated with the user's remote destination profile (in this case 408-555-7890) (step 4). The outgoing call to the remote destination is routed via the PSTN gateway (step 5). Finally the call rings at the remote destination PSTN phone with number 408 555-7890 (step 6). The call can then be answered at either phone.

Figure 25-2 Mobile Connect

Typically a Mobile Connect user's configured remote destination is their mobile phone on a global system for mobile communications (GSM) or cellular network; however, any destination reachable via the PSTN can be configured as a user's remote destination. Furthermore, a Mobile Connect user can have up to 10 remote destinations configured, so an incoming call could potentially ring as many as 10 PSTN phones as well as the user's desk phone. Once the call is answered at the desk phone or at a remote destination phone, any other call legs that have been extended to ring additional remote destinations or the desk phone (if not answered at the desk phone) will be cleared. If the incoming call is answered at the remote destination, the voice media path will be hairpinned within the enterprise PSTN gateway utilizing two DS0s or analog ports. This utilization must be considered when deploying the Mobile Connect feature.


Note In order for Mobile Connect to work as in Figure 25-2, ensure that the user-level Enable Mobility check box under the End User configuration page has been checked and that at least one of the user's configured remote destinations has the Enable Mobile Connect check box checked.


Desk Phone Pickup

As illustrated in Figure 25-3, once a user answers a Mobile Connect call at the remote destination device (step 1: in this case, 408 555-7890), at any point the user can hang up the call at the remote destination and pick it up again at their desk phone by simply pressing the Resume softkey on the desk phone (step 2: at DN 408 555-1234 in this case). The call continues uninterrupted between the original caller at Phone A and the desk phone (step 3).

Figure 25-3 Desk Phone Pickup

Desk phone pickup can be performed whenever an enterprise anchored call is in progress at a configured remote destination phone and that phone is hung up.


Note An enterprise anchored call refers to any call that has at least one call leg connected via an enterprise PSTN gateway and that was originated as either a remote destination to an enterprise DID call or as a Mobile Connect, Mobile Voice Access, or Enterprise Feature Access call.


The option to pick up or resume the call at the desk phone is available for a certain amount of time. For this reason, it is good practice for the Mobile Connect user to ensure that the calling phone hangs up before the remote destination phone is hung up. This ensures that the call cannot be resumed at the desk phone by someone else. By default, the call remains available for pickup at the desk phone for 10 seconds after the remote destination phone hangs up; however, this time is configurable and can be set from 0 and 30000 milliseconds on a per-user basis by changing the Maximum Wait Time for Desk Pickup parameter under the End User configuration page. Desk phone pickup can also be performed after invoking the mid-call hold feature at the remote destination phone. However, in these cases, the Maximum Wait Time for Desk Pickup parameter setting has no effect on the amount of time the call will be available for pickup. A call placed on mid-call hold will remain on hold and be available for desk phone pickup until manually resumed at either the remote or desktop phone.


Note If the Smart Client Installed check box on the Remote Destination configuration page is checked, indicating that a remote destination device is a Smart Phone, then desk phone pickup will not be possible when the remote destination phone is hung up. When the remote destination is a Smart Phone, desk phone pickup can be invoked only when the user explicitly places the in-progress call on enterprise hold (mid-call hold).


Remote Destination Phone Pickup

Figure 25-4 illustrates Mobile Connect remote destination phone pickup functionality. Assuming Phone A calls Mobile Connect user's enterprise DN 408 555-1234 and the call is answered at the user's desk phone and is in progress (step 1), the user must push the Mobility softkey. Assuming the Mobile Connect feature is enabled for this phone and remote pickup is available, the user presses the Select softkey (step 2). A call is generated to the user's remote destination phone (in this case, 408 555-7890), and the remote phone begins to ring. Once the call is answered at the remote phone, the call continues uninterrupted between Phone A and the Mobile Connect user's remote phone with number 408 555-7890 (step 3).

Figure 25-4 Remote Destination Phone Pickup

When a Mobile Connect user has multiple remote destinations configured, each remote destination will ring when the Pickup softkey is pressed, and the user can answer the desired phone.


Note In order for remote destination phone pickup to work as in Figure 25-4, ensure that at least one of the user's configured remote destinations has the Mobile Phone check box checked. In addition, the Mobility softkey must be configured for all mobility users by adding the softkey to each user's associated desk phone softkey template. Failure to check the Mobile Phone check box and to make the Mobility softkey available to mobility users will prevent the use of remote destination phone pickup functionality.


Mid-Call Features

As illustrated in Figure 25-5, once a user answers a Mobile Connect call at the remote destination device (step 1: in this case, 408 555-7890), the user can invoke mid-call features such as hold, resume, transfer, and conferencing by sending DTMF digits from the remote destination phone to Unified CM via the enterprise PSTN gateway (step 2). When the mid-call features hold, transfer, and conference are invoked, MoH is forwarded from Unified CM to the held party (step 3: in this case, Phone A). In-progress calls can be transferred to another phone, or additional phones can be conferenced using enterprise conference resources (step 4).

Figure 25-5 Mobility Mid-Call Feature

Mid-call features are invoked at the remote destination phone by a series of DTMF digits forwarded to Unified CM. Once received by Unified CM, these digit sequences are matched to the configured Enterprise Feature Access Codes for Hold, Exclusive Hold, Resume, Transfer, and Conference (see Unified CM Service Parameters for Mobile Connect), and the appropriate function is performed. The typical method for generating mid-call feature DTMF digit sequences is via a Smart Client on the user's remote destination phone. The Smart Client provides an easy and automated method for assigning these DTMF digit sequences to a set of softkeys on the remote destination phone. A Smart Phone user can then easily invoke the mid-call features by pressing the appropriate softkey.


Note In order to perform the transfer and conference mid-call features, a second call leg is generated by the remote destination phone to a system-configured Enterprise Feature Access DID that answers the call, takes user or Smart Phone input (including PIN number, mid-call feature access code, and target number), and then creates the required call leg to complete the transfer or conference operation. Enterprise Feature Access operations are discussed in more detail in the section on Mobile Voice Access and Enterprise Feature Access.


Table 25-2 lists the Smart Phone mid-call feature key sequences and includes not only the key presses required by the user to invoke each feature, but also the Smart Phone behavior.

 

Table 25-2 Smart Phone Mid-Call Feature Key Sequences 

Mid-Call Feature
Enterprise Feature Access Code (default)
Smart Phone Feature Name
Smart Phone Key Sequence
Smart Phone Behavior

Hold

*81

Enterprise Hold

Press:
Enterprise Hold softkey

Smart Phone sends *81

Exclusive Hold

*82

Enterprise Exclusive Hold

Press:
Enterprise Exclusive Hold softkey

Smart Phone sends *82.

[Note: This is the type of hold is invoked automatically for Smart Phone Enterprise Transfer and Enterprise Conference features, which prevents desk phone from resuming the call (see below).]

Resume

*83

Enterprise Resume

Press:
Enterprise Resume softkey

Smart Phone sends *83

Transfer

*84

Enterprise Transfer

1. Press:
Enterprise Transfer softkey

2. Enter:
<Transfer_Target/DN>

3. Upon answer by transfer target (for consultive transfer) or upon ringback (for early attended transfer), press:
Enterprise Transfer softkey

Smart Phone sends *82

Then Smart Phone automatically does the following once the transfer target/DN is entered:

1. Makes new call to pre-configured Enterprise Feature Access DID.

2. Upon Enterprise Feature Access answer, sends pre-configured PIN number followed by *84 followed by transfer target/DN.

Conference

*85

Enterprise Conference

1. Press:
Enterprise Conference softkey

2. Enter:
<Conference_Target/DN>

3. Upon answer by conference target, press:
Enterprise Conference softkey

Smart Phone sends *82

Then Smart Phone automatically does the following once the conference target/DN is entered:

1. Makes new call to pre-configured Enterprise Feature Access DID.

2. Upon Enterprise Feature Access answer, sends pre-configured PIN number followed by *85 followed by conference target/DN.



Note Currently no Smart Client applications provide programmed softkeys for automating mid-call features, therefore the only method available today for invoking mid-call features is manual key presses.


While the Smart Phone method of using mid-call features is the preferred and easiest method to use, users without Smart Clients on their remote destination phones can still take advantage of mid-call features by manually keying the feature access codes and entering the appropriate key sequences. Table 25-3 indicates the required key sequences for invoking mid-call features manually.

 

Table 25-3 Manual Mid-Call Feature Key Sequences 

Mid-Call Feature
Enterprise Feature Access Code (default)
Manual Key Sequence

Hold

*81

Enter: *81

Exclusive Hold

*82

Enter: *82

Resume

*83

Enter: *83

Transfer

*84

1. Enter: *82 (Exclusive Hold)

2. Make new call to Enterprise Feature Access DID.

3. On connect, enter:
<PIN_number> # *84 # <Transfer_Target/DN> #

4. Upon answer by transfer target (for consultive transfer) or upon ringback (for early attended transfer), enter: *84

Conference

*85

1. Enter: *82 (Exclusive Hold)

2. Make new call to Enterprise Feature Access DID.

3. On connect enter:
<PIN_number> # *85 # <Conference_Target/DN> #

4. Upon answer by conference target enter: *85


The inter-digit timeout for mid-call feature key sequences must be considered. For non-Smart Phone remote destinations, ensure that the Smart Client Installed box is unchecked on the Remote Destination configuration screen. For Smart Phones, the Smart Client Installed box should be checked. The Smart Client Installed box determines whether the Non-Smart Mobile Phone Interdigit Timer or the Smart Mobile Phone Interdigit Timer service parameters are used when determining the inter-digit timeout (see Unified CM Service Parameters for Mobile Connect). When the Smart Client Installed box is checked, the Smart Mobile Phone Interdigit Time is used. By default, this timeout is only 500 milliseconds because the mid-call features are automatically invoked using the Smart Phone softkeys. When the Smart Client Installed box is unchecked, the Non-Smart Mobile Phone Interdigit Timer is used. By default, this timeout is 2000 milliseconds and is significantly longer to allow for the manual entry of key sequences required to invoke the mid-call features.


Note Media resource allocation for mid-call features such as hold and conferencing is determined by the Remote Destination Profile configuration. The media resource group list (MRGL) of the device pool configured for the Remote Destination Profile is used to allocate a conference bridge for the conferencing mid-call feature. The User Hold Audio Source and Network Hold MoH Audio Source settings of the Remote Destination Profile, in combination with the media resource group list (MRGL) of the device pool, are used to determine the appropriate MoH stream to be sent to a held device.


Single Enterprise Voicemail Box

An additional feature that Unified Mobility provides in conjunction with Mobile Connect is the ability to have a single voicemail box for all enterprise business calls. This prevents a user from having to check multiple mailboxes (enterprise, cellular, home, and so forth) for calls to their enterprise phone number. To help implement this feature, the Remote Destination configuration page provides a set of timers that can be used in conjunction with the regular call-forward timers. The purpose of these timers is to ensure that, when and if a call is forwarded to a voicemail box on ring-no-answer, the call is forwarded to the enterprise voicemail box rather than any remote destination voicemail box. This behavior can be achieved in one of two ways:

Ensure the forward-no-answer time is shorter at the desk phone than at the remote destination phones.

To do so, ensure that the global Forward No Answer Timer field in Unified CM or the No Answer Ring Duration field under the individual phone line is configured with a value that is less than the amount of time a remote destination phone will ring before forwarding to the remote destination voicemail box. In addition, the Delay Before Ringing Timer parameter under the Remote Destination configuration page can be used to delay the ringing of the remote destination phone in order to further lengthen the amount of time that must pass before a remote destination phone will forward to its own voicemail box. However, when adjusting the Delay Before Ringing Timer parameter, take care to ensure that the global Unified CM Forward No Answer Timer (or the line-level No Answer Ringer Duration field) is set sufficiently high enough so that the mobility user has time to answer the call on the remote destination phone. The Delay Before Ringing Timer parameter can be set for each remote destination and is set to 4000 milliseconds by default.

Ensure that the remote destination phone stops ringing before it is forwarded to its own voicemail box.

You can accomplish this by setting the Answer Too Late Timer parameter under the Remote Destination configuration page to a value that is less than the amount of time that a remote destination phone will ring before forwarding to its voicemail box. This ensures that the remote destination phone stops ringing before the call can be forwarded to its own voicemail box. The Answer Too Late Timer parameter can be set for each remote destination and is set to 19,000 milliseconds by default.

To ensure that the call is still forwarded to the enterprise voicemail box in cases where a user's remote destination phone is busy and call waiting is not available or in cases where a user's cellular phone is out of range, you can use the Answer Too Soon Timer parameter on the Remote Destination configuration page. If the call is forwarded and answered right away by the remote destination voicemail, this parameter ensures that the call leg extended to the remote destination phone will be disconnected, thus allowing additional time for the desk phone to be answered or for the enterprise voicemail system to handle the call. The Answer Too Soon Timer parameter can be set for each remote destination and is set to 1500 milliseconds by default.


Note Incoming calls to a remote destination that are manually diverted by the mobility user can end up in the mobile voicemail box if the manual divert occurs after the Answer Too Soon timer has expired. To prevent this from happening, mobility users should be advised to ignore or silence the ringing of incoming calls they wish to divert to voicemail. This will ensure that unanswered calls always end up in the enterprise voicemail box.



Note In most deployment scenarios, the default Delay Before Ringing Timer, Answer Too Late Timer, and Answer Too Soon Timer values are sufficient and do not need to be changed.


Enabling and Disabling Mobile Connect

The Mobile Connect feature can be enabled or disabled using one of the following methods:

Cisco Unified CM Administration or Cisco Unified CM User Options pages

An administrator or user unchecks the Mobile Connect box to disable, or checks the Mobile Connect box to enable, the feature. This is done for each remote destination.

Mobile Voice Access or Enterprise Feature Access

A mobility-enabled user dials into the Mobile Voice Access or Enterprise Feature Access DID and, after entering appropriate credentials, enters the digit 2 to enable or 3 to disable Mobile Connect. With Mobile Voice Access, the user is prompted to enable or disable Mobile Connect for a single remote destination or all of their remote destinations. With Enterprise Feature Access, the user can enable or disable Mobile Connect only for the remote destination device from which they are calling.

Access Lists for Allowing or Blocking Mobile Connect Calls

Access lists can be configured within Cisco Unified CM and associated to a remote destination. Access lists are used to allow or block inbound calls (based on incoming caller ID) from being extended to a mobility-enabled user's remote destinations.

Access lists are configured for mobility-enabled users as either blocked or allowed. Access lists contain one or more members or filters consisting of a specific number or number mask, and the numbers are compared against the incoming caller ID of the calling party. In addition to containing specific number strings or number masks for matching caller ID, access lists can also contain a filter for incoming calls in which the caller ID is not available or is set to private. A blocked access list contains an implicit "allow all" at the end of the list so that calls from any numbers entered into the access list will be blocked but calls from all other numbers will be allowed. An allowed access list contains an implicit "deny all" at the end of the list so that calls from any numbers entered in the access list will be allowed but calls from all other numbers will be blocked.

Once configured, access lists are associated with a user's remote destination using either the Allowed Access List or Blocked Access List fields on the Remote Destination configuration screen. The selected access list provides allowed or blocked call filtering for Mobile Connect calls on a per-remote-destination basis. Access lists can be configured and associated to a remote destination by an administrator using the Cisco Unified CM Administration interface or by an end user using the Cisco Unified CM User Options interface.

Mobile Connect Architecture

The architecture of the Mobile Connect feature is as important to understand as its functionality. Figure 25-6 depicts the message flows and architecture required for Mobile Connect. The following sequence of interactions and events can occur between Unified CM, the Mobile Connect user, and the Mobile Connect user's desk phone:

1. The Mobile Connect phone user who wishes to pick up an in-progress call on their remote destination phone pushes the Mobility softkey on their desk phone (see step 1 in Figure 25-6).

2. Unified CM returns the Mobile Connect status (On or Off) and offers the user the ability to select the Send Call to Mobile Phone option (see step 2 in Figure 25-6).

3. Mobile Connect users can use the Unified CM User Options interface to configure their own mobility settings via the web-based configuration pages at

http://<Unified-CM_Server_IP_Address>/ccmuser/

where <Unified-CM_Server_IP_Address> is the IP address of the Unified CM publisher server (see step 3 in Figure 25-6).

Figure 25-6 Mobile Connect Architecture

Mobile Connect Redundancy

The Mobile Connect feature relies on the following components:

Unified CM servers

PSTN gateway

Each component must be redundant or resilient in order for Mobile Connect to continue functioning fully during various failure scenarios.

Unified CM Server Redundancy

The Unified CM server is required for the Mobile Connect feature. Unified CM server failures are non-disruptive to Mobile Connect functionality, assuming phone and gateway registrations are made redundant using Unified CM Groups.

In order for Mobile Connect users to use the Unified CM User Options web interface to configure their mobility settings (remote destinations and access lists), the Unified CM publisher server must be available. If the publisher is down, users will not be able to change mobility settings. Likewise, administrators will be unable to make mobility configuration changes to Unified CM; however, existing mobility configurations and functionality will continue.

In addition, changes to Mobile Connect status must be written by the system on the Unified CM publisher server; if the Unified CM publisher is unavailable, then enabling or disabling Mobile Connect will not be possible.

PSTN Gateway Redundancy

Because the Mobile Connect feature relies on the ability to extend additional call legs to the PSTN to reach the Mobile Connect users' remote destination phones, PSTN gateway redundancy is important. Should a PSTN gateway fail or be out of capacity, the Mobile Connect call cannot complete. Typically, enterprise IP telephony dial plans provide redundancy for PSTN access by providing physical gateway redundancy and call re-routing capabilities as well as enough capacity to handle expected call activity. Assuming that Unified CM has been configured with sufficient capacity, multiple gateways, and route group and route list constructs for call routing resiliency, the Mobile Connect feature can rely on this redundancy for uninterrupted functionality.

Mobile Voice Access and Enterprise Feature Access

Mobile Voice Access (also referred to as System Remote Access) and Enterprise Feature Access two-stage dialing are features built on top of the Mobile Connect application. Both features enable mobility-enabled users who are outside the enterprise to make calls as though they are directly connected to Unified CM. This functionality is commonly referred to as Direct Inward System Access (DISA) in traditional telephony environments. These features benefit the enterprise by limiting toll charges and consolidating phone billing directly to the enterprise rather than billing to each mobile user. In addition, these features allow the users to mask their mobile phone or remote destination numbers when sending outbound caller ID. Instead, the user's enterprise directory number is sent as caller ID. This ensures that returned calls to the user are made to the enterprise number, thus resulting in enterprise call anchoring.

Mobile Voice Access is accessed by calling a system-configured DID number that is answered and handled by an H.323 VoiceXML gateway. The VoiceXML gateway plays interactive voice response (IVR) prompts to the Mobile Voice Access user, requesting user authentication and input of a number to be dialed via the user phone keypad.

Enterprise Feature Access functionality includes the previously discussed mid-call transfer and conference features as well as two-stage dialing functionality. Two-stage dialing works the same way as Mobile Voice Access, but without the IVR prompts. The system-configured Enterprise Feature Access DID is answered by Unified CM. The user then uses the phone keypad or Smart Phone softkeys to input authentication and the number to be dialed. These inputs are received without prompts.

With both the Mobile Voice Access and Enterprise Feature Access two-stage dialing features, once the call to the input number is connected, users can invoke mid-call features or pick up the call on their desk phones just as with a Mobile Connect calls. This is possible because the call is anchored at the enterprise gateway.

Mobile Voice Access and Enterprise Feature Access Phone Support

Mobile Voice Access and Enterprise Feature Access are supported for all incoming PSTN devices capable of sending DTMF digits. Cisco Unified IP Phone support for these features is the same as for Mobile Connect (see Mobile Connect Phone Support). Although an IP phone is not required to use Mobile Voice Access or Enterprise Feature Access, a user wishing to pick up an in-progress call made by one of these features on a desk phone must have access to one of the phone models supported by Mobile Connect.

Unified CM Services and Service Parameters for Mobile Voice Access and Enterprise Feature Access

For the Mobile Voice Access application to function properly, you must enable certain services on Unified CM and configure certain parameters on Cisco Unified Mobility. This section lists those required services and parameters.

Unified CM Service for Mobile Voice Access

The Mobile Voice Access feature relies on the Cisco Unified Mobile Voice Access Service, which must be activated manually from the Unified CM Serviceability configuration page. This service can be activated on the publisher node only.

Unified CM Service Parameters for Mobile Voice Access and Enterprise Feature Access

The following items represent a partial list of Unified CM service parameters related to Mobile Voice Access and Enterprise Feature Access two-stage dialing functionality:

Enable Enterprise Feature Access (Default value: False)

This parameter determines whether Enterprise Feature Access is enabled for the system. This parameter must be set to True in order to use two-stage dialing feature as well as to invoke mid-call features such as hold, resume, and transfer from the remote destination phone.

Enable Mobile Voice Access (Default value: False)

This parameter determines whether Mobile Voice Access is enabled for the system. This parameter must be set to True in order to use the remote system access capabilities known as Mobile Voice Access.

Matching Caller ID with Remote Destination (Default value: Complete Match)

This parameter specifies whether the caller ID of a configured remote destination is completely matched or partially matched by the system for inbound calls. Based on this setting, the caller ID is completely or partially matched to the destination number configured for each remote destination. If set to Partial Match, this parameter works in conjunction with the Number of Digits for Caller ID Partial Match service parameter to determine how many numbers in the presented caller ID will be matched. Caller ID matching determines whether the system recognizes the remote destination in order to invoke Enterprise Feature Access mid-call features and two-stage dialing as well as Mobile Voice Access.

Number of Digits for Caller ID Partial Match (Default value: 10)

This parameter determines how many consecutive digits of caller ID will be matched against configured remote destinations. This parameter is used only when the Matching Caller ID with Remote Destination service parameter is set to Partial Match.

System Remote Access Blocked Numbers (Default value: <blank>

This parameter specifies a comma-separated list of numbers that cannot be dialed from remote destination phones when using the Mobile Voice Access or Enterprise Feature Access two-stage dialing features (for example, 911 or other emergency numbers). Numbers should be entered as they would be dialed from inside the enterprise, with appropriate PSTN access codes (for example, 9911), because this list of blocked numbers is applied only after any Application Dial Rules are applied.

In addition to configuring these system parameters, you must enable Mobile Voice Access for each user individually by checking the Enable Mobile Voice Access check box under the End User configuration page.

Mobile Voice Access IVR VoiceXML Gateway URL

The Mobile Voice Access feature requires the Unified CM VoiceXML application to reside on the H.323 gateway. The URL used to load this application is:

http://<Unified-CM-Publisher_IP-Address>:8080/ccmivr/pages/IVRMainpage.vxml

where <Unified-CM-Publisher_IP-Address> is the IP address of the Unified CM publisher node.

Mobile Voice Access Functionality

Figure 25-7 illustrates a Mobile Voice Access call flow. In this example, the Mobile Voice Access user on PSTN phone 408 555-7890 dials the Mobile Voice Access enterprise DID DN 408-555-2345 (step 1).

The call comes into the enterprise PSTN H.323 gateway, which also serves as the VoiceXML gateway. The user is prompted via IVR to enter their numeric user ID (followed by the # sign), PIN number (followed by the # sign), and then a 1 to make a Mobile Voice Access call, followed by the phone number they wish to reach. In this case, the user enters 9 1 972 555 3456 as the number they wish to reach (followed by the # sign) (step 2).


Note If the PSTN phone from which the Mobile Voice Access user is calling is configured as a Mobile Connect remote destination for that user and the incoming caller ID can be matched against this remote destination by Unified CM, the user does not have to enter their numeric user ID. Instead they will be prompted to enter just the PIN number.


In the meantime, Unified CM has forwarded IVR prompts to the VoiceXML gateway, the gateway has played these prompts to the user, and the gateway has collected user input including the numeric ID and PIN number of the user. This information is forwarded to Unified CM for authentication and to generate the call to 9 1 972 555 3456 (step 3). After authenticating the user and receiving the number to be dialed, Unified CM generates a call via the user's Remote Destination Profile (step 4). The outbound call to 972 555-3456 is routed via the PSTN gateway (step 5). Finally, the call rings at the PSTN destination phone with number 972 555-3456 (step 6).

Figure 25-7 Mobile Voice Access


Note In order for Mobile Voice Access to work as in Figure 25-7, ensure that the system-wide Enable Mobile Voice Access service parameter is set to True (see Unified CM Service Parameters for Mobile Voice Access and Enterprise Feature Access) and that the per-user Enable Mobile Voice Access check box on the End User configuration page is also checked.


Mobile Voice Access Using Hairpinning

In deployments where the enterprise PSTN gateways are not using H.323 protocol, Mobile Voice Access functionality can still be provided using hairpinning on a separate gateway running H.323. Mobile Voice Access using hairpinning relies on off-loading the VoiceXML functionality to a separate H.323 gateway. Figure 25-8 illustrates a Mobile Voice Access call flow using hairpinning. In this example, just as in the previous example, the Mobile Voice Access user on PSTN phone 408 555-7890 dials the Mobile Voice Access enterprise DID DN 408-555-2345 (step 1). The call comes into the enterprise PSTN gateway and, just as before, the user is prompted via IVR to enter their numeric user ID, PIN number, and then a 1 to make a Mobile Voice Access call, followed by the phone number they wish to reach.


Note When using Mobile Voice Access with hairpinning, users calling into the system will not be identified automatically by their caller ID. Instead, users will have to key in their remote destination number manually prior to entering their PIN number.


Again the user enters 9 1 972 555 3456 as the number they wish to reach (followed by the # sign) (step 2). Next the PSTN gateway collects and forwards the user input to the separate H.323 VoiceXML gateway with DID 408-555-2345, and the VoiceXML gateway plays IVR prompts to the PSTN gateway and the Mobile Voice Access user (step 3).

In the meantime, Unified CM has forwarded IVR prompts to the H.323 VoiceXML gateway, and the VoiceXML gateway in turn has collected user input (including the numeric ID and PIN number of the user) from the PSTN gateway. This information is forwarded to Unified CM for authentication and to generate the call to 9 1 972 555 3456 (step 4). After authenticating the user and receiving the number to be dialed, Unified CM generates a call via the user's Remote Destination Profile (step 5). The outbound call to 972 555-3456 is routed via the PSTN gateway (step 6). Finally, the call rings at the PSTN destination phone with number 972 555-3456 (step 7). The voice media path in the case of each Mobile Voice Access call using hairpinning is not only hairpinned within the enterprise PSTN gateway utilizing two DS0s or analog ports, but it is also hairpinned at the H.323 VoiceXML gateway.

Figure 25-8 Mobile Voice Access Using Hairpinning


Note If you deploy Mobile Voice Access in hairpinning mode, Cisco recommends configuring the Mobile Voice Access DID at the PSTN gateway and the Mobile Voice Access Directory Number within Cisco Unified CM (under Media Resources > Mobile Voice Access) as different numbers. A translation pattern within Unified CM can then be used to translate the called number of the Mobile Voice Access DID to the configured Mobile Voice Access directory number. Because the Mobile Voice Access directory number configured within Unified CM is visible to the administrator only, translation between the DID and directory number will be invisible to the end user and there will be no change in end-user dialing behavior. This is recommended in order to prevent mobility call routing issues in multi-cluster environments. This recommendation does not apply to Mobile Voice Access in non-hairpinning mode.


Enterprise Feature Access with Two-Stage Dialing Functionality

Figure 25-9 illustrates the call flow for Enterprise Feature Access two-stage dialing. In this example, the mobility user at remote destination phone 408 555-7890 dials the Enterprise Feature Access DID 408 555-2345 (step 1). Once the call is connected, the remote destination phone is used to send DTMF digits to Unified CM via the PSTN gateway, beginning with the user's PIN (followed by the # sign) which is authenticated with Unified CM. Next a 1 (followed by the # sign) is sent to indicate a two-stage dialed call is being attempted, followed by the phone number the user wishes to reach. In this case the user enters 9 1 972 555 3456 as the destination number (step 2).


Note Unlike with Mobile Voice Access, Enterprise Feature Access requires that all two-stage dialed calls must originate from a phone that has been configured as a remote destination in order to match the caller ID and PIN against the end-user account. There is no provision within Enterprise Feature Access (for either two-stage dialing or for mid-call features) in which the mobility user can enter their remote destination number or ID to identify themselves to the system. Identity can be established only via the combination of incoming caller ID and entered PIN.


Next the outgoing call is originated via the user's remote destination profile (step 3), and the call to PSTN number 972 555-3456 is routed via the enterprise PSTN gateway (step 4). Finally, the call rings the PSTN phone (step 5: in this case, 972 555-3456). As with Mobile Voice Access, the voice media path of each Enterprise Feature Access two-stage dialed call is hairpinned within the enterprise PSTN gateway utilizing two DS0s or analog ports.

Figure 25-9 Enterprise Feature Access Two-Stage Dialing Feature


Note In order for Enterprise Feature Access two-stage dialing to work as in Figure 25-9, ensure that the system-wide Enable Enterprise Feature Access service parameter is set to True (see Unified CM Service Parameters for Mobile Voice Access and Enterprise Feature Access).


Desk and Remote Destination Phone Pickup

Because Mobile Voice Access and Enterprise Feature Access functionality is tightly integrated with the Mobile Connect feature, once a Mobile Voice Access or Enterprise Feature Access two-stage dialed call has been established, the user does have the option of using Mobile Connect functionality to pick up the in-progress call on their desk phone by simply hanging up the call on the originating phone and pushing the Resume softkey on their desk phone or by using the mid-call hold feature. In turn, the call can then be picked up on the user's configured remote destination phone by pressing the Mobility softkey and selecting Send Call to Mobile Phone.

Enabling and Disabling Mobile Connect

In addition to providing users of Mobile Voice Access and Enterprise Feature Access with the ability to make calls from the PSTN as though they are within the enterprise, the functionality provided by Mobile Voice Access on the H.323 VoiceXML gateway and provided by Enterprise Feature Access also gives users the ability to remotely enable and disable their Mobile Connect functionality for each remote destination via their phone keypad. Rather than entering a 1 to make a call, users enter a 2 to turn the Mobile Connect feature on and a 3 to turn the Mobile Connect feature off.

If a user has more than one remote destination configured when using Mobile Voice Access, they are prompted to key in the remote destination phone number for which they wish to enable or disable the Mobile Connect feature. When using Enterprise Feature Access, a user can enable or disable Mobile Connect only for the remote destination phone from which they are calling.

Mobile Voice Access and Enterprise Feature Access Number Blocking

Administrators might want to prevent users of Mobile Voice Access and Enterprise Feature Access from dialing certain numbers when using these features. In order to restrict or block calls to certain numbers when using these features for off-net calls, a comma-separated list of those numbers can be configured in the System Remote Access Blocked Numbers service parameter field (see Unified CM Service Parameters for Mobile Voice Access and Enterprise Feature Access). Once this parameter is configured with blocked numbers, those numbers will not be reachable from a user's remote destination phone when using Mobile Voice Access or Enterprise Feature Access features. Numbers that administrators might want to block can include emergency numbers such as 911. When configuring blocked numbers, ensure they are configured as they would be dialed by an enterprise user, with appropriate prefixes or steering digits. For example, if an emergency number is to be blocked and the emergency number is dialed by system users as 9911, then the number configured in the System Remote Access Blocked Numbers field should be 9911.

Remote Destination Configuration and Caller ID Matching

When authenticating users for Mobile Voice Access and Enterprise Feature Access two-stage dialing functionality as well as the mid-call features Transfer and Conference, the caller ID of the calling remote destination phone is matched against all remote destinations configured within the system. Matching of this caller ID depends on a number of factors, including how the remote destination numbers are configured, whether Application Dial Rules have been configured on the system, and whether the Matching Caller ID with Remote Destination parameter is set to Partial or Complete Match (see Unified CM Service Parameters for Mobile Voice Access and Enterprise Feature Access).

To control the nature of this matching, consider the following two approaches.

Using Application Dial Rules

With this approach, remote destinations are configured just as the caller ID would be presented from the PSTN. For example, if the caller ID from the PSTN for a remote destination phone is presented as 4085557890, then this number should be configured on the Remote Destination configuration page. In order to route Mobile Connect calls appropriately to this remote destination, it is then necessary to use Application Dial Rules to prefix necessary PSTN access codes and other required digits. For example, if 9 is required to reach the PSTN when dialing calls and a 1 is required for dialing long distance, then an Application Dial Rule would have to be created with the Prefix With Pattern field set to 91. When using this approach, the Matching Caller ID with Remote Destination parameter should be left at the default setting of Complete Match.


Note Not only are Application Dial Rules applied to Mobile Connect, Mobile Voice Access, and Enterprise Feature Access calls, but they are also applied to calls made with Cisco WebDialer, Cisco Unified CM Assistant, Cisco Unified CM Attendant Console, and Cisco Unified Personal Communicator applications. For this reason, exercise care when configuring these rules to ensure that dialing behavior across all applications is as expected.


Translation patterns or digit prefix mechanisms within Cisco Unified CM route list and route group constructs can be used instead of Application Dial Rules in order to prefix appropriate PSTN steering digits.

Using Partial Caller ID Matching

With this approach, remote destinations are configured as they would be dialed from the system to the PSTN. For example, if the number for the remote destination is 14085557890 and PSTN access from the system requires a 9, then this number should be configured on the Remote Destination configuration page as 914085557890. This approach precludes the need for Application Dial Rules, but it requires that the Matching Caller ID with Remote Destination service parameter be set to Partial Match and that the Number of Digits for Caller ID Partial Match be set to the appropriate number of consecutive digits that should be matched against the remote destination caller ID (see Unified CM Service Parameters for Mobile Voice Access and Enterprise Feature Access). For example, if the caller ID for a remote destination is 14085557890 and the remote destination is configured as 914085557890, then the Number of Digits for Caller ID Partial Match would ideally be set to 10 or 11. In this example, this parameter could be set to a lower number of digits; however, always take care to ensure that enough consecutive digits are matched so that all configured remote destinations in the system are matched uniquely. If there is no exact match and more than one configured remote destination number is matched when using partial caller ID matching, the system treats this as if there is no matching remote destination number, thus requiring the user to enter their remote destination number/ID manually in the case of Mobile Voice Access before providing their PIN. With Enterprise Feature Access, there is no mechanism for the user to enter their remote destination number; therefore, when using this functionality, take care to ensure that only unique matches occur.


Note If the PSTN service provider sends variable-length caller IDs, using partial caller ID matching is not recommended because ensuring a unique caller ID match for each inbound call might not be possible. In these scenarios, using complete caller ID matching is the preferred method.


Mobile Voice Access and Enterprise Feature Access Architecture

The architecture of the Mobile Voice Access feature is as important to understand as its functionality. Figure 25-10 depicts the message flows and architecture required for Mobile Voice Access. The following sequence of interactions and events can occur between the Unified Mobility applications server, Unified CM, and the H.323 VoiceXML (VXML) gateway:

1. Unified CM forwards IVR prompts and instructions to the H.323 VXML gateway via HTTP (see step 1 in Figure 25-10). This provides the VXML gateway with the ability to play these prompts for the inbound Mobile Voice Access callers.

2. The H.323 VXML gateway uses HTTP to forward Mobile Voice Access user input back to Unified CM (see step 2 in Figure 25-10).

3. The PSTN gateway forwards DTMF digits in response to user or Smart Phone key sequences from the remote destination phone for Enterprise Feature Access two-stage dialing and mid-call features (see step 3 in Figure 25-10).

Figure 25-10 Mobile Voice Access and Enterprise Feature Access Architecture


Note While Figure 25-10 depicts the H.323 VoiceXML gateway as a separate box from the PSTN gateway, this is not an architectural requirement. Both H.323 VoiceXML functionality and PSTN gateway functionality can be handled by the same box, provided there are no requirements for the PSTN gateway to run a protocol other than H.323. An H.323 gateway is required for Mobile Voice Access VoiceXML functionality.


Mobile Voice Access and Enterprise Feature Access Redundancy

The Mobile Voice Access and Enterprise Feature Access features rely on the same components and redundancy mechanisms as the Mobile Connect feature (see Mobile Connect Redundancy). Unified CM Groups are necessary for PSTN gateway registration redundancy. Likewise, PSTN physical gateway and gateway connectivity redundancy should be provided. Redundant access between the PSTN and the enterprise is required for remote destination phones to access Mobile Voice Access and Enterprise Feature Access features in the event of a gateway failure. However, while physical redundancy can and should be provided for the H.323 VoiceXML gateway, there is no redundancy mechanism for the Cisco Unified Mobile Voice Access service on Unified CM. This service can be enabled and run on the publisher node only. Therefore, if the publisher node fails, Mobile Voice Access functionality will be unavailable. Enterprise Feature Access and two-stage dialing functionality have no such dependency on the publisher and can therefore provide equivalent functionality to mobility users (without the IVR prompts).

Unified Mobility Design Considerations

The Cisco Unified Mobility solution delivers mobility functionality via Cisco Unified CM. Functionality includes Mobile Connect, Mobile Voice Access, and Enterprise Feature Access. When deploying this functionality it is important to understand dial plan implications, guidelines and restrictions, and performance and capacity considerations.

Dial Plan Considerations for Cisco Unified Mobility

In order to configure and provision Unified Mobility appropriately, it is important to understand the call routing behavior and dial plan implications of the remote destination profile configuration.

Remote Destination Profile Configuration

When configuring Unified Mobility, you must consider the following two settings on the Remote Destination Profile configuration page:

Calling Search Space

This setting combines with the directory number or line-level calling search space (CSS) to determine which partitions can be accessed for mobility dialed calls. This affects calls made by the mobility user from the remote destination phone, including Mobile Voice Access and Enterprise Feature Access two-stage dialing as well as calls made in conjunction with mid-call transfer and conferencing features. Ensure that this CSS, in combination with the line-level CSS, contains all partitions that need to be accessed for enterprise calls originating from a user's remote destination phone.

Rerouting Calling Search Space

This setting determines which partitions are accessed when calls are sent to a user's remote destination phone. This applies to all Mobile Connect calls. When a call to a user's enterprise directory number is also sent via Mobile Connect to a user's remote destination, this CSS determines how the system reaches the remote destination phone. For this reason, the CSS should provide access to partitions with appropriate route patterns and gateways for reaching the PSTN or Global System for Mobile Communication (GSM) network.

When you configure the Remote Destination Profile Rerouting CSS, Cisco recommends that the route patterns within this CSS point to a gateway that is in the same call admission control location as the gateway used to route the inbound call to the user's desk phone. This ensures that a call admission control denial due to insufficient bandwidth between two locations will not occur when calls are routed out to the remote destination. Further, because subsequent call admission control checks after the initial Mobile Connect call is routed will not result in a denial if there is insufficient WAN bandwidth, routing the inbound and outbound call legs out a gateway or gateways in the same call admission control location ensures that subsequent desk phone or remote destination pickup operations during this call will not require call admission control, which could result in WAN bandwidth oversubscription.

Likewise, when you configure the Remote Destination Profile CSS for outbound Mobile Voice Access or Enterprise Feature Access two-stage dialing call routing, Cisco recommends that the route patterns within this calling search space point to a gateway that is in the same call admission control location as the gateway that handles the inbound call leg to the Mobile Voice Access or Enterprise Feature Access DID. This ensures that a call admission control denial due to insufficient bandwidth will not occur during initial outbound call routing to the dialed number. However, be aware that a subsequent desk phone pickup can result in WAN bandwidth oversubscription if the desk phone is in a different call admission control location than the gateway through which the Mobile Voice Access or Enterprise Feature Access DIDs are reached.

In addition, because inbound PSTN calls to the mobility-enabled users will always come into their home location gateway based on the DID of their enterprise desk phone, in situations where the mobility-enabled user has moved call admission control locations either due to an Extension Mobility login at another site or due to the physical movement of the user's desk phone to another call admission control location, pointing to an outbound gateway that is located in the same call admission control location with the gateway through which the inbound call came will not be possible in most cases. For this reason, Cisco recommends avoiding scenarios or deployments in which mobility-enabled users use extension mobility to log on to phones in call admission control locations outside their home location or physically move devices between call admission control locations. If these types of scenarios are not avoided or minimized, there is an increased potential for call leg failures due to call admission control denial or WAN oversubscription due to desk phone or remote destination pickup activity.

Automatic Caller ID Matching and Enterprise Call Anchoring

Another aspect of the Unified Mobility dial plan that is important to understand is the system behavior with regard to automatic caller ID identification for inbound calls from configured remote destination phones. Whenever an inbound call comes into the system, the presented caller ID for that call is compared against all configured remote destination phones. If a match is found, the call will automatically be anchored in the enterprise, thus allowing the user to invoke mid-call features and to pick up in-progress calls at their desk phone. This behavior occurs for all inbound calls from any mobility user's remote destination phone, even if the inbound call is not originated as a mobility call using Mobile Voice Access or Enterprise Feature Access.


Note Automatic inbound caller ID matching for configured remote destination numbers is affected by whether the Matching Caller ID with Remote Destination service parameter is set to Partial or Complete Match. See Remote Destination Configuration and Caller ID Matching, for more information about this setting.


In addition to automatic enterprise call anchoring, inbound and outbound call routing must also be considered when a configured remote destination phone is calling into the enterprise. Inbound call routing for calls from configured remote destinations occurs in one of two ways, depending on the version of Cisco Unified Communications Manager. With Cisco Unified Communications Manager Release 6.0, inbound call routing for calls coming from a configured remote destination bypass the Inbound Calling Search Space (CSS) configured for the PSTN gateway or trunk and instead the call is routed using a concatenation of the Remote Destination Profile line CSS and device-level CSS.

With Cisco Unified Communications Manager Release 6.1 and later 6.x releases, the setting of the service parameter Inbound Calling Search Space for Remote Destination (see Unified CM Service Parameters for Mobile Connect) determines the nature of inbound call routing for calls coming from a configured remote destination. By default, this service parameter is set to Trunk or Gateway Inbound Calling Search Space. With the service parameter set to the default value, inbound calls from configured remote destinations will be routed using the Inbound CSS of the PSTN gateway or trunk on which the call is coming in. If, on the other hand, the parameter Inbound Calling Search Space for Remote Destination is set to the value Remote Destination Profile + Line Calling Search Space, inbound calls coming from remote destinations will bypass the Inbound CSS of the PSTN gateway or trunk and will instead be routed using the associated Remote Destination Profile CSS (in combination with the line-level CSS).

Given the nature of inbound call routing from remote destination phones, it is important to make sure that calling search spaces are configured appropriately in order to provide access for these inbound calls to any partitions required for reaching internal enterprise phones, thus ensuring proper call routing from remote destination phones.


Note Incoming calls that do not come from a configured remote destination phone are not affected by the Inbound Calling Search Space for Remote Destination service parameter because they will always use the trunk or gateway inbound CSS.


Outbound call routing for Mobile Voice Access or Enterprise Feature Access calls always uses a concatenation of the Remote Destination Profile line CSS and device-level CSS, therefore it is important to make sure that these calling search spaces are configured appropriately in order to provide access to any route patterns necessary for off-net or PSTN access, thus ensuring proper outbound call routing from remote destination phones.

Caller ID Transformations

Any calls made into the cluster by configured remote destination numbers will automatically have their caller ID or calling number changed from the calling remote destination phone number to the enterprise directory number of the associated desk phone. For example, if a remote destination phone with number 408 555-7890 has been configured and associated to a user's enterprise desk phone with number 555-1234, then any call from the user's remote destination phone destined for any directory number in the cluster will automatically have the caller ID changed from the remote destination number of 408 555-7890 to the enterprise directory number of 555-1234. This ensures that the active call caller ID display and call history log caller ID reflect a mobility user's enterprise desk phone number rather than their mobile phone number, and it ensures that any return calls are made to the user's enterprise number, thus anchoring those calls within the enterprise.

Likewise, calls from a remote destination phone to external PSTN destinations and anchored in the enterprise via Mobile Voice Access or Enterprise Feature Access two-stage dialing, or those calls forked to the PSTN as a result of Mobile Connect, will also have caller ID changed from the calling remote destination phone number to the associated enterprise directory number.

Finally, in order to deliver the calling party number as an enterprise DID number rather than an enterprise directory number to external PSTN phones, calling party transformation patterns can be used. By using calling party transformation patterns to transform caller IDs from enterprise directory numbers to enterprise DIDs, return calls from external destinations will be anchored within the enterprise because they will be dialed using the full enterprise DID number. For more information about these transformations and dial plan implications, see Special Considerations for Cisco Unified Mobility, page 10-36.

Maintaining and Troubleshooting Unified Mobility

Unified Mobility functionality and operation can be tracked using the normal methods within a Cisco Unified CM deployment. Mobility operations and call flows are logged in the various system trace and log files just as with other call flows. Performance counters are available in the Real Time Monitoring Tool (RTMT) for tracking the overall health and utilization of the various Unified Mobility features. Furthermore, call detail records provide accurate information about the various mobility call types.

Call flows and operations of Mobile Connect, Enterprise Feature Access two-stage dialing, and other features such as desk phone and remote destination pickup, single enterprise voicemail box, and mid-call features are logged by the Cisco CallManager service in the SDI and SDL system logs just as with other normal call operations. Mobile Voice Access operations and call flows are logged by the Cisco Unified Mobile Voice Access service in the ccmivr log files. The ccmivr files log all Mobile Voice Access IVR operations, including IVR prompt requests, downloads, and play-out, as well as user input in response to prompts. To ensure that the most complete information is logged for these features, under the CM Service Group, the Cisco CallManager service trace level should be set to Detailed and the Cisco Unified Mobile Voice Access service trace level should be set to Debug.


Note Setting trace levels to Detailed and Debug can result in increased CPU utilization. These trace level settings should be set only when you are actively troubleshooting an issue or problem.


The following performance counters can be viewed in the RTMT tool to track the health and utilization of Unified Mobility:

Unified Mobility

\Cisco Mobility Manager\MobileCallsAnchored

Increments whenever an active Mobile Connect, Mobile Voice Access, Enterprise Feature Access two-stage dialed, or incoming call from a remote destination is in progress and anchored in the enterprise gateway. This counter can be collected over a period of time to determine peak call anchoring.

Mobile Connect

\Cisco Mobility Manager\MobilityFollowMeCallsAttempted

Increments each time a call to an enterprise number is extended to a remote destination via Mobile Connect.

\Cisco Mobility Manager\MobilityFollowMeCallsIgnoredDueToAnswerTooSoon

Increments each time a Mobile Connect call extended to a remote destination is pulled back because the call is answered before the Answer Too Soon Timer expires (single enterprise voicemail box feature).

Mobile Voice Access

\Cisco Mobility Manager\MobilityIVRCallsAttempted

Increments each time a mobility user makes a call using Mobile Voice Access and enters the digit 1 (indicating the desire to make a call) followed by the target number followed by #.

\Cisco Mobility Manager\MobilityIVRCallsSucceeded

Increments each time a phone dialed using Mobile Voice Access begins to ring.

\Cisco Mobility Manager\MobilityIVRCallsFailed

Increments each time a number dialed with Mobile Voice Access fails to ring due either to invalid number entry or insufficient call routing path within Cisco Unified CM.

Unified Mobility calls, like other calls to and from the system, generate call details records (CDRs). These call detail records can be examined to determine the nature of mobility call flows, how the calls were originated, and where they were terminated. This enables accurate call accounting for mobility calls. The following guidelines apply to evaluation of call records for mobility:

If a remote destination answers a Mobile Connect call, the call detail record by default will not indicate the number of the answering remote destination in the Destination Number field. However, if the "Show Line Group Member DN in finalCalledPartyNumber CDR Field" service parameter in Cisco Unified CM is set to True, then the remote destination that answered the call will be indicated in the Destination Number field of the CDR.

Call detail records for all Mobile Voice Access call flows are marked with a call type indication of Mobility_IVR, and each Mobile Voice Access call generates a single call detail record.

For each call made using Enterprise Feature Access two-stage dialing, two call detail records will be generated. One call detail record corresponds to the inbound call made by the user to the Enterprise Feature Access DID, while the other call detail record corresponds to the outbound call extended to the number the mobility user dialed.

Table 25-4 lists the common configuration issues or symptoms along with the resolution for each issue.

 

Table 25-4 Troubleshooting Common Configuration Issues 

Common Issues or Symptoms
Resolution

When the user presses the desk phone Mobility softkey, the message "You are not a valid Mobile Phone User" displays on the screen.

Configure the Owner User ID field of the user's desk phone with the appropriate user ID.

When the user presses the desk phone Mobility softkey to perform a remote destination pickup, only the Mobile Connect status is shown and "Send Call to Mobile Phone" is not displayed.

Ensure the Mobile Phone box is checked on the Remote Destination configuration screen.

When the user presses the desk phone Mobility softkey to perform a remote destination pickup and "Send Call to Mobile Phone" is selected, the message "Failed to send call to Mobile Phone" is displayed.

Ensure that an appropriate Rerouting Calling Search Space (CSS), allowing calls to be routed to the PSTN, has been configured on the Remote Destination Profile (RDP) configuration screen.

Incoming calls to a mobility-enabled user's enterprise directory number are not extended to the user's remote destination.

On the Remote Destination configuration screen:

Ensure that the Enable Mobile Connect box is checked.

Ensure that the Line Association checkbox for the enterprise directory number is checked.

Ensure that access lists are not configured and blocking extension of calls to the remote destination.

On the RDP configuration screen:

Ensure the appropriate Rerouting CSS that allows calls to reach the PSTN has been configured.

Mobile Voice Access and Enterprise Feature Access two-stage dialing calls are failing with a fast-busy tone once the user dials the target number followed by #.

Ensure an appropriate Calling Search Space that allows calls to reach the PSTN has been configured on the RDP configuration screen.


Guidelines and Restrictions for Unified Mobility

The following guidelines and restrictions apply with regard to deployment and operation of Mobile Connect within the Unified CM telephony environment:

Mobile Connect can support up to two simultaneous calls per user. Any additional calls that come in are automatically transferred to the user's voicemail.

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

Mobile Connect services do not extend to video calls. A video call received at the desktop phone cannot be picked up on the cellular phone.

The Unified CM Forced Authorization Code and Client Matter Code (FAC/CMC) feature does not work with Mobile Voice Access.

Remote destinations must be Time Division Multiplex (TDM) devices or off-system IP phones on other clusters or systems. You cannot configure IP phones within the same Unified CM cluster as remote destinations.

For additional guidelines and restrictions, refer to the Mobile Connect and Mobile Voice Access information in the latest version of the Cisco Unified Communications Manager Features and Services Guide, available at

http://www.cisco.com

Cisco Unified Mobility Performance and Capacity

Cisco Unified Mobility supports the following capacities:

Maximum of 15000 mobility-enabled users per cluster with MCS-7845 servers.

Maximum of 10000 mobility-enabled users per cluster with MCS-7835 servers.

Maximum of 4000 mobility-enabled users per cluster with MCS-7825 servers.

Maximum of 3750 remote destinations per MCS-7845 node, or 15000 per cluster.

Maximum of 2500 remote destinations per MCS-7835 node, or 10000 per cluster.

Maximum of 1000 remote destinations per MCS-7825 node, or 4000 per cluster.


Note A mobility-enabled user is defined as a user that has a remote destination profile and at least one remote destination configured or simply a mobility identity configured.


The maximum number of supported mobility-enabled users will depend on the number of remote destinations or mobility identities configured for each user. The capacity numbers for maximum number of mobility-enabled users given above assumes one remote destination or mobility identity per user. As the number of remote destinations or mobility identities per user increases, the number of supported mobility-enabled users decreases.

The above numbers are maximum capacities; however, Cisco Unified Mobility scalability and performance ultimately depend on the number of mobility users, the number of remote destinations each user has, and the busy hour call attempt (BHCA) rates of those users. Multiple remote destinations per user and/or high BHCA per user will result in lower capacity for Cisco Unified Mobility. To ensure proper sizing, use the Cisco Unified Communications Sizing Tool (Unified CST) to determine appropriate Unified Mobility capacity as well as overall system capacity. The Unified CST is available (with appropriate login account required) at

http://tools.cisco.com/cucst

Design Recommendations for Deploying Unified Mobility

Observer the following design recommendations when deploying Unified Mobility:

Ensure that the PSTN gateway protocol is capable of out-of-band DTMF relay, or allocate media termination points (MTPs) in order to covert in-band DTMF to out-of-band DTMF. When using Cisco IOS gateways for PSTN connectivity, out-of-band DTMF relay will be supported. However, third-party gateways might not support a common out-of-band DTMF method, and as a result an MTP might be required. In order to use Enterprise Feature Access Two-Stage Dialing and mid-call features, DTMF digits must be received out-of-band by Cisco Unified CM.


Note When relying on MTP for converting in-band DTMF to out-of-band DTMF, be sure to provide sufficient MTP capacity. If heavy or frequent use of Enterprise Feature Access Two-Stage Dialing or mid-call features is anticipated, Cisco recommends a hardware-based MTP or Cisco IOS software-based MTP.


Prior to deploying Unified Mobility, it is important to work with the PSTN provider to ensure the following:

Caller ID is provided by the service provider for all inbound calls to the enterprise. This is a requirement if Enterprise Feature Access Two-Stage Dialing or mid-call transfer and conferencing features are needed.

Outbound caller ID is not restricted by the service provider. This is a requirement if there is an expectation that mobility-enabled users will receive the caller ID of the original caller at their remote destination rather than a general enterprise system number or other non-meaningful caller ID.


Note Some providers restrict outbound caller ID on a trunk to only those DIDs handled by that trunk. For this reason, you might have to acquire a second PRI trunk from the provider that does not restrict caller ID. To obtain an unrestricted PRI trunk, some providers might require a signed agreement from the customer indicating they will not send or make calls to emergency numbers over this trunk.



Note Some providers allow unrestricted outbound caller ID on a trunk as long as the Redirected Dialed Number Identification Service (RDNIS) field or SIP Diversion Header contains a DID handled by the trunk. Beginning with Cisco Unified CM Release 6.1(4), the RDNIS or SIP Diversion Header for forked calls to remote destinations can be populated with the enterprise number of the user by checking the Redirecting Number IE Delivery - Outbound check box on the gateway or trunk configuration page. Contact your service provider to determine if they honor the RDNIS or SIP Diversion Header and allow unrestricted outbound caller ID.


Because mobility call flows typically involve multiple PSTN call legs, planning and allocation of PSTN gateway resources is extremely important for Unified Mobility. In cases where there are large numbers of mobility-enabled users, PSTN gateway resources will have to be increased. The following methods are recommend to minimize or reduce PSTN utilization:

Limit the number of remote destinations per mobility-enabled user to one (1). This will reduce the number of DS0s that are needed to extend the inbound call to the user's remote destination. One DS0 is consumed for each configured remote destination when a call comes into the user's enterprise directory number, even if the call is not answered at one of the remote destinations. Note that a DS0 per remote destination can be utilized for as long as 10 seconds, even if the call is not answered at the remote destination.

Use access lists to block or restrict the extension of calls to a particular remote destination based on incoming caller ID.

Educate end-users to disable Mobile Connect when it is not needed, to further eliminate DS0 utilization when a call comes in for that user's enterprise number. If Mobile Connect is disabled, incoming calls will still ring the desk phone and will still forward to enterprise voicemail if the call goes unanswered.

Due to the potential for call admission control denials resulting from insufficient WAN bandwidth between locations and the possibility that a desk phone pickup or remote destination pickup can result in a WAN bandwidth oversubscription, Cisco recommends configuring a Remote Destination Profile CSS and Rerouting CSS so that route patterns within these CSSs point to gateways that are located within the same call admission control location as the gateway on which the inbound call leg comes in. For more information, see Remote Destination Profile Configuration.

Cisco Unified Mobile Communicator

Cisco Unified Mobile Communicator is a graphical client that works in conjunction with a server running the Cisco Unified Mobility Advantage software to provide a rich user interface for accessing and controlling mobile phone features and functionality. The system integrates into existing corporate LDAP directories, allowing users to use a single set of credentials across all devices. Further, all traffic between Unified Mobile Communicator and Unified Mobility Advantage is protected by the Secure Socket Layer (SSL) protocol. Unified Mobile Communicator provides the following functionality for mobile phone users:

Access to corporate and personal directories

Presence service and status of other Cisco Unified Mobile Communicator clients

Visual access to corporate voicemail

Visibility into desk phone history of missed, placed, and received calls

Secure store-and-forward text messaging

Reception of conference notifications

Cisco Unified Mobile Communicator Phone Support and Data Plan Requirements

While the Unified Mobile Communicator client application runs on a variety of mobile devices, the sophisticated functionality imposes minimum device requirements that restrict the application to a set of supported phones. Currently two mobile operating systems are supported:

Blackberry RIM

Symbian


Note When deploying Cisco Unified Mobile Communicator with Blackberry handsets, a Blackberry Enterprise Server (version 4.1) is required.


Cisco Unified Mobile Communicator 3.x supports the following phones:

RIM OS

Blackberry 8100 (Pearl)

Blackberry 8300 (Curve)

Blackberry 8700

Blackberry 8800

Blackberry 8820

Blackberry 8830

Symbian OS

Nokia E61

Nokia E61i

Nokia E65

Despite the handset support listed above, service provider support for these handsets is also required. For this reason, support will vary depending on geographic location. Furthermore, because Cisco continuously adds support for new phones, the above list is not exhaustive. For a current list of the supported phones and service providers by geographic location, refer to the Cisco Unified Mobile Communicator product documentation available at http://www.cisco.com.

In addition to providing a supported device, the user must also be using that device with a supported data plan. The client uses a Mobile Data Network (MDN), such as General Packet Radio Service (GPRS) or Universal Mobile Telecommunications System (UMTS), to communicate with the Cisco Unified Mobility Advantage Enterprise Server. While the client and server use SSL to secure all data traffic, the client initiates connections to the server using the MDN on the port that the Unified Mobility Advantage administrator specified during installation.

Because this may be a non-traditional port, the client requires that the MDN be accessed with an unrestricted plan. By contrast, many operators offer a low-end "web only" plan that allows the client to access HTTP only over port 80. This type of plan is incompatible with Unified Mobile Communicator and will not work. Instead, the user must subscribe to a plan that allows arbitrary TCP traffic to pass from the client to any port on the server. This is sometimes referred to as a VPN plan. However, the client does not require a routable or static IP address because the Unified Mobility Advantage Enterprise Server maps dynamic and translated addresses appropriately.

Because the Cisco Unified Mobile Communicator client relies on a data connection back to the enterprise for all application integration and functionality, this data connection is extremely important. The amount of bandwidth consumed by this critical connection is highly variable. Given the variable nature of these connections, Cisco highly recommends an unlimited data plan rather than per-minute or per-byte plans for all users. However, in some deployments unlimited data plans might be cost prohibitive. For bandwidth estimation and planning purposes, Cisco has found that on average most Unified Mobile Communicator users consume approximately 5 megabytes of bandwidth per month, provided they are not using visual voicemail functionality. Of course, bandwidth consumption will vary widely depending on end-user behavior. For example, a user who performs large numbers of directory lookups or sends many text messages will consume considerably more bandwidth than a user who uses these features less frequently. For this reason, the average of 5 megabytes per month is merely a guideline. With visual voicemail, a one-minute voicemail message consumes approximately 354 kilobits, meaning that two hours of visual messages will consume all of this monthly average. Therefore it is easy to see that, when visual voicemail is in use, bandwidth requirements will be considerably higher.

Cisco Unified Mobile Communicator Service and System Parameters

While the majority of the Unified Mobile Communicator and Unified Mobility Advantage functionality works without any special configuration, the optional integration with Cisco Unified CM for enterprise call log integration and Unified Mobility integration does require configuration on Cisco Unified CM. For enterprise call log integration, end-user accounts must be configured within Cisco Unified CM, and Unified Mobile Communicator users' desk phones must be associated to these accounts. These accounts are used by the Unified Mobility Advantage Enterprise Server to monitor the desk phone of all Unified Mobile Communicator users to collect missed, received, and dialed calls. Each of these end-user accounts is limited to a maximum of 250 monitored devices, and the Unified Mobility Advantage Enterprise Server configuration allows a maximum of four account names, resulting in a maximum of 1,000 users. Each end-user account within Cisco Unified CM must be assigned to both the Standard CCM End Users group and Standard CTI Enabled group. For additional information about call log integration, refer to the Cisco Unified Mobility Advantage Installation and Upgrade Guide, available at

http://www.cisco.com/en/US/products/ps7270/prod_installation_guides_list.html

For integration with Unified Mobility, each user's Unified Mobile Communicator GSM number must be configured as a remote destination associated with the user's remote destination profile within Cisco Unified CM. For the specific configuration steps required for Unified Mobility integration, refer to the Cisco Unified Communications Manager Features and Services Guide, available at

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html

Cisco Unified Mobile Communicator Architecture

The solution consists of three primary components: Cisco Unified Mobile Communicator, the Cisco Unified Mobility Advantage Proxy Server, and the Cisco Unified Mobility Advantage Enterprise Server. (See Figure 25-11.) The Enterprise Server accesses existing corporate systems and applications, including the LDAP Server and Microsoft Exchange.

The Cisco Unified Mobility Advantage Enterprise Server contains the following sub-components:

Managed Server — The Managed Server manages communication to and from Cisco Unified Mobile Communicator and controls and runs the Cisco Unified Mobile Communicator User Portal, which enables users to provision and configure their Cisco Unified Mobile Communicator client.

Admin Server — The Admin Server controls and runs the Cisco Unified Mobility Advantage Admin Portal, which enables the administrator to configure and manage the Cisco Unified Mobility Advantage Enterprise server.

Node Manager Server — The Node Manager Server provides access to utilities needed for maintaining the server, including starting and stopping the Managed server.

Cisco Unified Mobility Advantage Database — The Cisco Unified Mobility Advantage Database is used to store application information about users, adapters, devices, and configuration.

Figure 25-11 Cisco Unified Mobile Communicator Architecture

A user session is initiated when Unified Mobile Communicator starts on the mobile device. When the application starts, it prompts the user for their LDAP password. (Because the device is associated with the user account during provisioning, the client does not need to collect a user ID). The client then initiates an SSL connection to the Cisco Unified Mobility Advantage Proxy Server using the Mobile Data Network. This appears at the proxy server as an inbound connection from the Internet. The protocol used over this connection is the Mobility Multiplexing Protocol (MMP). This protocol is optimized to conserve handset battery life. The MMP protocol is encapsulated in standards-based SSL packets.

Once the SSL connection is established, the Unified Mobility Advantage Proxy Server passes the request to the Unified Mobility Advantage Enterprise Server, which then authenticates the user against the LDAP directory. The TCP connection carrying the SSL traffic is maintained by the client, allowing the server to push traffic down to the client regardless of address translation, dynamic client addresses, and so forth. Throughout the life of the client connection, the Unified Mobility Advantage Proxy Server de-encrypts incoming packets from the client and does packet inspection to ensure that the packets are valid and from the authorized client. If they are, the proxy server re-encrypts the packets and passes them to the Unified Mobility Advantage Enterprise server.

In addition to using the LDAP credentials for authenticating the Unified Mobile Communicator client user, the Unified Mobility Advantage Enterprise Server also uses the credentials to connect to other backend application systems. For example, the server uses this information to connect to the Microsoft Exchange server as the user, accessing their calendar, personal contacts, and conference notifications.

In a Microsoft Active Directory (AD) environment, there are no sever-specific requirements for the LDAP server; any Domain Controller will work, provided it is a member of the appropriate domain. The Unified Mobility Advantage Enterprise Server submits LDAP searches to this server, and they propagate through the AD Domain as expected. In an environment that contains multiple Exchange servers, the Unified Mobility Advantage Enterprise server will query AD to determine the appropriate server for each user.

Because Cisco Unified Mobile Communicator clients connect to the Unified Mobility Advantage Proxy server from the Internet, Cisco recommends deploying the Proxy server in a demilitarized zone (DMZ) for security purposes, as shown in Figure 25-11. With this type of deployment, an external firewall should separate the Proxy server from the outside world; and because the Proxy server connects to the Unified Mobility Enterprise server from the DMZ, an internal firewall should separate the DMZ from the rest of the enterprise network. Both firewalls must be configured to allow the relevant traffic to pass from the Internet to the Proxy server, and from the DMZ to the Enterprise server within the internal enterprise network.

Two ports must be opened in the external firewall. These ports are defined during Unified Mobility Advantage installation and cannot be changed through configuration after installation. Table 25-5 lists the default values for these ports. For further details on default ports and reasonable alternatives, refer to the Cisco Unified Mobility Advantage Installation and Upgrade Guide, available at

http://www.cisco.com/en/US/products/ps7270/prod_installation_guides_list.html

Both of these ports must also be opened in the internal firewall. Additionally, the Proxy server connects to the Enterprise Server to download the proxy configuration file. This is done via an HTTP connection, also detailed in Table 25-5, which corresponds to the Admin Portal port as configured during Unified Mobility Advantage Enterprise Server installation.

 

Table 25-5 Ports Required for Communication Between Unified Mobile Communicator and the Unified Mobility Advantage Proxy and Enterprise Server 

Default Port
Protocol
Purpose
Firewall Considerations

TCP 8080

HTTP

Over-the-air Unified Mobile Communicator client provisioning for clients that use HTTP provisioning

This port must be opened in the external and internal firewalls to allow the users to download the Unified Mobile Communicator application for those clients that use HTTP provisioning (Symbian, for example). If none of the deployed clients requires HTTP provisioning, as would be the case in a Blackberry-only environment, this port can be left closed.

TCP 5443

SSL

Secure Unified Mobile Communicator client/server communication

This port is used for client-to-proxy communication for all clients and must be opened in the external and internal firewalls regardless of the deployed client base.

TCP 7080

HTTP

Retrieval of proxy configuration

This port is used by the Unified Mobility Advantage Proxy to connect to the Unified Mobility Advantage Enterprise server to download the proxy configuration. This port must be opened in the internal firewall for proper operation.


As mentioned earlier, the Unified Mobility Advantage Enterprise Server further connects to backend systems during normal operation. Table 25-6 highlights some of the most common ports for this purpose.

 

Table 25-6 Ports Required for Communication Between the Cisco Unified Mobility Advantage Enterprise Server and Backend Applications 

Port
Protocol
Purpose

TCP 443

Web-Based Distributed Authoring and Versioning (WebDAV) and OWA
(SSL)

Secure communication between Unified Mobility Advantage and Microsoft Exchange

TCP 80

Web-Based Distributed Authoring and Versioning (WebDAV) and OWA
(non-SSL)

Non-secure communication between Unified Mobility Advantage and Microsoft Exchange

TCP 2748

JTAPI

Call Log access between Unified CM and Unified Mobility Advantage

TCP 389

LDAP

LDAP Directory communication between Unified Mobility Advantage and Active Directory


For further details on the default port numbers and port modification, refer to the Cisco Unified Mobility Advantage Installation and Upgrade Guide, available at

http://www.cisco.com/en/US/products/ps7270/prod_installation_guides_list.html

Cisco Unified Mobile Communicator Features and Functionality

Cisco Unified Mobile Communicator provides users traveling outside the organization with the ability to use their mobile device to access and utilize various Unified Communications applications that reside inside the enterprise. The following enterprise applications can be integrated with the Unified Mobile Communicator solution. Each application provides the features and functionality outlined below.

LDAP Directory

The Cisco Unified Mobility Advantage server integrates with Microsoft Active Directory 2000 or 2003. This integration is required because Active Directory is used to authenticate Unified Mobile Communicator client connections. In addition to providing an authentication mechanism for clients, Active Directory is also used to resolve directory lookups from the client, providing user's with the ability to search the corporate directory from their mobile device. As shown in Figure 25-11, the integration with Active Directory is via LDAP.

Cisco Unified CM

The Cisco Unified Mobility Advantage Enterprise Server can be integrated with Cisco Unified CM to provide desk phone call log synchronization.

Unified Mobile Communicator users with call log integration enabled are able to view call history lists (missed, placed, and received calls) from their desk phone on the Unified Mobile Communicator client. As shown in Figure 25-11, a JTAPI connection is made between the Unified Mobility Advantage Enterprise Server and Unified CM. This JTAPI connection utilizes CTI to monitor incoming and outgoing calls to the user's desk phone. Note that call logs are synchronized only from the desk phone to the Unified Mobile Communicator client. Call logs are not synchronized from the Unified Mobile Communicator client to the desk phone.

In addition to integrating with Unified CM for call log integration, Unified Mobile Communicator users may also be fully integrated with Unified Mobility to take advantage of Mobile Connect, thus ensuring that incoming calls to a user's enterprise number will be extended to the user's mobile phone.

Cisco Unity

The Unified Mobility Advantage Enterprise server can be integrated with a Cisco Unity voice messaging system to provide the Unified Mobile Communicator client with message waiting indication (MWI) status for the user's enterprise voicemail box. With this integration, a user can also visually navigate their voicemail box using their mobile device. The user is able to navigate a list of all voicemails in the voicemail box. This list includes the following information:

Time the message was left

Length of the message

Caller ID or name (if available) of the person who left the message

Priority indication for the message

Current presence or availability indication of the person who left the message, if that person is a Unified Mobile Communicator user

When the user selects a message from the list, the message is downloaded by the Unified Mobile Communicator client using the data connection, and the user is able to play the message back and then delete or save the message on the voicemail system. Voicemail messages can be navigated in any order. As shown in Figure 25-11, the Unified Mobility Advantage Enterprise Server integrates with Cisco Unity via Microsoft Exchange using the Web-based Distributed Authoring and Versioning (WebDAV) protocol.


Note In order to integrate with Unified Mobility Advantage, Cisco Unity must be deployed in Unified Messaging mode.


Cisco Unified MeetingPlace and MeetingPlace Express

The Unified Mobility Advantage Enterprise Server can be integrated with Cisco Unified MeetingPlace or MeetingPlace Express so that Unified Mobile Communicator users can receive conference notifications or invitations to Cisco Unified MeetingPlace or MeetingPlace Express meetings. These meeting notifications include the subject, the time and date, dial-in number, and meeting ID of the conference. The user can then click to call the dial-in number.


Note Click-to-join is not supported. User must manually enter the meeting ID once the call is connected.


Integration with Cisco Unified MeetingPlace and Meeting Place Express is done via a direct connection from the Unified Mobility Advantage Enterprise Server to the Microsoft Exchange server utilized by the conferencing system. This connection uses the WebDAV protocol, as shown in Figure 25-11. Cisco Unified MeetingPlace and MeetingPlace Express notifications are received only for conference calls scheduled with the Outlook plugin, which result in calendar entries in the users' primary Microsoft Exchange server.

Microsoft Exchange

In addition to communicating with Microsoft Exchange for Cisco Unity voicemail integration and Cisco Unified MeetingPlace and MeetingPlace Express conferencing integration, the Cisco Unified Mobility Advantage Enterprise Server also integrates with Microsoft Exchange via WebDAV to facilitate maintenance of the users' personal contact lists that are stored on Exchange. Integration with Exchange also provides the ability to update users' presence status automatically based on their Exchange calendar availability. Integration with Microsoft Exchange is a requirement for the Unified Mobile Communicator solution even when not integrating with Cisco Unity or Cisco Unified MeetingPlace or MeetingPlace Express. Cisco Unified Mobile Communicator supports Microsoft Exchange 2000 and 2003.

Secure Text Messaging and Presence

In addition to the above application integrations and functionality, Unified Mobile Communicator users can also send secure text messages to one another using the Unified Mobile Communicator client. These messages are exchanged using the mobile data connection, therefore no SMS provider charges are incurred.

Likewise, Unified Mobile Communicator users can also exchange presence status regarding their availability. Unified Mobile Communicator clients receive presence information for other Unified Mobile Communicator clients within the user's directory list, voicemail message list, call history logs, and text message list. Unified Mobile Communicator users can manually adjust their availability within the client or rely on automatic updates to availability based on Exchange personal calendar availability and desk phone line status.

Message and presence status exchanges are facilitated natively within the Cisco Unified Mobility Advantage Enterprise Server and are therefore possible only between Unified Mobile Communicator clients.

Cisco Unified Mobile Communicator Redundancy

The Cisco Unified Mobile Communicator client relies completely upon the backhauled data connection across the GPRS or mobile data network to the Cisco Unified Mobility Advantage Enterprise server for application interaction and functionality. If this data connection is lost due to a failure in the GPRS network, loss of connectivity to the GPRS network, or failure of the Unified Mobility Advantage Proxy or Enterprise servers, then access to enterprise applications will be unavailable. Given any of these types of failures, users will be unable to use Unified Mobile Communicator to take advantage of the various application integrations. For example, the user would be unable to perform directory lookups, send text messages to other clients, access visual voicemail, access personal contacts, receive message waiting indication, receive conference notifications, or update presence status.

While the features and functionality provided by Unified Mobile Communicator will be unavailable if the data connection to the enterprise is unavailable, users will still be able to make and receive phone calls with their mobile devices using the GSM or mobile voice network as usual. In addition, if the user and the mobile phone have been integrated with Unified Mobility on Unified CM, then Mobile Connect functionality as well as features such as Mobile Voice Access and Enterprise Feature Access will still be available.

Failure of enterprise applications such as Cisco Unified CM or Cisco Unity can result in loss of particular functions, depending on the nature of these applications within the deployment. However, in many cases, multiple adapters may be configured within the Unified Mobility Advantage Enterprise Server and, assuming redundancy has also been provided for the various applications, often functionality can be maintained given an application or application server failure.

Cisco Unified Mobile Communicator Performance and Capacity

The Cisco Unified Mobility Advantage Enterprise Server is supported on the Cisco MCS-7845 H2/I2 server and supports up to 1,000 Unified Mobile Communicator clients.

To support more than 1,000 Unified Mobile Communicator users within a deployment, additional Unified Mobility Advantage Enterprise and Proxy servers may be installed. However, Unified Mobile Communicator clients configured and associated to one Unified Mobility Advantage Enterprise server will not be able to send text messages to clients on another server. Further, only a single Unified Mobility Advantage Proxy server and Unified Mobility Advantage Enterprise server is supported per Unified CM cluster.

When integrating Unified Mobile Communicator with Cisco Unified CM for enterprise call log integration, the Unified Mobility Advantage Enterprise Server interacts with Cisco Unified CM CTIManager for desk phone line monitoring. For each Unified Mobile Communicator enabled for call log integration, the Unified Mobility Advantage Enterprise server generates one CTI connection to the CTIManager. Therefore, in a deployment of Unified Mobile Communicator with one fully populated Unified Mobility Advantage Enterprise Server and call log integration enabled for all users, 1,000 CTI connections will be consumed. For this reason, when you deploy Unified Mobile Communicator with call log integration, you must consider the number of required CTI connections with regard to the overall cluster limit for CTI connections (10,000 CTI connections per Cisco Unified CM cluster with the MCS-7845 platform or 3,200 CTI connections per cluster with the MCS-7835 and MCS-7825 servers). If additional CTI connections are required for other applications, they can limit the capacity of Unified Mobile Communicator users with call log integration enabled.