Cisco Meeting Server 2.5.2. Клъстер в мащабируем и устойчив режим със запис на видеоконференция

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


теорияКато цяло има три типа внедряване на CMS сървър:

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

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

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

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

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

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

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

• База данни: позволява ви да комбинирате някои конфигурации като план за набиране, потребителски пространства и самите потребители. Поддържа клъстериране само за висока наличност (единичен главен).
• мост за повикване: услуга за аудио и видео конферентна връзка, носеща пълен контрол върху управлението и обработката на разговори и мултимедийни процеси. Поддържа групиране за висока наличност и мащабируемост.
• XMPP сървър: отговорен за регистриране и удостоверяване на клиенти, използващи приложението за срещи на Cisco и/или WebRTC(комуникация в реално време или просто в браузъра), както и междукомпонентна сигнализация. Може да се групира само за висока наличност.
• уеб мост: Осигурява клиентски достъп до WebRTC.
• loadbalancer: Осигурява единична точка за свързване за приложенията за срещи на Cisco в режим Single Split. Слуша външния интерфейс и порта за входящи връзки. По същия начин инструментът за балансиране на натоварването приема входящи TLS връзки от XMPP сървъра, чрез който може да превключва TCP връзки от външни клиенти.
  В нашия сценарий няма да е необходимо.
• TURN сървър: Осигурява технология за байпас на защитната стена, която позволява
  окачете нашия CMS зад защитна стена или NAT, за да свържете външни клиенти, използвайки приложението за срещи на Cisco или SIP устройства. В нашия сценарий няма да е необходимо.
• Уеб администратор: Административен интерфейс и API достъп, включително за ad hoc Unified CM конференции.

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

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

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

В допълнение към горното, протоколът SFTP за прехвърляне на файлове - обикновено лицензи, сертификати или регистрационни файлове - към и от CMS.

В ръководствата за внедряване от Cisco на английски и бяло пише, че клъстерът трябва да бъде внедрен най-малко три сървъри (възли) в контекста на бази данни. защото само с нечетен брой възли ще работи механизмът за избор на нов Database Master и като цяло Database Master има връзка с по-голямата част от базата данни на CMS сървъра.

И както показва практиката, два сървъра (възли) наистина не са достатъчни. Механизмът за избор работи, когато главният се рестартира, подчиненият сървър става главен само след като рестартираният сървър бъде повдигнат. Въпреки това, ако в клъстер от два сървъра главният сървър внезапно „изгасне“, тогава подчинения сървър няма да стане главен, а ако подчинения „изгасне“, тогава оставащият главен сървър ще стане подчинен.

Но в контекста на XMPP наистина би било необходимо да се събере клъстер от три сървъра, защото ако, например, деактивирате услугата XMPP на един от сървърите, в които XMMP е в състояние Leader, тогава на останалия XMPP сървър той ще остане в състояние Follower и връзките на CallBridge към XMPP ще отпаднат, защото CallBridge се свързва изключително с XMPP със статус Leader. И това е критично, защото. никакво обаждане няма да премине.

Също така в същите ръководства за внедряване е демонстриран клъстер с един XMPP сървър.

И като вземем предвид горното, става ясно защо: работи, защото е в режим на отказ.

В нашия случай XMPP сървърът ще присъства и на трите възела.

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

DNS записи

Преди да започнете да конфигурирате сървъри, трябва да създадете DNS записи А и SRV видове:

Имайте предвид, че нашите DNS записи имат два домейна example.com и конф.example.com. Example.com е домейн, който всички абонати на Cisco Unified Communication Manager могат да използват за своите URI, които е вероятно да присъстват във вашата инфраструктура или е вероятно да присъстват. Или домейнът example.com съвпада със същия домейн, който потребителите използват за своите имейл адреси. Или клиентът на Jabber на вашия лаптоп може да има URI [имейл защитен]. Домейн конф.example.com е домейнът, който ще бъде конфигуриран за потребителите на Cisco Meeting Server. Домейнът на Cisco Meeting Server ще бъде конф.example.com, така че същият потребител на Jabber ще трябва да използва URI user@, за да влезе в Cisco Meeting Serverконф.example.com.

Основна конфигурация

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

QoS

