In the first blog dealing with Device Mobility feature, we looked at the major components that go into the configuration of this exciting feature. Now, let’s look at how the device pool parameters drive this feature to the phones when they roam from one physical location to the next.
Let’s see how the Physical location is tied to the IP Subnet. First you will create a DMI (Device Mobility Info) for each IP subnet that will be associated with one or more phones. The only restriction is that only one DMI can be associated with a device pool and you can only create one subnet routine per DMI. When creating the DMI and subnet, you can collect a range of subnets by using VLSM principals assuming the collection of subnets are in the same address range. Also, the device pool assignment is done on the Device Mobility Info configuration page and not on the device pool itself.
Next you create Physical location tags to represent all the different locations of all your sites. Airport codes work great with this configuration. The Physical location is just a tag that is referenced by a IP Phone registering to see if it is in the same physical location since the last registration attempt.
When a IP Phone registers, it first determines if device mobility is configured for the phone itself. Then it determines its current DMI based upon the IP address it received during the DHCP configuration. Next it will select a device pool based upon that DMI and then determine if the DMI based device pool is the same as its configured or sometimes called the Homed Device Pool. If they are the same, stop don’t collect $200 you are done no device mobility settings required.
If the Homed Device pool is different than the DMI selected device pool, then it pulls the Physical Location tag from both and determines if they are the same. If they are, again nothing is required to be done and the phone finishes registering.
If the Physical location is different, now it will apply the Roaming Sensitive settings of the DMI picked device pool to the IP Phone. Now again this is only done if those physical location tags are different which is the key to applying roaming sensitive settings.
If you review the last blog, you will notice that the roaming sensitive settings have nothing to do with call routing. For that we introduce the second half, called Device Mobility Settings. These settings are chosen if something called the ‘Device Mobility Group’ is the SAME. This is a little twist from the above discussion because roaming sensitive settings only took affect if the physical location was different. Here it’s the opposite. If the DMG is the same, then device mobility feature will apply the ‘Device Mobility Settings’ which basically dictate via class of service what gateway or gateways you will be using when dialing let’s say to the PSTN or public switch telephone network.
Normally, the only reason why you would choose to create different Device Mobility Groups would be to have the users use the same dialing behaviors that they are used to since they are coming from different countries. For instance, if the corporate office is in UK and a IT guy from the USA visits that corporate office, by having different DMG groups, the USA guy would simply dial the same way he/she normally dials as if they were still in the USA. It keeps their dial behavior the same, however, the down side is that they will potentially be using the WAN to go out the USA gateway when calling local numbers in the UK which is not desirable. Therefore, it is imperative that you configure Tail End Hop Off routing (TEHO) when setting this up.
So as a review, the IP Phone registers, a DMI is selected based upon its current subnet address, this selects a DMI device pool which is determined if it is the same as its Home Device Pool. If they are not the same, it checks the Physical location tag in Homed as well as DMI selected to determine if the Physical locations are the same. If not, the ‘Device Roaming sensitive settings’ are applied. Then lastly it checks to see if the DMG’s are the same. If so, it applies the ‘Device Mobility-Related’ setting which will change its class of service selection which will ultimately force all calls out the local gateway versus their homed gateway. The below diagram from the Cisco UC SRND guide illustrates the relationships discussed above.
Author: Joe Parlas