Cisco Meeting Server 2.5.2. Клъстер в режим Scalable and Resilient с функция за запис на видеоконференции

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


ТеорияВсъщност съществуват три типа на внедряване на CMS сървър:

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

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

• Single Split(Единен разделен) разширява предишния тип внедряване, добавяйки отделен сървър за външен достъп. В остарели внедрявания това означаваше разполагане на CMS сървър в демилизирания сегмент на мрежата (DMZ), където външните клиенти могат да получат достъп до него, и един CMS сървър в ядрото на мрежата, където получават достъп до CMS вътрешни клиенти. Тази конкретна модел на внедряване сега е заместена от така нареченото Single Edge, което се състои от сървъри Cisco Expressway, които или имат, или ще имат много от функциите за заобикаляне на Firewall, така че на клиентите не им се налага да добавят отделен граничен CMS сървър.

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

• Scalable and Resilient(Масштабируем и отказоустойчив) този тип включва излишност за всеки компонент, което позволява на системата да нараства с вашите нужди до максимална капацитет, като същевременно осигурява излишност в случай на отказ. Той също така използва концепцията Single Edge за осигуряване на безопасен външен достъп. Това е типът, който ще разгледаме в това издание. Ако разберем как да внедрим клъстер от този тип, ще можем не само да разберем другите типове внедряване, но и да създадем клъстери на CMS сървъри с оглед на потенциалния растеж на нуждите.

Преди да преминем към внедряването, е необходимо да разберем някои основни неща, а именно

Основни софтуерни компоненти на CMS:

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

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

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

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

Освен посоченото по-горе, се използва протокол SFTP за пренос на файлове — обикновено лицензи, сертификати или логове — на CMS сървера и обратно.

В ръководствата от Cisco черно на бяло е написано, че клъстер трябва да бъде разгръщан минимум от три сървъра (възли) в контекста на бази данни. Тъй като само с нечетно количество възли ще работи механизмът за избор на нов Майстор на базата данни, а въобще Майсторът на базата данни има връзка с голяма част от базата данни на CMS сървера.

Как показала практика, двух серверов (нодов) действительно недостаточно. Механизм выбора срабатывает при перезагрузке мастер-сервера; слейв-сервер становится мастер-сервером только после перезагрузки. Однако если в кластере из двух серверов мастер-сервер неожиданно выходит из строя, слейв не станет мастер-сервером. Если же вышел из строя слейв, то оставшийся мастер станет слейвом.

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

Также в этих же руководствах по развертыванию демонстрируется кластер с одним XMPP сервером.

С учетом вышеизложенного становится понятно, почему: это работает, потому что в режиме failover.

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

Предполагается, что все три сервера работают.

DNS записи

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

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

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

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

QoS

