Chapter 12. Troubleshooting Cisco Extension Mobility Issues

Extension Mobility (EM) is an XML-based endpoint (phone, softphone/soft-client) authentication feature that enables users to roam between sites without having to take a device along with them. The user simply activates the EM service and logs in to any EM-enabled endpoint. When the user is logged in, his or her speed dials, settings, class of restriction (CoR), services, and other settings are downloaded to the endpoint, in essence, making that endpoint the user’s own. The EM feature enables multiple users to log in to a single phone so that individual users can access their own settings utilizing a shared device. This capability is beneficial to mobile workers who share workspaces, contact center agents, and so on. And this is the reason it’s also known as hot desking—that is, the capability to use the same device within a user group (the employees of an organization).

A number of issues are common with EM implementations. The process of troubleshooting requires a good understanding of the configuration components and methodology.

Chapter Objectives

Upon completing this chapter, you will be able to

• Describe the key concepts of Cisco Extension Mobility

• Describe common Cisco Extension Mobility–related issues and their causes

• Troubleshoot Cisco Extension Mobility login and logout issues

• Troubleshoot Cisco Extension Mobility call-routing issues

Cisco Extension Mobility Overview

Extension Mobility provides additional functionality for roaming users. The feature is enabled on a per-phone basis. Each phone is then subscribed to an application service residing within Cisco Unified Communications Manager (CUCM). Each user authorized for EM must have a device profile provisioned within CUCM specifically for EM. This mirrors the user’s desk phone(s) configuration. It uses the same settings, Calling Search Space (CSS), and so on. It also enables each user’s specific and/or custom settings, such as ring tones and speed dials, to be applied to the phone.

When a user is roaming, he or she presses the Services button on a Cisco IP Phone and then selects Extension Mobility. At that point, the user is prompted to log in. If CUCM is integrated with a Light Directory Access Protocol (LDAP) service, such as Active Directory (AD), the user uses the same credentials he or she uses to log in to any other enterprise application. If CUCM is not integrated to LDAP, the user will need to employ the credentials (User ID and PIN) configured in CUCM by the CUCM administrator.

Once a user is logged in, the phone undergoes a soft reset and applies the settings specified in the user’s device profile. Other device-specific parameters remain the same as what was previously configured on the phone. The configuration is somewhat flexible in terms of the default configuration of the device, the inactivity timeout, and other parameters.

The process of configuring and enabling EM is relatively simple. Design considerations need to be taken into account. You need to understand the parameters that are kept on the device just as much as the parameters that are applied to the device upon login of an EM user as well as the parameters required to enable the EM service on CUCM. One of the most common issues is simply entering the service URL incorrectly. The task list involved in configuring EM is as follows:

• Activate Required Services in Serviceability

• Configure EM Service Parameters

• Configure the EM Phone Service

• Create User Device Profiles

• Associate a Device Profile to the User

• Subscribe Phones to EM Service

Activate Required Services in Serviceability

A number of services are required for EM to function properly. They include the following:

• Cisco CallManager service

• Cisco Trivial File Transport Protocol (TFTP) service

• Cisco Extension Mobility service

The CallManager and TFTP services should already be running in the cluster because they are the baseline for the phone and other devices. The EM service may be a different story because it is not enabled as a course of standard practice. The EM service runs as an application using the Cisco Tomcat service as its foundation.

Open the CCMAdmin page and navigate to the Cisco Unified Serviceability Page. Click Tools > Service Activation and enable the Cisco Extension Mobility Service. Ensure that the Cisco CallManager and Cisco TFTP services are running. Check the boxes beside all three services, if they’re not already checked, and click Save. This step causes each selected service to go into Activated status. Figure 12-1 shows the Service Activation page in Serviceability.

Figure 12-1. Serviceability Service Activation Page

In Figure 12-1, the Cisco Extension Mobility service has been activated. Also, note that the Cisco CallManager and Cisco TFTP services are both activated. The EM service relies on the Cisco Extension Mobility service. However, it also relies on the Cisco Extension Mobility Application service, which is activated automatically on all nodes during installation. This service is visible in the utils service list command output in the command-line interface (CLI). It’s also visible in Serviceability under the CM Services section of Control Center – Network Services. The service can be stopped, started, or restarted from there. The Cisco Extension Mobility Application service provides an interface between the EM user phone and the Cisco Extension Mobility service. In addition, it subscribes to the change notification indicators within the cluster and maintains a list of nodes in the cluster that have an active Cisco Extension Mobility service.

