Cisco Meeting Server 2.5.2. Cluster в режиме Scalable and Resilient с функцией записи видеоконференций

В этом выпуске я покажу и объясню некоторые тонкости настройки CMS сервера в режиме отказоустойчивого кластера.


ТеорияВообще существует три типа развёртывания CMS сервера:

• Single Combined(Единый комбинированный), т.е. это один сервер, на котором запущены все необходимые сервисы. В большинстве случаев этот тип развертывания применим только для доступа внутренних клиентов и в небольших средах, где ограничения масштабируемости и избыточности одного сервера не являются критической проблемой, или в ситуациях, когда CMS выполняет только определенные функции, такие как специальные конференции на Cisco UCM.

  Примерная схема работы:
  

• Single Split(Единый разделённый) расширяет предыдущий тип развёртывания, добавляя отдельный сервер для внешнего доступа. В устаревших развертываниях это означало развертывание сервера CMS в демилитаризованном сегменте сети(DMZ), где внешние клиенты могли бы получить к нему доступ, и одного сервера CMS в ядре сети, где получают доступ к CMS внутренние клиенты. Эта конкретная модель развертывания теперь вытесняется так называемым типом Single Edge, который состоит из серверов Cisco Expressway, которые либо имеют, либо будут иметь многие из возможностей обхода Firewall’a, поэтому клиентам не нужно добавлять выделенный пограничный сервер CMS.

  Примерная схема работы:
  

• Scalable and Resilient(Масштабируемый и отказоустойчивый) этот тип включает в себя избыточность для каждого компонента, что позволяет системе расти с вашими потребностями до максимальной ёмкости, обеспечивая при этом избыточность в случае сбоя. Он также использует концепцию Single Edge для обеспечения безопасного внешнего доступа. Это тип, который мы рассмотрим в этом выпуске. Если мы будем понимать, как развернуть кластер этого типа, мы не только поймём другие типы развертывания, но и сможем понять, как создавать кластеры CMS серверов с учетом потенциального роста потребностей.

Прежде чем переходить к развёртыванию нужно понимать некоторые базовые вещи, а именно

Основные программные компоненты CMS:

• Database: позволяет объединять некоторые конфигурации, такие как абонентская группа, пространства пользователей и самих пользователей. Поддерживает кластеризацию только для высокой доступности (один мастер).
• Call Bridge: сервис для аудио- и видеоконференций, замыкающий на себе полный контроль за управлением и обработкой вызовами и мультимедиа процессами. Поддерживает кластеризацию для высокой доступности и масштабируемости.
• XMPP server: отвечает за регистрацию и аутентификацию клиентов использующих приложение Cisco Meeting Application и/или WebRTC(real-time communication, ну или попросту в браузере), а также межкомпонентную сигнализацию. Может быть кластеризован только для высокой доступности.
• Web Bridge: предоставляет доступ клиентов в WebRTC.
• Loadbalancer: обеспечивает единую точку подключения для приложений Cisco Meeting App в режиме Single Split. Прослушивает внешний интерфейс и порт для входящих соединений. В равной степени балансировщик нагрузки принимает входящие TLS соединения с XMPP-сервера, через которые он может переключать TCP-соединения от внешних клиентов.
  В нашем сценарии он не понадобится.
• TURN server: обеспечивает технологию обхода Firewall’а, позволяющую
  вывесить наш CMS за Firewall’ом или NAT’ом для подключения внешних клиентов использующих Cisco Meeting App или SIP устройства. В нашем сценарии он не понадобится.
• Web Admin: административный интерфейс и доступ к API, в том числе для специальных конференций Unified CM.

Режимы конфигурации

В отличие от большинства других продуктов Cisco, Cisco Meeting Server поддерживает три метода настройки, позволяющих развернуть любой вид развертывания.

• Командная строка (CLI): Интерфейс командной строки, известный как MMP, для задач начальной настройки и сертификатов.
• Веб-администратор: в первую очередь для конфигурации, связанной с CallBridge, особенно при настройке одного некластеризованного сервера.
• REST API: используется для самых сложных задач по настройке и задач, связанных с кластерной базой данных.

Кроме вышеуказанного, используется протокол SFTP для передачи файлов — обычно лицензий, сертификатов или журналов — на сервер CMS и с него.

В deployment guide’ах от Cisco английским по белому написано, что кластер нужно разворачивать минимум из трёх серверов(нодов) в контексте баз данных. Т.к. только с нечётным количеством узлов отработает механизм выбора нового Мастера базы данных, и вообще Мастер базы данных имеет связь с большей частью базы данных CMS сервера.

И как практика показывает двух серверов(нодов) действительно не вполне достаточно. Механизм выбора отрабатывает при перезагрузке Master’а, Slave сервер становится Master’ом исключительно после поднятия перезагруженного сервера. Однако, если в кластере из двух серверов Master сервер вдруг «погас», то Slave сервер Master’ом не станет, а если «погас» Slave то и оставшийся Master сервер станет Slave’ом.