Поскольку CMS генерирует real-time Трафик, чувствителен към закъснения и загуба на пакети, в повечето случаи е препоръчително да настроите Quality of Service (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

В нашия случай има два такива сървъра, така че ще има две команди.
Проверяваме:

И задаваме времевата зона за нашия сървър.

DNS

DNS сървъри в CMS добавяме с команда от вида:

dns add forwardzone

В нашия случай има два такива сървъра, така че ще има две команди.
Проверяваме:

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

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

ipv4  add 
 /

Проверяваме:

Име на сървъра (Hostname)

Името на сървъра задаваме с команда от вида:

hostname

И след това рестартираме.


На това базовата конфигурация приключи.

Сертификатите

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

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

Кластеризация на базата данни обаче има някои специфични изисквания за сертификатите и затова изисква собствени сертификати, различаващи се от сертификатите на другите услуги. CMS използва сертификат на сървъра, който е подобен на сертификатите, използвани от другите сървъри, но има и сертификат на клиента, използван за свързване с базата данни. Сертификатите на базата данни се използват както за удостоверяване, така и за криптиране. Вместо да предоставя потребителско име и парола за свързване на клиента с базата данни, той представя сертификат на клиента, на който сървърът се доверява. Всеки сървър в клъстера на базата данни ще използва едно и също съчетание от публичен и частен ключ. Това позволява на всички сървъри в клъстера да криптират данни по такъв начин, че те да могат да бъдат декриптирани само от другите сървъри, които също използват същото съчетание от ключове.

За да работи резервирането, клъстерите на базата данни трябва да се състоят от минимум 3 сървъра, но не повече от 5, с максимално време за закъснение в двете посоки от 200 мс между членовете на клъстера. Това ограничение е по-строго отколкото за клъстеризация на Call Bridge, затова често е ограничителен фактор в географски разпределени разгръщания.

Ролята на базата данни за CMS има редица уникални изисквания. За разлика от другите роли, тя изисква сертификат на клиента и сървъра, където сертификатът на клиента има определено поле CN, което се представя на сървъра.

CMS използва база данни postgres с един основен сървър и няколко напълно идентични реплики. Във всеки момент на време съществува само една основна база данни ('сървър на базата данни'). Останалите членове на клъстера са реплики или 'клиенти на базата данни'.

За клъстера на базата данни са необходими сертификат за отделен сървър и клиентски сертификат. Те трябва да бъдат подписани от сертификати, обикновено от вътрешен частен център за сертификация. Тъй като който и да е от членовете на клъстера на базата данни може да стане главен, двойките сертификати на сървъра на базата данни и клиента (съдържащи обществен и частен ключ) трябва да бъдат копирани на всички сървъри, за да могат да приемат самоличността на клиента или на сървъра на базата данни. Освен това, кореновият сертификат на CA трябва да бъде зареден, за да се гарантира, че клиентските и сървърните сертификати могат да бъдат проверени.

Така че, формираме заявка за сертификат, който ще се използва от всички услуги на сървъра с изключение на базата данни (за това ще има отделна заявка) с команда от вида:

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

В CN пишем обобщено наименование на нашите сървъри. Например, ако имената на нашите сървъри server01, server02, server03, то CN ще бъде server.example.com

Същото правим и на останалите два сървъра с разликата, че в командите ще бъдат съответните „hostname’и“

Формираме две заявки за сертификати, които ще се използват от услугата база данни с команди от вида:

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. Файл с трите „индивидуални“ сертификата.

В резултат на това на всеки сървър трябва да изглежда приблизително така.

Клъстер на базата данни

Сега, когато имате всички сертификати качени на CMS сървърите, можете да настроите и активирате клъстеризация на базата данни между три възела. Първата стъпка е да изберете един сървър за главен възел на клъстера и да го конфигурирате напълно.

Главна база данни

Първата стъпка в настройката на репликация на базата данни е да посочите сертификатите, които ще се използват за базата данни. Това става с команда от вида:

database cluster certs

Сега да укажем на CMS кой интерфейс да използва за клъстеризация на бази данни с командата:

database cluster localnode a

След това инициализираме базата данни на клъстера на главния сървър с командата:

database cluster initialize

Клиентски възли на базата данни

Извършваме същата процедура, само вместо команда database cluster initialize въвеждаме команда от вида:

database cluster join

където ip address existing master е IP адресът на CMS сървъра, на който е била инициализирана кластеризацията, простичко казано - мастърът.

Проверяваме как работи нашият клъстер на базата данни на всички сървъри с командата:

database cluster status

Правим същото и на оставащия трети сървър.

В крайна сметка, първият ни сървър е мастер, а останалите - слейвове.

Уеб администраторска служба

Активираме уеб администраторската услуга:

webadmin listen a 445

Порт 445 е избран, тъй като порт 443 се използва за достъп на потребителите до уеб клиента.

Настройваме уеб администратора с файловете на сертификатите, използвайки команда от вида:

webadmin certs

И активираме уеб администратора с командата:

webadmin enable

Ако всичко е наред, ще получим редове SUCCESS, в които е посочено, че уеб администраторът е настроен правилно за мрежата и сертификата. Проверяваме работоспособността на услугата с уеб браузър, като въведем адреса на уеб администратора, например: cms.example.com:445

Клъстер на Call Bridge

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

Долуописаните команди трябва да бъдат изпълнени на всеки сървър с подходящите сертификати.
И така:

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

callbridge certs  []

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

callbridge listen a

И рестартираме услугата с командата:

callbridge restart

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

Кластеризацията на моста за повиквания се конфигурира основно през интерфейса на уеб администратора.
Следващата процедура трябва да се проведе на всеки сървър в клъстера.
И така,

1. Влизаме през уеб в 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

И рестартираме услугата с командата:

callbridge restart

В крайна сметка на всеки сървър трябва да изглежда така:

XMPP Cluster

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

Долуописаните команди трябва да бъдат изпълнени на всеки сървър с подходящите сертификати.
И така:

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

xmpp certs  []

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

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

И активираме XMPP услугата с командата:

xmpp enable

В XMPP услугата трябва да създадем идентификатори за всеки Call Bridge, които ще се използват при регистрацията в XMPP услугата. Тези имена са произволни (и не са свързани с уникалните имена, които сте настроили за клъстерирането на Call Bridge). На един XMPP сървър трябва да добавим три Call Bridge, а след това да въведем тези идентификатори на другите 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

Секретът добавяме много внимателно, за да не се появят случайно излишни интервали.


В крайна сметка на всеки сървър трябва да има такава идентична картина:

След това на всички сървъри в клъстера посочваме доверителен файл, съдържащ всичките три сертификата, създаден преди с командата:

xmpp cluster trust

Активираме режим xmpp клъстер на всички сървъри в клъстера с командата:

xmpp cluster enable

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

xmpp cluster initialize

На останалите сървъри добавяме в xmpp клъстера с команда от вида:

xmpp cluster join

Проверяваме на всеки сървър успешността на създаването на 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]. В полето Домейн 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 Bridge успешно е свързана към услугата XMPP.

