Cisco Meeting Server 2.5.2. Cluster v režimu škálovatelný a odolný s funkcí nahrávání videokonferencí

V tomto vydání ukážu a vysvětlím některé nuance nastavení CMS serveru v režimu vysoce dostupného clustera.


TeorieCelkově existují tři typy nasazení CMS serveru:

• Single Combined(Jednotný kombinovaný), tzn. je to jeden server, na kterém běží všechny potřebné služby. Ve většině případů je tento typ nasazení použitelný pouze pro přístup interních klientů a v malých prostředích, kde omezení škálovatelnosti a redundancy jednoho serveru nejsou kritickým problémem, nebo v situacích, kdy CMS plní pouze určité funkce, jako jsou speciální konference na Cisco UCM.

  Přibližný schématický diagram fungování:
  

• Single Split(Jednotný rozdělený) rozšiřuje předchozí typ nasazení přidáním samostatného serveru pro externí přístup. Ve starších nasazeních to znamenalo nasazení serveru CMS v demilitarizované zóně (DMZ), kde by měli externí klienti k němu přístup, a jednoho serveru CMS v jádru sítě, kde mají přístup k CMS interní klienti. Tento specifický model nasazení nyní nahrazuje takzvaný typ Single Edge, který se skládá ze serverů Cisco Expressway, které buď mají, nebo budou mít mnohé z vlastností obcházení Firewallu, takže klienti nemusí přidávat dedikovaný okrajový server CMS.

  Přibližný schématický diagram fungování:
  

• Scalable and Resilient(Škálovatelný a vysoce dostupný) tento typ zahrnuje redundantnost pro každou komponentu, což umožňuje systému růst s vašimi potřebami až k maximální kapacitě, přičemž zajistí redundanci v případě selhání. Také využívá koncept Single Edge pro zajištění bezpečného externího přístupu. To je typ, který prozkoumáme v tomto vydání. Pokud pochopíme, jak nasadit cluster tohoto typu, nejen budeme rozumět jiným typům nasazení, ale také budeme moci pochopit, jak vytvářet clustery CMS serverů s ohledem na potenciální růst potřeb.

Než přejdeme k nasazení, je třeba pochopit některé základní věci, a to

Základní softwarové komponenty CMS:

• Databáze: umožňuje sloučit některé konfigurace, jako jsou skupiny účastníků, uživatelské prostory a samotní uživatelé. Podporuje clustering pouze pro vysokou dostupnost (jeden master).
• Call Bridge: služba pro audio- a videokonference, zajišťující úplnou kontrolu nad řízením a zpracováním hovorů a multimediálních procesů. Podporuje clusterování pro vysokou dostupnost a škálovatelnost.
• XMPP server: odpovídá za registraci a autentizaci klientů používajících aplikaci Cisco Meeting Application a/nebo WebRTC (real-time communication, neboli jednoduše v prohlížeči), stejně jako mezi komponenty signalizaci. Může být clusterován pouze pro vysokou dostupnost.
• Web Bridge: poskytuje přístup klientů do WebRTC.
• Loadbalancer: zajišťuje jednotný bod připojení pro aplikace Cisco Meeting App v režimu Single Split. Naslouchá na externím rozhraní a portu pro příchozí spojení. Stejně tak load balancer přijímá příchozí TLS spojení z XMPP serveru, přes které může přepínat TCP spojení od externích klientů.
  V našem scénáři nebude potřeba.
• TURN server: zajišťuje technologii obcházení firewallu, která umožňuje
  vytáhnout náš CMS za firewall nebo NAT pro připojení externích klientů používajících Cisco Meeting App nebo SIP zařízení. V našem scénáři nebude potřeba.
• Web Admin: administrativní rozhraní a přístup k API, včetně pro speciální konference Unified CM.

Režimy konfigurace

Na rozdíl od většiny ostatních produktů Cisco, Cisco Meeting Server podporuje tři metody nastavení, které umožňují nasadit jakýkoliv typ nasazení.

• Příkazový řádek (CLI): rozhraní příkazového řádku, známé jako MMP, pro úkoly počátečního nastavení a certifikátů.
• Webový administrátor: především pro konfiguraci související s CallBridge, zvláště při nastavování jednoho neclusterovaného serveru.
• REST API: používá se pro nejnáročnější úkoly konfigurace a úkoly související s clusterovou databází.

Kromě výše uvedeného se používá protokol SFTP pro přenos souborů – obvykle licencí, certifikátů nebo protokolů – na server CMS a z něj.

V deployment guidech od Cisco je vyvráceno černé na bílém, že cluster by měl být nasazen minimálně ze tří serverů (nodů) v kontextu databází. Jen s neparitním počtem uzlů bude fungovat mechanismus výběru nového Master databáze, a vůbec Master databáze má spojení s většinou databáze CMS serveru.

A jak ukazuje praxe, dva servery (uzly) skutečně nejsou zcela dostatečné. Mechanismus výběru funguje při restartu Mastera, Slave server se stává Masterem výhradně po spuštění restartovaného serveru. Nicméně, pokud se v clusteru ze dvou serverů Master server náhle "vypne", Slave server se nestane Masterem, a pokud se "vypne" Slave, zbývající Master server se stane Slave.