А вот в контексте XMPP действительно нужно бы собирать кластер из трёх серверов, т.к. если, например, отключить XMPP службу на одном из серверов в котором XMMP в статусе Leader, то на оставшемся сервере XMPP так и останется в статусе Follower и подключения CallBridge’й к XMPP отвалятся, т.к. CallBridge подключается исключительно к XMPP со статусом Leader. А это критично, т.к. ни один звонок не пройдёт.

Также в этих же deployment guide’ах демонстрируется кластер с одним XMPP сервером.

И с учётом выше сказанного становится понятно почему: работает потому что в режиме failover.

В нашем случае XMPP сервер будет присутствовать на всех трёх нодах.

Предполагается, что все три наши сервера подняты.

DNS записи

Прежде чем приступать к настройке серверов необходимо завести DNS записи А и SRV типов:

Обратите внимание, что в наших DNS записях присутствует два домена example.com и conf.example.com. Example.com является доменом, который могут использовать для своих URI все абоненты Cisco Unified Communication Manager’a, который скорее всего в вашей инфраструктуре присутствует или с высокой долей вероятности присутствовать будет. Или домен example.com соответствует тому же домену, который пользователи используют для своих адресов электронной почты. Или же клиент Jabber на вашем ноутбуке может иметь URI [email protected]. Домен conf.example.com — это тот домен, который будет настроен для пользователей Cisco Meeting Server’a. Доменом Cisco Meeting Server’a будет conf.example.com, поэтому для того же пользователя Jabber для входа в Cisco Meeting Server нужно будет использовать URI user@conf.example.com.

Базовая конфигурация

Все настройки описываемые ниже показаны на одном сервере, но провести их нужно на каждом сервере кластера.

QoS

Поскольку CMS генерирует real-time трафик, чувствительный к задержкам и потере пакетов, в большинстве случаев рекомендуется настроить качество обслуживания (QoS). Для этого CMS поддерживает маркировку пакетов кодами дифференцированных услуг (DSCP), которые он генерирует. Хотя приоритезация трафика на основе DSCP зависит от того каким образом трафик обрабатывается сетевыми компонентами вашей инфраструктуры, в нашем случае мы настроим наш CMS с типичным распределением приоритетов DSCP на основе лучших практик QoS.

На каждом сервере введём вот эти команды

dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1A

Таким образом, весь видео трафик был помечен AF41 (DSCP 0x22), весь голосовой трафик помечен EF (DSCP 0x2E), прочие виды трафика с низкой задержкой, такие как SIP и XMPP, используют AF31 (DSCP 0x1A).

Проверяем:

NTP

Сетевой протокол времени (NTP) важен не только для обеспечения точных временных отметок звонков и конференций, но также и для проверки сертификатов.

Добавляем сервера NTP вашей инфраструктуры командой вида

ntp server add <server>

В нашем случае таких серверов два, поэтому и команд будет две.
Проверяем:

И задаём временную зону для нашего сервера

DNS

DNS серверы в CMS добавляем командой вида:

dns add forwardzone <domain-name> <server ip>

В нашем случае таких серверов два, поэтому и команд будет две.
Проверяем:

Конфигурация сетевого интерфейса

Настраиваем а интерфейс командой вида:

ipv4 <interface> add <address>/<prefix length> <gateway>

Проверяем:

Имя сервера(Hostname)

Имя сервера задаём командой вида:

hostname <name>

И перезагружаем.


На этом базовая конфигурация закончена.

Сертификаты

ТеорияCisco Meeting Server требует шифрованной связи между различными компонентами, и в результате сертификаты X.509 требуются для всех развертываний CMS. Они помогают обеспечить доверие к службам/серверу другим серверам/службам.

Для каждой службы требуется сертификат, однако создание отдельных сертификатов для каждой службы может привести к путанице и лишней сложности. К счастью, мы можем сгенерировать пару открытого и закрытого ключей сертификата, а затем повторно использовать их для нескольких служб. В нашем случае один и тот же сертификат будет использоваться для Call Bridge, сервера XMPP, Web Bridge и Web Admin. Таким образом нужно создать по паре открытого и закрытого ключей сертификата на каждый сервер в кластере.

Кластеризация базы данных, однако, имеет некоторые особые требования к сертификатам и поэтому требует своих собственных сертификатов, отличных от сертификатов остальных служб. CMS использует сертификат сервера, который похож на сертификаты, используемые другими серверами, но есть также сертификат клиента, используемый для соединений с базой данных. Сертификаты базы данных используются, как для аутентификации, так и для шифрования. Вместо того, чтобы предоставлять имя пользователя и пароль для подключения клиента к базе данных, он представляет сертификат клиента, которому доверяет сервер. Каждый сервер в кластере базы данных будет использовать одну и ту же пару открытого и закрытого ключей. Это позволяет всем серверам в кластере шифровать данные таким образом, чтобы они могли быть расшифрованы только другими серверами, которые также используют ту же самую пару ключей.

