Cisco Unified Call Manager способен функционировать в крупных организациях, имеющих множество филиалов. Наиболее распространённая топология построения комплекса телефонии - централизованная. В централизованной топологии CUCM находится в центральном офисе и осуществляет управление всеми телефонами организации, в том числе и телефонами филиалов. Это удобная топология, поскольку под управлением единого кластера все функции работают без ограничений, имеется централизованное управление, логирование и администрирование.
Минус Централизованной топологии в том, что телефоны филиалов зависят от связи с центральным сервером. Чаще всего это каналы VPN поверх интернет соединений, которые обладают известной степенью надёжности. В результате в моменты пропадания связи телефоны будут "отваливаться".
Именно в этих случаях к нам на помощь приходит технология SRST.

Cisco Unified Survivable Site Telephony (SRST) - это служба, обеспечивающая сервис для телефонов в филиалах, в тех случаях когда связь с CUCM по каким-то причинам прервалась. По сравнению с сервисами CUCM, SRST конечно предлагает только ограниченные функции.
Система SRST функционирует на устройстве CIsco Multiservice Router: автоматически обнаруживает факт сбоя и затем использует технологию Simple Network-Enabled Auto Provision, с помощью которой происходит автоконфигурирование маршрутизатора, в результате которого тот уже сможет выполнять Call Processing для телефонов филиала. После восстановления связи с CUCM все телефоны автоматом "перескакивают" обратно на CUCM.

Существует несколько видов SRST:

• Cisco Unified SRST - обеспечивает сервис для телефонов SCCP. Максимально поддерживается 1500 IP телефонов (Cisco IOS 3945). Это самый простой и быстрый вид реализации SRST, хотя и обеспечивающий минимальное количество сервисов.
  Действительно, режим SRST-это аварийный режим, и значит "не надолго". Если на это короткое время достаточно лишь функций позвонить соседу, выйти в город или принять входящий звонок - это режим для вас.
  Конфигурация такого режима начинается со строки:

  call-manager-fallback

  Простота этого режима заключатся в том, что нам не нужно конфигурировать телефоны на SRST Gateway:
  Далее в этой статье в основном описывается именно этот режим.

• CUCME в режиме SRST - Как понятно из названия, это действительно полноценно настроенный CUCME.
  Чем же отличается CUCME в режиме SRST от "простого" CUCME?
  На самом деле в случае сбоя связи до CUCM телефоны вполне себе переключатся и на "простой" CUCME. Фокус в том, что при восстановлении связи с CUCM телефоны уже не вернутся обратно на CUCM. Таким образом CUCME в режиме SRST - это тот же CUCME только с функцией возвращения(re-register back ).
  Поскольку здесь уже используется CUCME, то в работе доступно гораздо больше сервисов для телефонов, такие как: Call Park, Presence, Cisco Extension Mobility, local voice-mail integrations. Максимально поддерживается 450 IP телефонов (Cisco IOS 3945).
  Итак, конфигурация CUCME в режиме SRST начинается с той же строки для CUCME:

  telephony-service
   srst mode auto-provision [none | all | dn]

  Вторая строка собственно включает режим SRST для CUCME, при это мы можем выбрать опции:
  - none. Очень похоже на режим call-manager-fallback: конфигурации телефонов "подсасываются", и создаются динамические ephone-dn, но не видна через show running-config. В дополнение есть возможность создания ручных ephone-dn.
  - all и dn. конфигурации телефонов "подсасываются" через SNAP и становятся видны через show running-config. Мы их можем редактировать, добавлять функции типа monitor/watch lines, blf configuration, intercom. Также мы можем сохранять этот конфиг через write. Понятно что после сохранения данный конфиг "перекроет" конфиг подсосанный через SNAP.

• Cisco Unified SIP SRST - обеспечивает сервис для телефонов SIP. Максимально поддерживается 1500 IP телефонов (Cisco IOS 3945).

Работа SRST: Normal Operation

Как уже говорилось, в штатном состоянии CUCM осуществляет поддержку всех телефонов, включая телефоны в филиалах, т.е. по факту телефоны регистрируются на центральном CUCM. При этом для связи обычно используются VPN каналы поверх WAN.

Работа SRST: Switchover Signaling

В случае, когда телефоны теряют связь с CUCM, они регистрируются на локальном Cisco Unified SRST Router.
SRST Router для телефона выступает как альтернатива основному Cisco Call Manager.