V kontextu XMPP by však bylo skutečně potřeba vytvořit cluster ze tří serverů, protože pokud například vypnete službu XMPP na jednom ze serverů, kde je XMPP ve stavu Leader, na zbývajícím serveru zůstane XMPP ve stavu Follower a připojení CallBridge k XMPP přestane fungovat, protože CallBridge se připojuje výhradně k XMPP se statusem Leader. To je kritické, protože žádný hovor nebude probíhat.

Také v těchto příručkách pro nasazení je demonstrován cluster s jedním XMPP serverem.

A s vědomím výše uvedeného je jasné proč: funguje, protože v režimu failover.

V našem případě bude XMPP server přítomen na všech třech uzlech.

Předpokládá se, že všechny tři naše servery jsou spuštěny.

DNS záznamy

Než začnete konfigurovat servery, je nutné vytvořit DNS záznamy. A a SRV typů:

Všimněte si, že v našich DNS záznamech jsou přítomny dvě domény example.com a conf.example.com. Example.com je doména, kterou mohou používat všichni abonenti Cisco Unified Communication Managera, který je pravděpodobně ve vaší infrastruktuře přítomen nebo se s vysokou pravděpodobností přítomen bude. Nebo doména example.com odpovídá téže doméně, kterou uživatelé používají pro své e-mailové adresy. A nebo klient Jabber na vašem notebooku může mít URI user@example.com. Doména conf.example.com — je ta doména, která bude nastavena pro uživatele Cisco Meeting Servera. Doménou Cisco Meeting Servera bude conf.example.com, proto pro toho samého uživatele Jabber bude pro přihlášení do Cisco Meeting Serveru potřeba použít URI user@conf.example.com.

Základní konfigurace

Veškerá nastavení popsaná níže jsou uvedena na jednom serveru, ale je třeba je provést na každém serveru clusteru.

QoS

Jelikož CMS generuje real-time Provozování provozu citlivého na latenci a ztrátu paketů většinou doporučuje nastavit kvalitu služeb (QoS). K tomu CMS podporuje označování paketů kódy diferenciovaných služeb (DSCP), které generuje. Prioritizace provozu na základě DSCP závisí na tom, jakým způsobem je provoz zpracováván síťovými komponenty vaší infrastruktury, v našem případě nastavíme náš CMS s typickým rozdělením priorit DSCP na základě osvědčených postupů QoS.

Na každém serveru zadáme tyto příkazy

dscp 4 multimédia 0x22
dscp 4 multimediální-streaming 0x22
dscp 4 hlas 0x2E
dscp 4 signaling 0x1A
dscp 4 nízká-latenční 0x1A

Tak byl celý video provoz označen AF41 (DSCP 0x22), celý hlasový provoz označen EF (DSCP 0x2E), jiné typy nízkolatentního provozu, jako SIP a XMPP, používají AF31 (DSCP 0x1A).

Kontrolujeme:

NTP

Síťový protokol času (NTP) je důležitý nejen pro zajištění přesných časových razítek hovorů a konferencí, ale také pro ověřování certifikátů.

Přidáváme NTP servery vaší infrastruktury příkazem typu

ntp server add

V našem případě jsou tyto servery dva, a proto budou příkazy dva.
Kontrolujeme:

A nastavíme časové pásmo pro náš server

