Cisco Meeting Server 2.5.2. Klusteri skaalautuvassa ja joustavassa tilassa videoneuvottelun tallennuksella

Tässä numerossa näytän ja selitän joitain CMS-palvelimen asennuksessa vikasietoklusteritilassa.


teoriaYleisesti ottaen on olemassa kolmenlaisia ​​CMS-palvelinten käyttöönottoja:

• Yksittäinen yhdistetty(Yksi yhdistetty), ts. tämä on yksi palvelin, jolla kaikki tarvittavat palvelut ovat käynnissä. Useimmissa tapauksissa tämäntyyppinen käyttöönotto soveltuu vain sisäiseen asiakaskäyttöön ja pienempiin ympäristöihin, joissa yksittäisen palvelimen skaalautuvuus- ja redundanssirajoitukset eivät ole kriittisiä, tai tilanteissa, joissa CMS suorittaa vain tiettyjä toimintoja, kuten ad hoc. Cisco UCM -konferenssit.

  Suunniteltu työsuunnitelma:
  

• Yksittäinen jaettu(Single Split) laajentaa edellistä käyttöönottotyyppiä lisäämällä erillisen palvelimen ulkoista käyttöä varten. Vanhoissa käyttöönotoissa tämä tarkoitti CMS-palvelimen käyttöönottoa demilitarisoidussa verkkosegmentissä (DMZ), jossa ulkoiset asiakkaat voivat käyttää sitä, ja yhtä CMS-palvelinta verkon ytimessä, jossa sisäiset asiakkaat voivat käyttää CMS:ää. Tämä erityinen käyttöönottomalli on nyt korvattu niin sanotulla tyypillä Yksi reuna, joka koostuu palvelimista Cisco Expressway, joilla on tai tulee olemaan monia samoja palomuurin ohitusominaisuuksia, joten asiakkaiden ei tarvitse lisätä erillistä reuna-CMS-palvelinta.

  Suunniteltu työsuunnitelma:
  

• Skaalautuva ja joustava(Skaalautuva ja vikasietoinen) Tämä tyyppi sisältää redundanssin jokaiselle komponentille, mikä mahdollistaa järjestelmän kasvamisen tarpeidesi mukaan maksimikapasiteettiin ja tarjoaa redundanssin vian sattuessa. Se käyttää myös Single Edge -konseptia turvallisen ulkoisen pääsyn tarjoamiseen. Tämä on tyyppi, jota tarkastelemme tässä jaksossa. Jos ymmärrämme, kuinka tämän tyyppisiä klustereita otetaan käyttöön, emme vain ymmärrä muun tyyppisiä käyttöönottoja, vaan pystymme myös ymmärtämään, miten luodaan CMS-palvelimien klustereita kysynnän mahdollisen kasvun huomioon ottamiseksi.

Ennen kuin siirryt käyttöönottoon, sinun on ymmärrettävä joitain perusasioita, nimittäin

Tärkeimmät CMS-ohjelmistokomponentit:

• tietokanta: Voit yhdistää joitain määrityksiä, kuten soittosuunnitelmaa, käyttäjätiloja ja itse käyttäjiä. Tukee vain klusterointia korkeaa käytettävyyttä varten (yksi isäntä).
• Soita Bridgelle: ääni- ja videoneuvottelupalvelu, joka tarjoaa täyden hallinnan puhelujen ja multimediaprosessien hallinnasta ja käsittelystä. Tukee klusterointia korkean käytettävyyden ja skaalautuvuuden takaamiseksi.
• XMPP-palvelin: vastaa asiakkaiden rekisteröinnistä ja todentamisesta käyttämällä Cisco Meeting -sovellusta ja/tai WebRTC(reaaliaikainen viestintä tai yksinkertaisesti selaimessa), sekä komponenttien välinen signalointi. Voidaan ryhmitellä vain korkeaa käytettävyyttä varten.
• Web Bridge: Tarjoaa asiakkaan pääsyn WebRTC:hen.
• Kuormituksen tasapainotin: Tarjoaa yhden yhteyspisteen Cisco Meeting Apps -sovelluksille Single Split -tilassa. Kuuntelee ulkoista liitäntää ja porttia saapuvia yhteyksiä varten. Samoin kuormituksen tasapainotin hyväksyy saapuvat TLS-yhteydet XMPP-palvelimelta, jonka kautta se voi vaihtaa TCP-yhteyksiä ulkoisista asiakkaista.
  Meidän skenaariossamme sitä ei tarvita.
• KÄÄNTÄ palvelin: Tarjoaa palomuurin ohitustekniikan, joka mahdollistaa
  aseta CMS:mme palomuurin tai NAT:n taakse ulkoisten asiakkaiden yhdistämiseksi Cisco Meeting App -sovelluksen tai SIP-laitteiden avulla. Meidän skenaariossamme sitä ei tarvita.
• Verkkojärjestelmänvalvoja: Hallinnollinen käyttöliittymä ja API-käyttö, mukaan lukien erityiset Unified CM -konferenssit.

Konfigurointitilat

Toisin kuin useimmat muut Ciscon tuotteet, Cisco Meeting Server tukee kolmea määritysmenetelmää minkä tahansa tyyppisen käyttöönoton mahdollistamiseksi.

• Komentorivi (CLI): Komentoriviliittymä, joka tunnetaan nimellä MMP, alkumääritys- ja varmennetehtäviä varten.
• Web-järjestelmänvalvoja: Ensisijaisesti CallBridgeen liittyville kokoonpanoille, erityisesti kun määritetään yksittäinen klusteripalvelin.
• REST API: Käytetään monimutkaisimpiin konfigurointitehtäviin ja klusteroituihin tietokantoihin liittyviin tehtäviin.

Edellä mainittujen lisäksi käytetään protokollaa SFTP siirtää tiedostoja – yleensä lisenssejä, varmenteita tai lokeja – CMS-palvelimelle ja sieltä pois.