Web Bridge

На всеки сървър на клъстера активираме услугата Web Bridge с командата:

webbridge listen a:443

Конфигурираме Web Bridge услугата с файловете на сертификатите с команда от вида:

webbridge certs

Web Bridge поддържа HTTPS. Той ще пренасочва HTTP към HTTPS, ако е настроен да използва „http-redirect”.
За да активирате пренасочването на HTTP, използвайте следната команда:

webbridge http-redirect enable

За да даде на Call Bridge да разбере, че Web Bridge може да се доверява на връзките от Call Bridge, използвайте командата:

webbridge trust

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

Такава картина трябва да бъде на всеки сървър на клъстера.


Сега трябва да създадем потребител с роля „appadmin“, той ни е необходим, за да можем да конфигурираме нашия клъстер(!), а не всеки отделен сървър в клъстера, така че настройките ще бъдат приложени равно на всеки сървър, произвеждайки ги само веднъж.


За по-нататъшна конфигурация ще използваме Postman.

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

За да изпращате команди на сървърите на CMS, е необходимо да зададете правилната кодировка.

Посочваме Webbridge с командата. POST с параметъра url и стойността cms.example.com



В самия webbridge посочваме необходимите параметри: гостен достъп, защитен достъп и др.

Call Bridge Groups

По подразбиране CMS не винаги използва максимално ефективно наличните й ресурси за конференционни връзки.

Например, за среща с трима участници, всеки участник може да се окаже на три различни Call Bridge. За да могат тези трима участници да комуникират помежду си, Call Bridge автоматично ще установи връзки между всички сървъри и клиенти в едно и също пространство, така че да изглежда, че всички клиенти са на един и същи сървър. За съжаление, недостатък на това е, че една конференция от 3 души сега ще консумира 9 медийни портове. Това явно е неефективно използване на ресурсите. Освен това, когато Call Bridge наистина е претоварен, механизмът по подразбиране е да продължи да приема обаждания и да предоставя услуги с намалено качество на всички абонати на този Call Bridge.

Тези проблеми се решават с помощта на функцията 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 Bridge за по-ефективно използване на ресурсите на кластера Cisco Meeting Server.

Импорт на потребители от Active Directory

Услугата Web Admin разполага с секция за конфигурация на LDAP, но тя не предоставя сложни параметри за конфигурация и информацията не се запазва в кластерната база данни, затова настройката трябва да се извърши ръчно на всеки сървър чрез уеб интерфейса или чрез API, и за да не ни е нужно да 'ставаме три пъти', ще зададем данните чрез API.

Използвайки URL адреса за достъп cms01.example.com:445/api/v1/ldapServers създаваме обект на LDAP сървър, посочвайки параметри като:

• IP адрес на сървъра
• номер на порта
• потребителско име
• парола
• сигурен

Сигурен — true или false избираме в зависимост от порта, 389 — незащитен, 636 — защитен.


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

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

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

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

coSpaceNameMapping създава име на space-а в CMS на база полето displayName. Този атрибут, заедно с атрибута coSpaceUriMapping, са нужни за създаването на space за всеки потребител.

coSpaceUriMapping определяема потребителската част на URI, свързана с личното пространство на потребителя. Някои домейни могат да бъдат конфигурирани за задаване в пространството. Ако потребителската част съвпада с това поле за някой от тези домейни, извикването ще бъде насочено към пространството на този потребител.

coSpaceSecondaryUriMapping определя втори URI, за да достигне пространството. Това може да се използва за добавяне на числов псевдоним за маршрутизиране на извикванията в пространството на импортирания потребител, като алтернатива на буквено-цифровия URI, определен в параметъра coSpaceUriMapping.

Сървърът LDAP и сопоставянето на LDAP са настроени. Сега е необходимо да ги свържете, създавайки LDAP източник.

Използвайки URL адреса за достъп cms01.example.com:445/api/v1/ldapSource създаваме обект LDAP Source, задавайки параметри като:

• сървер
• сопоставяне
• baseDn
• filter

Сега, когато настройката на LDAP е завършена, можете да извършите ръчна синхронизация.

Правим това или в Web-интерфейса на всеки сървър, натискайки Синхронизиране сега в раздела 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 може динамично да създава пространство в CMS, така че всяко извикване да може да достигне до CMS и да съответства на правилото за входящи извиквания, което е предназначено за пространствата.

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

SIP Security Profile:


Транки:


Всеки транк изглежда еднакво:




Conference Bridge


Всеки Conference Bridge изглежда еднакво:


Route Group


Route List


Media Resource Group


Media Resource Group List

Правила за повиквания

В отличие от по-усъвършенстваните системи за управление на повиквания, като Unified CM или Expressway, за новите повиквания CMS разглежда домейна само в полето SIP Request-URI. Така че, ако SIP INVITE е предназначен за sip: user@domain.com, 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 конференция

На скрийншота е видно зле (не знам как да направя по-добре), затова ще напиша лог така:

Информация	127.0.0.1:35870: API потребител "api" създаде ново пространство 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Информация	извикването за създаване не успя да намери coSpace -- опитва се да извлече от базата данни

Информация	API "001036270012" Space GUID: 7986bb6c-af4e-488d-9190-a75f16844e44  Call GUID: 93bfb890-646c-4364-8795-9587bfdc55ba  Call Correlator GUID: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66  Вътрешен G

Информация	127.0.0.1:35872: API потребител "api" създаде ново извикване 93bfb890-646c-4364-8795-9587bfdc55ba

Информация	извикване 7: идващ SIP призив от "sip:672@172.x.x.x" до локален URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"

Информация	API крак на извикването bc0be45e-ce8f-411c-be04-594e0220c38e в извикване 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API извикване 93bfb890-646c-4364-8795-9587bfdc55ba)

Информация	конференция 434f88d0-8441-41e1-b6ee-6d1c63b5b098 има контрол/медия GUID: fb587c12-23d2-4351-af61-d6365cbd648d

Информация	конференция 434f88d0-8441-41e1-b6ee-6d1c63b5b098 наречена "001036270012"

Информация	извикване 7: конфигурирано - API крак на извикването bc0be45e-ce8f-411c-be04-594e0220c38e с SIP идентификатор на извикването "7e309680-cd217a6a-f237-e88214ac@172.x.x.x"

Информация	извикване 7: настройка на UDT RTP сесия за DTLS (комбинирани медии и контрол)
Информация	конференция "001036270012": нешифровани крака на извикването вече присъстват

Информация	участник "672@172.x.x.x" се присъедини към пространството 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Информация	участник "672@172.x.x.x" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) се присъедини към конференция 434f88d0-8441-41e1-b6ee-6d1c63b5b098 чрез SIP

Информация	извикване 8: идващ SIP призив от "sip:690@172.x.x.x" до локален URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"

Информация	API крак на извикването db61b242-1c6f-49bd-8339-091f62f5777a в извикване 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API извикване 93bfb890-646c-4364-8795-9587bfdc55ba)

Информация	извикване 8: конфигурирано - API крак на извикването db61b242-1c6f-49bd-8339-091f62f5777a с SIP идентификатор на извикването "7e309680-cd217a6a-f238-e88214ac@172.x.x.x"

Информация	извикване 8: настройка на UDT RTP сесия за DTLS (комбинирани медии и контрол)

Информация	извикване 9: идващ SIP призив от "sip:673@172.x.x.x" до локален URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"

Информация	API крак на извикването 37a6e86d-d457-47cf-be24-1dbe20ccf98a в извикване 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API извикване 93bfb890-646c-4364-8795-9587bfdc55ba)

Информация	извикване 9: конфигурирано - API крак на извикването 37a6e86d-d457-47cf-be24-1dbe20ccf98a с SIP идентификатор на извикването "7e309680-cd217a6a-f239-e88214ac@172.x.x.x"

Информация	извикване 9: настройка на UDT RTP сесия за DTLS (комбинирани медии и контрол)
Информация	извикване 8: компенсиране за отдалечен край, който не съвпада с типовете полезен товар

Информация	участник "690@172.x.x.x" се присъедини към пространството 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Информация	участник "690@172.x.x.x" (289e823d-6da8-486c-a7df-fe177f05e010) се присъедини към конференция 434f88d0-8441-41e1-b6ee-6d1c63b5b098 чрез SIP