Чтобы резервирование работало, кластеры базы данных должны состоять как минимум из 3 серверов, но не более 5, с максимальным временем прохождения сигнала в обоих направлениях 200 мс между любыми членами кластера. Этот предел является более ограничительным, чем для кластеризации Call Bridge, поэтому он часто является ограничивающим фактором в географически распределенных развертываниях.

Роль базы данных для CMS имеет ряд уникальных требований. В отличие от других ролей, он требует сертификата клиента и сервера, где сертификат клиента имеет определенное поле CN, которое представляется серверу.

CMS использует базу данных postgres с одним главным и несколькими полностью идентичными репликами. В каждый момент времени существует только одна основная база данных («сервер базы данных»). Остальные члены кластера являются репликами или «клиентами базы данных».

Для кластера базы данных требуются сертификат выделенного сервера и сертификат клиента. Они должны быть подписаны сертификатами, обычно внутренним частным центром сертификации. Поскольку любой из членов кластера базы данных может стать главным, пары сертификатов сервера базы данных и клиента (содержащие открытый и закрытый ключи) должны быть скопированы на все серверы, чтобы они могли принять идентичность клиента или сервера базы данных. Кроме того, корневой сертификат CA должен быть загружен, чтобы гарантировать, что сертификаты клиента и сервера могут быть проверены.

Итак, формируем запрос для сертификата, который будет использоваться всеми службами сервера за исключением database(для этого будет отдельный запрос) командой вида:

pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com

В CN пишем обобщённое название наших серверов. Например если hostname’ы наших серверов server01, server02, server03, то CN будет server.example.com

Тоже самое делаем на оставшихся двух серверах с тем отличием, что в командах будут соответствующие «hostname’ы»

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

pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com

pki csr dbclusterclient CN:postgres

где dbclusterserver и dbclusterclient имена наших запросов и будущих сертификатов, hostname1(2)(3) имена соответствующих серверов.

Эту процедуру мы выполняем только на одном сервере(!), а сертификаты и соответствующие .key-файлы загрузим на другие сервера.

Включение режима клиентского сертификата в AD CS

Ещё нужно слить в один файл сертификаты для каждого сервераВ *NIX:

cat server01.cer server02.cer server03.cer > server.cer

В Windows/DOS:

copy server01.cer + server02.cer + server03.cer  server.cer

И загрузить на каждый сервер:
1. «Индивидуальный» сертификат сервера.
2. Корневой сертификат(вместе с промежуточными если такие есть).
3. Сертификаты для базы данных(«серверный» и «клиентский») и файлы с расширением .key, которые сформировались при создании запроса для «серверного» и «клиентского» сертификата базы данных. Эти файлы должны быть на всех серверах одними и теми же.
4. Файл всех трёх «индивидуальных» сертификатов.

В итоге должна получиться примерно такая файловая картина на каждом сервере.

Database Cluster

Теперь, когда у вас есть все сертификаты, загруженные на серверы CMS, вы можете настроить и включить кластеризацию базы данных между тремя узлами. Первым шагом является выбор одного сервера в качестве главного узла кластера базы данных и его полная настройка.

Master Database

Первым шагом в настройке репликации базы данных является указание сертификатов, которые будут использоваться для базы данных. Это делается с помощью команды вида:

database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>

Теперь укажем CMS, какой интерфейс использовать для кластеризации баз данных командой:

database cluster localnode a

Затем инициализируем базу данных кластера на главном сервере командой:

database cluster initialize

Client Database Nodes

Проделываем ту же самую процедуру, только вместо команды database cluster initialize вводим команду вида:

database cluster join <ip address existing master>

где ip address existing master ip адрес CMS сервера на котором была произведена инициализация кластера, попросту Master’a.

Проверяем как работает наш кластер базы данных на всех серверах командой:

database cluster status

Тоже самое делаем и на оставшемся третьем сервере.

В итоге получается, что первый наш сервер является Master’ом, остальные Slave’ами.

Web Admin Service

Включаем службу веб-администратора:

webadmin listen a 445

445 порт выбран потому, что 443 порт используется для доступа пользователей в web-клиент

Настраиваем Web Admin службу с файлами сертификатов командой вида:

webadmin certs <keyfile> <certificatefile> <ca bundle>

И включаем Web Admin командой:

webadmin enable

Если всё хорошо, то мы получим строки SUCCESS, в которых указано, что Web Admin правильно настроен для сети и сертификата. Проверяем работоспособность службы с помощью веб-браузера и вводим адрес веб-администратора, например: cms.example.com:445

Call Bridge Cluster