Ciscon käyttöönotto-oppaissa on kirjoitettu valkoisella ja englanniksi, että klusteri on otettava käyttöön vähintään kolme palvelimet (solmut) tietokantojen yhteydessä. Koska Vain parittomalla määrällä solmuja toimii uuden tietokantasätäjän valintamekanismi, ja yleensä tietokantapäälliköllä on yhteys useimpiin CMS-palvelintietokantoihin.

Ja kuten käytäntö osoittaa, kaksi palvelinta (solmua) ei todellakaan riitä. Valintamekanismi toimii, kun isäntä käynnistetään uudelleen, orjapalvelimesta tulee isäntä vasta kun uudelleenkäynnistetty palvelin on tuotu esiin. Jos kuitenkin kahden palvelimen klusterissa pääpalvelin yhtäkkiä sammuu, orjapalvelimesta ei tule isäntäpalvelinta, ja jos orjapalvelin sammuu, jäljelle jääneestä pääpalvelimesta tulee orjapalvelin.

Mutta XMPP:n yhteydessä olisi todella tarpeen koota kolmen palvelimen klusteri, koska jos esimerkiksi poistat XMPP-palvelun käytöstä jollakin palvelimista, jossa XMMP on Leader-tilassa, niin jäljellä olevalla palvelimella XMPP pysyy seuraajatilassa ja CallBridge-yhteydet XMPP:hen katkeavat, koska CallBridge muodostaa yhteyden yksinomaan XMPP:hen Leader-tilalla. Ja tämä on kriittistä, koska... yksikään puhelu ei mene läpi.

Samoissa käyttöönotto-oppaissa esitetään myös klusteri, jossa on yksi XMPP-palvelin.

Ja kun otetaan huomioon yllä oleva, käy selväksi miksi: se toimii, koska se on vikasietotilassa.

Meidän tapauksessamme XMPP-palvelin on läsnä kaikissa kolmessa solmussa.

Oletetaan, että kaikki kolme palvelinta ovat päällä.

DNS-tietueet

Ennen kuin aloitat palvelimien määrityksen, sinun on luotava DNS-tietueet А и SRV tyypit:

Huomaa, että DNS-tietueissamme on kaksi verkkotunnusta example.com ja conf.example.com. Esimerkki.com on toimialue, jota kaikki Cisco Unified Communication Manager -tilaajat voivat käyttää URI-tunnuksilleen, jotka todennäköisimmin ovat infrastruktuurissasi tai todennäköisesti ovat olemassa. Tai example.com vastaa samaa verkkotunnusta, jota käyttäjät käyttävät sähköpostiosoitteessaan. Tai kannettavan tietokoneen Jabber-asiakkaalla voi olla URI [sähköposti suojattu]. Verkkotunnus conf.example.com on toimialue, joka määritetään Cisco Meeting Server -käyttäjille. Cisco Meeting Serverin toimialue on conf.example.com, joten samaa Jabber-käyttäjää varten user@ URI:tä on käytettävä kirjautumiseen Cisco Meeting Serveriinconf.example.com.

Peruskokoonpano

Kaikki alla kuvatut asetukset näkyvät yhdellä palvelimella, mutta ne on tehtävä jokaiselle klusterin palvelimelle.

QoS

Koska CMS luo reaaliaikainen liikenne on herkkä viiveille ja pakettien katoamiselle, useimmissa tapauksissa on suositeltavaa määrittää palvelun laatu (QoS). Tämän saavuttamiseksi CMS tukee pakettien merkitsemistä luomillaan Differentiated Services Codes (DSCP:illä) -koodeilla. Vaikka DSCP-pohjainen liikenteen priorisointi riippuu siitä, kuinka infrastruktuurisi verkkokomponentit käsittelevät liikennettä, meidän tapauksessamme konfiguroimme CMS:n tyypillisellä DSCP-priorisoinnilla QoS:n parhaiden käytäntöjen perusteella.

Jokaiselle palvelimelle syötetään nämä komennot

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

Siten kaikki videoliikenne merkittiin AF41:ksi (DSCP 0x22), kaikki puheliikenne merkittiin EF:ksi (DSCP 0x2E), muun tyyppinen matalaviiveinen liikenne, kuten SIP ja XMPP, käyttävät AF31:tä (DSCP 0x1A).

tarkista:

NTP

Network Time Protocol (NTP) on tärkeä paitsi tarkkojen puhelujen ja neuvottelujen aikaleimien tarjoamisessa, myös varmenteiden tarkistamisessa.

Lisää NTP-palvelimia infrastruktuuriisi komennolla kuten

ntp server add <server>

Meidän tapauksessamme tällaisia ​​palvelimia on kaksi, joten joukkueita on kaksi.
tarkista:

Ja aseta aikavyöhyke palvelimellemme

DNS

Lisäämme DNS-palvelimet CMS:ään komennolla, kuten:

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

Meidän tapauksessamme tällaisia ​​palvelimia on kaksi, joten joukkueita on kaksi.
tarkista:

Verkkoliitännän asetukset

Määritämme käyttöliittymän komennolla, kuten:

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

tarkista:

Palvelimen nimi (isäntänimi)

Asetamme palvelimen nimen komennolla, kuten:

hostname <name>

Ja käynnistetään uudelleen.


Tämä viimeistelee peruskokoonpanon.

Sertifikaatit

teoriaCisco Meeting Server vaatii salattua tiedonsiirtoa eri komponenttien välillä, minkä seurauksena X.509-varmenteet vaaditaan kaikkiin CMS-käyttöönottoihin. Ne auttavat varmistamaan, että muut palvelimet/palvelut luottavat palveluihin/palvelimeen.