. Vytvořte A-záznam blog a určete pro něj nějakou fiktivní IP (to je oficiální

DNS servery v CMS přidáváme příkazem typu:

dns add forwardzone

V našem případě jsou tyto servery dva, a proto budou příkazy dva.
Kontrolujeme:

Konfigurace síťového rozhraní

Nastavujeme rozhraní příkazem typu:

ipv4  add 
/

Kontrolujeme:

Název serveru (Hostname)

Název serveru nastavujeme příkazem typu:

hostname

A restartujeme.


Na tom je základní konfigurace hotová.

Certifikáty

TeorieCisco Meeting Server vyžaduje šifrovanou komunikaci mezi různými komponenty, a proto jsou certifikáty X.509 vyžadovány pro všechna nasazení CMS. Pomáhají zajistit důvěru v služby/server ostatním serverům/službám.

Pro každou službu je vyžadován certifikát, avšak vytváření samostatných certifikátů pro každou službu může vést k zmatku a zbytečné složitosti. Naštěstí můžeme vygenerovat pár veřejného a soukromého klíče certifikátu a poté je znovu použít pro víc služeb. V našem případě bude stejný certifikát použit pro Call Bridge, server XMPP, Web Bridge a Web Admin. Takže je třeba vytvořit pár veřejného a soukromého klíče certifikátu na každý server v clusteru.

Klastry databází mají však některé specifické požadavky na certifikáty a proto vyžadují vlastní certifikáty, odlišné od certifikátů ostatních služeb. CMS používá certifikát serveru, který je podobný certifikátům používaným jinými servery, ale existuje také certifikát klienta, který se používá pro připojení k databázi. Certifikáty databáze se používají jak pro autentizaci, tak pro šifrování. Místo poskytování uživatelského jména a hesla pro připojení klienta k databázi představuje certifikát klienta, kterému server důvěřuje. Každý server v clusteru databáze používá stejnou dvojici veřejného a soukromého klíče. To umožňuje všem serverům v clusteru šifrovat data tak, aby mohla být dešifrována pouze jinými servery, které také používají stejnou dvojici klíčů.

Aby zálohování fungovalo, klastry databází musí mít alespoň 3 servery, ale ne více než 5, s maximální dobou šíření signálu v obou směrech 200 ms mezi jakýmikoli členy clusteru. Tento limit je přísnější než pro clustering Call Bridge, a proto je často omezujícím faktorem v geograficky distribuovaných nasazeních.

Role databáze pro CMS má řadu unikátních požadavků. Na rozdíl od ostatních rolí vyžaduje certifikát klienta a serveru, přičemž certifikát klienta má specifické pole CN, které je představováno serveru.

CMS používá databázi Postgres s jedním hlavním a několika zcela identickými replikami. V každém okamžiku existuje pouze jedna hlavní databáze ("server databáze"). Ostatní členové clusteru jsou replikami nebo "klienty databáze".

Pro cluster databáze jsou potřeba certifikát dedikovaného serveru a certifikát klienta. Tyto certifikáty by měly být podepsány certifikáty, obvykle interním soukromým certifikačním úřadem. Protože se kterákoli z členů clusteru databáze může stát primárním, dvojice certifikátů databázového serveru a klienta (obsahující veřejný a soukromý klíč) by měly být zkopírovány na všechny servery, aby mohly přijmout identitu klienta nebo databázového serveru. Dále musí být nahrán kořenový certifikát CA, aby bylo zajištěno, že certifikáty klienta a serveru mohou být ověřeny.

Takže formulujeme žádost o certifikát, který bude používán všemi službami serveru kromě databáze (pro to bude zvláštní žádost) příkazem ve tvaru:

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

Do CN zapisujeme zobecněný název našich serverů. Například, pokud jsou hostname našich serverů server01, server02, server03, pak CN bude server.example.com

Totéž uděláme na zbývajících dvou serverech s tím rozdílem, že v příkazech budou odpovídající „hostname’y“

Zformulujeme dvě žádosti o certifikáty, které budou používány službou databáze příkazy ve tvaru:

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

pki csr dbclusterclient CN:postgres

kde dbclusterserver a dbclusterclient název našich žádostí a budoucích certifikátů, hostname1(2)(3) název odpovídajících serverů.

Tento postup provádíme pouze na jednom serveru(!), a certifikáty a odpovídající .key soubory nahrajeme na ostatní servery.

Aktivace režimu klientského certifikátu v AD CS

Ještě je potřeba sloučit certifikáty pro každý server do jednoho souboru.V *NIX:

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

Ve Windows/DOS:

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

A nahrát na každý server:
1. „Individuální“ certifikát serveru.
2. Kořenový certifikát (spolu s mezilehlými, pokud nějaké existují).
3. Certifikáty pro databázi („serverový“ a „klientský“) a soubory s příponou .key, které vznikly při vytváření žádosti pro „serverový“ a „klientský“ certifikát databáze. Tyto soubory by měly být na všech serverech shodné.
4. Soubor všech tří „individuálních“ certifikátů.

Výsledkem by měl být přibližně takový souborový obraz na každém serveru.

Database Cluster

Nyní, když máte všechny certifikáty nahrané na servery CMS, můžete nastavit a aktivovat cluster databázového serveru mezi třemi uzly. Prvním krokem je vybrat jeden server jako hlavní uzel clusteru databáze a jeho kompletní nastavení.

Hlavní databáze

Prvním krokem při nastavování replikace databáze je určení certifikátů, které budou použity pro databázi. To se provádí pomocí příkazu ve tvaru:

database cluster certs

Nyní určíme CMS, jaké rozhraní použít pro clustering databází pomocí příkazu:

database cluster localnode a

Poté inicializujeme databázi clusteru na hlavním serveru příkazem:

database cluster initialize

Klientské uzly databáze

Provádíme stejný postup, jen místo příkazu database cluster initialize zadáváme příkaz ve tvaru:

database cluster join

kde ip address existing master je IP adresa CMS serveru, na kterém byla inicializace clusteru provedena, jednoduše řečeno Mastera.

Kontrolujeme, jak funguje náš cluster databáze na všech serverech, pomocí příkazu:

database cluster status

To samé provedeme i na zbývajícím třetím serveru.

Výsledkem je, že náš první server je Master, ostatní jsou Slave.

Služba webového administrátora

Aktivujeme službu webového administrátora:

webadmin listen a 445

Port 445 je vybrán, protože port 443 je používán pro přístup uživatelů k webovému klientu.

Nastavujeme službu webového administrátora s používáním souborů certifikátů pomocí příkazu ve tvaru:

webadmin certs

A aktivujeme webového administrátora příkazem:

webadmin enable

Pokud je vše v pořádku, obdržíme řádky SUCCESS, které potvrzují, že webový administrátor je správně nastaven pro síť a certifikát. Kontrolujeme funkčnost služby pomocí webového prohlížeče a zadáme adresu webového administrátora, například: cms.example.com:445

Call Bridge Cluster

Call Bridge je jediná služba, která je přítomna v každém nasazení CMS. Call Bridge je hlavním mechanismem konferenčního spojení. Rovněž poskytuje SIP rozhraní, takže hovory mohou být směrovány na něj nebo z něj, například pomocí Cisco Unified CM.

Následující příkazy je třeba provést na každém serveru se správnými certifikáty.
Takže:

Spojujeme certifikáty se službou Call Bridge příkazem ve tvaru:

callbridge certs  []

Přivazujeme služby CallBridge k potřebnému rozhraní příkazem:

callbridge listen a

A restart the service with the command:

callbridge restart

Now that we have configured the Call Bridges, we can set up Call Bridge clustering. Call Bridge clustering is different from database or XMPP clustering. The Call Bridge Cluster can support between 2 to 8 nodes without any restrictions. It provides not only redundancy but also load distribution, allowing conferences to be actively distributed among Call Bridge servers through intelligent call distribution. The CMS has additional features, Call Bridge groups and related functions that can be used for further management.

Call Bridge clustering is primarily configured through the web administrator interface.
The procedure described below needs to be performed on each server in the cluster.
Takže,

1. Log in via web to Configuration > Cluster.
2. In the Call Bridge identity use callbridge[01,02,03] as unique names corresponding to the server names. These names are arbitrary but must be unique for this cluster. They are descriptive as they indicate that these are identifiers for the servers [01,02,03].
3. In Clustered Call Bridges enter the web administrator URLs of our servers in the cluster, cms[01,02,03].example.com:445, in the Address field. Be sure to specify the port. You can leave the Peer link SIP domain blank.
4. Add the certificate of each server to the CallBridge trust, a file that contains all the certificates of our servers that we merged into this file at the very beginning, with a command like:

callbridge trust cluster

A restart the service with the command:

callbridge restart

As a result, each server should look like this:

XMPP Cluster

The XMPP service in the CMS is used to handle all registration and authentication for Cisco Meeting Apps (CMA), including the CMA WebRTC web client. The Call Bridge itself also acts as an XMPP client for authentication purposes and therefore must be configured like other clients. XMPP resilience is a feature supported in production environments starting from version 2.1.

Následující příkazy je třeba provést na každém serveru se správnými certifikáty.
Takže:

We link the certificates to the XMPP service using a command like:

xmpp certs  []

Then define the listening interface with the command:

xmpp listen a

Pro službu XMPP je vyžadována unikátní doména. Je to přihlašovací jméno pro uživatele. Jinými slovy, když se uživatel pokusí přihlásit pomocí aplikace CMA (nebo přes klienta WebRTC), zadá userID@logindomain. V našem případě to bude userid@conf.example.com. Proč to není prostě example.com? V našem konkrétním nasazení jsme vybrali naši doménu Unified CM, kterou uživatelé Jabber budou používat v Unified CM, jako example.com, proto potřebujeme jinou doménu pro uživatele CMS, abychom směrovali hovory do CMS a z CMS přes domény SIP.

Nastavte doménu XMPP pomocí příkazu ve tvaru:

xmpp domain

A aktivujeme službu XMPP příkazem:

xmpp enable

V rámci služby XMPP je třeba vytvořit přihlašovací údaje pro každý Call Bridge, které budou použity při registraci do služby XMPP. Tato jména jsou libovolná (a nejsou spojena s unikátními názvy, které jste nastavili pro clustering mostů hovorů). Na jednom serveru XMPP je třeba přidat tři mosty hovorů a poté tyto přihlašovací údaje zadat na ostatních serverech XMPP v clusteru, protože tato konfigurace není uložena v clusterové databázi. Později nastavíme každý Call Bridge tak, aby používal toto jméno a tajemství pro registraci do služby XMPP.

Nyní musíme nastavit službu XMPP na prvním serveru se třemi Call Bridge’y callbridge01, callbridge02 a callbridge03. Každému účtu budou přidělena náhodná hesla. Později budou zadána na jiných servrech Call Bridge pro přihlášení na tento XMPP server. Zadáme následující příkazy:

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

Na závěr zkontrolujeme, co jsme získali příkazem:

xmpp callbridge list

Přesně stejný obraz by měl být na ostatních serverech po provedení níže uvedených kroků.

Dále přidáme na zbývajících dvou serverech přesně taková nastavení, pouze příkazy

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

Tajemství přidáváme velmi opatrně, aby se do něj náhodou nedostaly například nadbytečné mezery.


Na každém serveru by měl být stejný obraz:

Dále na všech serverech clusteru uvedeme do důvěryhodného souboru obsahujícího všechny tři certifikáty, které jsme vytvořili dříve příkazem ve tvaru:

xmpp cluster trust

Aktivujeme režim xmpp clusteru na všech serverech clusteru příkazem:

xmpp cluster enable

Na prvním serveru clusteru spouštíme vytvoření xmpp clusteru příkazem:

xmpp cluster initialize

Na ostatních serverech přidáváme do xmpp clusteru příkazem ve tvaru:

xmpp cluster join

Kontrolujeme na každém serveru úspěšnost vytvoření XMPP clusteru příkazy:

xmpp status
xmpp cluster status

První server:

Druhý server:

Třetí server:

Připojení Call Bridge k XMPP

Nyní, když je XMPP cluster spuštěn, je třeba nakonfigurovat služby Call Bridge pro připojení k XMPP clusteru. Tato konfigurace se provádí prostřednictvím webového správce.

Na každém serveru přejdeme do Configuration > General a do pole Unique Call Bridge name napíšeme odpovídající serveru unikátní názvy Call Bridge callbridge[01,02,03]. Do pole Doména conf.example.ru a odpovídající hesla, která můžeme zjistit
na jakémkoli serveru clusteru příkazem:

xmpp callbridge list

Pole „Server“ necháme prázdné, Callbridge provede vyhledání DNS SRV pro _xmpp-component._tcp.conf.example.com, aby našel dostupný server XMPP. IP adresy připojení callbridge'i k XMPP se mohou lišit na každém serveru, závisí to na tom, jaké hodnoty se vracejí na dotaz o záznamu _xmpp-component._tcp.conf.example.com callbridge'u, což zase závisí na nastavení priorit pro tento DNS záznam.

Dále přejdeme do Status > General, abychom se ujistili, že služba Call Bride byla úspěšně připojena k službě XMPP.

Web Bridge

Na každém serveru clusteru spouštíme službu Web Bridge příkazem:

webbridge listen a:443

Nastavujeme službu Web Bridge pomocí souborů certifikátů příkazem ve tvaru:

webbridge certs

Web Bridge podporuje HTTPS. Bude přesměrovávat HTTP na HTTPS, pokud je nastaven pro používání „http-redirect“.
Chcete-li aktivovat přesměrování HTTP, použijte následující příkaz:

webbridge http-redirect enable

Aby Call Bridge dal najevo, že Web Bridge může důvěřovat připojením z Call Bridge, použijte příkaz:

webbridge trust

kde to je soubor obsahující všechny tři certifikáty od každého serveru v clusteru.

Takový obrázek by měl být na každém serveru clusteru.


Nyní musíme vytvořit uživatele s rolí „appadmin“, kterou potřebujeme k tomu, abychom mohli konfigurovat náš cluster(!), a ne každý server clusteru zvlášť, takto budou nastavení aplikována stejně na každý server, přičemž budou prováděna pouze jednou.


Pro další konfiguraci budeme používat Postman.

Pro autorizaci vybereme Basic v sekci Authorizace

Pro správné odesílání příkazů na servery CMS je třeba nastavit požadovanou kódování.

Uvádíme Webbridge příkazem. POST s parametrem url a hodnotou cms.example.com



Na samotném webbridge uvádíme potřebné parametry: hostitelský přístup, zabezpečený přístup a další.

Call Bridge Groups

Ve výchozím nastavení CMS nevyužívá vždy maximálně efektivně dostupné zdroje konferenčního spojení.

Například při schůzce se třemi účastníky může každý účastník být na třech různých Call Bridge. Aby tito tři účastníci mohli mezi sebou komunikovat, Call Bridge automaticky navážou spojení mezi všemi servery a klienty ve stejném Space, aby to vypadalo, jako by všichni klienti byli na jednom serveru. Bohužel, nevýhodou toho je, že jedna konference o 3 osobách nyní spotřebovává 9 mediálních portů. To je očividně neefektivní využití zdrojů. Navíc, když je Call Bridge skutečně přetížen, výchozí mechanizmus spočívá v tom, že pokračuje v přijímání hovorů a poskytuje služby s nižší kvalitou všem účastníkům tohoto Call Bridge.

Tyto problémy jsou řešeny funkcí Call Bridge Group. Tato funkce byla představena ve verzi 2.1 softwaru Cisco Meeting Server a byla rozšířena pro podporu vyvažování zatížení jak pro příchozí, tak pro odchozí hovory, Cisco Meeting App (CMA), včetně účastníků WebRTC.

K vyřešení problému s opětovným připojením byla zavedena tři konfigurovatelná zatížení pro každý Call Bridge:

LoadLimit — to je maximální číselné zatížení pro konkrétní Call Bridge. Každá platforma má doporučenou mezní hodnotu zatížení, například 96000 pro CMS1000 a 1,25 GHz na virtuální procesor pro virtuální stroj. Různé hovory spotřebovávají určité množství zdrojů v závislosti na rozlišení a snímkové frekvenci účastníka.
NewConferenceLoadLimitBasisPoints (ve výchozím nastavení 50% loadLimit) — nastavuje limit zatížení serveru, po kterém jsou nové konference odmítány.
ExistingConferenceLoadLimitBasisPoints (ve výchozím nastavení 80% z loadLimit) — hodnota zatížení serveru, po které budou účastníci, kteří se připojují k existující konferenci, odmítnuti.

Zatímco byla tato funkce vyvinuta pro distribuci hovorů a zatížení, mohou být pro Call Bridge Groups také přiřazeny další skupiny, jako jsou servery TURN, servery Web Bridge a zařízení pro nahrávání, což jim umožňuje být správně seskupeny pro optimální využití. Pokud není žádný z těchto objektů přiřazen skupině hovorů, předpokládá se, že jsou k dispozici všem serverům bez určitého prioritizování.

Tyto možnosti se nastavují zde: cms.example.com:445/api/v1/system/configuration/cluster

Dále oznamujeme každému callbridge, do které callbridge skupiny patří:

První callbridge

Druhý callbridge

Třetí callbridge


Takto jsme nastavili skupinu Call Bridge pro efektivnější využití zdrojů clusteru Cisco Meeting Server.

Import uživatelů z Active Directory

Služba Web Admin má sekci konfigurace LDAP, ale nenabízí složité konfigurační možnosti, a informace se neukládají do clusterové databáze, takže je nutné provést nastavení buď ručně na každém serveru prostřednictvím webového rozhraní, nebo prostřednictvím API, a abychom nemuseli „třikrát vstávat“, data budeme i tak zadávat přes API.

Použití URL pro přístup cms01.example.com:445/api/v1/ldapServers vytváříme objekt LDAP Server, přičemž uvádíme parametry jako:

• IP adresa serveru
• číslo portu
• uživatelské jméno
• heslo
• secure

Secure – true nebo false vybíráme v závislosti na portu, 389 – nechráněný, 636 – chráněný.


Mapujeme LDAP parametry zdroje na atributy v Cisco Meeting Server.
Mapování LDAP porovnává atributy v LDAP katalogu s atributy v CMS. Skutečné atributy:

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Popis atributůJID představuje identifikátor přihlášení uživatele do CMS. Vzhledem k tomu, že se jedná o LDAP server Microsoft Active Directory, JID CMS je mapován na sAMAccountName v LDAP, který je vlastně identifikátorem přihlášení uživatele do Active Directory. Také si uvědomte, že vezmete sAMAccountName a přidáte doménu conf.pod6.cms.lab na jeho konec, protože to je přihlášení, které vaši uživatelé budou používat pro vstup do CMS.

nameMapping mapuje to, co je obsaženo v poli Active Directory displayName, na pole jména uživatele CMS.

coSpaceNameMapping vytváří jméno space v CMS na základě pole displayName. Tento atribut spolu s atributem coSpaceUriMapping je to, co je potřeba pro vytvoření space pro každého uživatele.

coSpaceUriMapping určuje uživatelskou část URI související s osobním prostorem uživatele. Některé domény mohou být nastaveny pro použití v prostoru. Pokud se uživatelská část shoduje s tímto polem pro jednu z těchto domén, bude volání směrováno do tohoto osobního prostoru uživatele.

coSpaceSecondaryUriMapping určuje druhý URI pro dosažení prostoru. To může být použito pro přidání číselného aliasu pro směrování volání do prostoru importovaného uživatele jako alternativy k alfanumerickému URI definovanému v parametru coSpaceUriMapping.

Server LDAP a mapování LDAP jsou nastavena. Nyní je potřeba je propojit vytvořením LDAP zdroje.

Použití URL pro přístup cms01.example.com:445/api/v1/ldapSource vytváříme objekt LDAP Source, přičemž uvádíme takové parametry jako:

• server
• mapping
• baseDn
• filter

Nyní, když je nastavení LDAP dokončeno, můžeme provést ruční synchronizaci.

Děláme to buď v webovém rozhraní každého serveru stisknutím Sync now v sekci Active Directory


nebo prostřednictvím API příkazem POST použitím URL pro přístup cms01.example.com:445/api/v1/ldapSyncs

Ad-Hoc konference

Co to je?V tradičním pojetí konference je to, když dva účastníci hovoří mezi sebou, a jeden z účastníků (používající zařízení registrované v Unified CM) stiskne tlačítko „Konference“, zavolá další osobě, a po rozhovoru s touto třetí stranou znovu stiskne tlačítko „Konference“, aby se připojil ke všem účastníkům třístranné konference.

Ad-Hoc konference se od naplánované konference v CMS liší tím, že Ad-Hoc konference není pouze SIP hovor pro CMS. Když iniciátor konference znovu stiskne tlačítko „Konference“, aby pozval všechny na stejnou schůzku, Unified CM musí zavolat API pro CMS, aby vytvořil konferenci „za běhu“, do které budou poté přesměrována všechna volání. To se děje pro účastníky nepozorovaně.

To znamená, že Unified CM musí nastavit API pověření a adresu / port WebAdmin služby, stejně jako SIP-Trunk přímo na server CMS pro pokračování hovoru.

Pokud je to potřeba, CUCM může dynamicky vytvářet prostor v CMS, aby každé volání mohlo dorazit do CMS a odpovídat pravidlu příchozích hovorů, které je určeno pro prostory.

Integrace s CUCM se nastavuje stejně, jak je popsáno v článku. dříve s výjimkou toho, že na Cisco UCM je třeba vytvořit tři trunky pro CMS, tři Conference Bridge, v SIP Security Profile uvést tři Subject Name, Route Group, Route List, Media Resource Group a Media Resource Group List, a v Cisco Meeting Server trochu přidat pravidla směrování.

SIP Security Profile:


Trunky:


Každý trunk vypadá stejně:




Conference Bridge


Každý Conference Bridge vypadá stejně:


Route Group


Route List


Media Resource Group


Media Resource Group List

Pravidla volání

Na rozdíl od sofistikovanějších systémů správy volání, jako je Unified CM nebo Expressway, pro nové volání CMS prochází doménu pouze v poli SIP Request-URI. Pokud je SIP INVITE určeno pro sip:user@domain.com, CMS se stará pouze o domain.com. CMS se řídí těmito pravidly k určení, kam hovor poslat:

1. Nejprve CMS se pokusí porovnat doménu SIP s doménami nastavenými v pravidlech zpracování příchozích hovorů. Poté mohou být tyto hovory směrovány do ('cílových') prostor nebo konkrétním uživatelům, internímu IVR nebo přímo integrovaným adresátům Microsoft Lync/Skype pro firmy (S4B).
2. Pokud v pravidlech zpracování příchozích hovorů nejsou žádná shoda, CMS se pokusí porovnat doménu nastavenou v tabulce přesměrování hovorů. Pokud je shoda nalezena, pravidlo může výslovně hovor odmítnout nebo přesměrovat. V tuto chvíli může CMS přepsat doménu, což je někdy užitečné pro hovory do domén Lync. Můžete také zvolit pass throw, což znamená, že žádné pole nebude dále změněno, nebo použít interní uživatelskou skupinu CMS. Pokud v pravidlech přesměrování hovorů nejsou žádná shoda, ve výchozím nastavení se používá odmítnutí hovoru. Mějte na paměti, že v CMS, i když je hovor 'přesměrován', multimédia se stále připojují k CMS, což znamená, že budou probíhat jak signální, tak multimediální provoz.
Teprve tehdy podléhají pouze přesměrované hovory pravidlům odchozích hovorů. Tyto možnosti určují adresáty, kam hovor posílat, typ spojovací linky (ať už se jedná o nový hovor Lync nebo standardní SIP) a jakákoli převody, které mohou být provedeny, pokud v pravidle přesměrování hovorů nebyla vybrána žádná předávka.

Zde je vlastně log toho, co se děje při Ad-Hoc konferenci.

Na obrazovce je to špatně vidět (nevím, jak to udělat lépe), proto napíšu log takto:

Info	127.0.0.1:35870: Uživatel API "api" vytvořil nový prostor 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	volání create se nezdařilo, nenašlo coSpace -- pokouší se načíst z databáze

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  Interní G

Info	127.0.0.1:35872: Uživatel API "api" vytvořil nový hovor 93bfb890-646c-4364-8795-9587bfdc55ba

Info	call 7: příchozí SIP hovor od "sip:672@172.x.x.x" na místním URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"

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

Info	konference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 má kontrolu/media GUID: fb587c12-23d2-4351-af61-d6365cbd648d

Info	konference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 pojmenovaná "001036270012"

Info	call 7: konfigurováno - API call leg bc0be45e-ce8f-411c-be04-594e0220c38e s SIP call ID "7e309680-cd217a6a-f237-e88214ac@172.x.x.x"

Info	call 7: nastavuje RTP sezení UDT pro DTLS (kombinovaná média a kontrola)
Info	konference "001036270012": nyní přítomny nešifrované hovorové větve

Info	účastník "672@172.x.x.x" se připojil do prostoru 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	účastník "672@172.x.x.x" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) se připojil ke konferenci 434f88d0-8441-41e1-b6ee-6d1c63b5b098 přes SIP

