Cisco Meeting Server 2.5.2. Cluster skálázható és rugalmas módban, videokonferenciák rögzítési funkcióval

Ebben a részben bemutatom és elmagyarázom a CMS szerver beállításának néhány apró részletét a hibatűrő klaszter üzemmódban.


ElméletAlapvetően háromféle CMS szerver telepítési mód létezik:

• Single Combined(Egyetlen egyesített), azaz egy olyan szerver, amelyen az összes szükséges szolgáltatás fut. A legtöbb esetben ez a telepítési típus csak belső ügyfelek hozzáférésére alkalmazható, és kis környezetekben, ahol a skálázhatóság és a redundancia korlátai nem jelentenek kritikus problémát, vagy olyan helyzetekben, amikor a CMS csak bizonyos funkciókat lát el, mint például a Cisco UCM speciális konferenciái.

  A működés vázlatos schemáját mutatja:
  

• Single Split(Egyetlen felosztott) a korábbi telepítési típust bővíti, külön szervert hozzáadva a külső hozzáféréshez. A régi telepítések esetén ez a CMS szerver DMZ (demilitarizált zóna) szegmenst adott, ahol a külső ügyfelek hozzáférhettek, és egy CMS szerver a hálózat magjában, ahol a CMS belső ügyfelei fértek hozzá. Ez a konkrét telepítési modell mostantól a "Single Edge" típus váltja fel. Single Edge, amely szerverekből áll, Cisco Expressway, amelyek rendelkeznek vagy rendelkezni fognak a tűzfal megkerülésének számos lehetőségével, ezért az ügyfeleknek nem kell dedikált CMS határoló szervert hozzáadniuk.

  A működés vázlatos schemáját mutatja:
  

• Skálázható és hibatűrő(Skálázható és hibatűrő) ez a típus redundanciát tartalmaz minden komponens számára, lehetővé téve a rendszer növekedését az igényeidnek megfelelően a maximális kapacitásig, miközben redundanciát biztosít a hibák esetén. Ez a Single Edge koncepciót is használja a biztonságos külső hozzáférés biztosítására. Ez az a típus, amit ebben a részben megvizsgálunk. Ha megértjük, hogyan lehet ilyen típusú klasztert telepíteni, nemcsak a másik telepítési típusokat értjük meg, hanem azt is, hogyan lehet CMS szerverk klasztereit létrehozni a potenciális igények növekedésével összhangban.

A telepítéshez való áttérés előtt néhány alapvető dolgot meg kell értenünk, mégpedig

A CMS alapvető szoftverkomponensei:

• Adatbázis: lehetővé teszi bizonyos konfigurációk, például az előfizetőcsoport, felhasználói terek és maguk a felhasználók egyesítését. Csak a magas rendelkezésre állás érdekében támogatja a klaszterezést (egy mester).
• Call Bridge: egy audio- és videokonferenciákhoz készült szolgáltatás, amely teljes ellenőrzést biztosít a hívások és multimédia folyamatok kezelésénél és feldolgozásánál. Támogatja a klaszterezést a magas rendelkezésre állás és skálázhatóság érdekében.
• XMPP szerver: a Cisco Meeting Application és/vagy WebRTC alkalmazást használó kliensek regisztrálásáért és hitelesítéséért felelős,valós idejű kommunikáció, avagy egyszerűen a böngészőben), valamint az komponensek közötti jelzésért. Csak a magas rendelkezésre állás érdekében lehet klaszterezni.
• Web Bridge: hozzáférést biztosít a kliensek számára WebRTC-hez.
• Loadbalancer: egységes csatlakozási pontot biztosít a Cisco Meeting App alkalmazásokhoz Single Split módban. Figyeli a külső interfészt és portot a bejövő kapcsolatokhoz. A terheléselosztó egyenlően fogadja a bejövő TLS kapcsolatokat az XMPP szerverről, amelyeken keresztül TCP kapcsolatokat tud váltani a külső kliensektől.
  A mi forgatókönyvünkben nem lesz rá szükség.
• TURN server: a tűzfal megkerülési technológiáját biztosítja, lehetővé téve,
  hogy CMS-ünket a tűzfal mögé vagy NAT mögé helyezzük a Cisco Meeting App vagy SIP eszközöket használó külső kliensek csatlakozásához. A mi forgatókönyvünkben nem lesz rá szükség.
• Web Admin: adminisztrációs felület és API hozzáférés, beleértve a Unified CM speciális konferenciáit.

Konfigurációs módok

A legtöbb Cisco terméktől eltérően a Cisco Meeting Server három beállítási módszert támogat, amelyek lehetővé teszik bármilyen telepítési módot.

• Parancssor (CLI): A parancssori felület, mint MMP, az alapbeállítási feladatokhoz és tanúsítványokhoz.
• Web adminisztrátor: elsősorban a CallBridge-hez kapcsolódó konfigurációkhoz, különösen egy nem klaszterezett szerver beállításánál.
• REST API: a legbonyolultabb konfigurálási feladatokhoz és klaszteres adatbázissal kapcsolatos feladatokhoz használják.

A fentieken kívül, a SFTP fájlok átvitelére szolgáló protokoll - jellemzően licencek, tanúsítványok vagy naplók CMS szerverre és onnan.

A Cisco telepítési útmutatók angol nyelvű megfogalmazásában világosan le van írva, hogy a klasztert legalább három szerverből (nodból) kell kiépíteni az adatbázisok szempontjából. Mivel csak páratlan számú csomóponthoz fog működni az új adatbázismester kiválasztási mechanizmusa, és egyáltalán az adatbázismester kapcsolatban áll a CMS szerver adatbázisának nagy részével.

A gyakorlat azt mutatja, hogy két szerver (nód) valóban nem elégséges. A vezérlőmechanizmus a Master újraindításakor lép életbe, a Slave szerver csak akkor válik Masterré, amikor a újraindított szerver feláll. Ha azonban a két szerverből álló klaszterben a Master szerver hirtelen „leáll”, a Slave szerver nem válik Masterré, ha pedig a Slave áll le, akkor a megmaradó Master szerver is Slave lesz.

XMPP kontextusában azonban valóban szükséges egy három szerverből álló klaszter kialakítása, mivel ha például az egyik, a Leader státuszú XMPP szolgáltatás letiltásra kerül, a maradék szerveren az XMPP a Follower státuszon marad, és a CallBridge-hez való kapcsolatok megszakadnak, mivel a CallBridge kizárólag a Leader státuszú XMPP-hez csatlakozik. Ez kritikus, mivel egyetlen hívás sem fog átmenni.

