Cisco Meeting Server 2.5.2. Kluster modu eskalagarrian eta erresilientean bideokonferentziaren grabazioarekin

Zenbaki honetan CMS zerbitzari bat hutsegite-kluster moduan konfiguratzeko zailtasun batzuk erakutsi eta azalduko ditut.


teoriaOro har, hiru CMS zerbitzariaren inplementazio mota daude:

• Bakarra Konbinatua(Bakarra konbinatuta), hau da. hau da zerbitzari bat eta bertan beharrezkoak diren zerbitzu guztiak exekutatzen ari dira. Kasu gehienetan, inplementazio mota hau bezeroen barnerako sarbiderako eta zerbitzari bakar baten eskalagarritasun- eta erredundantzia-mugak arazo larria ez diren ingurune txikiagoetan soilik da egokia, edo CMSak funtzio jakin batzuk bakarrik betetzen dituen egoeretan, hala nola, ad hoc. Cisco UCMri buruzko hitzaldiak.

  Gutxi gorabeherako lan-eskema:
  

• Banaketa bakarra(Single Split) aurreko inplementazio mota hedatzen du kanpoko sarbiderako zerbitzari bereizi bat gehituz. Oinarrizko inplementazioetan, honek CMS zerbitzari bat sare desmilitarizatuko segmentu batean (DMZ) zabaltzea esan nahi zuen, non kanpoko bezeroak atzi zezaketen, eta CMS zerbitzari bat sareko nukleoan, non barneko bezeroak CMSra sar zezaketen. Inplementazio-eredu jakin hau mota deritzona ordezkatzen ari da Ertz Bakarra, zerbitzariek osatzen dutena Cisco Expressway, Firewall saihesteko gaitasun asko dituzten edo izango dituztenak, beraz, bezeroek ez dute ertzeko CMS zerbitzari dedikaturik gehitu beharrik.

  Gutxi gorabeherako lan-eskema:
  

• Eskalagarria eta erresilientea(Eskalagarria eta akatsen tolerantzia) Mota honek osagai bakoitzaren erredundantzia barne hartzen du, eta sistema zure beharretara hazten da bere ahalmen maximoraino, hutsegite kasuan erredundantzia eskaintzen duen bitartean. Single Edge kontzeptua ere erabiltzen du kanpoko sarbide segurua emateko. Hau da atal honetan ikusiko dugun mota. Kluster mota hau nola zabaldu ulertzen badugu, beste inplementazio mota batzuk ulertuko ez ezik, CMS zerbitzarien klusterrak nola sortu ere ulertuko dugu eskariaren hazkunde potentziala egokitzeko.

Inplementaziora pasatu aurretik, oinarrizko gauza batzuk ulertu behar dituzu, alegia

CMS softwarearen osagai nagusiak:

• Datu-basea: konfigurazio batzuk konbinatzeko aukera ematen dizu, hala nola markatze plana, erabiltzaileen espazioak eta erabiltzaileak beraiek. Erabilgarritasun handiko clustering-a onartzen du (maisu bakarra) soilik.
• Deitu Zubia: deien eta multimedia prozesuen kudeaketa eta prozesamenduaren kontrol osoa ematen duen audio eta bideokonferentziarako zerbitzua. Clustering onartzen du erabilgarritasun eta eskalagarritasun handiko.
• XMPP zerbitzaria: Cisco Meeting aplikazioa eta/edo WebRTC erabiliz bezeroen erregistroa eta autentifikazioaren arduraduna (denbora errealeko komunikazioa edo, besterik gabe, arakatzailean), baita osagaien arteko seinaleztapena ere. Erabilgarritasun handiagatik soilik bildu daiteke.
• Web Zubia: WebRTCrako bezeroari sarbidea ematen dio.
• Karga-orekatzailea: Konexio-puntu bakarra eskaintzen du Cisco Meeting Apps bakarreko zatiketa moduan. Kanpoko interfazea eta ataka entzuten ditu sarrerako konexioetarako. Era berean, karga-orekatzaileak XMPP zerbitzariaren sarrerako TLS konexioak onartzen ditu, eta horien bidez kanpoko bezeroetatik TCP konexioak alda ditzake.
  Gure eszenatokian ez da beharrezkoa izango.
• TURN zerbitzaria: aukera ematen duen Firewall bypass teknologia eskaintzen du
  jarri gure CMS Firewall edo NAT baten atzean Cisco Meeting App edo SIP gailuak erabiliz kanpoko bezeroak konektatzeko. Gure eszenatokian ez da beharrezkoa izango.
• Web Administratzailea: Administrazio-interfazea eta API sarbidea, Unified CM konferentzia berezietarako barne.

Konfigurazio moduak

Cisco-ren beste produktu gehienek ez bezala, Cisco Meeting Server-ek hiru konfigurazio-metodo onartzen ditu edozein inplementazio-mota egokitzeko.

• Komando-lerroa (CLI): MMP izenez ezagutzen den komando-lerroko interfazea hasierako konfigurazio eta ziurtagiri zereginetarako.
• Web Administratzailea: Batez ere, CallBridge-rekin lotutako konfigurazioetarako, batez ere klusteratutako zerbitzari bakarra konfiguratzean.
• REST API: Konfigurazio-zeregin konplexuenetarako eta datu-base multzokatuta lotutako zereginetarako erabiltzen da.

Aurrekoaz gain, protokoloa erabiltzen da SFTP fitxategiak (normalean lizentziak, ziurtagiriak edo erregistroak) transferitzeko CMS zerbitzaritik eta.

Ciscoren inplementazio gidetan zuriz eta ingelesez idatzita dago klusterra zabaldu behar dela gutxienez hiru zerbitzariak (nodoak) datu-baseen testuinguruan. Zeren Nodo kopuru bakoitiarekin bakarrik funtzionatuko du Database Master berri bat hautatzeko mekanismoak, eta, oro har, Database Masterrak konexioa du CMS zerbitzariaren datu-base gehienekin.

