Cisco Unified Communications SRND Based on Cisco Unified Communications Manager 7.x
Cisco Mobility Applications
Downloads: This chapterpdf (PDF - 2.43MB) The complete bookPDF (PDF - 16.32MB) | 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

Access Numbers for Mobile Voice Access and Enterprise Feature Access

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

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 Integration with Cisco Unified CM

Cisco Unified Mobile Communicator Architecture

Cisco Unified Mobile Communicator Features and Functionality

LDAP Directory

Cisco Unified CM

Cisco Unified Presence

Cisco Unity and Unity Connection Voice Mail

Cisco Unified MeetingPlace

Microsoft Exchange

Secure Text Messaging

Cisco Unified Mobile Communicator Redundancy

Cisco Unified Mobile Communicator Performance and Capacity

Design Recommendations for Deploying Cisco Unified Mobile Communicator

Dual-Mode Phones and Clients

Dual-Mode Phone Architecture

Voice over Wireless LAN Network Infrastructure

Dual-Mode Features and Functions

Dual-Mode Clients: Cisco Mobile

Dual-Mode Clients: Nokia Call Connect

High Availability for Dual-Mode Phones

Capacity Planning for Dual-Mode Phones

Design Considerations for Dual-Mode Phones


Cisco Mobility Applications


Last revised on: June 4, 2010

 

Cisco mobility applications provide the ability to deliver 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 through 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 at 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, conferencing, and directed call park features from their mobile phone during in-progress mobility calls. These features are invoked from 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 in 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 phone as if they were calling from their enterprise IP desk phone. These features provide a cost savings in terms of toll charges for long distance or international calls as well as calls to internal non-DID extensions on the system which would not normally be reachable from outside the enterprise. These two-stage dialing features also 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 outbound caller ID. Instead, the user's enterprise 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.

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 by means of the service provider data service over the Internet and is terminated at the Cisco Adaptive Security Appliance (ASA) and forwarded on to the Unified Mobility Advantage server, which interfaces with various applications and components within the enterprise Unified Communications infrastructure. The PSTN and mobile voice network are 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 for user authentication and directory lookups

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

Conferencing and collaboration with Cisco Unified MeetingPlace for receiving conference notifications

Presence integration with Cisco Unified Presence, allowing exchange of presence information and synchronization of buddy lists with other clients and applications such as Cisco Unified Personal Communicator.

Enterprise call log and dial-via-office with Cisco Unified Communications Manager (Unified CM) for receiving call history logs from the user's desk phone and for providing the ability to dial calls via the enterprise IP telephony infrastructure.

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 communication applications, Cisco Unified Mobile Communicator mobile client can be integrated with Unified Mobility to take advantage of these various features including Mobile Connect, 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

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 Mobile Communicator 7.x client support for Nokia Symbian and Apple iPhone handsets

Cisco Unified Mobile Communicator Phone Support and Data Plan Requirements

Cisco Unified Mobile Communicator features and functionality, including Cisco Unified Presence federation and dial-via-office

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 Cisco Unified Mobile Communicator, including security, certificate, and firewall requirements

Design Recommendations for Deploying Cisco Unified Mobile Communicator

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

Design Recommendations for Deploying Unified Mobility

Directed Call Park mid-call feature

Mid-Call Features

Dual-mode phone solutions, including coverage for the Cisco Mobile iPhone dual-mode client and the Nokia Call Connect dual-mode client

Dual-Mode Phones and Clients

Enabling and disabling Mobile Connect

Enabling and Disabling Mobile Connect

Maintaining and troubleshooting Unified Mobility

Maintaining and Troubleshooting Unified Mobility

Mobile Voice Access support for SIP VoiceXML gateways

Mobile Voice Access and Enterprise Feature Access

New Dial-via-Office Forward feature for the iPhone

Cisco Unified Mobile Communicator Features and Functionality

New iPhone feature for click-to-join from conference notifications

Cisco Unified Mobile Communicator Features and Functionality

Removal of Microsoft Exchange requirement for Cisco Unified Mobile Communicator 7.1 and later releases

Cisco Unified Mobile Communicator Features and Functionality

Replacement of Unified Mobility Advantage Proxy server with ASA TLS Proxy

Cisco Unified Mobile Communicator Architecture

Support for Cisco Unified Mobility Advantage on the Cisco MCS-7825 Media Convergence Server

Cisco Unified Mobile Communicator Performance and Capacity

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

Design Recommendations for Deploying Unified Mobility

Support for service provider VoIP-based SIP trunks with Unified CM 7.1(2) and later releases

Guidelines and Restrictions for 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 line. 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

Cisco IP Communicator

All phones listed above support Mobile Connect remote destination pickup by means of 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 7920, 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 Cisco Unified IP Phones 7905G, 7912G, 7912G-A, 7940G, and 7960G running SIP and 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 keyed manually by the user. 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 keyed manually by the user. 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 keyed manually by the user. 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 keyed manually by the user. 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 keyed manually by the user. This code is sent as a DTMF sequence from the remote destination phone back to the enterprise gateway and is relayed to Unified CM.

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

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 effect 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 through 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 through 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 by means of 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 gateway 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 resumes 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 hangs up the call.


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 to 30,000 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.

Remote Destination Phone Pickup

Figure 25-4 illustrates Mobile Connect remote destination phone pickup functionality. Assuming Phone A calls the 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 destination 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 resumes 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 Select 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, conference, and directed call park by sending DTMF digits from the remote destination phone to Unified CM via the enterprise PSTN gateway (step 2). When the mid-call feature hold, transfer, conference, or directed call park is 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 directed call park number, 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.


Note To enable the Directed Call Park mid-call feature, you must configure Cisco Unified CM with directed call park numbers and call park retrieval prefixes.



Note In order to perform the transfer, conference, and directed call park 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 input (including PIN number, mid-call feature access code, and target number), and then creates the required call leg to complete the transfer, conference, or directed call park operation.


Mid-call features are accessed by manually keying the feature access codes and entering the appropriate key sequences. Table 25-2 indicates the required key sequences for accessing mid-call features.

 

Table 25-2 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

Directed Call Park

N/A

1. Enter: *82 (Exclusive Hold)

2. Make new call to Enterprise Feature Access DID.

3. On connect, enter:
<PIN_number> # *84 # <Directed_Call_Park_Number> # *84 #

Note To retrieve a parked call, the user must use Mobile Voice Access or Enterprise Feature Access Two-Stage Dialing to place a call to the directed call park number. When entering the directed call park number to be dialed, it must be prefixed with the appropriate call park retrieval prefix.

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



Note Media resource allocation for mid-call features such as hold and conference 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, is 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 by 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 per 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. 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.

Desk phone Mobility softkey

The user presses the Mobility softkey when the phone is in the on-hook state and selects either Enable Mobile Connect or Disable Mobile Connect. With this method, Mobile Connect is enabled or disabled for all of the user's remote destinations.

Cisco Unified Mobile Communicator client