Ezekben a telepítési útmutatókban egy egy XMPP szerverrel rendelkező klasztert is bemutatnak.

Figyelembe véve a fent említetteket, világossá válik, hogy működik, mert failover üzemmódban működik.

A mi esetünkben az XMPP szerver mindhárom nódon jelen lesz.

Feltételezzük, hogy mindhárom szerverünk működik.

DNS bejegyzések

Mielőtt nekilátnánk a szerverek beállításának, DNS bejegyzéseket kell létrehozni. A és SRV típusú:

Figyeljen arra, hogy a DNS bejegyzéseinkben két domain található: example.com és conf.example.com. Az example.com az a domain, amit a Cisco Unified Communication Manager felhasználói URI-jukhoz használhatnak, amely valószínűleg jelen van a hálózatában, vagy nagy valószínűséggel jelen lesz. Vagy az example.com domain az, amelyet a felhasználók az e-mail címeikhez használnak. Vagy a Jabber kliens a laptopján a user@example.com URI-t használhat. A domain conf.example.com az a domain, amelyet a Cisco Meeting Server felhasználói számára konfigurálnak. A Cisco Meeting Server domainje conf.example.com, ezért ugyanazon Jabber felhasználó számára a Cisco Meeting Serverbe való belépéshez a user@ URI-t kell használniuk.conf.example.com.

Alap konfiguráció

Az alábbiakban leírt összes beállítást egy szerveren mutatjuk be, de ezeket minden klaszterbeli szerveren el kell végezni.

QoS

Mivel a CMS generálja real-time A késleltetésre és csomagvesztésre érzékeny forgalom esetében általában ajánlott a szolgáltatásminőség (QoS) beállítása. Ehhez a CMS támogatja a csomagok címkézését a differenciált szolgáltatási kódok (DSCP) segítségével, amelyeket generál. Bár a DSCP alapú forgalompriorizálás attól függ, hogy a forgalmat hogyan kezelik az infrastruktúra hálózati összetevői, mi az CMS-t a QoS legjobb gyakorlataira alapozva, tipikus DSCP prioritáselosztással állítjuk be.

Minden szerveren futtatjuk ezeket a parancsokat

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

Így az összes videóforgalom AF41 (DSCP 0x22) jelölést kapott, az összes hangforgalom EF (DSCP 0x2E) jelölést kapott, míg a késleltetés szempontjából alacsonyabb forgalmak, mint a SIP és XMPP, AF31 (DSCP 0x1A) jelölést használnak.

Ellenőrizzük:

NTP

A Hálózati Időprotokoll (NTP) nemcsak a hívások és konferenciák pontos időbélyegeinek biztosításához, hanem a tanúsítványok ellenőrzéséhez is fontos.

A hálózati infrastruktúrához NTP szervereket a következő parancs formájában adunk hozzá

ntp server add

Ebben az esetben két ilyen szerver van, így két parancsot fogunk használni.
Ellenőrizzük:

Majd beállítjuk a szerverünk időzónáját

DNS

A DNS szervereket a CMS-ben a következő parancs formájában adjuk hozzá:

dns add forwardzone

Ebben az esetben két ilyen szerver van, így két parancsot fogunk használni.
Ellenőrizzük:

A hálózati interfész konfigurációja

Az interfészt a következő parancs formájában állítjuk be:

ipv4  add 
 /

Ellenőrizzük:

A szerver neve (Hostname)

A szerver nevét a következő parancs formájában állítjuk be:

hostname

És újraindítjuk.


Ezzel a bázis konfiguráció véget ért.

Tanúsítványok

ElméletA Cisco Meeting Server titkosított kommunikációt igényel a különböző összetevők között, és ennek eredményeként X.509 tanúsítványokra van szükség minden CMS telepítéshez. Ezek segítenek biztosítani a megbízhatóságot a szolgáltatások/szerverek között.

Minden szolgáltatáshoz szükség van tanúsítványra, azonban külön tanúsítványok létrehozása minden szolgáltatás számára zavarhoz és felesleges bonyolultsághoz vezethet. Szerencsére generálhatunk egy nyilvános és egy privát kulcs párt, majd újra felhasználhatjuk őket több szolgáltatáshoz. Ebben az esetben ugyanazt a tanúsítványt fogjuk használni a Call Bridge, XMPP szerver, Web Bridge és Web Admin esetében. Így minden szerverre a klaszterben egy nyilvános és privát kulcs párt kell létrehoznunk.

Az adatbázis klaszterezésének azonban különleges követelményei vannak a tanúsítványokkal kapcsolatban, ezért saját tanúsítványokat igényel, amelyek eltérnek a többi szolgáltatás tanúsítványaitól. A CMS egy olyan szerver tanúsítványt használ, amely hasonló a más szerverek által használt tanúsítványokhoz, de van egy kliens tanúsítvány is, amely az adatbázisokkal való kapcsolat során használatos. Az adatbázis tanúsítványok mind az azonosításra, mind a titkosításra szolgálnak. Ahelyett, hogy felhasználónevet és jelszót biztosítanánk a kliens adatbázishoz való csatlakozásához, a kliens egy tanúsítványt mutat be, amelyet a szerver megbízhatónak tart. Minden szerver az adatbázis klaszterben ugyanazt a nyilvános és titkos kulcspárost használja. Ez lehetővé teszi, hogy az összes szerver a klaszterben az adatokat úgy titkosítsa, hogy azokat csak más, ugyanazt a kulcspárost használó szerverek tudják visszafejteni.

Ahhoz, hogy a biztonsági másolat elkészítése működjön, az adatbázis klasztereknek legalább 3 szerverből kell állniuk, de nem haladhatják meg az 5-öt, és a jelátviteli idő mindkét irányban legfeljebb 200 ms lehet a klaszter bármely tagja között. Ez a korlát szigorúbb, mint a Call Bridge klaszterezésnél, ezért gyakran korlátozó tényező a földrajzilag elosztott telepítések esetében.

A CMS adatbázisának szerepe számos egyedi követelményt támaszt. Más szerepektől eltérően ez megköveteli a kliens és szerver tanúsítványt, ahol a kliens tanúsítványának van egy adott CN mezője, amelyet a szervernek kell bemutatni.