Информация	извикване 7: компенсиране за отдалечен край, който не съвпада с типовете полезен товар
Информация	извикване 8: режим на несъответствие на типовете полезен товар 1/0
Информация	извикване 8: отговаряне на предложението в режим на несъответствие на типовете полезен товар
Информация	извикване 8: получено последващо предложение за един кодек
Информация	извикване 8: режим на несъответствие на типовете полезен товар 1/0
Информация	извикване 8: отговаряне на предложението в режим на несъответствие на типовете полезен товар
Информация	извикване 8: изпращане на отговор на допълнителното предложение с един кодек
Информация	извикване 9: компенсиране за отдалечен край, който не съвпада с типовете полезен товар

Информация	участник "673@172.x.x.x" се присъедини към пространството 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Информация	участник "673@172.x.x.x" (d27e9a53-2c8a-4e9c-9363-0415cd812767) се присъедини към конференция 434f88d0-8441-41e1-b6ee-6d1c63b5b098 чрез SIP

Информация	извикване 9: BFCP (роля на клиента) сега активна
Информация	извикване 9: изпращане на BFCP приветствие като клиент след получаване на приветствие, когато BFCP не е активен
Информация	извикване 9: BFCP (роля на клиента) сега активна
Информация	извикване 7: приключване; отдалечен SIP разпад - свързано за 0:13
Информация	извикване 7: унищожаване на API крак на извикването bc0be45e-ce8f-411c-be04-594e0220c38e

Информация	участник "672@x.x.x" напусна пространството 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Информация	извикване 9: на пауза
Информация	извикване 9: режим на несъответствие на типовете полезен товар 1/0
Информация	извикване 9: отговаряне на предложението в режим на несъответствие на типовете полезен товар
Информация	извикване 8: на пауза
Информация	извикване 8: получено последващо предложение за един кодек
Информация	извикване 8: режим на несъответствие на типовете полезен товар 1/0
Информация	извикване 8: отговаряне на предложението в режим на несъответствие на типовете полезен товар
Информация	извикване 8: изпращане на отговор на допълнителното предложение с един кодек
Информация	извикване 9: приключване; отдалечен SIP разпад - свързано за 0:12

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


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

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


Правила за изходящи обаждания

За да се разреши на потребителите да извършват изходящи обаждания в кластера Unified CM, е необходимо да се настройват правилата за изходящи свързвания. Домейнът на крайни точки, регистрирани в Unified CM, като Jabber, е example.com. Обажданията в този домейн трябва да бъдат насочвани като стандартни SIP обаждания към възлите за обработка на обаждания в Unified CM. Основният сървър е cucm-01.example.com, а допълнителният е cucm-02.example.com.

Първото правило описва елементарната маршрутизация на обажданията между сървідрите в кластера.

Поле Local от домейн отговаря за това, което ще се показва в SIP-URI на звънеца след символа «@». Ако го оставим празен, след символа «@» ще бъде IP адресът на CUCM, през който преминава повикването. Ако посочим домейн, след символа «@» ще бъде съответно домейнът. Това е необходимо, за да има възможност за обратно позвъняване, в противен случай ще бъде невъзможно да се върнете обратно по SIP-URI име@ip-адрес.

Позвъняване, когато е посочен Local от домейн


Позвъняване, когато НЕ е посочен Local от домейн


Задължително посочете явно Encrypted или Unencrypted за изходящи повиквания, тъй като с параметър Auto нищо не работи.

Recording

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

Тъй като имаме клъстер и лицензията трябва да бъде "разстегната" на всичките три сървъра в клъстера. Тогава просто в личния кабинет асоциираме (добавяме) MAC адресите на a-интерфейсите на всички CMS сървъри, включени в клъстера.

И такава картина трябва да бъде на всеки сървър в клъстера

Всъщност сценарии за разполагане на Recorder са няколко, но ще се придържаме към следния:


Преди да настроите Recorder, е необходимо да подготвите място, където ще се записват видеоконференциите. Всъщност ето го линк, как да настроите всичко за Recording. Ще акцентирам на важните моменти и детайли:

1. По-добре е да подадете сертификат от първия сървър в клъстера.
2. Грешката «Recorder unavailable» може да възникне, тъй като е посочен неправилен сертификат в Recorder Trust.
3. Записът може да не протича, ако за запис е посочена не кореновата директория в NFS.

Понякога възниква необходимост автоматично да се записва конференция на един конкретен потребител или пространство.

За целта се създават два CallProfile:
С деактивирана функция за запис


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


След това към необходимо пространство «прикрепваме» CallProfile с автоматична функция за запис.


В CMS е установено, че ако CallProfile е явно свързан с конкретни space'ове, той функционира само за тези конкретни 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