Info	call 8: příchozí SIP hovor od "sip:690@172.x.x.x" na místním URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"

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

Info	call 8: konfigurováno - API call leg db61b242-1c6f-49bd-8339-091f62f5777a s SIP call ID "7e309680-cd217a6a-f238-e88214ac@172.x.x.x"

Info	call 8: nastavuje RTP sezení UDT pro DTLS (kombinovaná média a kontrola)

Info	call 9: příchozí SIP hovor od "sip:673@172.x.x.x" na místním URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"

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

Info	call 9: konfigurováno - API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a s SIP call ID "7e309680-cd217a6a-f239-e88214ac@172.x.x.x"

Info	call 9: nastavuje RTP sezení UDT pro DTLS (kombinovaná média a kontrola)
Info	call 8: kompenzace za to, že vzdálený konec neodpovídá typům payload

Info	účastník "690@172.x.x.x" se připojil do prostoru 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	účastník "690@172.x.x.x" (289e823d-6da8-486c-a7df-fe177f05e010) se připojil ke konferenci 434f88d0-8441-41e1-b6ee-6d1c63b5b098 přes SIP

Info	call 7: kompenzace za to, že vzdálený konec neodpovídá typům payload
Info	call 8: neodpovídající režim typů payload 1/0
Info	call 8: odpovídání nabídky v neodpovídajícím režimu typů payload
Info	call 8: obdržena následná nabídka jednoho kodeku
Info	call 8: neodpovídající režim typů payload 1/0
Info	call 8: odpovídání nabídky v neodpovídajícím režimu typů payload
Info	call 8: odesílání odpovědi na dodatečnou nabídku jednoho kodeku
Info	call 9: kompenzace za to, že vzdálený konec neodpovídá typům payload

