-
Cisco Unified Communications SRND Based on Cisco Unified Communications Manager 7.x
-
Preface
-
Introduction
-
Unified Communications Deployment Models
-
Network Infrastructure
-
Gateways
-
Cisco Unified CM Trunks
-
Media Resources
-
Music on Hold
-
Call Processing
-
Call Admission Control
-
Dial Plan
-
Emergency Services
-
Third-Party Voicemail Design
-
Cisco Voice Messaging
-
Cisco Unified MeetingPlace
-
Cisco Unified MeetingPlace Express
-
IP Video Telephony
-
LDAP Directory Integration
-
IP Telephony Migration Options
-
Voice Security
-
Unified Communications Endpoints
-
Device Mobility
-
Cisco Unified Presence
-
Cisco Collaboration Clients and Applications
-
Cisco Unified CM Applications
-
Cisco Mobility Applications
-
Network Management
-
Cisco Unified Communications Manager Business Edition
-
Recommended Hardware and Software Combinations
-
Glossary
-
Index
-
Table Of Contents
Unified CM Service Parameters for Mobile Connect
Remote Destination Phone Pickup
Single Enterprise Voicemail Box
Enabling and Disabling Mobile Connect
Access Lists for Allowing or Blocking Mobile Connect Calls
Mobile Voice Access and Enterprise Feature Access
Mobile Voice Access and Enterprise Feature Access Phone Support
Unified CM Services and Service Parameters for Mobile Voice Access and Enterprise Feature Access
Unified CM Service for Mobile Voice Access
Unified CM Service Parameters for Mobile Voice Access and Enterprise Feature Access
Mobile Voice Access IVR VoiceXML Gateway URL
Mobile Voice Access Functionality
Mobile Voice Access Using Hairpinning
Enterprise Feature Access with Two-Stage Dialing Functionality
Desk and Remote Destination Phone Pickup
Enabling and Disabling Mobile Connect
Mobile Voice Access and Enterprise Feature Access Number Blocking
Remote Destination Configuration and Caller ID Matching
Mobile Voice Access and Enterprise Feature Access Architecture
Mobile Voice Access and Enterprise Feature Access Redundancy
Dial Plan Considerations for Cisco Unified Mobility
Remote Destination Profile Configuration
Automatic Caller ID Matching and Enterprise Call Anchoring
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
Cisco Unity and Unity Connection Voice Mail
Cisco Unified Mobile Communicator Redundancy
Cisco Unified Mobile Communicator Performance and Capacity
Design Recommendations for Deploying Cisco Unified Mobile Communicator
Cisco Mobility Applications
Last revised on: September 18, 2009
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 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 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 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, and they provide the enterprise with an easy way to track phone calls made by users via a uniform and centrally located set of call detail records. Furthermore, these features provide the ability to mask a user's mobile phone number when sending 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 is utilized for voice services.
Enterprise applications and features that can be integrated with the Cisco Unified Mobile Communicator application include:
•
•
•
•
•
•
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, Mobile Voice Access, and Single Enterprise Voicemail Box.
The various applications and features discussed in this chapter apply to all Cisco Unified Communications deployment models unless otherwise noted.
This chapter begins with a discussion of Unified Mobility features, functionality, and design and deployment considerations. Given the various benefits of Unified Mobility and the fact that Cisco Unified Mobile Communicator can be integrated to take advantage of the features provided, this discussion paves the way for examination of Cisco Unified Mobile Communicator. This examination includes a discussion of architecture, functionality, and design and deployment implications for the following mobility applications and features:
•
•
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
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 Mobility Advantage scalability
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
Directed Call Park mid-call feature
Enabling and disabling Mobile Connect
Maintaining and troubleshooting Unified Mobility
Mobile Voice Access support for SIP VoiceXML gateways
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
Support for Cisco Unified Mobility Advantage on the Cisco MCS-7825 Media Convergence Server
Support for Redirected Dialed Number Identification Service (RDNIS) or SIP Diversion Header for Mobile Connect calls
Cisco Unified Mobility
Cisco Unified Mobility refers to the native mobility functionality within the Cisco Unified Communications Manager (Unified CM) and includes the Mobile Connect, Mobile Voice Access, and Enterprise Feature Access features.
Unified Mobility functionality depends on the appropriate configuration of Unified CM. For this reason, it is important to understand the nature of this configuration as well as the logical components.
Figure 25-1 illustrates the configuration requirements for Unified Mobility. First, as for all users, a mobility user's enterprise phone is configured with appropriate line-level settings such as directory number, partition, and calling search space. In addition, the device-level settings of the enterprise phone include parameters such as device pool, common device configuration, calling search space, media resource group list, and user and network hold audio sources. All of these line and device settings on the user's enterprise phone affect the call routing and music on hold (MoH) behavior for incoming and outgoing calls.
Next, a remote destination profile must be configured for each mobility user in order for them to take advantage of Unified Mobility features. The remote destination profile is configured at the line level with the same directory number, partition, and calling search space as the user's enterprise phone. This results in a shared line between the remote destination profile and the enterprise phone. The remote destination profile configuration includes device pool, calling search space, rerouting calling search space, and user and network hold audio source parameters. The remote destination profile should be thought of as a virtual phone whose configuration mirrors the user's line-level enterprise phone settings, but whose profile-level configuration combined with the line-level settings determines the call routing and MoH behavior that the user's remote destination phone will inherit. The user's enterprise directory number, which is shared between the remote destination profile and the enterprise phone, allows calls to that number to be extended to the user's remote destination.
Figure 25-1 Cisco Unified Mobility Configuration Architecture
As further shown in Figure 25-1, a mobility user can have one or more remote destinations configured and associated with their remote destination profile. A remote destination represents a single PSTN phone number where a user can be reached. A user can have up to 10 remote destinations defined. Call routing timers can be configured for each remote destination to adjust the amount of time a call will be extended to a particular remote phone, as well as the amount of time to wait before extending the call and the amount of time that must pass before a call can be answered at the remote phone. Mobility users can also configure filters for each remote destination to allow or deny calls from certain phone numbers to be extended to that remote phone.
Mobile Connect
The Mobile Connect feature allows an incoming call to an enterprise user to be offered to the user's IP desk phone as well as up to 10 configurable remote destinations. Typically a user's remote destination is their mobile or cellular telephone. Once the call is offered to both the desktop and remote destination phone(s), the user can answer at any of those phones. Upon answering the call on one of the remote destination phones or on the IP desk phone, the user has the option to hand off or pick up the call on the other phone.
Mobile Connect Phone Support
Mobile Connect is supported on any of the following phone models:
•
•
•
•
•
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:
•
•
•
•
•
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
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:
•
This parameter indicates the feature access code used for the hold mid-call feature. This code is either manually keyed by the user or programmed as a key on a Smart Phone. This code is sent as a DTMF sequence from the remote destination phone back to the enterprise gateway and is relayed to Unified CM.
•
This parameter indicates the feature access code used for the exclusive hold mid-call feature. When exclusive hold is invoked at the remote destination phone, the call cannot be picked up or resumed at the user's desk phone. This code is either manually keyed by the user or programmed as a key on a Smart Phone. This code is sent as a DTMF sequence from the remote destination phone back to the enterprise gateway and is relayed to Unified CM.
•
This parameter indicates the feature access code used for the resume mid-call feature. This code is either manually keyed by the user or programmed as a key on a Smart Phone. This code is sent as a DTMF sequence from the remote destination phone back to the enterprise gateway and is relayed to Unified CM.
•
This parameter indicates the feature access code used for the transfer mid-call feature. This code is either manually keyed by the user or programmed as a key on a Smart Phone. This code is sent as a DTMF sequence from the remote destination phone back to the enterprise gateway and is relayed to Unified CM.
•
This parameter indicates the feature access code used for the conference mid-call feature. This code is either manually keyed by the user or programmed as a key on a Smart Phone. This code is sent as a DTMF sequence from the remote destination phone back to the enterprise gateway and is relayed to Unified CM.
•
This parameter determines the nature of inbound call routing for calls coming into the enterprise from configured remote destination phones. By default, the inbound calling search space (CSS) of the PSTN gateway or trunk on which the call is coming in will be used to route the inbound call. If the value of this parameter is set to Remote Destination Profile + Line Calling Search Space, the Remote Destination Profile CSS (in combination with the line CSS) will be used to route the inbound call. This parameter has no affect on inbound call routing from non-remote destination phones.
•
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 DS0s or analog ports. This utilization must be considered when deploying the Mobile Connect feature.
Note
Desk Phone Pickup
As illustrated in Figure 25-3, once a user answers a Mobile Connect call at the remote destination device (step 1: in this case, 408 555-7890), at any point the user can hang up the call at the remote destination and pick it up again at their desk phone by simply pressing the Resume softkey on the desk phone (step 2: at DN 408 555-1234 in this case). The call continues uninterrupted between the original caller at Phone A and the desk phone (step 3).
Figure 25-3 Desk Phone Pickup
Desk phone pickup can be performed whenever an enterprise anchored call is in progress at a configured remote destination phone and that phone is hung up.
Note
The option to pick up or resume the call at the desk phone is available for a certain amount of time. For this reason, it is good practice for the Mobile Connect user to ensure that the calling phone hangs up before the remote destination phone is hung up. This ensures that the call cannot be resumed at the desk phone by someone else. By default, the call remains available for pickup at the desk phone for 10 seconds after the remote destination phone hangs up; however, this time is configurable and can be set from 0 and 30000 milliseconds on a per-user basis by changing the Maximum Wait Time for Desk Pickup parameter under the End User configuration page. Desk phone pickup can also be performed after invoking the mid-call hold feature at the remote destination phone. However, in these cases, the Maximum Wait Time for Desk Pickup parameter setting has no effect on the amount of time the call will be available for pickup. A call placed on mid-call hold will remain on hold and be available for desk phone pickup until manually resumed at either the remote or desktop phone.
Remote Destination Phone Pickup
Figure 25-4 illustrates Mobile Connect remote destination phone pickup functionality. Assuming Phone A calls Mobile Connect user's enterprise DN 408 555-1234 and the call is answered at the user's desk phone and is in progress (step 1), the user must push the Mobility softkey. Assuming the Mobile Connect feature is enabled for this phone and remote pickup is available, the user presses the Select softkey (step 2). A call is generated to the user's remote destination phone (in this case, 408 555-7890), and the remote phone begins to ring. Once the call is answered at the remote phone, the call continues uninterrupted between Phone A and the Mobile Connect user's remote phone with number 408 555-7890 (step 3).
Figure 25-4 Remote Destination Phone Pickup
When a Mobile Connect user has multiple remote destinations configured, each remote destination will ring when the Pickup softkey is pressed, and the user can answer the desired phone.
Note
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
The typical method for generating mid-call DTMF digit sequences is via a Smart Client on the user's remote destination phone. The Smart Client provides an easy and automated method for assigning these DTMF digit sequences to a set of softkeys on the remote destination phone. A Smart Phone user can then easily invoke the mid-call features by pressing the appropriate softkey.
Note
Table 25-2 lists the Smart Phone mid-call feature key sequences and includes not only the key presses required by the user to invoke each feature, but also the Smart Phone behavior.
Note
While the Smart Phone method of using mid-call features is the preferred and easiest method to use, users without Smart Clients on their remote destination phones can still take advantage of mid-call features by manually keying the feature access codes and entering the appropriate key sequences. Table 25-3 indicates the required key sequences for invoking mid-call features manually.
Note
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:
•
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.
•
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
Note
Enabling and Disabling Mobile Connect
The Mobile Connect feature can be enabled or disabled by using one of the following methods:
•
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.
•
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.
•
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.
•
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.
2.
3.
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:
•
•
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.
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
Enterprise Feature Access functionality includes the previously discussed mid-call transfer and conference features as well as two-stage dialing functionality. Two-stage dialing works the same way as Mobile Voice Access, but without the IVR prompts. The system-configured Enterprise Feature Access DID is answered by Unified CM. The user then uses the phone keypad or Smart Phone softkeys to input authentication and the number to be dialed. These inputs are received without prompts.
With both the Mobile Voice Access and Enterprise Feature Access two-stage dialing features, once the call to the input number is connected, users can invoke mid-call features or pick up the call on their desk phones just as with a Mobile Connect calls. This is possible because the call is anchored at the enterprise gateway.
Mobile Voice Access and Enterprise Feature Access Phone Support
Mobile Voice Access and Enterprise Feature Access are supported for all incoming PSTN devices capable of sending DTMF digits. Cisco Unified IP Phone support for these features is the same as for Mobile Connect (see Mobile Connect Phone Support). Although an IP phone is not required to use Mobile Voice Access or Enterprise Feature Access, a user wishing to pick up an in-progress call made by one of these features on a desk phone must have access to one of the phone models supported by Mobile Connect.
Unified CM Services and Service Parameters for Mobile Voice Access and Enterprise Feature Access
For the Mobile Voice Access application to function properly, you must enable certain services on Unified CM and configure certain parameters on Cisco Unified Mobility. This section lists those required services and parameters.
Unified CM Service for Mobile Voice Access
The Mobile Voice Access feature relies on the Cisco Unified Mobile Voice Access Service, which must be activated manually from the Unified CM Serviceability configuration page. This service can be activated on the publisher node only.
Unified CM Service Parameters for Mobile Voice Access and Enterprise Feature Access
The following items represent a partial list of Unified CM service parameters related to Mobile Voice Access and Enterprise Feature Access two-stage dialing functionality:
•
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.
•
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.
•
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.
•
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.
•
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
In the meantime, Unified CM has forwarded IVR prompts to the VoiceXML gateway, the gateway has played these prompts to the user, and the gateway has collected user input including the numeric ID and PIN number of the user. This information is forwarded to Unified CM for authentication and to generate the call to 9 1 972 555 3456 (step 3). After authenticating the user and receiving the number to be dialed, Unified CM generates a call via the user's Remote Destination Profile (step 4). The outbound call to 972 555-3456 is routed via the PSTN gateway (step 5). Finally, the call rings at the PSTN destination phone with number 972 555-3456 (step 6).
Figure 25-7 Mobile Voice Access
Note
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 and, just as before, the user is prompted via IVR to enter their numeric user ID, PIN number, and then a 1 to make a Mobile Voice Access call, followed by the phone number they wish to reach.
Note
Again the user enters 9 1 972 555 3456 as the number they wish to reach (followed by the # sign) (step 2). Next the PSTN gateway collects and forwards the user input to the separate H.323 VoiceXML gateway with DID 408-555-2345, and the VoiceXML gateway plays IVR prompts to the PSTN gateway and the Mobile Voice Access user (step 3).
In the meantime, Unified CM has forwarded IVR prompts to the H.323 VoiceXML gateway, and the VoiceXML gateway in turn has collected user input (including the numeric ID and PIN number of the user) from the PSTN gateway. This information is forwarded to Unified CM for authentication and to generate the call to 9 1 972 555 3456 (step 4). After authenticating the user and receiving the number to be dialed, Unified CM generates a call via the user's Remote Destination Profile (step 5). The outbound call to 972 555-3456 is routed via the PSTN gateway (step 6). Finally, the call rings at the PSTN destination phone with number 972 555-3456 (step 7). The voice media path in the case of each Mobile Voice Access call using hairpinning is not only hairpinned within the enterprise PSTN gateway utilizing two DS0s or analog ports, but it is also hairpinned at the H.323 VoiceXML gateway.
Figure 25-8 Mobile Voice Access Using Hairpinning
Note
Note
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
Next the outgoing call is originated via the user's remote destination profile (step 3), and the call to PSTN number 972 555-3456 is routed via the enterprise PSTN gateway (step 4). Finally, the call rings the PSTN phone (step 5: in this case, 972 555-3456). As with Mobile Voice Access, the voice media path of each Enterprise Feature Access two-stage dialed call is hairpinned within the enterprise PSTN gateway utilizing two DS0s or analog ports.
Figure 25-9 Enterprise Feature Access Two-Stage Dialing Feature
Note
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 from dialing certain numbers when using these features. In order to restrict or block calls to certain numbers when using these features for off-net calls, a comma-separated list of those numbers can be configured in the System Remote Access Blocked Numbers service parameter field (see Unified CM Service Parameters for Mobile Voice Access and Enterprise Feature Access). Once this parameter is configured with blocked numbers, those numbers will not be reachable from a user's remote destination phone when using Mobile Voice Access or Enterprise Feature Access features. Numbers that administrators might want to block can include emergency numbers such as 911. When configuring blocked numbers, ensure they are configured as they would be dialed by an enterprise user, with appropriate prefixes or steering digits. For example, if an emergency number is to be blocked and the emergency number is dialed by system users as 9911, then the number configured in the System Remote Access Blocked Numbers field should be 9911.
Remote Destination Configuration and Caller ID Matching
When authenticating users for Mobile Voice Access and Enterprise Feature Access two-stage dialing functionality as well as the mid-call features Transfer and Conference, the caller ID of the calling remote destination phone is matched against all remote destinations configured within the system. Matching of this caller ID depends on a number of factors, including how the remote destination numbers are configured, whether Application Dial Rules have been configured on the system, and whether the Matching Caller ID with Remote Destination parameter is set to Partial or Complete Match (see Unified CM Service Parameters for Mobile Voice Access and Enterprise Feature Access).
To control the nature of this matching, consider the following two approaches.
Using Application Dial Rules
With this approach, remote destinations are configured just as the caller ID would be presented from the PSTN. For example, if the caller ID from the PSTN for a remote destination phone is presented as 4085557890, then this number should be configured on the Remote Destination configuration page. In order to route Mobile Connect calls appropriately to this remote destination, it is then necessary to use Application Dial Rules to prefix necessary PSTN access codes and other required digits. For example, if 9 is required to reach the PSTN when dialing calls and a 1 is required for dialing long distance, then an Application Dial Rule would have to be created with the Prefix With Pattern field set to 91. When using this approach, the Matching Caller ID with Remote Destination parameter should be left at the default setting of Complete Match.
Note
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
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.
2.
3.
Figure 25-10 Mobile Voice Access and Enterprise Feature Access Architecture
Note
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:
•
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.
•
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
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
Outbound call routing for Mobile Voice Access or Enterprise Feature Access calls always uses a concatenation of the Remote Destination Profile line CSS and device-level CSS, therefore it is important to make sure that these calling search spaces are configured appropriately in order to provide access to any route patterns necessary for off-net or PSTN access, thus ensuring proper outbound call routing from remote destination phones.
Caller ID Transformations
Any calls made into the cluster by configured remote destination numbers will automatically have their caller ID or calling number changed from the calling remote destination phone number to the enterprise directory number of the associated desk phone. For example, if a remote destination phone with number 408 555-7890 has been configured and associated to a user's enterprise desk phone with number 555-1234, then any call from the user's remote destination phone destined for any directory number in the cluster will automatically have the caller ID changed from the remote destination number of 408 555-7890 to the enterprise directory number of 555-1234. This ensures that the active call caller ID display and call history log caller ID reflect a mobility user's enterprise desk phone number rather than their mobile phone number, and it ensures that any return calls are made to the user's enterprise number, thus anchoring those calls within the enterprise.
Likewise, calls from a remote destination phone to external PSTN destinations and anchored in the enterprise via Mobile Voice Access or Enterprise Feature Access two-stage dialing, or those calls forked to the PSTN as a result of Mobile Connect, will also have caller ID changed from the calling remote destination phone number to the associated enterprise directory number.
Finally, in order to deliver the calling party number as an enterprise DID number rather than an enterprise directory number to external PSTN phones, calling party transformation patterns can be used. By using calling party transformation patterns to transform caller IDs from enterprise directory numbers to enterprise DIDs, return calls from external destinations will be anchored within the enterprise because they will be dialed using the full enterprise DID number. For more information about these transformations and dial plan implications, see Special Considerations for Cisco Unified Mobility, page 10-92.
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
The following performance counters can be viewed in the RTMT tool to track health and utilization of Unified Mobility:
Unified Mobility
•
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
•
Increments each time a call to an enterprise number is extended to a remote destination via Mobile Connect.
•
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
•
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 #.
•
Increments each time a phone dialed using Mobile Voice Access begins to ring.
•
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:
•
•
•
Table 25-4 lists the common configuration issues or symptoms and the resolution for each issue.
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:
•
•
•
•
•
•
For additional guidelines and restrictions, refer to the Mobile Connect and Mobile Voice Access information in the latest version of the Cisco Unified Communications Manager Features and Services Guide, available at
Cisco Unified Mobility Performance and Capacity
Cisco Unified Mobility supports the following capacities:
•
•
•
•
•
•
Note
The maximum number of supported mobility-enabled users will depend on the number of remote destinations or mobility identities configured for each user. The capacity numbers for maximum number of mobility-enabled users given above assumes one remote destination or mobility identity per user. As the number of remote destinations or mobility identities per user increases, the number of supported mobility-enabled users decreases.
Note
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
Design Recommendations for Deploying Unified Mobility
Observe the following design recommendations when deploying Unified Mobility:
•
Note
•
–
–
Note
Note
•
–
–
–
•
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:
•
•
•
•
•
•
•
Note
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:
•
•
•
Note
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:
•
•
•
•
Note
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 the supported mobile OSs and handsets listed above for Cisco Unified Mobile Communicator 7.x, Cisco Unified Mobile Communicator 3.x supports the RIM OS for Blackberry mobile handsets.
Handset model support for the RIM OS varies based on the specific Cisco Unified Mobile Communicator version. For Cisco Unified Mobile Communicator 3.1.8 and earlier versions, only a very specific set of handset models is supported. Further, service provider certification and support for handsets is required. For this reason, support will vary depending on geographic location. For a current list of the supported Blackberry handsets and service providers by geographic location for Cisco Unified Mobile Communicator 3.1.8 and earlier versions, 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
Beginning with Cisco Unified Mobile Communicator 3.1.10, handset support for RIM OS is based on a minimum set of requirements. The following list contains general requirements that Blackberry handsets must meet in order to be supported:
•
•
•
Note
For a current list of specific requirements that Blackberry handsets must meet for Cisco Unified Mobile Communicator 3.1.10 and later versions, 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
Cisco Unified Mobility Advantage 7.x supports Cisco Unified Mobile Communicator Blackberry RIM OS 3.x clients, with some limitations in functionality. When Cisco Unified Mobile Communicator Blackberry 3.x clients are deployed with a Cisco Unified Mobility Advantage 7.x server, the following features and functionality are supported:
•
•
•
•
•
•
The following Cisco Unified Mobile Communicator 7.x features are unavailable on Blackberry RIM OS:
•
•
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:
•
–
–
•
–
–
Note
Note
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
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 SSL connection through the ASA 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
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
Dial-via-office reverse callback is currently supported only for Windows Mobile and Nokia mobile handsets running Cisco Unified Mobile Communicator 7.x.
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 SSL connection through the ASA 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. Once the number is received at the mobile device, the Cisco Unified Mobile Communicator client generates a call dialog box prompting the user to call the Enterprise Feature Access number (step 3). When the user responds to the dialog by selecting Call, an outgoing call from the mobile device is generated 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
Note
Figure 25-13 Cisco Unified Mobile Communicator, Dial-via-Office Forward
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 currently supported only with Cisco Mobile, the Cisco Unified Mobile Communicator client for the iPhone.
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 federated 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, federation 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 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:
•
•
•
•
•
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
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.
Beginning with Cisco Unified Mobility Advantage 7.1, 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, support for Cisco MeetingPlace Express has been dropped due to the fact that MeetingPlace Express does not support click-to-join through SOAP.
Note
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, 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, 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 Unified Mobile Communicator Redundancy
The Cisco Unified Mobile Communicator client is completely reliant upon the backhauled data connection across the GPRS or 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 GPRS network, or failure of the ASA TLS Proxy or the 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
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 GSM or mobile voice network as usual. In addition, if the user and the mobile phone have been integrated with Unified Mobility on Unified CM, then Mobile Connect functionality as well as features such as Mobile Voice Access and Enterprise Feature Access will still be available.
Failure of enterprise applications such as Cisco Unified 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:
•
•
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:
•
•
•
•
•
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 GSM or 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:
•
•
•
•
•
–
–
Note
•
•
http://www.cisco.com/en/US/products/ps7270/products_device_support_tables_list.html