Configure EM Service Parameters

The step to configure EM service parameters is optional. You can simply accept the default service settings. However, it is prudent to understand what each of the settings within the Service Parameter page can do and/or impact. In the CCMAdmin page, go to System > Service Parameters. Select the server in question and then choose the Cisco Extension Mobility service. The page presented is shown in Figure 12-2.

Figure 12-2. Cisco Extension Mobility Service Parameter Configuration Page

In Figure 12-2, all the parameters are left to their default settings. Note that the view you get upon loading this page may be a bit different. Notice the message, “There are hidden parameters in this group. Click on Advanced button to see hidden parameters” at the bottom of the page. Click the Advanced button at the top of the page to see all the available options. Table 12-1 provides an explanation of each parameter.

Table 12-1. Cisco Extension Mobility Service Parameters

As mentioned, altering these settings is entirely optional. However, they can have a significant impact on EM in both intracluster and EM cross cluster (EMCC) environments.

Configure the EM Phone Service

EM is invoked as a phone service. To access it, the Service or Applications button on the phone must be pressed. This button is typically imprinted with a gear or cog. The Extension Mobility application now appears in the list of options.

For it to appear, it must be configured as an IP phone service. Open the CCMAdmin page and go to Device > Device Settings > Phone Services. To add the EM service, click Add New. Figure 12-3 shows the IP Phone Services Configuration page.

Figure 12-3. IP Phone Services Configuration Page

In Figure 12-3, a number of fields are visible. The Service Name is arbitrary but should be something descriptive because it will show up on the phone when the Service/Applications button is pressed. The description should be similarly meaningful. The Service URL is vital! This is where most of the misconfiguration errors occur. The URL is as follows:

http://<IP Address of CUCM server>:8080/emapp/EMAppServlet?device=#DEVICENAME#

The IP address should be the address of the CUCM node running the Cisco Extension Mobility Service. The Service Category should be set to XML Service. The Service Type is typically set to Standard IP Phone, unless you choose to remap it to the Directories or Messages button. That is atypical, however.

You also can add numerous options to the service parameters in the service definition. This includes login information, passwords, and other potential components. One common change to the service URL is the addition of a parameter to enable a one button logout. This simple change can make a big difference in the user experience. The service URL should be altered as follows:

http://<IP Address>:8080/emapp/EMAppServlet?device=#DEVICENAME#&doLogout=true

For Extension Mobility Cross Cluster implementations, alter as follows:

http://<IP Address>:8080/emapp/EMAppServlet?device=#DEVICENAME#&EMCC=#EMCC#

The Service Parameter Information section of the service definition provides additional power in augmenting the user experience. For example, entries can be made for userid and seq (the user ID and PIN). Although this not necessarily recommended from a security standpoint, it does illustrate some of the available capabilities. When the EM service is invoked, the user ID and PIN are automatically sent for authentication. This assumes that the user ID and PIN are static and standard across all phones. Again, this is very insecure, a possibility. As a side note, you can make this change through the service URL. It would look like this:

http://<IP Address>:8080/emapp/EMAppServlet?device=#DEVICENAME#&userid=<userid>&seq=<userpin>

There is a great deal of power, and potential risk, within the capabilities of any IP phone service.

When the Services or Applications button is pressed, a call to the URL is made. An HTTP/XML call is generated to the IP phone services, which returns a list of available services to the phone—those services to which it is subscribed.

When the EM service is selected, an HTTP call to the EM service is generated. This serves as the interface between the phone and the service. Figure 12-4 shows the message flow for EM.

Figure 12-4. Cisco EM Message Flow

The EM application service forwards an XML response back to the phone requesting the user’s login credentials. If the user is already logged in, he or she is prompted with an option to log out. If the user is logging in, the user ID and PIN must be entered. The response is forwarded to the EM application service. That information is then forwarded to the EM service that interacts with the CUCM database to verify the user’s credentials. The EM application service maintains a list of all nodes in the cluster running the EM service. So, the credentials are forwarded to all nodes running the EM service.

Upon verification of the credentials, the EM service reads the device profile info from the CUCM database and selects the relevant information to be written to the phone based on the user’s device profile settings.