Call Bridge является единственной службой, присутствующей в каждом развертывании CMS. Call Bridge является основным механизмом конференц-связи. Он также обеспечивает SIP интерфейс, так что вызовы могут маршрутизироваться к нему или из него, например Cisco Unified CM’ом.

Описанные ниже команды надо выполнить на каждом сервере с соответствующими сертификатами.
Итак:

Связываем сертификаты со службой Call Bridge командой вида:

callbridge certs <keyfile> <certificatefile>[<cert-bundle>]

Привязываем службы CallBridge к нужному нам интерфейсу командой:

callbridge listen a

И перезапускаем службу командой:

callbridge restart

Теперь, когда у нас есть настроены Call Bridge’ы, мы можем настроить кластеризацию Call Bridge. Кластеризация Call Bridge отличается от кластеризации базы данных или XMPP. Call Bridge Cluster может поддерживать от 2 до 8 узлов без каких-либо ограничений. Он обеспечивает не только избыточность, но и распределение нагрузки, благодаря чему конференции могут активно распределяться между серверами Call Bridge с помощью интеллектуального распределения вызовов. CMS имеет дополнительные функции, группы Call Bridge и связанные с ними функции, которые можно использовать для дальнейшего управления.

Кластеризация моста вызовов настраивается в основном через интерфейс веб-администратора
Нижеописанную процедуру нужно провести на каждом сервере кластера.
Итак,

1. Заходим через web в Configuration > Cluster.
2. В Call Bridge identity в качестве уникального имени вводим callbridge[01,02,03] соответствующее имени сервера. Эти имена произвольны, но должны быть уникальными для этого кластера. Они носят описательный характер, поскольку указывают на то, что это идентификаторы серверов [01,02,03].
3.В Clustered Call Bridges вводим URL-адреса веб-администратора наших серверов в кластере, cms[01,02,03].example.com:445, в поле Address. Обязательно укажите порт. Вы можете оставить Peer link SIP domain пустым.
4. Добавляем в доверие CallBridge’у каждого сервера сертификат, файл которого содержит все сертификаты наших серверов, которые мы слили в этот файл в самом начале, командой вида:

callbridge trust cluster <trusted cluster certificate bundle>

И перезапускаем службу командой:

callbridge restart

В итоге на каждом сервере должна получиться вот такая картина:

XMPP Cluster

Служба XMPP в CMS используется для обработки всей регистрации и аутентификации для Cisco Meeting Apps (CMA), включая веб-клиента CMA WebRTC. Сам Call Bridge также действует, как клиент XMPP для целей аутентификации и поэтому должен быть настроен как другие клиенты. Отказоустойчивость XMPP — это функция, которая поддерживается в производственных средах, начиная с версии 2.1

Описанные ниже команды надо выполнить на каждом сервере с соответствующими сертификатами.
Итак:

Связываем сертификаты со службой XMPP командой вида:

xmpp certs <keyfile> <certificatefile>[<cert-bundle>]

Затем определите интерфейс прослушивания командой:

xmpp listen a

Для службы XMPP требуется уникальный домен. Это логин для пользователей. Другими словами, когда пользователь пытается войти в систему с помощью приложения CMA (или через клиент WebRTC), он вводит userID@logindomain. В нашем случае это будет userid@conf.example.com. Почему это не просто example.com? В нашем конкретном развертывании мы выбрали наш домен Unified CM, который пользователи Jabber будут использовать в Unified CM, как example.com, поэтому нам нужен другой домен для пользователей CMS, чтобы маршрутизировать вызовы в CMS и из CMS через домены SIP.

Настройте домен XMPP с помощью команды вида:

xmpp domain <domain>

И включаем службу XMPP командой:

xmpp enable

В службе XMPP необходимо создать учетные данные для каждого Call Bridge, которые будут использоваться при регистрации в службе XMPP. Эти имена являются произвольными (и не связаны с уникальными именами, которые вы настроили для кластеризации моста вызовов). На одном сервере XMPP необходимо добавить три моста вызовов, а затем ввести эти учетные данные на других серверах XMPP в кластере, поскольку эта конфигурация не помещается в кластерную базу данных. Позже мы настроим каждый Call Bridge для использования этого имени и секрета для регистрации в службе XMPP.

Теперь нам нужно настроить службу XMPP на первом сервере с тремя Call Bridge’ами callbridge01, callbridge02 и callbridge03. Каждой учетной записи будут назначены случайные пароли. Позже они будут введены на других серверах Call Bridge для входа на этот XMPP-сервер. Вводим следующие команды:

xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03

В итоге проверяем что получилось командой:

xmpp callbridge list

В точности такая же картина должны быть на остальных серверах после действий описанных ниже.

Далее добавляем на оставшихся двух серверах точно такие настройки, только командами

xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03

Secret добавляем очень аккуратно, чтобы случайно в него например не попали лишние пробелы.


В итоге на каждом сервере должны быть такая одинаковая картина:

Далее на всех серверах кластера указываем в доверие файл содержащий все три сертификата, созданный ранее командой вида:

xmpp cluster trust <trust bundle>

Включаем режим xmpp кластера на всех серверах кластера командой:

xmpp cluster enable

На первом сервере кластера инициируем создание xmpp кластера командой:

xmpp cluster initialize

На остальных серверах добавляем в xmpp кластер командой вида:

xmpp cluster join <ip address head xmpp server>

Проверяем на каждом сервере успешность создания XMPP кластера на каждом сервере командами:

xmpp status
xmpp cluster status

Первый сервер:

Второй сервер:

Третий сервер:

Подключение Call Bridge к XMPP

Теперь, когда кластер XMPP запущен, необходимо настроить службы Call Bridge для подключения к кластеру XMPP. Эта конфигурация выполняется через веб-администратор.

Заходим на каждом сервере в Configuration > General и в поле Unique Call Bridge name пишем соответствующие серверу уникальные имена Call Bridge callbridge[01,02,03]. В поле Domain conf.example.ru и соответствующие пароли, подсмотреть их можно
на любом сервере кластера командой:

xmpp callbridge list

Поле «Сервер» оставляем пустым, Callbridge выполнит поиск DNS SRV для _xmpp-component._tcp.conf.example.com, чтобы найти доступный сервер XMPP. IP адреса подключения callbridge’ей к XMPP могут отличаться на каждом сервере, это зависит от того какие значения возвращаются на запрос по записи _xmpp-component._tcp.conf.example.com callbridge’у, что в свою очередь зависит от настроек приоритетов для данной DNS записи.

Далее переходим в Status > General, чтобы убедиться, успешно ли служба Call Bride подключена к службе XMPP.

Web Bridge

На каждом сервере кластера включаем службу Web Bridge командой:

webbridge listen a:443

Настраиваем Web Bridge службу с файлами сертификатов командой вида:

webbridge  certs <keyfile> <certificatefile> <ca bundle>

Web Bridge поддерживает HTTPS. Он будет перенаправлять HTTP на HTTPS, если настроен для использования «http-redirect».
Чтобы включить перенаправление HTTP, используйте следующую команду:

webbridge http-redirect enable

Чтобы Call Bridge дал понять, что Web Bridge’у можно доверять соединениям из Call Bridge, используйте команду:

webbridge trust <certfile>

где это файл, содержащий все три сертификата от каждого сервера в кластере.

Такая картина должны быть на каждом сервере кластера.


Теперь нам нужно создать пользователя с ролью «appadmin», он нам нужен для того чтобы мы могли настраивать наш кластер(!), а не каждый сервер кластера по отдельности, таким образом настройки будут применяться одинаково на каждый сервер при том, что производиться они будут один раз.


Для дальнейшей настройки мы будем использовать Postman.

Для авторизации выбираем Basic в разделе Autorization

Для корректной отправки команд на сервера CMS нужно выставить нужную кодировку

Указываем Webbridge’и командой POST с параметром url и значением cms.example.com



В самом webbridge’e указываем нужны параметры: гостевой доступ, защищенный доступ и прочее.

Call Bridge Groups

По умолчанию CMS не всегда максимально эффективно использует доступные ей ресурсы конференц-связи.

Например, для встречи с тремя участниками каждый участник может оказаться на трех разных Call Bridge’ax. Для того чтобы эти три участника могли общаться друг с другом, Call Bridge’ы автоматически установят соединения между всеми серверами и клиентами в одном и том же Space’e, чтобы выглядело это всё так, как будто все клиенты на одном сервере. К сожалению, недостатком этого является то, что одна конференция из 3 человек теперь будет потреблять 9 медиа-портов. Это, очевидно, неэффективное использование ресурсов. Кроме того, когда Call Bridge действительно перегружен, механизм по умолчанию заключается в том, чтобы продолжать принимать вызовы и предоставлять услуги с пониженным качеством всем абонентам этого Call Bridge’a.

Эти проблемы решаются с помощью функции Call Bridge Group. Эта функция была представлена ​​в версии 2.1 программного обеспечения Cisco Meeting Server и была расширена для поддержки балансировки нагрузки как для входящих, так и для исходящих вызовов, Cisco Meeting App (CMA), включая участников WebRTC.

Для решения проблемы переподключения были введены три настраиваемых ограничения нагрузки для каждого Call Bridge:

LoadLimit — это максимальная числовая нагрузка для конкретного Call Bridge. У каждой платформы есть рекомендуемое предельное значение нагрузки, например 96000 для CMS1000 и 1.25 GHz на виртуальный процессор для виртуальной машины. Различные вызовы потребляют определенное количество ресурсов в зависимости от разрешения и частоты кадров участника.
NewConferenceLoadLimitBasisPoints (по умолчанию 50% loadLimit) — устанавливает предел загрузки сервера, после которого новые конференции отклоняются.
ExistingConferenceLoadLimitBasisPoints (по умолчанию 80% от loadLimit) — значение загрузки сервера, после которого участники, присоединяющиеся к существующей конференции, будут отклонены.