A CMS egy postgres adatbázist használ, egy fővel és több teljesen azonos replikával. Minden egyes pillanatban csak egy fő adatbázis van (az „adatbázis szerver”). A klaszter többi tagja replikák vagy „adatbázis kliensek”.

Az adatbázis klaszterhez dedikált szerver tanúsítványra és kliens tanúsítványra van szükség. Ezeket általában egy belső privát tanúsítványkezelőtől kell aláírni. Mivel az adatbázis klaszter bármelyik tagja lehet a vezető, az adatbázis szerver és kliens tanúsítvány párjait (amelyek nyilvános és titkos kulcsokat tartalmaznak) minden szerverre másolni kell, hogy azok el tudják fogadni az adatbázis kliens vagy szerver identitását. Ezen kívül a CA gyökér tanúsítványt is fel kell tölteni, hogy biztosítsuk, hogy a kliens és szerver tanúsítványok ellenőrizhetők legyenek.

Tehát készítünk egy tanúsítványkérvényt, amelyet az összes szerver szolgáltatás fog használni, a database szolgáltatás kivételével (ehhez külön kérvény lesz), a következő parancs típussal:

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

A CN mezőbe a szervereink általános nevét írjuk. Például, ha a szervereink hostname-jei server01, server02, server03, akkor a CN server.example.com

Hasonlóképpen járunk el a fennmaradó két szerveren is, annyi eltéréssel, hogy a parancsokban a megfelelő "hostname"-ek szerepelnek.

Két tanúsítványkérvényt készítünk, amelyeket a database szolgáltatás fog használni, a következő parancsokkal:

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

pki csr dbclusterclient CN:postgres

ahol dbclusterserver és dbclusterclient a kérvényeink és a jövőbeli tanúsítványaink nevei, hostname1(2)(3) a megfelelő szerverek nevei.

Ezt az eljárást csak egy szerveren hajtjuk végre (!), a tanúsítványokat és a megfelelő .key fájlokat a többi szerverre töltjük fel.

A kliens tanúsítvány üzemmód aktiválása az AD CS-ben

Ezen kívül össze kell vonni egy fájlba az összes tanúsítványt minden szerver számáraA *NIX rendszeren:

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

Windows/DOS alatt:

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

És fel kell tölteni minden szerverre:
1. A "dedikált" szerver tanúsítványt.
2. A gyökér tanúsítványt (az esetlegesen létező köztes tanúsítványokkal együtt).
3. Az adatbázis tanúsítványokat (a "szerver" és a "kliens"), valamint a .key kiterjesztésű fájlokat, amelyek a "szerver" és a "kliens" adatbázis tanúsítvány kérvényének létrehozásakor keletkeztek. Ezeknek a fájloknak minden szerveren azonosnak kell lenniük.
4. Az összes három "dedikált" tanúsítvány fájlja.

Ennek eredményeképpen körülbelül ilyen fájlstruktúrának kell fennállnia minden szerveren.

Adatbázis klaszter

Most már, hogy minden tanúsítványt feltöltött a CMS szerverekre, beállíthatja és engedélyezheti az adatbázisok klaszterezését három csomópont között. Az első lépés egy szerver kiválasztása mint az adatbázis klaszter fő csomópontja, és annak teljes beállítása.

Fő Adatbázis

Az adatbázis-replikáció beállításának első lépése a tanúsítványok megadása, amelyeket az adatbázis használ. Ezt az alábbi parancs segítségével lehet végrehajtani:

database cluster certs

Most megadjuk a CMS-nek, hogy melyik interfészt használja az adatbázisok klaszterezéséhez a következő parancs segítségével:

database cluster localnode a

Ezután inicializáljuk az klaszter adatbázist a fő szerveren a következő parancs segítségével:

database cluster initialize

Kliens Adatbázis Csomópontok

Ugyanezt a folyamatot hajtjuk végre, de a következő parancs helyett database cluster initialize beírjuk a következő parancsot:

database cluster join

ahol az ip address existing master a CMS szerver IP címe, ahol az klaszter inicializálása történt, azaz a Master.

Ellenőrizzük, hogyan működik az adatbázis klaszterünk minden szerveren a következő paranccsal:

database cluster status

Ugyanezt csináljuk a harmadik szerveren is.

Ennek eredményeként az első szerverünk a Master, a többiek a Slave-ként működnek.

Web Admin Szolgáltatás

Engedélyezzük a webadminisztrátor szolgáltatást:

webadmin listen a 445

A 445-ös portot választottuk, mert a 443-as portot a felhasználók web-klienshez való hozzáférésére használják.

A Web Admin szolgáltatást a tanúsítványfájlokkal a következő parancs segítségével állítjuk be:

webadmin certs

És engedélyezzük a Web Admin-t a következő parancs segítségével:

webadmin enable

Ha minden rendben van, akkor SUCCESS sorokat kapunk, amelyekben az áll, hogy a Web Admin helyesen van beállítva a hálózat és a tanúsítvány számára. Ellenőrizzük a szolgáltatás működését egy web böngésző segítségével, és írjuk be a webadminisztrátor címét, például: cms.example.com:445

Hívás Híd Klaszter

A Hívás Híd az egyetlen szolgáltatás, amely minden CMS telepítésben jelen van. A Hívás Híd a konferenciák alapvető mechanizmusa. Emellett SIP interfészt biztosít, így a hívások irányíthatók hozzá vagy onnan ki, például a Cisco Unified CM-en keresztül.

Az alább leírt parancsokat minden szerveren végre kell hajtani a megfelelő tanúsítványokkal.
Tehát:

Összekapcsoljuk a tanúsítványokat a Hívás Híd szolgáltatással a következő parancs segítségével:

callbridge certs  []

A Hívás Híd szolgáltatásokat a szükséges interfészhez rendeljük a következő parancs segítségével:

callbridge listen a

Majd újraindítjuk a szolgáltatást a következő parancs segítségével:

callbridge restart

Most, hogy beállítottuk a Call Bridge-eket, beállíthatjuk a Call Bridge klaszterezést. A Call Bridge klaszterezés eltér a adatbázis vagy XMPP klaszterezésétől. A Call Bridge klaszter 2 és 8 csomópont között támogathat korlátok nélkül. Nemcsak redundanciát biztosít, hanem terheléselosztást is, lehetővé téve, hogy a konferenciák aktívan oszlanak meg a Call Bridge szerverek között intelligens híváselosztás révén. A CMS további funkciókat, Call Bridge csoportokat és kapcsolódó funkciókat kínál a további kezelés érdekében.