Users with a remote destination phone running the Cisco Unified Mobile Communicator client can toggle the Mobile Connect feature status by changing the Single Number Reach setting to Enable or Disable under the client Preferences settings screen. This will enable or disable Mobile Connect for the Cisco Unified Mobile Communicator remote destination only.

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. Furthermore, these access lists are invoked based on the time of day.

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 filters 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 where 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 in 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 configured Ring Schedule under the Remote Destination configuration screen, the configured Ring Schedule in combination with the selected access list provides time-of-day call filtering for Mobile Connect calls on a per-remote-destination basis. Access lists and Ring Schedules 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 either enable or disable the Mobile Connect feature or 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 when the phone is in the Connected state, or it offers the user the ability to enable or disable the Mobile Connect status when the phone is in the On Hook state (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. Finally, 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 allow a mobility-enabled user who is outside the enterprise to make a call 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. These features also enable mobile users to dial internal extensions or non-DID enterprise numbers that would not normally be reachable from outside the enterprise.

Mobile Voice Access is accessed by calling a system-configured DID number that is answered and handled by an H.323 or SIP VoiceXML (VXML) 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.


Note Mobile Voice Access support for SIP VXML gateways requires Unified CM 7.1(3) or later release.


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 two-stage dialing, 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 or SIP 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 or SIP 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 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 or SIP, 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 (step 2) and is forward to Unified CM for call handling (step 3). Unified CM next routes the inbound call to the H.323 VoiceXML gateway (step 4). The user is then prompted by IVR to enter their numeric user ID, PIN, and then a 1 to make a Mobile Voice Access call, followed by the phone number they wish to reach. Again the user enters 9 1 972 555 3456 as the number they wish to reach (followed by the # sign).


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. The reason the user is not automatically identified is that, for hairpinning deployments, the PSTN gateway must first route the call to Unified CM to reach the hairpinned Mobile Voice Access gateway. Because the call is routed to Unified CM first, the conversion of the calling number from a mobile number to an enterprise directory number occurs prior to the call being handled by the Mobile Voice Access gateway. This results in the Mobile Voice Access gateway being unable to match the calling number with a configured remote destination, and therefore the system prompts the user to enter their remote destination number. This is unique to hairpinning deployments; with normal Mobile Voice Access flows, the PSTN gateway does not have to route the call to Unified CM first in order to access Mobile Voice Access because the functionality is available on the local gateway.


In the meantime, the H.323 VoiceXML gateway collects and forwards the user input to Unified CM and then plays the forwarded IVR prompts to the PSTN gateway and the Mobile Voice Access user. Unified CM in turn has received user input, authenticated the user, and forwarded appropriate IVR prompts to the H.323 VoiceXML gateway based on user input (step 5). After receiving the number to be dialed, Unified CM generates a call using the user's Remote Destination Profile (step 6). The outbound call to 972 555-3456 is routed through the PSTN gateway (step 7). Finally, the call rings at the PSTN destination phone with number 972 555-3456 (step 8).

In the case of each Mobile Voice Access call using hairpinning, the voice media path is hairpinned not only within the enterprise PSTN gateway utilizing two gateway ports, but also at the H.323 VoiceXML gateway.

Figure 25-8 Mobile Voice Access Using Hairpinning


Note When deploying 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.



Note Mobile Voice Access in hairpinning mode is supported only with H.323 VXML gateways.


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 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 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 or SIP 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 two-stage dialing 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.

Access Numbers for Mobile Voice Access and Enterprise Feature Access

While the Unified CM system allows the configuration of only a single Mobile Voice Access Directory Number and a single Enterprise Feature Access Number, this does not preclude the use of multiple externally facing numbers that can access these internally configured numbers. For example, consider a system deployed in the US in New York City with a remote site in San Jose as well as overseas in London. Even though the system may have the Mobile Voice Access directory number configured as 555-1234, the gateways at each location can be configured to map a local or toll-free DID number to this Mobile Voice Access directory number. For example, the gateway in New York may have DIDs of +1 212 555 1234 and +1 800 555 1234, which both map to the Mobile Voice Access number, while the gateway in San Jose has a DID of +1 408 666 5678 and the gateway in London has a DID of +44 208 777 0987, which also map to the Mobile Voice Access number of the system. By acquiring multiple local or toll-free DID numbers, system administrators can ensure that two-stage dialed calls will always originate as a call into the system that is either local or toll free, providing further reductions in telephony costs.

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, 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 and Enterprise Feature Access feature is as important to understand as their functionality. Figure 25-10 depicts the message flows and architecture required for Mobile Voice Access and Enterprise Feature Access. The following sequence of interactions and events can occur between Unified CM, the PSTN gateway, and the H.323 or SIP VXML gateway:

1. Unified CM forwards IVR prompts and instructions to the H.323 or SIP 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 or SIP 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 or SIP VoiceXML gateway as a separate box from the PSTN gateway, this is not an architectural requirement. Both 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 or SIP. An H.323 or SIP 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 or SIP 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

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 configuring 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 routing calls 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 configuring the Remote Destination Profile CSS for outbound Mobile Voice Access or Enterprise Feature Access 2-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.

Finally, because inbound PSTN calls to the mobility-enabled user will always come in 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 that the inbound call came in on 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 setting of the service parameter Inbound Calling Search Space for Remote Destination (see Unified CM Service Parameters for Mobile Connect). 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 Calling Search Space (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.

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, the CM Service Group 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 used only when actively troubleshooting an issue or problem.


The following performance counters can be viewed in the RTMT tool to track 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 an invalid number entry or an insufficient call routing path within Cisco Unified CM.

Unified Mobility calls, like other calls to and from the system, generate call detail 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 Cisco Unified CM service parameter 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 are 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-3 lists the common configuration issues or symptoms and the resolution for each issue.

 

Table 25-3 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 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 is supported only with PRI TDM PSTN connections. T1 or E1-CAS, FXO, FXS, and BRI PSTN connections are not supported. This PRI requirement is based on the fact that Cisco Unified CM must receive expeditious answer and disconnect indication from the PSTN in order to ensure full feature support. Answer indication is needed in order for Cisco Unified CM to stop ringing the desk phone and other remote destinations when a Mobile Connect call is answered at a particular remote destination. In addition, answer indication is required in order to support the single enterprise voicemail box feature. Finally, disconnect indication is required for desk phone pickup. A PRI PSTN connection will always provide answer or disconnect indication.

Mobile Connect is also supported over SIP trunk VoIP PSTN connections as long as the Cisco IOS Unified Border Element provides the demarcation point between the Unified CM SIP trunk and the service provider trunk and as long as mid-call features (or other DTMF-dependent features) are not in use. Mid-call features are not supported over VoIP PSTN connections. A VoIP-based PSTN connection is still able to provide expeditious answer and disconnect indication to Unified CM due to the end-to-end signaling path provided by VoIP-based PSTN connections.

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 information on Cisco Unified Mobility in the latest version of 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 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 assume 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.


Note A mobility identity is configured just like a remote destination within the system and has the same capacity implications as a remote destination. Unlike a remote destination, however, the mobility identity is associated directly to a phone device rather than a remote destination profile. The mobility identity applies only to dual-mode phones and Cisco Unified Mobile Communicator clients.


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 or mobility identities 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

Observe 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, conference, and directed call park 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, a second PRI trunk that does not restrict caller ID might have to be acquired from the provider. 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 7.1(3), 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 may be used 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. Because access lists can now be invoked based on the time of day, this eliminates the need for repeated updates of access lists by the end-user or the administrator.

Educate end-users to disable Mobile Connect when 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 may result in a WAN bandwidth oversubscription, Cisco recommends configuring 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 mobility solution that provides users the ability to access and leverage Cisco Unified Communications applications from their mobile phones. The Cisco Unified Mobile Communicator and Cisco Mobile graphical clients work 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 and buddy synchronization with the enterprise

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

Dial-via-office using Cisco Unified CM


Note Not all functionality listed above is available on all supported handsets or mobile operating systems.


Cisco Unified Mobile Communicator Phone Support and Data Plan Requirements

While the Cisco 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.

Cisco Unified Mobile Communicator 7.x is designed to run on the following mobile operating systems or handsets:

Windows Mobile 6.0 or 6.1 Standard

Nokia Symbian and Nokia S60 Third Edition (Nokia handsets)

Apple iPhone 3G or 3GS running firmware version 3.0.1 or later (iPhone handsets)

Research in Motion (RIM) Blackberry (Blackberry handsets)


Note The Cisco Unified Mobile Communicator client for the iPhone and Blackberry devices is called Cisco Mobile.


Handset model support varies according to the mobile operating system (OS); however, specific handset support certification is not required. For each mobile OS, Cisco requires handsets to support a minimum set of requirements. These requirements vary per mobile OS, but the following list contains general requirements that handsets must meet in order to be supported:

Specific version of mobile OS (varies per OS)

Specific form factors, screen sizes, and keyboard technologies (varies per operating system)

Installed root certificate from recognized Certificate Authority (VeriSign or GeoTrust)

No restrictions on installing or running third-party applications


Note Actual user experience can vary between devices.


For more details on specific handset requirements, refer to the Compatibility Matrix for Cisco Unified Mobility Advantage and Cisco Unified Mobile Communicator, available at

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

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 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 over port 80 only. 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 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 for all users rather than per-minute or per-byte plans. 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.6 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, sends many text messages, or makes large numbers of dial-via-office calls will consume considerably more bandwidth than a user who uses these features less frequently. For this reason, the average of 5.6 megabytes per month is merely a guideline. With visual voicemail, a one-minute voicemail message consumes approximately 354 kilobits, meaning that approximately two hours of visual messages will consume all of this monthly average. Therefore, it is easy to see that bandwidth requirements will be considerably higher when visual voicemail is in use.

Cisco Unified Mobile Communicator Integration with Cisco Unified CM

In order to support enterprise call log integration, dial-via-office functionality, and Unified Mobility integration with the Cisco Unified Mobile Communicator solution, the Cisco Unified Mobility Advantage server must be integrated to Unified CM. This requires an administrator to perform a number of configuration steps on Unified CM. For enterprise call log integration, application 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 Server to monitor the desk phones of all Unified Mobile Communicator users to collect missed, received, and dialed calls. Each of these application user accounts is limited to a maximum of 250 monitored devices, and the Unified Mobility Advantage Server configuration allows a maximum of four account names, resulting in a maximum of 1,000 users. Each application user account within Cisco Unified CM must be assigned to both the Standard CTI Allow Call Monitoring group and Standard CTI Enabled group.

For dial-via-office functionality and integration with Unified Mobility, each user's Unified Mobile Communicator device must be configured as a device within Cisco Unified CM, this device must be configured with the user's enterprise number (the same directory number as the user's desk phone), and a mobility identity configured with the GSM number of the user's mobile phone must be associated to this device.

For more information on integration with Unified CM, including configuration steps for enterprise call log integration, dial-via-office, and Unified Mobility integration, refer to the Cisco Unified Mobility Advantage installation and configuration documentation available at

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

Cisco Unified Mobile Communicator Architecture

The solution consists of three primary components: Cisco Unified Mobile Communicator, the Adaptive Security Appliance (ASA) TLS Proxy, and the Cisco Unified Mobility Advantage Server. (See Figure 25-11.) The Cisco Unified Mobility Advantage Server accesses existing Unified Communications applications and corporate systems, including as shown in Figure 25-11.

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 Microsoft Active Directory password. (Because the device is associated with the user account during provisioning, the client does not have to collect a user ID). The client then initiates an SSL connection to the ASA TLS Proxy using the Mobile Data Network. This appears at the proxy 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 ASA passes the request to the Unified Mobility Advantage 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 ASA TLS Proxy de-encrypts incoming packets from the client and does deep packet inspection to ensure that the packets are valid and are from the authorized client. If they are, the ASA proxy re-encrypts the packets and passes them to the Cisco Unified Mobility Advantage Server.

In addition to using the LDAP credentials for authenticating the Unified Mobile Communicator client user, the Unified Mobility Advantage Server also uses the credentials to connect to other back-end 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.

Whether deploying the ASA as both a TLS Proxy and firewall or deploying the ASA as simply a TLS Proxy in a DMZ and relying on some external firewall, you must configure two ports and open them on both the externally facing firewall or interface (between the Internet and the DMZ) and the internally facing firewall or interface (between the DMZ and the enterprise). A port in each of the following sets of ranges must be opened for both the external and internal firewalls:

External Firewall Ports

Client Connection Port (TCP/SSL) in the range of 5400 to 5500

Provisioning Port (HTTP) in the range of 9000 to 9100

Internal Firewall Ports

Client Connection Port (TCP/SSL) in the range of 5400 to 5500

Provisioning Port (HTTP) in the range of 9000 to 9100


Note The default client connection port (TCP/SSL) is 5443, and the default provisioning port (HTTP) is 9080.



Note You do not have to open the provisioning port in the firewall if you are deploying only iPhone or Blackberry handsets because these handsets do not download the Cisco Unified Mobile Communicator client over the provisioning port. For iPhone handsets, the client is downloaded from the Apple App Store; and for Blackberry handsets, the client is pushed to the handset via the Blackberry Enterprise Server (BES).


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

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.

For a complete list of the supported applications and versions that can integrate with the Cisco Unified Mobile Communicator solution, refer to the Compatibility Matrix for Cisco Unified Mobility Advantage and Cisco Unified Mobile Communicator, available at

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

LDAP Directory

The Cisco Unified Mobility Advantage server integrates with Microsoft Active Directory. This integration is required because Active Directory is used to authenticate Unified Mobile Communicator client connections. The user's Active Directory account password is never stored on the Cisco Unified Mobility Advantage server or the Unified Mobile Communicator client. 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

Cisco Unified Mobility Advantage Server can be integrated with Cisco Unified CM to provide desk phone call log synchronization, dial-via-office, and Unified Mobility integration.

Desk Phone Call Log Integration

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 Server and Unified CM. This JTAPI connection utilizes CTI to monitor incoming and outgoing calls to the primary line of 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.

Dial-via-Office

Dial-via-office functionality provides the ability to initiate a call from the mobile phone running the Cisco Unified Mobile Communicator client, using the Cisco Unified CM telephony infrastructure and enterprise PSTN gateway. This functionality is facilitated by SIP signaling over a SIP connection between the Unified Mobility Advantage Server and Unified CM, as shown in Figure 25-11.

Utilization of dial-via-office can be mandated by the Unified Mobility Advantage administrator for all calls made from the mobile phone by the Unified Mobile Communicator user. However, calls to configured emergency numbers or direct-dial numbers will bypass the dial-via-office mandate. Administrators may also choose to allow Unified Mobile Communicator users to decide if and when they use the dial-via-office feature. In those situations, the end-user can configure the phone to always use dial-via-office when making calls (except for calls to emergency numbers or direct-dial numbers they have configured, which are always signaled over the mobile voice network) or to prompt them on a per-call basis.

There are two types of dial-via-office supported with the Cisco Unified Mobile Communicator solution:

Dial-Via-Office Reverse Callback

Dial-Via-Office Forward

Dial-Via-Office Reverse Callback

Figure 25-12 illustrates a dial-via-office reverse callback call flow. In this example, a Unified Mobile Communicator user wishes to dial the PSTN phone 972-555-7890. The user dials the number or selects the number from a contact or directory list, which generates a SIP INVITE over the data connection to the enterprise and the Cisco Unified Mobility Advantage Server (step 1). This SIP INVITE is encapsulated in the MMP protocol and sent over the secure connection through the ASA or BES server (depending on the client type) between the client and the Cisco Unified Mobility Advantage server. The request is then forwarded by the Cisco Unified Mobility Advantage server over the SIP connection to Cisco Unified CM (step 2). Unified CM then generates a callback to the user's mobile phone number using the enterprise PSTN gateway (step 3). Once the incoming call from Unified CM is auto-answered at the mobile device, a call is extended to the number the user called or selected (step 4; in this case, 972-555-7890). Once the call is answered at the far end, the call is anchored through the enterprise PSTN gateway (step 5). Because the call is now anchored in the enterprise gateway, the user has the ability at any point during this call to use the Unified Mobility desk phone pickup feature as well as to invoke Unified Mobility mid-call features.


Note All voice or media from the user's mobile phone will always travel over the mobile voice network. Media never traverses the data connection to the enterprise. The mobile data network connection is used only for call signaling traffic and other application interactions.


Figure 25-12 Cisco Unified Mobile Communicator, Dial-via-Office Reverse Callback

In addition to having the dial-via-office reverse callback feature call back to the Cisco Unified Mobile Communicator device; users are also given the option of providing, within the Unified Mobile Communicator client configuration, an alternative number on which to be called back. For example, rather than receiving the callback on the mobile phone, the user could direct the callback to a conference room phone.


Note When invoking the dial-via-office reverse callback feature, if the callback from Unified CM is directed to a user-specified alternate number, users will have no ability to perform desk phone pickup or to invoke mid-call features for that call.


Dial-via-office reverse callback is supported for Windows Mobile, Nokia, and Blackberry mobile handsets.

Dial-Via-Office Forward

Figure 25-13 illustrates a dial-via-office forward call flow. In this example, a Unified Mobile Communicator user wishes to dial the PSTN phone 972-555-7890. The user dials the number or selects the number from a contact or directory list, which generates a SIP INVITE over the data connection to the enterprise and the Cisco Unified Mobility Advantage Server (step 1). This SIP INVITE is encapsulated in the MMP protocol and sent over the secure connection through the ASA or BES server (depending on the client type) between the client and the Cisco Unified Mobility Advantage server. The request is then forwarded by the Cisco Unified Mobility Advantage server over the SIP connection to Cisco Unified CM (step 2). Unified CM then responds back to the Cisco Unified Mobility Advantage server with the configured system-wide Enterprise Feature Access number, which is then forwarded back to the user's mobile device over the secure connection through the ASA or BES server, depending on the client type (step 3). Once the number is received at the mobile device, the Cisco Unified Mobile Communicator client automatically generates an outgoing call from the mobile device to the Enterprise Feature Access number (step 4). Once this call is received by Unified CM, the system matches the inbound caller ID against the configured mobility identity for the user. If the inbound caller ID matches the user's configured mobility identity, a call is made by the system to the number the user dialed or selected (step 5; in this case, 972-555-7890). Once the call is answered at the far end, the call is anchored through the enterprise PSTN gateway (step 6). Because the call is now anchored in the enterprise gateway, the user has the ability at any point during this call to use the Unified Mobility desk phone pickup feature as well as to invoke Unified Mobility mid-call features.


Note In order for the dial-via-office forward call to be completed successfully, Unified CM must receive an inbound caller ID from the PSTN network that matches the mobility identity number configured for the Unified Mobile Communicator device placing the dial-via-office call. If the inbound caller ID from the PSTN is not received or does not match the user's configured mobility identity, the dial-via-office forward call will fail.



Note All voice or media from the user's mobile phone will always travel over the mobile voice network. Media never traverses the data connection to the enterprise. The mobile data network connection is used only for call signaling traffic and other application interactions.


Figure 25-13 Cisco Unified Mobile Communicator, Dial-via-Office Forward


Note With iPhone firmware versions prior to 3.1, the dial-via-office call will not complete automatically and will require manual intervention by the user to complete the call. The user will receive a dialog box on the client in step 3 of Figure 25-13 and must select Call in order for the call to the Enterprise Feature Access number in step 4 to be generated.


In order for Cisco Unified Mobile Communicator to be able to dial the Enterprise Feature Access number sent by Unified CM for a dial-via-office forward call, the number sent must be a full E.164 number so that it can be dialed via the mobile voice network. If the number configured in the Enterprise Feature Access Directory Number field within Unified CM (under Call Routing > Mobility Configuration) is not a full E.164 number, the administrator should configure the Dial-via-Office Forward Service Access Number service parameter for the Cisco CallManager service with the full E.164 number that corresponds to the Enterprise Feature Access directory number configured within Unified CM. If the Dial-via-Office Forward Service Access Number service parameter is not configured, Unified CM will send the Enterprise Feature Access directory number exactly as configured. If this number is not a full E.164, the call from the Cisco Unified Mobile Communicator into the Unified CM system (step 4 of Figure 25-13) will fail, thus rendering the dial-via-office forward feature inoperable.

As an example, suppose the Enterprise Feature Access directory number is configured within Unified CM as 51234. Then in situations where the Dial-via-Office Forward Service Access Number is not configured, Unified CM will forward the Enterprise Feature Access number back to Unified Mobility Advantage as 51234, resulting in the call dialog at the Unified Mobile Communicator device to display 51234. If the user selects the Call option, the phone will attempt to call 51234 over the mobile voice network, and this call will fail. However, if the Dial-via-Office Forward Service Access Number is configured as 9195551234, then Unified CM will forward the Enterprise Feature Access number back to Unified Mobility Advantage as 9195551234. This ensures that, when the user selects the Call option, the call will be routed properly over the mobile voice network and PSTN back to the enterprise.

Dial-via-office forward is supported with Cisco Mobile, the Cisco Unified Mobile Communicator clients for the iPhone and Blackberry.

Unified Mobility Integration

In addition to integrating with Unified CM for call log integration and dial-via-office, Unified Mobile Communicator users may also be 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. Unlike with previous versions of Unified CM, the integration of Cisco Unified Mobile Communicator clients with Unified Mobility in Unified CM 7.x and later releases is done through a configured mobility identity associated directly to the Cisco Unified Mobile Communicator device within Unified CM. In previous versions of Unified CM, Unified Mobile Communicator clients were integrated with Unified Mobility through a remote destination associated to a remote destination profile. The configuration settings for a mobility identity within Unified CM are the same as a remote destination. Furthermore, all of the guidelines surrounding configuration of the remote destination number and caller ID matching (see Remote Destination Configuration and Caller ID Matching) apply to configuration of the mobility identity number as well. Within the Unified Mobile Communicator 7.x client interface, the user has the ability to enable or disable Mobile Connect (Single Number Reach) under the General settings menu.

Cisco Unified Presence

The Unified Mobility Advantage Server can be integrated with Cisco Unified Presence so that Unified Mobile Communicator users are able to update their presence status or availability to the enterprise network. Likewise, the Unified Mobile Communicator client receives presence information for other enterprise clients within the user's buddy list, directory list, contact list, voicemail message list, and call history logs. Presence status and buddy lists are synchronized between the Unified Mobile Communicator client and the user's Cisco Unified Personal Communicator client. Unified Mobile Communicator users can manually adjust their availability within the client or rely on automatic updates to availability based on Microsoft Exchange personal calendar availability and desk phone line status. As shown in Figure 25-11, integration with Cisco Unified Presence is done using a SIP/SIMPLE connection between the Unified Mobility Advantage Server and the Cisco Unified Presence server.


Note Cisco Mobile, the Unified Mobile Communicator client for the iPhone, does not display presence status or support sending or receiving of presence status updates.


Cisco Unity and Unity Connection Voice Mail

The Unified Mobility Advantage server can be integrated with Cisco Unity (in Unified Messaging or Integrated Messaging mode) and Cisco Unity Connection voicemail systems 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 messages 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 providing presence status to the enterprise presence infrastructure

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 and then delete or save the message on the voicemail system. Changes to the status of a voicemail message made by the Cisco Unified Mobile Communicator client (for example, marking the message as read or deleting the message) are propagated to the voicemail system and are appropriately reflected on the user's desk phone and other clients such as Cisco Unified Personal Communicator. Voicemail messages can be navigated in any order. As shown in Figure 25-11, Unified Mobility Advantage Server integrates with Cisco Unity or Unity Connection using the IMAP protocol.

Cisco Unified MeetingPlace

The Unified Mobility Advantage Server can be integrated with Cisco Unified MeetingPlace so that Unified Mobile Communicator users can receive conference notifications or invitations to MeetingPlace 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 supported only with Cisco Mobile, the Cisco Unified Mobile Communicator for the iPhone and Blackberry. For all other Cisco Unified Mobile Communicator clients, the user must manually enter the meeting ID once the call is connected.


Integration with Cisco Unified MeetingPlace is done via a direct connection from the Unified Mobility Advantage Server to the Microsoft Exchange server utilized by the conferencing system. This connection uses the web-based Distributed Authoring and Versioning (WebDAV) protocol, as shown in Figure 25-11. Prior to version 7.1, Cisco Unified Mobile Communicator clients received Cisco Unified MeetingPlace notifications only for conference calls scheduled with the Outlook plug-in. Beginning with Cisco Unified Mobile Communicator 7.1, it is no longer necessary to schedule conferences using the Outlook plug-in in order to receive notifications for the conferences. Conference notifications can also now be received for conferences scheduled using the Unified MeetingPlace web user interface.

In order for conference notifications to be received by Cisco Unified Mobile Communicator clients (including Cisco Mobile), the Cisco Unified MeetingPlace meeting notification email templates must be modified to include a cump:// prefixed link in each meeting notification. The Cisco Unified Mobility Advantage server looks for this link in all meeting notifications contained within the user's Exchange mailbox. If this link is not present in a meeting notification, then notification of the meeting will not be listed or received by the client. For details surrounding the required modifications to the Cisco Unified MeetingPlace meeting notification email templates, refer to the Cisco Unified Mobility Advantage configuration guides at

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

Beginning with Cisco Unified Mobility Advantage 7.1(3), the integration to MeetingPlace not only supports conference notifications but also allows the user to click-to-join a conference without the need to enter a password or meeting ID. This click-to-join functionality is facilitated by a SOAP call to the Web Services API of the MeetingPlace server, as shown in Figure 25-11. While the integration to MeetingPlace for conference notifications continues to be done through Exchange using the WebDAV protocol with version 7.1(3), support for Cisco MeetingPlace Express has been dropped due to the fact that MeetingPlace Express does not support click-to-join through SOAP.


Note Click-to-join is supported only with Cisco Mobile, the Unified Mobile Communicator client for the iPhone and Blackberry.


In deployments where Cisco WebEx is providing web sharing capabilities for Cisco Unified MeetingPlace meetings, the iPhone and Blackberry Cisco Mobile clients will cross-launch the Cisco WebEx Meeting Center application on the iPhone or Blackberry (assuming this application has already been installed on the device). For this cross-launch to work, the Cisco Unified MeetingPlace system must be successfully integrated with Cisco WebEx.

Microsoft Exchange

In addition to communicating with Microsoft Exchange for Cisco Unified MeetingPlace conferencing integration, the Cisco Unified Mobility Advantage Server also integrates with Microsoft Exchange via WebDAV to facilitate maintenance of the user's personal contact lists that are stored on Exchange. Integration with Exchange also provides the ability to update a user's presence status automatically based on their Exchange calendar availability. Prior to Cisco Unified Mobile Communicator and Unified Mobility Advantage 7.1(3), integration with Microsoft Exchange is a requirement for this solution, even when not integrating with Cisco Unified MeetingPlace or utilizing personal contact lists and calendar integration. Beginning with version 7.1(3), integration to Microsoft Exchange is optional and is required only if conference notifications, personal contact lists, or calendar integration are needed.

Secure Text Messaging

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. This message exchange is facilitated natively within the Cisco Unified Mobility Advantage Server. These messages are exchanged using the mobile data connection, therefore no SMS provider charges are incurred.


Note Cisco Mobile, the Unified Mobile Communicator client for the iPhone, does not support secure text messaging using the Cisco Unified Mobility Advantage server.


Cisco Unified Mobile Communicator Redundancy

The Cisco Unified Mobile Communicator client is completely reliant upon the backhauled data connection across the mobile data network to the Cisco Unified Mobility Advantage 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 mobile data network, or failure of the ASA TLS Proxy, BES server, or Cisco Unified Mobility Advantage Server, then access to enterprise applications will be unavailable. Given any of these types of failures, users will be unable to access 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, update or synchronize buddy lists and presence information, or make calls using the dial-via-office feature.


Note Given a failure of the data connection between the Cisco Unified Mobile Communicator client and Cisco Unified Mobility Advantage or a failure of the connection between Cisco Unified Mobility Advantage and Cisco Unified CM, the client will fall back to direct dial even in cases where dial-via-office has been mandated administratively.


While the features and functions provided by Unified Mobile Communicator will be unavailable if the data connection to the enterprise is unavailable, the user will still be able to make and receive phone calls with their mobile device using the 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 Presence, Cisco Unified CM, or Cisco Unity and Unity Connection can result in loss of particular functions, depending on the nature of these applications within the deployment. However, in many cases multiple adapters can be configured within the Unified Mobility Advantage 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 Server supports the following user capacities:

Cisco MCS 7845-H2/I2 supports up to 1,000 Unified Mobile Communicator clients.

Cisco MCS 7825-H4/I4, running Cisco Unified Mobility Advantage 7.1(3) or later release, supports up to 500 Unified Mobile Communicator clients.

Cisco MCS 7825-H2/I2 or 7825-H3/I3, running Cisco Unified Mobility Advantage 7.0(2) or later release, supports up to 250 Unified Mobile Communicator clients.

To support more than 1,000 Unified Mobile Communicator users within a deployment, additional Unified Mobility Advantage Servers may be installed. However, Unified Mobile Communicator clients configured and associated to one Cisco Unified Mobility Advantage Server will not be able to send text messages to clients on another server.

When integrating Unified Mobile Communicator with Cisco Unified CM for enterprise call log integration, the Unified Mobility Advantage Server interacts with Unified CM CTIManager for desk phone line monitoring. For each Unified Mobile Communicator enabled for call log integration, the Cisco Unified Mobility Advantage Server generates one CTI connection to the CTIManager. Therefore, with a deployment of Unified Mobile Communicator with one fully populated Unified Mobility Advantage Server running on an MCS 7845 with 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 following cluster-wide limits for CTI connections:

20,000 CTI connections per Unified CM cluster with Cisco MCS 7845-H2/I2 servers.

10,000 CTI connections per Unified CM cluster with Cisco MCS 7845-H1/I1 servers.

8,000 CTI connections per Unified CM cluster with Cisco MCS 7835-H2/I2 servers.

3,600 CTI connections per Unified CM cluster with Cisco MCS 7825-H3/I3 and 7825-H4 servers.

3,200 CTI connections per Unified CM cluster with all other Cisco MCS 7825 and MCS 7835 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.

Integration of Unified Mobile Communicator with Unified CM for dial-via-office and Unified Mobility functionality requires the configuration of each Unified Mobile Communicator as a Unified CM device and configuration of the mobile number as a mobility identity. Therefore, when implementing these integrations, you must also consider overall Unified CM phone and mobility-enabled user capacities.

Design Recommendations for Deploying Cisco Unified Mobile Communicator

Observe the following design considerations when deploying Cisco Unified Mobile Communicator:

For security reasons, the Cisco Unified Mobility Advantage server should be deployed behind the enterprise firewall because it is the integration point for all enterprise services and applications.

Because the Cisco Adaptive Security Appliance (ASA) serves as a proxy server for communications between Cisco Unified Mobile Communicator clients and the Cisco Unified Mobility Advantage server, the ASA should be deployed in the enterprise DMZ.

An SSL certificate from a Certificate Authority must be obtained. The certificate is required in order to enable encryption of data flowing between Cisco Unified Mobile Communicator clients and the Cisco Unified Mobility Advantage server.

SSL certificates must be obtained from well-known certificate authorities VeriSign or GeoTrust because mobile phones have limited capabilities in terms of importing root certificates. Root certificates from VeriSign and GeoTrust are commonly available on most mobile handsets.

Firewall ports in the corporate firewall must be opened to allow connectivity from the Cisco Unified Mobile Communicator clients on the Internet to the ASA in the DMZ and from the ASA in the DMZ to the Cisco Unified Mobility Advantage server in the enterprise. The following firewall ports must be opened:

Client connection port (SSL): a single TCP port in the range 5400 to 5500 (default port is 5443)

Provisioning port (HTTP): a single TCP port in the range 9000 to 9100 (default port is 9080)


Note You do not have to open the provisioning port in the firewall if you are deploying only iPhone or Blackberry handsets because these handsets do not download the Cisco Unified Mobile Communicator client over the provisioning port. For iPhone handsets, the client is downloaded from the Apple App Store; and for Blackberry handsets, the client is pushed to the handset via the Blackberry Enterprise Server (BES).


Microsoft Active Directory is required to authenticate Cisco Unified Mobile Communicator users. All Cisco Unified Mobile Communicator users must have a valid account within Microsoft Active Directory, otherwise authentication will fail and user will not be able to utilize features and services provided by this solution.

Always ensure that appropriate back-end enterprise application servers have been deployed and configured appropriately based on the Cisco Unified Mobile Communicator solution features and functionality required. For a complete list of supported features and the required back-end application servers, refer to the Compatibility Matrix for Cisco Unified Mobility Advantage and Cisco Unified Mobile Communicator, available at

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

If you deploy Cisco Mobile, the Unified Mobile Communicator client for the Blackberry, you must also deploy a Blackberry Enterprise Server (BES) with Mobile Data Services (MDS) and integrate it directly to the Unified Mobility Advantage server. Cisco Mobile clients on Blackberry devices do not connect to the enterprise ASA but instead use the secure Research In Motion (RIM) mobile network operations center (NOC) and the secure connection from the NOC to the enterprise BES server before connecting to the Unified Mobility Advantage server.

Dual-Mode Phones and Clients

As the prevalence of mobile users, mobile phones, and mobile carrier services continues to increase, the ability to use a single device for voice and data services both inside and outside the enterprise becomes increasingly attractive. Dual-mode phones and the clients that run on them afford an enterprise the ability to provide customized voice and data services to users while inside the enterprise and to leverage the mobile carrier network as a backup provider of general voice and data services, all by using a single mobile phone. By enabling voice and data services inside the enterprise and providing network connectivity for dual-mode phones, enterprises are able to provide these services locally at reduced connectivity costs. For example, voice over IP (VoIP) calls made on the enterprise network will typically incur less cost than those same calls made over the mobile voice network.

This section examines dual-mode phone architecture and common functions and features provided by dual-mode phones and clients, including hand-off considerations related to moving an active voice call between the enterprise WLAN network and the mobile voice network. After covering general dual-mode solution architecture and features and functions, this section provides coverage of various capabilities and integration considerations for two specific dual-mode clients:

Cisco Mobile — A dual-mode client for the iPhone mobile device, providing the ability to make VoIP calls on the enterprise WLAN network as well as to access corporate directory and voicemail services.

Nokia Call Connect — A dual-mode client for Nokia mobile devices, providing the ability to make VoIP calls on the enterprise WLAN network as well as to access corporate directory and other applications and services.

In addition, this section discusses high availability and capacity planning considerations for dual-mode phones and clients.

Dual-Mode Phone Architecture

Dual-mode phones provide two physical interfaces or radios that enable the device to connect to both mobile voice and data carrier networks by means of traditional cellular or mobile network technologies and wireless local area networks (WLANs) using IEEE 802.11 standards.


Note The use of the term dual-mode phone in this section refers specifically to devices with 802.11 radios in addition to the cellular radio for carrier voice and data network connectivity. Dual-mode devices that provide Digital Enhanced Cordless Telecommunications (DECT) or other wireless radios and/or multiple cellular radios are outside the scope of this section.


Figure 25-14 depicts the basic dual-mode solution architecture for incorporating dual-mode devices into a Cisco Unified Communications System. The dual-mode phone associates to the enterprise WLAN, and then the dual-mode client registers to Cisco Unified CM as an enterprise phone. Once registered, the dual-mode device relies on the underlying enterprise Cisco IP telephony network for making and receiving calls. Only when enterprise WLAN connectivity is unavailable, will the dual-mode phone fall back to the mobile voice network for making and receiving calls. When the dual-mode phone is associated to the enterprise WLAN and the client is registered to Unified CM, the phone will be reachable through the user's enterprise number. Any inbound calls to the user's enterprise number will ring the dual-mode phone. If the user has a Cisco IP desk phone, then the dual-mode client registration enables a shared line instance for the user's enterprise number so that an incoming call rings both the user's desk phone and the dual-mode phone. When unregistered, the dual-mode client will not receive incoming enterprise calls at the dual-mode phone unless the user has been enabled for Cisco Unified Mobility and Mobile Connect (or single number reach) has been turned on for the user's mobile number.

Figure 25-14 Dual-Mode Phone Architecture

Dual-mode phones must be capable of dual transfer mode (DTM) in order to be connected simultaneously to both the mobile voice and data network and the WLAN network. This allows the device to be reachable and able to make and receive calls on both the cellular radio and WLAN interface of the device. In some cases proper dual-mode client operation might not be possible if mobile voice and data networks do not support dual-connected devices.

Voice over Wireless LAN Network Infrastructure

Before considering the various dual-mode features and functions and the impact these features and functions have on the enterprise telephony infrastructure, it is critical to plan and deploy a finely tuned, QoS-enabled, and highly available WLAN network. Because dual-mode phones rely on the underlying WLAN infrastructure for carrying both critical signaling and other traffic for setting up calls and accessing various applications as well as the real-time voice media traffic, deploying a WLAN network optimized for both data and real-time voice traffic is necessary. A poorly deployed WLAN network will be subjected to large amounts of interference and diminished capacity, leading not only to poor voice quality but in some cases dropped or missed calls. This will in turn render the WLAN deployment unusable for making and receiving voice calls. Therefore, when deploying dual-mode phones, it is imperative to conduct a WLAN radio frequency (RF) site survey before, during, and after the deployment to determine appropriate cell boundaries, configuration and feature settings, capacity, and redundancy to ensure a successful voice over WLAN (VoWLAN) deployment. Each dual-mode phone device type and/or client should be tested on the WLAN deployment to ensure proper integration and operation prior to a production deployment. Using a WLAN that has been deployed and configured to provide optimized VoWLAN services (such as the Cisco Unified Wireless Network), including quality of service, will ensure a successful dual-mode phone deployment.

A WLAN network consists of one or more wireless access points (APs), which provide wireless network connectivity for wireless devices. Wireless APs are the demarcation point between the wireless network and the wired network. Multiple APs are deployed and distributed over a physical area of coverage in order to extend network coverage and capacity. APs can be deployed autonomously within the network so that each AP is configured, managed, and operated independently from all other APs, or they can be deployed in a managed method in which all APs are configured, managed, and controlled by a WLAN controller. In the latter method, the WLAN controller is responsible for managing the APs as well as handling AP configuration and inter-AP roaming. In either case, to ensure successful VoWLAN deployment, APs should be deployed using the following general guidelines:

As shown in Figure 25-15, WLAN Channel Cell Overlap APs should be deployed with cell overlap of 20% for 2.4 GHz (802.11b/g) deployments. Channel overlap for 5 GHz (802.11a) deployments should overlap between 15% and 20%.

This overlap ensures that a dual-mode device can successfully roam from one AP to the next as the device moves around within a location while still maintain voice and data network connectivity. A device that successfully roams between two APs is able to maintain an active voice call without any noticeable change in the voice quality or path.

Figure 25-15 WLAN Channel Cell Overlap

As shown in Figure 25-16, WLAN Cell Radius and Same Channel Cell Separation APs should be deployed with cell power-level boundaries (or channel cell radius) of -67 decibels per milliwatt (dBm). Additionally, the same-channel cell boundary separation should be approximately 19 dBm.

A cell radius of approximately -67 dBm (or less) minimizes packet loss, which can be problematic for real-time voice traffic. A same-channel cell separation of 19 dBm is critical to ensure that APs or clients do not cause co-channel interference to other devices associated to the same channel, which would likely result in poor voice quality. The cell radius guideline of -67 dBm applies for both 2.4 GHz (802.11b/g) and 5 GHz (802.11a) deployments.

Figure 25-16 WLAN Cell Radius and Same Channel Cell Separation


Note The 19 dBm same-channel cell separation is simplified and is considered ideal. It is very unlikely that this 19 dBm of separation can be achieved in most deployments. The most important RF design criteria are the -67 dBm cell radius and the 15% to 20% recommended overlap between cells. Designing to these constraints optimizes channel separation.


When deploying or tuning a WLAN network for dual-mode phone connectivity, it is also important to consider high availability and capacity in order to ensure resilient and sufficient coverage for the number of devices being deployed. A WLAN network should be deployed in a manner that ensures that adequate and redundant cells of coverage are provided without overlapping same-channel cells. By providing ample cell coverage without same-channel cell overlap and sufficient non-same-channel cell overlap in order to facilitate roaming between APs, network connectivity for dual-mode clients can be made highly available. The chances of oversubscribing a VoWLAN deployment are greatly minimized by deploying sufficient numbers of APs to handle required call capacities. AP call capacities are based on the number of simultaneous VoWLAN calls that can be supported in a single channel cell area. The general rule for VoWLAN call capacities is as follows:

Maximum of 14 simultaneous VoWLAN calls per 2.4 GHz (802.11b/g) channel cell. For 802.11b-only deployments or deployments where there are large numbers of active 802.11b clients, a maximum of 7 simultaneous VoWLAN calls per channel cell is supported.

Maximum of 20 simultaneous VoWLAN calls per 5 GHz (802.11a) channel cell

These call capacity values are highly dependent upon the RF environment, the VoWLAN dual-mode handset features, and underlying WLAN system features. Actually capacities for a particular deployment could be less.


Note A single call between two dual-mode phones associated to the same AP is considered to be two simultaneous VoWLAN calls.


Most wireless APs and dual-mode phone clients also provide a variety of security options for providing secure access to the enterprise WLAN. In all cases, select a security method supported by both the WLAN infrastructure and the dual-mode phones that matches the security policies and requirements of the enterprise.

For more information on the Cisco Unified Wireless Network Infrastructure, see Wireless LAN Infrastructure. For more details on Voice over WLAN design, refer to the Voice over Wireless LAN Design Guide, available at

http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns820/landing_voice_wireless.html


Note While most dual-mode phones and clients are capable of attaching to public and private WLAN access points or hotspots and connecting back to the enterprise through the Internet for call control and other Unified Communications services, Cisco cannot guarantee voice quality for these types of connections. Cisco recommends an enterprise class voice-optimized WLAN network for connecting dual-mode phones and clients. Most public and private WLAN APs and hotspots are tuned for data applications and devices. In these cases, the AP radios are turned to maximum power, and dynamic-power clients are tuned to maximum power on network attachment, to allow for larger client capacities. While this may be ideal for data applications that are capable of retransmitting dropped or lost packets, for voice applications this can result in very poor voice quality due to the potential for large numbers of dropped packets.


Dual-Mode Features and Functions

Dual-mode devices provide a range of features and functions. While features and operations may vary from device to device, the common operations and behaviors described in this section apply to all dual-mode devices.

Enterprise Call Routing

Because dual-mode phones leverage the enterprise telephony infrastructure and call control services at least some of the time, it is important to understand the nature and behavior of call routing when the dual-mode device is inside the enterprise.

Inbound Call Routing

Because the dual-mode device is registers to Unified CM as a user's enterprise extension with enterprise number, the dual-mode device rings when incoming calls to the system are destined for that user's enterprise number. This occurs for incoming calls originated on the PSTN or from other Unified CM clusters or enterprise IP telephony systems as well as for incoming calls originated within the Unified CM cluster by other users. If the dual-mode user has other devices or clients that are also associated to the enterprise number, these devices will also ring as shared lines; and once the call is answered at one of the devices or clients, ringing of all other devices and clients ceases.

In scenarios where a user has been enabled for Cisco Unified Mobility, and Mobile Connect or single number reach is enabled for the user's dual-mode phone mobile number, the incoming call may also be extended to the mobility identity corresponding to the dual-mode phone number. However, this depends on whether the dual-mode device is inside the enterprise and registered to Unified CM. In situations in which the dual-mode device is inside the enterprise and registered to Unified CM, an incoming call to the user's enterprise number will not be extended by Mobile Connect to the mobility identity of the dual-mode device even if Mobile Connect is turned on for this extension. The reason an incoming call to the enterprise number is not extended to the mobility identity of a dual-mode device when it is registered to Unified CM is that the system is aware the device is inside the enterprise and available on the WLAN network. Thus, in order to reduce utilization of enterprise PSTN resources, Unified CM does not extend the call to the dual-mode device's mobile voice network interface through the PSTN. Instead, only the WLAN interface corresponding to the enterprise number is called.

For situations in which the dual-mode device is outside the enterprise and/or not registered to Unified CM, incoming calls to the enterprise number will be extended to the dual-mode device according to the configured mobility identity, assuming that the user has been enabled for Unified Mobility and that Mobile Connect for the mobility identity is turned on. For more information on integration of dual-mode devices and clients with Unified Mobility, see Interactions Between Cisco Mobile and Cisco Unified Mobility, and Interactions Between Nokia Call Connect and Cisco Unified Mobility.

In all cases, incoming calls made directly to the dual-mode device's mobile phone number will always be routed directly to the cellular radio of the dual-mode device on the mobile network, unless the provider network or device settings are such that calls are not extended to the device by the mobile network. This is considered appropriate behavior because these calls were not made to the user's enterprise number. These would be considered personal calls, and as such should not be routed through the enterprise.

Outbound Call Routing

For outbound calls from the dual-mode device, the interface used depends on the location and connectivity of the device at that particular time. If the dual-mode device is outside the enterprise and not registered to Unified CM, then calls are routed by the cellular radio interface to the mobile voice network as usual. However, when inside the enterprise and registered to Unified CM, the dual-mode device should make all calls through the WLAN radio interface to the enterprise WLAN network, thus leveraging the enterprise telephony infrastructure. In the case of some dual-mode clients, there may be a need for configuration of one or more settings in order to have the client register automatically to Unified CM when enterprise network connectivity is available. Whenever the dual-mode client is not registered to Unified CM, then outbound calls will be made using the mobile voice network rather than the enterprise network.

Dial Plan

The enterprise dial plan will determine the dialing behavior of the dual-mode device when it is inside the enterprise and registered to Unified CM. For example, if the enterprise dial plan is configured to allow abbreviated dialing to reach internal extensions, then a dual-mode device registered to Unified CM can leverage this abbreviated dialing. While it is certainly a convenience for dual-mode users to be able to dial within the enterprise using enterprise dialing habits and leveraging abbreviated dialing as well as site-based and/or PSTN steering digits for outbound calls, it is also a somewhat unnatural dialing scheme because mobile phone users dial numbers for outgoing calls on their mobile phone by using full E.164 dial strings since this is what is expected by the mobile voice network for outbound calling.

The enterprise dialing experience for an end-user is ultimately up to the enterprise policies and administrator of the enterprise telephony deployment. However, for dual-mode phones, Cisco recommends normalizing required dialing strings so that users reach a particular called destination by calling a single number, whether inside the enterprise or outside the enterprise. Because dialing on the mobile network is typically done using full E.164 (with or without a preceding '+') and mobile phone contacts are typically stored with full E.164 numbers, Cisco recommends configuring the enterprise dial plan to accommodate full E.164 or full E.164 with preceding '+' for dual-mode phones. When the dial plan is configured within Unified CM to handle this type of outbound dialing for dual-mode phones, it is possible for users to store a single set of contacts on the phone in the E.164 format and, when dialed from these contacts or manually using the full E.164 number, calls will always be routed to the appropriate destination, whether the device is inside the enterprise and registered to Unified CM or outside the enterprise and connected only to the mobile voice network. Configuring the enterprise dial plan in this manner provides the best possible end-user dialing experience so that users do not have to be aware of whether the device is registered to the Unified CM within the enterprise.

To achieve normalized dialing from dual-mode phones, whether inside or outside the enterprise, configure the dial plan within Unified CM with the following considerations in mind:

Ensure that the enterprise dial plan is capable of handling dial strings from dual-mode phones typically used on the mobile voice network. For example, the dial plan should be configured to handle the following strings, which might be dialed from a mobile phone to reach a particular phone through the mobile voice network: +1 408 555 1234, 408 555 1234.

For calls destined for other enterprise numbers, systems configured for abbreviated dialing should be capable of modifying dial strings and rerouting to enterprise extensions as appropriate. For example, assuming the enterprise dial plan is based on five-digit internal dialing, the system should be configured to handle call routing to an enterprise extension so that a call to made to +1 408 555 1234 or 408 555 1234 is modified and rerouted to 51234 if the call is made while the dual-mode device is inside the enterprise and registered to Unified CM.

Ensure that all inbound calls to the enterprise destined for dual-mode devices have the calling number and/or caller ID prefixed with appropriate digits so that missed, placed, and received call history lists are in full E.164 formats. This will allow dual-mode device users to dial from call history lists without the need for editing the dial string. Instead, users will be able to select a number from the call history list to redial, whether inside or outside the enterprise. For example, if an incoming call from inside the enterprise originates from 51234 to a dual-mode user's enterprise number and the call goes unanswered, Unified CM should be configured to manipulate the calling number so that the resulting entry within the history list of the dual-mode device shows either 408 555 1234 or + 1 408 555 1234. This number can be dialed both inside the enterprise when the dual-mode device is registered to Unified CM or outside the enterprise without the need for further manipulation.

The one exception to normalized dialing for dual-mode devices is for scenarios in which some enterprise extensions or phones are reachable only internally (that is, they have no externally reachable corresponding DID number). In these situations, non-externally reachable numbers can be dialed (manually or from contacts) using abbreviated formats. Because these numbers will never be available externally and can be dialed only from inside the enterprise, some sort of enterprise-only indication should be made when storing these numbers in the contact list. Further, incoming calls from these internal-only numbers should not have the calling number modified for call history lists because these numbers may be called only inside the enterprise. Instead, calls from these extensions should be listed in all call history lists without modification so that the abbreviated dial strings can be successfully dialed only while the device is inside the enterprise and registered to Unified CM.

Emergency Services and Dialing Considerations

Dual-mode phones do present a slight challenge when it comes to making calls to emergency service numbers such as 911, 999, and 112. Because the dual-mode device may be located inside or outside the enterprise, providing location indication of a dual-mode phone and its user in the event of an emergency must be considered. Mobile phones already receive location services from their provider networks, and these location services are always available and typically able to pinpoint locations far more precisely than enterprise wireless networks; therefore Cisco recommends relying on the mobile voice network for making emergency calls and determining device and user location. To ensure that dual-mode phones rely exclusively on the mobile voice network for emergency and location services, configure dual-mode devices within Unified CM so that they do not have access to route patterns that allow calls to emergency numbers such as 911, 999, and 112. Further, dual-mode phone users should be advised to make all emergency calls over the mobile voice network rather than the enterprise network.

Enterprise Caller ID

When dual-mode devices are inside the enterprise and registered to Unified CM, all calls made through the WLAN interface of the dual-mode phone will be routed with the user's enterprise number as caller ID. This ensures that returned calls made from call history lists at the far-end are always routed through the enterprise because the return call is to the user's enterprise number. If the dual-mode user has been enabled for Cisco Unified Mobility, and Mobile Connect is turned on for the dual-mode mobile number, return calls to the enterprise number would also be extended to the dual-mode device through the PSTN whenever it is outside the enterprise.

Mid-Call Features

When dual-mode phone clients are inside the enterprise and registered to Unified CM as telephony endpoints, they are able to invoke call processing supplementary services such as hold, resume, transfer, and conference, using call signaling methods as supported by Unified CM. Just as with any IP phone or client registered to Unified CM, these devices are able to leverage enterprise media resources such as music on hold (MoH), conference bridges, media termination points, and transcoders.

External Call Routing

When the dual-mode device is located outside the enterprise and is not registered to Unified CM, it may make and receive calls only through the mobile voice network. For this reason, Unified CM has no visibility into any calls being made or received at the dual-mode phone device while it is unregistered. The mobile number is the caller ID being sent to the network when calls are made from dual-mode phones outside the enterprise. This will likely result in unanswered calls being made directly back to the dual-mode device's mobile number instead of being routed back through the enterprise.

If the dual-mode phone is integrated with Cisco Unified Mobility, enterprise two-stage dialing services may be leveraged for making calls through the enterprise network even when the dual-mode device is outside the enterprise and not registered to Unified CM. Unified Mobility two-stage dialing is done using either Mobile Voice Access or Enterprise Feature Access and requires the user to dial an enterprise DID number and enter credentials prior to dialing the number they are calling. For more information on Unified Mobility two-stage dialing features, see Mobile Voice Access and Enterprise Feature Access.

Likewise, if the dual-mode phone is integrated with Unified Mobility, a user can also receive incoming calls to their enterprise number at the mobile number through Mobile Connect; can invoke mid-call features using DTMF key sequences including hold, resume, transfer, and conference; and can perform desk phone pickup to move an active call from the mobile phone to the enterprise desk phone.

Additional Services and Features

In addition to call processing or call control services, dual-mode phones and clients are capable of providing the additional features and services described in this section.

Call Hand-Off

One very important aspect of dual-mode phone deployments is call preservation as a user moves in and out of the enterprise and network connectivity changes from the cellular radio to the WLAN radio, and vice versa. Because dual-mode phone users are often mobile, it is important that any active call is maintained as a dual-mode user moves in or out of the enterprise. For this reason, dual-mode clients and the underlying enterprise telephony network should be capable of some form of call hand-off.

There are two types of call hand-off that should be accommodated by both the dual-mode client and the underlying IP telephony infrastructure:

Hand-out

Call hand-out refers to the movement of an active call from the WLAN interface of the dual-mode phone to the cellular interface of the dual mode phone. This requires the call to be handed out from the enterprise WLAN network to the mobile voice network through the enterprise PSTN gateway.

Hand-in

Call hand-in refers to the movement of an active call from the cellular interface of the dual mode phone to the WLAN interface of the dual mode phone. This requires the call to be handed in from the mobile voice network to the enterprise WLAN network through the enterprise PSTN gateway.

The hand-off behavior of a dual-mode phone depends on the nature of the dual-mode client and its particular capabilities. Some dual-mode clients are capable of providing only manual hand-off, while other clients are able to invoke hand-off automatically based on network conditions. In manual hand-off scenarios, the dual-mode users are responsible for engaging and completing the hand-off operation based on their location and needs. With automatic hand-off, the dual-mode client is capable of sensing strengthening or weakening of the enterprise WLAN AP signal and making a decision to hand-out in the case of weakening WLAN signal strength and engaging the hand-out operation, or making a decision to hand-in in the case of strengthening WLAN signal and engaging the hand-in operation.

Hand-off operations are critical for maximizing utilization of the enterprise IP telephony infrastructure for phone calls. These operations are also necessary for providing voice continuity and good user experience so that users do not have to hang up the original call and make another call to replace it.

Corporate Directory Access

Some dual-mode clients are capable of accessing enterprise directory services, including directory lookups and personal contact lists. While this is not a required feature for dual-mode devices and clients, it does provide productivity improvements for dual-mode phone users when they are able to access corporate directory information from their mobile phone.

Enterprise Voicemail Services

Many dual-mode clients are also capable of accessing enterprise voicemail services. Most dual-mode clients are capable of receiving enterprise message waiting indication whenever an unread voicemail is in the user's enterprise voicemail box and the dual-mode phone is attached to the enterprise WLAN network. Further, dual-mode clients can be used to retrieve enterprise voicemail messages. Typically enterprise voicemail messages are retrieved when the user dials the voicemail system number and navigates to their voicemail box after providing required credentials. However, some dual-mode clients provide the ability to retrieve voicemail messages from the voicemail box by downloading and displaying a list of all messages in the voicemail box and then by selecting individual messages to be downloaded to the dual-mode phone for listening. This is sometimes referred to as visual voicemail. Both the dual-mode phone client and the enterprise voicemail system must be capable of providing voicemail lists and allowing downloads of the messages over the network. Cisco Unity and Cisco Unity Connection both support visual voicemail and can provide voicemail lists and downloadable voicemails, provided the dual-mode client also supports this functionality.

Dual-Mode Clients: Cisco Mobile

Cisco Mobile is a dual-mode client for the Apple iPhone. Once the client application is downloaded from the Apple Application Store and installed on the iPhone using iTunes, the iPhone can associate to the enterprise WLAN network and register to Unified CM as a SIP enterprise phone.


Note The Cisco Mobile dual-mode iPhone client is supported with Unified CM 7.1(3) and later releases.


To provide registration and call control services to the Cisco Mobile dual-mode iPhone client, the device must be configured within Unified CM as a Cisco Dual-Mode for iPhone device type. Next the iPhone must be configured to access the enterprise WLAN for connectivity based on the enterprise WLAN infrastructure and security policies. Once the iPhone has been configured to access the WLAN, when the Cisco Mobile client is launched, it will register the device to Unified CM.


Note With Unified CM versions prior to 7.1(5), a Cisco options package (COP) file must be uploaded to Unified CM to enable the Cisco Dual-Mode for iPhone device type. With Unified CM 7.1(5), this device type is installed by default.


To integrate to Unified Mobility and to leverage hand-off functionality, the mobile number of the iPhone must be configured as a mobility identity associated to the Cisco Dual-Mode for iPhone device within Unified CM.

The Cisco Mobile client is supported on iPhone models 3G and 3GS running firmware version 3.0.1 or later. The iPhone WLAN interface supports 802.11b and g network connectivity.

The Cisco Mobile client not only provides dual-mode phone services but also provides directory lookup services when configured to access the enterprise Microsoft Active Directory and provides visual voicemail services when configured to access the user's voicemail box on Cisco Unity Connection.


Note When simultaneously deploying both Cisco Mobile and the Cisco Unified Mobile Communicator client for the iPhone, Cisco Mobile should not be configured to access the user's enterprise voicemail box. Instead, the Cisco Mobile client should be used for visual voicemail access because it provides more features and a superior user experience.


The Cisco Mobile client is capable of performing only manual hand-out as described in the section on Cisco Mobile Hand-Off.

For more information about the Cisco Mobile dual-mode iPhone client, additional feature details, and supported hardware and software versions, refer to the Cisco Unified Mobile Communicator documentation available at

http://cisco.com/en/US/products/ps7271/tsd_products_support_series_home.html

Cisco Mobile Hand-Off

To properly deploy Cisco Mobile dual-mode clients, it is important to understand the nature of hand-off operations within the client. The hand-off method used by the Cisco Mobile iPhone dual-mode client depends on the Transfer to Mobile Network setting on the Cisco Dual-Mode for iPhone device configuration page. The method described below is based on this configuration field being set to Use Mobility Softkey (user receives call).

The operation depicted in Figure 25-17 is of an active call on an iPhone dual-mode phone within the enterprise being moved manually from the WLAN interface to the mobile voice network or cellular interface of the device through the enterprise PSTN gateway. As shown, there is an existing call between the iPhone dual-mode device associated to the enterprise WLAN and registered to Unified CM, and a phone on the PSTN network (step 1). Because this is a manual process, the user must select the Use Mobile Network button from the in-call menu within the Cisco Mobile client, which signals to Unified CM the need to hand-out the call (step 2). Next Unified CM generates a call to the configured mobility identity number corresponding to this Cisco Mobile device through the enterprise PSTN gateway (step 3). This call to the mobility identity is made to the mobile voice network or cellular interface of the iPhone. The user can now move out of the enterprise and away from WLAN network coverage (step 4). In the meantime, the inbound call from Unified CM is received at the mobile voice network interface, and the user must answer the call manually to complete the hand-out. Once the inbound call on the cellular interface is answered, the RTP stream that was traversing the WLAN is redirected to the PSTN gateway, and the call continues uninterrupted between the Cisco Mobile dual-mode client and the original PSTN phone with the call anchored in the enterprise gateway (step 5).

Figure 25-17 Cisco Mobile Dual-Mode Hand-Out (WLAN-to-Mobile Voice Network)

An additional hand-out method is available with the Cisco Mobile dual-mode client, involving the use of the configured Unified CM Handoff Number. In order to use this method, the Transfer to Mobile Network field on the Cisco Dual-Mode for iPhone device configuration page should be set to Use Handoff DN Feature (user places call). With this method, instead of signaling hand-off to Unified CM and receiving a call from the system through the PSTN gateway to the mobile phone number of the iPhone (steps 2 and 3 in Figure 25-17), when the user invokes hand-off the Cisco Mobile client generates a call through the mobile voice network or cellular interface to the DID corresponding to the Handoff Number configured within Unified CM (in this example, + 1 408 555 1234). Once this inbound call to the hand-off number is received by the system, the RTP stream that was traversing the WLAN is redirected to the PSTN gateway, and the call continues uninterrupted between the Cisco Mobile dual-mode client and the original PSTN phone with the call anchored in the enterprise gateway.


Note Cisco Mobile does not support hand-in. In scenarios where an in-progress call is active between the iPhone mobile voice network or cellular interface and an enterprise phone (or a PSTN phone with the call anchored in the enterprise gateway), the only way to move the call to the WLAN interface of the iPhone is to hang up the call and redial once the Cisco Mobile client has associated to the enterprise WLAN and registered to Unified CM.


Interactions Between Cisco Mobile and Cisco Unified Mobility

The Cisco Mobile dual-mode client for the iPhone can be integrated with Cisco Unified Mobility to leverage Cisco Mobile Connect, mid-call DTMF features, two-stage dialing, single enterprise voicemail box, and desk phone pickup.

Integration with Unified Mobility requires the iPhone dual-mode mobile phone number to be configured within Unified CM as a mobility identity associated with the Cisco Dual-Mode for iPhone device. Once the mobile number is configured as a mobility identity within the system, Mobile Connect can be leveraged so that incoming calls to the user's enterprise number will be extended to the iPhone dual-mode device through the mobile voice network as long as the iPhone dual-mode device is outside the enterprise and not registered to Unified CM. In situations where the iPhone dual-mode device is inside the enterprise and registered to Unified CM, an inbound call to the enterprise number will not be extended to the mobile voice network interface of the device. When the iPhone dual-mode device is inside the enterprise, only the WLAN interface of the device will receive the inbound call. This prevents unnecessary consumption of enterprise PSTN gateway resources.

When outside the enterprise and not registered to Unified CM, the iPhone dual-mode device can invoke mid-call features by means of DTMF and perform desk phone pickup for any enterprise anchored call. The iPhone dual-mode device can also leverage Mobile Voice Access and Enterprise Feature Access two-stage dialing features when making outbound calls to route these calls through the enterprise and anchor them in the enterprise PSTN gateway.

In addition to configuring a mobility identity for the iPhone dual-mode device, you can configure additional mobile phone numbers or off-system phone numbers as remote destinations and associate them to the Cisco Dual Mode for iPhone device within Unified CM. When associating the mobility identity and additional remote destinations to the iPhone device, you do not have to configure a remote destination profile.

For more information about the Cisco Unified Mobility feature set as well as design and deployment considerations, see Cisco Unified Mobility.

Interactions Between Cisco Mobile and Cisco Unified Mobile Communicator

The Cisco Mobile iPhone dual-mode client can be used in parallel with the Cisco Unified Mobile Communicator client for iPhone. When both clients are deployed, not only is the iPhone device able to leverage the enterprise IP telephony infrastructure for making and receiving calls inside the enterprise, but it is also able to leverage Unified Mobile Communicator features such as directory lookups, desk phone call log integration, presence, visual voicemail and text messaging.

To deploy both the Cisco Mobile iPhone dual-mode client and the Cisco Mobile client that runs in conjunction with the enterprise Cisco Unified Mobility Advantage server, configure only the Cisco Dual-Mode for iPhone device within Unified CM. A Cisco Unified Mobile Communicator device should not be configured for the iPhone device within Unified CM because configured remote destination and mobility identity numbers must all be unique within the system. The mobile phone number of the iPhone can be configured and associated to only a single device within Unified CM, and this device should be the Cisco Dual-Mode for iPhone device. By configuring the mobile phone number of the iPhone as a mobility identity and associating this number to the iPhone dual-mode device within Unified CM, you enable Unified Mobility integration as well as hand-out capabilities for the Cisco Mobile dual-mode client.

With Unified CM 7.1(5), in order to integrate the Cisco Mobile dual-mode client with the Cisco Mobile client that runs in conjunction with the Cisco Unified Mobility Advantage server, check the Enable Cisco Unified Mobile Communicator checkbox on the Cisco Dual-Mode for iPhone device configuration page within Unified CM. When this box is check, the dual-mode device type within Unified CM provides support for the dual-mode client as well as the Cisco Mobile client that runs in conjunction with the Cisco Unified Mobility Advantage server, including the dial-via-office feature.

With Unified CM 7.1(3) there is no ability to support both Cisco Mobile clients and the dial-via-office feature because the Enable Cisco Unified Mobile Communicator checkbox is not available. With Unified CM 7.1(3), the Cisco Mobile client that runs in conjunction with the enterprise Unified Mobility Advantage server can still be run on the iPhone to provide all of the Cisco Unified Mobile Communicator features and functions except dial-via-office.

In situations where both the Cisco Mobile iPhone dual-mode client and the Cisco Unified Mobile Communicator iPhone client are deployed on the same handset, Cisco recommends using the Cisco Unified Mobile Communicator client for enterprise directory lookups and visual voicemail. While the Cisco Mobile iPhone dual-mode client provides similar functionality, the Cisco Unified Mobile Communicator provides a better user experience and a richer set of features.

For Unified CM 7.1(3) deployments, dial-via-office functionality is not supported in conjunction with the Cisco Mobile dual-mode iPhone client; therefore, when the device is outside the enterprise, users should leverage Unified Mobility two-stage dialing functionality to make calls through the enterprise.

For more information about the Cisco Unified Mobile Communicator solution, feature set, and design and deployment considerations, see Cisco Unified Mobile Communicator.

Dual-Mode Clients: Nokia Call Connect

Nokia Call Connect is a dual-mode client for Nokia mobile smart phones. Once installed on the Nokia device, the client can associate to the enterprise WLAN network and register to Unified CM as a Skinny Client Control Protocol (SCCP) enterprise phone.

To provide registration and call control services to Nokia dual-mode devices, Unified CM must support the Nokia S60 device type, which is available only after loading the Nokia-provided Cisco options package (COP) file onto Unified CM.

Once the dual-mode device has been configured within Unified CM, it is necessary to load the Nokia Call Connect client onto the Nokia device. This can be done using a computer with a USB, Bluetooth, or infrared port running the Nokia PC Suite. After the Nokia Call Connect Symbian installation system (SIS) file has been loaded on the Nokia device, the device must be configured to access the enterprise WLAN for connectivity based on the enterprise WLAN infrastructure and security policies. Once the handset has been configured to access the WLAN, when the Nokia Call Connect client is launched, it will register the device to Unified CM. To integrate the Nokia dual-mode device with Unified Mobility so the user can leverage features such as Mobile Connect, configure the Nokia mobile phone number as a mobility identity and associate it to the Nokia S60 device within Unified CM.


Note Cisco recommends configuring the Nokia Call Connect client SCCP registration setting to Always On to ensure that, whenever the Nokia device is associated to the enterprise WLAN network, it will attempt to register to Unified CM. Cisco also recommends setting the Nokia dual-mode phone's preferred or default call type setting to Internet Call to ensure that, when the Nokia Call Connect client is registered to Unified CM, the device will always attempt to route outbound calls through the WLAN interface of the dual-mode phone. These recommended settings ensure that the Nokia dual-mode phone maximizes its use of the enterprise IP telephony infrastructure for making and receiving business calls.


The Nokia Call Connect 2.0 client is supported on Nokia S60 3.2 handsets, including the Nokia E52, E55, E72, and E75. Nokia S60 3.1 handsets, including the E51, E61i, E63, E66, E71, and E90, are also supported but might not support advanced features such as automatic hand-off. Nokia mobile phone WLAN interfaces supports 802.11b and g network connectivity.

The Nokia Call Connect client not only provides dual-mode phone services but also provides directory lookup services when configured to access the Unified CM directory as well as enterprise-based XML phones services like those supported on Cisco IP desk phones.

Nokia Call Connect 2.0 and later clients are capable of performing automatic hand-out and hand-in as outlined in the sections below.

For more information about the Nokia Call Connect dual-mode client, supported handsets, and software versions, and to access the latest client and COP file, refer to:

http://www.cisco.com/en/US/products/ps10589/tsd_products_support_series_home.html

Nokia Call Connect Dual-Mode Hand-off

To properly deploy Nokia Call Connect dual-mode clients, it is necessary to understand the nature of the hand-off operation within the Nokia dual-mode client.

In the following examples, the hand-off number is +1 408 555 1234 (this is the full E.164 hand-off number). The Cellular Handover Number under the Nokia Call Connect Voice Call Continuity (VCC) settings is configured with this number.

All inbound calls are stripped to four digits by the upstream gateway, so the Handoff Number configured within Unified CM is 1234. The VoIP Handover Number is configured as 1234 under the Nokia Call Connect VCC settings.

Hand-Out (WLAN to Cellular)

Figure 25-18 shows a hand-out operation in which an active call on a Nokia dual-mode phone within the enterprise is moved from the WLAN interface to the mobile voice network or cellular interface of the device through the enterprise PSTN gateway. As shown, there is an existing call between the Nokia dual-mode device associated to the enterprise WLAN and registered to Unified CM, and a phone on the PSTN network (step 1). The Nokia dual-mode user begins to leave the enterprise (step 2), and as the WLAN signal strength drops below -78 dBm (default value for the WLAN HO threshold setting in VCC) for a period of 1,000,000 microseconds (1 second, default value for the WLAN HO hysteresis setting in VCC), a silent background call is opened to +1 408 555 1234 (the configured Cellular Handover Number in VCC and corresponding to the Handoff Number configured in Unified CM) over the mobile voice network and PSTN into the enterprise PSTN gateway and is delivered to Unified CM (step 3). Once received, the calling number is checked against all configured mobility identities on the system, and assuming a match is found, the RTP stream that was traversing the WLAN is now redirected to the PSTN gateway and the call is continued uninterrupted between the dual-mode device and the original PSTN phone with the call anchored in the enterprise gateway (step 4).

Figure 25-18 Nokia Call Connect Dual-Mode Hand-Out (WLAN-to-Mobile Voice Network)

The Nokia Call Connect dual-mode client also supports manual hand-out using the Switch to Cellular or Handover to GSM in-call menu options. The availability and behavior of these manual hand-out methods depends on the device type and firmware version. For devices running firmware version 3.1 and earlier, the Switch to Cellular menu option when selected performs a blind transfer of the active call to the mobile voice network interface of the device through the enterprise PSTN gateway. For devices running firmware version 3.2 and later, the Handover to GSM menu option when selected performs a manual handoff using the Unified CM Handoff Number as shown in step 3 of Figure 25-18 without relying on WLAN handover thresholds and hysteresis VCC settings.

Hand-In (Cellular to WLAN)

Figure 25-19 depicts a hand-in operation in which an active call on a Nokia dual-mode phone outside the enterprise is moved from the mobile voice network interface to the WLAN interface of the device through the enterprise PSTN gateway. As shown, there is an existing call between the Nokia dual-mode device on the mobile voice network and a phone on the PSTN network (step 1). The Nokia dual-mode user moves into the enterprise (step 2), and the device associates in the background to the WLAN infrastructure and registers to Unified CM. After registration, the device will wait for the amount of time specified by the WLAN HO hysteresis high setting in VCC (60 seconds by default), and then a silent background call is opened to 1234 (the configured VoIP Handover Number in VCC, which corresponds to the Unified CM Handoff Number configured in Unified CM) and delivered to Unified CM (step 3). Once received, the enterprise calling number is checked against configured Nokia S60 dual-mode phones on the system, and assuming a match is found, the call that was traversing the mobile voice network/PSTN and the enterprise PSTN gateway is now redirected to the WLAN network, and the call is continued uninterrupted between the dual-mode device and the original PSTN phone (step 4).

Figure 25-19 Nokia Call Connect Dual-Mode Hand-In (Mobile Voice Network-to-WLAN)

For more information about Nokia Call Connect VCC settings, refer to the Nokia Call Connect for Cisco User's Guide, available at

http://europe.nokia.com/support/download-software/nokia-call-connect-for-cisco

Interactions Between Nokia Call Connect and Cisco Unified Mobility

The Nokia Call Connect dual-mode client can be integrated with Cisco Unified Mobility to leverage Cisco Mobile Connect, mid-call DTMF features, two-stage dialing, single enterprise voicemail box, and desk phone pickup.

Integration with Unified Mobility requires the Nokia dual-mode phone mobile number to be configured within Unified CM as a mobility identity associated with the Nokia S60 device. Once the mobile number is configured as a mobility identity within the system, Mobile Connect can be leveraged so that incoming calls to the user's enterprise number will be extended to the Nokia dual-mode device through the mobile voice network as long as the Nokia dual-mode device is outside the enterprise and is not registered to Unified CM. In situations where the Nokia dual-mode device is inside the enterprise and registered to Unified CM, an inbound call to the enterprise number will not be extended to the mobile voice network interface of the device. When the Nokia dual-mode device inside the enterprise, only the WLAN interface of the device will receive the inbound call. This prevents unnecessary consumption of enterprise PSTN gateway resources.

When outside the enterprise and not registered to Unified CM, the Nokia dual-mode device can invoke mid-call features by means of DTMF and can perform desk phone pickup for any enterprise anchored call. The Nokia dual-mode device can also leverage Mobile Voice Access and Enterprise Feature Access two-stage dialing features when making outbound calls, to route these calls through the enterprise and anchor them in the enterprise PSTN gateway.

In addition to configuring a mobility identity for the Nokia dual-mode device, you can configure additional mobile phone numbers or off-system phone numbers as remote destinations and associate them to the Nokia S60 device within Unified CM. When associating the mobility identity and additional remote destinations to the Nokia device, you do not have to configure a remote destination profile.

For more information about the Unified Mobility feature set as well as design and deployment considerations, see Cisco Unified Mobility.

Interactions Between Nokia Call Connect and Cisco Unified Mobile Communicator

The Nokia Call Connect dual-mode client can be used in parallel with the Cisco Unified Mobile Communicator client for Nokia. When both clients are deployed, not only is the Nokia device able to leverage the enterprise IP telephony infrastructure for making and receiving calls inside the enterprise, but it is also able to leverage Unified Mobile Communicator features such as directory lookups, desk phone call log integration, presence, visual voicemail, text messaging, and dial-via-office.

To integrate Nokia Call Connect dual-mode client with Unified Mobile Communicator, check the Enable Cisco Unified Mobile Communicator checkbox on the Nokia S60 device configuration page within Unified CM.

Once configured within Unified CM, both clients can be run on the Nokia dual-mode device; however, it is important to understand the implications for the dial-via-office feature. While all other features and functions within the two clients will operate normally, the dial-via-office interaction behaves somewhat differently when the Nokia Call Connect client is installed on the same device. The dial-via-office feature within Unified Mobile Communicator will engage only for calls routed through the mobile voice network or cellular interface. For this reason, calls made by the Nokia Call Connect client through the WLAN interface will not engage dial-via-office, which is preferable behavior because the call is already being made over the enterprise IP telephony infrastructure.

However, for calls made from the mobile voice or cellular interface, the dial-via-office feature may be engaged depending on the dial-via-office settings within the Unified Mobile Communicator client and/or the dial-via-office settings on the Cisco Unified Mobility Advantage server. If the administrator of the Unified Mobility Advantage server forces dial-via-office for users, then the Unified Mobile Communicator client will attempt to invoke dial-via-office for every call made out the cellular interface of the device. In these situations, the user should set the configuration parameter Allow dial via office for to Call from this app on the Unified Mobile Communicator client so that only calls made directly from the Unified Mobile Communicator client will attempt to invoke dial-via-office. By configuring the client this way, the user can ensure that dial-via-office will not be engaged when calls are made through the cellular interface outside of the Unified Mobile Communicator client. For example, it would be undesirable to engage dial-via-office on the Nokia device when the Nokia Call Connect client is attempting to hand-out a call from the enterprise WLAN to the mobile voice network. During hand-out, the cellular interface of the Nokia dual-mode device calls the Unified CM Handoff Number, and having dial-via-office engage would cause additional unnecessary call legs to be created and might in fact result in a failure to hand-off the original call.

Likewise, if the administrator has allowed individual Unified Mobile Communicator users to configure their own dial-via-office settings within the client, then the users can set the client to prompt them to choose between making the call directly and using dial-via-office each time a call is attempted through the cellular interface. By setting the Unified Mobile Communicator When dialing setting to Let me choose and the Allow dial via office for setting to Call from this app, the user has maximum control over when dial-via-office will be used. In all cases, users should use dial-via-office only when the Nokia dual-mode device is outside the enterprise and not registered to Unified CM.

For more information about the Cisco Unified Mobile Communicator solution, feature set, and design and deployment considerations, see Cisco Unified Mobile Communicator.

High Availability for Dual-Mode Phones

Although dual-mode phones by their nature are highly available with regard to network connectivity (when the enterprise WLAN network is unavailable, the mobile voice network can be used for voice and data services), enterprise WLAN and IP telephony infrastructure high availability must still be considered.

First, the enterprise WLAN must be deployed in a manner that provides redundant WLAN access. For example, APs and other WLAN infrastructure components should be deployed so that the failure of a wireless AP does not impact network connectivity for the dual-mode device. Likewise, WLAN management and security infrastructure must be deployed in a highly redundant fashion so that dual-mode devices are always able to connect securely to the network.

Next, Unified CM call processing and registration service high availability must be considered. Just as with other devices within the enterprise that leverage Unified CM for call processing services, dual-mode phones must register with Unified CM. Given the redundant nature of the Unified CM cluster architecture, which provides primary and backup call processing and device registration services, dual-mode device registration as well as call routing are still available even in scenarios in which a Unified CM server node fails.

Similar considerations apply to PSTN access. Just as with any IP telephony deployment, multiple PSTN gateways and call routing paths should be deployed to ensure highly available access to the PSTN. This is not unique to dual-mode phone deployments, but is an important consideration none the less.

Capacity Planning for Dual-Mode Phones

Capacity planning considerations for dual-mode phones are the same as for other IP telephony endpoints or devices that rely on the IP telephony infrastructure and applications for registration, call processing, and PSTN access services.

When deploying dual-mode phones within the enterprise, it is important to consider the registration load on Unified CM as well as the Unified Mobility limits. A single Unified CM server is capable of handling a maximum of 7,500 device configurations and registrations. When deploying dual-mode phones, you must consider the per-server maximum device support, and you might have to deploy additional call processing subscriber nodes to handle the added load.

In addition, as discussed in Cisco Unified Mobility Performance and Capacity, the maximum number of remote destinations and mobility identities within a single Unified CM cluster is 15,000. Because most dual-mode devices will likely be integrated with Unified Mobility to take advantage of features such as Mobile Connect, desk phone pickup, and two-stage dialing, the mobile phone number of each of these dual-mode devices must be configured as a mobility identity within the Unified CM cluster. This is necessary to facilitate integration to Unified Mobility as well as to facilitate hand-off in some cases. Therefore, when integrating dual-mode phones with Unified Mobility, it is important to consider the overall remote destination and mobility identity capacity of the Unified CM cluster to ensure sufficient capacity exists. If additional users or devices are already integrated to Unified Mobility within the system, they can limit the amount of remaining remote destination and mobility identity capacity available for dual-mode devices.

Overall call processing capacity of the Unified CM system and PSTN gateway capacity must also be considered when deploying dual-mode phones. Beyond handling the actual dual-mode device configuration and registration, the system must also have sufficient capacity to handle the added BHCA impact of these new dual-mode phones and users. Likewise, it is critical to ensure sufficient PSTN gateway capacity is available to accommodate dual-mode devices. This is especially the case for dual-mode devices that are integrated to Unified Mobility because the types of users that would have dual-mode devices are typically highly mobile. Highly mobile users typically generate more enterprise PSTN gateway load from mobility features such as Mobile Connect, where an incoming call to a mobile user's enterprise number generates one or more calls to the PSTN, or from two-stage dialing, where a user makes a call through the enterprise by leveraging the enterprise PSTN gateway.

The above considerations are certainly not unique to dual-mode phones. They apply to all situations in which devices and users are added to Unified CM, resulting in additional load to the overall Unified Communications System.

The Cisco Unified Communications Sizing Tool is available to Cisco partners and employees to help calculate the capacity of the Cisco Unified Communications System, including Unified CM. The sizing tool provides input for the number of dual-mode phone devices as part of the overall system capacity, and it appropriately sizes the system to accommodate the number of dual-mode devices and their impact to the overall size of the system based on their registration, call processing or BHCA, and gateway utilization load. Contact your Cisco partner or Cisco Systems Engineer (SE) for assistance with sizing of your system.

For Cisco partners and employees, the Cisco Unified Communications Sizing Tool is available at http://tools.cisco.com/cucst.

Design Considerations for Dual-Mode Phones

Observe the following design recommendations when deploying dual-mode phones and clients:

Dual-mode phones must be capable of dual transfer mode (DTM) in order to be connected simultaneously to both the mobile voice and data network and the WLAN network so that the device is reachable and able to make and receive calls on both the cellular radio and WLAN interface of the device. In some cases, proper dual-mode client operation might not be possible if mobile voice and data networks do not support dual-connected devices.

APs should be deployed with cell overlap of 20% for 2.4 GHz (802.11b/g) deployments. Channel overlap for 5 GHz (802.11a) deployments should overlap between 15% and 20%. This overlap ensures that a dual-mode device can successfully roam from one AP to the next as the device moves around within a location, while still maintaining voice and data network connectivity.

APs should be deployed with cell power level boundaries (or channel cell radius) of -67 dBm in order to minimize packet loss. Furthermore, the same-channel cell boundary separation should be approximately 19 dBm. A same-channel cell separation of 19 dBm is critical for ensuring that APs or clients do not cause co-channel interference to other devices associated to the same channel, which would likely result in poor voice quality.

Cisco recommends using only an enterprise class voice-optimized WLAN network for connecting dual-mode phones and clients. While most dual-mode phones and clients are capable of attaching to public or private WLAN access points or hotspots for connecting back to the enterprise through the Internet for call control and other Unified Communications services, Cisco cannot guarantee voice quality for these types of connections.

The Unified Mobility Mobile Connect feature will not extend incoming calls to the dual-mode device's configured mobility identity if the dual-mode device is inside the enterprise and registered to Unified CM. This is by design in order to reduce utilization of enterprise PSTN resources. Because the dual-mode device registers to Unified CM, the system knows whether the device is reachable inside the enterprise; and if it is, there is no reason to extend the call to the PSTN in order to ring the dual-mode device's mobile voice network interface. Only when the dual-mode device is unregistered will Mobile Connect extend incoming calls to the user's enterprise number out to the mobility identity number on the PSTN.

When deploying dual-mode phones, Cisco recommends normalizing required dialing strings so that users reach a particular called destination by calling a single number, whether inside or outside the enterprise. Because dialing on the mobile network is typically done using full E.164 (with or without a preceding '+') and mobile phone contacts are typically stored with full E.164 numbers, Cisco recommends configuring the enterprise dial plan to accommodate full E.164 or full E.164 with preceding '+' for dual-mode phones. By configuring the enterprise dial plan in this manner, you can provide the best possible end-user dialing experience so that users do not have to be aware of whether the device is registered to the Unified CM within the enterprise.

Cisco recommends that dual-mode phone users rely on the mobile voice network for making emergency calls and determining device and user location. This is because mobile provider networks typically provide much more reliable location indication than enterprise WLAN networks. To ensure that dual-mode phones rely exclusively on the mobile voice network for emergency and location services, configure dual-mode devices within Unified CM so that they do not have access to route patterns that allow calls to emergency numbers such 911, 999, and 112. Dual-mode phone users should be advised to make all emergency calls over the mobile voice network rather than the enterprise network.

In deployments where both the Cisco Mobile iPhone dual-mode client and the Cisco Unified Mobile Communicator iPhone client are deployed on the same handset, Cisco recommends the following:

Configure the dual-mode phone within Unified CM as a Cisco Dual-Mode for iPhone client, and configure the mobile number of the iPhone as an associated mobility identity. Do not configure a corresponding Cisco Unified Mobile Communicator client device within Unified CM because the mobility identity must be unique within the system.

Dial-via-office should be enabled and utilized with the Cisco Mobile dual-mode client only when running Unified CM 7.1(5) and the Enable Cisco Unified Mobile Communicator box has been checked. When running Unified CM 7.1(3), dial-via-office and the dual-mode client are mutually exclusive.

Use the Cisco Unified Mobile Communicator client for enterprise directory lookups and visual voicemail. While the Cisco Mobile iPhone dual-mode client provides similar functionality, the Cisco Unified Mobile Communicator client provides a better user experience and a richer set of features.

In situations where both the Nokia Call Connect dual-mode client and the Cisco Unified Mobile Communicator Nokia client are deployed on the same handset, avoid using dial-via-office whenever the dual-mode device is inside the enterprise and registered to Unified CM. Cisco recommends the following:

When dual-mode phones are deployed in the enterprise, the administrator of the Cisco Unified Mobility Advantage Server should not force dial-via-office by using the Dial Via Office Policy setting. Instead, the administrator should allow users to choose whether they use dial-via-office.

If dial-via-office is forced for Cisco Unified Mobile Communicator by the administrator of the Cisco Unified Mobility Advantage server, the user should configure the Allow dial via office for setting to Call from this app within the Unified Mobile Communicator client so that only calls made directly from within the Unified Mobile Communicator client will attempt to invoke dial-via-office. By configuring the client this way, the user can ensure that dial-via-office will not be engaged unexpectedly. If the Unified Mobile Communicator client is not in the foreground, then the user can be sure that dial-via-office will not be invoked.

If dial-via-office is not forced by the Unified Mobility Advantage administrator, the Unified Mobile Communicator user should set the When dialing setting to Let me choose and the Allow dial via office for setting to Call from this app. By configuring the settings in this manner, the user has maximum control over when dial-via-office will be used. In all cases, users should use dial-via-office only when the Nokia dual-mode device is outside the enterprise and not registered to Unified CM.

Cisco recommends the following Nokia Call Connect client configuration settings in order to maximize the dual-mode device's use of the enterprise IP telephony infrastructure for making and receiving business calls:

Configure the Nokia Call Connect client SCCP registration setting to Always On to ensure that, whenever the Nokia device is associated to the enterprise WLAN network, it will attempt to register to Unified CM.

Configure the Nokia dual-mode phone's preferred or default call type setting to Internet Call to ensure that, when the Nokia Call Connect client is registered to Unified CM, the device will always attempt to route outbound calls through the WLAN interface of the dual-mode phone.