Eta praktikak erakusten duenez, bi zerbitzari (nodo) ez dira nahikoa. Hautaketa-mekanismoak funtzionatzen du Masterra berrabiarazi denean, Slave zerbitzaria Master bihurtzen da berrabiarazitako zerbitzaria abiarazi ondoren soilik. Hala ere, bi zerbitzarien multzo batean Maisua zerbitzaria bat-batean itzaltzen bada, orduan Slave zerbitzaria ez da Maisu bihurtuko, eta Slave itzaltzen bada, gainerako zerbitzari Maisua Esklabo bihurtuko da.

Baina XMPPren testuinguruan, benetan beharrezkoa izango litzateke hiru zerbitzariko kluster bat muntatzea, zeren adibidez, XMPP zerbitzua desgaitzen baduzu XMMP Leader egoeran dagoen zerbitzarietako batean, gainerako zerbitzarian XMPP Jarraitzaile egoeran jarraituko du eta CallBridge-ren XMPP konexioak desagertu egingo dira, zeren eta. CallBridge XMPPra soilik konektatzen da Leader egoerarekin. Eta hau kritikoa da, zeren... dei bakar bat ere ez da pasatuko.

Inplementazio-gida berdinetan XMPP zerbitzari bat duen kluster bat erakusten da.

Eta aurrekoa kontuan hartuta, argi geratzen da zergatik: hutsegite moduan dagoelako funtzionatzen du.

Gure kasuan, XMPP zerbitzaria hiru nodoetan egongo da.

Suposatzen da gure hiru zerbitzariak martxan daudela.

DNS erregistroak

Zerbitzariak konfiguratzen hasi aurretik, DNS erregistroak sortu behar dituzu А и SRV. motak:

Kontuan izan gure DNS erregistroetan bi domeinu daudela example.com eta conf.adibidea.com. Example.com Cisco Unified Communication Manager harpidedun guztiek beren URIetarako erabil dezaketen domeinua da, ziurrenik zure azpiegituran edo egongo dena. Edo example.com erabiltzaileek euren helbide elektronikoetarako erabiltzen duten domeinu berarekin bat dator. Edo zure ordenagailu eramangarriko Jabber bezeroak URI bat izan dezake [posta elektroniko bidez babestua]. Domeinua conf.example.com Cisco Meeting Server erabiltzaileentzat konfiguratuko den domeinua da. Cisco Meeting Server-en domeinua izango da conf.example.com, beraz, Jabber erabiltzaile berarentzat, user@ URIa erabili beharko litzateke Cisco Meeting Server-en saioa hastekoconf.adibidea.com.

Oinarrizko konfigurazioa

Jarraian deskribatzen diren ezarpen guztiak zerbitzari batean erakusten dira, baina klusterreko zerbitzari bakoitzean egin behar dira.

QoS

CMSa sortzen denez real-time Atzerapenekiko eta pakete galerekiko sentikorra den trafikoa, kasu gehienetan zerbitzuaren kalitatea (QoS) konfiguratzea gomendatzen da. Hori lortzeko, CMS-k paketeak etiketatzea onartzen du sortzen dituen Zerbitzu Diferentziatuen Kodeekin (DSCP). DSCPn oinarritutako trafikoaren lehentasunak zure azpiegituren sareko osagaiek trafikoa nola prozesatzen dutenaren araberakoa den arren, gure kasuan gure CMSa QoS praktika onen arabera konfiguratuko dugu DSCP lehenespen tipikoarekin.

Zerbitzari bakoitzean komando hauek sartuko ditugu

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

Horrela, bideo-trafiko guztia AF41 (DSCP 0x22) markatu zen, ahots-trafiko guztia EF (DSCP 0x2E), beste latentzia baxuko trafiko mota batzuek, hala nola SIP eta XMPP, AF31 erabiltzen dute (DSCP 0x1A).

Egiaztatzen dugu:

NTP

Network Time Protocol (NTP) garrantzitsua da deien eta konferentziaren denbora-zigilu zehatzak emateko ez ezik, ziurtagiriak egiaztatzeko ere.

Gehitu NTP zerbitzariak zure azpiegiturari bezalako komando batekin

ntp server add <server>

Gure kasuan, halako bi zerbitzari daude, beraz, bi talde egongo dira.
Egiaztatzen dugu:

Eta ezarri ordu-zona gure zerbitzariarentzat

DNS

DNS zerbitzariak CMSra gehitzen ditugu komando batekin:

dns add forwardzone <domain-name> <server ip>

Gure kasuan, halako bi zerbitzari daude, beraz, bi talde egongo dira.
Egiaztatzen dugu:

Sare-interfazearen konfigurazioa

Interfazea honelako komando batekin konfiguratzen dugu:

ipv4 <interface> add <address>/<prefix length> <gateway>

Egiaztatzen dugu:

Zerbitzariaren izena (Ostalari izena)

Zerbitzariaren izena honelako komando batekin ezarri dugu:

hostname <name>

Eta berrabiarazi egiten dugu.


Honek oinarrizko konfigurazioa osatzen du.

Ziurtagiriak

teoriaCisco Meeting Server-ek hainbat osagairen arteko komunikazio enkriptatua behar du, eta, ondorioz, X.509 ziurtagiriak behar dira CMS inplementazio guztietan. Zerbitzuak/zerbitzariak beste zerbitzari/zerbitzuek fidagarriak direla ziurtatzen laguntzen dute.

Zerbitzu bakoitzak ziurtagiri bat behar du, baina zerbitzu bakoitzerako ziurtagiri bereiziak sortzeak nahasmena eta alferrikako konplexutasuna sor ditzake. Zorionez, ziurtagiri baten gako publiko-pribatu bikotea sor dezakegu eta gero berrerabili hainbat zerbitzutan. Gure kasuan, ziurtagiri bera erabiliko da Call Bridge, XMPP Server, Web Bridge eta Web Admin. Horrela, klusterreko zerbitzari bakoitzeko ziurtagiri publiko eta pribatuen pare bat sortu behar dituzu.

