Решения Cisco Unified Communications приобретаются всё больший размах. Только один кластер CUCM поддерживает до 30 000 клиентов, но уже есть решения в которых участвует несколько сотен Call Agents, CUCM, CUCME, а также CUBE и SRST. А поскольку маршрутизация звонков между этими элементами осуществлялась только в виде статики, настройка диалплана получалась очень громоздкой.

Технологии Cisco Service Advertisement Framework (SAF) а также Call Control Discovery (CCD) дают возможность для Call Agents распространять их Call Routing Information в сети, а также загружать маршруты от других Call Agents из сети.
Таким образом, SAF и CCD применяются при разворачивании очень больших решений на основе Cisco Unified Comunications, и позволяют сильно упростить внедрение Dial Plan.

Большие сети и масштабируемость Диалплана

Как известно, для настройки совместной работы нескольких кластеров мы можем использовать Intercluster Trunk как с поддержкой H.323 gatekeeper так и без нее.

Без использования Cenralized Services (H.323 gatekeeper, SIP network services), конфигурация межкластерной связи возможно только при организации Full-Mesh, т.е. каждый Call Agent должен быть подключён отдельным транком к каждому. Также на каждом Call Agent должна быть соответствующая прописана маршрутизация. Понятно, что такая модель применима только небольшим по размеру структурам.

Использование модели Hub-and-spoke, подразумевает использование в качестве Cenralized Services H.323 Gatekeeper или SIP network service.
Это решение гораздо лучше масштабируется, тут нет необходимости настраивать Full-Mesh и ненадо настраивать маршрутизацию в каждой точке. Но здесь также присутствуют и свои минусы: single point of failure, а также необходимость настройки вручную самого централизованного сервиса.

Таким образом ни один из упомянутых методов не предоставляет динамический обмен Call-routing information между call-routing domains.

Вообще маршрутизация звонков по своей природе близка к маршрутизации IP пакетов - IP routing.
Как известно, в больших сетях масштабируемость IP routing достигается с помощью Dynamic Routing Protocols.
У каждого маршрутизатора имеются непосредственно подключённые к нему Local Networks. Dynamic Routing Protocols позволяет отдавать эти Local Networks другим, соседним маршрутизаторам, в результате чего все маршрутизаторы будут знать все доступные подсети а также путь к ним.

Аналогичный подход можно применить и к распространению Call-Routing Infomation: каждый Call Routing Domain будет отдавать локальные номера или диапазоны локальных номеров.

Начиная с версии CUCM 8 была реализованы технологии, позволяющие выполнять advertizing Call-Routing Infomation:
CCD (Call Control Discovery) - это сервис, позволяющий Call Agent отдавать локальные DN (Directory Number) и им соответствующие PSTN numbers в SAF-enabled network. Также CCD позволяет и принимать Call-routing information из сети SAF.

SAF (Service Advertisement Framework) - используется для распространения информации внутри SAF-enabled network.
SAF Forwarders взаимодействуют с CCD-enabled Call Agents (Он же SAF Client). SAF Forwarders обмениваются информацией друг с другом, благодаря чему SAF Clients получают Call-Routing Infomation, т.е. internal directory numbers и соответствующие им PSTN numbers.

SAF

SAF (Service Advertisement Framework) - это унифицированное масштабируемое решение, позволяющее устройствам в сети обмениваться информацией.
SAF может быть использована для Advertise и Learn информации для любого сервиса. CCD - это первое приложение Cisco, которое использует SAF.

Внутри сети SAF работают устройства SAF forwarders, они занимаются передачей и распространением полезной информации(SAF Service Information). SAF forwarders никак не обрабатывают SAF Service Information, - они лишь гарантируют надёжный обмен между SAF clients. SAF forwarders для передачи SAF Service Information используют протокол SAF Forwarding Protocol (SAF-FP).

SAF Forwarding Protocol (SAF-FP) использует технологию и функции EIGRP, включая Diffusing Update Algorithm, Authenticated Update и т.д. Но, несмотря на то, что SAF-FP очень похож на EIGRP, он работает независимо от IP протокола, т.е. SAF-FP работает уровнем выше, чем IP, EIGRP, BGP или OSPF.

SAF forwarders могут взаимодействовать с SAF clients.
Примерами SAF client являются CCD-enabled Call Agents(например CUCM, CUCME, SRST, CUBE).
SAF client может передавать SAF Service Information в сеть, или получать эту SAF Service Information из сети.
В нашем случае SAF Service Information это собственно Call-Routing Infomation.
SAF clients взаимодействуют с SAF forwarders с использованием протокола SAF Client Protocol (SAF-CP)

SAF client регистрируются в сеть, т.е. на SAF forwarder.
SAF client может Publish services (отдавать инфу) или Subscribe to services (принимать инфу).
SAF forwarder распространяют друг другу обновления, полученные от SAF clients, и передают их другим SAF clients, подписавшимся на информацию.