Тъй като CMS генерира в реално време трафик, който е чувствителен към закъснения и загуба на пакети, в повечето случаи се препоръчва да конфигурирате качеството на услугата (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 <name>

И рестартираме.


Това завършва основната конфигурация.

Сертификати

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

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

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

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

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

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

Клъстерът на базата данни изисква сертификат за специален сървър и сертификат за клиент. Те трябва да бъдат подписани със сертификати, обикновено вътрешен частен CA. Тъй като всеки член на клъстера на базата данни може да стане главен, двойките сертификати на сървъра на базата данни и клиента (съдържащи публичния и частния ключ) трябва да бъдат копирани на всички сървъри, така че да могат да поемат самоличността на клиента или сървъра на базата данни. В допълнение, основният 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

Правим същото на останалите два сървъра с тази разлика, че командите ще съдържат съответните "имена на хостове"

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

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

pki csr dbclusterclient CN:postgres

където dbclusterserver и dbclusterclient имената на нашите заявки и бъдещи сертификати, име на хост1(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 <server_key> <server_crt> <client_key> <client_crt> <ca_crt>

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

database cluster localnode a

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

database cluster initialize

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

Изпълняваме същата процедура, само вместо командата инициализиране на клъстер на база данни въведете команда като:

database cluster join <ip address existing master>

където ip адрес съществуващ главен ip адрес на CMS сървъра, на който е инициализиран клъстерът, просто Master.

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

database cluster status

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

В резултат на това се оказва, че първият ни сървър е Master, останалите са Slaves.

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

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

webadmin listen a 445

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

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

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

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

webadmin enable

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

Обадете се на 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 е различно от клъстерирането на база данни или XMPP. Call Bridge Cluster може да поддържа от 2 до 8 възела без никакви ограничения. Той осигурява не само излишък, но и балансиране на натоварването, така че конференциите да могат да се разпределят активно между сървърите на Call Bridge с помощта на интелигентно разпределение на повикванията. CMS има допълнителни функции, Call Bridge групи и свързани функции, които могат да се използват за по-нататъшно управление.

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

1. Преминаваме през мрежата в Configuration> Cluster.
2. В самоличност на мост за обаждане като уникално име въведете callbridge[01,02,03], съответстващо на името на сървъра. Тези имена са произволни, но трябва да са уникални за този клъстер. Те са описателни, тъй като показват, че са идентификатори на сървър [01,02,03].
3. В Клъстерни мостове за повикване въведете URL адресите на уеб администратора на нашите сървъри в клъстера, CMS[01,02,03].example.com:445, в полето Адрес. Не забравяйте да посочите порта. Можете да оставите SIP домейна на Peer link празен.
4. Добавяме сертификат към доверието на CallBridge за всеки сървър, чийто файл съдържа всички сертификати на нашите сървъри, които обединихме в този файл в самото начало, с команда като:

callbridge trust cluster <trusted cluster certificate bundle>

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

callbridge restart

В резултат на всеки сървър трябва да получите следната картина:

XMPP клъстер

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

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

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

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

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

xmpp listen a

Услугата XMPP изисква уникален домейн. Това е входът за потребителите. С други думи, когато потребител се опита да влезе с помощта на приложението CMA (или чрез WebRTC клиент), той въвежда userID@logindomain. В нашия случай това ще бъде userid@конф.example.com. Защо не е само example.com? В нашето конкретно внедряване избрахме нашия Unified CM домейн, който потребителите на Jabber ще използват в Unified CM като example.com, така че се нуждаем от различен домейн за потребителите на CMS, за да маршрутизираме повиквания към и от CMS през SIP домейните.

Настройте XMPP домейн с команда като:

xmpp domain <domain>

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

xmpp enable

В услугата XMPP трябва да създадете идентификационни данни за всеки Call Bridge, който ще се използва при регистрация в услугата XMPP. Тези имена са произволни (и не са свързани с уникалните имена, които сте конфигурирали за клъстериране на мост за повикване). Трябва да добавите три моста за повикване на един XMPP сървър и след това да въведете тези идентификационни данни на други XMPP сървъри в клъстера, тъй като тази конфигурация не се вписва в базата данни на клъстера. По-късно ще конфигурираме всеки Call Bridge да използва това име и тайна, за да се регистрира в услугата XMPP.

Сега трябва да настроим услугата XMPP на първия сървър с три Call Bridges 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 и в полето Уникално име на Call Bridge пишем уникалните имена на Call Bridge, съответстващи на сървъра callbridge [01,02,03]... В полето домейн conf.example.com и съответните пароли, можете да ги шпионирате
на всеки клъстерен сървър с командата:

xmpp callbridge list

Оставете полето "Сървър" празно. Калбридж ще извърши DNS SRV търсене за _xmpp-component._tcp.conf.example.comза да намерите наличен XMPP сървър. IP адресите за свързване на callbridge към XMPP може да се различават на всеки сървър, зависи от това какви стойности се връщат към заявката за запис _xmpp-component._tcp.conf.example.com callbridge, което от своя страна зависи от настройките за приоритет на този DNS запис.

След това отидете на Статус > Общи, за да видите дали услугата Call Bride успешно се е свързала с услугата XMPP.

уеб мост

На всеки сървър на клъстер активирайте услугата 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“, необходим ни е, за да можем да конфигурираме нашия клъстер (!), А не всеки сървър от клъстера поотделно, така че настройките ще се прилагат еднакво към всеки сървър, въпреки че ще се правят веднъж.


За по-нататъшно персонализиране ще използваме пощаджия.

За упълномощаване изберете Основно в секцията Упълномощаване

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

Посочете Webbridge с командата ПУСНИ с параметър URL и смисъл cms.example.com



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

Обадете се на мостови групи

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

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

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

За решаване на проблема с повторното свързване бяха въведени три конфигурируеми ограничения на натоварването за всеки Call Bridge:

ограничение на натоварването е максималното числово натоварване за конкретен 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/система/конфигурация/клъстер

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

Първи callbridge

Втори мост за повикване

Трети мост за повикване


По този начин конфигурирахме групата Call Brdige да използва по-ефективно ресурсите на клъстера на Cisco Meeting Server.

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

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

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

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

Сигурен - вярно или невярно в зависимост от порта, 389 - не е защитен, 636 - защитен.


Съпоставяне на опциите за LDAP източник към атрибути в Cisco Meeting Server.
LDAP картографирането картографира атрибутите в LDAP директорията към атрибутите в CMS. Всъщност атрибути:

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

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

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

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

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

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

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

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

• сървър
• картография
• baseDn
• филтриране

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

Правим това или в уеб интерфейса на всеки сървър, като щракнем Синхронизирайте сега раздел Active Directory


или чрез API командата ПУСНИ използване на 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, три конферентни моста, да посочите три имена на субекти в SIP профила за сигурност, група маршрути, списък с маршрути, група за медийни ресурси и списък с групи за медийни ресурси и да добавите някои правила за маршрутизиране към Cisco Сървър за срещи.

SIP защитен профил:


Сандъци:


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




Конферентен мост


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


Група маршрути


Списък с маршрути


Група за медийни ресурси


Списък с групи от медийни ресурси

Правила за обаждане

За разлика от по-усъвършенстваните системи за контрол на повиквания като Unified CM или Expressway, за нови повиквания CMS търси само домейна в полето SIP Request-URI. Така че, ако SIP INVITE е за sip: [имейл защитен], CMS се интересува само от domain.com. CMS следва тези правила, за да определи къде да насочи повикване:

1. Първо, CMS се опитва да съпостави SIP домейна с домейните, конфигурирани в правилата за обработка на входящи повиквания. След това тези повиквания могат да бъдат насочени към („целеви“) пространства или конкретни потребители, вътрешни IVR или директно интегрирани дестинации на Microsoft Lync/Skype за бизнеса (S4B).
2. Ако няма съвпадение в правилата за обработка на входящи повиквания, CMS ще се опита да съпостави домейна, конфигуриран в таблицата за пренасочване на повиквания. Ако се установи съвпадение, правилото може изрично да отхвърли повикването или да го пренасочи. През това време CMS може да пренапише домейна, което понякога е полезно за извикване на домейни на Lync. Можете също така да изберете да преминете, което означава, че нито едно от полетата няма да бъде променено допълнително, или да използвате вътрешен план за набиране на 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. Така че като минимум искате обажданията към този домейн да са насочени към пространства. Ще трябва също така да настроите правила за всичко, което е за FQDN (и евентуално дори IP адрес) на всеки от CMS сървърите. Нашето външно управление на повикванията, Unified CM, ще настрои SIP канали, предназначени за всеки от CMS сървърите поотделно. Дали дестинацията на тези SIP канали е IP адрес или FQDN на сървъра ще определи дали CMS трябва да бъде конфигуриран да приема повиквания, насочени към неговия IP адрес или FQDN.

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


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

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

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

Област Локално от домейн отговаря за това какво ще се показва в SIP-URI на обаждащия се на този, който се обажда след символа “@”. Ако го оставим празно, тогава след символа "@" ще има ip-адреса на CUCM'a, през който минава това повикване. Ако посочим домейн, тогава след символа “@” всъщност ще има домейн. Това е необходимо, за да можете да извършите обратно повикване, в противен случай няма да е възможно обратно повикване чрез SIP-URI име@ip-адрес.

Обадете се, когато е посочено Локално от домейн


Обади се кога НЕ посочено Локално от домейн


Не забравяйте изрично да укажете Шифровано или Нешифровано за изходящи повиквания, защото нищо не работи с параметъра Auto.

запис

Видеоконференциите се записват от Record-сървъра. Recorder е точно същия Cisco Meeting Server. Рекордерът не изисква никакви лицензи, за да бъде инсталиран върху себе си. Лицензите за запис са необходими за сървъри, работещи с услуги CallBridge, т.е. Лицензът за запис е необходим и трябва да се приложи към компонента CallBridge, а не към сървъра, на който се изпълнява записващото устройство. Рекордерът се държи като клиент на Extensible Messaging and Presence Protocol (XMPP), така че XMPP сървърът трябва да бъде активиран на сървъра, хостващ CallBridge.

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

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

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


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

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

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

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


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


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


В CMS е така установено, че ако CallProfile е изрично свързан с някои интервали или интервали, тогава този CallProfile работи само за тези конкретни пространства. И ако CallProfile не е обвързан с никакво пространство, тогава по подразбиране той се прилага към онези пространства, към които изрично не е обвързан 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

Източник: www.habr.com