В большой организации всегда находятся пользователи, которым необходимо часто перемещаться из одного офиса в другой. Для связи этим людям очень пригодятся Cisco Unified IP Phone или Cisco IP Comunicator (softphone).
Вместе с тем, в связи с различным местоположением офисов возникают определённые следствия, например различия во времени, шлюзах, правил набора и т.д.

Device Mobiblity - решение, входящие в состав CUCM, которое позволяет автоматически перенастраивать endpoints в соответствии с их физическим местоположением.

Нюансы связанные с Roaming Devices

Конфигурация IP Phone включает в себя в том числе настройки, привязанные к местоположению этого телефона, т.е. изначально предполагается что местоположение телефона будет постоянным.

Если же телефон будет перемещаться из одного офиса в другой, некоторые его настройки уже будут неточными:

• Region - настройки кодеков могут оказаться неверными
• Location - Настройки Call Admission Control могут оказаться неправильными.
• Survivable Remote Site Telephony (SRST) reference - будет неработоспособна.
• Automated Alternate Routing (AAR) group - call redirection будет нерабочим.
• Calling Search Space (CSS) - будут использоваться непрвильные шлюзы.
• Media Resource Groups (MRGs) and Media Resource Group Lists (MRGLs) - будут использоваться неправильные медиа-ресурсы

Понятно, что для поддержки правильных значений, у CUCM должен быть механизм отслеживания физического местоположения Roaming Devices.

Device Mobility

Device Mobility позволяет успешно решать все эти вопросы. При этом телефон всё также регистрируется на CUCM, при этом делается коррекция настроек, специфичных для местоположения. При этом изменения местоположения определяется по IP-subnet в которой данный телефон оказался.
Таким образом, на телефоне сохраняются все настройки User-specific (номер, speed dials, call forward), а к местоположению адаптируются настройки location-specific/

Device Mobility поддерживает протоколы SCCP и SIP.
Когда телефон добавляется к сети, первое что оно получает - это IP адрес. Поскольку в каждом офисе используется своя IP подсеть, CUCM может определять Phone Location на основе IP адреса этого телефона. Далее, на основе Physical Location телефона, CUCM перенастраивает у телефона Site-specific settings.

Site-specific settings

Как уже было сказано, Device Mobility не "трогает" настроек User-pecific
Device Mobility может корректировать у телефона его Site-specific settings.
К этим настройкам можно отнести две категории настроек:

• Roaming-sensitive settings:
  - Date/Time Group
  - Region
  - Locatin
  - Network locale
  - SRST Reference
  - MRGL
  - Physical Location
  - Device Mobility Group
  - Local Route Group
• Device Mobility-related settings
  - Device Mobility CSS
  - AAR CSS
  - Calling Party Transformation CSS

Таким образом:
Roaming-sensitive settings - это установки Site-specific settings, не касающиеся Call Routing.
Device Mobility-related settings - имеют непосредственное отношение к маршрутизации, т.е. к Call Routing.

Device Mobility может применять только однуRoaming-sensitive settings, или обе Roaming-sensitive settings + Device Mobility-related settings

Device Mobility Configuration Elements

Device Mobility использует следующие конфигурационные элементы:

• Device Pool - определяет список общих характеристик для группы устройств. Device pool включает настройки, имеющие отношение только к Device или Locatin-oriented. К каждому устройству может быть ассоциирован только один Device Pool.
• Device Mobility info - определяет IP-subnet и ассоциирует её с одним или более Device pool. Также несколько Device Mobility info - могут быть ассоциированы с одним Device pool
• Physical Location - это метка (tag), которая присваивается одному или более Device pool. Определяет Roaming device внутри одной Physical Location или же между несколькими Physical Location.
• Device Mobility Group - то метка (tag), которая присваивается одному или более Device pool.

Взаимодействие Device Mobility Configuration Elements

Рассмотрим взаимодействие Mobility Configuration Elements на примере:

В данном примере мы рассмотрим организацию, у которой есть несколько офисов в Москве, Питере и Лондоне.
Для каждого офиса создана своя Device mobility info со своей IP-subnet
Каждая Device mobility info ассоциирована с соответствующим Device pool, причём MSK3_dmi ассоциирована одновременно с двумя Device pool

Пулы MSK1_dmi, MSK2_dmi, MSK3_dmi ассоциированы с общим MSK_pl, поскольку они находятся в одном городе и у них идентичные Roaming-sensitive settings (такие как Date/Time Group, SRST Reference, MRGL и т.д.)
Пул PTR1_dp входит в отдельный Physical location PTR_pl, поскольку это другой город.
Пулы Москвы и Питера ассоциированы с общим Device mobility group Russia_dmg, поскольку все они из одной страны, и следовательно настройки Call Routing у них идентичны.

Таким образом, зная IP-subnet, Cisco Call Manager CUCM может определить соответствующий ему Device pool, а также Physical location и Device mobility group.

Device Mobility Operation

Если телефон, для которого включена Device Mobility, регистрируется на CUCM и получает IP-address из подсети, настроенной в Device Mobility info, происходят следующие события:

• Выбирается current device pool
  - Если Device Mobility info ассоциирована с Home Device pool, считается что телефон находится в home location, и Device Mobility не производит никаких действий.
  - Если Device Mobility info ассоциирована с другим Device pool, считается что телефон "на выезде" и текущим берётся этот Device pool.
• Если current device pool отличен от Home Device pool, проводятся следующие проверки:
  - Если Phisical locations не отличаются, конфигурация телефона не модиицируется
  - Если Phisical locations различны, осуществляется применение roaming-sensitive parameters.
  - Если current device pool и Home Device pool находятся в одной и той же Device Mobility Groups, осуществляет применение Mobility-related settings

Обратите внимаение, что roaming-sensitive parameters применяются если Phisical locations различны.
А Mobility-related settings применяются если current device pool и Home Device pool находятся в одной и той же Device Mobility Groups.

Изобразим все эти операции в виде схемы:

Таким образом, Phisical locations и Device Mobility Groups могут применяться в следующем виде:

• Phisical locations - Device pool-ы с такой меткой обладают одинаковыми Roaming-sensitive settings: SRST references, MRGL, использование кодеков, CAC и т.д. - т.е. эти параметры непосредственно отражают свойства местоположения. В зависимости от особенностей сети, Phisical location может соответствовать зданию, группе зданий или целому городу. Обычно в разных офисах разные Phisical locations, но в одном офисе могут быть несколько IP подсетей и в этом случае Phisical location будет та же.
• Device Mobility Groups - данная метка должна определять сайты с аналогичными dialing patterns. Это достигается применением от Current Device pool параметров: Device CSS, AAR Group, AAR CSS т.е. Device Mobility related settings оказывают влияние на то, как будет осуществляться Call Routing в том месте, куда приехал телефон.. В зависимости от размера сети, Device Mobility Groups могут представлять страны или области.

Касательно Device Mobility Groups надо понимать, что при изменении Call Routing меняется и Gateway и numbering plans.
Это означает что выход в межгород будет производиться совершенно по другому и к этому пользователь может оказаться не готов.
Возьмём к примеру некий номер Австрии в формате E.164: +43 699 18900009
Для звонка в Австрию из Германии нужно набрать: 0.00 43 699 18900009.
А из Российского офиса нужно набрать: 9.810 43 699 18900009
Поэтому ещё не известно что лучше. Для отключения применения Device Mobility related settings - нужно поместить соответствующие Device pools этих офисов в разные Device Mobility Groups.

Впрочем подобные проблемы легко решаются введением Globalized Call Routing, а также TEHO.
Globalized Call Routing описывается в Вопросы правильного построения диалплана (dialplan) в крупной организации