SAF Client Types

SAF forwarder всегда есть Cisco IOS Router.
Как уже говорилось, SAF forwarder не обрабатывают SAF Service Information - его задача предать информацию SAF Clients.
SAF Clients уже знает что делать с SAF Service Information.
Например SAF Client с сервисом CCD - это есть Call Agent(Call control device), который принимает и отсылает Call-routing information.

SAF Client различают двух типов:

• External SAF Client - SAF Client и SAF Forwarder располагаются на разных устройствах. Они используют для коммуникации SAF-CP. Примером CCD External SAF client является CUCM.
• Internal SAF Client - SAF Client и SAF Forwarder располагаются на одном и том же устройстве - Cisco IOS Router. Они используют для коммуникации внутренний API. Примеры CCD Internal SAF Clients: CUBE, SRST, CUCME, Cisco IOS Gateway.

SAF message Components

SAF message состоит из двух частей:

• SAF Header - заголовком пользуются в основном SAF forwarders. Заголовок определяет Service type (например CCD), а также включает информацию касающуюся SAF: metrics, loop detection info и т.д.
• SAF Service data - имеет отношение к SAF Client. SAF Service data включает IP адрес а также порт advertising SAF Client, а также собственно полезную информацию (client data).
  При использовании CCD в качестве Advertised Service client data представляет собой Directory Numbers, IP адрес Агента (Call Control Device), Signaling Protocol, PSTN Prefixes и т.д.

SAF Neighbors

SAF Forwarders могут быть neghbors как на 2-м уровне так и на 3-м.

На 2-м уровне может быть использовано:
- Multicast: Возможын динамический поиск соседей, и нет необходимости настраивать соседей вручную.
- Unicast: SAF Forwarders могут быть настроены на вручную введённых соседей
Такие соседи называются Adjacent SAF Neighbors

На-3-м уровне между девайсами возможны несколько IP-hops. Такие соседи называются Nonadjacent SAF Neighbors. Соседей необходимо настраивать вручную и динамический поиск соседей невозможен.

CCD

Call Control Discovery (CCD) - это функция Call Agent, позволяющая Call Agent отдавать Call Routing Infromation, т.е. локальные DN (Directory Number) и им соответствующие PSTN numbers, в SAF-enabled network. Также CCD позволяет и принимать Call-routing information из сети SAF.

Можно сказать, что SAF Client = CCD + Call Agent

Call-routing information состоит из следующих частей:

• Dial plan information: Включает внутренние Directory Numbers (DN) вместе с префиксами для Side codes (если таковые используются), IP адреса соответствующих этим номерам Call Agents, и signaling protocol который должен быть использован для связи с указанными Call Agents.
  Вся эта информация идет от Call Agents и распространяется по сети с использованием SAF, а затем принимается остальными Call Agents.
• Reachability information: Как только какой-нибудь Call Agents становится недоступным, эта информация немедленно передаётся в сеть.

Если необходима функция доступа до телефонов Backup через PSTN (по сути это аналог CFUR). Call Agents отдаёт не только внутренние DN-ы, но и им соответствующие номера PSTN. В этом случае PSTN номер передаётся как PSTN failover digit transformation rule, также называемое ToDID rule. ToDID rule описывает, какие манипуляции нужно произвести с внутренним DN, чтобы в итоге получить соответствующий номер PSTN failover.
ToDID rule состоит из следующих компоненотов:

• Number of digits to be stripped - означает количество цифр, которые будут сняты от исходного DN. Например если исходный DN 8-408-2ХХХ, нам сперва понадобится снять первые 8408, чтобы получить номер 2ХХХ. В этом случае число снятых цифр будет 4:
• Prefix to be added to internal number - Это вторая необходимая операция: чтобы получить полноценный номер PSTN, на нужно будет добавить справа дополнительные цифры: +1408555, чтобы итоговый номер был: +14085552ХХХ

В итоге ToDID rule для нашего примера будет таким: 4:+140855.

Таким образом, каждый Call Agent отдаёт локальные DN-ы, а также ToDID rule. Этого достаточно для того, чтобы можно было дозвониться от других Call Agent как при нормальной работе, так и при сбое и использовании Backup через PSTN.

CCD services в CUCM

CCD "живёт" в CUCM в двух видах: CCD advertising service и CCD requesting service

CCD advertising service настраивается с DN-ами (номерами), которые будут отдаваться (advertised).
В CUCM это настраивается через hosted DN ranges. Для каждого hosted DN range настраивается PSTN failover information, т.е. ToDID rule.
Также должны отдаваться и Signaling protocol и IP адреса Call Agents. Эта часть настраивается в Trunk, при этом сами IP адреса Call Agents определяются транком через device pool, с которым ассоциирован транк.
Trunk может быть двух видов SAF-enabled H.323 intercluster trunk (ICT) или SAF CCD SIP trunk.
CCD отдаёт call routes а также один или более IP адресов своих Call Agent.