В то время, как эта функция была разработана для распределения вызовов и распределения нагрузки, другие группы, такие, как серверы TURN, серверы Web Bridge и устройства записи, также могут быть назначены для Call Bridge Groups, так что они также могут быть правильно сгруппированы для оптимального использования. Если какой-либо из этих объектов не назначен группе вызовов, предполагается, что они доступны всем серверам без какого-либо определенного приоритета.

Эти параметры настраиваются здесь: cms.example.com:445/api/v1/system/configuration/cluster

Далее указываем каждому callbridge’у к какой callbridge-группе он принадлежит:

Первый callbridge

Второй callbridge

Третий callbridge


Таким образом мы настроили группу Call Brdige’eй для более эффективного использования ресурсов кластера Cisco Meeting Server’a.

Импорт пользователей из Active Directory

Служба Web Admin имеет раздел конфигурации LDAP, но он не предоставляет сложные параметры конфигурации, и информация не сохраняется в кластерной базе данных, поэтому настройку придется выполнять, либо вручную на каждом сервере через Web-интерфейс, либо через API, и чтобы нам «три раза не вставать» данные мы будем задавать всё-таки через API.

Используя URL-адрес для доступа cms01.example.com:445/api/v1/ldapServers cоздаём объект LDAP Server’a, указывая такие параметры, как:

• IP-адрес сервера
• номер порта
• имя пользователя
• пароль
• secure

Secure — true или false выбираем в зависимости от порта, 389 — не защищенный, 636 — защищённый.


Отображаем LDAP параметры источника на атрибуты в Cisco Meeting Server’e.
Отображение LDAP сопоставляет атрибуты в каталоге LDAP с атрибутами в CMS. Собственно атрибуты:

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Описание атрибутовJID представляет идентификатор входа пользователя в CMS. Поскольку это LDAP-сервер Microsoft Active Directory, JID CMS сопоставляется с sAMAccountName в LDAP, который по сути является идентификатором входа в Active Directory пользователя. Также обратите внимание, что вы берете sAMAccountName и добавляете домен conf.pod6.cms.lab к его концу, потому что это логин, который ваши пользователи будут использовать для входа в CMS.

nameMapping сопоставляет то, что содержится в поле Active Directory displayName, с полем имени CMS пользователя.

coSpaceNameMapping создаёт имя space’a CMS на основе поля displayName. Этот атрибут вместе с атрибутом coSpaceUriMapping являются тем, что требуется для создания space’a для каждого пользователя.

coSpaceUriMapping определяет пользовательскую часть URI, связанную с личным space’ом пользователя. Некоторые домены могут быть настроены для набора в space. Если пользовательская часть совпадает с этим полем для одного из этих доменов, вызов будет направлен в space этого пользователя.

coSpaceSecondaryUriMapping определяет второй URI, чтобы достигнуть space’a. Это может использоваться для добавления числового псевдонима для маршрутизации вызовов в space импортированного пользователя в качестве альтернативы буквенно-цифровому URI, определенному в параметре coSpaceUriMapping.

Сервер LDAP и сопоставление LDAP настроены. Теперь требуется связать их вместе, создав источник LDAP.

Используя URL-адрес для доступа cms01.example.com:445/api/v1/ldapSource cоздаём объект LDAP Source, указывая такие параметры, как:

• server
• mapping
• baseDn
• filter

Теперь, когда настройка LDAP завершена, можно выполнить операцию ручной синхронизации.

Делаем это либо в Web-интерфейсе каждого сервера нажав Sync now в разделе Active Directory


либо через API командой POST используя URL-адрес для доступа cms01.example.com:445/api/v1/ldapSyncs

Ad-Hoc конференции

Что это?В традиционном понятии конференция это, когда два участника разговаривают друг с другом, а один из участников (используя устройство, зарегистрированное в Unified CM) нажимает кнопку «Конференция», вызывает другого человека и после разговора с этой третьей стороной нажимает снова нажмите кнопку «Конференция», чтобы присоединиться ко всем участникам трехсторонней конференции.

Ad-Hoc конференцию от запланированной конференции в CMS отличает то, что Ad-Hoc конференция — это не просто вызов SIP для CMS. Когда инициатор конференции нажимает кнопку «Конференция» во второй раз, чтобы пригласить всех на одно и то же собрание, Unified CM должен выполнить вызов API для CMS, чтобы создать конференцию «на лету», на которую затем передаются все вызовы. Все это происходит незаметно для участников.

Это означает, что Unified CM должен настроить учетные данные API и адрес / порт WebAdmin службы, а также SIP-Trunk непосредственно на сервер CMS для продолжения вызова.

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