Jokainen palvelu vaatii varmenteen, mutta erillisten varmenteiden luominen kullekin palvelulle voi aiheuttaa sekaannusta ja tarpeetonta monimutkaisuutta. Onneksi voimme luoda varmenteen julkisen ja yksityisen avainparin ja käyttää niitä sitten uudelleen useissa palveluissa. Meidän tapauksessamme samaa varmennetta käytetään Call Bridgessä, XMPP-palvelimessa, Web Bridgessä ja Web Adminissa. Siksi sinun on luotava pari julkisia ja yksityisiä varmenneavaimia kullekin klusterin palvelimelle.

Tietokantaklusterilla on kuitenkin joitain erityisiä varmennevaatimuksia, ja siksi se vaatii omia varmenteita, jotka eroavat muiden palveluiden varmenteista. CMS käyttää palvelinvarmennetta, joka on samanlainen kuin muiden palvelimien käyttämät varmenteet, mutta tietokantayhteyksiin on myös asiakassertifikaatti. Tietokantavarmenteita käytetään sekä todentamiseen että salaukseen. Sen sijaan, että se antaisi asiakkaalle käyttäjätunnuksen ja salasanan muodostaakseen yhteyden tietokantaan, se esittää asiakasvarmenteen, johon palvelin luottaa. Jokainen tietokantaklusterin palvelin käyttää samaa julkista ja yksityistä avainparia. Tämä sallii kaikkien klusterin palvelinten salata tiedot siten, että vain muut palvelimet, jotka jakavat saman avainparin, voivat purkaa sen salauksen.

Jotta redundanssi toimisi, tietokantaklusterien on koostuttava vähintään kolmesta palvelimesta, mutta enintään viidestä, ja maksimi edestakainen kiertoaika klusterin jäsenten välillä on 3 ms. Tämä raja on rajoittavampi kuin Call Bridge -klusterointi, joten se on usein rajoittava tekijä maantieteellisesti hajautetuissa käyttöönottoissa.

CMS:n tietokantaroolilla on useita ainutlaatuisia vaatimuksia. Toisin kuin muut roolit, se vaatii asiakas- ja palvelinvarmenteen, jossa asiakasvarmenteella on erityinen CN-kenttä, joka esitetään palvelimelle.

CMS käyttää postgres-tietokantaa, jossa on yksi master ja useita täysin identtisiä replikoita. On vain yksi ensisijainen tietokanta kerrallaan ("tietokantapalvelin"). Muut klusterin jäsenet ovat replikoita tai "tietokanta-asiakkaita".

Tietokantaklusteri vaatii erillisen palvelinvarmenteen ja asiakassertifikaatin. Ne on allekirjoitettava varmenteilla, yleensä sisäisellä yksityisellä varmentajalla. Koska mistä tahansa tietokantaklusterin jäsenestä voi tulla isäntä, tietokantapalvelimen ja asiakkaan varmenneparit (jotka sisältävät julkiset ja yksityiset avaimet) on kopioitava kaikille palvelimille, jotta ne voivat ottaa asiakkaan tai tietokantapalvelimen identiteetin. Lisäksi CA-juurivarmenne on ladattava, jotta asiakas- ja palvelinvarmenteet voidaan tarkistaa.

Joten luomme varmennepyynnön, jota käyttävät kaikki palvelinpalvelut paitsi tietokanta (tälle tulee erillinen pyyntö) komennolla, kuten:

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

CN:ssä kirjoitamme palvelimiemme yleiset nimet. Esimerkiksi, jos palvelimidemme isäntänimet server01, server02, server03, silloin CN on server.example.com

Teemme saman kahdella muulla palvelimella sillä erolla, että komennot sisältävät vastaavat "isäntänimet"

Luomme kaksi varmennepyyntöä, joita tietokantapalvelu käyttää komennoilla, kuten:

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

pki csr dbclusterclient CN:postgres

missä dbclusterserver и dbclusterclient pyyntöjemme ja tulevien todistustemme nimet, isäntänimi1(2)(3) vastaavien palvelimien nimet.

Suoritamme tämän toimenpiteen vain yhdellä palvelimella (!), ja lataamme varmenteet ja vastaavat .avaintiedostot muille palvelimille.

Ota asiakasvarmennetila käyttöön AD CS:ssä

Sinun on myös yhdistettävä kunkin palvelimen varmenteet yhdeksi tiedostoksi.*NIX:ssä:

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

Windows/DOS:ssa:

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

Ja lataa jokaiselle palvelimelle:
1. "Yksittäinen" palvelinvarmenne.
2. Juurisertifikaatti (yhdessä mahdollisten välitodistusten kanssa).
3. Tietokannan varmenteet ("palvelin" ja "asiakas") ja tiedostot .key-tunnisteella, jotka luotiin luotaessa "palvelin"- ja "asiakas"-tietokantavarmenteita koskevaa pyyntöä. Näiden tiedostojen on oltava samat kaikilla palvelimilla.
4. Kaikkien kolmen "yksittäisen" varmenteen tiedosto.

Tämän seurauksena sinun pitäisi saada jotain tämän kaltaista tiedostokuvaa jokaiselle palvelimelle.

Tietokantaklusteri

Nyt kun kaikki varmenteet on ladattu CMS-palvelimiin, voit määrittää ja ottaa käyttöön tietokantaklusteroinnin kolmen solmun välillä. Ensimmäinen vaihe on valita yksi palvelin tietokantaklusterin pääsolmuksi ja määrittää se kokonaan.

Päätietokanta

Ensimmäinen vaihe tietokannan replikoinnin määrittämisessä on määrittää tietokannassa käytettävät sertifikaatit. Tämä tehdään komennolla, kuten:

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

Kerrotaan nyt CMS:lle, mitä käyttöliittymää käytetään tietokannan klusterointiin komennolla:

database cluster localnode a

Sitten alustamme klusteritietokannan pääpalvelimella komennolla:

database cluster initialize

Asiakastietokantasolmut

Teemme saman menettelyn, vain komennon sijasta tietokantaklusterin alustus syötä komento kuten:

database cluster join <ip address existing master>

