An dësem Ausgab wäert ech e puer vun de Schwieregkeete weisen an erkläre fir en CMS Server am Failover Cluster Modus opzestellen.
TheorieAm Allgemengen ginn et dräi Aarte vu CMS Server Deployment:
- Single kombinéiert(Single kombinéiert), d.h. Dëst ass ee Server op deem all déi néideg Servicer lafen. An deene meeschte Fäll ass dës Aart vun Détachement nëmme gëeegent fir den internen Client Zougang an a méi klengen Ëmfeld, wou d'Skalierbarkeet an d'Redundanzbeschränkungen vun engem eenzege Server net e kriteschen Thema sinn, oder a Situatiounen wou d'CMS nëmme bestëmmte Funktiounen ausféiert, sou wéi ad hoc Konferenzen op Cisco UCM.
Approximate Schema vun der Aarbecht:
- eenzel opzedeelen(Single Split) erweidert de fréiere Deploymenttyp andeems en separaten Server fir externen Zougang derbäigesat gëtt. Bei legacy Deploymenten huet dëst gemengt en CMS Server an engem demilitariséierten Netzwierksegment (DMZ) z'installéieren, wou extern Clienten Zougang kënnen hunn, an een CMS Server am Netzkär, wou intern Clienten Zougang zum CMS kréien. Dëse speziellen Deploymentmodell gëtt elo vum sougenannten Typ ersat Single Edge, déi aus Serveren besteet Cisco Expressway, déi entweder vill vun deene selwechte Firewall Bypass-Fähigkeiten hunn oder wäerten hunn, sou datt d'Clienten keen dedizéierten Edge CMS-Server brauchen.
Approximate Schema vun der Aarbecht:
- Skalierbar a elastesch(Skalierbar a Feelertolerant) Dësen Typ enthält Redundanz fir all Komponent, wat de System erlaabt mat Äre Bedierfnesser op seng maximal Kapazitéit ze wuessen wärend Redundanz am Fall vun engem Echec ubitt. Et benotzt och d'Single Edge Konzept fir sécheren externen Zougang ze bidden. Dëst ass den Typ dee mir an dësem Episod kucken. Wa mir verstinn wéi dës Zort vu Cluster z'installéieren, wäerte mir net nëmmen aner Aarte vun Deployementer verstoen, awer mir kënnen och verstoen wéi CMS-Server Cluster kreéieren fir potenziell Wuesstum an der Nofro z'empfänken.
Ier Dir op d'Deployment weidergeet, musst Dir e puer grondleeënd Saache verstoen, nämlech
Main CMS Software Komponenten:
- Datebank: Erlaabt Iech e puer Konfiguratiounen ze kombinéieren, wéi zB Dialplang, Benotzerplazen a Benotzer selwer. Ënnerstëtzt Clustering fir héich Disponibilitéit (Single Master) nëmmen.
- Call Bréck: e Service fir Audio- a Videokonferenzen, dee voll Kontroll iwwer d'Gestioun an d'Veraarbechtung vun Uriff a Multimediaprozesser ubitt. Ënnerstëtzt Clustering fir héich Disponibilitéit a Skalierbarkeet.
- XMPP Server: verantwortlech fir d'Aschreiwung an d'Authentifikatioun vu Cliente mat der Cisco Meeting Applikatioun an/oder WebRTC(Echtzäit Kommunikatioun, oder einfach am Browser), souwéi Intercomponent Signalisatioun. Kann nëmme fir héich Disponibilitéit clusteréiert ginn.
- Web Bréck: Bitt Client Zougang zu WebRTC.
- Loadbalancer: Bitt en eenzege Verbindungspunkt fir Cisco Meeting Apps am Single Split Modus. Lauschtert op den externen Interface an den Hafen fir erakommen Verbindungen. Gläich akzeptéiert de Lastbalancer erakommende TLS Verbindunge vum XMPP Server, duerch deen et TCP Verbindunge vun externe Clienten wiessele kann.
An eisem Szenario wäert et net gebraucht ginn. - TURN Server: Bitt Firewall Contournement Technologie déi erlaabt
Plaz eis CMS hannert enger Firewall oder NAT fir extern Clientë mat Cisco Meeting App oder SIP-Geräter ze verbannen. An eisem Szenario wäert et net gebraucht ginn. - Web Admin: Administrativ Interface an API Zougang, och fir speziell Unified CM Konferenzen.
Konfiguratiounsmodi
Am Géigesaz zu de meescht aner Cisco Produkter ënnerstëtzt Cisco Meeting Server dräi Konfiguratiounsmethoden fir all Typ vun Deployment z'empfänken.
- Kommandozeil (CLI): Kommando Linn Interface bekannt als MMP fir initial Configuratioun an Zertifikat Aufgaben.
- Web Administrateur: Haaptsächlech fir CallBridge-Zesummenhang Konfiguratiounen, besonnesch wann Dir en eenzegen net-clusteréierte Server opstellt.
- Rescht API: Benotzt fir déi komplexst Konfiguratiounsaufgaben a clustered Datebank-relatéiert Aufgaben.
Zousätzlech zu der uewendriwwer gëtt de Protokoll benotzt SFTP fir Dateien ze transferéieren - normalerweis Lizenzen, Certificaten oder Logbicher - op a vum CMS Server.
An Détachement Guiden aus Cisco ass et op wäiss an Englesch geschriwwen datt de Cluster muss ofgesat ginn op d'mannst dräi Serveren (Noden) am Kontext vun Datenbanken. Well Nëmme mat enger komescher Zuel vu Wirbelen funktionnéiert de Mechanismus fir en neien Datebank Master ze wielen, an allgemeng huet den Datebank Master eng Verbindung mat de meeschte vun der CMS Server Datebank.
A wéi d'Praxis weist, sinn zwee Server (Noden) wierklech net ganz genuch. De Selektiounsmechanismus funktionnéiert wann de Master nei gestart gëtt, de Sklave Server gëtt Master nëmmen nodeems de nei gestarte Server opgeriicht ass. Wéi och ëmmer, wann an engem Cluster vun zwee Serveren de Master-Server op eemol erausgeet, da gëtt de Sklave-Server net de Master, a wann de Sklave erausgeet, da gëtt de verbleiwen Master-Server de Sklave.
Awer am Kontext vun XMPP wier et wierklech néideg fir e Cluster vun dräi Serveren ze sammelen, well wann Dir zum Beispill den XMPP Service op engem vun de Serveren auszeschalten an deenen XMMP am Leader Status ass, da bleift XMPP op de verbleiwen Server am Follower Status an CallBridge Verbindunge mat XMPP falen aus, well CallBridge verbënnt exklusiv mat XMPP mam Leader Status. An dat ass kritesch, well ... keen eenzegen Uruff wäert duerchgoen.
Och am selwechten Deployment Guiden gëtt e Cluster mat engem XMPP Server demonstréiert.
A wann Dir déi uewe berécksiichtegt, gëtt et kloer firwat: et funktionnéiert well et am failover-Modus ass.
An eisem Fall wäert den XMPP Server op all dräi Wirbelen präsent sinn.
Et gëtt ugeholl datt all dräi vun eise Serveren op sinn.
DNS records
Ier Dir ufänkt Serveren opzestellen, musst Dir DNS-Records erstellen А и SRV Typen:
Notéiert w.e.g. datt an eisen DNS records zwee Domainen example.com an conf.example.com. Beispill.com ass en Domain dat all Cisco Unified Communication Manager Abonnente fir hir URIs benotze kënnen, déi héchstwahrscheinlech an Ärer Infrastruktur präsent ass oder wahrscheinlech präsent ass. Oder example.com entsprécht dem selwechten Domain dat d'Benotzer fir hir E-Mailadressen benotzen. Oder de Jabber Client op Ärem Laptop kann en URI hunn [Email geschützt]. Domain conf.example.com ass den Domain dee fir Cisco Meeting Server Benotzer konfiguréiert gëtt. D'Domain vum Cisco Meeting Server wäert sinn conf.example.com, also fir dee selwechte Jabber Benotzer muss de Benotzer@ URI benotzt ginn fir op Cisco Meeting Server ze loggenconf.example.com.
Basis Configuratioun
All Astellungen hei ënnendrënner beschriwwe ginn op engem Server ugewisen, awer se mussen op all Server am Cluster gemaach ginn.
QoS
Zënter dem CMS generéiert Echtzäit Traffic sensibel fir Verspéidungen a Paketverloscht, am meeschte Fäll ass et recommandéiert Qualitéit vum Service (QoS) ze konfiguréieren. Fir dëst z'erreechen, ënnerstëtzt d'CMS Tagging Pakete mat den Differentiated Services Codes (DSCPs) déi se generéiert. Obwuel DSCP-baséiert Traffic Prioritéit hänkt dovun of wéi de Verkéier vun den Netzwierkkomponenten vun Ärer Infrastruktur veraarbecht gëtt, an eisem Fall konfiguréiere mir eis CMS mat typescher DSCP Prioritéit baséiert op QoS Best Practices.
Op all Server wäerte mir dës Kommandoen aginn
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1ASou war all Video Verkéier markéiert AF41 (DSCP 0x22), all Stëmm Verkéier war EF markéiert (DSCP 0x2E), aner Zorte vun niddereg latency Traffic wéi SIP an XMPP benotzen AF31 (DSCP 0x1A).
Mir iwwerpréiwen:
NTP
Network Time Protocol (NTP) ass wichteg net nëmme fir präzis Zäitstempel vun Uriff a Konferenzen ze liwweren, awer och fir Zertifikater z'iwwerpréiwen.
Füügt NTP-Server op Är Infrastruktur mat engem Kommando wéi
ntp server add <server>
An eisem Fall ginn et zwee esou Serveren, also wäerten et zwou Équipen sinn.
Mir iwwerpréiwen:
A setzen d'Zäitzone fir eise Server
DNS
Mir addéieren DNS-Server an den CMS mat engem Kommando wéi:
dns add forwardzone <domain-name> <server ip>
An eisem Fall ginn et zwee esou Serveren, also wäerten et zwou Équipen sinn.
Mir iwwerpréiwen:
Network Interface Configuratioun
Mir konfiguréieren den Interface mat engem Kommando wéi:
ipv4 <interface> add <address>/<prefix length> <gateway>
Mir iwwerpréiwen:
Servernumm (Hostnumm)
Mir setzen de Servernumm mat engem Kommando wéi:
hostname <name>
A mir restarten.
Dëst fäerdeg d'Basiskonfiguratioun.
Zertifikaten
TheorieCisco Meeting Server verlaangt verschlësselte Kommunikatioun tëscht verschiddene Komponente, an als Resultat, sinn X.509 Certificaten fir all CMS Détachement néideg. Si hëllefen sécherzestellen datt d'Servicer / Server vun anere Serveren / Servicer vertraut ginn.
All Service erfuerdert e Certificat, awer separat Certificaten fir all Service erstellen kann zu Duercherneen an onnéideg Komplexitéit féieren. Glécklech kënne mir den ëffentlech-private Schlësselpaar vun engem Zertifika generéieren an se dann iwwer verschidde Servicer weiderbenotzen. An eisem Fall gëtt dee selwechte Zertifika fir Call Bridge, XMPP Server, Web Bridge a Web Admin benotzt. Also musst Dir e Paar vun ëffentlechen a privaten Zertifikatschlësselen fir all Server am Cluster erstellen.
Datebankclustering huet awer e puer speziell Zertifika Ufuerderunge a erfuerdert dofir seng eege Certificaten déi anescht sinn wéi déi vun den anere Servicer. CMS benotzt e Serverzertifika, deen ähnlech ass wéi d'Zertifikater, déi vun anere Servere benotzt ginn, awer et gëtt och e Clientzertifika fir Datebankverbindungen. Datebankzertifikater gi souwuel fir Authentifikatioun wéi och Verschlësselung benotzt. Amplaz e Benotzernumm a Passwuert fir de Client ze bidden fir mat der Datebank ze verbannen, stellt et e Client Zertifikat dat vum Server vertraut gëtt. All Server am Datebankcluster wäert datselwecht ëffentlecht a private Schlësselpaar benotzen. Dëst erlaabt all Serveren am Stärekoup Daten op esou eng Manéier ze verschlësselen datt se nëmme vun anere Serveren entschlësselt kënne ginn, déi och datselwecht Schlësselpaar deelen.
Fir Redundanz ze schaffen, mussen d'Datebankcluster aus engem Minimum vun 3 Serveren bestoen, awer net méi wéi 5, mat enger maximaler Ronn-Reeszäit vun 200 ms tëscht all Clustermemberen. Dës Limit ass méi restriktiv wéi fir Call Bridge Clustering, sou datt et dacks de limitéierende Faktor bei geographesch verdeelt Deployementer ass.
D'Datebankroll fir e CMS huet eng Rei eenzegaarteg Ufuerderungen. Am Géigesaz zu anere Rollen erfuerdert et e Client a Server Zertifikat, wou de Client Zertifikat e spezifescht CN Feld huet dat dem Server presentéiert gëtt.
De CMS benotzt eng Postgres Datebank mat engem Master a verschidde komplett identesch Repliken. Et gëtt nëmmen eng primär Datebank gläichzäiteg (den "Datebankserver"). Déi verbleiwen Membere vum Cluster sinn Repliken oder "Datebankclienten".
En Datebankcluster erfuerdert en dedizéierten Serverzertifika an e Clientzertifika. Si musse vun Zertifikater ënnerschriwwe ginn, normalerweis eng intern privat Zertifika Autoritéit. Well all Member vum Datebankcluster de Meeschter ka ginn, mussen d'Datebankserver a Client Zertifikatpaaren (déi ëffentlech a privat Schlësselen enthalen) op all Server kopéiert ginn, sou datt se d'Identitéit vum Client oder Datebankserver kënnen iwwerhuelen. Zousätzlech muss de CA Root Zertifikat gelueden ginn fir sécherzestellen datt de Client a Server Zertifikater verifizéiert kënne ginn.
Also, mir erstellen eng Ufro fir en Zertifika deen vun all Serverservicer ausser der Datebank benotzt gëtt (et gëtt eng separat Ufro dofir) mat engem Kommando wéi:
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
Am CN schreiwen mir den allgemengen Numm vun eise Serveren. Zum Beispill, wann d'Hostnimm vun eise Serveren Server01, Server02, Server03, da wäert CN sinn server.example.com
Mir maachen datselwecht op de verbleiwen zwee Serveren mam Ënnerscheed datt d'Befehle déi entspriechend "Hostnamen" enthalen
Mir generéieren zwou Ufroe fir Certificaten déi vum Datebankservice benotzt ginn mat Kommandoen wéi:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgreswou dbclusterserver и dbclusterclient Nimm vun eisen Ufroen an zukünfteg Certificaten, Hostnumm1(2)(3) Nimm vun den entspriechende Serveren.
Mir maachen dës Prozedur nëmmen op engem Server (!), A mir lueden d'Zertifikater an déi entspriechend .key Dateien op aner Serveren erop.
Aktivéiert Client Zertifikat Modus an AD CS
Dir musst och d'Zertifikater fir all Server an eng Datei fusionéieren.Op *NIX:
cat server01.cer server02.cer server03.cer > server.cerOp Windows/DOS:
copy server01.cer + server02.cer + server03.cer server.cer
A lued op all Server erop:
1. "Individuell" Server Zertifikat.
2. Root Zertifikat (zesumme mat Mëttelstuf, wann all).
3. Certificaten fir d'Datebank ("Server" an "Client") a Fichieren mat der .key Extensioun, déi generéiert goufen, wann eng Ufro fir d'"Server" an "Client" Datebank Certificaten. Dës Dateie mussen op all Server d'selwecht sinn.
4. Fichier vun all dräi "individuell" Certificaten.
Als Resultat sollt Dir eppes wéi dëst Dateibild op all Server kréien.
Datebank Cluster
Elo datt Dir all d'Zertifikater op d'CMS Server eropgelueden hutt, kënnt Dir d'Datebankclusterung tëscht den dräi Noden konfiguréieren an aktivéieren. Den éischte Schrëtt ass e Server als Master Node vum Datebankcluster ze wielen an et komplett ze konfiguréieren.
Master Datebank
Den éischte Schrëtt fir d'Datebankreplikatioun opzestellen ass d'Zertifikater ze spezifizéieren déi fir d'Datebank benotzt ginn. Dëst gëtt mat engem Kommando gemaach wéi:
database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>Loosst eis elo dem CMS soen wéi eng Interface fir Datebankclustering mam Kommando ze benotzen:
database cluster localnode aDa initialiséieren mir d'Cluster-Datebank um Haaptserver mam Kommando:
database cluster initialize
Client Datebank Noden
Mir maachen déi selwecht Prozedur, nëmmen amplaz vum Kommando Datebank Cluster initialiséieren gitt e Kommando wéi:
database cluster join <ip address existing master>wou IP Adress bestehend Master IP Adress vum CMS Server op deem de Stärekoup initialiséiert gouf, einfach Master.
Mir kontrolléieren wéi eisen Datebankcluster op all Server funktionnéiert mam Kommando:
database cluster status
Mir maachen déi selwecht op de Rescht drëtt Server.
Als Resultat stellt et sech eraus datt eisen éischte Server de Master ass, de Rescht sinn Sklaven.
Web Admin Service
Aktivéiert de Web Administrator Service:
webadmin listen a 445Port 445 gouf gewielt well Port 443 fir Benotzer Zougang zum Web Client benotzt gëtt
Mir konfiguréieren de Web Admin Service mat Zertifikatdateien mat engem Kommando wéi:
webadmin certs <keyfile> <certificatefile> <ca bundle>An aktivéiert Web Admin mam Kommando:
webadmin enable
Wann alles gutt ass, kréie mir SUCCESS Linnen, déi uginn datt de Web Admin korrekt fir d'Netz an Zertifikat konfiguréiert ass. Mir kontrolléieren d'Funktionalitéit vum Service mat engem Webbrowser a gitt d'Adress vum Webadministrator, zum Beispill: : 445
Call Bréck Cluster
Call Bridge ass deen eenzegen Service deen an all CMS Deployment präsent ass. Call Bridge ass den Haaptkonferenzmechanismus. Et stellt och eng SIP Interface sou datt Uriff kann op oder vun et duerch, Zum Beispill, engem Cisco Unified CM geréckelt ginn.
D'Befehle, déi hei ënnen beschriwwe ginn, mussen op all Server mat de passenden Certificaten ausgefouert ginn.
Also:
Mir associéieren Certificaten mam Call Bridge Service mat engem Kommando wéi:
callbridge certs <keyfile> <certificatefile>[<cert-bundle>]Mir binden CallBridge Servicer un d'Interface déi mir brauchen mam Kommando:
callbridge listen aA restart de Service mam Kommando:
callbridge restart
Elo datt mir eis Call Bridges konfiguréiert hunn, kënne mir Call Bridge Clustering konfiguréieren. Call Bridge Clustering ass anescht wéi Datebank oder XMPP Clustering. Call Bridge Cluster kann vun 2 bis 8 Wirbelen ouni Restriktiounen ënnerstëtzen. Et bitt net nëmmen Redundanz, awer och Belaaschtung, sou datt Konferenzen aktiv iwwer Call Bridge Servere verdeelt kënne mat intelligenter Uruffverdeelung. D'CMS huet zousätzlech Funktiounen, Call Bridge Gruppen an Zesummenhang Fonctiounen déi fir weider Gestioun benotzt ginn.
Call Bréck Clustering ass haaptsächlech duerch d'Web Admin Interface konfiguréiert
D'Prozedur hei ënnendrënner beschriwwe muss op all Server am Cluster duerchgefouert ginn.
An dofir,
1. Gitt duerch de Web op Configuratioun> Cluster.
2. An der Call Bréck Identitéit Als eenzegaartegen Numm gitt Callbridge [01,02,03] entspriechend dem Servernumm. Dës Nimm sinn arbiträr, awer musse fir dëse Stärekoup eenzegaarteg sinn. Si sinn deskriptiv an der Natur well se uginn datt se Serveridentifizéierer sinn [01,02,03].
3.B Clustered Call Brécke gitt d'Webadministrator URLe vun eise Serveren am Cluster, [01,02,03].example.com:445, am Adressfeld. Gitt sécher den Hafen ze spezifizéieren. Dir kënnt Peer Link SIP Domain eidel loossen.
4. Füügt e Certificat un d'CallBridge Vertrauen vun all Server, deen de Fichier all d'Zertifikater vun eise Serveren enthält, déi mir am Ufank an dës Datei fusionéiert hunn, mat engem Kommando wéi:
callbridge trust cluster <trusted cluster certificate bundle>A restart de Service mam Kommando:
callbridge restart
Als Resultat, op all Server sollt Dir dëst Bild kréien:
XMPP Cluster
Den XMPP Service am CMS gëtt benotzt fir all Umeldung an Authentifikatioun fir Cisco Meeting Apps (CMA) ze handhaben, och den CMA WebRTC Web Client. D'Call Bridge selwer handelt och als XMPP Client fir Authentifikatiounszwecker a muss dofir konfiguréiert sinn wéi aner Clienten. XMPP Feeler Toleranz ass eng Feature déi zënter der Versioun 2.1 a Produktiounsëmfeld ënnerstëtzt gouf
D'Befehle, déi hei ënnen beschriwwe ginn, mussen op all Server mat de passenden Certificaten ausgefouert ginn.
Also:
Mir associéieren Zertifikater mam XMPP Service mat engem Kommando wéi:
xmpp certs <keyfile> <certificatefile>[<cert-bundle>]Dann definéiert d'Nolauschterer Interface mam Kommando:
xmpp listen aDen XMPP Service erfuerdert en eenzegaartegt Domain. Dëst ass de Login fir Benotzer. An anere Wierder, wann e Benotzer probéiert mat der CMA App ze aloggen (oder duerch de WebRTC Client), gitt se userID@logindomain. An eisem Fall ass et userid@conf.example.com. Firwat ass et net just example.com? An eiser spezieller Deployment hu mir eis Unified CM Domain ausgewielt, déi Jabber Benotzer an Unified CM als example.com benotzen, also brauche mir en anert Domain fir CMS Benotzer fir Uriff op a vun der CMS iwwer SIP Domains ze routen.
Setzt en XMPP Domain op mat engem Kommando wéi:
xmpp domain <domain>An aktivéiert den XMPP Service mam Kommando:
xmpp enableAm XMPP Service musst Dir Umeldungsinformatiounen erstellen fir all Call Bridge déi benotzt gëtt wann Dir mam XMPP Service registréiert. Dës Nimm sinn arbiträr (a sinn net Zesummenhang mat der eenzegaarteg Nimm Dir fir Opruff Bréck Cluster konfiguréiert). Dir musst dräi Uruffbrécke op engem XMPP Server addéieren an dann dës Umeldungsinformatiounen op anere XMPP Serveren am Cluster aginn, well dës Konfiguratioun net an d'Cluster Datebank passt. Méi spéit konfiguréiere mir all Call Bridge fir dësen Numm a Geheimnis ze benotzen fir sech mam XMPP Service anzeschreiwen.
Elo musse mir den XMPP Service op den éischte Server mat dräi Call Bridges callbridge01, callbridge02 an callbridge03 konfiguréieren. All Kont gëtt zoufälleg Passwierder zougewisen. Si ginn spéider op aner Call Bridge Server agefouert fir op dësen XMPP Server ze loggen. Gitt déi folgend Kommandoen un:
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03Als Resultat kontrolléiere mir wat mam Kommando geschitt ass:
xmpp callbridge list
Genau datselwecht Bild soll op de verbleiwen Serveren no de Schrëtt hei ënnendrënner erscheinen.
Als nächst addéiere mer genee déiselwecht Astellungen op de verbleiwen zwee Serveren, nëmme mat de Kommandoen
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03Mir addéieren Secret ganz virsiichteg sou datt zum Beispill keng extra Plazen dra sinn.
Als Resultat soll all Server datselwecht Bild hunn:
Als nächst, op all Server am Stärekoup, spezifizéiere mir am Vertrauen d'Datei mat all dräi Certificaten, déi virdru mat engem Kommando wéi dëst erstallt goufen:
xmpp cluster trust <trust bundle>Mir aktivéieren xmpp Cluster Modus op all Cluster Server mam Kommando:
xmpp cluster enableUm éischte Server vum Cluster initiéieren mir d'Schafung vun engem xmpp Cluster mam Kommando:
xmpp cluster initializeOp anere Server füügt e Cluster op xmpp mat engem Kommando wéi:
xmpp cluster join <ip address head xmpp server>Mir kontrolléieren op all Server den Erfolleg fir en XMPP Cluster op all Server ze kreéieren mat de Kommandoen:
xmpp status
xmpp cluster statusÉischt Server:
Zweete Server:
Drëtte Server:
Connecting Call Bridge zu XMPP
Elo datt den XMPP Cluster leeft, musst Dir d'Call Bridge Servicer konfiguréieren fir mam XMPP Cluster ze verbannen. Dës Konfiguratioun gëtt duerch de Web Admin gemaach.
Op all Server gitt op Configuratioun> Allgemeng an am Feld Eenzegaarteg Call Bréck Numm schreiwen eenzegaarteg Nimm entspriechend dem Server Call Bréck Callbridge[01,02,03]. Am Feld Domain conf.example.ru an entspriechend Passwierder, Dir kënnt op hinnen Spioun
op all Server am Cluster mam Kommando:
xmpp callbridge list
Loosst de Feld "Server" eidel callbridge wäert en DNS SRV Lookup maachen fir _xmpp-component._tcp.conf.example.comfir e verfügbaren XMPP Server ze fannen. D'IP Adresse fir Callbridges mat XMPP ze verbannen kënnen op all Server ënnerscheeden, et hänkt dovun of wéi eng Wäerter op d'Rekordfuerderung zréckginn _xmpp-component._tcp.conf.example.com callbridge, déi am Tour hänkt op der Prioritéit Astellunge fir eng ginn DNS Rekord.
Als nächst gitt op Status> Allgemeng fir z'iwwerpréiwen ob den Call Bride Service erfollegräich mam XMPP Service ugeschloss ass.
Web Bréck
Op all Server am Cluster aktivéiert de Web Bridge Service mam Kommando:
webbridge listen a:443Mir konfiguréieren de Web Bridge Service mat Zertifikatdateien mat engem Kommando wéi:
webbridge certs <keyfile> <certificatefile> <ca bundle>Web Bridge ënnerstëtzt HTTPS. Et wäert HTTP op HTTPS viruleeden wann et konfiguréiert ass fir "http-Redirect" ze benotzen.
Fir HTTP Viruleedung z'aktivéieren, benotzt de folgende Kommando:
webbridge http-redirect enableFir Call Bridge ze wëssen datt Web Bridge Verbindunge vu Call Bridge vertraue kann, benotzt de Kommando:
webbridge trust <certfile>wou dëst e Fichier ass mat all dräi Certificaten vun all Server am Cluster.
Dëst Bild sollt op all Server am Cluster sinn.
Elo musse mir e Benotzer mat der Roll "appadmin" erstellen, mir brauchen et fir datt mir eise Cluster (!) kënne konfiguréieren an net all Server am Cluster separat, sou ginn d'Astellunge gläich op all Server ugewannt trotz der Tatsaach, datt se eemol gemaach ginn.
Fir weider Opstellung wäerte mir benotzen .
Fir Autorisatioun, wielt Basis an der Autorisatiounssektioun
Fir korrekt Kommandoen op den CMS Server ze schécken, musst Dir déi erfuerderlech Kodéierung setzen
Mir spezifizéieren Webbridge mam Kommando POST mat Parameter URL a Bedeitung
An der Webbréck selwer weisen mir déi erfuerderlech Parameteren un: Gaascht Zougang, geschützt Zougang, etc.
Call Bréck Gruppen
Par défaut mécht d'CMS net ëmmer déi effizientst Notzung vun de Konferenzressourcen, déi et verfügbar ass.
Zum Beispill, fir eng Versammlung mat dräi Participanten, kann all Participant op dräi verschidden Call Bridges ophalen. Fir datt dës dräi Participanten matenee kommunizéieren, wäerten Call Bridges automatesch Verbindungen tëscht all Server a Clienten am selwechte Raum opbauen, sou datt et alles ausgesäit wéi wann all Clienten um selwechte Server sinn. Leider ass de Nodeel dovun datt eng eenzeg 3-Persoun Konferenz elo 9 Medienhäfen verbraucht. Dëst ass offensichtlech eng ineffizient Notzung vu Ressourcen. Zousätzlech, wann eng Call Bridge wierklech iwwerlaascht ass, ass de Standardmechanismus weider Uriff ze akzeptéieren a reduzéiert Qualitéitsservice un all Abonnente vun där Call Bridge ze bidden.
Dës Probleemer gi mat der Call Bridge Group Feature geléist. Dës Feature gouf an der Versioun 2.1 vun der Cisco Meeting Server Software agefouert a gouf erweidert fir d'Laaschtbalancéierung fir béid Inbound an Outbound Cisco Meeting App (CMA) Appellen z'ënnerstëtzen, dorënner WebRTC Participanten.
Fir de Reconnection Problem ze léisen, goufen dräi konfiguréierbar Belaaschtungsgrenze fir all Call Bridge agefouert:
LoadLimit - dëst ass déi maximal numeresch Belaaschtung fir eng bestëmmte Call Bridge. All Plattform huet eng recommandéiert Lastlimit, wéi 96000 fir den CMS1000 an 1.25 GHz pro vCPU fir déi virtuell Maschinn. Verschidde Uriff verbrauchen eng gewësse Quantitéit vu Ressourcen ofhängeg vun der Resolutioun an der Frame Taux vum Participant.
NewConferenceLoadLimitBasisPoints (Standard 50% loadLimit) - setzt d'Serverbelaaschtungslimit, no deenen nei Konferenzen verworf ginn.
ExistingConferenceLoadLimitBasisPoints (Standard 80% vun loadLimit) - de Serverbelaaschtungswäert, no deem d'Participanten, déi op eng existent Konferenz bäitrieden, refuséiert ginn.
Iwwerdeems dës Fonktioun fir Uruff Verdeelung a Laascht Equiliber entworf gouf, kënnen aner Gruppen wéi TURN Serveren, Web Bridge Serveren an Recorder och zu Call Bridge Groups zougewisen ginn, sou datt se och richteg fir optimal Notzung gruppéiere kënnen. Wann eng vun dësen Objete sinn net zu engem Opruff Grupp zougewisen, si sinn ugeholl fir all Serveren ouni speziell Prioritéit sinn.
Dës Parameteren sinn hei konfiguréiert: :445/api/v1/system/configuration/cluster
Als nächst weisen mir all Callbridge un wéi eng Callbridge Grupp et gehéiert:
Éischt Callbridge
Zweet Callbridge
Drëtt Callbridge
Also hu mir den Call Brdige Grupp konfiguréiert fir d'Ressourcen vum Cisco Meeting Server Cluster méi effizient ze benotzen.
Import Benotzer aus Active Directory
De Web Admin Service huet eng LDAP Konfiguratiounssektioun, awer et bitt keng komplex Konfiguratiounsoptiounen, an d'Informatioun gëtt net an der Cluster Datebank gespäichert, sou datt d'Konfiguratioun muss gemaach ginn, entweder manuell op all Server iwwer de Web Interface, oder duerch d'API, a sou datt mir "dräi Mol "Stinn net op" wäerte mir nach ëmmer d'Donnéeën iwwer d'API setzen.
Benotzt URL fir Zougang :445/api/v1/ldapServers erstellen en LDAP Server-Objet, spezifizéieren Parameteren wéi:
- Server IP
- port Zuel
- Benotzernumm
- Passwuert
- sécher
Séchert - wielt richteg oder falsch ofhängeg vum Hafen, 389 - net sécher, 636 - geschützt.
Mapping LDAP Quell Parameteren ze Attributer an Cisco Meeting Server.
D'LDAP Mapping mapt Attributer am LDAP Verzeichnis op Attributer am CMS. Déi tatsächlech Attributer:
- jidMapping
- NummMapping
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Beschreiwung vun AttributerIADB representéiert d'Login-ID vum Benotzer am CMS. Well dëst e Microsoft Active Directory LDAP Server ass, mapt d'CMS JID op den sAMAccountName an LDAP, wat am Wesentlechen dem Benotzer seng Active Directory Login ID ass. Notéiert och datt Dir sAMAccountName hëlt an d'Domain conf.pod6.cms.lab un d'Enn bäidréit, well dëst de Login ass, déi Är Benotzer benotze fir an d'CMS ze loggen.
NummMapping entsprécht deem wat am Active Directory DisplayName Feld enthale gëtt mam CMS Nummfeld vum Benotzer.
coSpaceNameMapping erstellt e CMS Raumnumm baséiert op dem DisplayName Feld. Dëst Attribut, zesumme mam coSpaceUriMapping Attribut, ass wat néideg ass fir e Raum fir all Benotzer ze kreéieren.
coSpaceUriMapping definéiert de Benotzerdeel vun der URI, déi mam perséinleche Raum vum Benotzer assoziéiert ass. E puer Domaine kënne konfiguréiert ginn fir an de Weltraum geruff ze ginn. Wann de Benotzerdeel mat dësem Feld fir eng vun dësen Domainen entsprécht, gëtt den Uruff op de Raum vum Benotzer geleet.
coSpaceSecondaryUriMapping definéiert eng zweet URI fir Plaz z'erreechen. Dëst kann benotzt ginn fir en numeresche Alias ze addéieren fir Uriff op de Raum vum importéierte Benotzer als Alternativ zu der alphanumerescher URI, déi am coSpaceUriMapping Parameter definéiert ass, ze addéieren.
Den LDAP-Server an d'LDAP-Mapping sinn konfiguréiert. Elo musst Dir se matenee verbannen andeems Dir eng LDAP Quell erstellt.
Benotzt URL fir Zougang :445/api/v1/ldapSource erstellt en LDAP Source-Objekt, spezifizéiert Parameteren wéi:
- Server
- Conclusiounen
- baseDn
- filter
Elo datt d'LDAP Konfiguratioun fäerdeg ass, kënnt Dir d'manuell Synchroniséierungsoperatioun ausféieren.
Mir maachen dat entweder am Web Interface vun all Server vun Klick Synchroniséiert elo Sektioun Active Directory
oder iwwer d'API mam Kommando POST benotzt URL fir Zougang :445/api/v1/ldapSyncs
Ad-hoc Konferenzen
Wat ass dat?Am traditionelle Konzept ass eng Konferenz wann zwee Participanten matenee schwätzen, an ee vun de Participanten (mat engem Apparat registréiert mat Unified CM) dréckt op de "Konferenz" Knäppchen, rufft déi aner Persoun un, an nodeems se mat där Drëtt Partei geschwat hunn. , dréckt nach eng Kéier op de "Konferenz" Knäppchen fir all Participanten un der Tripartite Konferenz matzemaachen.
Wat eng Ad-Hoc Konferenz vun enger geplangter Konferenz an engem CMS ënnerscheet ass datt eng Ad-Hoc Konferenz net nëmmen e SIP Uruff un e CMS ass. Wann de Konferenzinitiator eng zweete Kéier op de Konferenzknäppchen klickt fir jiddereen op déiselwecht Versammlung ze invitéieren, muss Unified CM en API Uruff un d'CMS maachen fir eng on-the-fly Konferenz ze kreéieren, op déi all Uruff dann transferéiert ginn. All dëst geschitt onnotéiert vun de Participanten.
Dëst bedeit datt Unified CM d'API Umeldungsinformatiounen an d'WebAdmin Adress / Port vum Service souwéi de SIP Trunk direkt op den CMS Server muss konfiguréieren fir den Uruff weiderzemaachen.
Wann néideg, kann CUCM dynamesch e Raum am CMS erstellen, sou datt all Uruff d'CMS erreeche kann a mat der Entréeën Uruffregel passen, déi fir Plazen geduecht ass.
Integratioun mat CUCM konfiguréiert op déiselwecht Manéier wéi am Artikel beschriwwen ausser datt op Cisco UCM musst Dir dräi Trunks fir den CMS erstellen, dräi Konferenzbrécke, am SIP Sécherheetsprofil spezifizéieren dräi Sujetennimm, Route Groups, Route Lists, Media Resourse Groups and Media Resourse Group Lists, a füügt e puer Routingregelen derbäi. zu Cisco Meeting Server.
SIP Sécherheet Profil:
Trunks:
All Stamm gesäit d'selwecht aus:
Konferenz Bréck
All Konferenzbréck gesäit d'selwecht aus:
Route Group
Route Lëscht
Media Ressource Group
Media Ressource Group Lëscht
Call Regelen
Am Géigesaz zu méi fortgeschratt Call Management Systemer wéi Unified CM oder Expressway, kuckt CMS nëmmen d'Domain am SIP Request-URI Feld fir nei Uriff. Also wann SIP INVITE fir Schlupp ass: [Email geschützt]De CMS këmmert sech nëmmen ëm domain.com. CMS follegt dës Reegele fir ze bestëmmen wou en Uruff rout:
1. D'CMS probéiert als éischt de SIP-Domain mat den Domänen ze passen, déi an den Entréeën Uruffregelen konfiguréiert sinn. Dës Uriff kënnen dann op ("geziilt") Plazen oder spezifesch Benotzer, intern IVRs, oder direkt integréiert Microsoft Lync/Skype for Business (S4B) Destinatiounen geréckelt ginn.
2. Wann et kee Match an der Entréeën Opruff Regelen ass, wäert CMS probéieren d'Domain ze Match an der Opruff Forwarding Dësch konfiguréiert. Wann e Match gemaach gëtt, kann d'Regel den Uruff explizit refuséieren oder den Uruff weiderginn. Zu dëser Zäit kann d'CMS d'Domain nei schreiwen, wat heiansdo nëtzlech ass fir Lync Domainen ze ruffen. Dir kënnt och wielen ze Passe geheien, dat heescht datt keng vun de Felder weider geännert ginn, oder benotzt en internen CMS Dialplang. Wann et kee Match an den Uruff Forwarding Regelen ass, ass de Standard den Uruff ze refuséieren. Denkt drun datt am CMS, obwuel den Uruff "Forward" ass, d'Medien nach ëmmer un d'CMS gebonnen sinn, dat heescht datt et am Signal- a Medienverkéierswee ass.
Dann sinn nëmme weidergeleet Uruff ënnerleien un d'Reegelen fir erausginn Uruff. Dës Astellunge bestëmmen d'Destinatioune wou d'Uriff geschéckt ginn, den Trunk-Typ (egal ob et en neie Lync-Uruff oder e Standard SIP-Uruff ass), an all Konversiounen déi duerchgefouert kënne ginn wann d'Iwwerweisung net an der Call Forwarding Regel ausgewielt gëtt.
Hei ass den aktuellen Logbuch vun deem wat während enger Ad-Hoc Konferenz geschitt
De Screenshot weist et schlecht (ech weess net wéi ech et besser maachen), also schreiwen ech de Log esou:
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:12D'Ad-Hoc Konferenz selwer:
Entréeën Call Regelen
D'Konfiguratioun vun de Parameteren vun erakommen Uriff ass néideg fir en Uruff am CMS ze kréien. Wéi Dir am LDAP-Setup gesinn hutt, goufen all Benotzer mam Domain conf.pod6.cms.lab importéiert. Also op e Minimum wëllt Dir Uruff un dës Domain fir Zilplazen ze zielen. Dir musst och Regelen opstellen fir alles wat fir de vollqualifizéierten Domain Numm (a vläicht souguer d'IP Adress) vun all CMS Server geduecht ass. Eis extern Uruffkontrolle, Unified CM, konfiguréiert SIP Trunks déi all eenzel vun den CMS Serveren individuell gewidmet sinn. Ofhängeg ob d'Destinatioun vun dëse SIP Trunks eng IP Adress ass oder de FQDN vum Server wäert bestëmmen ob d'CMS muss konfiguréiert ginn fir Uriff un hir IP Adress oder FQDN ze akzeptéieren.
D'Domain déi déi héchst Prioritéit Inbound Regel huet gëtt als Domain fir all Benotzerraim benotzt. Wann d'Benotzer iwwer LDAP synchroniséieren, erstellt d'CMS automatesch Plazen, awer nëmmen de Benotzerdeel vun der URI (coSpaceUriMapping), zum Beispill, user.space. Deel Déi voll URI gëtt op Basis vun dëser Regel generéiert. Tatsächlech, wann Dir op dësem Punkt op Web Bridge aloggen, géift Dir gesinn datt de Space URI keen Domain huet. Andeems Dir dës Regel als héchst Prioritéit setzt, setzt Dir den Domain fir déi generéiert Plazen conf.example.com.
Erausgoen Call Regelen
Fir d'Benotzer z'erméiglechen Outbound Uruff un den Unified CM Cluster ze maachen, musst Dir Outbound Reegele konfiguréieren. D'Domain vun Endpunkte registréiert mat Unified CM, wéi Jabber, ass example.com. Uriff op dës Domain sollen als Standard SIP-Uriff op Unified CM Call Processing Node geréckelt ginn. Den Haaptserver ass cucm-01.example.com, an den zousätzlechen ass cucm-02.example.com.
Déi éischt Regel beschreift déi einfachst Routing vun Uriff tëscht Clusterserveren.
Beräich Lokal aus Domain ass verantwortlech fir dat wat an der SIP-URI vum Uruffer ugewise gëtt fir déi Persoun déi nom "@" Symbol genannt gëtt. Wa mir et eidel loossen, da gëtt et nom "@" Symbol d'IP Adress vun der CUCM, duerch déi dësen Uruff passéiert. Wa mir en Domain spezifizéieren, da gëtt et nom "@" Symbol tatsächlech en Domain. Dëst ass néideg fir kënnen ze ruffen, soss ass et net méiglech iwwer SIP-URI Numm@ip-Adress zréckzeruffen.
Call wann uginn Lokal aus Domain
Call wann NET uginn Lokal aus Domain
Vergewëssert Iech explizit Verschlësselte oder Onverschlësselte fir erausginn Uriff ze spezifizéieren, well näischt mam Auto Parameter funktionnéiert.
Opzehuelen
Videokonferenzen ginn vum Record Server opgeholl. Recorder ass genau d'selwecht wéi Cisco Meeting Server. Recorder erfuerdert keng Installatioun vu Lizenzen. Opnamlizenzen sinn néideg fir Serveren déi CallBridge Servicer lafen, d.h. eng Opname Lizenz ass erfuerderlech a muss op den CallBridge Komponent applizéiert ginn, an net op de Server deen Recorder leeft. Recorder behält sech als Extensible Messaging and Presence Protocol (XMPP) Client, sou datt den XMPP Server muss aktivéiert sinn um Server Hosting CallBridge.
Well Mir hunn e Cluster an d'Lizenz muss iwwer all dräi Serveren am Cluster "gestreckt" ginn. Dann einfach an Ärem perséinleche Kont an de Lizenzen, déi mir d'MAC Adresse vun den a-Schnëttplazen vun allen CMS Serveren am Cluster associéieren (addéieren).
An dëst ass d'Bild dat op all Server am Cluster soll sinn
Am Allgemengen ginn et e puer Szenarie fir den Recorder ze placéieren, awer mir bleiwen un dësem:
Ier Dir Recorder opstellt, musst Dir eng Plaz virbereeden wou d'Videokonferenzen tatsächlech opgeholl ginn. Eigentlech hei , wéi Dir all Recording opstellt. Ech konzentréieren op wichteg Punkten an Detailer:
1. Et ass besser de Certificat vum éischte Server am Cluster ze rutschen.
2. De Feeler "Recorder unavailable" kann optrieden, well de falsche Certificat am Recorder Trust spezifizéiert ass.
3. Schreiwen kann net schaffen, wann den NFS Verzeichnis fir den Opnahmen spezifizéiert ass net de Root Verzeechnes.
Heiansdo gëtt et e Besoin fir automatesch eng Konferenz vun engem spezifesche Benotzer oder Raum opzehuelen.
Fir dëst ginn zwee CallProfiles erstallt:
Mat Opnam behënnert
A mat automatescher Opnamfunktioun
Als nächst "befestegt" mir e CallProfile mat enger automatescher Opnamfunktioun op den erfuerderleche Raum.
Am CMS ass et sou etabléiert datt wann e CallProfil explizit un all Raum oder Raum gebonnen ass, da funktionnéiert dësen CallProfile nëmme a Relatioun mat dëse spezifesche Raum. A wann de CallProfile net un all Raum gebonnen ass, da gëtt se par défaut op déi Plazen ugewannt, op déi kee CallProfile explizit gebonnen ass.
Nächst Kéier probéieren ech ze beschreiwen wéi de CMS ausserhalb vum internen Netzwierk vun der Organisatioun zougänglech ass.
Quell:
Source: will.com