A hívásbridge klaszterezése hétköznaposan a webes adminisztrátor felületen keresztül állítható be.
A következő eljárást minden klaszterezett szerveren végre kell hajtani.
Tehát,

1. Belépünk a webes felületen a Configuration > Cluster menübe.
2. A Call Bridge azonosító mezőbe egyedi névként beírjuk a callbridge[01,02,03] szervernevekhez igazodva. Ezek a nevek önkényesek, de egyediek kell, hogy legyenek ebben a klaszterben. Leíró jellegűek, mivel arra utalnak, hogy ez a szerverek [01,02,03] azonosítói.
3. A Klaszterezett Call Bridge-ek mezejébe a klaszterünk szervereinek web-adminisztrátor URL címeit írjuk be, cms[01,02,03].example.com:445
mezőre. Ne feledje, hogy a portot is meg kell adni. A Peer link SIP domain mező üresen hagyható.

4. Minden szerver CallBridge-hez a megbízható kapcsolathoz a tanúsítványt hozzá kell adni, amely tartalmazza az összes szerverünk tanúsítványát, amelyeket az elején olvasztottunk egy fájlba, például a következő paranccsal:

Majd újraindítjuk a szolgáltatást a következő parancs segítségével:

callbridge restart

callbridge trust cluster

Végül minden szerveren a következő képnek kellene megjelennie:

XMPP klaszter

Az alább leírt parancsokat minden szerveren végre kell hajtani a megfelelő tanúsítványokkal.
Tehát:

Az XMPP szolgáltatás a CMS-ben felelős minden Cisco Meeting Apps (CMA) regisztráció és hitelesítés kezeléséért, beleértve a CMA WebRTC webklienst is. A Call Bridge is XMPP ügyfélként működik a hitelesítési célokra, ezért ugyanúgy kell beállítani, mint a többi ügyfelet. Az XMPP megbízhatósága az a funkció, amely a termelési környezetekben támogatott a 2.1-es verziótól kezdődően.

A tanúsítványokat a következő parancs segítségével kapcsoljuk össze az XMPP szolgáltatással:

xmpp certs []

Majd határozza meg a hallgatási felületet a következő paranccsal:

Az XMPP szolgáltatáshoz egyedi domain szükséges. Ez a felhasználók bejelentkezési neve. Más szavakkal, amikor a felhasználó az CMA alkalmazáson (vagy a WebRTC kliensen) keresztül próbál bejelentkezni, be kell írnia a userID@logindomain kifejezést. A mi esetünkben ez lesz userid@conf.example.com. Miért nem egyszerűen example.com? A mi konkrét telepítésünknél a Unified CM domainünket választottuk, amelyet a Jabber felhasználók használnak az Unified CM-en, mint example.com, ezért szükségünk van egy másik domainre a CMS felhasználók számára, hogy irányítsuk a hívásokat a CMS-be és CMS-ből SIP domaineken keresztül.

Az XMPP domain beállításához az alábbi parancsot használja:

xmpp domain

Majd aktiváljuk az XMPP szolgáltatást az alábbi paranccsal:

xmpp enable

Az XMPP szolgáltatásban minden Call Bridge-hez létre kell hozni hitelesítő adatokat, amelyeket az XMPP szolgáltatásba való bejelentkezéshez használnak. Ezek a nevek tetszőlegesek (és nem kapcsolódnak a hídklaszterezési beállításokhoz). Egy XMPP szerveren három hídot kell hozzáadni, majd ezeket a hitelesítő adatokat be kell írni más XMPP szerverekre a klaszterben, mivel ez a konfiguráció nem kerül a klaszter adatbázisába. Később mindegyik Call Bridge-et beállítjuk, hogy ezt a nevet és jelszót használja az XMPP szolgáltatásba való bejelentkezéshez.

Most be kell állítanunk az XMPP szolgáltatást az első kiszolgálón a callbridge01, callbridge02 és callbridge03 három Call Bridge-szel. Minden fiókhoz véletlenszerű jelszavakat rendelünk. Később ezeket be kell írni a többi Call Bridge szerverre, hogy csatlakozzanak ehhez az XMPP szerverhez. Az alábbi parancsokat írjuk be:

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

Végül ellenőrizzük, hogy mi készült a következő paranccsal:

xmpp callbridge list

A többi kiszolgálón a fentiek szerint egészen hasonló képet kell látni.

Ezután a két megmaradt szerveren pontosan ugyanazokat a beállításokat adjuk hozzá, csak az alábbi parancsokkal:

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

A Secret-et nagyon óvatosan adjuk hozzá, hogy ne kerüljön bele például véletlenül felesleges szóköz.


A végén minden szerveren ugyanazt a képet kell látni:

Ezután a klaszter összes szerverén megadjuk a bizalomfájlhoz, amely az összes három korábban létrehozott tanúsítványt tartalmazza, az alábbi parancs formájában:

xmpp cluster trust

Bekapcsoljuk az xmpp klaszter módot a klaszter összes szerverén az alábbi paranccsal:

xmpp cluster enable

A klaszter első szerverén elindítjuk az xmpp klaszter létrehozását a következő paranccsal:

xmpp cluster initialize

A többi szerveren az xmpp klaszterhez való csatlakozáshoz használjuk az alábbi parancsot:

xmpp cluster join

Ellenőrizzük, hogy az XMPP klaszter sikeresen létrejött-e minden szerveren a következő parancsokkal:

xmpp status
xmpp cluster status

Első szerver:

Második szerver:

Harmadik szerver:

Call Bridge csatlakoztatása az XMPP-hez

Most, hogy az XMPP klaszter fut, be kell állítanunk a Call Bridge szolgáltatásokat az XMPP klaszterhez való csatlakozáshoz. Ezt a konfigurációt a webadminisztrátor segítségével végezzük el.

Minden szerveren lépjünk be a Configuration > General menübe, és a mezőbe Unique Call Bridge name írjuk be a szerverhez tartozó egyedi Call Bridge neveket callbridge[01,02,03]mezőbe Domain conf.example.ru és a megfelelő jelszavakat, amelyeket bármelyik szerveren meg lehet nézni a következő paranccsal:
mezőt üresen hagyjuk,

xmpp callbridge list