jossa ip-osoite CMS-palvelimen olemassa oleva pää-ip-osoite, johon klusteri alustettiin, yksinkertaisesti Master.

Tarkistamme kuinka tietokantaklusterimme toimii kaikilla palvelimilla komennolla:

database cluster status

Teemme saman jäljellä olevalla kolmannella palvelimella.

Tuloksena käy ilmi, että ensimmäinen palvelimemme on isäntä, loput ovat orjia.

Web Admin Service

Ota verkkojärjestelmänvalvojapalvelu käyttöön:

webadmin listen a 445

Portti 445 valittiin, koska porttia 443 käytetään käyttäjien pääsyyn verkkoasiakkaaseen

Määritämme Web Admin -palvelun sertifikaattitiedostoilla komennolla, kuten:

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

Ja ota Web Admin käyttöön komennolla:

webadmin enable

Jos kaikki on hyvin, saamme SUCCESS-rivejä, jotka osoittavat, että Web Admin on määritetty oikein verkkoa ja varmennetta varten. Tarkistamme palvelun toimivuuden verkkoselaimella ja annamme verkkovastaavan osoitteen, esim. cms.example.com: 445

Soita Bridge Clusteriin

Call Bridge on ainoa palvelu jokaisessa CMS-asennuksessa. Call Bridge on tärkein neuvottelumekanismi. Se tarjoaa myös SIP-rajapinnan, jotta puhelut voidaan reitittää siihen tai sieltä esimerkiksi Cisco Unified CM:n avulla.

Alla kuvatut komennot on suoritettava jokaisessa palvelimessa, jolla on asianmukaiset varmenteet.
Joten:

Yhdistämme varmenteet Call Bridge -palveluun komennolla, kuten:

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

Sidomme CallBridge-palvelut tarvitsemaamme käyttöliittymään komennolla:

callbridge listen a

Ja käynnistä palvelu uudelleen komennolla:

callbridge restart

Nyt kun puhelusillamme on määritetty, voimme määrittää Call Bridge -klusteroinnin. Call Bridge -klusterointi eroaa tietokanta- tai XMPP-klusterista. Call Bridge Cluster voi tukea 2–8 solmua ilman rajoituksia. Se tarjoaa redundanssin lisäksi myös kuormituksen tasapainotuksen, jotta neuvottelut voidaan aktiivisesti jakaa Call Bridge -palvelimien välillä älykkään puhelunjaon avulla. CMS:ssä on lisäominaisuuksia, Call Bridge -ryhmiä ja niihin liittyviä ominaisuuksia, joita voidaan käyttää jatkohallintaan.

Puhelun siltaklusterointi konfiguroidaan ensisijaisesti web-hallintaliittymän kautta
Alla kuvattu toimenpide on suoritettava jokaisessa klusterin palvelimessa.
Niin,

1. Siirry verkon kautta kohtaan Kokoonpano > Cluster.
2. Soita Bridgen identiteetti Anna yksilöiväksi nimeksi callbridge[01,02,03], joka vastaa palvelimen nimeä. Nämä nimet ovat mielivaltaisia, mutta niiden on oltava yksilöllisiä tälle klusterille. Ne ovat luonteeltaan kuvailevia, koska ne osoittavat, että ne ovat palvelintunnisteita [01,02,03].
3.B Klusteripuhelusillat syötä klusterin palvelimidemme verkkojärjestelmänvalvojan URL-osoitteet, cms[01,02,03].example.com:445 Osoite-kentässä. Muista määrittää portti. Voit jättää vertaislinkin SIP-verkkotunnuksen tyhjäksi.
4. Lisää jokaisen palvelimen CallBridge-luottamukseen varmenne, jonka tiedosto sisältää kaikki palvelintemme varmenteet, jotka olemme yhdistäneet tähän tiedostoon heti alussa komennolla kuten:

callbridge trust cluster <trusted cluster certificate bundle>

Ja käynnistä palvelu uudelleen komennolla:

callbridge restart

Tämän seurauksena jokaisella palvelimella sinun pitäisi saada tämä kuva:

XMPP-klusteri

CMS:n XMPP-palvelua käytetään kaiken Cisco Meeting Appsin (CMA) rekisteröinnin ja todentamisen käsittelemiseen, mukaan lukien CMA WebRTC -verkkoasiakas. Call Bridge itse toimii myös XMPP-asiakkaana todennustarkoituksiin, ja siksi se on määritettävä muiden asiakkaiden tapaan. XMPP-vikasietoisuus on ominaisuus, jota on tuettu tuotantoympäristöissä versiosta 2.1 lähtien

Alla kuvatut komennot on suoritettava jokaisessa palvelimessa, jolla on asianmukaiset varmenteet.
Joten:

Yhdistämme varmenteet XMPP-palveluun komennolla, kuten:

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

Määritä sitten kuunteluliittymä komennolla:

xmpp listen a

XMPP-palvelu vaatii yksilöllisen toimialueen. Tämä on käyttäjien kirjautuminen. Toisin sanoen, kun käyttäjä yrittää kirjautua sisään CMA-sovelluksella (tai WebRTC-asiakkaan kautta), hän kirjoittaa käyttäjätunnus@logindomain. Meidän tapauksessamme se on userid@conf.example.com. Miksei se ole vain esimerkki.com? Erityisessä käyttöönotossamme valitsimme Unified CM -verkkotunnuksemme, jota Jabber-käyttäjät käyttävät Unified CM:ssä esimerkkinä example.com, joten tarvitsimme eri toimialueen, jotta CMS-käyttäjät voivat reitittää puhelut CMS:ään ja sieltä SIP-verkkotunnusten kautta.

Määritä XMPP-toimialue komennolla, kuten:

xmpp domain <domain>

Ja ota XMPP-palvelu käyttöön komennolla:

xmpp enable