Info	účastník "673@172.x.x.x" se připojil do prostoru 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	účastník "673@172.x.x.x" (d27e9a53-2c8a-4e9c-9363-0415cd812767) se připojil ke konferenci 434f88d0-8441-41e1-b6ee-6d1c63b5b098 přes SIP

Info	call 9: BFCP (úloha klienta) nyní aktivní
Info	call 9: odesílání BFCP hello jako klient po obdržení hello, když BFCP není aktivní
Info	call 9: BFCP (úloha klienta) nyní aktivní
Info	call 7: ukončuje; vzdálené SIP ukončení - připojeno po 0:13
Info	call 7: ničení API call leg bc0be45e-ce8f-411c-be04-594e0220c38e

Info	účastník "672@x.x.x" opustil prostor 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call 9: na pozastavení
Info	call 9: neodpovídající režim typů payload 1/0
Info	call 9: odpovídání nabídky v neodpovídajícím režimu typů payload
Info	call 8: na pozastavení
Info	call 8: obdržena následná nabídka jednoho kodeku
Info	call 8: neodpovídající režim typů payload 1/0
Info	call 8: odpovídání nabídky v neodpovídajícím režimu typů payload
Info	call 8: odesílání odpovědi na dodatečnou nabídku jednoho kodeku
Info	call 9: končí; vzdálené SIP ukončení - připojeno po 0:12