Callbridge DNS SRV keresést fog végezni a _xmpp-component._tcp.conf.example.com , hogy megtalálja az elérhető XMPP szervert. A Callbridge-nek az XMPP-hez való csatlakozó IP címei minden szerveren eltérhetnek, ez attól függ, hogy milyen értékek térnek vissza a DNS rekord kérdésérecallbridge számára, ami viszont a DNS rekord beállításainak prioritásaitól függ. , hogy megtalálja az elérhető XMPP szervert. A Callbridge-nek az XMPP-hez való csatlakozó IP címei minden szerveren eltérhetnek, ez attól függ, hogy milyen értékek térnek vissza a DNS rekord kérdésére Ezután lépjünk a Status > General menübe, hogy megbizonyosodjunk arról, hogy a Call Bridge szolgáltatás sikeresen csatlakozott az XMPP szolgáltatáshoz.

Minden klasterben lévő szerveren indítsuk el a Web Bridge szolgáltatást a következő paranccsal:

Web Bridge

webbridge listen a:443

Állítsuk be a Web Bridge szolgáltatást a tanúsítvány fájlokkal az alábbi példa parancs segítségével:

webbridge certs

A Web Bridge támogatja a HTTPS-t. HTTP-t HTTPS-re irányít át, ha be van állítva az "http-redirect" használatára.

A HTTP átirányítás engedélyezéséhez használja a következő parancsot:
webbridge http-redirect enable

Ahhoz, hogy a Call Bridge azt jelezze, hogy a Web Bridge-nek lehet bízni a Call Bridge-ből érkező kapcsolatokban, használja a következő parancsot:

webbridge trust

ahol ez egy olyan fájl, amely tartalmazza az összes három tanúsítványt minden klasterben lévő szervertől.

Ilyen állapotban kell lennie minden klasterben lévő szervernek.

Most létre kell hoznunk egy felhasználót „appadmin” szerepkörrel, amely szükséges ahhoz, hogy konfigurálhassuk a klasztert(!), és ne minden egyes szervert külön-külön, így a beállítások minden szerverre azonosak lesznek, ugyanakkor csak egyszer kell őket elvégezni.


A további beállításokhoz ezt fogjuk használni


A hitelesítéshez válasszuk a Basic-t az Autorization részben. Postman.

A bejelentkezéshez válasszuk a Basic lehetőséget az Autorization szakaszban

A CMS szerverekre való parancsok helyes elküldéséhez meg kell határozni a megfelelő kódolást.

Webbridge-eket állítunk be a parancssal. POST http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/jun01/yang-ext:mount/junos-conf-root:configuration/junos-conf-protocols:protocols a beállítással url és az értékkel cms.example.com



A webbridge-ben meg kell adni a szükséges paramétereket: vendéghozzáférés, biztonságos hozzáférés és egyebek.

Call Bridge Csoportok

Alapértelmezés szerint a CMS nem mindig használja maximálisan hatékonyan a rendelkezésre álló konferencia-erőforrásokat.

Például, ha egy három résztvevős találkozóra kerül sor, akkor minden résztvevő három különböző Call Bridge-en lehet. Ahhoz, hogy ezek a három résztvevő kommunikálhasson egymással, a Call Bridge-ek automatikusan kapcsolódnak mind a szerverekhez, mind a kliensekhez ugyanabban a Space-ben, hogy úgy tűnjön, mintha minden kliens ugyanazon a szerveren lenne. Sajnos ennek a hátránya, hogy egy 3 fős konferencia most már 9 médiaportot fog igénybe venni. Ez nyilvánvalóan nem hatékony erőforrás-felhasználás. Ezen kívül, amikor egy Call Bridge valóban leterhelt, az alapértelmezett mechanizmus az, hogy folytatja a hívások fogadását és szolgáltatásokat nyújtja csökkentett minőségben az összes előfizető számára a Call Bridge-en.

Ezeket a problémákat a Call Bridge Csoport funkció segít megoldani. Ez a funkció a Cisco Meeting Server 2.1 verziójában került bevezetésre, és kiterjesztésre került a terheléselosztás támogatására mind a bejövő, mind a kimenő hívások esetében, beleértve a Cisco Meeting App (CMA) alkalmazást és a WebRTC résztvevőket is.

A problémák megoldásához három testreszabható terhelési korlátot vezettek be minden Call Bridge-hez:

LoadLimit — ez a maximális numerikus terhelés a konkrét Call Bridge esetében. Minden platformnak van ajánlott terhelési határa, például 96000 a CMS1000 esetében és 1,25 GHz egy virtuális processzorra a virtuális gépen. Különböző hívások különböző mennyiségű erőforrást fogyasztanak a résztvevő felbontásától és képkockasebességétől függően.
NewConferenceLoadLimitBasisPoints (alapértelmezés szerint a 50% loadLimit) — beállítja a szerver terhelési határát, amely után az új konferenciák elutasításra kerülnek.
ExistingConferenceLoadLimitBasisPoints (alapértelmezés szerint a loadLimit 80%-a) — ez a szerver terhelési értéke, amely után a meglévő konferenciához csatlakozó résztvevők elutasításra kerülnek.

Míg ezt a funkciót a hívások elosztására és a terhelés elosztására tervezték, más csoportok, mint például a TURN szerverek, a Web Bridge szerverek és a rögzítő eszközök is kijelölhetők Call Bridge Csoportokhoz, így megfelelően csoportosíthatók az optimális felhasználás érdekében. Ha ezek közül bármelyik objektum nincs hozzárendelve a hívócsoporthoz, akkor azt feltételezik, hogy azok minden szerver számára elérhetők, bármilyen bizonyos prioritás nélkül.

Ezek a beállítások itt konfigurálhatók: cms.example.com:445/api/v1/system/configuration/cluster

Ezután megadjuk minden callbridge-nek, hogy melyik callbridge-csoporthoz tartozik:

Első callbridge

Második callbridge

Harmadik callbridge


Így beállítottuk a Call Bridge csoportot a Cisco Meeting Server erőforrásainak hatékonyabb felhasználása érdekében.

Felhasználók importálása az Active Directory-ból

A Web Admin szolgáltatásnak van LDAP konfigurációs szekciója, de nem biztosít bonyolult konfigurációs beállításokat, és az információk nem mentődnek el a klaszter adatbázisába, így a beállítást manuálisan kell elvégezni minden szerveren a Web felületen vagy API-n keresztül, és hogy „háromszor ne kelljen felállnunk”, az adatokat mindenképpen API-n keresztül fogjuk megadni.

URL cím használatával való hozzáférés cms01.example.com:445/api/v1/ldapServers LDAP Server objektumot hozunk létre az alábbi beállítások megadásával:

• A szerver IP címe
• portszám
• felhasználónév
• jelszó
• biztonságos

A Secure értéke – true vagy false az 389-es (nem védett) vagy a 636-os (védett) porttól függően.


Megjelenítjük az LDAP forrás beállításait a Cisco Meeting Server attribútumain.
Az LDAP leképezés az LDAP könyvtárban található attribútumokat a CMS attribútumaival állítja párba. Az attribútumok a következők:

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Az attribútumok leírásaJID a felhasználó CMS belépési azonosítóját jelenti. Mivel ez egy Microsoft Active Directory LDAP szerver, a CMS JID a sAMAccountName-hez van párosítva az LDAP-ban, amely gyakorlatilag a felhasználó Active Directory-ba való belépési azonosítója. Ezenkívül vegye figyelembe, hogy a sAMAccountName-t veszi és hozzáadja a conf.pod6.cms.lab domént a végéhez, mert ez a bejelentkezési azonosító, amelyet a felhasználói CMS-hez való bejelentkezéskor használnak.

nameMapping párosítja, ami az Active Directory displayName mezőjében található, a CMS felhasználónév mezőjével.

coSpaceNameMapping létrehozza a CMS space nevét a displayName mező alapján. Ez az attribútum a coSpaceUriMapping attribútummal együtt szükséges ahhoz, hogy minden felhasználó számára létrehozzanak egy space-t.

coSpaceUriMapping meghatározza a felhasználó URI-jának személyes részét, amely a felhasználó személyes terével kapcsolatos. Néhány domain beállítható a térbe való beírásra. Ha a felhasználói rész megegyezik e mezővel a fenti domainek egyikénél, a hívás a felhasználó terébe lesz irányítva.

coSpaceSecondaryUriMapping meghatározza a második URI-t, hogy elérje a teret. Ez használható számokkal ellátott álnevek hozzáadására a hívások importált felhasználó nevének terébe való irányítására, alternatívaként a coSpaceUriMapping paraméterben megadott alfanumerikus URI-hoz képest.

LDAP szerver és LDAP leképezés be van állítva. Most már össze kell kötni őket, létrehozva egy LDAP forrást.

URL cím használatával való hozzáférés cms01.example.com:445/api/v1/ldapSource LDAP forrást hozunk létre, az alábbi paraméterek megadásával:

• server
• mapping
• baseDn
• filter

Most, hogy az LDAP beállítása befejeződött, elvégezhető a kézi szinkronizálás.

Ezt megtehetjük vagy minden szerver webes felületén, a Sync now a következő részben Active Directory


gombra kattintva, vagy az API-n keresztül a POST http://10.132.1.202:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/jun01/yang-ext:mount/junos-conf-root:configuration/junos-conf-protocols:protocols parancs használatával, az alábbi URL-címmel: cms01.example.com:445/api/v1/ldapSyncs

Ad-Hoc konferenciák

Mi ez?A hagyományos értelemben a konferencia az, amikor két résztvevő beszélget egymással, és az egyik résztvevő (a Unified CM-be bejegyzett eszközt használva) megnyomja a "Konferencia" gombot, hív egy másik embert, majd miután beszélt a harmadik féllel, ismét megnyomja a "Konferencia" gombot, hogy csatlakozzon az összes résztvevőhöz a három résztvevős konferencián.

Az Ad-Hoc konferenciát a CMS-ben tervezett konferenciától az különbözteti meg, hogy az Ad-Hoc konferencia nem csupán egy SIP-hívás a CMS-hez. Amikor a konferencia kezdeményezője második alkalommal megnyomja a "Konferencia" gombot, hogy mindenkit meghívjon ugyanarra a gyűlésre, a Unified CM-nek API-hívást kell végrehajtania a CMS-hez, hogy "lendületben" létrehozza a konferenciát, amire aztán minden hívás merül. Mindez a résztvevők számára észrevétlenül zajlik.

Ez azt jelenti, hogy a Unified CM-nak be kell állítania az API hitelesítő adatokat és a WebAdmin szolgáltatás URL-jét / portját, valamint a SIP-Trunkot közvetlenül a CMS szerverére, hogy a hívás folytatódhasson.

Szükség esetén a CUCM dinamikusan hozhat létre teret a CMS-ben, hogy minden hívás elérhesse a CMS-t és megfeleljen a bejövő hívások szabályaival, amelyek a terekre vonatkoznak.

Integráció a CUCM-mel ugyanúgy van beállítva, ahogy a cikkben le van írva korábban leírtunk A Cisco UCM rendszerhez három trunkot szükséges létrehozni a CMS-hez, három konferencia hidat, a SIP Security Profile-ban három Subject Name-t, Route Group-t, Route List-t, Media Resource Group-ot és Media Resource Group List-t, továbbá a Cisco Meeting Server-ben néhány routing szabályt kell egy kicsit bővíteni.

SIP Security Profile:


Trunkok:


Minden trunk ugyanúgy néz ki:




Konferencia híd


Minden konferencia híd ugyanúgy néz ki:


Route Group


Route List


Media Resource Group


Media Resource Group List

Hívás szabályok

A Unified CM vagy Expressway-hoz hasonló fejlettebb híváskezelő rendszerektől eltérően, a CMS az új hívásoknál csak a SIP Request-URI mezőben nézi meg a domaint. Tehát ha a SIP INVITE a sip: user@domain.com címet célozza, a CMS csak a domain.com-ot veszi figyelembe. A CMS az alábbi szabályok szerint határozza meg, hová irányítsa a hívást:

1. Először a CMS megpróbálja a SIP domaint az érkező hívások feldolgozási szabályaiban konfigurált domainekkel párosítani. Ekkor a hívások célzott területekre, konkrét felhasználókra, belső IVR-re vagy közvetlenül integrált Microsoft Lync/Skype for Business (S4B) címzettekre irányíthatók.
2. Ha az érkező hívások feldolgozási szabályaiban nincs egyezés, a CMS megpróbálja a hívásirányítási táblázatban konfigurált domaint párosítani. Ha a párosítás megtörténik, a szabály kifejezetten elutasíthatja a hívást, vagy átirányíthatja azt. Ekkor a CMS átírhatja a domaint, ami néha hasznos a Lync domainek esetében. Lehetőség van pass through választására is, ami azt jelenti, hogy egyetlen mező sem módosul, vagy használhatja a CMS belső előfizetői csoportját. Ha a hívásirányítási szabályokban nincs egyezés, alapértelmezés szerint a hívás elutasításra kerül. Ne feledje, hogy a CMS-ben, bár a hívás „átirányítva” van, a multimédia még mindig a CMS-hez kötődik, ami azt jelenti, hogy az a jelzős és multimédia forgalom útvonalán marad.
Ezek után csak az átirányított hívások tartoznak az outgoing hívás szabályok alá. Ezek a beállítások határozzák meg a címzetteket, ahová a hívásokat küldeni kell, a kapcsolódási vonal típusát (legyen az új Lync hívás vagy standard SIP) és bármilyen átalakítást, amelyet el lehet végezni, ha a hívásirányítási szabályban nem választották a továbbítást.