Device Mobiblity и CSS

Вообще в свойствах IP Phone могут быть настроены Line CSS и Device CSS.
В самой простой настройке рекомендуется настраивать только Device CSS, а Line CSS оставлять пустным.

Использование одновременно 2-х CSS позволяет помимо маршрутизации собственно звонка, также применить и Calling Priviliges.
При этом в маршрутизации исходящего звонка сначала применяется Line CSS, а затем Device CSS.
В этом случае:

• Line CSS используется для применения Calling Priviliges или Class Of Service (CoS): на линию вешается определённая Line CSS, которая включает в себя соответствующую Partition, в которой размещены блокирующие Patterns. Таким образом обычно создаются несколько CSS для различных градаций доступа:
  - ACCESS_01_Internal_CSS
  - ACCESS_02_Local_CSS
  - ACCESS_03_Mobile_CSS
  - ACCESS_04_National_CSS
  - ACCESS_05_International_CSS
• Device CSS - используется чисто для маршрутизации. Т.е. она в себя включает Partition и далее Pattern, которые в итоге приводят на Local Gateway

Поскольку Line CSS более приоритетна чем Device CSS, вначале срабатывают необходимые блокирующие Patterns и только потом производится дальнейшая маршрутизация в соответствии с Device CSS.

Device Mobility может менять Device CSS и AAR CSS, но никогда не модифицирует Line CSS.
Таким образом, когда телефон переезжает в другой офис, при применении параметров Device Mobility будут модифицироваться только Device CSS и AAR CSS, а настройки касающиеся Class Of Service (CoS) останутся прежними.

Device Mobility и Globalized Call Routing

Как уже упоминалось Device Mobility применяется следующим образом:

• Roaming-sensitive settings - это настройки такие как: location, region, SRST reference, MRGL и т.д. Эти настройки применяются если телефон переехал в другую Physical Location.
• Device Mobility-related settings - это настройки такие как device CSS, AAR CSS, AAR Group. Эти настройки применяются как дополнение к Roaming-sensitive settings, и применяются в случае, если телефон переехал в другую Physical Location но остался в той же Mobility Group

Таким образом при переезде телефона у нас могут возникнуть две ситуации:
- либо для телефона будет использован Home gateway и Home Dial Rules т.е. все звонки наружу будут проводиться с использованием домашнего шлюза, что может быть не оптимально.
- либо будет применены Device Mobility-related settings и телефон будет использовать Gateway of the roaming site. Что также может оказаться не оптимально.

В случае использования Globalized Call Routing совместно Local Route Group все эти проблемы снимаются полностью.

При использовании Globalized Call Routing все на телефоне набранные номера нормализуются на уровне Line CSS --> ingress_from_Phones_*Town*_pt --> Translation Patterns, в итоге все набранные номера станут в Global format.
Для выбора Gateway используется device CSS, который в свою очередь ссылается на Local Route Group. Поскольку Local Route Groupe входит в состав Roaming Sensitive Setting, то при переезде у телефона по факту меняется Gateway. При этом пользователю не нужно "заморачиваться" на правила набора в новом месте, поскольку все набранные номера нормализуются, а затем локализуются непосредственно на шлюзах через использование Transformation CSS.

На схеме также отображена классическая реализация TEHO
Для всех доступны шаблоны номеров соответствующих городов в формате E.164, которые ведут на нужный шлюз.
В случае проблем со шлюзом звонок пойдет на локальный для телефона шлюз, благодаря использованию Standard Local Route Group.

AAR CSS и AAR Group могут быть одинаковыми для всех, поскольку сам AAR Number будет введен в формате E.164.

Таким образом, совместное использование Device Mobility и Globalized Call Routing позволяет пользователям при переезде нет нужды менять их home dial rules, а также использовать Local Gateways.
При использовании Globalized Call Routing для корректной реализации Device Mobility, больше не нужны Device Mobility Groups.