Samotná Ad-Hoc konference:


Pravidla příchozích hovorů
Nastavení parametrů příchozích hovorů je nezbytné pro možnost přijímání hovorů v CMS. Jak jste viděli v nastavení LDAP, všichni uživatelé byli importováni s doménou conf.pod6.cms.lab. Proto alespoň chcete, aby hovory na tuto doménu byly určeny pro prostory. Také budete muset nastavit pravidla pro všechno, co je určeno pro plné doménové jméno (a možná i pro IP adresu) každého z serverů CMS. V našem externím ovládání hovorů, Unified CM, budou nastaveny SIP trunky určené pro každý z serverů CMS individuálně. V závislosti na tom, zda je určením těchto SIP trunků IP adresa, nebo plné doménové jméno serveru, určí, zda je třeba nastavit CMS pro přijímání hovorů směřujících na jeho IP adresu nebo plné doménové jméno.

Doména, která má pravidlo příchozího provozu s nejvyšší prioritou, se používá jako doména pro jakékoli uživatelské prostory. Když se uživatelé synchronizují přes LDAP, CMS automaticky vytváří prostory, ale pouze uživatelskou část URI (coSpaceUriMapping), například user.space. Část domain plného URI se vytváří na základě tohoto pravidla. Ve skutečnosti, pokud byste se na této úrovni přihlásili do Web Bridge, viděli byste, že u Space URI není doména. Nastavením tohoto pravidla jako nejvyšší priority určujete doménu pro generované prostory jako conf.example.com.