SRST Gateway обнаруживает что к нему регистрируются телефоны, запрашивает конфигурацию у этих телефонов, и затем сам себя конфигурирует, т.е. в конфигурации SRST изначально нет кокретных телефонов с их DN, MAC-адресами и тд. Для такого автоконфигурирования SRST Gateway использует технологию SNAP.
Во время переключения в режим SRST телефоны отображают сообщение, информирующее пользователя о том что произошла смена режима работы.
Вместе с тем телефон продолжает пытаться наладить связь и посылает keepalive messages на CUCM

Работа SRST: Call Flow after Switchover

При пропадании связи между телефонами филиала и CUCM происходит автоматическое переключение регистрации телефонов на локальный SRST Gateway. При этом сервис SRST обеспечивает обработку звонков с ограниченными функциями.

Как видно, как для звонков наружу, так и для звонков в центральный филиал SRST Router использует подключение по PSTN.

Работа SRST: Switchback

Как уже было сказано, IP телефоны в режиме SRST постоянно пытаются заново подключиться к CUCM.
По умолчанию попытки переподключиться выполняются каждые 120 секунд.
После восстановления связи телефоны регистрируются на центральном CUCM и служба SRST возвращается в режим Standby.

SRST Timing

Как уже упоминалось, в нормальном состоянии телефоны обмениваются с CUCM сообщениями TCP Keepalive.
По умолчанию они составляют 30 сек.

Чаще всего мы имеем дело с кластером CUCM, т.е. в группе Cisco Unified Communications Manager Group включено несколько серверов. Это означает, что при потере связи телефоны сперва будут перебирать все сервера CUCM в группе и только потом подключатся к сервису SRST.
Обращение к одному серверу в среднем занимает 1минуту.
Общее время переключения можно вычислить следующим образом:

• Произошёл сбой подключения WAN. Телефон выжидает в течение 3 неполученных TCP Keepalive от Primary CUCM. T=30+30+30=90c
• Обращение к Secondary CUCM. T = 90 + 60 = 150c
• Обращение к Tetriary CUCM. T = 150 + 60 = 210c
• Регистрация на сервисе SRST занимает 20сек. T = 210 + 20 = 230c

Таким образом:
При сбое связи, переключение на SRST займет 3 минуты, если у нас два сервера CUCM и 4 минуты если их 3.
При восстановлении связи, обратное переключение произойдёт в течение 120секунд или 2 минуты.

Значение TCP Keepalive можно поменять:
CUCM > System > Service Parameters > выбираем сервер, выбираем сервис Cisco Call Manager > Station and Backup Server KeepAlive Interval

SRST Versions

Версия сервиса SRST напрямую зависит от версии установленного на маршрутизаторе IOS-а.

Количество поддерживаемых телефонов зависит от железа маршрутизатора:

SRST и CFUR

Итак, мы рассмотрели службу SRST, как механизм, обеспечивающий функционирование телефонии для временно изолированного филиала. Но тут возникает следующая проблема: в случае отлючённого филиала , с точки зрения CUCM, все отключенные удалённые телефоны будут находиться в состоянии unregistered, следовательно, если пользователь в центральном офисе набирает внутренний номер филиала, звонок не состоится. Здесь нам приходит на помощь CFUR.

CFUR (Call Forward Unregistered) - функция, позволяющая дозваниваться до внутренних номеров филиала в случае проблем со связью. Call Forward Unregistered имеется в CUCM, свойствах DN, - по сути это альтернативный номер, куда осуществляется перевод звонка, в случае если данный телефон находится в состоянии unregistered.
CFUR (Call Forward Unregistered) работает подобно широко известной функции Call Forward No Answer.
В качестве номера мы можем вбить к примеру внешний номер PSTN данного филиала, или более сложный номер, включая добавочный, если в филиале присутствует IVR.

Есть одна небольшая проблема, связанная со CFUR: предположим, что отключится не филиал целиком, а только отдельно взятый телефон. Поскольку он будет в состоянии unregistered, при звонке на его номер активируется CFUR, которая перенаправит звонок через PSTN. Но звонок через PSTN упадёт всё на тот же незарегистрированный DN, и как следствие опять на CFUR - в результате мы получим петлю.
Здесь нам поможет параметр Max Forward Unregistered Hops to DN. Это число одновременных "переведённых" звонков по CFUR. Параметр не даст звонкам множиться в следствие петли.
CUCM > System > Service Parameters > выбираем сервер, выбираем сервис Cisco Call Manager > Max Forward Unregistered Hops to DN
По умолчанию значение параметра 0, что означает "выключено".
При активации CFUR, рекомендуется Max Forward Unregistered Hops to DN выставить на значение 2. Что позволит дозваниваться до абонента двум одновременным звонкам.