-
Cisco Unified Communications SRND Based on Cisco Unified Communications Manager 5.x
-
Preface
-
Introduction
-
IP Telephony Deployment Models
-
Network Infrastructure
-
Gateways
-
Cisco Unified Communications Manager Trunks
-
Media Resources
-
Music on Hold
-
Call Processing
-
Call Admission Control
-
Dial Plan
-
Emergency Services
-
Third-Party Voicemail Design
-
Cisco Unity
-
Cisco Unified MeetingPlace Integration
-
Cisco Unified MeetingPlace Express
-
IP Video Telephony
-
LDAP Directory Integration
-
IP Telephony Migration Options
-
Voice Security
-
IP Telephony Endpoints
-
Cisco Unified Presence
-
Cisco Unified Communications Manager Applications
-
Cisco Mobility Applications
-
Recommended Hardware and Software Combinations
-
Glossary
-
Index
-
Table Of Contents
Unified CM Services and Mobility System Parameters
Unified CM Services for Mobile Connect
Unified Mobility System Parameters
Remote Destination Phone Pickup
Single Enterprise Voicemail Box
Mobile Connect Dial Plan Considerations
Centralized Gateway Call Routing
Distributed Gateway Call Routing
Unified Mobility Application Server Redundancy
Mobile Voice Access Phone Support
Cisco Unified CM Services and Mobility System Parameters
Unified CM Services for Mobile Voice Access
Unified Mobility Mobile Voice Access System Parameters
Mobile Voice Access IVR VoiceXML Gateway URL
Mobile Voice Access Functionality
Mobile Voice Access Using Hairpinning
Desk and Remote Destination Phone Pickup
Enabling and Disabling Mobile Connect
Mobile Voice Access Architecture
Mobile Voice Access Dial Plan Considerations
Mobile Voice Access Redundancy
Guidelines and Restrictions for Unified Mobility
Unified Mobility Performance and Capacity
Cisco Mobility Applications
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 functionality delivered within the Cisco Unified Communications solution is provided via the Cisco Unified Mobility application server. The Mobility server communicates with Cisco Unified Communications Manager (Unified CM) via the Java Telephony Application Programming Interface (JTAPI) and AVVID XML Layer (AXL) and provides the following mobility application functionality:
•
Mobile Connect
Mobile Connect or Single Number Reach provides Cisco Unified Communications users with the ability to be reached via a single enterprise phone number that will ring 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.
•
Mobile Voice Access or Enterprise Dial tone provides mobile users with the ability to make calls from their mobile phone as if they were calling from their enterprise IP desk phone. The feature provides a cost savings in terms of toll charges for long distance or international calls, and it provides the enterprise with an easy way to track phone calls made by employees via a uniform and centrally located set of call detail records.
This chapter examines the following mobility applications as provided by the Cisco Unified Mobility application server:
This chapter also examines general guidelines and restrictions as well as performance and capacity of the Cisco Unified Mobility application server:
Mobile Connect
Mobile Connect is an application that allows an incoming call to an enterprise user to be offered to the user's IP desk phone as well as up to four 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 with both Skinny Client Control Protocol (SCCP) and Session Initiation Protocol (SIP).
Beginning with Cisco Unified Communications Manager release 5.1.1(b), the Cisco Unified IP Phones 7942G, 7945G, 7962G, 7965G, and 7975G are also supported with Mobile Connect for both SCCP and 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, Unified Mobility, and the enterprise PSTN gateway that handled the outgoing call to the remote destination.
Note
Unified CM Services and Mobility System Parameters
For the Mobile Connect 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 Services for Mobile Connect
The Mobile Connect application relies in part on the Cisco CTIManager and Cisco AXL Web Service feature services, which must be activated manually from the Serviceability page on one or more nodes. The Mobile Connect application also relies on the Cisco CallManager Cisco IP Phone Services network service, which is automatically activated on Unified CM nodes during installation.
The Cisco CTIManager service interfaces and interacts with the Cisco CallManager Service and the Mobility application server for Mobile Connect call control and monitoring. The Cisco AXL Web Service interfaces and interacts with the Unified CM database and the Mobility application server for authentication of Mobile Connect users.
The Cisco Unified IP Phone Services service is needed to provide access to the Mobile Connect phone service for remote phone pickup from the desktop phone. The URL used to define the Mobile Connect phone service is:
http://<Mobility_Server_IP-Address>:8081/ip_phone/main.xml
(where <Mobility_Server_IP-Address> is the IP address of the Mobility application server)
In addition, you must configure a parameter named dn (case-sensitive) for the Mobile Connect phone service. This is a required parameter. When a device is subscribed to the Mobile Connect phone service, the shared line directory number must be entered in this parameter field.
Unified Mobility System Parameters
The following items represent a partial list of Cisco Unified Mobility system parameters related to Mobile Connect functionality:
•
This parameter determines whether the Mobile Connect feature is enabled. This is a system-wide parameter. (Note that this parameter can also be configured per remote destination per user within Unified Mobility.)
•
This parameter specifies the maximum time, in seconds, that the system will allow the desk phone to pick up after the remote destination phone ends a Mobile Connect call. If this time is exceeded, the call will be terminated and desk phone pickup will not be possible. (Note that this parameter can also be configured per user within Unified Mobility.)
•
This parameter determines whether a Mobile Connect call answered by the desk phone can be picked up at the remote destination phone. This is a system-wide parameter. (Note that this parameter can also be configured per user under the line appearance configuration page within Unified Mobility.)
•
This parameter specifies the minimum time, in milliseconds, that must pass before the remote destination phone can be answered after the call is extended to this phone. If the call is answered before this time, the system assumes that the remote destination voicemail has picked up the call. This feature is designed to prevent calls to enterprise phones from being forwarded to the remote destination voicemail system. The Enable Minimum Cellular Phone Ring Timer parameter must be set to yes in order for this parameter to be used. (Note that this parameter can also be configured per remote destination per user within Unified Mobility.)
•
This parameter specifies the maximum time, in milliseconds, that a call to the remote destination phone will be extended. If the call is not answered before this time, the remote destination call leg is disconnected. The Enable Maximum Cellular Phone Ring Timer parameter must be set to yes in order for this parameter to be used. (Note that this parameter can also be configured per remote destination per user within Unified Mobility.)
•
This parameter specifies the minimum time, in milliseconds, that the system will wait before extending a Mobile Connect call to configured remote destinations. The Enable Delay Before Ringing Cellular Phone system parameter must be set to yes in order for this parameter to be used. (Note that this parameter can also be configured per user within Unified Mobility.)
•
This parameter specifies the Unified CM node that should be used for AXL interaction.
Mobile Connect Functionality
Figure 23-1 illustrates a basic Mobile Connect call flow. In this example, Phone A on the PSTN calls a Mobile Connect user's enterprise directory number (DN) 408-555-1234 (step 1). The call comes into the enterprise PSTN gateway and is extended via Unified CM to the IP phone with DN 408-555-1234 (step 2), and this phone begins to ring. The call is also extended to the Unified CM shared line CTI port with the same DN (step 3). In turn, this call is offered to the Unified Mobility application server (step 4). Unified Mobility then places a call to the Mobile Connect user's configured remote destination (in this case 408-555-7890) via a Unified CM outgoing CTI port (step 5). The outgoing call is routed via the Mobility CTI route point in Unified CM (step 6) and then routed to the remote destination via the PSTN gateway (step 7). Finally the call rings at the remote destination PSTN phone with number 408 555-7890 (step 8). The call can then be answered at either phone.
Figure 23-1 Mobile Connect
Typically a Mobile Connect user's configured remote destination is their mobile phone on a global system for mobile communications (GSM) or cellular network; however, any destination reachable via the PSTN can be configured as a user's remote destination. Furthermore, a Mobile Connect user can have up to four remote destinations configured, so an incoming call could potentially ring as many as four PSTN phones as well as the user's desk phone. 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 23-2, 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 hung 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 23-2 Desk Phone Pickup
Desk phone pickup can occur whenever a call is in progress at a configured remote destination phone and that phone is hung up. The option to pick up or resume the call at the desk phone is always 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, you can configure this setting by changing the system-wide parameter Maximum Wait Time For Desk Phone Pickup or the specific user line appearance parameter (see Unified Mobility System Parameters).
Remote Destination Phone Pickup
Figure 23-3 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 (step1), the user must push the Services button on the phone and select the Mobile Connect phone service. Assuming the Mobile Connect feature is enabled for this phone and that remote pickup is available, the user presses the Pickup softkey and then the Hold 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 23-3 Remote Destination Phone Pickup
After pushing the Pickup softkey, the Mobile Connect user can also wait to push the Hold softkey until the remote destination phone has begun to ring or even until the remote destination phone has been answered. However, in order for the voice media path to be extended to the remote destination phone, the Hold softkey must be pushed. 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
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, Unified Mobility provides a set of timers that can be used in conjunction with call-forward timers on Unified CM. 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 Unified Mobility system parameter Delay Before Ringing Cellular Phone (see Unified Mobility System Parameters) 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.
•
You can accomplish this by setting the Unified Mobility system parameter Maximum Cellular Phone Ring Timer (see Unified Mobility System Parameters) to a value that is less than the amount of time that a remote destination phone will forward to its voicemail box. This ensures that the remote destination phone stops ringing before the call can be forwarded to its own voicemail box.
To ensure that the call is still forwarded to the enterprise voicemail box in cases where a user's 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 Unified Mobility system parameter Minimum Cellular Phone Ring Timer (see Unified Mobility System Parameters). 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.
Mobile Connect Architecture
The architecture of the Mobile Connect feature is as important to understand as its functionality. Figure 23-4 depicts the message flows and architecture required for Mobile Connect. The following sequence of interactions and events can occur between the Unified Mobility applications server, Unified CM, and the Mobile Connect user:
1.
2.
3.
4.
Note
5.
6.
http://<Mobility_Server_IP-Address>/cmmuser/
where <Mobility_Server_IP-Address> is the IP address of the Unified Mobility application server (see step 6 in Figure 23-4).
Figure 23-4 Mobile Connect Architecture
Mobile Connect Dial Plan Considerations
Dial plan configuration is extremely important for Mobile Connect. To ensure that calls to a Mobile Connect user's enterprise DN not only ring the desk phone but also get extended to the user's configured remote destination or destinations, it is important to configure the shared line and outgoing CTI ports as well as the CTI route point with the appropriate dial plan class of control.
Figure 23-5 shows an example of a Mobile Connect dial plan with the requirements for calling search spaces and partitions as well as the configuration of the various types of devices within these dial plan components. One partition is required for Mobile Connect, and that partition is called Mobility for the example in Figure 23-5. It contains the Mobility CTI Route Point DN.
In addition, one calling search space is required for Mobile Connect, and in this example the calling search space is called MobilityManager_CSS. It contains the Mobility partition.
Besides showing the minimum dial plan requirements for Mobile Connect in the example in Figure 23-5, additional dial plan configuration has been depicted because most real-world telephony networks will have added or existing dial plan requirements that must be integrated with the Mobile Connect dial plan. First, two additional partitions, Internal and PSTN, are depicted. The Internal partition includes all the internal DNs, including the Mobile Connect user desk phone DNs as well as the Shared Line CTI port DNs and the Outgoing CTI port DNs. The PSTN partition includes a set of route patterns used for routing calls to the PSTN via the common route group (RG), route list (RL), and voice gateway mechanism. Next, two additional calling search spaces, Incoming_PSTN_CSS and Outgoing_PSTN_CSS, are shown. Incoming_PSTN_CSS serves as the calling search space to which incoming calls from the PSTN are sent. In order for these incoming calls to reach the appropriate enterprise phones, this calling search space contains the Internal partition so that calls can reach all the internal DNs and the Shared Line CTI ports. The Outgoing_PSTN_CSS calling search space contains both the Internal partition and the PSTN partition so that devices pointing to this calling search space can reach not only internal phones but also external PSTN phones.
This is the extent of the Mobile Connect dial plan in this example. However, it is also important to properly configure the various phone and CTI ports and route point DNs or lines with the appropriate calling search spaces so that call routing works as required. In this case all Mobile Connect user phones, Shared Line CTI Ports, and the Mobility CTI Route Point lines would be configured with the Outgoing_PSTN_CSS calling search space so that all of these lines can reach the route patterns of the PSTN partitions and, therefore, the remote destination PSTN phone numbers configured for all Mobile Connect users. Likewise, these lines also need to be able to reach all internal phone, Shared Line CTI Port, and Outgoing CTI Port DNs for internal call routing. Next, all Outgoing CTI Port lines are configured with the MobilityManager_CSS calling search space so that all of these lines can reach the Mobility Route Point DN in the Mobility partition. In this way, the dial plan ensures that calls extended by the Unified Mobility application server to the Outgoing CTI Ports to Mobile Connect users' configured remote destinations will be routed via the Mobility Route Point.
Figure 23-5 Mobile Connect Dial Plan Example
Centralized Gateway Call Routing
Unified Mobility call routing to the PSTN for Mobile Connect is handled by the Outgoing CTI port pool and the Mobility CTI Route Point configured within Unified CM. However, in order to integrate with Unified CM so that this routing mechanism can be used, Unified Mobility relies on a pair of CTI connections (Shared Line User Link and Outgoing Port User Links). While Unified Mobility has the ability to configure and maintain more than one set of CTI connections to Unified CM, it has no mechanism for controlling which outgoing calls are routed on which set of CTI connections. As a result, there is no mechanism for supporting more than one Outgoing CTI port pool or more than one Mobility CTI Route Point within Unified CM. What this means for routing Mobile Connect calls to the PSTN is that all Mobile Connect calls must use the same Mobility CTI route point. Therefore, there is no ability to easily route groups of Mobile Connect calls to the PSTN based on groups of users and their location. Instead, all Mobile Connect calls are typically routed out one or more centralized gateways for all users regardless of their location. For this reason, PSTN call routing is dependent on centralized gateways.
The use of centralized gateways can present problems for Mobile Connect calls from the perspective of a dial plan and call routing when Unified Mobility is deployed in a centralized call processing environment where there are multiple remote branch sites with local PSTN gateways and Mobile Connect users. As Figure 23-6 illustrates, call admission control on the WAN between sites can prevent Mobile Connect calls from being completed if there is not sufficient bandwidth on the WAN. In this example, Phone A (a PSTN phone) dials a Mobile Connect user's enterprise DID, DN 408 555-1234 (step 1). The incoming call comes into the enterprise via the branch site PSTN gateway and is extended to the user's desk phone (step 2). The call is also extended to the user's configured remote destination (in this case, 408 555-7890) over the WAN to the centralized gateway in the central site (step 3). Because this call could potentially be routed over the WAN and out the centralized gateway, it is possible the call will fail due to a call admission control denial if there is not sufficient bandwidth on the WAN link (step 4).
Figure 23-6 Mobile Connect with Centralized Gateway
Distributed Gateway Call Routing
As the call flow depicted in Figure 23-6 illustrates, the outgoing PSTN call to the Mobile Connect user's remote destination egresses the enterprise on a different PSTN gateway than the original incoming PSTN call to the user's enterprise DN. In centralized call processing environments with low-speed WAN links between the central site and remote branch sites where Mobile Connect functionality is desired, it might be appropriate to modify the Mobile Connect dial plan so that Mobile Connect calls to a user's remote destination can be routed out the same PSTN gateway on which the call came into the enterprise. In many cases, this provides more efficient call routing and prevents the potential for call admission control denials on WAN links interconnecting sties.
Figure 23-7 shows a dial plan method for achieving distributed gateway call routing in a Mobile Connect environment. In this example the Mobility CTI route point points to the MM_PSTN_CSS calling search space, which contains the MM_PSTN partition. The MM_PSTN partition in turn includes a series of site-specific route patterns in the form of 9 + 1 + area code or Number Plan Area (NPA), each pointing to a different route group (RG), route list (RL), and PSTN gateway mechanism, thus ensuring that outgoing PSTN calls from the Mobility CTI route point are routed out a particular site's gateway or gateways. In this case all outgoing Mobile Connect calls dialed with an NPA or area code of 212 will be forwarded out the NYC RG, RL, and PSTN gateway construct (after the appropriate number of digits have been discarded as dictated by site-specific requirements). Likewise, outgoing Mobile Connect calls dialed with the 408 and 972 NPAs will be forwarded out the SJC RG, RL, and PSTN gateway construct and the DFW RG, RL, and PSTN gateway construct, respectively. Of course, this method of distributed gateway call routing can be made as granular as necessary to facilitate multiple gateway sites within the same NPA by adding more specific route patterns in the MM_PSTN partition.
Figure 23-7 Mobile Connect Distributed Gateway Call Routing Dial Plan Example
With a distributed gateway call routing dial plan as depicted in Figure 23-7, it is possible to avoid sending most outbound remote destination Mobile Connect calls across the WAN. Figure 23-8 shows the previous call flow with this new dial plan in place. Now when the PSTN phone (Phone A) dials the Mobile Connect user's enterprise DID DN 408 555-1234 (step 1) just as before, the incoming call comes into the enterprise via the branch site PSTN gateway and is extended to the user's desk phone (step 2). However, now the call is extended to the user's configured remote destination (in this case, 408 555-7890) out the branch site PSTN gateway rather than across the WAN to the centralized gateway (step 3). By hairpinning the call at the local branch gateway, you can avoid the potential for call failure due to a call admission control denial if there is not sufficient bandwidth on the WAN link.
Figure 23-8 Mobile Connect With Distributed Gateways
One scenario that the dial plan example in Figure 23-7 does not account for is one in which the NPA of a Mobile Connect user's remote destination phone is different than their enterprise DID NPA. As an example, referring again to Figure 23-8, suppose the Mobile Connect user's remote destination phone number is 212 555-7890 rather than 408 555-7890. In that case, the outbound call to the user's remote destination phone would be extended across the WAN to the site with the gateway that handles the 212 NPA rather than routing out the local branch PSTN gateway. In order to handle situations like this one, route patterns with steering digits or site code prefixes can be used in the MM_PSTN partition so that calls are distributed to remote gateways, not based on the NPA of the called number, but based on the configured prefix of a user's remote destination. This adds complexity to the dial plan and increases the administrative burden for maintaining such a dial plan. It also puts the onus on the Mobile Connect user to understand and know the appropriate site code to prefix their remote destination numbers when configuring them via the Unified Mobility user web interface. However, this might be an acceptable trade-off if more efficient call routing is achieved.
Ultimately, each network administrator must decide whether the centralized gateway or distributed gateway (with or without site prefixes) method of Mobile Connect call routing is most appropriate for their enterprise, and they must weigh dial plan complexity against the potential for undesirable PSTN call routing.
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 Mobility Application Server Redundancy
The application server provides the basis for Mobile Connect functionality. If this server fails, Mobile Connect users associated to the server will not be able to use Mobile Connect. There is no backup or redundancy mechanism in place to handle a complete Unified Mobility server failure.
In addition to the physical server itself, if any of the subcomponents within the Unified Mobility application server fail, Mobile Connect functionality can be lost or limited.
In order for Mobile Connect to function, both the Outgoing CTI User Link and the Shared Line CTI User Links must be in service. These links rely on the availability of Unified CM CTIManager nodes. Redundancy for these links is provided by specifying both a primary and secondary (or backup) Unified CM CTIManager node under the link configuration page. If the primary CTIManager node fails or if communication to the primary node is lost, the secondary CTIManager node can continue to provide connectivity for these links, thus ensuring that Mobile Connect functionality continues.
Cisco recommends dividing Mobile Connect users among three Shared Line CTI User links. This requires creation of three Mobility Shared Line CTI port users on Unified CM for each Unified Mobility application server. Each Mobility Shared Line user on Unified CM should be associated with one-third of the Shared Line CTI ports. On each Unified Mobility application server, three Shared Line CTI User Links should be created, with each one configured to use a different Mobility Shared Line CTI port user on Unified CM and a different primary Unified CM CTIManager node. By ensuring that Mobile Connect users are evenly distributed across the three Shared Line CTI User Links and across three CTIManager nodes, you can distribute the CTI load so that any CTIManager node failure affects only one-third of the Mobile Connect users. Furthermore, with this distributed configuration, system initialization is faster and failover to the backup CTIManager is faster.
Note
In order for the Mobile Connect user web interface to function so that Mobile Connect users can configure their applications settings (remote destinations, cellular timers, caller filters, and so forth), the Mobility application server relies on AXL connectivity to a Unified CM server in order to authenticate Mobile Connect users. AXL connectivity is determined by the Unified CM AXL Server Name or IP Address system parameter on the Unified Mobility server (see Unified Mobility System Parameters). This parameter specifies a single Unified CM server for AXL connectivity. However, if this server were to fail, Unified Mobility has no failover mechanism for AXL connectivity and must wait until the configured Unified CM AXL server is back in service. If this connectivity is not available, the user cannot be authenticated, and therefore the user cannot make changes; however, existing Mobile Connect configuration and functionality will continue.
Unified CM Server Redundancy
The Unified CM server is an integral part of the Mobile Connect feature. Unified CM server failures can be problematic for Mobile Connect functionality in certain scenarios. First, CTIManager service node failures can affect Unified Mobility Shared Line and Outgoing CTI Port links as previously discussed, but redundancy is provided in the Unified Mobility server for primary and secondary nodes. In addition, Mobile Connect functionality is very dependent on a number of Unified CM CTI components including the shared line CTI ports, the outgoing CTI port pool, and the Mobility CTI route point. However, both Unified CM group constructs (via device pools) for providing registration redundancy and CTIManager node redundancy for CTI connectivity within the cluster ensure that these CTI components will survive Unified CM node failures.
PSTN Gateway Redundancy
Because the Mobile Connect feature relies on the ability to extend a second call leg to the PSTN to reach the Mobile Connect user's remote destination phone, 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
Mobile Voice Access, also referred to as System Remote Access, is a feature built on top of the Mobile Connection application, and it enables a Mobile Connect 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. This feature benefits the enterprise by limiting toll charges and consolidating phone billing directly to the enterprise rather than billing to each mobile user. Mobile Voice Access is accessed by calling a system-configured DID number that is answered and handled by an H.323 VoiceXML gateway. The VoiceXML gateway plays interactive voice response (IVR) prompts to the Mobile Voice Access user, requesting user authentication and input of a number to be dialed via the user phone keypad. Once the call is connected, users can pick up the call on their desk phones just as with a Mobile Connect call.
Mobile Voice Access Phone Support
Mobile Voice Access is supported for all incoming PSTN devices capable of sending DTMF digits in response to the IVR prompts. Cisco Unified IP Phone support for Mobile Voice Access is the same as for Mobile Connect (see Mobile Connect Phone Support). Although an IP phone is not required to use Mobile Voice Access, a user wishing to pick up an in-progress Mobile Voice Access call on a desk phone will need access to one of the Mobile Connect supported phone models.
Cisco Unified CM Services and Mobility System Parameters
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 Services for Mobile Voice Access
The Mobile Voice Access application relies in part on the Cisco CTIManager feature services, which must be activated manually from the Serviceability page on one or more nodes. The Cisco CTIManager service interfaces and interacts with the Cisco CallManager Service and the Mobility application server for Mobile Voice Access call control and monitoring.
Unified Mobility Mobile Voice Access System Parameters
The following items represent a partial list of Cisco Unified Mobility system parameters related to Mobile Voice Access functionality:
•
This parameter indicates the Mobile Voice Access DID number(s). Use commas to delimit multiple DID numbers. This field can have a maximum of 200 characters, so the maximum number of DIDs will vary depending on the number of digits in each DID. For example, if all DIDs are seven digits, then a maximum of 25 DIDs can be configured (7 * 25 + 24 comma delimiters = 199 characters). As another example, if all DIDs are 10 digits, then a maximum of 18 DIDs can be configured (10 * 18 + 17 comma delimiters = 197 characters).
•
This parameter specifies whether Mobile Voice Access is enabled or not. To enable Mobile Voice Access system-wide, set this parameter to yes. (Note that this parameter can also be configured per Mobile Connect user within Unified Mobility.)
In addition to configuring the system parameters above, you must enable Mobile Voice Access for each user individually by setting the Enable User Remote Access field to yes under the Mobile Connect User Configuration page.
Mobile Voice Access IVR VoiceXML Gateway URL
The Mobile Voice Access feature requires the Unified Mobility VoiceXML application to reside on the H.323 gateway. The URL used to load this application is:
http://<Mobility_Server_IP-Address>:8080/cmmivr/pages/IVRMainpage.vxml
where <Mobility_Server_IP-Address> is the IP address of the Unified Mobility application server.
Mobile Voice Access Functionality
Figure 23-9 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).
Note
The call comes into the enterprise PSTN H.323 gateway, which also serves as the VoiceXML gateway. The user is prompted via IVR to enter their numeric user ID (followed by the # sign), PIN number (followed by the # sign), and then a 1 to make a Mobile Voice Access call, followed by the phone number they wish to reach. In this case, the user enters 9 1 972 555 3456 as the number they wish to reach (followed by the # sign) (step 2).
Note
In the meantime, the Unified Mobility application server 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 the Unified Mobility server 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 Mobility transfers the call to an outgoing CTI port (step 4). The call is then placed via the user's shared line CTI port (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 of each Mobile Voice Access call is hairpinned within the enterprise PSTN gateway utilizing two DS0s or analog ports.
Figure 23-9 Mobile Voice Access
Note
Mobile Voice Access Using Hairpinning
In deployments where the enterprise PSTN gateways are not using H.323 protocol, Mobile Voice Access functionality can still be provided using hairpinning on a separate gateway running H.323. Mobile Voice Access using hairpinning relies on off-loading the VoiceXML functionality to a separate H.323 gateway. Figure 23-10 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 (if required), PIN number, and then a 1 to make a Mobile Voice Access call, followed by the phone number they wish to reach. Again the user enters 9 1 972 555 3456 as the number they wish to reach (followed by the # sign) (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). Note that the media path between the PSTN gateway and the H.323 VoiceXML gateway requires a media termination point (MTP), therefore the media (including IVR prompts) must travel through this MTP (step 3A).
Note
In the meantime, the Unified Mobility application server 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 the Unified Mobility server 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 Mobility transfers the call to an outgoing CTI port (step 5). The call is then placed via the user's shared line CTI port (step 6). The outbound call to 972 555-3456 is routed via the PSTN gateway (step 7). Finally, the call rings at the PSTN destination phone with number 972 555-3456 (step 8). 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 23-10 Mobile Voice Access Using Hairpinning
If you anticipate heavy or frequent use of Mobile Voice Access using hairpinning, Cisco recommends a hardware-based MTP or Cisco IOS software-based MTP. Whenever possible, the MTP resource should be co-resident on the H.323 VoiceXML gateway or at the very least in the same physical location as the H.323 VoiceXML gateway. This will minimize the chances of unnecessary hairpinning of media for Mobile Voice Access calls and will keep media hairpinning within the same H.323 VoiceXML gateway or the same gateway location.
Desk and Remote Destination Phone Pickup
Because Mobile Voice Access is tightly integrated with the Mobile Connect feature, once a Mobile Voice Access call has been established (with or without hairpinning), 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. The Mobile Voice Access call can then be picked up on the user's configured remote destination phone by selecting the Mobile Connect phone service and pushing the Pickup softkey.
Enabling and Disabling Mobile Connect
In addition to providing Mobile Voice Access users with the ability to make calls from the PSTN as though they are within the enterprise, the IVR functionality provided by Mobile Voice Access on the H.323 VoiceXML gateway 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, Mobile Voice Access 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, they are prompted to key in the remote destination phone number for which they wish to enable or disable the Mobile Connect feature.
Mobile Voice Access Architecture
The architecture of the Mobile Voice Access feature is as important to understand as its functionality. Figure 23-11 depicts the message flows and architecture required for Mobile Voice Access. The following sequence of interactions and events can occur between the Unified Mobility applications server, Unified CM, and the H.323 VoiceXML (VXML) gateway:
1.
2.
3.
4.
Figure 23-11 Mobile Voice Access Architecture
Mobile Voice Access Dial Plan Considerations
Dial plan configuration for Mobile Voice Access requires the same dial plan class of control as required for Mobile Connect functionality. Mobile Voice Access relies on the same calling search spaces, partitions, route lists, route groups, and route patterns for proper operation. For more details, see Mobile Connect Dial Plan Considerations.
One additional consideration for the Mobile Voice Access dial plan is the Mobile Voice Access DID. This DID provides access from the PSTN to the VoiceXML and IVR functionality of Mobile Voice Access. Given a centralized call processing environment with multiple branch sites, it is a good idea to provide local DIDs and VoiceXML or IVR H.323 gateway service at each branch site. This not only provides toll savings by providing Mobile Voice Access users with a non-toll local access number, but by providing local H.323 VoiceXML gateway service in the case of Mobile Voice Access using hairpinning, it also prevents the call media from hairpinning over the WAN to a centralized H.323 VoiceXML gateway.
Mobile Voice Access Redundancy
The Mobile Voice Access feature relies on the same components and redundancy mechanisms as the Mobile Connect feature (see Mobile Connect Redundancy). However, the H.323 VoiceXML gateway and Mobile Voice Access DID requirements of Mobile Voice Access do present additional redundancy requirements. Unlike the Mobile Connect feature, Mobile Voice Access relies on a specific gateway protocol (H.323) and functionality (VoiceXML) as well as the need for specific feature access DIDs. Therefore, in addition to the components required for the Mobile Connect feature, the H.323 VoiceXML gateways required for Mobile Voice Access must also be redundant. As with regular PSTN gateways, H.323 VoiceXML gateways (whether for Mobile Voice Access or Mobile Voice Access using hairpinning) must be redundant so that there is sufficient capacity as well as multiple gateways and route group and route list constructs for call routing resiliency. The Mobile Voice Access feature can achieve resilient functionality only if multiple H.323 VoiceXML gateways and feature access DIDs are available.
Unified Mobility
The Cisco Unified Communications solution delivers mobility functionality via the Cisco Unified Mobility application server. The Unified Mobility server communicates with Unified CM via JTAPI and AXL, and it provides Mobile Connect and Mobile Voice Access functionality.
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 latest version of the Cisco Unified Mobility Administration Guide, available at
Unified Mobility Performance and Capacity
The Unified Mobility application server (version 1.2 or higher) supports the following capacities:
•
•
•
The Unified Mobility application server interacts with the Unified CM CTIManager for CTI line monitoring and call control. CTI connections within Unified CM are required in order to interact with Unified Mobility. CTI connection quantities needed for Unified Mobility interaction are as follows:
•
A shared line is required for each Mobile Connect or Mobile Voice Access user. Therefore, for each Mobility application server, a maximum of 1500 shared line CTI ports would be required, which equates to 1500 CTI connections per server. This would mean a maximum of 4500 CTI connections per cluster, given a maximum of three Unified Mobility application servers (MCS-7825, 7835, or 7845) per cluster.
•
An outgoing CTI port is required for each Mobile Connect or Mobile Voice Access call. Cisco recommends one outgoing CTI port for every five shared-line CTI ports (a ratio of 1:5). Therefore, for each Mobility application server, a maximum of 300 outgoing CTI ports would be required, which equates to 300 CTI connections per server. This would mean a maximum of 900 CTI connections per cluster, given a maximum of three Unified Mobility application servers (MCS-7825, 7835, or 7845) per cluster. Note that, if the ratio of outgoing CTI ports to shared-line CTI ports is higher, then the server-wide and cluster-wide numbers would be higher also.
•
A single CTI route point is required for each Unified Mobility application server. This would translate to a maximum of 3 CTI connections per cluster, given a maximum of three Unified Mobility application servers per cluster.
A total of 1801 CTI connections per Unified Mobility application server is possible, given an MCS-7825, 7835, or 7845 server. Each Unified Mobility application server should be configured to use a different primary and backup Unified CM CTIManager node in order to distribute the CTI load across multiple nodes in the cluster, if more than one server is deployed within a cluster.
Assuming a Mobility deployment at full capacity with MCS-7825, 7835, or 7845 servers (three Unified Mobility application servers with 1500 Mobile Connect or Mobile Voice Access users each), a total of 5403 CTI connections would be required within the Unified CM cluster. The number of required CTI connections for Unified Mobility within Unified CM must be considered with regard to the overall cluster limit for Unified CM CTI connections (10,000 CTI connections per cluster with the MCS-7845 platform or 3200 CTI connections per cluster with the MCS-7835 and MCS-7825 servers). If additional CTI connections are required for other applications, they can limit the capacity of the Unified Mobility application server.