Two types of configuration parameters can be dynamically configured when logging in to EM. They are user-specific device parameters and complete configuration parameters.

The complete configuration parameters include

• Directory numbers

• Feature buttons

• Speed dials

• Busy lamp field buttons (BLF)

The user-specific device parameters include

• User music on hold audio source

• Phone button template

• Softkey template

• User locale

• DND and privacy settings

• Phone service subscriptions

After these changes are made, the EM service sends a successful response to the EM application service, which sends a reset message to the phone to apply the new configuration.

Create User Device Profiles

The EM device profile acts as a virtual device that maps to a physical device when a user logs in to the EM service. The physical device takes on the attributes of the virtual device. The device profile needs to be created specifically to match the phone to be utilized by the roaming user. The device profile includes information found at the device level of an IP phone. So, device profiles need to be configured both on a per-user basis and a per-phone-type basis. This means that a profile needs to exist for each type of phone that the roaming user can potentially use. The more diverse the mix of endpoints used by the roaming user community, the more specific device profiles must be per user. If a user needs to be able to log in to a 7965, 8865, and 9971, a device profile for each phone model must be created.

Each phone must have its default device profile. This is known as the logged-out profile. A default configuration is created for the device to use when no user is logged in to the phone. When a user logs in, the default profile is replaced. When the user logs out, the default profile is returned.

To create the profile, open CCMAdmin and go to Device > Device Settings > Device Profile. Click Add New. Select the type of phone to be used by the roaming users. Provide a name for the profile. Take care in naming the profiles. These names will be user specific. So, it is often desirable to use a name that includes the username itself, such as dp-username-phonetype or similar. For example, use dp-jdoe-8861 for John Doe’s 8861 device profile. Figure 12-5 shows the Device Profile Configuration page.

Figure 12-5. Device Profile Configuration Page

In Figure 12-5, the device profile page is quite different from the device page on a typical endpoint. The number of configurable options is greatly reduced. Items such as CSS, automated alternate routing (AAR) groups, and so on are not available in the device profile. Those items remain configured as they are specified on the physical device. Figure 12-5 showed a new device profile being configured. Upon being saved, it becomes more like a typical phone configuration; it has line appearances and so on added. This is shown in Figure 12-6.

Figure 12-6. Device Profile Configuration Page with Line Associations

The line should be configured as a shared line appearance with the user’s desk phone. This gives it the line calling search space and other parameters specific to that particular user.

In addition to user-specific profiles, you need a default device profile for each device type that will have EM enabled. To create the default device profile, open CCMAdmin and go to Device > Device Settings > Default Device Profile. Figure 12-7 shows the Default Device Profile Configuration page.

Figure 12-7. Default Device Profile Configuration Page

In Figure 12-7, notice that there are no line-specific parameters as there were with the device profile. The default device profile merely serves to provide settings for those parameters that are replaced by the device profile when an EM user logs in.

One last configuration detail with the device profile is often missed. It is the subscribing of the device profile to the EM service. The steps for doing so are identical to the steps for subscribing a phone to the service.

Associate a Device Profile to the User

With the user and default device profiles created, the next step is to associate the user and the device profile. This is performed via the user page under User Management > End User. Select the user to whom the profile should be associated and add it to the Extension Mobility section. Figure 12-8 shows the End User Configuration page.

Figure 12-8. End User Configuration Page

In Figure 12-8, the device profile that was just created has been moved from the Available Profiles box into the Controlled Profiles box in the Extension Mobility section of the End User Configuration page. Also, be sure to check the Home Cluster box and Enable Extension Mobility Cross Cluster. Click Save.

If a user logs in to differing phone types throughout the network, a device profile per phone type is necessary. This ensures that the correct settings are applied per device. When logging in, the user is prompted to select the EM profile to be used for the phone.

Subscribe Phones to EM Service

To configure the physical phone, you complete two steps. The first is enabling Extension Mobility. This is performed with a check box and the selection of a Log Out Profile. Figure 12-9 shows the Phone Configuration page with the check box for EM checked.

Figure 12-9. Phone Configuration Page

In Figure 12-9, the check box is ticked, and the device is set to Use Current Device Settings when logged out. If desired, you can create a profile specifically to be used when a user is logged out. This is not unusual in many environments where the phones are configured to be able to dial only emergency services (911, 999, and so on) when logged out.