CCD requesting service "умеет" подписываться (subscribe) на инфу call routing information, которую он (сервис) будет получать от своего SAF forwarder. Это позволяет получать маршруты извне, т.е. из SAF-enabled network.
Только один CCD requesting service может быть настроен на кластере CUCM, но к нему могут быть ассоциированы несколько транков разных видов (H.323 или SIP).

Здесь нужно понимать, что сам транк не используется для отдачи или принятия маршрутов - для этих целей применяются CCD и SAF. Trunk используется для определения IP адресов удалённых Call Ahents, а также поддерживаемых ими Signaling protocols.
Например если CCD requesting service ассоциирован только с транком типа H.323, то и получать он будет только маршруты доступные через H.323, но не через SIP.

Обработка полученных маршрутов в CCD CUCM

В CUCM у нас есть возможность настроить фильтр для полученных маршрутов, с помощью которого можно запретить машруты по следующим критериям:

• Learned pattern prefix - маршруты сверяются по префиксу, т.е. начиная с самого левой цифры.
• Learned pattern - полученный маршрут сверяется по его полной длине
• Remore Call control Identity - Каждый Call Agent имеет SAF client ID, по нему также можно фильтровать.
• Remote IP - блокируем маршрутна основе advertising IP address

Один и тот же Destination number может быть получен извне несколько раз, т.е. от нескольких Call Agents. Также он может быть получен одновременно через SIP и H.323. Если маршрут был learned multiple times, CUCM будет распределять нагрузку (load share) между несколькими источниками этого маршрута.

Все полученные маршруты помещаются в определённую настроенную партицию, соответственно у всех девайсов, кому нужен доступ, должен быть CSS с включенной этой партицией.

В случае, если маршрут перестаёт быть доступен по IP - включаются ToDID rules для этого маршрута. При этом звонок производится на трансформированный номер с использованием AAR CSS девайса-источника.
Обратите внимание, хотя в данном случае используется AAR CSS, PSTN backup for CCD не имеет никакого отношения к AAR, просто используется AAR CSS для данного девайса.
(Напомню, AAR (Automated Alternate Routing) используется в случае отказа CAC для звонка.)

CCD Operation

На рисунке приведён пример работы CCD.
У нас есть два офиса: центральный и филиал. В каждом настроены внутренние номера, а также внешние DID.
CUCM с каждой стороны начинают отдвать маршруты, сеть SAF распространяет эти маршруты. В результате каждый филиал усвоит указанные Learned Routes.

Звонок HQ -> Филиал

Посмотрим что получится если телефон в HQ набирает номер 4001.
Все полученные маршруты помещаются в определённую partition. Для успешного звонка CSS телефона-источника должна иметь доступ к этой партиции.
Итак, CUCM определяет что с набранным номером совпал с CCD-learned Pattern. В соответствии с полученным маршрутом, звонок должен быть направлен через SAF-enabled SIP trunk.
SAF-enabled SIP trunk создаётся динамически с Destination IP, который был получен через CCD (в нашем случае 192.168.1.11)

Сбой соединения в филиале

Рассмотрим ситуацию, когда произошёл разрыв соединения SAF client и SAF forwarder на территории филиала.
SAF forwarder филиала обнаруживает проблему по отсутствию keepalives от зарегистрированного SAF client. Затем он отсылает соответствующее update в SAF-enabled network.
Теперь все SAF forwarders "знают", что IP path до 4XXX в данный момент недоступен.
Все SAF forwarders передают это обновление на зарегистрированных SAF clients, и SAF clients помечают данный маршрут как unreachable.

Звонок HQ -> Филиал во время сбоя

Если во время сбоя телефон HQ наберёт 4001, CCD-learned pattern также будет фигурировать в таблице call-routing table кластера HQ.
Но IP path данного паттерна будет промаркирован как unreachable, следовательно в данном случае звонок не пойдет через SIP trunk.

Далее CUCM проверяет наличие правила ToDID, ассоциированного с CCD-learned pattern.В нашем случае ToDID rule следующее: 0:+1972555. Перед двоеточием у на "0", поэтому от исходного номера ничего не стрипится (strip), но добавляется префикс +1972555. В результате транформации номер будет +19725554001.
Далее номер матчится с соответствующим паттерном, который ведет звонок уже через линию PSTN.

При этом в качестве CSS для PSTN backup call используется AAR CSS того аппарата, с которого осуществляется звонок. Понятно, что этому CSS должны быть доступны соответствующие Route Pattern, Route List, Route Groupи и тд.

Также стоит отметить, что по умолчанию, в случае недоступности IP path более 48 часов, CCD-learned pattern удаляется полностью, в том числе вместе и с ToDID rule.