In deze aflevering laat ik enkele nuances zien en uitleggen over het instellen van de CMS-server in een fault-tolerant cluster.
TheorieEr zijn drie types van het inzetten van een CMS-server:
- Single Combined(Eén gecombineerde), wat betekent dat dit één server is waarop alle benodigde services draaien. In de meeste gevallen is dit type inzet alleen toepasbaar voor interne klanten en in kleine omgevingen waar de beperkingen van schaalbaarheid en redundantie van één server geen kritische problemen zijn, of in situaties waarin de CMS slechts bepaalde functies uitvoert, zoals speciale conferenties op Cisco UCM.
Een voorbeeldschema van werking:
- Single Split(Eén gesplitste) breidt het vorige type inzet uit door een aparte server voor externe toegang toe te voegen. In verouderde deployments betekende dit het inzetten van een CMS-server in een gedemilitariseerd netwerksegment (DMZ), waar externe klanten toegang tot hadden, en één CMS-server in de kern van het netwerk, waar interne klanten toegang tot de CMS kregen. Dit specifieke model van inzet wordt nu vervangen door het zogenaamde type Single Edge, dat bestaat uit servers Cisco Expressway, die veel van de mogelijkheden voor het omzeilen van firewalls hebben of zullen hebben, zodat klanten geen aparte edge-server voor de CMS hoeven toe te voegen.
Een voorbeeldschema van werking:
- Scalable and Resilient(Schaalbaar en fouttolerant) dit type omvat redundantie voor elk component, waardoor het systeem kan groeien met uw behoeften tot maximale capaciteit, terwijl het ook redundantie biedt in geval van een storing. Het maakt ook gebruik van het concept Single Edge voor veilige externe toegang. Dit is het type dat we in deze aflevering zullen bespreken. Door te begrijpen hoe we een cluster van dit type kunnen implementeren, begrijpen we niet alleen andere types van inzet, maar kunnen we ook begrijpen hoe we CMS-serverclusters kunnen creëren met het oog op potentiële groei van behoeften.
Voordat we verder gaan met de inzet, is het belangrijk om enkele basiszaken te begrijpen, namelijk
De belangrijkste softwarecomponenten van de CMS:
- Database: stelt het mogelijk om enkele configuraties samen te voegen, zoals abonnee groepen, gebruikersruimten en de gebruikers zelf. Ondersteunt clustering alleen voor hoge beschikbaarheid (één master).
- Call Bridge: een service voor audio- en videoconferenties, waarmee volledige controle over het beheer en de verwerking van oproepen en multimedia-processen mogelijk is. Ondersteunt clustering voor hoge beschikbaarheid en schaalbaarheid.
- XMPP-server: is verantwoordelijk voor de registratie en authenticatie van clients die de Cisco Meeting Application en/of WebRTC gebruiken (real-time communicatie, of simpelweg in de browser), evenals intercomponent-signalisatie. Kan alleen voor hoge beschikbaarheid worden geclusterd.
- Web Bridge: biedt toegang voor clients in WebRTC.
- Loadbalancer: biedt een enkel aansluitpunt voor de Cisco Meeting App in Single Split-modus. Luistert naar de externe interface en poort voor binnenkomende verbindingen. Eveneens accepteert de loadbalancer binnenkomende TLS-verbindingen van de XMPP-server, waardoor deze TCP-verbindingen van externe clients kan overdragen.
In ons scenario is deze niet nodig. - TURN-server: biedt de techniek om Firewalls te omzeilen, waardoor
onze CMS buiten de Firewall of NAT kan worden geplaatst voor verbinding met externe clients die de Cisco Meeting App of SIP-apparaten gebruiken. In ons scenario is deze niet nodig. - Web Admin: het beheerdersinterface en toegang tot de API, inclusief voor speciale vergaderingen van Unified CM.
Configuratiemodi
In tegenstelling tot de meeste andere producten van Cisco, ondersteunt Cisco Meeting Server drie configuratiemethoden die het mogelijk maken om elk type implementatie te realiseren.
- Command Line (CLI): De command line interface, bekend als MMP, voor initiële configuratie en certificaten.
- Webbeheerder: voornamelijk voor configuratie gerelateerd aan CallBridge, vooral bij de configuratie van één niet-geclusterde server.
- REST API: wordt gebruikt voor de meest complexe configuratietaken en taken gerelateerd aan de cluster-database.
Naast het bovenstaande wordt het protocol SFTP gebruikt voor bestandsoverdracht — meestal licenties, certificaten of logboeken — naar en van de CMS-server.
In de deployment-gidsen van Cisco staat zwart op wit dat een cluster moet worden uitgerold minimaal uit drie servers (nodes) in de context van databases. Dit komt omdat alleen met een oneven aantal nodes het mechanisme voor het kiezen van een nieuwe database-master functioneert, en de database-master in het algemeen verbonden is met het grootste deel van de database van de CMS-server.
En zoals de praktijk aantoont, zijn twee servers (nodes) eigenlijk niet voldoende. Het selectiemechanisme werkt tijdens het herstarten van de Master, de Slave-server wordt pas een Master na het opstarten van de herstartte server. Als bijvoorbeeld de Master-server in een cluster van twee servers uitvalt, zal de Slave-server geen Master worden; en als de Slave uitvalt, zal de resterende Master-server ook een Slave worden.
In de context van XMPP is het echter echt nodig om een cluster van drie servers op te zetten, omdat als je bijvoorbeeld de XMPP-dienst op een van de servers met XMPP in de status Leader uitschakelt, de resterende server XMPP in de status Follower blijft en de verbindingen van CallBridge naar XMPP zullen falen, omdat CallBridge alleen verbinding maakt met XMPP in de status Leader. Dit is cruciaal, aangezien geen enkele oproep zal doorkomen.
In deze deploymentgidsen wordt ook een cluster met één XMPP-server getoond.
Gezien het bovenstaande is het duidelijk waarom: het werkt omdat het in failover-modus functioneert.
In ons geval zal de XMPP-server op alle drie de nodes aanwezig zijn.
Er wordt aangenomen dat al onze drie servers zijn opgestart.
DNS-records
Voordat je begint met het configureren van de servers, is het noodzakelijk om DNS-records aan te maken. A en SRV Types:
Let op dat in onze DNS-records twee domeinen aanwezig zijn: example.com en conf.example.com. Example.com is het domein dat alle klanten van Cisco Unified Communication Manager kunnen gebruiken voor hun URI's, die waarschijnlijk al in je infrastructuur aanwezig zijn of met een hoge waarschijnlijkheid aanwezig zullen zijn. Of het domein example.com komt overeen met hetzelfde domein dat gebruikers gebruiken voor hun e-mailadressen. Of de Jabber-client op je laptop kan de URI user@example.com hebben. Het domein conf.example.com is het domein dat zal worden ingesteld voor gebruikers van Cisco Meeting Server. Het domein van Cisco Meeting Server zal zijn conf.example.com, dus voor dezelfde gebruiker Jabber moet je de URI user@ gebruiken om in te loggen op de Cisco Meeting Server.conf.example.com.
Basisconfiguratie
Alle instellingen die hieronder worden beschreven, zijn weergegeven op één server, maar moeten op elke server in het cluster worden uitgevoerd.
QoS
Aangezien CMS genereert real-time Verkeer dat gevoelig is voor vertraging en pakketverlies, moet meestal worden geconfigureerd met kwaliteitsdienstverlening (QoS). Hiervoor ondersteunt de CMS de markering van pakketten met differentiërende servicecodes (DSCP), die het genereert. Hoewel de prioritering van verkeer op basis van DSCP afhankelijk is van hoe het verkeer door de netwerkcomponenten van uw infrastructuur wordt verwerkt, zullen we in ons geval onze CMS configureren met een typische DSCP-prioriteitsverdeling op basis van de beste QoS-praktijken.
Voer op elke server de volgende commando's in
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1AOp deze manier is al het videoverkeer gemarkeerd als AF41 (DSCP 0x22), al het spraakverkeer is gemarkeerd als EF (DSCP 0x2E), andere soorten verkeer met lage latentie, zoals SIP en XMPP, maken gebruik van AF31 (DSCP 0x1A).
We controleren:
NTP
Het Network Time Protocol (NTP) is niet alleen belangrijk voor het zorgen voor nauwkeurige tijdstempels voor oproepen en conferenties, maar ook voor het verifiëren van certificaten.
Voeg NTP-servers aan uw infrastructuur toe met een commando als:
ntp server add In ons geval zijn er twee van zulke servers, dus er zullen twee commando's zijn.
We controleren:
En stel de tijdzone voor onze server in
DNS
DNS-servers in de CMS voegen we toe met een commando als:
dns add forwardzone In ons geval zijn er twee van zulke servers, dus er zullen twee commando's zijn.
We controleren:
Configuratie van de netwerkinterface
We configureren de interface met een commando als:
ipv4 add / We controleren:
Servernaam (Hostname)
We stellen de servernaam in met een commando als:
hostname En we herstarten.
De basisconfiguratie is hiermee voltooid.
Certificates
TheorieCisco Meeting Server vereist gecodeerde communicatie tussen verschillende componenten, en daarom zijn X.509-certificaten vereist voor alle CMS-implementaties. Ze helpen om vertrouwen te waarborgen aan diensten/serveren van andere diensten/serveren.
Voor elke dienst is een certificaat vereist, maar het aanmaken van afzonderlijke certificaten voor elke dienst kan verwarrend en onnodig ingewikkeld zijn. Gelukkig kunnen we een paar openbare en privésleutels voor het certificaat genereren en deze vervolgens hergebruiken voor meerdere diensten. In ons geval zal hetzelfde certificaat worden gebruikt voor Call Bridge, XMPP-server, Web Bridge en Web Admin. We moeten dus een paar openbare en privésleutels voor elk server in het cluster aanmaken.
Database clustering heeft echter enkele bijzondere eisen aan certificaten en vereist daarom eigen certificaten die verschillen van die van andere diensten. Het CMS gebruikt een servercertificaat dat lijkt op de certificaten die door andere servers worden gebruikt, maar er is ook een clientcertificaat dat wordt gebruikt voor verbindingen met de database. Databasecertificaten worden gebruikt voor zowel authenticatie als encryptie. In plaats van een gebruikersnaam en wachtwoord te verstrekken voor de verbinding van de client met de database, presenteert het een clientcertificaat dat door de server wordt vertrouwd. Elke server in de databasecluster gebruikt hetzelfde paar van publieke en private sleutels. Dit stelt alle servers in de cluster in staat om gegevens te versleutelen op een manier die alleen door andere servers kan worden ontsleuteld die ook hetzelfde paar sleutels gebruiken.
Om failover goed te laten functioneren, moeten databaseclusters bestaan uit minimaal 3 servers, maar niet meer dan 5, met een maximale round-trip tijd van 200 ms tussen enige leden van de cluster. Deze limiet is strikter dan voor Call Bridge clustering, waardoor het vaak een beperkende factor is in geografisch verspreide implementaties.
De rol van de database voor het CMS heeft een aantal unieke vereisten. In tegenstelling tot andere rollen vereist het zowel een client- als servercertificaat, waarbij het clientcertificaat een specifiek CN-veld heeft dat aan de server wordt gepresenteerd.
Het CMS gebruikt een postgres-database met één primaire en meerdere volledig identieke replica's. Op elk moment bestaat er slechts één primaire database (‘database server’). De overige leden van de cluster zijn replica's of 'database clients'.
Voor een databasecluster zijn een dedicated servercertificaat en een clientcertificaat vereist. Ze moeten zijn ondertekend door certificaten, meestal door een interne particuliere certificeringsautoriteit. Aangezien iedere lid van het databasecluster de hoofdmacht kan worden, moeten paren van database-server- en clientcertificaten (bevatten een openbaar en privé sleutel) naar alle servers worden gekopieerd, zodat zij de identiteit van de client of de database-server kunnen accepteren. Bovendien moet het root-certificaat van de CA worden geladen om te garanderen dat de certificaten van de client en server kunnen worden geverifieerd.
Laten we dan een aanvraag voor het certificaat opstellen dat door alle serverdiensten zal worden gebruikt behalve de database (voor dit zal een afzonderlijke aanvraag worden gedaan) met de opdracht:
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
In de CN schrijven we de algemene naam van onze servers. Bijvoorbeeld, als de hostnamen van onze servers server01, server02, server03, dan wordt de CN server.example.com
Dezelfde procedure voeren we uit op de andere twee servers met als verschil dat in de opdrachten de bijbehorende "hostnamen" zullen staan.
We stellen twee aanvragen voor certificaten op die door de database-service zullen worden gebruikt met de opdrachten:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgreswaar dbclusterserver en dbclusterclient de namen van onze aanvragen en toekomstige certificaten. hostname1(2)(3) de namen van de overeenkomstige servers.
Deze procedure voeren we alleen uit op één server (!), en we zullen de certificaten en de bijbehorende .key-bestanden naar andere servers uploaden.
Klanten certificaatmodus inschakelen in AD CS
We moeten ook de certificaten voor elke server in één bestand samenvoegen.In *NIX:
cat server01.cer server02.cer server03.cer > server.cerIn Windows/DOS:
copy server01.cer + server02.cer + server03.cer server.cer En uploaden naar elke server:
1. Het "individuele" servercertificaat.
2. Rootcertificaat (samen met eventuele tussenliggende certificaten indien aanwezig).
3. Certificaten voor de database ("server-" en "clientcertificaat") en bestanden met de extensie .key, die zijn aangemaakt bij het opstellen van de aanvraag voor het "server-" en "clientcertificaat" van de database. Deze bestanden moeten dezelfde zijn op alle servers.
4. Bestand met alle drie de "individuele" certificaten.
Uiteindelijk moet er ongeveer zo'n bestandstructuur op elke server zijn.
Database Cluster
Nu je alle certificaten op de CMS-servers hebt geüpload, kun je de databaseclustering tussen drie knooppunten instellen en inschakelen. De eerste stap is om één server te kiezen als de hoofdknop van de databasecluster en deze volledig in te stellen.
Hoofd Database
De eerste stap in het instellen van database-replicatie is het opgeven van de certificaten die voor de database zullen worden gebruikt. Dit gebeurt met een commando van de vorm:
database cluster certsLaten we nu aan de CMS opgeven welke interface we willen gebruiken voor databaseclustering met het commando:
database cluster localnode aVervolgens initialiseren we de databasecluster op de hoofdserver met het commando:
database cluster initialize
Client Database Nodes
We doorlopen dezelfde procedure, maar in plaats van het commando database cluster initialize gebruiken we een commando van de vorm:
database cluster joinwaarbij ip address existing master het IP-adres is van de CMS-server waarop de initialisatie van de cluster heeft plaatsgevonden, simpelweg de Master.
We controleren hoe onze databasecluster op alle servers werkt met het commando:
database cluster status
Hetzelfde doen we ook op de resterende derde server.
Uiteindelijk blijkt dat onze eerste server de Master is, terwijl de andere Slaves zijn.
Web Admin Service
We schakelen de webadminservice in:
webadmin listen a 445Poort 445 is gekozen omdat poort 443 wordt gebruikt voor de toegang van gebruikers tot de webclient.
We configureren de Web Admin-service met certificaatbestanden met het commando van de vorm:
webadmin certsEn we schakelen de Web Admin in met het commando:
webadmin enable 
Als alles goed is, zien we de regels SUCCESS, waarin staat dat de Web Admin correct is ingesteld voor het netwerk en certificaat. We controleren de functionaliteit van de service via een webbrowser en voeren het adres van de webadmin in, bijvoorbeeld: :445
Call Bridge Cluster
Call Bridge is de enige service die in elke CMS-implementatie aanwezig is. Call Bridge is het belangrijkste mechanisme voor conferentietelefonie. Het biedt ook een SIP-interface, zodat oproepen naar of van hem kunnen worden gerouteerd, bijvoorbeeld via Cisco Unified CM.
De onderstaande commando's moeten op elke server met de juiste certificaten worden uitgevoerd.
Dus:
We koppelen de certificaten aan de Call Bridge-service met een commando van de vorm:
callbridge certs []We koppelen de CallBridge-services aan de gewenste interface met het commando:
callbridge listen aEn we starten de service opnieuw met het commando:
callbridge restart 
Nu we de Call Bridges hebben ingesteld, kunnen we de clustering van de Call Bridge configureren. De clustering van Call Bridge verschilt van de clustering van databases of XMPP. Een Call Bridge Cluster kan van 2 tot 8 knooppunten ondersteunen zonder enige beperkingen. Het biedt niet alleen redundantie, maar ook een load balancing, waardoor conferenties actief kunnen worden verdeeld over de Call Bridge-servers via intelligente oproepverdeling. CMS heeft extra functies, Call Bridge-groepen en gerelateerde functies die kunnen worden gebruikt voor verder beheer.
De clustering van de Call Bridge wordt voornamelijk ingesteld via de webbeheerinterface.
De hieronder beschreven procedure moet op elke server in het cluster worden uitgevoerd.
So,
1. Ga via web naar Configuratie > Cluster.
2. In Call Bridge-identiteit geven we als unieke naam callbridge[01,02,03] in, overeenkomstig de servernaam. Deze namen zijn willekeurig, maar moeten uniek zijn voor dit cluster. Ze hebben een beschrijvende aard, omdat ze aangeven dat dit de identificatie is van servers [01,02,03].
3. In Geclusterd Call Bridges geef je de URL's van de webbeheerder van onze servers in het cluster, [01,02,03].example.com:445, in het veld Adres. Vergeet niet de poort op te geven. Je kunt het Peer link SIP-domein leeg laten.
4. Vertrouw Call Bridge van elke server het certificaat toe, waarvan het bestand alle certificaten bevat van onze servers, die we in dit bestand hebben samengevoegd in het begin, met een commando als:
callbridge trust clusterEn we starten de service opnieuw met het commando:
callbridge restart 
Uiteindelijk moet op elke server het volgende resultaat verschijnen:
XMPP Cluster
De XMPP-service in CMS wordt gebruikt voor het verwerken van alle registratie en authenticatie voor Cisco Meeting Apps (CMA), inclusief de webclient CMA WebRTC. De Call Bridge zelf fungeert ook als XMPP-client voor authenticatiedoeleinden en moet daarom worden ingesteld zoals andere clients. De failover van XMPP is een functie die wordt ondersteund in productieomgevingen, vanaf versie 2.1.
De onderstaande commando's moeten op elke server met de juiste certificaten worden uitgevoerd.
Dus:
Koppel de certificaten aan de XMPP-service met een commando als:
xmpp certs []Bepaal vervolgens de luisterinterface met het commando:
xmpp listen aVoor de XMPP-service is een unieke domeinnaam vereist. Dit is de login voor gebruikers. Met andere woorden, wanneer een gebruiker probeert in te loggen met de CMA-app (of via de WebRTC-client), voert hij userID@logindomain in. In ons geval zal dit userid@conf.example.com zijn. Waarom is dit niet gewoon example.com? In onze specifieke implementatie hebben we ons domein Unified CM gekozen, dat gebruikers van Jabber in Unified CM als example.com zullen gebruiken, dus hebben we een andere domein nodig voor CMS-gebruikers om oproepen naar CMS te routeren en terug van CMS via SIP-domeinen.
Stel het XMPP-domein in met een commando in de volgende vorm:
xmpp domainEn we schakelen de XMPP-service in met het commando:
xmpp enableBinnen de XMPP-service moeten we referenties creëren voor elke Call Bridge, die zullen worden gebruikt voor registratie bij de XMPP-service. Deze namen zijn willekeurig (en niet gerelateerd aan unieke namen die je hebt ingesteld voor clusterisatie van call bridges). Op één XMPP-server moeten we drie call bridges toevoegen en vervolgens deze referenties invoeren op andere XMPP-servers in het cluster, aangezien deze configuratie niet in de cluster-database kan worden geplaatst. Later configureren we elke Call Bridge om deze naam en geheim te gebruiken voor registratie bij de XMPP-service.
Nu moeten we de XMPP-service op de eerste server instellen met de drie Call Bridges callbridge01, callbridge02 en callbridge03. Iedere account krijgt willekeurige wachtwoorden. Later zullen deze op andere Call Bridge-servers worden ingevoerd om in te loggen op deze XMPP-server. Voer de volgende commando's in:
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03Controleer uiteindelijk wat we hebben gedaan met het commando:
xmpp callbridge list 
Hetzelfde resultaat zou moeten zijn op de andere servers na de onderstaande handelingen.
Voeg vervolgens op de overige twee servers precies dezelfde instellingen toe, maar met de commando's
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03Voeg het geheim zeer zorgvuldig toe, zodat er bijvoorbeeld geen extra spaties in terechtkomen.
Uiteindelijk zou op elke server hetzelfde resultaat moeten zijn:
Vervolgens geven we op alle servers in het cluster de vertrouwde bestand op dat alle drie de certificaten bevat, eerder aangemaakt met een commando in de volgende vorm:
xmpp cluster trustSchakel de xmpp-cluster modus in op alle servers in het cluster met het commando:
xmpp cluster enableOp de eerste server van het cluster starten we de creatie van de xmpp-cluster met het commando:
xmpp cluster initializeOp de andere servers voegen we toe aan de xmpp-cluster met een commando als:
xmpp cluster joinWe controleren op elke server of de creatie van de XMPP-cluster succesvol was met de commando's:
xmpp status
xmpp cluster statusEerste server:
Tweede server:
Derde server:
Verbinding van Call Bridge met XMPP
Nu de XMPP-cluster actief is, moeten we de Call Bridge-diensten configureren voor verbinding met de XMPP-cluster. Deze configuratie gebeurt via de webadmin.
We gaan op elke server naar Configuration > General en in het veld Unique Call Bridge name schrijven we de server-specifieke unieke namen voor Call Bridge callbridge[01,02,03]. In het veld Domein conf.example.nl en de bijbehorende wachtwoorden, die we kunnen inzien
op elke server van het cluster met het commando:
xmpp callbridge list 
Het veld 'Server' laten we leeg, Callbridge zal een DNS SRV-zoekopdracht uitvoeren voor _xmpp-component._tcp.conf.example.com, om een beschikbare XMPP-server te vinden. De IP-adressen voor de verbinding van callbridges met XMPP kunnen verschillen op elke server, afhankelijk van de waarden die worden geretourneerd bij de aanvraag per record. _xmpp-component._tcp.conf.example.com De verbinding van callbridge, wat op zijn beurt afhankelijk is van de prioriteitsinstellingen voor dit DNS-record.
Vervolgens gaan we naar Status > General om te controleren of de Call Bridge-dienst succesvol is verbonden met de XMPP-dienst.
Web Bridge
Op elke server van het cluster activeren we de Web Bridge-dienst met het commando:
webbridge listen a:443We configureren de Web Bridge-dienst met certificaatbestanden met een commando als:
webbridge certsWeb Bridge ondersteunt HTTPS. Het zal HTTP omleiden naar HTTPS, indien ingesteld voor het gebruik van 'http-redirect'.
Om HTTP-omleiding in te schakelen, gebruikt u de volgende opdracht:
webbridge http-redirect enableOm de Call Bridge te laten weten dat de Web Bridge de verbindingen van Call Bridge vertrouwt, gebruikt u het commando:
webbridge trustwaarbij dit een bestand is dat alle drie de certificaten van elke server in het cluster bevat.
Zo zou het eruit moeten zien op elke server van het cluster.
Nu moeten we een gebruiker met de rol 'appadmin' aanmaken, die we nodig hebben om ons cluster in te stellen (!), zodat niet elke server van het cluster apart moet worden ingesteld, waardoor de instellingen eenmalig op elke server worden toegepast.
Voor verdere configuratie zullen we gebruik maken van .
Voor autorisatie kiezen we Basic in de sectie Autorization
Om commando's naar de CMS-servers correct te verzenden, moet de juiste codering worden ingesteld.
Geef de Webbridges op met het commando. PUT met de parameter url en waarde.
In de webbridge zelf geven we de benodigde parameters op: gasttoegang, beveiligde toegang en andere.
Call Bridge Groups
Standaard gebruikt de CMS niet altijd de beschikbare conferentiemiddelen op de meest efficiënte manier.
Bijvoorbeeld, voor een vergadering met drie deelnemers kan elke deelnemer zich op drie verschillende Call Bridges bevinden. Om ervoor te zorgen dat deze drie deelnemers met elkaar kunnen communiceren, zullen de Call Bridges automatisch verbindingen tot stand brengen tussen alle servers en clients in dezelfde Space, zodat het lijkt alsof alle clients op dezelfde server zijn. Helaas is een nadeel hiervan dat een conferentie met 3 personen nu 9 media-poorten zal verbruiken. Dit is duidelijk een inefficiënte gebruik van middelen. Bovendien, wanneer een Call Bridge echt overbelast is, is de standaardmechanisme om blijven oproepen te accepteren en diensten met verminderde kwaliteit aan alle abonnees van deze Call Bridge te bieden.
Deze problemen worden opgelost met de functie Call Bridge Group. Deze functie werd geïntroduceerd in versie 2.1 van de Cisco Meeting Server software en is uitgebreid om load balancing voor zowel inkomende als uitgaande oproepen, de Cisco Meeting App (CMA), inclusief WebRTC-deelnemers, te ondersteunen.
Om het probleem van herverbindingen aan te pakken, zijn er drie configureerbare belastinglimieten ingevoerd voor elke Call Bridge:
LoadLimit is de maximale numerieke belasting voor een specifieke Call Bridge. Elke platform heeft een aanbevolen limiet voor de belasting, bijvoorbeeld 96000 voor CMS1000 en 1,25 GHz per virtuele processor voor de virtuele machine. Verschillende oproepen verbruiken een bepaald aantal middelen, afhankelijk van de resolutie en framesnelheid van de deelnemer.
NewConferenceLoadLimitBasisPoints (standaard 50% loadLimit) - stelt de belastinglimiet van de server in, waarna nieuwe conferenties worden afgewezen.
ExistingConferenceLoadLimitBasisPoints (standaard 80% van loadLimit) - de serverbelasting waarop deelnemers die zich bij een bestaande conferentie voegen, zullen worden afgewezen.
Deze functie is ontwikkeld voor het verdelen van oproepen en het balanceren van de belasting, maar andere groepen, zoals TURN-servers, Web Bridge-servers en opnameapparaten, kunnen ook worden toegewezen aan Call Bridge Groups, zodat ze correct kunnen worden gegroepeerd voor optimaal gebruik. Als een van deze objecten niet aan een oproepgroep is toegewezen, wordt aangenomen dat ze beschikbaar zijn voor alle servers zonder enige specifieke prioriteit.
Deze instellingen kunnen hier worden aangepast: :445/api/v1/system/configuration/cluster
We wijzen vervolgens elke callbridge toe aan welke callbridge-groep deze behoort:
Eerste callbridge
Tweede callbridge
Derde callbridge
Op deze manier hebben we een Call Bridge-groep ingesteld voor een efficiënter gebruik van de middelen van de Cisco Meeting Server-cluster.
Importeren van gebruikers uit Active Directory
De Web Admin-service heeft een configuratiegedeelte voor LDAP, maar biedt geen geavanceerde configuratieopties, en de informatie wordt niet opgeslagen in de clusterdatabase, dus de configuratie moet handmatig op elke server worden uitgevoerd via de webinterface of via de API. Om te voorkomen dat we 'drie keer moeten opstaan', zullen we de gegevens toch via de API invoeren.
Gebruikmakend van de URL om toegang te krijgen :445/api/v1/ldapServers creëren we een object voor de LDAP-server, waarbij we parameters opgeven zoals:
- IP-adres van de server
- poortnummer
- gebruikersnaam
- wachtwoord
- secure
Secure - waar of onwaar, we kiezen afhankelijk van de poort, 389 - niet beveiligd, 636 - beveiligd.
Toon LDAP-bronparameters op attributen in de Cisco Meeting Server.
De mapping van LDAP koppelt de attributen in de LDAP-directory aan de attributen in CMS. De attributen zijn:
- jidMapping
- nameMapping
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Omschrijving van de attributenJID vertegenwoordig de inlogidentificatie van de gebruiker in CMS. Aangezien dit een LDAP-server van Microsoft Active Directory is, wordt de JID van CMS gekoppeld aan sAMAccountName in LDAP, wat in wezen de inlogidentificatie is van de Active Directory-gebruiker. Merk ook op dat je sAMAccountName neemt en het domein conf.pod6.cms.lab eraan toevoegt, omdat dit de inlog is die je gebruikers zullen gebruiken om in te loggen op CMS.
nameMapping koppelt wat er in het veld Active Directory displayName staat aan het naamveld van CMS-gebruikers.
coSpaceNameMapping creëert de naam van de CMS-space op basis van het displayName-veld. Dit attribuut samen met het attribuut coSpaceUriMapping zijn wat nodig is om een space te creëren voor elke gebruiker.
coSpaceUriMapping bepaalt het gebruikersgedeelte van de URI dat verband houdt met de persoonlijke ruimte van de gebruiker. Sommige domeinen kunnen worden ingesteld voor invoer in de ruimte. Als het gebruikersgedeelte overeenkomt met dit veld voor een van deze domeinen, wordt de oproep doorgestuurd naar de ruimte van deze gebruiker.
coSpaceSecondaryUriMapping bepaalt een tweede URI om de ruimte te bereiken. Dit kan worden gebruikt om een numerieke alias toe te voegen voor het routeren van oproepen naar de ingeleverde gebruikersruimte als alternatief voor de alfanumerieke URI die is gedefinieerd in de coSpaceUriMapping-parameter.
LDAP-server en LDAP-mapping zijn ingesteld. Nu moet deze met elkaar worden verbonden door een LDAP-bron te creëren.
Gebruikmakend van de URL om toegang te krijgen :445/api/v1/ldapSource maken we een LDAP-bronobject op basis van parameters zoals:
- server
- mapping
- baseDn
- filter
Nu de LDAP-configuratie is voltooid, kan de handmatige synchronisatie worden uitgevoerd.
Dit kan ofwel in de webinterface van elke server worden gedaan door te klikken op Synchroniseer nu in de sectie Active Directory
of via de API met het commando PUT gebruikmakend van het URL-adres om toegang te krijgen :445/api/v1/ldapSyncs
Ad-Hoc conferenties
Wat is dit?In de traditionele zin is een conferentie wanneer twee deelnemers met elkaar praten en een van de deelnemers (die een apparaat gebruikt dat geregistreerd is in de Unified CM) op de knop 'Conferentie' drukt, een ander belt en na het gesprek met deze derde partij opnieuw op de knop 'Conferentie' drukt om alle deelnemers aan de driedelige conferentie aan te sluiten.
Ad-Hoc conferentie verschilt van een geplande conferentie in CMS, omdat een Ad-Hoc conferentie niet slechts een SIP-oproep voor CMS is. Wanneer de initiator van de conferentie voor de tweede keer op de knop 'Conferentie' drukt om iedereen uit te nodigen voor dezelfde bijeenkomst, moet Unified CM de API-aanroep voor CMS uitvoeren om de conferentie 'on-the-fly' te creëren, waaraan vervolgens alle oproepen worden doorgegeven. Dit alles gebeurt onopgemerkt voor de deelnemers.
Dit betekent dat Unified CM de API-referenties en het adres/poort van de WebAdmin-service moet instellen, evenals de SIP-Trunk direct op de CMS-server om de oproep voort te zetten.
Indien nodig kan CUCM dynamisch een ruimte in CMS creëren, zodat elke oproep naar CMS kan worden geleid en voldoet aan het inkomende oproepregel dat bedoeld is voor ruimtes.
Integratie met CUCM wordt ingesteld zoals beschreven in het artikel Met uitzondering van het feit dat er op Cisco UCM drie trunks voor CMS moeten worden gemaakt, drie Conference Bridges, in het SIP Security Profile drie Subject Names moeten worden opgegeven, evenals Route Group, Route List, Media Resource Group en Media Resource Group List, en in Cisco Meeting Server moeten er een paar routingregels worden toegevoegd.
SIP Security Profile:
Trunks:
Elke trunk ziet er hetzelfde uit:
Conference Bridge
Elke Conference Bridge ziet er hetzelfde uit:
Route Group
Route List
Media Resource Group
Media Resource Group List
Belregels
In tegenstelling tot meer geavanceerde call management systemen, zoals Unified CM of Expressway, bekijkt CMS voor nieuwe oproepen het domein alleen in het SIP Request-URI veld. Dus als SIP INVITE is gericht aan sip: user@domain.com, houdt CMS zich alleen bezig met domain.com. CMS volgt deze regels om te bepalen waar de oproep naartoe moet worden gestuurd:
1. Eerst probeert CMS het SIP-domein te matchen met de domeinen die zijn ingesteld in de regels voor binnenkomende oproepen. Vervolgens kunnen deze oproepen worden doorgestuurd naar ('doel') ruimtes of specifieke gebruikers, interne IVR, of rechtstreeks geïntegreerde ontvangers van Microsoft Lync/Skype voor bedrijven (S4B).
2. Als er geen overeenkomsten zijn in de regels voor binnenkomende oproepen, zal CMS proberen het domein te matchen dat is ingesteld in de tabel voor het doorsturen van oproepen. Als er een match is, kan de regel de oproep expliciet afwijzen of doorsturen. Op dat moment kan CMS het domein herschrijven, wat soms nuttig is voor oproepen naar Lync-domeinen. U kunt ook kiezen voor pass throw, wat betekent dat geen van de velden verder zal worden gewijzigd, of de interne abonnee groep van CMS gebruiken. Als er geen overeenkomsten zijn in de regels voor doorsturen van oproepen, wordt de oproep standaard afgewezen. Houd er rekening mee dat in CMS, hoewel de oproep 'doorgestuurd' is, de multimedia nog steeds wordt gebonden aan CMS, wat betekent dat het zich in het pad van signalisatie en multimedia verkeer zal bevinden.
Alleen doorgestuurde oproepen vallen onder de regels voor uitgaande oproepen. Deze parameters bepalen de ontvangers waarheen oproepen moeten worden verzonden, het type verbindingslijn (of het nu een nieuwe Lync-oproep of standaard SIP is) en eventuele conversies die kunnen worden uitgevoerd als de overdrachtsregel niet is geselecteerd.
Hier is het logboek van wat er gebeurt tijdens een Ad-Hoc-conferentie
Op de screenshot is het niet goed zichtbaar (weet niet hoe ik het beter kan doen), daarom schrijf ik het logboek als volgt:
Info 127.0.0.1:35870: API-gebruiker "api" heeft nieuwe ruimte 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012) aangemaakt.
Info oproep maken mislukt, kon coSpace niet vinden -- probeert op te halen uit database.
Info API "001036270012" Ruimte GUID: 7986bb6c-af4e-488d-9190-a75f16844e44 <--> Oproep GUID: 93bfb890-646c-4364-8795-9587bfdc55ba <--> Oproep Correlator GUID: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 <--> Interne G
Info 127.0.0.1:35872: API-gebruiker "api" heeft nieuwe oproep 93bfb890-646c-4364-8795-9587bfdc55ba aangemaakt.
Info oproep 7: inkomende SIP-oproep van "sip:672@172.x.x.x" naar lokale URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
Info API-oproep been bc0be45e-ce8f-411c-be04-594e0220c38e in oproep 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API-oproep 93bfb890-646c-4364-8795-9587bfdc55ba)
Info conferentie 434f88d0-8441-41e1-b6ee-6d1c63b5b098 heeft controle/media GUID: fb587c12-23d2-4351-af61-d6365cbd648d
Info conferentie 434f88d0-8441-41e1-b6ee-6d1c63b5b098 genaamd "001036270012"
Info oproep 7: geconfigureerd - API-oproep been bc0be45e-ce8f-411c-be04-594e0220c38e met SIP-oproep ID "7e309680-cd217a6a-f237-e88214ac@172.x.x.x"
Info oproep 7: stelt UDT RTP-sessie in voor DTLS (gecombineerde media en controle).
Info conferentie "001036270012": ongeëncrypte oproepbenen zijn nu aanwezig.
Info deelnemer "672@172.x.x.x" voegde zich toe aan ruimte 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012).
Info deelnemer "672@172.x.x.x" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) voegde zich toe aan conferentie 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP.
Info oproep 8: inkomende SIP-oproep van "sip:690@172.x.x.x" naar lokale URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
Info API-oproep been db61b242-1c6f-49bd-8339-091f62f5777a in oproep 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API-oproep 93bfb890-646c-4364-8795-9587bfdc55ba)
Info oproep 8: geconfigureerd - API-oproep been db61b242-1c6f-49bd-8339-091f62f5777a met SIP-oproep ID "7e309680-cd217a6a-f238-e88214ac@172.x.x.x"
Info oproep 8: stelt UDT RTP-sessie in voor DTLS (gecombineerde media en controle).
Info oproep 9: inkomende SIP-oproep van "sip:673@172.x.x.x" naar lokale URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
Info API-oproep been 37a6e86d-d457-47cf-be24-1dbe20ccf98a in oproep 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API-oproep 93bfb890-646c-4364-8795-9587bfdc55ba)
Info oproep 9: geconfigureerd - API-oproep been 37a6e86d-d457-47cf-be24-1dbe20ccf98a met SIP-oproep ID "7e309680-cd217a6a-f239-e88214ac@172.x.x.x"
Info oproep 9: stelt UDT RTP-sessie in voor DTLS (gecombineerde media en controle).
Info oproep 8: compenseren voor verre einde dat niet overeenkomt met payload types.
Info deelnemer "690@172.x.x.x" voegde zich toe aan ruimte 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012).
Info deelnemer "690@172.x.x.x" (289e823d-6da8-486c-a7df-fe177f05e010) voegde zich toe aan conferentie 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP.
Info oproep 7: compenseren voor verre einde dat niet overeenkomt met payload types.
Info oproep 8: niet-overeenkomende payload types modus 1/0.
Info oproep 8: antwoord op aanbieding in niet-overeenkomende payload types modus.
Info oproep 8: vervolg enkele codec aanbieding ontvangen.
Info oproep 8: niet-overeenkomende payload types modus 1/0.
Info oproep 8: antwoord op aanbieding in niet-overeenkomende payload types modus.
Info oproep 8: verzenden reactie op enkele-codec aanvullende aanbieding.
Info oproep 9: compenseren voor verre einde dat niet overeenkomt met payload types.
Info deelnemer "673@172.x.x.x" voegde zich toe aan ruimte 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012).
Info deelnemer "673@172.x.x.x" (d27e9a53-2c8a-4e9c-9363-0415cd812767) voegde zich toe aan conferentie 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP.
Info oproep 9: BFCP (clientrol) nu actief.
Info oproep 9: verzenden BFCP hallo als client na ontvangst van hallo toen BFCP niet actief was.
Info oproep 9: BFCP (clientrol) nu actief.
Info oproep 7: beëindigen; externe SIP beëindiging - verbonden voor 0:13.
Info oproep 7: vernietigen API-oproep been bc0be45e-ce8f-411c-be04-594e0220c38e.
Info deelnemer "672@x.x.x" verliet ruimte 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012).
Info oproep 9: in de wacht.
Info oproep 9: niet-overeenkomende payload types modus 1/0.
Info oproep 9: antwoord op aanbieding in niet-overeenkomende payload types modus.
Info oproep 8: in de wacht.
Info oproep 8: vervolg enkele codec aanbieding ontvangen.
Info oproep 8: niet-overeenkomende payload types modus 1/0.
Info oproep 8: antwoord op aanbieding in niet-overeenkomende payload types modus.
Info oproep 8: verzenden reactie op enkele-codec aanvullende aanbieding.
Info oproep 9: beëindigen; externe SIP beëindiging - verbonden voor 0:12.De Ad-Hoc conferentie zelf:
Regels voor binnenkomende oproepen
De configuratie van de parameters voor binnenkomende oproepen is vereist voor het ontvangen van oproepen in CMS. Zoals u hebt gezien in de LDAP-instellingen, zijn alle gebruikers geïmporteerd met het domein conf.pod6.cms.lab. Daarom wilt u in ieder geval dat oproepen naar dit domein gericht zijn op de spaces. U moet ook regels instellen voor alles wat bedoeld is voor de volledig gekwalificeerde domeinnaam (en mogelijk zelfs voor het IP-adres) van elk van de CMS-servers. In onze externe oproepcontrole, Unified CM, worden SIP-trunks ingesteld die specifiek zijn voor elke CMS-server. Afhankelijk van of de bestemming van deze SIP-trunks een IP-adres is, of de volledig gekwalificeerde domeinnaam van de server, bepaalt dit of CMS moet worden ingesteld om oproepen te ontvangen die zijn gericht op zijn IP-adres of volledig gekwalificeerde domeinnaam.
Het domein met de hoogste prioriteit voor binnenkomend verkeer wordt gebruikt als het domein voor alle gebruikersspaces. Wanneer gebruikers synchroniseren via LDAP, maakt CMS automatisch spaces aan, maar alleen het gebruikersdeel van de URI (coSpaceUriMapping), bijvoorbeeld user.space. Het deel van de volledige URI wordt gebaseerd op deze regel. In feite, als u op dit moment in de Web Bridge zou inloggen, zou u zien dat de Space URI geen domein heeft. Door deze regel als hoogste prioriteit in te stellen, stelt u het domein voor de gegenereerde spaces in als conf.example.com.
Regels voor uitgaande oproepen
Om gebruikers in staat te stellen uitgaande oproepen te doen naar de Unified CM-cluster, moeten de regels voor uitgaande verbindingen worden ingesteld. Het domein van de eindpunten die geregistreerd zijn in Unified CM, zoals Jabber, is example.com. Oproepen naar dit domein moeten als standaard SIP-oproepen naar de Unified CM-oproepverwerking nodes worden gestuurd. De primaire server is cucm-01.example.com, en als secundaire is cucm-02.example.com.
De eerste regel beschrijft de eenvoudigste oproeproutering tussen de servers van het cluster.
Veld Lokaal van domein verantwoordelijk voor wat wordt weergegeven in de SIP-URI van de beller bij de ontvanger na het symbool «@». Als we dit leeg laten, dan zal er na het symbool «@» het IP-adres van de CUCM verschijnen waar deze oproep doorheen gaat. Als we echter een domein opgeven, dan verschijnt er na het symbool «@» juist dat domein. Dit is nodig zodat het mogelijk is om terug te bellen, anders is het niet mogelijk om terug te bellen naar het SIP-URI naam@ip-adres.
Oproep wanneer opgegeven Lokaal van domein
Oproep wanneer NIE opgegeven Lokaal van domein
Vergeet niet om duidelijk Encrypted of Unencrypted op te geven, anders werken de uitgaande oproepen niet, omdat bij de parameter Auto niets werkt.
Opname
De opname van videoconferenties wordt uitgevoerd door de Record-server. Recorder is precies dezelfde als de Cisco Meeting Server. Recorder vereist geen licenties om op zichzelf te installeren. Licenties voor opname zijn vereist voor de servers waarop de CallBridge-diensten draaien, dat wil zeggen dat de Recording-licentie nodig is en moet worden toegepast op het CallBridge-component, en niet op de server waar de Recorder draait. Recorder gedraagt zich als een client van het uitbreidbare protocol voor berichtenuitwisseling en aanwezigheid (XMPP), daarom moet de XMPP-server ingeschakeld zijn op de server waar de CallBridge zich bevindt.
Aangezien we een cluster hebben en de licentie moet worden 'uitgestrekt' over alle drie de servers in het cluster. Moeten we simpelweg in ons persoonlijke account de MAC-adressen van de a-interfaces van alle CMS-servers die deel uitmaken van het cluster associëren (toevoegen).
En zo hoort het plaatje eruit te zien op elke server van het cluster
Er zijn verschillende scenario's voor het plaatsen van de Recorder, maar we zullen ons aan het volgende houden:
Voordat de Recorder wordt ingesteld, is het nodig om een plek voor te bereiden waar videoconferenties daadwerkelijk zullen worden opgenomen. Dit is eigenlijk het , hoe we de hele Recording instellen. Ik zal de aandacht vestigen op belangrijke punten en details:
1. Het is beter om het certificaat van de eerste server in het cluster aan te bieden.
2. De foutmelding «Recorder unavailable» kan optreden omdat het verkeerde certificaat in Recorder Trust is opgegeven.
3. Opname kan niet plaatsvinden als er voor de opname geen hoofdmap in NFS is opgegeven.
Soms is er behoefte om automatisch de conferentie van één specifieke gebruiker of space op te nemen.
Hiervoor worden er twee CallProfile's aangemaakt:
Met de opnamefunctie uitgeschakeld
En met de automatische opnamefunctie ingeschakeld
Vervolgens 'koppelen' we de CallProfile met automatische opnamefunctie aan de gewenste space.
In CMS is het zo geregeld dat als een CallProfile expliciet aan bepaalde ruimtes is gekoppeld, deze CallProfile alleen van toepassing is op die specifieke ruimtes. Als de CallProfile aan geen enkele ruimte is gekoppeld, wordt deze standaard toegepast op die ruimtes waaraan geen enkele CallProfile expliciet is gekoppeld.
De volgende keer zal ik proberen te beschrijven op welke manieren toegang tot CMS buiten het interne netwerk van de organisatie wordt verkregen.
Bronnen:
Bron: habr.com