Ez tulajdonképpen a log, ami a helyszíni Ad-Hoc konferencia során történik.

A képernyőképen rosszul látszik (nem tudom, hogyan lehetne jobban csinálni), ezért a logot így írom:

Információ	127.0.0.1:35870: Az API felhasználó "api" új teret hozott létre: 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Információ	az új pályázat nem találta a coSpace-t -- próbálkozás az adatbázisból való visszahívásra

Információ	API "001036270012" Terem GUID: 7986bb6c-af4e-488d-9190-a75f16844e44 <--> Hívás GUID: 93bfb890-646c-4364-8795-9587bfdc55ba <--> Hívás Korelátor GUID: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 <--> Belső G

Információ	127.0.0.1:35872: Az API felhasználó "api" új hívást hozott létre: 93bfb890-646c-4364-8795-9587bfdc55ba

Információ	7. hívás: bejövő SIP hívás "sip:672@172.x.x.x"-tól a helyi URI "sip:001036270012@cms01.example.com:5060" \/ "sip:001036270012@cms01.example.com"

Információ	API hívás láb bc0be45e-ce8f-411c-be04-594e0220c38e a hívásban: 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API hívás: 93bfb890-646c-4364-8795-9587bfdc55ba)

Információ	konferencia 434f88d0-8441-41e1-b6ee-6d1c63b5b098 vezérlő/média GUID: fb587c12-23d2-4351-af61-d6365cbd648d

Információ	konferencia 434f88d0-8441-41e1-b6ee-6d1c63b5b098 neve: "001036270012"

Információ	7. hívás: konfigurálva - API hívás láb bc0be45e-ce8f-411c-be04-594e0220c38e SIP hívás ID-vel: "7e309680-cd217a6a-f237-e88214ac@172.x.x.x"

Információ	7. hívás: UDT RTP kapcsolat létrehozása DTLS-hez (összesített média és vezérlés)
Információ	konferencia "001036270012": titkosítatlan hívás lábak most jelen vannak

Információ	résztvevő "672@172.x.x.x" csatlakozott a térhez: 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Információ	résztvevő "672@172.x.x.x" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) csatlakozott a konferenciához: 434f88d0-8441-41e1-b6ee-6d1c63b5b098 SIP-en keresztül

Információ	8. hívás: bejövő SIP hívás "sip:690@172.x.x.x"-tól a helyi URI "sip:001036270012@cms01.example.com:5060" \/ "sip:001036270012@cms01.example.com"

Információ	API hívás láb db61b242-1c6f-49bd-8339-091f62f5777a a hívásban: 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API hívás: 93bfb890-646c-4364-8795-9587bfdc55ba)

Információ	8. hívás: konfigurálva - API hívás láb db61b242-1c6f-49bd-8339-091f62f5777a SIP hívás ID-vel: "7e309680-cd217a6a-f238-e88214ac@172.x.x.x"

Információ	8. hívás: UDT RTP kapcsolat létrehozása DTLS-hez (összesített média és vezérlés)

Információ	9. hívás: bejövő SIP hívás "sip:673@172.x.x.x"-tól a helyi URI "sip:001036270012@cms01.example.com:5060" \/ "sip:001036270012@cms01.example.com"

Információ	API hívás láb 37a6e86d-d457-47cf-be24-1dbe20ccf98a a hívásban: 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API hívás: 93bfb890-646c-4364-8795-9587bfdc55ba)

Információ	9. hívás: konfigurálva - API hívás láb 37a6e86d-d457-47cf-be24-1dbe20ccf98a SIP hívás ID-vel: "7e309680-cd217a6a-f239-e88214ac@172.x.x.x"

Információ	9. hívás: UDT RTP kapcsolat létrehozása DTLS-hez (összesített média és vezérlés)
Információ	8. hívás: kompenzálás a távoli vég nem megfelelő payload típusok miatt

Információ	résztvevő "690@172.x.x.x" csatlakozott a térhez: 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Információ	résztvevő "690@172.x.x.x" (289e823d-6da8-486c-a7df-fe177f05e010) csatlakozott a konferenciához: 434f88d0-8441-41e1-b6ee-6d1c63b5b098 SIP-en keresztül

Információ	7. hívás: kompenzálás a távoli vég nem megfelelő payload típusok miatt
Információ	8. hívás: nem megfelelő payload típusok mód 1/0
Információ	8. hívás: válasz az ajánlatra a nem megfelelő payload típusok módjában
Információ	8. hívás: követő egyedi kodek ajánlat érkezett
Információ	8. hívás: nem megfelelő payload típusok mód 1/0
Információ	8. hívás: válasz az ajánlatra a nem megfelelő payload típusok módjában
Információ	8. hívás: válasz küldése az egyedi kodek további ajánlatához
Információ	9. hívás: kompenzálás a távoli vég nem megfelelő payload típusok miatt

Információ	résztvevő "673@172.x.x.x" csatlakozott a térhez: 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Információ	résztvevő "673@172.x.x.x" (d27e9a53-2c8a-4e9c-9363-0415cd812767) csatlakozott a konferenciához: 434f88d0-8441-41e1-b6ee-6d1c63b5b098 SIP-en keresztül

Információ	9. hívás: BFCP (ügyfél szerep) most aktív
Információ	9. hívás: BFCP üdvözlés küldése ügyfélként, miután üdvözlés érkezett, amikor a BFCP nem volt aktív
Információ	9. hívás: BFCP (ügyfél szerep) most aktív
Információ	7. hívás: befejeződik; távoli SIP bontás - csatlakoztatva: 0:13
Információ	7. hívás: az API hívás láb bc0be45e-ce8f-411c-be04-594e0220c38e megsemmisítése