Интеграция с CUCM настраивается так же, как описано в статье ранее за исключением того, что на Cisco UCM нужно создать три транка для CMS, три Conference Bridge’a, в SIP Security Profile указать три Subject Name’a, Route Group’у, Route List, Media Resourse Group и Media Resourse Group List, а в Cisco Meeting Server’e немного добавить правил маршрутизации.

SIP Security Profile:


Транки:


Каждый транк выглядит одинаково:




Conference Bridge


Каждый Conference Bridge выглядит одинаково:


Route Group


Route List


Media Resourse Group


Media Resourse Group List

Правила вызовов

В отличие от более совершенных систем управления вызовами, таких как Unified CM или Expressway, для новых вызовов CMS просматривает домен только в поле SIP Request-URI. Так что, если SIP INVITE предназначен для sip: [email protected], CMS заботится только о domain.com. CMS следует этим правилам для определения, куда направить звонок:

1. Сначала CMS пытается сопоставить домен SIP с доменами, настроенными в правилах обработки входящих вызовов. Затем эти вызовы можно направлять в («целевые») пространства или конкретным пользователям, внутренним IVR или напрямую интегрированным адресатам Microsoft Lync/Skype для бизнеса (S4B).
2. Если в правилах обработки входящих вызовов нет совпадений, CMS попытается сопоставить домен, настроенный в таблице переадресации вызовов. Если сопоставление установлено, правило может явно отклонить вызов или переадресовать вызов. В это время CMS может переписать домен, что иногда полезно для звонков в домены Lync. Вы также можете выбрать pass throw, что означает, что ни одно из полей не будет дополнительно изменено, или использовать внутреннюю абонентскую группу CMS. Если в правилах переадресации вызовов нет совпадений, по умолчанию используется отклонение вызова. Имейте в виду, что в CMS, хотя вызов «переадресован», мультимедиа все еще привязывается к CMS, что означает, что он будет находиться в пути сигнализации и мультимедиа трафика.
Тогда только переадресованные вызовы подчиняются правилам исходящих вызовов. Эти параметры определяют адресатов, куда отправлять вызовы, тип соединительной линии (будь то новый вызов Lync или стандартным SIP) и любые преобразования, которые могут быть выполнены, если в правиле переадресации вызовов не выбрана передача.

Вот собственно лог того, что происходит при Ad-Hoc конференции

На скриншоте видно плохо(не знаю как сделать лучше), поэтому напишу лог так:

Info	127.0.0.1:35870: API user "api" created new space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call create failed to find coSpace -- attempting to retrieve from database

Info	API "001036270012" Space GUID: 7986bb6c-af4e-488d-9190-a75f16844e44 <--> Call GUID: 93bfb890-646c-4364-8795-9587bfdc55ba <--> Call Correlator GUID: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 <--> Internal G

Info	127.0.0.1:35872: API user "api" created new call 93bfb890-646c-4364-8795-9587bfdc55ba

Info	call 7: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg bc0be45e-ce8f-411c-be04-594e0220c38e in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 has control/media GUID: fb587c12-23d2-4351-af61-d6365cbd648d

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 named "001036270012"

Info	call 7: configured - API call leg bc0be45e-ce8f-411c-be04-594e0220c38e with SIP call ID "[email protected]"

Info	call 7: setting up UDT RTP session for DTLS (combined media and control)
Info	conference "001036270012": unencrypted call legs now present

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 8: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg db61b242-1c6f-49bd-8339-091f62f5777a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	call 8: configured - API call leg db61b242-1c6f-49bd-8339-091f62f5777a with SIP call ID "[email protected]"

Info	call 8: setting up UDT RTP session for DTLS (combined media and control)

Info	call 9: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	call 9: configured - API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a with SIP call ID "[email protected]"

Info	call 9: setting up UDT RTP session for DTLS (combined media and control)
Info	call 8: compensating for far end not matching payload types

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (289e823d-6da8-486c-a7df-fe177f05e010) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 7: compensating for far end not matching payload types
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: compensating for far end not matching payload types

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (d27e9a53-2c8a-4e9c-9363-0415cd812767) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 9: BFCP (client role) now active
Info	call 9: sending BFCP hello as client following receipt of hello when BFCP not active
Info	call 9: BFCP (client role) now active
Info	call 7: ending; remote SIP teardown - connected for 0:13
Info	call 7: destroying API call leg bc0be45e-ce8f-411c-be04-594e0220c38e

Info	participant "[email protected]" left space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call 9: on hold
Info	call 9: non matching payload types mode 1/0
Info	call 9: answering offer in non matching payload types mode
Info	call 8: on hold
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: ending; remote SIP teardown - connected for 0:12

Сама Ad-Hoc конференция:


Правила входящих вызовов
Настройка параметров входящих вызовов необходима для возможности приема вызова в CMS. Как вы видели в настройке LDAP, все пользователи были импортированы с доменом conf.pod6.cms.lab. Поэтому, как минимум, вы хотите, чтобы вызовы в этот домен предназначались для пробелов. Вам также нужно будет установить правила для всего, что предназначено для полного доменного имени (и, возможно, даже для IP-адреса) каждого из серверов CMS. В нашем внешнем контроле вызовов, Unified CM, будут настроены магистрали SIP, предназначенные для каждого из серверов CMS индивидуально. В зависимости от того, является ли назначение этих магистралей SIP IP-адресом, или полное доменное имя сервера будет определять, нужно ли настроить CMS для приема вызовов, направленных на его IP-адрес или полное доменное имя.

Домен, имеющий правило входящего трафика с наивысшим приоритетом, используется в качестве домена для любых пользовательских space’ов. Когда пользователи синхронизируются через LDAP, CMS автоматически создает space’ы, но только пользовательскую часть URI (coSpaceUriMapping), например, user.space. Часть domain полного URI создается на основе этого правила. Фактически, если бы вы вошли в Web Bridge на этом этапе, вы бы увидели, что у Space URI нет домена. Установив это правило в качестве наивысшего приоритета, вы задаете домен для сгенерированных space’ов как conf.example.com.


Правила исходящих вызовов

Чтобы разрешить пользователям совершать исходящие вызовы в кластер Unified CM, необходимо настроить правила исходящих соединений. Доменом конечных точек, зарегистрированных в Unified CM, таких как Jabber, является example.com. Вызовы в этот домен следует направлять как стандартные SIP-вызовы на узлы обработки вызовов Unified CM. В качестве основного выступает cucm-01.example.com сервер, в качестве дополнительного cucm-02.example.com.

Первое же правило описывает простейшую маршрутизацию звонков между серверами кластера.

Поле Local from domain отвечает за то, что будет отображаться в SIP-URI звонящего у того кому звонят после символа «@». Если мы его оставим пустым, то после символа «@» будет ip-адрес CUCM’a через который этот звонок проходит. Если же мы укажем домен, то после символа «@» собственно и будет домен. Это нужно для того, чтобы была возможность перезвонить обратно, иначе дозвониться обратно по SIP-URI имя@ip-адрес будет не возможно.

Звонок когда указан Local from domain


Звонок когда НЕ указан Local from domain


Обязательно явно укажите Encrypted или Unencrypted будут исходящие звонки, потому при параметре Auto ничего не работает.

Recording

Запись видеоконференций ведётся Record-сервером. Recorder представляет из себя точно такой же Cisco Meeting Server. Recorder не требует установки на себя никаких лицензий. Лицензии на запись требуются серверам на которых запущены службы CallBridge, т.е. лицензия Recording необходима и должна применяться к компоненту CallBridge, а не к серверу где запущен Recorder. Recorder ведет себя, как клиент расширяемого протокола обмена сообщениями и присутствия (XMPP), поэтому сервер XMPP должен быть включен на сервере, на котором размещен CallBridge.

Т.к. у нас кластер и лицензию нужно «растянуть» на все три сервера кластера. То просто в личном кабинете в лицензиях ассоциируем(добавляем) MAC-адреса a-интерфейсов всех CMS серверов входящих в кластер.

И вот такая картина должна быть на каждом сервере кластера

Вообще сценариев размещения Recorder’a несколько, но мы будем придерживаться такого:


Перед тем, как настраивать Recorder требуется подготовить место куда собственно и будут записываться видеоконференции. Собственно вот ссылка, как настроить весь Recording. Я сакцентирую внимание на важных моментах и деталях:

1. Сертификат лучше подсунуть от первого сервера в кластере.
2. Ошибка «Recorder unavailable» может возникать потому, что указан не тот сертификат в Recorder Trust.
3. Запись может не идти, если для записи указан не корневой каталог в NFS.

Иногда возникает необходимость автоматически записывать конференцию одного конкретного пользователя или space’a.

Для этого создаются два CallProfile’a:
С отключенной функцией записи


И с автоматической функцией записи


Далее к нужному space’у «прикручиваем» CallProfile с автоматической функцией записи.


В CMS так заведено, что если CallProfile явно привязан к каким-либо space’ам или space’у, то и работает этот CallProfile применительно только к этим конкретным space’ам. А если CallProfile не привязан ни к одному space’у, то по умолчанию он применяется к тем space’ам к которым явно не привязан ни один CallProfile.

В следующий раз попробую описать, какими способами осуществляется доступ к CMS за пределами внутренней сети организации.

Источники:

• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-5/Cisco-Meeting-Server-2-5-Single-Combined-Server-Deployment.pdf
• www.cisco.com/c/en/us/support/docs/conferencing/meeting-server/202722-Configure-Recorder-in-CMS-Acano-Call-Bri.html
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-3/Cisco-Meeting-Server-MMP-Command-Reference-2-3.pdf
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-5/Cisco-Meeting-Server-API-Reference-Guide-2-4-and-later.pdf

Источник: habr.com