Datu-baseen clustering-ak, ordea, ziurtagiri-eskakizun berezi batzuk ditu eta, beraz, bere ziurtagiri propioak behar ditu, beste zerbitzuetakoak ez direnak. CMS-k zerbitzari-ziurtagiri bat erabiltzen du, beste zerbitzariek erabiltzen dituzten ziurtagirien antzekoa dena, baina datu-basearen konexioetarako bezero-ziurtagiri bat ere badago. Datu-basearen ziurtagiriak autentifikaziorako eta enkriptatzeko erabiltzen dira. Bezeroari datu-basera konektatzeko erabiltzaile-izena eta pasahitza eman beharrean, zerbitzariak fidagarria den bezero-ziurtagiria aurkezten du. Datu-base klusterreko zerbitzari bakoitzak gako publiko eta pribatu pare bera erabiliko du. Horri esker, klusterreko zerbitzari guztiek datuak enkriptatu ditzakete, gako-pare bera partekatzen duten beste zerbitzariek soilik deszifratu ahal izateko.

Erredundantziak funtziona dezan, datu-baseen klusterrek gutxienez 3 zerbitzariz osatuta egon behar dute, baina gehienez 5, eta gehienez 200 ms-ko joan-etorria izango dute kluster kideen artean. Muga hau Call Bridge clustering-a baino murriztaileagoa da, beraz, geografikoki banatutako inplementazioetan faktore mugatzailea izan ohi da.

CMS baten datu-basearen eginkizunak baldintza berezi batzuk ditu. Beste rol batzuk ez bezala, bezeroaren eta zerbitzariaren ziurtagiria behar du, non bezeroaren ziurtagiriak zerbitzariari aurkezten zaion CN eremu zehatz bat duen.

CMS-k postgres datu-base bat erabiltzen du maisu batekin eta hainbat erreplika guztiz berdinekin. Aldi berean datu-base nagusi bakarra dago ("datu-basearen zerbitzaria"). Klusterreko gainerako kideak erreplikak edo "datu-base bezeroak" dira.

Datu-base-kluster batek zerbitzari-ziurtagiri dedikatu bat eta bezero-ziurtagiri bat behar ditu. Ziurtagirien bidez sinatu behar dira, normalean barneko autoritate ziurtagiri pribatu batek. Datu base-klusterreko edozein kide nagusi bihur daitekeenez, datu-basearen zerbitzariaren eta bezeroaren ziurtagiri-bikoteak (gako publikoak eta pribatuak dituztenak) zerbitzari guztietan kopiatu behar dira, bezeroaren edo datu-basearen zerbitzariaren identitatea bere gain hartu ahal izateko. Horrez gain, CA erroko ziurtagiria kargatu behar da bezero eta zerbitzariaren ziurtagiriak egiaztatu ahal izango direla ziurtatzeko.

Beraz, datu-baseak izan ezik zerbitzari-zerbitzu guztiek erabiliko duten ziurtagiri baten eskaera sortzen dugu (horretarako eskaera bereizia izango da) honelako komando batekin:

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

CNn gure zerbitzarien izen orokorra idazten dugu. Adibidez, gure zerbitzarien ostalari-izenak badira server01, server02, server03, orduan CN izango da zerbitzaria.adibidea.com

Gauza bera egiten dugu gainerako bi zerbitzarietan, komandoek dagozkion "ostalari-izenak" izango dituztelako.

Datu-base zerbitzuak erabiliko dituen ziurtagirien eskaera bi sortzen ditugu, honelako komandoekin:

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

pki csr dbclusterclient CN:postgres

non dbclusterserver и dbclusterclient gure eskaeren eta etorkizuneko ziurtagirien izenak, ostalari-izena1(2)(3) dagozkion zerbitzarien izenak.

Prozedura hau zerbitzari batean bakarrik egiten dugu (!), eta ziurtagiriak eta dagozkien .key fitxategiak beste zerbitzarietara igoko ditugu.

Gaitu bezeroaren ziurtagiri modua AD CSn

Era berean, zerbitzari bakoitzaren ziurtagiriak fitxategi batean batu behar dituzu.*NIX-en:

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

Windows/DOS-en:

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

Eta igo zerbitzari bakoitzean:
1. “Banakako” zerbitzariaren ziurtagiria.
2. Erro-ziurtagiria (tartekoekin batera, baldin badago).
3. Datu-basearen ziurtagiriak (“zerbitzaria” eta “bezeroa”) eta .key luzapena duten fitxategiak, “zerbitzaria” eta “bezeroa” datu-basearen ziurtagirien eskaera sortzean sortutakoak. Fitxategi hauek berdinak izan behar dute zerbitzari guztietan.
4. Hiru ziurtagiri “banakako” fitxategia.

Ondorioz, fitxategi-irudi honen antzeko zerbait lortu beharko zenuke zerbitzari bakoitzean.

Datu-baseen Klusterra

Ziurtagiri guztiak CMS zerbitzarietara igota dituzunean, hiru nodoen artean datu-baseen multzokatzea konfiguratu eta gaitu dezakezu. Lehen urratsa zerbitzari bat hautatzea da datu-basearen klusterraren nodo nagusi gisa eta guztiz konfiguratzea.

Datu-base maisua

Datu-basearen erreplikazioa konfiguratzeko lehen urratsa datu-baserako erabiliko diren ziurtagiriak zehaztea da. Hau honelako komando bat erabiliz egiten da:

database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>

Orain, esan diezaiogun CMS-ri zein interfaze erabili behar den datu-baseen clustering komandoarekin:

database cluster localnode a

Ondoren, kluster datu-basea zerbitzari nagusian hasieratuko dugu komandoarekin:

database cluster initialize

Bezeroen datu-base nodoak

Prozedura bera egiten dugu, komandoaren ordez datu-baseen kluster hasieratzea sartu honelako komando bat:

database cluster join <ip address existing master>

non kluster hasieratu zen CMS zerbitzariaren ip helbidea lehendik dagoen ip helbidea, besterik gabe, Master.

Gure datu-baseen klusterrak zerbitzari guztietan nola funtzionatzen duen egiaztatzen dugu komandoarekin:

database cluster status

Gauza bera egiten dugu gainerako hirugarren zerbitzarian.

Ondorioz, gure lehen zerbitzaria Maisua da, gainerakoak Esklaboak direla.

Web Admin Zerbitzua

Gaitu web administratzaile zerbitzua:

webadmin listen a 445

445 ataka aukeratu da 443 ataka erabiltzaileak web bezerora sartzeko erabiltzen duelako

Web Admin zerbitzua ziurtagiri fitxategiekin konfiguratzen dugu komando batekin:

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

Eta gaitu Web Admin komandoarekin:

webadmin enable

Dena ondo badago, ARRAKASTA lerroak jasoko ditugu Web Admin sarerako eta ziurtagirirako behar bezala konfiguratuta dagoela adieraziz. Web arakatzaile baten bidez zerbitzuaren funtzionaltasuna egiaztatzen dugu eta web administratzailearen helbidea sartzen dugu, adibidez: cms.adibidea.com: 445

Deitu Bridge Cluster

Call Bridge CMS inplementazio guztietan dagoen zerbitzu bakarra da. Call Bridge da konferentzia-mekanismo nagusia. SIP interfaze bat ere eskaintzen du, deiak bertara edo bertatik bideratu ahal izateko, adibidez, Cisco Unified CM batek.

Jarraian deskribatzen diren komandoak zerbitzari bakoitzean exekutatu behar dira ziurtagiri egokiekin.
Beraz:

Ziurtagiriak Call Bridge zerbitzuarekin lotzen ditugu komando batekin:

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

CallBridge zerbitzuak behar dugun interfazera lotzen ditugu komandoarekin:

callbridge listen a

Eta berrabiarazi zerbitzua komandoarekin:

callbridge restart

Orain gure Call Bridges konfiguratuta dauzkagula, Call Bridge clustering konfiguratu dezakegu. Call Bridge clustering-a datu-basearen edo XMPP clustering-aren desberdina da. Call Bridge Cluster-ek 2 eta 8 nodo onartzen ditu inolako murrizketarik gabe. Erredundantzia ez ezik, karga orekatzea ere eskaintzen du, konferentziak Call Bridge zerbitzarietan aktiboki banatu ahal izateko deien banaketa adimenduna erabiliz. CMS-k funtzio gehigarriak, Call Bridge taldeak eta erlazionatutako funtzioak ditu, kudeaketa gehiagorako erabil daitezkeenak.

Deien zubi multzoa web-administrazio-interfazearen bidez konfiguratzen da batez ere
Jarraian azaltzen den prozedura klusterreko zerbitzari bakoitzean egin behar da.
Horrela,

1. Joan sarean Konfigurazioa > Klusterra.
2. Urtean Deitu Bridge identitatea Izen esklusibo gisa, idatzi zerbitzariaren izenari dagokion callbridge[01,02,03]. Izen hauek arbitrarioak dira, baina bakarrak izan behar dute kluster honetarako. Izaera deskribatzailea dute zerbitzariaren identifikatzaileak direla adierazten dutelako [01,02,03].
3.B Dei-zubi multzokatuak sartu gure zerbitzarien web administratzailearen URLak klusterrean, cms[01,02,03].example.com:445, Helbidea eremuan. Ziurtatu ataka zehazten duzula. Peer link SIP domeinua hutsik utz dezakezu.
4. Gehitu ziurtagiri bat zerbitzari bakoitzaren CallBridge konfiantzari, zeinaren fitxategiak gure zerbitzarien ziurtagiri guztiak ditu, fitxategi honetan batu genituen hasieran, honelako komando batekin:

callbridge trust cluster <trusted cluster certificate bundle>

Eta berrabiarazi zerbitzua komandoarekin:

callbridge restart

Ondorioz, zerbitzari bakoitzean argazki hau lortu beharko zenuke:

XMPP Klusterra

CMSko XMPP zerbitzua Cisco Meeting Apps (CMA) erregistratzeko eta autentifikazio guztiak kudeatzeko erabiltzen da, CMA WebRTC web bezeroa barne. Call Bridge-k berak XMPP bezero gisa ere jokatzen du autentifikazio-helburuetarako eta, beraz, beste bezero batzuek bezala konfiguratu behar da. XMPP akatsen tolerantzia ekoizpen-inguruneetan onartzen den funtzio bat da 2.1 bertsioaz geroztik

Jarraian deskribatzen diren komandoak zerbitzari bakoitzean exekutatu behar dira ziurtagiri egokiekin.
Beraz:

Ziurtagiriak XMPP zerbitzuarekin lotzen ditugu komando batekin:

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

Ondoren, definitu entzuteko interfazea komandoarekin:

xmpp listen a

XMPP zerbitzuak domeinu bakarra behar du. Hau erabiltzaileentzako saioa da. Beste era batera esanda, erabiltzaile bat CMA aplikazioa erabiliz (edo WebRTC bezeroaren bidez) saioa hasten saiatzen denean, userID@logindomain sartzen du. Gure kasuan userid@ izango daconf.adibidea.com. Zergatik ez da example.com besterik? Gure hedapen zehatzean, Jabber-eko erabiltzaileek Unified CM-n erabiliko duten gure Unified CM domeinua hautatu genuen example.com gisa, beraz, beste domeinu bat behar genuen CMS erabiltzaileek deiak CMSra eta SIP domeinuen bidez bideratzeko.

