Chapter 13. Troubleshooting Cisco Unified Mobility Issues
Cisco Unified Mobility is a set of features that permits users to associate remote phone number destinations with their defined desk phone extensions and locations. It allows calls received at that desktop extension to be sent to mobile phones, home phones, or any other calling destination, whether internal or external to the corporate network.
This chapter examines the basics of the feature set, its components, configuration, and ways to troubleshoot potential issues that can arise.
Chapter Objectives
Upon completing this chapter, you will be able to
• Describe the key concepts of Cisco Unified Mobility
• Describe Cisco Unified Mobility configuration elements
• Describe how CSSs are implemented in Cisco Unified Mobility
• Describe how to implement call filtering for Mobile Connect calls
• List common Cisco Unified Mobility–related issues
• Troubleshoot Mobile Connect
• Troubleshoot Cisco Unified Mobility Voice Access
Cisco Unified Mobility Overview
Cisco Unified Mobility has been around for quite some time. It is rather interesting that, when the capabilities are described to Cisco collaboration customers, the initial responses include “Wow! That sounds great! How do I get that, and how much is it?” The answer is simple and usually met with surprised reactions. This no-cost feature set has been available since Cisco Unified Communications Manager (CUCM) 6.0. Few features have a greater “wow factor” or perceived value in CUCM than this one. The two essential aspects to the Cisco Unified Mobility feature set are as follows:
• Mobile Connect (MC): Allows an incoming call to a user’s desk phone directory number (DN) to be offered up to ten different remote destinations. This includes a cellular phone, alternate desk phone, home phone, Session Initiation Protocol Uniform Resource Identifier (SIP URI), and so on. Mobile Connect is also commonly referred to as single number reach (SNR).
• Mobile Voice Access (MVA): Allows a user to access and utilize enterprise dialing capabilities from outside the network. This legacy offering is also called direct inward system access (DISA).
Mobile Connect
Although both Mobile Connect and Mobile Voice Access allow active calls to be moved at will between the remote phone and the desk phone, Mobile Connect (aka single number reach) is the aspect that makes the biggest splash. Mobile Connect provides the capability to hide the cellular phone number of the individual user. Hiding cellular phone numbers of key individuals within a corporation is a highly coveted capability. The other capability offered is the capability to move a call seamlessly between the desk phone and remote destination with the touch of a button.
Mobile Connect is enacted when a user’s desk phone number is dialed. The inbound call is sent to CUCM, and additional calls are placed to the defined remote destinations. This means that a call utilizes a trunk line on ingress and then another when the remote destination is dialed. Therefore, implementation of this feature should involve keeping trunk utilization top priority. Running out of public switched telephone network (PSTN) trunks is an undesirable result. Some companies opt to limit the use of the feature to key individuals for this reason.
The brief description offered so far has introduced a number of key elements in the Mobile Connect realm. Most important among them is the concept of a remote destination. This is the number to which a call should be placed when the primary DN is dialed. Ten remote destinations can be defined per user. Key timers defined in the remote destination configuration perform the following functions:
• Notify the system how long to wait before calling the remote destinations
• Keep the call from going to the voice-mail box of the remote destination
• Have the capability to set a schedule detailing when calls are and are not forwarded
Other options are discussed in the configuration section later in this chapter.
The remote destination is associated with a remote destination profile (RDP). The remote destination profile is analogous to the device page of an Internet Protocol (IP) phone, similar to the device profile used with extension mobility. The remote destination is subject to class of restriction (CoR) defined in the rerouting calling search space (CSS) definition at the remote destination profile. As such, a high degree of troubleshooting ends up focusing on the rerouting calling search space when calls are not properly forwarded to remote destinations. Mobile Connect influences the calling-number presentation. If a call is placed from a configured remote destination—a user’s cell phone, for example—the call is presented to the destination with the user’s desk phone DN as the calling number rather than the cell phone number itself. This means that the automatic number identification (ANI) and dialed number identification service (DNIS) come into play. ANI is the calling-party number. DNIS is the called-party number. The ANI of the calling party must match the configured remote destination to be recognized. Some additional options are available in the configuration of the features. They are discussed shortly.
For purposes of discussion, consider the topology shown in Figure 13-1.
Figure 13-1. Mobile Connect Topology
In Figure 13-1, a user has been provisioned with a desk phone. The desk phone has been assigned 2001 as its DN. A remote destination has been created for that user to enable Mobile Connect features. The remote destination created for the user at DN 2001 is the cellular phone (+1-408-555-1001) shown in the figure. When that cellular phone is used to dial another company DN—in this case, 2002 (or +1-511-555-2002)—the system sees that the ANI, 408-555-1001, is a defined remote destination for DN 2001. Therefore, when the call is offered to 2002, the calling-party number is shown as 2001. This is also the case when the user calls into the voice-mail system. It recognizes the caller as a known extension because the ANI is replaced with the desk phone DN.
The primary capability for which Mobile Connect is utilized is the single number reach (SNR) feature. The concept has been described already. It is the capability to move the call back and forth between the desk phone and the remote destination phone. Figure 13-2 shows the topology using a cellular phone.
Figure 13-2. Mobile Connect Topology, Continued
Just as in the previous example, a user has a defined DN on the CUCM as well as a remote destination profile. However, in this case, the inbound call is not being placed from a known remote destination. It is being placed by a third party, unknown to the system. When a user receives a call, he or she makes a choice as to the device to use in answering the call. If the user chooses the desk phone, and the conversation goes on longer than anticipated, he or she can press the Mobility button on the desk phone and acknowledge that the call should move to mobile. At this point, the defined remote destination phone will ring. The call is answered and is now active on the cellular phone. The opposite case is also true. When a user answers a Mobile Connect forwarded call on the remote destination device, CUCM still maintains control of the call. If the user is out of the office when the call is answered, but the call continues on until after he or she arrives at the office, the user can simply hang up the cellular phone and press the Resume button on the desk phone, as if the call had been on hold. No pause in conversation is required. The party on the other end of the call would not even know there was a change.
Mobile Voice Access
Mobile Voice Access (MVA) is enacted by a user dialing into a pilot number to access CUCM enterprise voice features. Essentially, it provides a dial via office capability so that end users need not use their personal resources when taking care of company business. Using MVA, users can place calls from a defined remote destination to the outside as if using the desk phone in the office. Figure 13-3 shows the essential topology for Mobile Voice Access.
Figure 13-3. Mobile Voice Access Topology
An MVA pilot number is defined in CUCM and in the gateway. Users dial this pilot number from outside the network. It triggers an interactive voice response (IVR) call application presiding in the ingress gateway. The gateway application is triggered specifically by the dialing of the pilot number (2999). In this case, 2999 is an exact match to a dial peer that launches the application script. The IVR makes use of the Voice Extensible Markup Language (VXML) under the hood. The user is asked to authenticate (user ID and PIN) and then prompted to enter the destination phone number he or she wishes to dial. Once logged in, the user can enable or disable MVA or initiate a call sourced from the enterprise network. The calling-party information utilized for the call is the user’s desk extension, so the call appears to come from the office. Like Mobile Connect, calls placed using MVA can be moved back and forth between the remote destination phone and the desk phone.
The protocol in use with the voice gateway is of particular interest. Typically, VXML gateways are configured to make use of H.323 functionality. However, it is possible to implement the solution utilizing a more traditional Media Gateway Control Protocol (MGCP) or Skinny Call Control Protocol (SCCP) gateway configuration. That is not to say that the VXML/IVR application will run on the MGCP or SCCP gateway. The H.323 gateway must still be in the mix. Figure 13-4 shows the topological changes that enable the use of MGCP or SCCP on the ingress voice gateway.
Figure 13-4. Mobile Voice Access with MGCP or SCCP Gateways
In Figure 13-3, the pilot number matched a dial peer on the ingress gateway, which launched the VXML application. In Figure 13-4, this is no longer the case, as the ingress gateway is running MGCP. So, CUCM must be configured to send the call to the H.323 VXML gateway hosting the application. On the voice gateway, the MVA application is triggered in the same manner, by the called-party number, 2999, matching a dial peer and launching the application process. The significant difference is the positioning of the VXML gateway and whether it catches the call on ingress or CUCM forwards the call to it.
From there, the process is identical. The user is authenticated and presented with available options. The caller is then connected to the MVA media resources, and the outbound call is placed via the MGCP gateway on the user’s behalf with the desk phone number as the calling-party number.
Note
With proper design considerations, the H.323 functionality providing the application interface and the MGCP functionality can be combined onto a single gateway.
Cisco Unified Mobility Configuration Elements
Configuring Cisco Unified Mobility is not overly difficult. The configuration of both MVA and MC has similar underlying requirements. Figure 13-5 shows the relationship between all the components in the feature set.
Figure 13-5. Cisco Unified Mobility Configuration Elements
However, be aware that there are a number of so-called moving parts. As with other features, the first step is to activate and start the service. Open the Cisco Unified Serviceability page and select the relevant CUCM node. Click the check box next to Cisco Unified Mobile Voice Access Service and then click Save. Figure 13-6 shows the Service Activation page.
Figure 13-6. Cisco Unified Mobile Voice Access Service Activation
With the service activated, a corresponding media resource is activated and registered. Configuring it involves setting the pilot DN and partition and then adding a locale for the service. Open the CCMAdmin page and click on Media Resources > Mobile Voice Access. Figure 13-7 shows the Mobile Voice Access configuration page.
Figure 13-7. Mobile Voice Access Configuration Page
As discussed in the overview, a VXML gateway needs to be accessible to handle the call application. The pilot number configured under the media resources has to be reachable via the gateway. So, dial peer configuration is required on the gateway to launch the application when it is matched. Without this gateway, the caller is not able to use the feature because an VXML application is needed.
Callers accessing the system are authenticated by the remote destination number and the PIN configured for the user associated with the remote destination. In configuring the remote destination information, some dependencies are in play.
Remote Destination Profiles
The remote destination profile has to be created first because it is a required parameter in the remote destination configuration. The remote destination profile is similar to the device page of an IP phone. It has many of the same elements, device pool, CSS, and so on. One of the crucial differences is the rerouting CSS. This allows enforcement of the class of restriction, dictating to which remote destinations calls can be forwarded when the primary number is called. If the rerouting calling search space does not allow calls to the remote destination pattern, the call is rejected. For example, if the remote destination is an international destination and the rerouting calling search space includes a block of international route patterns, the call fails. Figure 13-8 shows the Remote Destination Profile Configuration page.
Figure 13-8. Remote Destination Profile Configuration Page
In Figure 13-8, the remote destination profile information has been filled in and saved. After that information is saved, the DN configuration option opens on the left side. This is configured as a shared line with the user’s primary desk phone. Add the DN to the profile, as shown in Figure 13-9. Notice that multiple DNs can be associated with a single remote destination profile. If a user has multiple DNs on one or more phones, the one remote destination profile can be used to forward calls placed to each of the user’s configured DNs. They simply need to be added here to make the association.
Figure 13-9. Remote Destination Profile Configuration Page, Continued
In Figure 13-9, note the addition of a direct link to Add a New Remote Destination. This is a simple way to navigate to the remote destination configuration page. Alternatively, click Device > Remote Destination. Then click Add New.
Remote Destinations
If you clicked the Add a New Remote Destination link, note that the owner user ID has already been populated. Fill in the rest of the required information and click Save. Figure 13-10 shows the Remote Destination Configuration page.
Figure 13-10. Remote Destination Configuration Page
In Figure 13-10, note the boxes that are checked. The Enabled Unified Mobility Features box, the Enable Single Number Reach box, and the Enable Move to Mobile box are all checked to enable all the available functionality for the user. Of course, there are additional configuration options. At the bottom of the figure, the timers are available for configuration. They dictate how long the primary phone should ring before an additional call is placed to the remote destination, how to handle voice mail on the remote destination device, and when to stop ringing the remote destination device. Further down the page are additional options for specifying a ring schedule, time zone for the schedule, and access lists. Figure 13-11 shows these options.
Figure 13-11. Remote Destination Configuration Page, Continued
In Figure 13-11, a ring schedule has been set to allow calls to be forwarded on specific days during specific hours. In addition to the schedule, there is a section that allows specific calls to be forwarded while others are blocked. If access lists have been set up in Call Routing > Class of Control > Access List, they can be referenced here in relation to whether the call is forwarded.
After you configure the remote destination as desired, click Save. At that point, a Remote Destination Profile entry is made available on the left side of the screen. Check the Line Association box, and then click Save again. Figure 13-12 shows the Remote Destination Configuration page with this option added and checked.
Figure 13-12. Remote Destination Configuration Page, Continued
Softkey Templates
The next aspect in the configuration of Cisco Unified Mobility is to allow for the Move to Mobile function. The box has already been checked in the remote destination configuration. But, to move the call, the Mobility softkey must be added to the desk phone. The softkey templates are context sensitive. So, the key must be added in the correct state. It only appears under contexts in which it is a valid option. Therefore, you don’t need to worry about putting it in the wrong place. It must be added to the Connected and On Hook states. Adding it to the On Hook state is optional. However, it does allow the user to check the status of the feature and enable/disable it. To do so, open CCMAdmin and click Device > Device Settings > Softkey Template. Then click Add New or copy an existing template. Figure 13-13 shows the Softkey Template Configuration page when adding a new template.
Figure 13-13. Softkey Template Configuration Page
After naming the template, decide whether you want it to be the default template for the system. Check the box or not, based on your decision. Not many options are available on the page shown in Figure 13-13. The next step is to configure the softkey layout. In the top-right corner, a drop-down box is already set to Configure Softkey Layout. Click the Go button beside it to assign the functions to each context. Figure 13-14 shows the Softkey Template Configuration page.
Figure 13-14. Softkey Template Configuration Page
Select the call state you want to modify in the drop-down box at the top of the Softkey Layout Configuration. In Figure 13-14, On Hook is selected and Mobility chosen and added to the available buttons. It was moved from the left box to the right box. Click Save, and then select the Connected call state and add Mobility to the right box again. Click Save again, and then Apply Config. If desired, you can move the Mobility button up or down in the list of selected softkeys. This changes the order in which it appears on the phone.
Service Parameters
For Mobile Connect remote destinations to be recognized by the system when they call in to an enterprise DN, they must match the ANI of the incoming call. Remote destinations typically include an access code for external dial tone (such as 9 or 0) and possibly a long-distance code. This means that, for the ANI to match the remote destination exactly, it must be prefixed with those codes. That practice is not necessarily in line with best practice. Alternatively, a service parameter in the Cisco CallManager Service Parameter Configuration page can be changed. Open the Cisco CallManager Service Parameter Configuration page and scroll down to the Clusterwide Parameters (System - Mobility) section. In that section, there are two fields to consider. The first is Matching Caller ID with Remote Destination. It defaults to Complete Match. Change it to Partial Match. Next, change the Number of Digits for Caller ID Partial Match to something less than the default, 10. Figure 13-15 shows the Service Parameter Configuration page with these changes made.
Figure 13-15. Service Parameter Configuration Page
In Figure 13-15, note two additional service parameters of interest. It may have been prudent to mention them in a prior section, but it would have meant multiple dives into the Cisco CallManager Service Parameter page. It was simply more efficient to address them here. Set Enable Mobile Voice Access to True and set the Mobile Voice Access Number. In the case of the examples here, use 2999.
CSS Implementation in Cisco Mobility Connect
MVA and MC employ CSS like other features. However, they make use of more than just the general device/line CSS. The collective CSS varies based on both the feature in use and the manner in which the features are invoked. Each line that a user wishes to use with Mobility must be added to the remote destination profile. The remote destination profile must also be associated with the user. The lines in the remote destination profile are shared with those of the primary phones. Figure 13-16 shows an example of a user with two desk phones and two DNs that are attached to a single remote destination profile.
Figure 13-16. Share Lines with Remote Destination Profile
The settings of the shared DN, partition/calling search space included, apply to all associated devices. The remote destination profile is configured with a (standard) CSS. This is used for calls that a remote phone places when it uses MVA, and a rerouting CSS, which is applicable to calls that are placed to a remote destination. For example, refer to Figure 13-16, if a call is placed to directory number 2002, Line1 at Office Phone 2 and all remote destinations that are associated with Line2 of the remote destination ring. For the call to the remote destination number, the rerouting CSS is used. If the remote phone with number 9 1 479 555-1555 calls in to the MVA and requests an outgoing call to be placed, the CSS of Line2 and the CSS of the remote destination profile are used for the outgoing enterprise call that Remote Destination2 initiates.
Mobile Connect uses two CSSs, depending on the origin of the call. For inbound PSTN calls to an office DN associated with a remote destination profile, the rerouting CSS is used to access the configure remote destination number. For an inbound call from a remote phone (that is a recognized remote destination) to an internal DN, the CSS of the ingress device is used, whether it be a gateway or other trunking mechanism. The ingress device CSS requires access to the internal called-party number, usually the gateway inbound CSS.
The call legs of a call utilizing MVA are handled independently. The inbound leg from the gateway is handled by CUCM and the MVA media resource (the VXML gateway). The CSS for this depends on the service parameter setting called Inbound CSS for Remote Destination in the Cisco CallManager Service settings. It can be set to use the Trunk/Gateway inbound CSS or the combination of the remote destination profile and line CSS.
The outbound call leg of an MVA call is set up between the MVA media resource (again, the VXML gateway) and the PSTN destination called from the MVA call application. The CSS used is the concatenated CSS of the shared line and the CSS of the remote destination profile. Priority is given to the partitions contained within the CSS of the shared line.
Cisco Unified Mobility Access List Functions
The capability to schedule times for forwarding calls and access lists was briefly mentioned in the discussion of configuration elements. In CUCM, access lists can be created to block or forward specific patterns. They’re simple to configure. User-specific schedules and access lists can be created and applied to the remote destination. Figure 13-17 shows the time of day schedule in the remote destination.
Figure 13-17. Time of Day Routing with Remote Destinations
Setting the schedule is somewhat self-explanatory: select the day of the week and the hours during which the call should be forwarded to the selected remote destination. What is not so self-explanatory is the access lists used in the When Receiving a Call During the Above Ring Schedule section. Access lists can limit calls forwarded based on the calling-party number. The access lists are configured in CCMAdmin under Call Routing > Class of Control > Access List. Click Add New and name the access list. You need to specify the owner of the access list because it will be associated with the user’s remote profile. Also, select whether the pattern should be blocked or allowed. Figure 13-18 shows an example of a blocked route pattern.
Figure 13-18. Access List Configuration
In Figure 13-18, 900 numbers are blocked. This is done by clicking the Add Member button. In the Access List Member Detail page, you add the 900XXXXXX route pattern by selecting Directory Number in the Filter Mask field and entering the pattern to be filtered on in the DN Mask field. Then click Save.
In Figure 13-17, three options are available in the When Receiving a Call During the Above Ring Schedule section. Each has a radio button next to it.
• Always Ring This Destination: Ring the remote destination regardless of the calling-party number. It is, however, subject to the schedule parameters.
• Ring This Destination Only If Caller Is In: Ring the remote destination based on the schedule and only if the calling-party number is in the allowed patterns in the defined access lists (Allowed Access List).
• Do Not Ring This Destination If Caller Is In: Ring the remote destination based on the schedule and only if the calling-party number is not in the blocked patterns of the access list (Blocked Access List).
A call rings the remote destination if it is received within the combined parameters of the schedule and access lists. If the call is received while allowed by the schedule and the Always Ring This Destination button is selected, it is forwarded. If the call is received outside the parameters of the schedule, the call rings the desk phone but not the remote destination. If access lists are in use, whether they are allowed or blocked, they’ll combine with the schedule and the selected radio button to decide whether to forward the call to the remote destination in question.
Troubleshooting Cisco Unified Mobility Issues
The most common issues with Cisco Unified Mobility typically stem from CSS issues or simple omissions of softkey template changes. Sure, there are a number of other potential issues. This section examines a few of the most common issues with the feature set. These issues include the following:
• Remote phones not ringing when a call is placed to the office phone
• Users unable to move calls between the desk phone and remote destination phone
• Users unable to reach MVA for outbound calling
Cisco Mobile Connect
With Mobile Connect, the most common issue is in the rerouting CSS. It has to include a class of control that allows dialing to the remote destination. If long-distance calls are not allowed, for example, and the remote destination is a long-distance destination, the call won’t go through. That is the first thing to check in any failure of a remote destination to ring when the desk phone DN is called.
The users enabled for this feature set will want to be able to move the call between the desk phone and the mobile phone. This is possible only if the Mobility softkey has been added to the desk phone. If it hasn’t been added to the softkey template, it is important to do so. The process for performing this task was covered in the configuration section of this chapter. You should add the softkey to the Connected context of the desk phone. Adding it to the On Hook context of the phone allows the user to enable or disable the feature. If the calls are not forwarding properly, ensure that the feature is indeed enabled.
Assuming the softkey has been added to the phone, another common issue is the failure to move the call to the mobile number. If the user presses the Mobility softkey and receives an error message stating that he or she is not a valid Mobile Phone User, the Mobility User ID field on the desk phone device page has most likely not been populated with the user ID. Open CCMAdmin and click Device > Phone > Find. Issue a query to find the user’s phone. On the device page, there is a field for Mobility User ID. Associate it with the user in question. Then have the user try the operation again.
If the user is able to activate the service on the phone and attempts to transfer the call to mobile but the call fails, there may be a CSS issue in play. Recall that the rerouting CSS is utilized in pushing calls to the remote destination. When a call comes in to a DN that has a shared line between the desk phone and the remote destination profile, the remote destination should ring also. Of course, this depends on the rerouting CSS of the remote destination profile.
Figure 13-19 shows a typical call troubleshooting topology for internal and PSTN calling.
Figure 13-19. Access List Configuration
In Figure 13-19, a call has come in for DN 2001 from a PSTN caller. The phone with the 2001 DN rings. However, the remote destination defined does not ring. A relatively limited number of issues can be causing the problem here.
First, make sure the feature has been enabled (and not disabled). That seems an odd statement, but recall that the administrator must enable it in the remote destination configuration. If the check boxes for Enable Single Number Reach and Enable Move to Mobile are not checked, the remote destination does not necessarily ring. Figure 13-20 shows the Remote Destination page. Make sure the check boxes are checked so that calls can be forwarded.
Figure 13-20. Remote Destination Configuration Page
The second possibility is that you placed the Mobility button on the On Hook context page of the softkey template. This way, the user can enable or disable the move to mobile feature. If the user has disabled it, he or she must re-enable it. Have the user press the Mobility button and ensure the feature is enabled.
Assuming both of the discussed items are correct and the feature is enabled, it’s time to check the schedule and access list. The time of day schedule allows the user to define the days and times during which the remote destination(s) rings. The remote destination(s) won’t ring outside the defined schedule. Open the remote destination and check the schedule configuration. Ensure that the day and time are configured to allow the call to be placed to the remote destination(s) in question.
If the schedule is okay and the feature is enabled at both points, check the access list configuration. Recall that there are block lists and allow lists. Either can be selected for each remote destination. If the calling-party number is being matched to a block on the access list, the remote destination will not ring. If the calling-party number matches an allow on the access list, the remote destination will ring as long as the schedule permits the call to be forwarded. The blocked access list blocks all listed entries. Any entry that is not on the blocked list is allowed. The allowed access list works in the opposite way. The entries that are on the list are allowed, and entries that are not on the list are blocked. The access list configures three types of entries:
• A specific directory number, which can include common wildcard characters
• Private
• Not available
The last two types are used in situations in which the calling ID is suppressed.
Other misconfiguration possibilities exist on the CUCM side with regard to Mobile Connect. Most issues tend to be caused by the CSSs involved or the enable/disable status of the feature. On occasion, the misconfiguration might be due to an incorrect partition (same DN and partition). If the DN on the remote destination profile is configured in a different partition from that of the desk phone DN, the remote destination will not ring when the desk phone DN is called. Make sure the DNs are a shared line appearance.
The user ID of the remote destination profile, the owner user ID on the remote destination, and the mobility user ID on the desk phone device page must all match. There seems to be a lack of consistency in naming these fields. They all need to be associated with the desired end user for the feature to work properly.
The next item to check, in terms of configuration, is the check box on the remote destination line. If the line is not marked for association, the remote phone will not ring. Open the remote destination page and make sure the check box next to the DN is checked. It is labeled Line Association. Refer to Figure 13-20 to reference the check box in which the box is checked.
With validation of the configuration of the feature at the user/desk phone level as well as the relevant remote destination/remote destination profile aspects, the suspicion falls back to the CSS configuration. The remote destination may not ring if the rerouting CSS is not set correctly at the remote destination profile. The rerouting CSS must have access to the route pattern specified in the remote destination. If it’s a PSTN destination, a matching PSTN route pattern must be accessible within the CSS.
With all these details validated, verified, reconfigured, double-checked, and so on, if the phone still doesn’t ring, check the ring timers. The remote destination allows some granular control over the timers involved in sending the call to the remote destination, pulling the call back, and handling voice mail. If the Wait x Seconds Before Ringing This Phone parameter is set too high, the call may go to the user’s voice mail prior to being sent to the remote destination. If the timer is left at the default of 4 seconds, it waits 4 seconds before ringing the remote destination. Check the timers. Make sure they’re valid for the device(s) in question.
Call Trace Example: Inbound Call to Mobile Connect
Let’s look at the ingress PSTN gateway. Understanding what happens there is important because it may assist in getting the feature set configured and remote destinations ringing. What follows is a trace view of a working call. Figure 13-21 shows the beginning of the trace.
Figure 13-21. Mobile Connect Call Trace, Part 1
In Figure 13-21, the PSTN calling-party number is 5554444. The called-party number (significant digits = 4 on the ingress gateway) is 2001. The desk phone and user with DN 2001 are associated with the remote destination 6065554444. The trace begins with the inbound call. The calling number is checked to see if it is a known remote destination. It is determined that the calling number is not a match. Digit analysis begins, and the inbound call is determined to be destined to 2001. The gateway’s inbound CSS is checked to see if 2001 can be matched. The 2001 is in the Internal_Pt, which is in its inbound CSS. The trace in the figure ends with a report that there are no other potential matches. Figure 13-22 continues the detail of the trace.
Figure 13-22. Mobile Connect Call Trace, Part 2
With the digit analysis complete, the call is sent to the phone(s) with the DN 2001. It is sent to any registered device with that DN, in the Internal_Pt. As expected, the phone rings. If there are associated remote destinations/remote destination profiles, they are processed according to the configured timers. In this case, the remote destination profile referenced in the trace output is “jdoe-rdp.” The remote destination is 6065554444. The remote destination is checked against the time of day configuration (be sure to set the time zone correctly). If the schedule allows it, the access lists are checked for allow/block configuration. Here, DayofWeek [1] indicates that it’s Monday. It also shows that no access list is found. So, the call is extended. Near the bottom of the trace, the outbound call setup request to the remote destination is 6065554444. It actually shows [006065554444]. In this case, it includes a PSTN access code of 0 and a long-distance prefix of 0 from the original caller, 5554444. Figure 13-23 shows the next phase of the trace.
Figure 13-23. Mobile Connect Call Trace, Part 3
Figure 13-23 is more a general summary of the call. It begins with the enterprise features available to the call. It shows the initialization of the call and shows general information about the remote destination, along with the associated user ID and timers. Figure 13-24 shows the continuation of the trace output.
Figure 13-24. Mobile Connect Call Trace, Part 4
The call proceeds and is processed as any other PSTN call. However, the CSS shown, TodFilteredPSS, is the rerouting CSS of the remote destination profile. It is not the CSS assigned to the line or device. Based on the contents of the rerouting calling search space, the trace shows the potential matches for the dialed digits. When the route pattern to be utilized is selected, the trace logs the associated route list, route group, gateway, and so on.
Troubleshooting Calls from Remote Destination Phones
The two most common problems associated with remote-phone calling are as follows:
• The complete PSTN number is presented instead of the associated office phone number.
• The internal called party cannot be reached.
You can see how to troubleshoot these issues in Figure 13-25.
Figure 13-25. Troubleshooting Calls from Remote Destination Phones
If the issue is the incorrect presentation of the calling-party number, you should double-check a few items, which include
• Remote Destination Line Association check box
• Remote Destination Line Partition
• Mobile Connect Disabled (by admin or user)
• Cisco CallManager Service Parameter caller ID matching
During the configuration of Mobile Connect, one or more remote destinations were defined for the user. The remote destination has a line component. Figure 13-26 shows the page in question.
Figure 13-26. Remote Destination Configuration Page
In Figure 13-26, notice that the line component includes a check box labeled Line Association. If that box is not checked, the phone isn’t able to pull the necessary information to present the desk phone as the calling-party number.
While you’re double-checking the check box for the line association, drill down into the line. Make sure the DN and partition defined for the line association match the desk phone exactly. If not, the association can’t be made properly.
Assuming both of those items are correctly configured, go back to the Remote Destination Configuration page (refer to Figure 13-26). Make sure the boxes for Enable Unified Mobility Features, Enable Single Number Reach, and Enable Move to Mobile are checked.
If the problem still persists, make sure the user hasn’t disabled Mobile Connect at the phone level. This is possible if you added the Mobility button to the On Hook state in the phone’s softkey template. If it was added to the On Hook state, make sure the feature has not been manually disabled at the user’s phone.
Finally, take a look at the Cisco CallManager Service parameters. Figure 13-27 shows the fields that can assist in troubleshooting this issue.
Figure 13-27. Cisco CallManager Service Parameter Configuration Page
Figure 13-27 shows the service parameters that you should be most concerned with. Recall the earlier discussion in the Service Parameter section, wherein the ANI needs to be identical to the remote destination number. This is typically a mismatch due to the need to prefix the remote destination with a PSTN access code, such as 9 or 0. If the Matching Caller ID with Remote Destination service parameter is set to Complete Match (the default setting), it is likely that there are issues in the presented calling-party number when calling into the network from the remote destination phone. Change the setting to Partial Match and then alter the Number of Digits for Caller ID Partial Match to some value less than the number of digits that allow an exact match to the ANI. So, if the remote destination is defined as 914085551234 and the ANI is presented as 4085551234, you should set the service parameter to 10 (default setting) so that it ignores the 9 and the 1 in detecting inbound calls from defined remote destinations. At times, the PSTN provider may alter the ANI format and number of digits sent. In the United States, providers may send 7 or 10 digits, depending on the provider and geographical locale. Alter the setting accordingly.
Troubleshooting Redirection of Calls to Remote Destination Phones
With the inbound issues covered, let’s examine the most common outbound call issues associated with Mobile Connect. When a user presses the Mobility button on the phone, it should show a prompt confirming that the user wants to move the call to the mobile destination. Answering the prompt in the affirmative should result in a call being placed to the defined remote destination, such as a cellular phone. If the attempt to move the call to mobile fails, the phone presents an error message stating that the redirection was not successful. Some common configuration parameters that you should check include the following:
• Mobility Softkey is not enabled
• Mobile Connect is not enabled (or disabled by admin or user)
• Remote Destination is misconfigured
• Remote Destination Profile is in an incorrect partition
• Remote Destination Profile line is not properly associated
• Rerouting Calling Search Space is incorrect
• Dial Plan incompatibility with CoS or dialing behavior
• Improper Gateway configuration
Figure 13-28 illustrates a sample topology.
Figure 13-28. Call Redirection Troubleshooting
Figure 13-28 shows the basic elements, including the remote phone, office phones, CUCM, and the PSTN egress gateway. CUCM is in the picture as more than simply the call control element; the configuration takes place there. In addition, note that the majority of issues discussed in the previous section also apply in this scenario. So, there is some repetition of information.
If the user cannot redirect a call, the problem may be due to the lack of the Mobility button being assigned to the softkey template. Or, it may be that the Mobility softkey has been assigned, but the template has not been associated with that particular user’s phone. In any event, both must be done: the Mobility button must be assigned to the softkey template and the softkey template assigned to the phone. Otherwise, the user does not have the option to redirect the call.
Assuming the softkey has been assigned, it is feasible for the user to disable the feature. At a minimum, the Mobility softkey needs to be assigned to the Connected context of the phone’s softkey template. This allows a call in progress to be moved to mobile. If the Mobility softkey has also been added to the On Hook context of the softkey template, the user can enabled or disable the feature manually. Ensure that the user has not disabled the feature. Have him or her press the Mobility softkey to view the status of the feature.
With softkey issues sufficiently covered, let’s examine the configuration of the remote destination and remote destination profile. As mentioned previously in this chapter, the relationship between them can be intricate. The most common configuration issue has to do with the prefixing of the remote destination number with the proper PSTN access code(s), be it a +1, 9, 0, or other relevant access code. It all depends on how the dial plan is configured to allow calls to egress to that particular remote destination, whether it is a local, long-distance, international, or E.164 route pattern.
Recall that the remote destination profile must have an associated line. This must be a shared line appearance with the user’s desk phone. The DN and partition need to match exactly in order. In addition, the line must be selected (through the check box) in the remote destination profile to be associated properly. So, a few items of note may be out of place in the configuration.
With the number format and line association(s) verified, check the rerouting CSS. This tends to be the most overlooked aspect of the configuration. The class of service (CoS) for the rerouting CSS must allow calls to the number specified in the remote destination. Check the rerouting CSS on the desk phone and the remote destination profile to ensure that both permit calls to the remote destination route pattern.
If a user is roaming using extension mobility (EM), there can be international incompatibilities. The egress gateway for the roaming user may not understand the prefix configured for the remote destination. Avoid this by using full E.164 dial plan elements throughout the deployment. In some instances, it may be that the simplest means of correcting the issue while a user is roaming is to alter the prefixed digits while he or she is traveling. However, this is not a truly scalable, or desirable, solution. Build the dial plan to accommodate the needs of the business and utilize features/intelligence built into CUCM as a platform.
Cisco Unified Mobile Voice Access
MVA allows users access to enterprise telephony and dial via office features while outside the network. Users can place PSTN calls from remote destinations by calling into a designated MVA pilot number and utilizing an IVR located on the ingress gateway or another gateway within the network. The user dials the pilot number, authenticates with the system, and then enters the desired destination phone number. CUCM places the outbound call to the destination on behalf of the user. After the call is established, the user can move the call to the desk phone, if it is accessible during the call, and then back to the remote destination phone if necessary.
The mechanics behind the scenes are similar to Mobile Connect in terms of establishing calls. The means of utilizing the feature set are quite different. The initial access to the system is through an inbound call to a pilot number that launches an application process for the IVR. So, the user must be able to reach the pilot number and the IVR application (whether on the ingress gateway or on another gateway within the network). If the IVR is unreachable, the features are unreachable. The troubleshooting process differs slightly based on the location of the IVR. If the IVR is not on the PSTN ingress gateway, it must be reachable both from CUCM and from the PSTN ingress gateway. Validate the network viability and QoS configuration to ensure that traffic is protected and passing among the relevant elements.
If the call comes in properly and the IVR gateway is reachable, but the IVR does not respond, some misconfiguration likely exists in the IVR gateway. Recall that the IVR gateway function is an H.323 gateway, at least in terms of the IVR application processing. Most likely, it is a dial peer configuration issue that has caused there to be no inbound dial peer match or multiple possible matches. In the case of multiple matches, the dial peer that ends up being selected may not be the one that includes the configuration which launches the IVR application process.
A dial peer process is based on inbound and outbound call legs. There is a specific hierarchy to dial peer selection for call routing. When a call comes in, a dial peer must be there to match for session routing to various applications. It is not solely a digit-by-digit analysis decision. The full digit string is used in matching. Inbound dial peer matching is done based on the following (in terms of highest precedence):
1. Called-party number (DNIS) with the incoming called-number command
2. Calling-party number (ANI) with the answer-address command
3. Calling-party number (ANI) with the destination-pattern command
4. Call ingress voice-port with the voice-port command
5. Default Dial Peer 0
The dial peer that is meant to launch the IVR application should have the incoming called-number. command in its configuration. This matches all inbound patterns and takes highest precedence in dial peer processing. If more than one dial peer has the incoming called-number command, it may be prudent to manually configure precedence on them to ensure that the application dial peer wins every time.
If a user is reporting that he or she is able to reach the IVR yet unable to authenticate, check that the user is using the correct PIN. If necessary, reset the PIN for the user. If the user is able to authenticate successfully and enter the destination number, yet the outbound call still fails, the culprit is most likely within the dial plan or gateway. Check the gateway for called number digit manipulation on inbound calls. Also, recall that media resources specifically for MVA are activated and registered. These require DNs. The gateway CSS must have access to the mobile voice access media resource DN partition; otherwise, calls will fail.
A somewhat less common possibility is that the Inbound CSS for Remote Destination Cisco CallManager Service parameter has been changed. This clusterwide setting takes precedence over the CSS configured at the gateway. Its default setting is Trunk or Gateway Inbound CSS. However, in some instances, it is beneficial to change it to Remote Destination Profile + Line Calling Search Space. This situation is atypical but can dramatically impact the call processing methodology and the troubleshooting methodologies employed.
Otherwise, outbound call routing for Mobile Voice Access calls always use the concatenated CSS for the Remote Destination Profile Line and the device. It is crucial that these calling search spaces provide the proper CoS to allow access to PSTN route patterns required by users making MVA calls.
Another aspect to consider is the calling-party presentation. One of the more desired capabilities of MVA is the capability to dial through the office and mask the actual number of the phone being used to place the call. The outbound must be presented with the office desk phone number as the calling-party number. If the External Number Mask parameter is used on the desk phone to change the DN to a PSTN format, remember to utilize the same mask for the shared line on the remote destination profile.
The remote destination profile is a virtual phone that represents all remote destinations. Its line configuration is used for outbound MVA calls rather than the line configuration of the actual desk phone. It is a common misconception to think that these act like other typical shared lines. The External Phone Number Mask does not propagate from the shared desk phone DN. If the digit manipulation configuration for outbound PSTN calls relies on the External Phone Number Mask, and it is not set at the remote destination profile line level, the internal DN is used as the calling-party number on outbound MVA calls.
Chapter Summary
Mobile Connect is, by far, one of the most popular features in CUCM. The capability to hide cell phone numbers and provide single number reach to users is in exceedingly high demand. More and more, company business cards publish only a single phone number, that of the desk phone. In the not-so-distant future, even that may disappear in favor of SIP URIs. When this change does occur, it will probably come with the same requirements for the features offered by MC. The capability to add or remove video mid-call, based on the capabilities of the endpoint in use for the call, is already built into CUCM, and has been for some time.
The capability to seamlessly move calls back and forth between the desk phone and cell phone has also become more of a standard feature in enterprise telephony deployments.
The configuration elements primarily focus around the remote destinations and remote destination profiles. These certainly require that user-specific aspects be configured as well as media resource needs. The most importance aspect is the configuration and use of the rerouting CSS of the remote destination profile. It may well be the biggest make-or-break parameter of the deployment.
MC calls can be enabled or disabled by either the user (if the Mobility softkey is on the On Hook context of the softkey template) or the administrator. Calls to remote destinations can be controlled by time of day or day of week, or based on permit/deny access lists based on calling-party number.
MVA offers enterprise telephony calling capabilities and features to remote users. It makes use of the combined CSS of the gateway or shared line and the remote destination profile for inbound calls to the IVR application and the MVA media resources. For outbound calls, it uses the concatenated calling search spaces of the shared line and remote destination profile.
Most of the issues involved in the Cisco Unified Mobility solution stem from CSS configurations providing the necessary route pattern access, ANI/Remote Destination mismatch (for calling-party presentation), and misunderstanding of the way calls are routed with each feature in play. Troubleshooting may well require validation of network, gateway, and CUCM configuration.
References
For additional information, refer to the following:
• Cisco Unified Mobility: Single Number Reach & Call flows
https://supportforums.cisco.com/document/93566/cisco-unified-mobility-single-number-reach-call-flows
• Configuring Single Number Reach (SNR)
Review Questions
Use these questions to review what you’ve learned in this chapter. The answers appear in Appendix A, “Answers to Chapter Review Questions.”
1. Which Cisco Unified Mobility feature provides the Single Number Reach (SNR) functionality to authorized users?
a. Mobile Connect
b. Mobile Voice Access
c. Extension Mobility
d. DISA
2. The calling party number is known as which of the following?
a. ANI
b. DNIS
c. DNS
d. EM
3. The called party number is known as which of the following?
a. ANI
b. DNIS
c. DNS
d. EM
4. With Mobile Connect, what caller ID information is presented to the called party when a remote phone calls an internal directory number? Assume that the remote phone belongs to an internal user and has a remote destination profile.
a. DNIS
b. ANI
c. Internal Caller ID of the calling party’s associated desk phone
d. Caller ID of the mobile phone
5. VXML gateways used with Mobile Voice Access should be configured to use which protocol in processing MVA calls?
a. H.323
b. SIP
c. MGCP
d. SCCP
6. Which directory number should be configured on a remote destination profile?
a. The user’s cell phone number
b. Shared line with the user’s internal directory number
c. A newly created directory number which should be associated to the user
d. Any of the above, so long as the class of service allows calling
7. Which softkey must be added in order for users to take advantage of Mobile Connect features?
a. Transfer
b. Mobility
c. iDivert
d. Join
8. Which Service Parameter allows the system to recognize a user’s cell phone, when configured as a remote destination, and replace the calling party number information with that user’s internal directory number?
a. Enable Enterprise Feature Access
b. Mobile Voice Access Number
c. Matching Caller ID with Remote Destination
d. Single Number Reach Voicemail Policy
9. Which calling search space is most often the source of issues when using Mobile Connect features?
a. Line calling search space
b. Device calling search space
c. Rerouting calling search space
d. Subscribe calling search space
10. Which is the first criterion (highest precedence) against which incoming dial peers are matched?
a. Called Party Number with the incoming called-number command
b. Calling Party Number with the answer-address command
c. Calling Party Number with the destination-pattern command
d. Call Ingress Voice-Port with the voice-port command
e. Default Dial Peer 0