Pravidla odchozích hovorů

Aby uživatelé mohli uskutečňovat odchozí hovory do clusteru Unified CM, je nutné nastavit pravidla odchozích spojení. Doménou koncových bodů registrovaných v Unified CM, jako je Jabber, je example.com. Hovory do této domény by měly být směrovány jako standardní SIP hovory na uzly zpracování hovorů Unified CM. Hlavní server je cucm-01.example.com, jako doplňkový cucm-02.example.com.

První pravidlo popisuje nejjednodušší směrování hovorů mezi servery clusteru.

Pole Místní doména určuje, co se zobrazí v SIP-URI volajícího u toho, komu volají, po symbolu „@“. Pokud to necháme prázdné, po symbolu „@“ se zobrazí IP adresa CUCM, přes kterou hovor prochází. Pokud však uvedeme doménu, po symbolu „@“ se bude zobrazovat doména. To je nutné, aby bylo možné zavolat zpět, jinak bude nemožné dovolat se zpět na SIP-URI jméno@ip-adresa.

Hovor, když je uveden Místní doména


Hovor, když NE uvedeno Místní doména


Povinně jasně uveďte Encrypted nebo Unencrypted pro odchozí hovory, protože při parametru Auto nic nefunguje.

Nahrávání

Záznam videokonferencí je prováděn serverem Record. Recorder je stejný jako Cisco Meeting Server. Recorder nevyžaduje žádné licence. Licence na záznam jsou potřebné pro servery, na kterých běží služby CallBridge, tj. licence Recording je nutná a měla by být aplikována na komponentu CallBridge, nikoli na server, na kterém běží Recorder. Recorder se chová jako klient rozšiřitelného protokolu pro výměnu zpráv a přítomnost (XMPP), proto musí být server XMPP povolen na serveru, na kterém je umístěn CallBridge.