XMPP-palvelussa sinun on luotava tunnistetiedot jokaiselle Call Bridgelle, jota käytetään rekisteröityessäsi XMPP-palveluun. Nämä nimet ovat mielivaltaisia ​​(eivätkä liity yksilöllisiin nimiin, jotka määritit puhelusiltaklusterointia varten). Sinun on lisättävä kolme puhelusiltaa yhteen XMPP-palvelimeen ja syötettävä sitten nämä tunnistetiedot klusterin muihin XMPP-palvelimiin, koska tämä kokoonpano ei sovi klusterin tietokantaan. Myöhemmin määritämme jokaisen Call Bridgen käyttämään tätä nimeä ja salaisuutta XMPP-palveluun rekisteröitymiseen.

Nyt meidän on määritettävä XMPP-palvelu ensimmäisellä palvelimella kolmella Call Bridgellä callbridge01, callbridge02 ja callbridge03. Jokaiselle tilille annetaan satunnaiset salasanat. Ne syötetään myöhemmin muille Call Bridge -palvelimille tälle XMPP-palvelimelle kirjautumista varten. Anna seuraavat komennot:

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

Tämän seurauksena tarkistamme, mitä tapahtui komennolla:

xmpp callbridge list

Täsmälleen saman kuvan pitäisi näkyä muilla palvelimilla alla kuvattujen vaiheiden jälkeen.

Seuraavaksi lisäämme täsmälleen samat asetukset kahdelle muulle palvelimelle, vain komennoilla

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

Lisäämme Secretin erittäin huolellisesti, jotta siihen ei esimerkiksi jää ylimääräisiä välilyöntejä.


Tämän seurauksena jokaisella palvelimella pitäisi olla sama kuva:

Seuraavaksi klusterin kaikissa palvelimissa määritetään luotettavasti kaikki kolme varmennetta sisältävä tiedosto, joka on luotu aiemmin seuraavanlaisella komennolla:

xmpp cluster trust <trust bundle>

Otamme xmpp-klusteritilan käyttöön kaikissa klusteripalvelimissa komennolla:

xmpp cluster enable

Aloitamme klusterin ensimmäisellä palvelimella xmpp-klusterin luomisen komennolla:

xmpp cluster initialize

Muilla palvelimilla lisää klusteri xmpp:hen komennolla, kuten:

xmpp cluster join <ip address head xmpp server>

Tarkistamme jokaisella palvelimella XMPP-klusterin luomisen onnistumisen jokaiselle palvelimelle komennoilla:

xmpp status
xmpp cluster status

Ensimmäinen palvelin:

Toinen palvelin:

Kolmas palvelin:

Call Bridgen yhdistäminen XMPP:hen

Nyt kun XMPP-klusteri on käynnissä, sinun on määritettävä Call Bridge -palvelut muodostamaan yhteys XMPP-klusteriin. Tämä määritys tehdään web-järjestelmänvalvojan kautta.

Siirry kussakin palvelimessa kohtaan Kokoonpano > Yleiset ja kenttään Ainutlaatuinen Call Bridge -nimi kirjoittaa yksilöllisiä nimiä, jotka vastaavat palvelinta Call Bridge callbridge[01,02,03]... Kentällä Domain conf.example.ru ja vastaavat salasanat, voit vakoilla niitä
missä tahansa klusterin palvelimessa komennolla:

xmpp callbridge list

Jätä "Palvelin"-kenttä tyhjäksi Callbridge suorittaa DNS SRV -haun _xmpp-komponentti._tcp.conf.example.comlöytääksesi käytettävissä olevan XMPP-palvelimen. IP-osoitteet puhelusiltajen yhdistämiseksi XMPP:hen voivat vaihdella jokaisella palvelimella, se riippuu siitä, mitkä arvot palautetaan tietuepyyntöön _xmpp-komponentti._tcp.conf.example.com callbridge, joka puolestaan ​​riippuu tietyn DNS-tietueen prioriteettiasetuksista.

Siirry seuraavaksi kohtaan Tila > Yleiset ja tarkista, onko Call Bride -palvelu yhdistetty onnistuneesti XMPP-palveluun.

Web Bridge

Ota Web Bridge -palvelu käyttöön jokaisessa klusterin palvelimessa komennolla:

webbridge listen a:443

Määritämme Web Bridge -palvelun sertifikaattitiedostoilla komennolla, kuten:

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

Web Bridge tukee HTTPS:ää. Se ohjaa HTTP:n HTTPS:ään, jos se on määritetty käyttämään "http-uudelleenohjausta".
Ota HTTP-uudelleenohjaus käyttöön käyttämällä seuraavaa komentoa:

webbridge http-redirect enable

Kerro Call Bridgelle, että Web Bridge voi luottaa Call Bridgen yhteyksiin, käyttämällä komentoa:

webbridge trust <certfile>

jossa tämä on tiedosto, joka sisältää kaikki kolme varmennetta kustakin klusterin palvelimesta.

Tämän kuvan pitäisi olla jokaisella klusterin palvelimilla.


Nyt on luotava käyttäjä "appadmin"-roolilla, tarvitsemme sitä, jotta voimme konfiguroida klusterin (!), eikä jokaista klusterin palvelinta erikseen, jolloin asetukset vaikuttavat tasaisesti jokaiseen palvelimeen huolimatta tosiasia, että ne tehdään kerran.


Käytämme lisäasennuksiin Postinkantaja.

Valtuutusta varten valitse Valtuutus-osiossa Perus

Jotta komennot voidaan lähettää oikein CMS-palvelimelle, sinun on asetettava tarvittava koodaus

Määritämme Webbridgen komennolla POST parametrin kanssa url ja merkitys cms.example.com



Itse verkkosillassa ilmoitamme vaaditut parametrit: vieraskäyttö, suojattu pääsy jne.

Soita siltaryhmille

Oletusarvoisesti CMS ei aina käytä tehokkaimmin käytettävissään olevia neuvotteluresursseja.

