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

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


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

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

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

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

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

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

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

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

• База данни: позволява обединяването на някои конфигурации, като абонатна група, пространства за потребители и самите потребители. Поддържа клъстериране само за висока наличност (един майстор).
• Call Bridge: услуга за аудио- и видеоконференции, която осигурява пълен контрол върху управлението и обработката на повикванията и мултимедийните процеси. Поддържа клъстериране за висока наличност и мащабируемост.
• XMPP server: отговаря за регистрацията и аутентификацията на клиентите, използващи приложението Cisco Meeting Application и\/или WebRTC(реално време, или просто в браузъра), както и за междупродаваните сигнализации. Може да бъде клъстеризиран само за висока наличност.
• 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.

В ръководствата за разгръщане от 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 трафик, чувствителен към забавяния и загуба на пакети, в повечето случаи се препоръчва да се настрои качеството на услугата (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 ms в двете посоки между който и да е член на клъстера. Това ограничение е по-строго от това за клъстеризацията на 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 записваме обобщеното име на нашите сървъри. Например, ако хостовете на нашите сървъри server01, server02, server03, то CN ще бъде server.example.com

Същото правим и на останалите два сървъра с разликата, че в командите ще бъдат съответните «хостове»

Създаваме две искания за сертификати, които ще се използват от службата 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. Файл с трите «индивидуални» сертификати.

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

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

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

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

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

database cluster certs

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

database cluster localnode a

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

database cluster initialize

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

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

database cluster join

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

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

database cluster status

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

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

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

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

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 и свързани функции, които могат да се използват за допълнително управление.

Клъстеризацията на 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-a сертификата на всеки сървър, файлът на който съдържа всички сертификати на нашите сървъри, които сме слели в този файл в началото, с команда от вида:

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 за свързване с него. Тази конфигурация се извършва чрез уеб администратора.

Отиваме на всеки сървър в 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

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 автоматично ще създаде връзки между всички сървъри и клиенти в едно и също Space, за да изглежда всичко така, сякаш всички клиенти са на един сървър. За съжаление, недостатък на това е, че една конференция от 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 адрес на сървъра
• номер на порта
• име на потребителя
• парола
• secure

Secure — 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 на потребителя. Обърнете внимание, че вземате sAMAccountName и добавяте домейна conf.pod6.cms.lab в края му, защото това е входът, който вашите потребители ще използват за достъп до CMS.

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

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

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

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

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

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

• server
• съответствие
• baseDn
• филтър

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

Правим това или в уеб интерфейса на всеки сървър, натискайки Синхронизиране сега в секцията 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 Resource Group и Media Resource Group List, а в Cisco Meeting Server’e да се добавят леко правила за маршрутизиране.

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 извикване leg bc0be45e-ce8f-411c-be04-594e0220c38e в обаждане 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

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

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

Информация	извикване 7: конфигурирано - API call leg bc0be45e-ce8f-411c-be04-594e0220c38e с SIP call ID "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 call leg db61b242-1c6f-49bd-8339-091f62f5777a в обаждане 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Информация	извикване 8: конфигурирано - API call leg db61b242-1c6f-49bd-8339-091f62f5777a с SIP call ID "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 call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a в обаждане 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Информация	извикване 9: конфигурирано - API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a с SIP call ID "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 hello като клиент след получаване на hello, когато BFCP не е активен
Информация	извикване 9: BFCP (роля на клиента) сега активен
Информация	извикване 7: завършване; отдалечено SIP разпадане - свързано за 0:13
Информация	извикване 7: унищожаване на API call leg 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 нищо не работи.

Запис

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

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

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

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


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

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

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

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


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


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


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