The second aspect that must be configured on the phone is the subscription to the EM service. The service was created earlier in this chapter. However, it does not show up in the list of available services until the subscription is complete. Click the Related Links drop-down field in the top-right corner of the phone’s device page. Figure 12-10 shows the drop-down box in question.

Figure 12-10. Phone Configuration Page for Subscribe/Unsubscribe Services

In Figure 12-10, the Subscribe/Unsubscribe Services option is selected. Click it, and then click Go. A pop-up screen appears where the service can be selected. Select the desired service and then click Next. Figure 12-11 shows the Subscribe pop-up screen.

Figure 12-11. Service Subscription Configuration Page

After you click Next, the screen changes to that shown in Figure 12-12. If you want to change the default name of the service, do so here. Then click Subscribe.

Figure 12-12. Service Subscription Configuration Page, Continued

You then will see the message “Add Successful.” You can close the window or subscribe additional services for the phone. The EM service should now appear in the list of subscribed services in the pop-up window.

One last important step is to subscribe the user device profile to the EM service, if not already done. If this step is not completed, the user will not be presented with an option to access the EM service. Therefore, there will be no option to log out.

After you save these settings, any changes made to the service URL, service parameters, or other fields in the service definition for an IP phone service to which phones are subscribed require the subscriptions to be updated. There is a button just for this purpose on the IP Phone Services Configuration page. Figure 12-13 shows the IP Phone Service Configuration Page for the EM service created.

Figure 12-13. IP Phone Services Configuration Page

The box in Figure 12-13 provides emphasis for the Update Subscriptions button. Use this button to update all subscribed phones’ service information. The only other way the subscribed phones will get the updated information is to be unsubscribed and resubscribed to the service. Depending on the number of subscribed phones, the process of updating the subscriptions may take hours. In large deployments, Cisco recommends that IP phone services not be run on the publisher, TFTP server, or any call control node in the cluster. This way, you avoid the potential for a misconfiguration or other IP phone service–related issue impacting call control processes in the cluster.

For additional security, Cisco added EM support for the use of Secure HTTP (HTTPS) in CUCM 8.6 and higher. This allows for encrypted communications between the IP phone service and other applications. The user experience is no different from a login/logout perspective. The only real difference is that when the login is successful, the communication protocol used by the IP phone service changes to HTTPS.

Overview of Cisco Extension Mobility Issues

The most common EM-related issues fall into the following categories:

• Login/Logout Issues

• Phone Button Issues

• Phone Service Issues

• Call-Routing Issues

• Calling-Privilege Issues

These issues are not always straightforward in terms of troubleshooting. The following sections examine each situation and offer potential resolutions.

Login/Logout Issues

Login/logout issues can stem from something as mundane as a user entering invalid credentials or relate to more complex issues surrounding the EM service availability. If a user is already logged in to a phone, and no logout option has been configured, the administrator may need to force a logout from the CCMAdmin page. The configuration of the service can make or break the user experience. You should take care to add the ability to log out a phone from the service.

Luckily, when a user attempts a login and is unsuccessful, error codes are generated. These codes are displayed on the phone’s screen. Table 12-2 details the more common error codes and messages along with the action recommended in resolving each.

Table 12-2. Cisco EM Error Messages

Figure 12-14 breaks down some of the more common login issues.

Figure 12-14. Troubleshooting EM Login

Logging in to EM is a relatively simple process. If a user presses the Services button only to see that he or she has no EM service available, the phone needs to be subscribed to the service. If the service is there but is unavailable, the issue may stem from the phone-device or the logout-device profile in use by the phone. The profile in use by the phone is specified on the device page of the phone configuration in CCMAdmin, under Device > Phone. A section within the device page is called Extension Information. In it is a check box to enable Extension Mobility on the device. Of course, this option must be checked if the phone is to be usable by EM users. Second is the specification of a Log Out Profile. The Log Out Profile defines the phone’s characteristics when no EM user is actively using it. The default is for the phone to “Use Current Device Settings.” The phone should act as configured in the device page itself rather than any particular device profile. Figure 12-15 shows this part of the phone’s device page.

Figure 12-15. Enabling EM on the Phone Configuration Page