Esimerkiksi kolmen osallistujan kokouksessa kukin osallistuja voi päätyä kolmelle eri puhelusillalle. Jotta nämä kolme osallistujaa voivat kommunikoida keskenään, Call Bridges muodostaa automaattisesti yhteydet kaikkien palvelimien ja asiakkaiden välillä samassa tilassa, jolloin kaikki näyttää siltä, ​​​​että kaikki asiakkaat olisivat samalla palvelimella. Valitettavasti tämän haittapuolena on, että yksi 3 hengen konferenssi kuluttaa nyt 9 mediaporttia. Tämä on selvästikin tehotonta resurssien käyttöä. Lisäksi, kun Call Bridge on todella ylikuormitettu, oletusmekanismi on jatkaa puhelujen hyväksymistä ja tarjota heikompaa palvelua kaikille kyseisen Call Bridgen tilaajille.

Nämä ongelmat ratkaistaan ​​Call Bridge Group -ominaisuuden avulla. Tämä ominaisuus esiteltiin Cisco Meeting Server -ohjelmiston versiossa 2.1, ja sitä on laajennettu tukemaan sekä saapuvien että lähtevien Cisco Meeting App (CMA) -puheluiden kuormitusta, mukaan lukien WebRTC-osallistujat.

Uudelleenkytkentäongelman ratkaisemiseksi kullekin Call Bridgelle on otettu käyttöön kolme konfiguroitavaa kuormitusrajaa:

LoadLimit — tämä on tietyn Call Bridgen suurin numeerinen kuormitus. Jokaisella alustalla on suositeltu kuormitusraja, kuten 96000 CMS1000:lle ja 1.25 GHz vCPU:ta kohti virtuaalikoneen. Eri puhelut kuluttavat tietyn määrän resursseja osallistujan resoluutiosta ja kuvanopeudesta riippuen.
NewConferenceLoadLimitBasisPoints (oletusarvo 50 % loadLimit) - asettaa palvelimen kuormitusrajan, jonka jälkeen uudet neuvottelut hylätään.
ExistingConferenceLoadLimitBasisPoints (oletusarvo 80 % loadLimitistä) – palvelimen kuormitusarvo, jonka jälkeen olemassa olevaan konferenssiin liittyvät osallistujat hylätään.

Vaikka tämä ominaisuus on suunniteltu puheluiden jakamiseen ja kuormituksen tasapainottamiseen, muita ryhmiä, kuten TURN-palvelimet, Web Bridge -palvelimet ja -tallentimet, voidaan myös määrittää Call Bridge -ryhmiin, jotta ne voidaan myös ryhmitellä oikein optimaalista käyttöä varten. Jos jotakin näistä objekteista ei ole määritetty puheluryhmään, niiden oletetaan olevan kaikkien palvelimien käytettävissä ilman erityistä prioriteettia.

Nämä parametrit määritetään täällä: cms.example.com:445/api/v1/system/configuration/cluster

Seuraavaksi ilmoitamme kullekin puhelusillalle, mihin puhelusiltaryhmään se kuuluu:

Ensimmäinen puhelusilta

Toinen puhelusilta

Kolmas puhelusilta


Näin ollen määritimme Call Brdige -ryhmän käyttämään tehokkaammin Cisco Meeting Server -klusterin resursseja.

Käyttäjien tuonti Active Directorysta

Web Admin -palvelussa on LDAP-määritysosio, mutta se ei tarjoa monimutkaisia ​​määritysvaihtoehtoja, eikä tietoja tallenneta klusterin tietokantaan, joten konfigurointi on tehtävä joko manuaalisesti jokaisessa palvelimessa verkkoliittymän kautta tai API, ja jotta "kolme kertaa "Älä nouse", asetamme tiedot edelleen API:n kautta.

Käytä URL-osoitetta pääsyyn cms01.example.com:445/api/v1/ldapServers luo LDAP-palvelinobjektin ja määrittelee parametrit, kuten:

• Palvelimen IP
• porttinumero
• Käyttäjätunnus
• salasana
• turvallinen

Suojattu - valitse tosi tai epätosi portin mukaan, 389 - ei suojattu, 636 - suojattu.


LDAP-lähdeparametrien yhdistäminen Cisco Meeting Serverin attribuutteihin.
LDAP-kartoitus kartoittaa LDAP-hakemiston attribuutit CMS:n attribuutteihin. Varsinaiset attribuutit:

• jidMapping
• nimikartoitus
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Attribuuttien kuvausJID edustaa käyttäjän kirjautumistunnusta CMS:ssä. Koska tämä on Microsoft Active Directoryn LDAP-palvelin, CMS JID yhdistää LDAP:n sAMAccountNameen, joka on pohjimmiltaan käyttäjän Active Directory -kirjautumistunnus. Huomaa myös, että otat sAMAccountName-tunnuksen ja lisäät sen loppuun verkkotunnuksen conf.pod6.cms.lab, koska käyttäjäsi käyttävät tätä kirjautumistunnusta CMS:ään kirjautuessaan.

nimikartoitus vastaa Active Directory displayName -kentän sisältöä käyttäjän CMS-nimikenttään.

coSpaceNameMapping luo CMS-tilan nimen displayName-kentän perusteella. Tämä määrite yhdessä coSpaceUriMapping-attribuutin kanssa on se, mitä tarvitaan tilan luomiseen kullekin käyttäjälle.

coSpaceUriMapping määrittää URI:n käyttäjäosan, joka liittyy käyttäjän henkilökohtaiseen tilaan. Jotkut toimialueet voidaan määrittää soitettavaksi avaruuteen. Jos käyttäjäosa vastaa tätä kenttää jollekin näistä toimialueista, puhelu ohjataan kyseisen käyttäjän tilaan.

coSpaceSecondaryUriMapping määrittää toisen URI:n avaruuden saavuttamiseksi. Tätä voidaan käyttää numeerisen aliaksen lisäämiseen puheluiden reitittämiseksi tuodun käyttäjän tilaan vaihtoehtona coSpaceUriMapping-parametrissa määritetylle aakkosnumeeriselle URI:lle.

