Extension Mobility and Device Mobility Do Not Move the Line CSS
Priya, a sales engineer, has extension 1123 at San Jose and an Extension Mobility device profile whose line CSS is SANJOSE-LINES. Her desk phone is in device pool SANJOSE-PHONES. She travels to Austin and logs into a lobby phone in device pool AUSTIN-PHONES (location AUSTIN, SRST reference AUSTIN-SRST). Device Mobility is enabled cluster-wide, with device mobility groups SANJOSE and AUSTIN and a roaming device pool AUSTIN-ROAMING. The lobby phone's IP address is in the Austin subnet, so CUCM applies the AUSTIN-ROAMING device pool when Priya is logged in. Priya dials 911 from the lobby phone, and the call is routed over the San Jose gateway; the PSAP calls back the San Jose main number instead of an Austin number. She then dials Austin local number 512-555-0199; the call also goes over the San Jose gateway, and the called party sees a 408 number. Internal extension dialing works normally. No route patterns or gateways are down.
1. Why do 911 and the local Austin call use the San Jose gateway even though Device Mobility applied the Austin roaming device pool?
Read the worked answer
The key distinction is which CSS governs which call. For a call originated from a line, CUCM uses the line CSS. Priya's line CSS comes from the Extension Mobility device profile, SANJOSE-LINES, and it contains San Jose PSTN partitions. Device Mobility changes the device's pool, which changes device-level settings such as the device CSS, location, region, and SRST reference. It does not rewrite the line CSS stored in the device profile. Therefore the 911 route pattern and the 9.1.5125550199 route pattern are both selected from SANJOSE-LINES and point at the San Jose gateway. The AUSTIN-ROAMING device pool may correctly change the location for call admission control and the SRST reference, but those settings do not override the line CSS used for digit analysis.
2. The PSAP callback reached San Jose security rather than an Austin number. What settings determine the emergency callback number, and how would you verify that Device Mobility actually applied?
Read the worked answer
The emergency callback number and emergency location are device-pool and device-level settings, not line-CSS settings. With Device Mobility, the roaming device pool should supply the Austin callback number and Austin ELIN or location. If the PSAP called San Jose, either the roaming device pool still contains the San Jose callback number, the callback number is overridden at the line or device level, or Device Mobility did not apply. To verify, check the phone's IP address against the device mobility group subnet list, confirm the device mobility mode on the phone and the cluster service parameter, and confirm that AUSTIN-ROAMING has the Austin ECBN/ELIN. Also check whether the line has a per-line emergency callback number that takes precedence. The gateway used for 911 and the callback number are separate problems and must be fixed independently.
3. What design change would make the Austin lobby phone route local calls and 911 correctly for any Extension Mobility user, without granting San Jose users Austin routing when they stay in San Jose?
Read the worked answer
Device Mobility alone cannot solve this, because the line CSS follows the user's device profile. Options are: (1) create site-specific device profiles and assign the appropriate profile when the user logs in, so the line CSS matches the site; (2) keep one profile but use line CSS partitions with site-specific 10-digit route patterns, so a call to 512-555-0199 matches the Austin pattern and a call to 408-555-1XXX matches the San Jose pattern; (3) for 911, use Emergency Responder with per-site ELINs and a 911 route pattern that is reachable from the line CSS, and ensure the ELIN is updated by device mobility. The first option is the cleanest for line CSS, but it requires operational discipline at login. The partition-order approach must be consistent on every CSS and must be tested for overlap with future site codes.