Konfiguratu XMPP domeinu bat honelako komando bat erabiliz:

xmpp domain <domain>

Eta gaitu XMPP zerbitzua komandoarekin:

xmpp enable

XMPP zerbitzuan, XMPP zerbitzuan erregistratzean erabiliko den Call Bridge bakoitzeko kredentzialak sortu behar dituzu. Izen hauek arbitrarioak dira (eta ez daude erlazionatuta dei-zubiak multzokatzeko konfiguratu dituzun izen esklusiboekin). Hiru dei-zubi gehitu behar dituzu XMPP zerbitzari batean eta, ondoren, kredentzial horiek klusterreko beste XMPP zerbitzarietan sartu behar dituzu, konfigurazio hau ez baitator kluster datu-basean. Geroago Call Bridge bakoitza konfiguratuko dugu izen eta sekretu hori erabiltzeko XMPP zerbitzuan erregistratzeko.

Orain XMPP zerbitzua konfiguratu behar dugu lehen zerbitzarian hiru Call Bridges callbridge01, callbridge02 eta callbridge03. Kontu bakoitzari ausazko pasahitzak esleituko zaizkio. Geroago, beste Call Bridge zerbitzarietan sartuko dira XMPP zerbitzari honetan saioa hasteko. Sartu komando hauek:

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

Ondorioz, komandoarekin zer gertatu den egiaztatu dugu:

xmpp callbridge list

Zehazki irudi bera agertu beharko litzateke gainerako zerbitzarietan behean deskribatzen diren urratsen ondoren.

Ondoren, ezarpen berdinak gehitzen ditugu gainerako bi zerbitzarietan, komandoekin bakarrik

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

Sekretua kontu handiz gehitzen dugu, adibidez, bertan leku gehigarririk ez egon dadin.


Ondorioz, zerbitzari bakoitzak irudi bera izan beharko luke:

Ondoren, klusterreko zerbitzari guztietan, hiru ziurtagiriak dituen fitxategia fidagarrian zehazten dugu, lehenago honelako komando batekin sortua:

xmpp cluster trust <trust bundle>

Xmpp cluster modua gaitzen dugu kluster zerbitzari guztietan komandoarekin:

xmpp cluster enable

Klusterraren lehen zerbitzarian, xmpp kluster bat sortzen hasten dugu komandoarekin:

xmpp cluster initialize

Beste zerbitzarietan, gehitu kluster bat xmpp-en komando batekin:

xmpp cluster join <ip address head xmpp server>

Zerbitzari bakoitzean zerbitzari bakoitzean XMPP kluster bat sortzearen arrakasta egiaztatzen dugu komando hauekin:

xmpp status
xmpp cluster status

Lehen zerbitzaria:

Bigarren zerbitzaria:

Hirugarren zerbitzaria:

Call Bridge XMPP-ra konektatzen

XMPP clusterra exekutatzen ari denez, Call Bridge zerbitzuak konfiguratu behar dituzu XMPP clusterra konektatzeko. Konfigurazio hau web administratzailearen bidez egiten da.

Zerbitzari bakoitzean, joan Konfigurazioa > Orokorra eta eremuan Call Bridge izen berezia idatzi zerbitzariari dagozkion Call Bridge izen esklusiboak callbridge[01,02,03]... Eremuan domeinu conf.example.ru eta dagozkien pasahitzak, haiek espioi ditzakezu
komandoarekin klusterreko edozein zerbitzarian:

xmpp callbridge list

Utzi "Zerbitzaria" eremua hutsik Callbridge DNS SRV bilaketa bat egingo du _xmpp-component._tcp.conf.example.comerabilgarri dagoen XMPP zerbitzari bat aurkitzeko. Callbridge-ak XMPP-ra konektatzeko IP helbideak desberdinak izan daitezke zerbitzari bakoitzean, erregistro-eskaerara itzultzen diren balioen araberakoa da. _xmpp-component._tcp.conf.example.com callbridge, DNS erregistro jakin baterako lehentasun-ezarpenen araberakoa dena.

Ondoren, joan Egoera > Orokorra atalera, Call Bride zerbitzua XMPP zerbitzura behar bezala konektatuta dagoen egiaztatzeko.

Web Zubia

Klusterreko zerbitzari bakoitzean, gaitu Web Bridge zerbitzua komandoarekin:

webbridge listen a:443

Web Bridge zerbitzua ziurtagiri fitxategiekin konfiguratzen dugu komando batekin:

webbridge  certs <keyfile> <certificatefile> <ca bundle>

Web Bridge-k HTTPS onartzen du. HTTP HTTPSera birbideratuko du "http-redirect" erabiltzeko konfiguratuta badago.
HTTP birbideratzea gaitzeko, erabili komando hau:

webbridge http-redirect enable

Call Bridge-ri jakinarazteko Web Bridge-k Call Bridge-ko konexioak fida ditzakeela, erabili komandoa:

webbridge trust <certfile>

non hau klusterreko zerbitzari bakoitzeko hiru ziurtagiriak dituen fitxategi bat da.

Irudi honek klusterreko zerbitzari guztietan egon behar du.


Orain "appadmin" rola duen erabiltzaile bat sortu behar dugu, behar dugu gure klusterra konfiguratu ahal izateko (!), eta ez klusterreko zerbitzari bakoitza bereizita, horrela ezarpenak berdin aplikatuko dira zerbitzari bakoitzari, nahiz eta izan ere, behin egingo dira.


Konfigurazio gehiagorako erabiliko dugu Postaria.

Baimena lortzeko, hautatu Oinarrizkoa Baimena atalean

CMS zerbitzariari komandoak behar bezala bidaltzeko, beharrezko kodeketa ezarri behar duzu

Webbridge komandoarekin zehazten dugu POST parametroarekin url eta esanahia cms.adibidea.com