LDAP-palvelin ja LDAP-kartoitus on määritetty. Nyt sinun on linkitettävä ne yhteen luomalla LDAP-lähde.

Käytä URL-osoitetta pääsyyn cms01.example.com:445/api/v1/ldapSource luo LDAP-lähdeobjektin ja määritä parametrit, kuten:

• palvelin
• kartoitus
• baseDn
• suodattaa

Nyt kun LDAP-määritys on valmis, voit suorittaa manuaalisen synkronoinnin.

Teemme tämän joko kunkin palvelimen verkkoliittymässä napsauttamalla Synkronoi nyt Luvussa Active Directory


tai API:n kautta komennolla POST käyttämällä URL-osoitetta pääsyyn cms01.example.com:445/api/v1/ldapSyncs

Ad-hoc-konferenssit

Mikä tämä on?Perinteisessä käsitteessä neuvottelu tarkoittaa sitä, että kaksi osallistujaa keskustelee keskenään ja toinen osallistujista (käyttäen Unified CM:ään rekisteröityä laitetta) painaa "Neuvottelu"-painiketta, soittaa toiselle henkilölle ja keskusteltuaan kolmannen osapuolen kanssa. , paina "Konferenssi"-painiketta uudelleen liittyäksesi kaikkiin osallistujiin kolmikantakonferenssiin.

Ad-hoc-konferenssin eroaa CMS:n ajoitetusta konferenssista se, että Ad-hoc-konferenssi ei ole vain SIP-puhelu CMS:lle. Kun neuvottelun aloittaja napsauttaa Neuvottelu-painiketta toisen kerran kutsuakseen kaikki samaan kokoukseen, Unified CM:n on soitettava API-puhelu CMS:lle luodakseen lennossa neuvottelun, johon kaikki puhelut sitten siirretään. Kaikki tämä tapahtuu osallistujien huomaamatta.

Tämä tarkoittaa, että Unified CM:n on määritettävä palvelun API-tunnistetiedot ja WebAdmin-osoite/portti sekä SIP-runko suoraan CMS-palvelimelle puhelun jatkamiseksi.

Tarvittaessa CUCM voi luoda dynaamisesti tilan CMS:ään, jotta jokainen puhelu pääsee CMS:ään ja vastaa tiloihin tarkoitettua saapuvan puhelun sääntöä.

Integrointi CUCM:n kanssa konfiguroitu samalla tavalla kuin artikkelissa on kuvattu aikaisemmin paitsi että Cisco UCM:ssä sinun on luotava kolme runkoa CMS:lle, kolme konferenssisiltaa, määritettävä SIP-suojausprofiilissa kolme aihenimeä, reittiryhmät, reittiluettelot, mediaresurssiryhmät ja mediaresurssiryhmäluettelot ja lisättävä muutama reitityssääntö. Cisco Meeting Serveriin.

SIP-suojausprofiili:


Rungot:


Jokainen runko näyttää samalta:




Konferenssisilta


Jokainen konferenssisilta näyttää samalta:


Reittiryhmä


Reittiluettelo


Mediaresurssiryhmä


Mediaresurssiryhmäluettelo

Puhelusäännöt

Toisin kuin kehittyneemmät puhelunhallintajärjestelmät, kuten Unified CM tai Expressway, CMS hakee uusia puheluita varten vain toimialueen SIP Request-URI -kentästä. Joten jos SIP INVITE on siemaukselle: [sähköposti suojattu]CMS välittää vain domain.comista. CMS noudattaa näitä sääntöjä määrittääkseen minne puhelu reititetään:

1. CMS yrittää ensin sovittaa SIP-toimialueen saapuvan puhelun säännöissä määritettyihin toimialueisiin. Nämä puhelut voidaan sitten reitittää ("kohdistettuihin") tiloihin tai tietyille käyttäjille, sisäisille IVR:ille tai suoraan integroituihin Microsoft Lync/Skype for Business (S4B) -kohteisiin.
2. Jos saapuvan puhelun säännöt eivät täsmää, CMS yrittää täsmäyttää soitonsiirtotaulukossa määritettyä toimialuetta. Jos osuma syntyy, sääntö voi nimenomaisesti hylätä puhelun tai siirtää puhelun. Tällä hetkellä sisällönhallintajärjestelmä voi kirjoittaa toimialueen uudelleen, mikä on joskus hyödyllistä Lync-toimialueille kutsumisessa. Voit myös valita heittoheiton, mikä tarkoittaa, että mitään kenttiä ei enää muokata, tai käyttää sisäistä CMS-valintasuunnitelmaa. Jos soitonsiirtosäännöt eivät täsmää, oletusarvoisesti puhelu hylätään. Muista, että CMS:ssä, vaikka puhelu on "välitetty", media on silti sidottu CMS:ään, mikä tarkoittaa, että se on merkinanto- ja medialiikenteen polulla.
Tällöin vain siirretyt puhelut ovat lähtevien puhelujen sääntöjen alaisia. Nämä asetukset määrittävät kohteet, joihin puhelut lähetetään, runkotyypin (onko kyseessä uusi Lync-puhelu tai tavallinen SIP-puhelu) ja mahdolliset muunnokset, jotka voidaan suorittaa, jos siirtoa ei ole valittu soitonsiirtosäännössä.

Tässä on todellinen loki siitä, mitä ad-hoc-konferenssin aikana tapahtuu

Kuvakaappaus näyttää sen huonosti (en tiedä kuinka parantaa sitä), joten kirjoitan lokiin näin:

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

Itse Ad-hoc-konferenssi:


