I denne udgave viser og forklarer jeg nogle nuancer ved opsætning af CMS-serveren i en fejltolerant klynge.
TeoriGenerelt er der tre typer implementering af CMS-serveren:
- Single Combined(Én kombineret), dvs. det er en server, hvor alle nødvendige tjenester kører. I de fleste tilfælde er denne implementering kun anvendelig til intern adgang og i små miljøer, hvor begrænsningerne for skalerbarhed og redundans på én server ikke er kritiske, eller i situationer hvor CMS kun udfører bestemte funktioner, såsom specialkonferencer på Cisco UCM.
En oversigt over arbejdet:
- Single Split(Én opdelt) udvider den tidligere implementeringstype ved at tilføje en separat server til ekstern adgang. I forældede implementeringer betød dette at implementere CMS-serveren i et demilitariseret netværkssegment (DMZ), hvor eksterne klienter kunne få adgang til den, og én CMS-server i kern-netværket, hvor interne klienter får adgang til CMS. Denne specifikke implementeringsmodel bliver nu udfaset til fordel for den såkaldte type Single Edge, der består af servere Cisco Expressway, som har eller vil have mange af mulighederne for at omgå firewalls, så kunderne ikke behøver at tilføje en dedikeret grænseserver til CMS.
En oversigt over arbejdet:
- Scalable and Resilient(Skalerbar og fejltolerant) denne type inkluderer redundans for hver komponent, hvilket giver systemet mulighed for at vokse med dine behov til maksimal kapacitet, samtidig med at det sikrer redundans i tilfælde af nedbrud. Det bruger også konceptet Single Edge for at sikre sikker ekstern adgang. Dette er den type, vi vil gennemgå i denne udgave. Hvis vi forstår, hvordan man implementerer en klynge af denne type, kan vi ikke kun forstå andre implementeringstyper, men også forstå, hvordan man opretter CMS-serverklynger med hensyntagen til potentielt voksende behov.
Før vi går videre til implementeringen, skal vi forstå nogle grundlæggende ting, nemlig
De vigtigste softwarekomponenter i CMS:
- Database: gør det muligt at kombinere nogle konfigurationer, såsom abonnentgrupper, brugerrum og brugerne selv. Understøtter klyngedannelse kun for høj tilgængelighed (én master).
- Call Bridge: en service til audio- og videokonferencer, der giver fuld kontrol over administration og behandling af opkald og multimedieprocesser. Understøtter klustering for høj tilgængelighed og skalerbarhed.
- XMPP-server: håndterer registrering og autentificering af kunder, der bruger Cisco Meeting Application og/eller WebRTC (real-time kommunikation, eller ganske enkelt i browseren), samt inter-komponent signalering. Kan kun klusteres for høj tilgængelighed.
- Web Bridge: giver adgang til kunder i WebRTC.
- Loadbalancer: leverer et enkelt forbindelsespunkt for Cisco Meeting App-applikationer i Single Split-tilstand. Lytter på den eksterne interface og port for indgående forbindelser. Loadbalancer modtager ligeledes indgående TLS-forbindelser fra XMPP-serveren, via hvilke den kan skifte TCP-forbindelser fra eksterne kunder.
I vores scenarie vil den ikke være nødvendig. - TURN-server: muliggør teknologi til at omgå firewallen, hvilket gør det muligt
at placere vores CMS uden for firewallen eller NAT'en for at forbinde eksterne kunder, der bruger Cisco Meeting App eller SIP-enheder. I vores scenarie vil den ikke være nødvendig. - Web Admin: administrationsgrænseflade og adgang til API, herunder for specifikke konferencer Unified CM.
Konfigurationsmetoder
I modsætning til de fleste andre Cisco-produkter understøtter Cisco Meeting Server tre metoder til opsætning, der muliggør implementering af enhver form for udrulning.
- Kommandolinje (CLI): Kommandolinjegrænseflade, kendt som MMP, til opgaver vedrørende indledende opsætning og certifikater.
- Web-administrator: primært til konfiguration relateret til CallBridge, især ved opsætning af en ikke-klusteret server.
- REST API: bruges til de mest komplekse opsætningsopgaver og opgaver relateret til kluster databasen.
Ud over ovenstående anvendes protokollen SFTP til filoverførsel - normalt licenser, certifikater eller logs - til og fra CMS-serveren.
I Cisco's deployment guides står der sort på hvidt, at et kluster skal implementeres mindst med tre servere (noder) i konteksten af databaser. Da kun et ulige antal noder vil aktivere mekanismen for valg af en ny database-master, og databasen-master har forbindelse til størstedelen af databasen på CMS-serveren.
Og som erfaringen viser, er to servere (noder) faktisk ikke helt tilstrækkeligt. Udvælgelsesmekanismen aktiveres ved genstart af Master'en, Slave-serveren bliver kun Master efter opstart af den genstartede server. Men hvis Master-serveren pludselig "slukker" i et cluster med to servere, bliver Slave-serveren ikke til Master; hvis Slave "slukker", vil den tilbageværende Master-server blive til Slave.
I konteksten af XMPP er det nødvendigt at samle et cluster af tre servere, da hvis man for eksempel deaktiverer XMPP-tjenesten på en af serverne, hvor XMPP er i lederstatus, så forbliver XMPP på den tilbageværende server i status som Follower, og forbindelserne til CallBridge til XMPP vil bryde sammen, da CallBridge kun opretter forbindelse til XMPP med lederstatus. Dette er kritisk, da ingen opkald vil gå igennem.
Der vises også et cluster med én XMPP-server i disse deploymentsvejledninger.
Og med den ovenstående forklaring bliver det klart, hvorfor: det fungerer i failover-tilstand.
I vores tilfælde vil XMPP-serveren være til stede på alle tre noder.
Det antages, at alle tre vores servere er oppe.
DNS-poster
Inden man begynder at konfigurere serverne, er det nødvendigt at oprette DNS-poster. A og SRV typer:
Bemærk, at der i vores DNS-poster er to domæner example.com og conf.example.com. Example.com er det domæne, som alle abonnenter af Cisco Unified Communication Manager kan bruge til deres URI, som højst sandsynligt findes i din infrastruktur eller med høj sandsynlighed vil gøre det. Eller domænet example.com svarer til det samme domæne, som brugerne bruger til deres e-mailadresser. Eller også kan Jabber-klienten på din bærbare computer have en URI user@example.com. Domænet conf.example.com er det domæne, der vil blive konfigureret for brugerne af Cisco Meeting Server. Domænet for Cisco Meeting Server vil være conf.example.com, så for den samme Jabber-bruger skal man bruge URI user@conf.example.com for at få adgang til Cisco Meeting Server.
Grundlæggende konfiguration
Alle indstillinger beskrevet nedenfor vises på én server, men de skal udføres på hver server i clustret.
QoS
Da CMS genererer real-time For traffic sensitive to delays and packet loss, it is generally recommended to configure Quality of Service (QoS). For this purpose, the CMS supports packet marking with Differentiated Services (DSCP) codes that it generates. Although prioritizing traffic based on DSCP depends on how the traffic is handled by the network components of your infrastructure, in our case, we will configure our CMS with a typical DSCP priority distribution based on QoS best practices.
We will enter the following commands on each server
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1AThus, all video traffic is marked AF41 (DSCP 0x22), all voice traffic is marked EF (DSCP 0x2E), while other types of low-latency traffic, such as SIP and XMPP, use AF31 (DSCP 0x1A).
Vi tjekker:
NTP
The Network Time Protocol (NTP) is essential not only for providing accurate timestamps for calls and conferences but also for verifying certificates.
We add NTP servers to your infrastructure with the following command
ntp server add In our case, there are two such servers, so there will be two commands.
Vi tjekker:
And we set the time zone for our server.
DNS
We add DNS servers in the CMS with the command:
dns add forwardzone In our case, there are two such servers, so there will be two commands.
Vi tjekker:
Network interface configuration
We configure the interface with the command:
ipv4 add / Vi tjekker:
Server Name (Hostname)
We set the server name with the command:
hostname And restart.
This completes the basic configuration.
Certifikater
TeoriCisco Meeting Server requires encrypted communication between various components, and as a result, X.509 certificates are needed for all CMS deployments. They help ensure trust in services/servers to other servers/services.
Each service requires a certificate, however, creating separate certificates for each service can lead to confusion and unnecessary complexity. Fortunately, we can generate a pair of public and private certificate keys, and then reuse them for multiple services. In our case, the same certificate will be used for the Call Bridge, XMPP server, Web Bridge, and Web Admin. Thus, it is necessary to create a pair of public and private certificate keys for each server in the cluster.
Database clustering, however, has some special requirements for certificates and therefore requires its own certificates, distinct from the certificates of other services. The CMS uses a server certificate that is similar to those used by other servers, but there is also a client certificate used for connections to the database. Database certificates are used for both authentication and encryption. Instead of providing a username and password for the client to connect to the database, it presents a client certificate that the server trusts. Each server in the database cluster will use the same pair of public and private keys. This allows all servers in the cluster to encrypt data in such a way that it can only be decrypted by other servers that also use the same key pair.
For failover to work, database clusters must consist of at least 3 servers but no more than 5, with a maximum round-trip time of 200 ms between any members of the cluster. This limit is more restrictive than for Call Bridge clustering, and thus it often becomes a limiting factor in geographically distributed deployments.
The role of the database for the CMS has a number of unique requirements. Unlike other roles, it requires a client and server certificate, where the client certificate has a specific CN field presented to the server.
The CMS uses a postgres database with one primary and several fully identical replicas. At any given time, there is only one primary database (the "database server"). The other members of the cluster are replicas or "database clients."
Et databaseklynge kræver et dedikeret servercertifikat og et klientcertifikat. De skal være underskrevet af certifikater, normalt fra et internt privat certifikationscenter. Da en hvilken som helst medlem af databaseklyngen kan blive hovedserver, skal parrene af database server- og klientcertifikater (der indeholder offentlige og private nøgler) kopieres til alle servere, så de kan acceptere identiteten af klienten eller database serveren. Derudover skal rodcertifikatet fra CA uploades for at sikre, at klient- og servercertifikaterne kan verificeres.
Så lad os formulere anmodningen om certifikatet, som vil blive brugt af alle serverens tjenester undtagen database (til dette vil der være en separat anmodning) med kommandoen:
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
I CN angiver vi et generelt navn for vores servere. For eksempel, hvis værtenavne for vores servere server01, server02, server03, så vil CN være server.example.com
Det samme gør vi på de resterende to servere, med den forskel at kommandoerne har de passende "værtsnavne".
Vi opretter to anmodninger til certifikaterne, der vil blive brugt af database-tjenesten med kommandoerne:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgreshvor dbclusterserver og dbclusterclient navnene på vores anmodninger og fremtidige certifikater, hostname1(2)(3) navnene på de tilsvarende servere.
Denne procedure udfører vi kun på én server(!), og vi uploader certifikaterne og de tilsvarende .key-filer til de andre servere.
Aktivering af klientcertifikatmode i AD CS
Desuden skal certifikaterne til hver server slås sammen til én fil.I *NIX:
cat server01.cer server02.cer server03.cer > server.cerI Windows/DOS:
copy server01.cer + server02.cer + server03.cer server.cer Og upload til hver server:
1. "Individuelt" servercertifikat.
2. Rodcertifikat (sammen med eventuelle mellemliggende hvis der er nogen).
3. Certifikaterne til databasen ("server" og "klient") og filer med .key-udvidelse, som blev dannet ved oprettelsen af anmodningen til "server"- og "klient"-certifikatet for databasen. Disse filer skal være identiske på alle servere.
4. Filen med alle tre "individuelle" certifikater.
I sidste ende skal der opnås et billede af filstrukturen som dette på hver server.
Database Cluster
Når du har alle certifikaterne uploadet til CMS-serverne, kan du konfigurere og aktivere databaseklyngen mellem de tre noder. Det første skridt er at vælge én server som hovednode i databaseklyngen og fuldføre dens opsætning.
Master Database
Det første skridt i opsætningen af database-replikation er at angive de certifikater, der skal bruges til databasen. Dette gøres med en kommando som:
database cluster certsLad os nu angive CMS, hvilken grænseflade der skal bruges til databaseklyngen med kommandoen:
database cluster localnode aDerefter initialiserer vi klynge-databasen på hovedserveren med kommandoen:
database cluster initialize
Client Database Nodes
Vi udfører den samme procedure, men i stedet for kommandoen database cluster initialize indsætter vi en kommando som:
database cluster joinhvor ip address existing master er IP-adressen på CMS-serveren, hvor clusteret blev initialized, simpelthen Master’en.
Vi tjekker, hvordan vores databaseklynge fungerer på alle serverne med kommandoen:
database cluster status
Det samme gør vi på den resterende tredje server.
Resultatet er, at vores første server fungerer som Master, mens de andre fungerer som Slaves.
Web Admin Service
Vi aktiverer web-administrationsservicen:
webadmin listen a 445Port 445 er valgt, fordi port 443 bruges til brugeradgang til webklienten.
Vi konfigurerer Web Admin-servicen med certifikatfilerne med kommandoen:
webadmin certsOg vi aktiverer Web Admin med kommandoen:
webadmin enable 
Hvis alt er i orden, vil vi få SUCCESS-linjer, der angiver, at Web Admin er korrekt konfigureret til netværket og certifikatet. Vi tjekker serviceydelsen via en webbrowser ved at indtaste adressen på webadministratoren, for eksempel: :445
Call Bridge Cluster
Call Bridge er den eneste service, der er til stede i hver CMS-implementering. Call Bridge er den primære mekanisme for konferencetelefoni. Den giver også SIP-grænseflade, så opkald kan rutes til eller fra den, for eksempel til Cisco Unified CM.
De følgende kommandoer skal udføres på hver server med de relevante certifikater.
Så:
Vi forbinder certifikaterne med Call Bridge-servicen med en kommando som:
callbridge certs []Vi binder CallBridge-servicerne til den ønskede grænseflade med kommandoen:
callbridge listen aOg vi genstarter tjenesten med kommandoen:
callbridge restart 
Nu, når vi har konfigureret Call Bridges, kan vi konfigurere Call Bridge clustering. Call Bridge clustering adskiller sig fra database- eller XMPP-klustering. Call Bridge Cluster kan understøtte fra 2 til 8 noder uden nogen begrænsninger. Det giver ikke kun redundans, men også belastningsfordeling, hvilket gør det muligt for konferencer aktivt at blive distribueret mellem Call Bridge-serverne ved hjælp af intelligent opkaldsfordeling. CMS har yderligere funktioner, Call Bridge grupper og relaterede funktioner, som kan bruges til yderligere administration.
Call Bridge clustering konfigureres primært gennem webadministrationsgrænsefladen.
Den nedenfor beskrevne procedure skal udføres på hver server i klyngen.
Så,
1. Log ind via web i Configuration > Cluster.
2. I Call Bridge identity indtaster vi det unikke navn callbridge[01,02,03] svarende til serverens navn. Disse navne er vilkårlige, men skal være unikke for denne klynge. De er beskrivende, da de angiver, at dette er identiteter for serverne [01,02,03].
3. I Clustered Call Bridges indtaster vi URL-adresserne til webadministrationen for vores servere i klusteret, [01,02,03].example.com:445 i feltet Address. Sørg for at angive porten. Du kan lade Peer link SIP-domænet stå tomt.
4. Tilføj CallBridge's certifikat for hver server til betroede certifikater, filen indeholder alle certifikaterne fra vores servere, som vi har slået sammen i denne fil i starten med en kommando som:
callbridge trust clusterOg vi genstarter tjenesten med kommandoen:
callbridge restart 
Resultatet på hver server skal se sådan ud:
XMPP Cluster
XMPP-tjenesten i CMS bruges til at håndtere al registrering og autentificering for Cisco Meeting Apps (CMA), herunder CMA WebRTC webklienten. Selve Call Bridge fungerer også som XMPP-klient til autentifikationsformål og skal derfor konfigureres som andre klienter. XMPP-fejltolerance er en funktion, der understøttes i produktionsmiljøer fra version 2.1.
De følgende kommandoer skal udføres på hver server med de relevante certifikater.
Så:
Vi forbinder certifikaterne med XMPP-tjenesten med en kommando som:
xmpp certs []Definer derefter lyttegrænsefladen med kommandoen:
xmpp listen aFor the XMPP service, a unique domain is required. This is the login for users. In other words, when a user tries to log in using the CMA application (or via the WebRTC client), they enter userID@logindomain. In our case, this will be userid@conf.example.com. Why not just example.com? In our specific deployment, we selected our Unified CM domain, which Jabber users will use in Unified CM, like example.com, so we need a different domain for CMS users to route calls to and from CMS through SIP domains.
Set up the XMPP domain using the command:
xmpp domainAnd we enable the XMPP service with the command:
xmpp enableIn the XMPP service, it is necessary to create credentials for each Call Bridge that will be used when registering with the XMPP service. These names are arbitrary (and not related to the unique names you set for call bridge clustering). On one XMPP server, you need to add three call bridges, and then enter these credentials on the other XMPP servers in the cluster, as this configuration does not fit in the clustered database. Later, we will configure each Call Bridge to use this name and secret for registration with the XMPP service.
Now we need to set up the XMPP service on the first server with three Call Bridges callbridge01, callbridge02, and callbridge03. Each account will be assigned random passwords. These will later be entered on the other Call Bridge servers to log into this XMPP server. We enter the following commands:
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03In the end, we check what we got with the command:
xmpp callbridge list 
The exact same picture should be on the other servers after the actions described below.
Next, we add the exact same settings on the remaining two servers, only with the commands
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03Be very careful when adding the secret to avoid accidentally including extra spaces.
In the end, each server should have the same picture:
Next, on all cluster servers, we specify the trust file containing all three certificates, created earlier with a command like:
xmpp cluster trustWe enable XMPP clustering mode on all cluster servers with the command:
xmpp cluster enablePå den første server i clustret starter vi oprettelsen af xmpp-clusteret med kommandoen:
xmpp cluster initializePå de øvrige servere tilføjer vi til xmpp-clusteret med kommandoen:
xmpp cluster joinVi kontrollerer på hver server, om oprettelsen af XMPP-clusteret er lykkedes med kommandoerne:
xmpp status
xmpp cluster statusFørste server:
Anden server:
Tredje server:
Forbindelse af Call Bridge til XMPP
Nu hvor XMPP-clusteret er startet, er det nødvendigt at konfigurere Call Bridge-tjenesterne til at forbinde til XMPP-clusteret. Denne konfiguration udføres via webadministratoren.
Vi går ind på hver server i Configuration > General og i feltet Unique Call Bridge name indtaster vi de server-specifikke unikke Call Bridge-navne callbridge[01,02,03]. I feltet Domæne conf.example.ru og de tilsvarende adgangskoder, som kan ses
på en hvilken som helst server i clustret med kommandoen:
xmpp callbridge list 
Feltet «Server» lader vi være tomt, Callbridge vil udføre en DNS SRV-søgning for _xmpp-component._tcp.conf.example.com, for at finde en tilgængelig XMPP-server. IP-adresserne, som Callbridge bruger til at forbinde til XMPP, kan variere på hver server, afhængig af hvilke værdier der returneres på forespørgslen til DNS-posten. _xmpp-component._tcp.conf.example.com for Callbridge, hvilket til gengæld afhænger af prioriteringsindstillingerne for denne DNS-post.
Dernæst går vi til Status > General for at sikre, at Call Bride-tjenesten er korrekt tilsluttet XMPP-tjenesten.
Web Bridge
På hver server i clustret aktiverer vi Web Bridge-tjenesten med kommandoen:
webbridge listen a:443Vi konfigurerer Web Bridge-tjenesten med certifikatfilerne med en kommando som:
webbridge certsWeb Bridge understøtter HTTPS. Den vil omdirigere HTTP til HTTPS, hvis den er konfigureret til at bruge 'http-redirect'.
For at aktivere HTTP-omdirigering skal du bruge følgende kommando:
webbridge http-redirect enableFor at lade Call Bridge vide, at Web Bridge kan stole på forbindelser fra Call Bridge, brug denne kommando:
webbridge trusthvor dette er en fil, der indeholder alle tre certifikater fra hver server i clustret.
Sådan skal det se ud på hver server i clustret.
Nu skal vi oprette en bruger med rollen 'appadmin'; vi har brug for det for at kunne konfigurere vores cluster (!), og ikke hver server i clustret individuelt, så indstillingerne anvendes ens på hver server ved kun at udføre dem én gang.
Til videre konfiguration vil vi bruge .
Til autorisation vælger vi Basic i sektionen Autorization
For correct command sending to the CMS servers, set the appropriate encoding.
Specify Webbridges with the command. POST with the parameter url og værdi
In the webbridge itself, specify the required parameters: guest access, secure access, and more.
Call Bridge Groups
By default, the CMS does not always use the available conference resources efficiently.
For example, for a meeting with three participants, each participant may end up on three different Call Bridges. To enable these three participants to communicate with each other, the Call Bridges will automatically establish connections between all servers and clients in the same Space, making it appear as if all clients are on one server. Unfortunately, the downside of this is that one conference with 3 people will now consume 9 media ports. This is clearly an inefficient use of resources. Additionally, when a Call Bridge is truly overloaded, the default mechanism is to continue accepting calls and providing services with reduced quality to all subscribers of that Call Bridge.
These issues are addressed by the Call Bridge Group feature. This feature was introduced in version 2.1 of the Cisco Meeting Server software and has been expanded to support load balancing for both incoming and outgoing calls, Cisco Meeting App (CMA), including WebRTC participants.
To address the reconnection issue, three configurable load limits have been introduced for each Call Bridge:
LoadLimit — this is the maximum numerical load for a specific Call Bridge. Each platform has a recommended load limit, such as 96000 for CMS1000 and 1.25 GHz per virtual processor for the virtual machine. Various calls consume a certain amount of resources depending on the resolution and frame rate of the participant.
NewConferenceLoadLimitBasisPoints (default 50% loadLimit) — sets the server load limit, beyond which new conferences are declined.
ExistingConferenceLoadLimitBasisPoints (default 80% of loadLimit) — the server load value, after which participants joining an existing conference will be declined.
Mens denne funktion blev udviklet til at fordele opkald og fordele belastningen, kan andre grupper, såsom TURN-servere, Web Bridge-servere og optagelsesenheder, også tildeles Call Bridge-grupper, så de også kan grupperes korrekt for optimal brug. Hvis nogen af disse objekter ikke er tildelt en opkaldsgruppe, antages det, at de er tilgængelige for alle servere uden nogen bestemt prioritet.
Disse indstillinger kan tilpasses her: :445/api/v1/system/configuration/cluster
Derefter angiver vi, hvilken callbridge hver callbridge tilhører:
Første callbridge
Anden callbridge
Tredje callbridge
Dermed har vi konfigureret en Call Bridge-gruppe for mere effektiv ressourceudnyttelse i Cisco Meeting Server-klyngen.
Importér brugere fra Active Directory
Web Admin-tjenesten har et LDAP-konfigurationsafsnit, men det tilbyder ikke avancerede konfigurationsmuligheder, og oplysningerne gemmes ikke i klyngens database, så konfigurationen skal udføres enten manuelt på hver server via webgrænsefladen eller via API'et. For at undgå unødvendige hændelser vil vi stadig angive dataene via API.
Ved at bruge URL-adressen til at få adgang til :445/api/v1/ldapServers opretter vi et LDAP Server-objekt og angiver parametre som:
- Serverens IP-adresse
- portnummer
- brugername
- adgangskode
- sikker
Sikker — true eller false vælges afhængigt af porten, 389 er usikker, 636 er sikker.
Viser LDAP-kildeparametre til attributterne i Cisco Meeting Server.
LDAP-visualisering matcher attributter i LDAP-kataloget med attributter i CMS. De faktiske attributter er:
- jidMapping
- nameMapping
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Beskrivelse af attributterJID repræsenterer brugerens login-id i CMS. Da dette er en Microsoft Active Directory LDAP-server, matches CMS JID med sAMAccountName i LDAP, som i bund og grund er brugerens login-id i Active Directory. Bemærk også, at du tager sAMAccountName og tilføjer domænet conf.pod6.cms.lab til slutningen, fordi det er den login, dine brugere vil bruge til at logge ind på CMS.
nameMapping matcher indholdet af Active Directory displayName-feltet med CMS-brugerens navn.
coSpaceNameMapping opretter et navn til space’en i CMS baseret på feltet displayName. Denne attribut sammen med attributten coSpaceUriMapping er det, der er nødvendigt for at oprette en space for hver bruger.
coSpaceUriMapping definerer den brugerdefinerede del af URI'en, der er knyttet til brugerens personlige space. Nogle domæner kan være konfigureret til at sætte i space. Hvis den brugerdefinerede del matcher dette felt for et af disse domæner, vil opkaldet blive sendt til denne brugers space.
coSpaceSecondaryUriMapping definerer en anden URI for at nå space’en. Dette kan bruges til at tilføje et numerisk alias til at rute opkald til en importerede brugers space som et alternativ til den alfanumeriske URI, der er defineret i parameteren coSpaceUriMapping.
LDAP-server og LDAP-mapping er konfigureret. Nu skal de forbindes ved at oprette en LDAP-kilde.
Ved at bruge URL-adressen til at få adgang til :445/api/v1/ldapSource opretter vi et LDAP Source-objekt ved at angive parametre som:
- server
- mapping
- baseDn
- filter
Nu hvor LDAP-konfigurationen er afsluttet, kan vi udføre en manuel synkronisering.
Dette gør vi enten i webgrænsefladen på hver server ved at klikke på Synkroniser nu i sektionen Active Directory
eller via API med kommandoen POST ved at bruge URL-adressen til at få adgang til :445/api/v1/ldapSyncs
Ad-Hoc konferencer
Hvad er det?I traditionel forstand er en konference, når to deltagere taler med hinanden, og en af deltagerne (ved hjælp af en enhed registreret i Unified CM) trykker på knappen "Konference", ringer til en anden person og efter at have talt med denne tredje part trykker igen på knappen "Konference" for at tilslutte alle deltagere i den trevejs konference.
Ad-Hoc konferencen adskiller sig fra den planlagte konference i CMS ved, at Ad-Hoc konferencen ikke blot er et SIP-opkald til CMS. Når initiatoren af konferencen trykker på knappen "Konference" en anden gang for at invitere alle til det samme møde, skal Unified CM udføre et API-opkald til CMS for at oprette konferencen "on the fly", hvortil alle opkald derefter sendes. Alt dette sker uden deltagerne bemærker det.
Det betyder, at Unified CM skal konfigurere API-legitimationsoplysningerne og adressen/porten til WebAdmin-tjenesten samt SIP-Trunken direkte på CMS-serveren for at fortsætte opkaldet.
Hvis nødvendigt kan CUCM dynamisk oprette en space i CMS, så hvert opkald kan nå frem til CMS og overholde reglen for indgående opkald, der er beregnet til spaces.
Integration med CUCM konfigureres på samme måde som beskrevet i artiklen med den undtagelse, at der på Cisco UCM skal oprettes tre trunker til CMS, tre Conference Bridges, tre Subject Names angives i SIP Security Profile, Route Group, Route List, Media Resource Group og Media Resource Group List, og der skal tilføjes nogle routingregler på Cisco Meeting Server.
SIP Security Profile:
Trunker:
Hver trunk ser ens ud:
Conference Bridge
Hver Conference Bridge ser ens ud:
Route Group
Route List
Media Resource Group
Media Resource Group List
Opkaldsregler
I modsætning til mere avancerede opkaldshåndteringssystemer som Unified CM eller Expressway, ser CMS kun på domænet i SIP Request-URI for nye opkald. Så hvis SIP INVITE er beregnet til sip: user@domain.com, er det kun domain.com, som CMS bekymrer sig om. CMS følger disse regler for at bestemme, hvor opkaldet skal dirigeres:
1. Først forsøger CMS at matche SIP-domænet med de domæner, der er konfigureret i reglerne for indkommende opkald. Disse opkald kan derefter dirigeres til ('destination') rum eller specifikke brugere, interne IVR'er eller direkte integrerede modtagere i Microsoft Lync/Skype for Business (S4B).
2. Hvis der ikke er nogen match i reglerne for indkommende opkald, forsøger CMS at matche domænet i opkaldsvideresendelses tabellen. Hvis der er et match, kan reglen eksplicit afvise opkaldet eller viderestille det. På dette tidspunkt kan CMS omdanne domænet, hvilket nogle gange er nyttigt for opkald til Lync-domæner. Du kan også vælge pass throw, hvilket betyder, at ingen af felterne vil blive yderligere ændret, eller bruge CMS interne abonnentgrupper. Hvis der ikke er nogen match i reglerne for videresendelse af opkald, anvendes som standard opkaldsafvisning. Vær opmærksom på, at selvom opkaldet er 'videresendt', forbliver multimedier knyttet til CMS, hvilket betyder, at det vil være i signalerings- og medietrafikvejen.
Kun videresendte opkald er underlagt reglerne for udgående opkald. Disse indstillinger bestemmer modtagerne, hvor opkaldene skal sendes til, typen af forbindelseslinje (om det er et nyt Lync-opkald eller standard SIP) og eventuelle transformationer, der kan udføres, hvis der ikke er valgt transmission i reglen for videresendelse af opkald.
Her er loggen over, hvad der sker under en Ad-Hoc-konference
På screenshotet er det dårligt synligt (jeg ved ikke, hvordan jeg kan gøre det bedre), derfor skriver jeg loggen sådan her:
Info 127.0.0.1:35870: API-bruger "api" oprettede nyt rum 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info opkald oprettelse fejlet med henvisning til coSpace -- forsøger at hente fra databasen
Info API "001036270012" Rum GUID: 7986bb6c-af4e-488d-9190-a75f16844e44 Call GUID: 93bfb890-646c-4364-8795-9587bfdc55ba Call Correlator GUID: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 Intern G
Info 127.0.0.1:35872: API-bruger "api" oprettede nyt opkald 93bfb890-646c-4364-8795-9587bfdc55ba
Info opkald 7: indkommende SIP-opkald fra "sip:672@172.x.x.x" til lokal URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
Info API opkald leg bc0be45e-ce8f-411c-be04-594e0220c38e i opkald 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API opkald 93bfb890-646c-4364-8795-9587bfdc55ba)
Info konference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 har kontrol/media GUID: fb587c12-23d2-4351-af61-d6365cbd648d
Info konference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 navngivet "001036270012"
Info opkald 7: konfigureret - API opkald leg bc0be45e-ce8f-411c-be04-594e0220c38e med SIP-opkald ID "7e309680-cd217a6a-f237-e88214ac@172.x.x.x"
Info opkald 7: opsætning af UDT RTP-session for DTLS (kombineret media og kontrol)
Info konference "001036270012": ukrypterede opkaldsben er nu tilgængelige
Info deltager "672@172.x.x.x" tilsluttede rum 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info deltager "672@172.x.x.x" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) tilsluttede konference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP
Info opkald 8: indkommende SIP-opkald fra "sip:690@172.x.x.x" til lokal URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
Info API opkald leg db61b242-1c6f-49bd-8339-091f62f5777a i opkald 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API opkald 93bfb890-646c-4364-8795-9587bfdc55ba)
Info opkald 8: konfigureret - API opkald leg db61b242-1c6f-49bd-8339-091f62f5777a med SIP-opkald ID "7e309680-cd217a6a-f238-e88214ac@172.x.x.x"
Info opkald 8: opsætning af UDT RTP-session for DTLS (kombineret media og kontrol)
Info opkald 9: indkommende SIP-opkald fra "sip:673@172.x.x.x" til lokal URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
Info API opkald leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a i opkald 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API opkald 93bfb890-646c-4364-8795-9587bfdc55ba)
Info opkald 9: konfigureret - API opkald leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a med SIP-opkald ID "7e309680-cd217a6a-f239-e88214ac@172.x.x.x"
Info opkald 9: opsætning af UDT RTP-session for DTLS (kombineret media og kontrol)
Info opkald 8: kompensering for fjernafsender, der ikke matcher payload-typer
Info deltager "690@172.x.x.x" tilsluttede rum 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info deltager "690@172.x.x.x" (289e823d-6da8-486c-a7df-fe177f05e010) tilsluttede konference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP
Info opkald 7: kompensering for fjernafsender, der ikke matcher payload-typer
Info opkald 8: ikke-matching payload-typer mode 1/0
Info opkald 8: svarer på tilbud i ikke-matching payload-typer mode
Info opkald 8: efterfølgende tilbud med enkelt codec modtaget
Info opkald 8: ikke-matching payload-typer mode 1/0
Info opkald 8: svarer på tilbud i ikke-matching payload-typer mode
Info opkald 8: sender svar til enkelt codec yderligere tilbud
Info opkald 9: kompensering for fjernafsender, der ikke matcher payload-typer
Info deltager "673@172.x.x.x" tilsluttede rum 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info deltager "673@172.x.x.x" (d27e9a53-2c8a-4e9c-9363-0415cd812767) tilsluttede konference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP
Info opkald 9: BFCP (klientrolle) nu aktiv
Info opkald 9: sender BFCP hej som klient efter modtagelse af hej, når BFCP ikke var aktiv
Info opkald 9: BFCP (klientrolle) nu aktiv
Info opkald 7: slutter; fjern SIP nedlukning - forbundet i 0:13
Info opkald 7: ødelægger API opkald ben bc0be45e-ce8f-411c-be04-594e0220c38e
Info deltager "672@x.x.x" forlod rum 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info opkald 9: på hold
Info opkald 9: ikke-matching payload-typer mode 1/0
Info opkald 9: svarer på tilbud i ikke-matching payload-typer mode
Info opkald 8: på hold
Info opkald 8: efterfølgende tilbud med enkelt codec modtaget
Info opkald 8: ikke-matching payload-typer mode 1/0
Info opkald 8: svarer på tilbud i ikke-matching payload-typer mode
Info opkald 8: sender svar til enkelt codec yderligere tilbud
Info opkald 9: slutter; fjern SIP nedlukning - forbundet i 0:12Selve Ad-Hoc-konferencen:
Regler for indgående opkald
Indstilling af parametre for indgående opkald er nødvendig for at muliggøre modtagelse af opkald i CMS. Som du så i LDAP-indstillingen, blev alle brugere importeret med domænet conf.pod6.cms.lab. Derfor vil du i hvert fald have, at opkald til dette domæne er beregnet til rummene. Du skal også opstille regler for alt, der er beregnet for det fulde domænenavn (og muligvis endda for IP-adressen) for hver af CMS-serverne. I vores eksterne opkaldskontrol, Unified CM, vil SIP-forbindelser blive konfigureret specifikt til hver CMS-server. Afhængigt af om destinationen for disse SIP-forbindelser er en IP-adresse, eller om det fulde domænenavn på serveren vil afgøre, om CMS skal konfigureres til at modtage opkald, der er rettet mod dens IP-adresse eller fulde domænenavn.
Domænet, der har regelen for indgående trafik med højeste prioritet, anvendes som domæne for enhver bruger-space. Når brugere synkroniseres via LDAP, opretter CMS automatisk spaces, men kun brugerdele af URI (coSpaceUriMapping), for eksempel user.space. Den del af den fulde URI oprettes baseret på denne regel. Faktisk, hvis du på dette stadium loggede ind på Web Bridge, ville du se, at Space URI ikke har noget domæne. Ved at sætte denne regel som højeste prioritet angiver du domænet for de genererede spaces som conf.example.com.
Regler for udgående opkald
For at give brugerne mulighed for at foretage udgående opkald til Unified CM-klyngen er det nødvendigt at konfigurere regler for udgående forbindelser. Domænet for de slutpunkter, der er registreret i Unified CM, såsom Jabber, er example.com. Opkald til dette domæne bør dirigeres som standard SIP-opkald til noderne i Unified CM-opkaldshåndteringen. Den primære server er cucm-01.example.com, som sekundær cucm-02.example.com.
Det første regel beskriver den mest grundlæggende opkaldsrouting mellem serverne i klyngen.
Felt Local from domain ansvarlig for, hvad der vil blive vist i SIP-URI for den, der modtager opkaldet efter symbolet «@». Hvis vi lader det være tomt, vil der efter symbolet «@» være IP-adressen på CUCM, som dette opkald passerer gennem. Hvis vi angiver et domæne, vil domænet faktisk blive vist efter symbolet «@». Dette er nødvendigt for at muliggøre opkald tilbage, ellers vil det ikke være muligt at ringe tilbage til SIP-URI navn@ip-adresse.
Opkald når angivet Local from domain
Opkald når IKKE er nævnt Local from domain
Sørg for tydeligt at angive Encrypted eller Unencrypted for udgående opkald, da parameteren Auto ellers ikke fungerer.
Optagelse
Optagelsen af videokonferencer udføres af Record-serveren. Recorderen er præcist den samme som Cisco Meeting Server. Recorder kræver ikke installation af nogen licenser. Licenser til optagelse kræves for serverne, hvor CallBridge-tjenesterne kører, det vil sige, at Recording-licensen er nødvendig og skal anvendes på komponenten CallBridge, ikke på den server, hvor Recorder er installeret. Recorder fungerer som en klient af den udvidede protokol til meddelelser og tilstedeværelse (XMPP), så XMPP-serveren skal være aktiveret på den server, hvor CallBridge er placeret.
Da vi har et cluster, skal licensen «strækkes» over alle tre servere i clusteren. Så i kundekontoen associere (tilføje) MAC-adresserne på a-grænsefladerne for alle CMS-servere, der indgår i clusteren.
Og sådan en billedskal være på hver server i clusteren
Der er faktisk flere scenarier for placeringen af Recorder, men vi vil holde os til følgende:
Før indstilling af Recorder er det nødvendigt at forberede et sted til optagelse af videokonferencer. Her er det: , hvordan man indstiller hele Recording. Jeg vil fokusere på vigtige punkter og detaljer:
1. Det er bedst at bruge certifikatet fra den første server i clusteren.
2. Fejlmeddelelsen «Recorder unavailable» kan opstå, fordi det forkerte certifikat er angivet i Recorder Trust.
3. Optagelsen kan være stoppet, hvis der ikke er angivet en rodkatalog til optagelse i NFS.
Nogle gange opstår behovet for automatisk at optage konferencen for en specifik bruger eller space.
For dette oprettes to CallProfile:
Med deaktiveret optagefunktion
Og med automatisk optagefunktion
Dernæst «tilknytter» vi CallProfile med automatisk optagefunktion til det ønskede space.
I CMS er det sådan, at hvis CallProfile er bundet til nogen space eller spaces, så fungerer denne CallProfile kun for disse specifikke space. Hvis CallProfile ikke er bundet til nogen space, så anvendes den som standard på de spaces, som ikke er bundet til nogen CallProfile.
Næste gang vil jeg forsøge at beskrive, hvilke metoder der benyttes til at få adgang til CMS uden for organisationens interne netværk.
Kilder:
Kilde: habr.com