Webbridgen bertan, beharrezkoak diren parametroak adierazten ditugu: gonbidatuen sarbidea, babestutako sarbidea, etab.

Deitu Zubietako Taldeak

Lehenespenez, CMSak ez ditu beti erabilgarri dituen konferentzia-baliabideen erabilerarik eraginkorrena egiten.

Esaterako, hiru parte-hartzaileko bilera batean, parte-hartzaile bakoitzak hiru Call Bridge desberdinetan amai dezake. Hiru parte-hartzaile hauek elkarren artean komunikatzeko, Call Bridges-ek automatikoki ezarriko ditu konexioak espazio berean zerbitzari eta bezero guztien artean, denak bezero guztiak zerbitzari berean egongo balira bezala izan dadin. Zoritxarrez, honen alde txarra da 3 pertsonako konferentzia bakar batek 9 multimedia ataka kontsumituko dituela orain. Baliabideen erabilera ez-eraginkorra da, jakina. Gainera, Call Bridge bat benetan gainkargatuta dagoenean, mekanismo lehenetsia deiak onartzen jarraitzea eta Call Bridge horren harpidedun guztiei kalitate murriztuko zerbitzua eskaintzea da.

Arazo hauek Call Bridge Group funtzioa erabiliz konpontzen dira. Ezaugarri hau Cisco Meeting Server softwarearen 2.1 bertsioan sartu zen eta hedatu egin da sarrerako eta irteerako Cisco Meeting App (CMA) deietarako karga orekatzeko, WebRTC parte-hartzaileak barne.

Berriro konektatzeko arazoa konpontzeko, hiru karga-muga konfiguragarri ezarri dira Call Bridge bakoitzeko:

Karga-muga — Hau Call Bridge jakin baterako zenbakizko karga maximoa da. Plataforma bakoitzak gomendatutako karga-muga du, adibidez, 96000 CMS1000rako eta 1.25 GHz vCPU bakoitzeko makina birtualerako. Dei ezberdinek baliabide kopuru jakin bat kontsumitzen dute parte-hartzailearen bereizmenaren eta fotograma-abiaduraren arabera.
BerriaConferenceLoadLimitBasisPoints (lehenetsia %50 loadLimit) - zerbitzariaren karga-muga ezartzen du, eta ondoren, hitzaldi berriak baztertzen dira.
ExistingConferenceLoadLimitBasisPoints (loadLimit-en % 80 lehenetsia) - zerbitzariaren karga-balioa eta horren ondoren lehendik dagoen konferentzia batean sartzen diren parte-hartzaileak baztertu egingo dira.

Ezaugarri hau deiak banatzeko eta karga orekatzeko diseinatu zen arren, beste talde batzuk, hala nola, TURN zerbitzariak, Web Bridge zerbitzariak eta grabagailuak Call Bridge Taldeei ere eslei diezaiekete, horiek ere behar bezala taldekatu ahal izateko erabilera optimorako. Objektu horietakoren bat dei-talde bati esleitzen ez bazaio, zerbitzari guztientzat erabilgarri egongo da lehentasun berezirik gabe.

Parametro hauek hemen konfiguratzen dira: cms.adibidea.com:445/api/v1/system/configuration/cluster

Ondoren, callbridge bakoitzari zein callbridge talderi dagokion adieraziko diogu:

Lehenengo callbridge

Bigarren callbridge

Hirugarren callbridge


Horrela, Call Brdge taldea konfiguratu dugu Cisco Meeting Server klusterraren baliabideak modu eraginkorragoan erabiltzeko.

Erabiltzaileak Active Directory-tik inportatzea

Web Admin zerbitzuak LDAP konfigurazio atal bat du, baina ez du konfigurazio-aukera konplexurik ematen, eta informazioa ez da kluster datu-basean gordetzen, beraz, konfigurazioa egin beharko da, eskuz zerbitzari bakoitzean Web interfazearen bidez, edo bidez. APIa, eta, horrela, "hiru aldiz "Ez altxatu" egiteko, oraindik ere datuak ezarriko ditugu APIaren bidez.

Sartzeko URLa erabiltzen cms01.adibidea.com:445/api/v1/ldapServers-ek LDAP zerbitzariaren objektu bat sortzen du, parametroak zehaztuz:

• Zerbitzariaren IPa
• ataka zenbakia
• erabiltzaile-izena
• pasahitza
• ziurtatzeko

Segurua - hautatu egia ala gezurra atakaren arabera, 389 - ez segurua, 636 - babestua.


LDAP iturburu-parametroak Cisco Meeting Server-en atributuekin mapatzea.
LDAP mapak LDAP direktorioko atributuak CMSko atributuekin mapatzen ditu. Benetako ezaugarriak:

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Atributuen deskribapenaJID erabiltzailearen saioa hasteko IDa adierazten du CMSan. Hau Microsoft Active Directory LDAP zerbitzaria denez, CMS JID-ak LDAPeko sAMAccountName-ra mapatzen du, hau da, funtsean, erabiltzailearen Active Directory-ren saio-hasiera IDa. Kontuan izan sAMAccountName hartzen duzula eta amaieran conf.pod6.cms.lab domeinua gehitzen duzula, hau da zure erabiltzaileek CMSan saioa hasteko erabiliko duten saioa delako.

nameMapping Active Directory displayName eremuan jasotakoa erabiltzailearen CMS izenaren eremuarekin bat egiten du.

coSpaceNameMapping CMS espazio-izena sortzen du displayName eremuan oinarrituta. Atributu hau, coSpaceUriMapping atributuarekin batera, erabiltzaile bakoitzarentzako espazio bat sortzeko behar dena da.

coSpaceUriMapping erabiltzailearen espazio pertsonalarekin lotutako URIaren erabiltzailearen zatia definitzen du. Domeinu batzuk espaziora markatzeko konfigura daitezke. Erabiltzaile-zatia eremu honekin bat badator domeinu horietako batean, deia erabiltzailearen espaziora bideratuko da.