Alternatively, you can create a device profile with specific dialing permissions. This is often used in EM environments to limit the class of restriction of the device when it is not in use and/or unattended. Typically, a Log Out profile restricts the phone to only internal dialing and emergency calling (for example, 911, 999, 119, depending on geography). Often, the phone is not even permitted to dial internally. That decision is made based on the organization’s business needs.

Upon successful launch of the EM application on the phone, the user must authenticate. Authentication errors are typically associated with incorrectly entering the username and PIN. If the PIN is verified as being entered correctly, another permission issue may exist.

The first thing to check is the check box on the device page to enable EM. The phone can be subscribed to the service without that box being checked. However, it will not be able to utilize the service without it. If you have a large number of phones that need to be enabled for EM, use the Update Phones function within the Bulk Administration Tool (BAT).

If the user still cannot log in, check the user’s associated device profile. First, make sure a device profile exists and is associated with that user. Second, check that the device profile was created using the same phone model as the phone into which the user is trying to log in. Remember, device profiles are device-type specific.

Another potential issue related to authentication is that, by default, EM users are allowed to log in to only one device at a time. This setting is configurable in the Extension Mobility Service Parameters, as shown in Figure 12-16.

Figure 12-16. EM Service Parameter Configuration Page

In Figure 12-16, the parameter in question is the Intra-cluster Multiple Login Behavior parameter. By default, it is set to Multiple Logins Not Allowed. Use the drop-down box to change it to Multiple Logins Allowed or Auto Logout. Allowing multiple logins permits a user to be logged in to multiple devices simultaneously. The Auto Logout setting retains the single device login behavior and automatically logs the user out of the other device when he or she tries to log in to a new one. For purposes of troubleshooting, either will fix the issue. For EM cross-cluster, multiple login is always allowed.

After a successful login, the phone restarts to apply the updated configuration. If the locale specified in the user’s device profile differs from that of the phone, the phone will restart on successful login and then reset due to the need to apply a rebuilt configuration file with altered locale information. It is an excellent idea to ensure that locales match across user, phone, and device profile configurations.

Logging out of EM is a similar process to that of logging in. The user presses the Services button and selects the EM service. However, at times, the service may not be available or may not offer a logout option. This occurs when the device profile to which the user is associated has not been subscribed to the EM service. The device profile, for all intents and purposes, is a phone. When it is overriding the base configuration of the phone, it has to have access to the same services as the underlying device if the user wants to use them. In CCMAdmin, go to Device > Device Settings > Device Profile, select the user’s device profile, and subscribe it to the EM service.

As was the case at login, the phone restarts upon successful logout. Additionally, the locale condition remains. So, if there is a mismatch, the phone restarts and then resets to apply the rebuilt configuration file.

Phone Button Issues

After a user gets logged in to a phone, the phone button layout is assigned by the configuration specified in the device profile. If the model of the phone being logged in to differs from that against which the device profile was configured, there may well be issues in features, lines, buttons, services, and so on being where they are supposed to be.

Although it is possible to configure a generic device profile that allows a high degree of phone model independence, some differences may not necessarily be overcome, depending on the diversity of phone models in use. The variables involved make this more difficult, in terms of maintaining model independence. Softkey templates, phone button templates, feature control templates, common device profiles, and so on can all contribute to things not being where, or acting, as they should. As of CUCM 7.0, EM was enhanced to provide the Feature Safe model equivalency. Phones can use any phone button template that has the same number of line buttons as the physical phone supports. All individual phone models within a given phone model family (for example, 7800 series, 8800 series) are equivalent and can share an EM profile. There are obvious exceptions, such as the 8831, in the case of the 8800 series.

To avoid these conflicts, you should create a user device profile for each model the user needs to be able to utilize.

Phone Service Issues

A user wishing to log in to a phone will press the phone’s Services button. When that happens, a number of things occur. The first thing that should be verified in any troubleshooting effort is that the Cisco EM Service is activated and running in the Cisco Unified Serviceability page.

When the Services button is pressed or menu accessed, the services to which the phone is subscribed are accessed and listed on the screen. Then, assuming the EM service is there, it is selected. If the EM service is not on the list, that is the first problem to chase. Ensure that the service subscription is in place both on the phone and the user’s device profile.

If the service is listed but is inaccessible, the most common error comes down to the entry of the service URL in the service configuration. There are numerous potential opportunities for such errors to occur. Refer to the “Configure EM Service Parameters” section earlier in this chapter. A number of options for entering the URL are provided. The most basic version of the URL is as follows:

http://<IP Address>:8080/emapp/EMAppServlet?device=#DEVICENAME#

If the URL is typed manually, there is some chance of a typographical error. Be sure to double-check that it is entered properly in the service definition.

Any changes to the server definition require that the subscription be updated for the phones already subscribed. Luckily, there is a button provided for just that purpose.

The safest manner of entry for any service entails using its IP address. However, there is a reliance on DNS to provide a wider, more flexible array of service possibilities. Using the IP address rather than the fully qualified domain name (FQDN) is a safer route in terms of the EM service. This precludes any issues concerning name resolution.

However, if the URL is entered using the FQDN of the CUCM node running the EM service, there is a possibility that its name simply cannot be resolved by DNS. Double-check the name resolution using a tool such as ping or nslookup. From a command prompt on a Windows or Mac machine, enter the nslookup command along with the FQDN of the CUCM node in question, usually the publisher. Example 12-1 shows how this might look.

Example 12-1. Verifying CUCM Name Resolution

---

C:> ping cucmpub.mydomain.com

Pinging cucmpub.mydomain.com [172.16.100.1] with 32 bytes of data:
Reply from 172.16.100.1: bytes=32 time<1ms TTL=63
Reply from 172.16.100.1: bytes=32 time<1ms TTL=63
Reply from 172.16.100.1: bytes=32 time<1ms TTL=63
Reply from 172.16.100.1: bytes=32 time<1ms TTL=63

Ping statistics for 172.16.100.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:>
C:> nslookup cucmpub.mydomain.com
Server:  winpdc.mydomain.com
Address:  172.16.100.10

Non-authoritative answer:
Name:    cucmpub.mydomain.com
Addresses:  172.16.100.1
C:>

---

Call-Routing Issues

Extension Mobility, within a cluster, presents an interesting set of potential issues in terms of call routing. You are taking a physical device with its own line configuration and overwriting much of that configuration with a logical device and line configuration. There is certainly ample opportunity for error. Class of service (CoS) can be easily broken when logging in to a device either because it was misconfigured for the user or the policies are simply broken from the outset. Destinations permitted from a user’s home device may suddenly be denied upon logging in to an EM profile. The reverse is also true. A previously denied destination may suddenly be permitted. The question of which is worse depends on the dialed destination number and the user involved.

With EM, the device CSS is not altered. Only the line CSS is updated based on the information contained in the EM device profile. When using a traditional CSS model with EM, the device keeps its original settings, which may not address all CoS permission levels across all sites. Instead, the device CSS addresses only the dialing habits of the local site. Users who roam internationally from the United States to Europe, for example, may suddenly find that they can dial 900 numbers from offices in Europe even though the same numbers were denied when dialed from the US office. In the United States, 900 numbers are typically associated with costly per-minute services, which tend to be career-limiting when dialed from the office. As such, those numbers are typically blocked entirely from being dialed by anyone within the company, regardless of other calling privileges.

In European offices, dialing 1-900-XXX-XXXX number patterns is not likely because that format isn’t consistent with dialing patterns in Europe. So, it may be a match to a +1 general route pattern and be routed, unintentionally allowing access to an otherwise blocked pattern. This is generally seen as a design flaw in the dial plan. For this, it is recommended that you utilize a Line/Device dial planning methodology. In this model, the line CSS includes only the CoS that relates to the particular user (that is, explicit denials). In other words, the Line/Device methodology has a block for 900 numbers in the line CSS, thus blocking those numbers from being dialed by the user regardless of where he or she may roam.

Calling Privilege Issues

When a user logs in to an EM-enabled phone, the device level configuration is not altered. Only the line characteristics are applied. So, it is important to keep in mind that Cisco EM does not modify the device CSS or the AAR CSS. It modifies only the line CSS. Once again, the idea is to drive the point home and keep it firmly in your mind regarding what is and is not modified. This understanding is key to troubleshooting.

When a user logs in to a phone, the Line CSS is the only thing that enables you to maintain the desired CoS for where the user can or cannot dial. The fact that the device level settings do not change means that the outbound gateways used for external route patterns remain in place for the phone, just the same as if the user had not logged in. This includes the local route group specified in the Device Pool settings. So, you might need to consider dialing behaviors, especially if a user has roamed internationally. The PSTN route patterns and partitions are typically specified in the device CSS when using a local route group configuration for dial planning. If a more traditional dial plan is in use, there may be issues associated with dialing and gateway selection when a user logs in to a phone in another site.