Jelikož máme cluster a licenci je třeba „roztáhnout“ na všechny tři servery clusteru. Takže jednoduše v osobním účtu v licencích asociujeme (přidáme) MAC adresy a rozhraní všech CMS serverů, které jsou součástí clusteru.

A takový obraz by měl být na každém serveru clusteru

Existuje několik scénářů umístění Recorderu, ale my se budeme držet následujícího:


Předtím, než začneme konfigurovat Recorder, je třeba připravit místo, kam se budou videokonference nahrávat. Tady je to odkaz, jak nastavit celý Recording. Zaměřím se na důležité momenty a detaily:

1. Je lepší použít certifikát z prvního serveru v clusteru.
2. Chyba „Recorder unavailable“ může vzniknout proto, že není uveden správný certifikát v Recorder Trust.
3. Záznam nemusí probíhat, pokud není pro záznam uveden kořenový adresář v NFS.

Někdy vyvstává potřeba automaticky zaznamenávat konferenci jednoho konkrétního uživatele nebo space.

K tomu se vytvářejí dva CallProfile:
S vypnutou funkcí záznamu


A s automatickou funkcí záznamu


Dále k potřebnému space „připojíme“ CallProfile s automatickou funkcí záznamu.


V CMS je to tak zařízeno, že pokud je CallProfile jasně přiřazen k některým prostorům nebo prostoru, pak tento CallProfile funguje pouze pro tyto konkrétní prostory. A pokud CallProfile není přiřazen k žádnému prostoru, pak se ve výchozím nastavení používá pro ty prostory, ke kterým není jasně přiřazen žádný CallProfile.

Příště se pokusím popsat, jakými způsoby je možné přistupovat k CMS mimo vnitřní síť organizace.

Zdroje:

• 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

Zdroj: habr.com