Információ	résztvevő "672@x.x.x" elhagyta a teret: 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Információ	9. hívás: függőben
Információ	9. hívás: nem megfelelő payload típusok mód 1/0
Információ	9. hívás: válasz az ajánlatra a nem megfelelő payload típusok módjában
Információ	8. hívás: függőben
Információ	8. hívás: követő egyedi kodek ajánlat érkezett
Információ	8. hívás: nem megfelelő payload típusok mód 1/0
Információ	8. hívás: válasz az ajánlatra a nem megfelelő payload típusok módjában
Információ	8. hívás: válasz küldése az egyedi kodek további ajánlatához
Információ	9. hívás: befejeződik; távoli SIP bontás - csatlakoztatva: 0:12

Az Ad-Hoc konferencia:


Bejövő hívások szabályai
A bejövő hívások paramétereinek beállítása szükséges a hívások fogadásához a CMS-ben. Ahogy az LDAP beállításában láthatták, minden felhasználó a conf.pod6.cms.lab domainről lett importálva. Tehát legalább annyit szeretne, hogy a hívások erre a domainre irányuljanak a terekhez. Emellett szabályokat kell megadnia minden olyan esetben, amikor a CMS szerverek IP-címére vagy teljes domainnevére van szükség. Az Unified CM-ben, ahol a hívásokat külsőleg kezeljük, a SIP trunkok minden CMS szerver számára külön-külön lesznek beállítva. Attól függően, hogy ezek a SIP trunkok IP-címre vagy a szerver teljes domainnevére vonatkoznak, meg fogja határozni, hogy be kell-e állítani a CMS-t a hívások fogadására, amelyek a szerver IP-címére vagy teljes domainnevére irányulnak.

A legmagasabb prioritású bejövő forgalmi szabályokkal rendelkező domain szolgál bármely felhasználói tér domainjaként. Amikor a felhasználók LDAP-on keresztül szinkronizálnak, a CMS automatikusan létrehozza a tereket, de csak a URI felhasználói részét (coSpaceUriMapping), például user.space. A domain teljes URI része ennek a szabálynak a alapján jön létre. Valójában, ha ezen a ponton bejelentkezne a Web Bridge-re, látná, hogy a Space URI-nak nincs domainje. E szabály legmagasabb prioritásúvá tételével a generált terek domainjét conf.-ra állítja.example.com.


Kimenő hívások szabályai

Ahhoz, hogy a felhasználók kimenő hívásokat kezdeményezhessenek az Unified CM klaszterbe, be kell állítani a kimenő kapcsolatok szabályait. Az Unified CM-ben, például Jabberben regisztrált végpontok domainje az example.com. A hívásokat erre a domainre standard SIP hívásokként kell irányítani az Unified CM híváskezelő csomópontjaira. Elsődleges szereplő a cucm-01.example.com szerver, míg másodlagos a cucm-02.example.com.

Az első szabály a legegyszerűbb hívásirányítást írja le a klaszter szerverei között.

Mező Helyi a domainból Az felelős, hogy mi jelenik meg a hívó SIP-URI-jában annak a számára, akit hívnak, a "@" jel után. Ha üresen hagyjuk, akkor a "@" jel után a CUCM IP-címe fog megjelenni, amin keresztül a hívás történik. Ha megadunk egy domént, akkor a "@" jel után a megadott domain fog szerepelni. Ez szükséges, hogy legyen lehetőség visszahívni, különben a SIP-URI név@ip-cím alapján nem lehet visszahívni.

Hívás, amikor meg van határozva Helyi a domainból


Hívás, amikor NEM azt írja elő Helyi a domainból


Kifejezetten meg kell adnia az Encrypted vagy Unencrypted paramétert, különben a kimenő hívások nem működnek, ezért az Auto paraméter mellett semmi sem működik.

Felvétel

A videokonferenciák rögzítése a Record szerverrel történik. A Recorder pontosan olyan, mint a Cisco Meeting Server. A Recorder nem igényel licencet. A rögzítéshez engedély szükséges a CallBridge szolgáltatásokkal rendelkező szervereken, tehát a Recording engedélyt a CallBridge komponensre kell alkalmazni, nem a Recorder szerverére. A Recorder úgy viselkedik, mint egy kiterjeszthető üzenetküldési és jelenléti protokoll (XMPP) kliens, ezért az XMPP szervernek be kell legyen kapcsolva azon a szerveren, ahol a CallBridge található.

Mivel klaszterünk van, a licencet "ki kell terjeszteni" az összes három klaszter szerverre. Ezért egyszerűen a felhasználói fiókban a licencen hozzárendeljük (hozzáadjuk) a klaszterbe tartozó összes CMS szerver a-interfészének MAC-címét.

Így kell kinéznie minden klaszter szervernek

Valójában több szcenáriója is van a Recorder elhelyezésének, de mi az alábbihoz fogunk ragaszkodni:


A Recorder konfigurálása előtt elő kell készíteni a helyet, ahová a videokonferenciákat rögzíteni fogják. Itt van link, hogyan kell beállítani az egész Recording-ot. Kiemelem a fontos pillanatokat és részleteket:

1. Jobb, ha az első szerver tanúsítványát adjuk meg a klaszterben.
2. A "Recorder unavailable" hiba akkor fordulhat elő, ha a Recorder Trust-ban nem a megfelelő tanúsítványt adtuk meg.
3. A rögzítés nem működhet, ha nem a gyökérmappa van megadva az NFS-ben.

Néha szükség van arra, hogy automatikusan rögzítse egy adott felhasználó vagy space konferenciáját.

Ehhez két CallProfile-t hozunk létre:
Rögzítési funkció nélküli


És automatikus rögzítési funkcióval


Ezután a szükséges space-hez hozzárendeljük a CallProfile-t az automatikus rögzítési funkcióval.


A CMS-ben úgy van, hogy ha a CallProfile kifejezetten kapcsolatban áll bármely space-szel vagy space-el, akkor ez a CallProfile csak ezekre a konkrét space-ekre vonatkozik. Ha viszont a CallProfile nincs egyetlen space-hez sem kapcsolva, akkor alapértelmezés szerint azokhoz a space-ekhez alkalmazható, amelyekhez kifejezetten nincs hozzárendelve CallProfile.

A következő alkalommal megpróbálom leírni, milyen módon lehet hozzáférni a CMS-hez a szervezet belső hálózatán kívül.

Források:

• 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

Forrás: habr.com