It is quite common, in traditional dial planning, for the device-level CSS to be the only one in use. This means that it not only is involved in gateway selection but also is involved in CoS restrictions. The result of this is that no user-specific privileges can be applied when an EM user logs in because the line CSS is not in use and the device CSS is not touched on EM login. This can easily result in suboptimal call routing due to incorrect gateway selection.

Chapter Summary

Extension Mobility is one of the most utilized features available in terms of the volume of users configured for it. The configuration is relatively straightforward. Yet, it is not without its potential pitfalls. It allows users to roam throughout the network while maintaining their class of service, speed dials, and other nuances of the individual user configuration.

The most common issues that arise are service related. Most often, the Cisco EM Service hasn’t been activated and started, the phone hasn’t been subscribed to the service, the service is misconfigured (typo in the URL), the user is experiencing login/logout-related challenges, or a dial plan issue is in play. That seems a rather short list, but we now know there is a great deal of technology behind it that must all be in order.

When troubleshooting call routing or call privilege issues, keep it simple. Use the dialed number analyzer. Evaluate the dial plan. Is the Line/Device dial plan in use? Is gateway selection done only at the Device CSS level? Remember that the Line CSS is the only one replaced when a user logs in to an EM phone. PSTN route patterns available to the Line CSS will be used, regardless of what is in the Device CSS. Review Chapter 8, “Troubleshooting Call Routing,” and have the Line/Device dial planning concepts in mind when you start looking into dialing-related problems.

References

• Feature and Service Guide

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/10_0_1/ccmfeat/CUCM_BK_F3AC1C0F_00_cucm-features-services-guide-100/CUCM_BK_F3AC1C0F_00_cucm-features-services-guide-100_chapter_011000.html

• Administration Guide for CUCM

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/11_5_1_SU1/Administration/cucm_b_administration-guide-1151su1.html

• Extension Mobility Walkthrough Cisco Support Community

https://supportforums.cisco.com/document/12210496/configuring-extension-mobility-cucm-10x

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 service(s) must be activated on CUCM for Extension Mobility to function properly? (Choose three.)

a. Cisco TFTP

b. Cisco CallManager

c. Cisco Extension Mobility

d. Cisco Extended Functions

2. From the CUCM CLI, which command shows the status of services?

a. utils service status

b. utils service list

c. show service status

d. show service list

3. By default, how many IP phones may a user log in to using Extension Mobility?

a. One

b. Two

c. Three

d. Four

4. Which of the following protocols are used by the Extension Mobility service? (Choose two.)

a. HTTP/HTTPS

b. XML

c. AXL

d. CTI

5. For a user to log in to an Extension Mobility–enabled device, what must first be configured?

a. User Device Profile

b. Logged Out Profile

c. Softkey Template

d. Phone Button Template

6. If a user cannot log in to the EM service, which should be checked or verified?

a. IP Phone Device Template

b. IP Phone EM Service Subscription

c. IP Phone AAR Configuration

d. IP Phone DN

7. Assuming the EM service is properly configured and the phone subscribed to the EM service, which of the following would cause an error when a user attempts to log in?

a. IP phone model different than that of the user’s device profile

b. DN misconfiguration

c. Calling Search Space issues

d. Incorrect softkey template

8. A device profile has been created for a user, but the user is still unable to log in to the EM service successfully. Which is a possible cause?

a. The device profile has not been associated with the user in the End User Configuration page.

b. The user has not been subscribed to the EM service.

c. The class of service is incorrectly configured.

d. The EM Service URL is incorrectly configured.

9. To enable an IP phone to use the EM service, which of the following configurations must be in place? (Choose two.)

a. Subscribe the IP phone to the EM service.

b. Check the Enable Extension Mobility box on the IP phone’s device page.

c. Configure an EM calling search space.

d. Reset the user’s PIN.

10. When a user logs in to an EM phone, which of the following is true regarding calling privileges?

a. The phone’s line and device calling search spaces are replaced.

b. The phone’s line calling search space is replaced, but the device calling search space is unaltered.

c. The phone’s line calling search space is unaltered, but the device calling search space is replaced.

d. Neither the line nor the device calling search spaces are altered.