Saapuvien puhelujen säännöt
Saapuvien puhelujen parametrien konfigurointi on välttämätöntä, jotta puhelu voidaan vastaanottaa CMS:ssä. Kuten näit LDAP-asetuksissa, kaikki käyttäjät tuotiin verkkotunnuksella conf.pod6.cms.lab. Joten ainakin haluat puhelut tähän verkkotunnukseen kohdistaaksesi välilyöntejä. Sinun on myös määritettävä säännöt kaikelle, joka on tarkoitettu kunkin CMS-palvelimen täydelliselle verkkotunnukselle (ja ehkä jopa IP-osoitteelle). Ulkoinen puhelunhallintamme, Unified CM, määrittää SIP-rungot, jotka on omistettu kullekin CMS-palvelimelle erikseen. Riippuen siitä, onko näiden SIP-runkojen kohde IP-osoite vai palvelimen FQDN, määrittää, pitääkö CMS määrittää hyväksymään sen IP-osoitteeseen tai FQDN-osoitteeseen ohjatut puhelut.

Verkkotunnusta, jolla on korkeimman prioriteetin saapuvan liikenteen sääntö, käytetään kaikkien käyttäjätilojen toimialueena. Kun käyttäjät synkronoivat LDAP:n kautta, CMS luo automaattisesti välilyöntejä, mutta vain URI:n käyttäjäosan (coSpaceUriMapping), esimerkiksi user.space. Osa verkkotunnuksen Täysi URI luodaan tämän säännön perusteella. Itse asiassa, jos kirjautuisit Web Bridgeen tässä vaiheessa, näkisit, että Space URI:llä ei ole toimialuetta. Asettamalla tämän säännön korkeimmaksi prioriteetiksi määrität luotujen tilojen toimialueen konf.esimerkki.fi.


Lähtevän puhelun säännöt

Jotta käyttäjät voivat soittaa lähteviä puheluita yhdistettyyn CM-klusteriin, sinun on määritettävä lähtevät säännöt. Unified CM:ään rekisteröityjen päätepisteiden toimialue, kuten Jabber, on example.com. Tämän toimialueen puhelut tulee reitittää vakio-SIP-puheluina Unified CM -puhelunkäsittelysolmuihin. Pääpalvelin on cucm-01.example.com ja lisäpalvelin on cucm-02.example.com.

Ensimmäinen sääntö kuvaa yksinkertaisinta puhelujen reititystä klusteripalvelimien välillä.

Kenttä Paikallinen verkkotunnuksesta on vastuussa siitä, mitä näkyy soittajan SIP-URI:ssa soitetulle henkilölle @-symbolin jälkeen. Jos jätämme sen tyhjäksi, niin @-symbolin jälkeen tulee CUCM:n IP-osoite, jonka kautta tämä puhelu kulkee. Jos määritämme verkkotunnuksen, @-symbolin jälkeen tulee itse asiassa verkkotunnus. Tämä on välttämätöntä, jotta voidaan soittaa takaisin, muuten ei ole mahdollista soittaa takaisin SIP-URI:n nimi@ip-osoite kautta.

Soita kun ilmoitetaan Paikallinen verkkotunnuksesta


Soita milloin EI ilmoitettu Paikallinen verkkotunnuksesta


Muista määrittää lähteville puheluille nimenomaan Salattu tai Salaamaton, koska mikään ei toimi Auto-parametrin kanssa.

Äänite

Tallennuspalvelin tallentaa videoneuvottelut. Tallennin on täsmälleen sama kuin Cisco Meeting Server. Tallennin ei vaadi minkään lisenssin asentamista. CallBridge-palveluita käyttäville palvelimille vaaditaan tallennuslisenssit, ts. Tallennuslisenssi vaaditaan, ja sitä on sovellettava CallBridge-komponenttiin, ei palvelimeen, jossa on tallennin. Tallennin toimii XMPP (Extensible Messaging and Presence Protocol) -asiakkaana, joten XMPP-palvelin on otettava käyttöön CallBridge-palvelimella.

Koska Meillä on klusteri ja lisenssi on "venytettävä" kaikkien kolmen klusterin palvelimen kesken. Sitten yksinkertaisesti henkilökohtaisella tililläsi lisensseihin yhdistämme (lisäämme) kaikkien klusteriin kuuluvien CMS-palvelimien a-rajapintojen MAC-osoitteet.

Ja tämä on kuva, jonka pitäisi olla jokaisella klusterin palvelimilla

Yleensä Recorderin sijoittamiseen on useita skenaarioita, mutta pysymme tässä:


Ennen kuin määrität tallentimen, sinun on valmisteltava paikka, jossa videoneuvottelut todella tallennetaan. Itse asiassa täällä linkki, kuinka kaikki tallenteet asetetaan. Keskityn tärkeisiin kohtiin ja yksityiskohtiin:

1. On parempi pudottaa varmenne klusterin ensimmäiseltä palvelimelta.
2. "Recorder unavailable" -virhe saattaa ilmetä, koska Recorder Trustissa on määritetty väärä varmenne.
3. Kirjoittaminen ei välttämättä toimi, jos tallennukseen määritetty NFS-hakemisto ei ole juurihakemisto.

Joskus on tarpeen tallentaa automaattisesti yhden tietyn käyttäjän tai tilan neuvottelu.

Tätä varten luodaan kaksi puheluprofiilia:
Tallennus pois päältä


Ja automaattinen tallennustoiminto


Seuraavaksi "liitetään" CallProfile automaattisella tallennustoiminnolla haluttuun tilaan.


CMS:ssä on niin vakiintunut, että jos CallProfile on nimenomaisesti sidottu mihin tahansa tilaan tai tilaan, tämä puheluprofiili toimii vain suhteessa näihin tiettyihin tiloihin. Ja jos puheluprofiilia ei ole sidottu mihinkään välilyöntiin, sitä sovelletaan oletusarvoisesti niihin tiloihin, joihin ei ole erikseen sidottu CallProfilea.

Seuraavalla kerralla yritän kuvailla, kuinka CMS:ää käytetään organisaation sisäisen verkon ulkopuolella.

Lähteet:

• 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-ja myöhemmin. pdf

Lähde: will.com