coSpaceSecondaryUriMapping bigarren URI bat definitzen du espaziora iristeko. Hau erabil daiteke inportatutako erabiltzailearen espaziora deiak bideratzeko zenbakizko alias bat gehitzeko, coSpaceUriMapping parametroan definitutako URI alfanumerikoaren alternatiba gisa.

LDAP zerbitzaria eta LDAP mapa konfiguratuta daude. Orain elkarrekin lotu behar dituzu LDAP iturri bat sortuz.

Sartzeko URLa erabiltzen cms01.adibidea.com:445/api/v1/ldapSource sortu LDAP iturburu-objektu bat, parametroak zehaztuz:

• zerbitzaria
• mapping
• oinarriDn
• iragazi

Orain LDAP konfigurazioa osatuta dagoenean, eskuzko sinkronizazio eragiketa egin dezakezu.

Hau zerbitzari bakoitzaren Web interfazean egiten dugu klik eginez Sinkronizatu orain Atal Active Directory


edo API bidez komandoarekin POST URLa erabiliz sartzeko cms01.adibidea.com:445/api/v1/ldapSyncs

Ad-Hoc jardunaldiak

Zer da hau?Kontzeptu tradizionalean, konferentzia bat da bi parte-hartzaile elkarri hitz egiten ari direnean, eta parte-hartzaileetako batek (Unified CM-n erregistratutako gailu bat erabiliz) "Konferentzia" botoia sakatzen du, beste pertsonari deitzen dio eta hirugarren horrekin hitz egin ondoren. , sakatu berriro "Konferentzia" botoia Hiruko konferentzian parte-hartzaile guztiekin batzeko.

Ad-Hoc konferentzia bat CMS batean programatutako konferentzia batetik bereizten duena da Ad-Hoc konferentzia bat ez dela CMS baterako SIP dei bat. Konferentziaren hastapenak bigarren aldiz Konferentzia botoian klik egiten duenean denak bilera berera gonbidatzeko, Unified CM-k API dei bat egin behar du CMS-ra, etengabeko konferentzia bat sortzeko, zeinetara dei guztiak transferitzeko. Hori guztia parte-hartzaileek oharkabean gertatzen da.

Horrek esan nahi du Unified CM-k API kredentzialak eta zerbitzuaren WebAdmin helbidea/ataka eta SIP Trunk zuzenean CMS zerbitzarira konfiguratu behar dituela deia jarraitzeko.

Beharrezkoa izanez gero, CUCM-k CMS-an espazio bat sor dezake dinamikoki, dei bakoitza CMSra irits dadin eta espazioetarako aurreikusitako sarrerako deien arauarekin bat etor dadin.

CUCM-rekin integratzea artikuluan azaltzen den modu berean konfiguratuta lehenago izan ezik, Cisco UCM-en CMSrako hiru enbor sortu behar dituzu, hiru Konferentzia-zubi, SIP Segurtasun Profilean hiru Subjektu-izenak, Ibilbide-taldeak, Ibilbide-zerrendak, Multimedia-baliabide-taldeak eta Multimedia-baliabide-taldeen zerrendak zehaztu eta bideratze-arau batzuk gehitu. Cisco Meeting Server-era.

SIP Segurtasun Profila:


Enborrak:


Enbor bakoitzak itxura berdina du:




Konferentzia zubia


Konferentzia-zubi bakoitzak itxura berdina du:


Ibilbide Taldea


Ibilbideen zerrenda


Komunikabideen Baliabideen Taldea


Komunikabideen baliabideen taldeen zerrenda

Deiaren Arauak

Unified CM edo Expressway bezalako deiak kudeatzeko sistema aurreratuagoak ez bezala, CMS-k SIP Request-URI eremuan soilik bilatzen du domeinua dei berrietarako. Beraz, SIP INVITE zurrutadarako bada: [posta elektroniko bidez babestua]CMS-k domeinua.com-i bakarrik axola dio. CMS-k arau hauek jarraitzen ditu dei bat non bideratu zehazteko:

1. CMS lehenik SIP domeinua sarrerako deien arauetan konfiguratutako domeinuekin bat egiten saiatzen da. Ondoren, dei hauek espazioetara edo erabiltzaile zehatzetara, barneko IVRetara edo zuzenean integratutako Microsoft Lync/Skype for Business (S4B) helmugetara bideratu daitezke.
2. Sarrerako deien arauetan bat ez badago, CMS deiak desbideratzeko taulan konfiguratutako domeinuarekin bat egiten saiatuko da. Bat-etortze bat egiten bada, arauak deia berariaz baztertu edo deia birbidal dezake. Une honetan, CMSak domeinua berridatzi dezake, eta hori batzuetan erabilgarria da Lync domeinuetara deitzeko. Bota pasatzea ere aukeratu dezakezu, hau da, eremuetako bat ere ez da gehiago aldatuko edo CMS barneko markatze-plan bat erabili. Deiak desbideratzeko arauetan bat ez badago, lehenetsia deia baztertzea da. Kontuan izan CMSan, deia "desbideratuta" den arren, hedabideak CMSra lotuta daudela, hau da, seinaleztapenaren eta hedabideen trafikoaren bidetik egongo da.
Orduan, desbideratutako deiak bakarrik daude irteerako deien arauen menpe. Ezarpen hauek zehazten dituzte deiak bidaltzen diren helmugak, enbor mota (Lync dei berria edo SIP dei estandarra den) eta deiak desbideratzeko arauan transferentzia hautatzen ez bada egin daitezkeen bihurketak.

Hona hemen Ad-Hoc konferentzia batean gertatzen denaren benetako erregistroa

Pantaila-argazkiak gaizki erakusten du (ez dakit nola hobetu), beraz, honela idatziko dut erregistroa:

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 konferentzia bera:


Sarrerako deien arauak
Sarrerako deien parametroak konfiguratzea beharrezkoa da CMSan dei bat jaso ahal izateko. LDAP konfigurazioan ikusi zenuten bezala, erabiltzaile guztiak conf.pod6.cms.lab domeinuarekin inportatu ziren. Beraz, gutxienez, domeinu honetarako deiak espazioetara bideratzeko nahi dituzu. Era berean, arauak ezarri beharko dituzu CMS zerbitzari bakoitzaren domeinu-izen guztiz kualifikaturako (eta agian IP helbidea ere) pentsatuta dagoen guztiarentzat. Gure kanpoko deien kontrolak, Unified CM-k, CMS zerbitzari bakoitzari banan-banan eskainitako SIP enborrak konfiguratuko ditu. SIP trunk hauen helmuga IP helbide bat den edo zerbitzariaren FQDNak zehaztuko du CMSa bere IP helbidera edo FQDNra zuzendutako deiak onartzeko konfiguratu behar den ala ez.

Sarrerako lehentasun handiena duen domeinua edozein erabiltzaile-espaziorako domeinu gisa erabiltzen da. Erabiltzaileak LDAP bidez sinkronizatzen direnean, CMSak automatikoki sortzen ditu espazioak, baina URIaren erabiltzailearen zatia soilik (coSpaceUriMapping), adibidez, user.space. Zatia domeinu Arau honetan oinarrituta sortzen da URI osoa. Izan ere, une honetan Web Bridgen saioa hasiko bazenu, ikusiko zenuke Space URIak ez duela domeinurik. Arau hau lehentasun handiena ezarriz gero, sortutako espazioen domeinua ezartzen ari zara konf.adibidea.com.


Irteerako deien arauak

Erabiltzaileek Unified CM clusterra irteerako deiak egin ditzaten, irteerako arauak konfiguratu behar dituzu. Unified CM-n erregistratutako azken puntuen domeinua, hala nola Jabber, example.com da. Domeinu honetarako deiak SIP dei estandar gisa bideratu behar dira Unified CM deiak prozesatzeko nodoetara. Zerbitzari nagusia cucm-01.example.com da, eta gehigarria cucm-02.example.com.

Lehen arauak cluster zerbitzarien arteko deien bideratze errazena deskribatzen du.

Field Domeinutik lokala deitzen duenaren SIP-URIan bistaratuko denaren arduraduna da deitzen ari den pertsona "@" ikurraren ondoren. Hutsik uzten badugu, "@" sinboloaren ondoren dei hau pasatzen den CUCMren IP helbidea egongo da. Domeinu bat zehazten badugu, "@" sinboloaren ondoren domeinu bat egongo da. Beharrezkoa da dei egin ahal izateko, bestela ezin izango da berriro deitu SIP-URI izena@ip-helbidea bidez.

Deitu adierazitakoan Domeinutik lokala


Deitu noiz EZ adierazi Domeinutik lokala


Ziurtatu Enkriptatua edo Enkriptatu gabea esplizituki zehazten duzula irteerako deietarako, ezerk ez baitu funtzionatzen Auto parametroarekin.

Grabaketa

Bideokonferentziak Grabaketa zerbitzariak grabatzen ditu. Grabagailua Cisco Meeting Server-en berdina da. Grabagailuak ez du inolako lizentziarik instalatu behar. Grabatzeko lizentziak behar dira CallBridge zerbitzuak exekutatzen dituzten zerbitzarientzat, hau da. Grabaketa lizentzia behar da eta CallBridge osagaiari aplikatu behar zaio, eta ez Recorder exekutatzen duen zerbitzariari. Grabagailuak Mezularitza eta Presentzia Protokolo Hedagarri baten (XMPP) bezero gisa jokatzen du, beraz, XMPP zerbitzaria gaituta egon behar da CallBridge ostatatzen duen zerbitzarian.

Zeren Kluster bat dugu eta lizentzia klusterreko hiru zerbitzarietan "hedatu" behar da. Ondoren, besterik gabe, zure kontu pertsonalean lotzen (gehitu) ditugun lizentzietan CMS zerbitzari guztien a-interfazeen MAC helbideak lotzen ditugu.

Eta hau da klusterreko zerbitzari guztietan egon beharko lukeen argazkia

Oro har, hainbat eszenatoki daude Recorder jartzeko, baina honi eutsiko diogu:


Grabagailua konfiguratu aurretik, bideokonferentziak benetan grabatuko diren leku bat prestatu behar duzu. Egia esan hemen link, Grabaketa guztiak nola konfiguratu. Puntu eta xehetasun garrantzitsuetan zentratzen naiz:

1. Hobe da klusterreko lehen zerbitzaritik ziurtagiria irristatu.
2. "Grabagailua ez dago erabilgarri" errorea gerta daiteke, ziurtagiri okerra zehaztuta dagoelako Recorder Trust-en.
3. Baliteke idazketak ez funtzionatzea, grabatzeko zehaztutako NFS direktorioa erroko direktorioa ez bada.

Batzuetan, erabiltzaile edo espazio zehatz baten konferentzia automatikoki grabatu beharra dago.

Horretarako, bi dei-profil sortzen dira:
Grabaketa desgaituta


Eta grabaketa automatikoko funtzioarekin


Ondoren, Grabazio-funtzio automatikoa duen CallProfile bat "eratxikitzen dugu" behar den espazioan.


CMS-n horrela ezarrita dago CallProfile bat edozein espazio edo espaziori esplizituki lotuta badago, Dei-Profile honek espazio espezifiko horiekin bakarrik funtzionatzen du. Eta CallProfile ez badago inolako espazio batera lotuta, lehenespenez CallProfile esplizituki lotzen ez duten espazio horiei aplikatzen zaie.

Hurrengoan saiatuko naiz deskribatzen nola sartzen den CMSra erakundearen barne saretik kanpo.

Iturriak:

• 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

Iturria: www.habr.com