Cisco Meeting Server 2.5.2. Cluster in modalità Scalable and Resilient con funzionalità di registrazione delle videoconferenze

In questo episodio, mostrerò e spiegherò alcune sfumature della configurazione del server CMS in modalità cluster ad alta disponibilità.


TeoriaIn generale, esistono tre tipi di distribuzione del server CMS:

• Single Combined(Combinato Singolo), ovvero un singolo server su cui sono attivi tutti i servizi necessari. Nella maggior parte dei casi, questo tipo di distribuzione è applicabile solo per l'accesso a clienti interni e in piccole ambientazioni, dove le limitazioni di scalabilità e ridondanza di un singolo server non sono un problema critico, o in situazioni in cui il CMS svolge solo determinate funzioni, come conferenze specifiche su Cisco UCM.

  Schema di funzionamento generale:
  

• Single Split(Diviso Singolo) espande il tipo di distribuzione precedente, aggiungendo un server separato per l'accesso esterno. Nei deployment obsoleti, ciò significava distribuire un server CMS in una zona demilitarizzata della rete (DMZ), dove i clienti esterni potevano accedervi, e un server CMS nel nucleo della rete, dove i clienti interni accedevano al CMS. Questo modello specifico di distribuzione è ora superato dal cosiddetto tipo Single Edge, che consiste in server Cisco Expressway, che hanno o avranno molte delle funzionalità per eludere il firewall, quindi i clienti non devono aggiungere un server dedicato per il CMS.

  Schema di funzionamento generale:
  

• Scalabile e Resiliente(Scalabile e resistente) questo tipo include ridondanza per ogni componente, permettendo al sistema di crescere con le tue esigenze fino alla massima capacità, garantendo al contempo ridondanza in caso di guasto. Utilizza anche il concetto di Single Edge per garantire un accesso esterno sicuro. Questo è il tipo che esamineremo in questa edizione. Comprendendo come implementare un cluster di questo tipo, non solo comprenderemo altri tipi di implementazione, ma saremo anche in grado di comprendere come creare cluster di server CMS tenendo conto della potenziale crescita delle esigenze.

Prima di procedere all'implementazione, è necessario comprendere alcune nozioni di base, ovvero

Componenti software principali del CMS:

• Database: consente di raggruppare alcune configurazioni, come gruppi di abbonati, spazi utenti e utenti stessi. Supporta la clustering solo per alta disponibilità (un maestro).
• Call Bridge: un servizio per conferenze audio e video, che offre completo controllo nella gestione e nell'elaborazione delle chiamate e dei processi multimediali. Supporta la clusterizzazione per alta disponibilità e scalabilità.
• server XMPP: si occupa della registrazione e autenticazione dei clienti che utilizzano l'applicazione Cisco Meeting Application e/o WebRTC (comunicazione in tempo reale, insomma direttamente nel browser), oltre alla segnalazione intercomponent. Può essere clusterizzato solo per alta disponibilità.
• Web Bridge: fornisce accesso ai clienti in WebRTC.
• Loadbalancer: offre un unico punto di connessione per le applicazioni Cisco Meeting App in modalità Single Split. Ascolta l'interfaccia esterna e la porta per le connessioni in ingresso. Allo stesso modo, il bilanciatore di carico accetta connessioni TLS in ingresso dal server XMPP, attraverso il quale può instradare le connessioni TCP dai clienti esterni.
  Non sarà necessario nel nostro scenario.
• server TURN: fornisce la tecnologia per eludere il firewall, permettendo di
  pubblicare il nostro CMS al di fuori del firewall o del NAT per la connessione di clienti esterni che utilizzano Cisco Meeting App o dispositivi SIP. Non sarà necessario nel nostro scenario.
• Web Admin: interfaccia di amministrazione e accesso all'API, incluso per conferenze speciali Unified CM.

Modalità di configurazione

A differenza della maggior parte degli altri prodotti Cisco, Cisco Meeting Server supporta tre metodi di configurazione, consentendo di implementare qualsiasi tipo di distribuzione.

• Interfaccia a riga di comando (CLI): Interfaccia a riga di comando, nota come MMP, per compiti di inizializzazione e certificati.
• Web Administrator: principalmente per la configurazione legata a CallBridge, specialmente quando si imposta un singolo server non clusterizzato.
• REST API: utilizzato per le attività di configurazione più complesse e per attività legate al database cluster.

Oltre a quanto sopra, viene utilizzato il protocollo SFTP per il trasferimento di file — solitamente licenze, certificati o registri — sul server CMS e viceversa.

Nelle guide di distribuzione di Cisco è chiaramente indicato che un cluster deve essere implementato con almeno tre server (nodi) nel contesto dei database. Infatti, solo con un numero dispari di nodi funzionerà il meccanismo di selezione di un nuovo Master del database, e in generale il Master del database ha una connessione con la maggior parte del database del server CMS.

Come dimostra la pratica, avere solo due server (nodi) non è davvero sufficiente. Il meccanismo di selezione si attiva durante il riavvio del Master; il server Slave diventa Master solo dopo l'avvio del server riavviato. Tuttavia, se nel cluster ci sono due server e il server Master si spegne, il server Slave non diventerà Master; se invece si spegne il Slave, l'unico server Master diventerà Slave.

Nel contesto di XMPP, è davvero necessario creare un cluster di tre server, poiché se, ad esempio, si disattiva il servizio XMPP su uno dei server in cui XMPP è nello stato di Leader, l'altro server rimarrà in stato di Follower e le connessioni di CallBridge a XMPP verranno interrotte, poiché CallBridge si connette solo a XMPP in stato di Leader. Questo è critico, perché nessuna chiamata passerà.

In queste stesse guide di deployment, viene mostrato un cluster con un solo server XMPP.

Tenendo conto di quanto sopra, diventa chiaro perché: funziona solo in modalità failover.

Nel nostro caso, il server XMPP sarà presente su tutti e tre i nodi.

Si presume che tutti e tre i nostri server siano attivi.

Record DNS

Prima di iniziare la configurazione dei server, è necessario creare i record DNS. E e SRV tipi:

Si noti che nei nostri record DNS sono presenti due domini example.com e conf.example.com. Example.com è il dominio che possono utilizzare per i propri URI tutti gli abbonati a Cisco Unified Communication Manager, il quale è probabilmente presente nella vostra infrastruttura o lo sarà con alta probabilità. Oppure il dominio example.com corrisponde a quello stesso dominio utilizzato dagli utenti per i propri indirizzi email. Inoltre, il client Jabber sul vostro computer portatile può avere l'URI user@example.com. Il dominio conf.example.com è quello che sarà configurato per gli utenti del Cisco Meeting Server. Il dominio del Cisco Meeting Server sarà conf.example.com, quindi per lo stesso utente Jabber per accedere al Cisco Meeting Server, sarà necessario utilizzare l'URI user@conf.example.com.

Configurazione di base

Tutte le impostazioni descritte di seguito sono indicate su un server, ma devono essere eseguite su ciascun server del cluster.

QoS

Poiché CMS genera real-time Il traffico sensibile alla latenza e alla perdita di pacchetti dovrebbe, nella maggior parte dei casi, essere gestito con un servizio di Quality of Service (QoS). Per questo CMS supporta l'etichettatura dei pacchetti con i codici dei servizi differenziati (DSCP) che genera. Anche se la priorità del traffico basata sui DSCP dipende da come il traffico viene gestito dai componenti di rete della tua infrastruttura, nel nostro caso configureremo il nostro CMS con una distribuzione dei priorità DSCP tipica, basata sulle migliori pratiche del QoS.

Su ogni server eseguiremo i seguenti comandi

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

In questo modo, tutto il traffico video sarà etichettato AF41 (DSCP 0x22), tutto il traffico vocale sarà etichettato EF (DSCP 0x2E), mentre altri tipi di traffico a bassa latenza, come SIP e XMPP, utilizzeranno AF31 (DSCP 0x1A).

Controllando:

NTP

Il protocollo di rete per il tempo (NTP) è importante non solo per garantire marcature temporali accurate per le chiamate e le conferenze, ma anche per la verifica dei certificati.

Aggiungiamo i server NTP alla tua infrastruttura con un comando del tipo

ntp server add

Nel nostro caso, ci sono due di questi server, quindi ci saranno due comandi.
Controllando:

E impostiamo il fuso orario per il nostro server

DNS

I server DNS vengono aggiunti in CMS con il comando di tipo:

dns add forwardzone

Nel nostro caso, ci sono due di questi server, quindi ci saranno due comandi.
Controllando:

Configurazione dell'interfaccia di rete

Configuriamo l'interfaccia con un comando di tipo:

ipv4  add 
/

Controllando:

Nome del server (Hostname)

Impostiamo il nome del server con un comando di tipo:

hostname

E riavviamo.


A questo punto, la configurazione di base è completata.

I certificati

TeoriaCisco Meeting Server richiede connessioni criptate tra i vari componenti, e di conseguenza, i certificati X.509 sono necessari per tutte le implementazioni CMS. Questi certificati aiutano a stabilire la fiducia nei servizi/server da parte di altri server/servizi.

È necessario un certificato per ciascun servizio, tuttavia, creare certificati separati per ogni servizio può portare a confusione e complessità superflua. Fortunatamente, possiamo generare una coppia di chiavi pubbliche e private del certificato e poi riutilizzarle per più servizi. Nel nostro caso, lo stesso certificato sarà utilizzato per Call Bridge, server XMPP, Web Bridge e Web Admin. Pertanto, è necessario creare una coppia di chiavi pubbliche e private del certificato per ogni server nel cluster.

La clusterizzazione del database ha requisiti particolari per i certificati, pertanto richiede certificati propri, diversi da quelli delle altre servizi. Il CMS utilizza un certificato del server simile a quelli usati da altri server, ma esiste anche un certificato del cliente, utilizzato per le connessioni al database. I certificati del database vengono utilizzati sia per l'autenticazione che per la crittografia. Invece di fornire un nome utente e una password per connettere il cliente al database, viene presentato un certificato del cliente di cui il server si fida. Ogni server nel cluster del database utilizzerà la stessa coppia di chiavi pubblica e privata. Questo consente a tutti i server nel cluster di crittografare i dati in modo tale che possano essere decifrati solo da altri server che utilizzano la stessa coppia di chiavi.

Per garantire il funzionamento del sistema di failover, i cluster del database devono essere composti da un minimo di 3 server e un massimo di 5, con un tempo di latenza massimo di 200 ms tra i membri del cluster. Questo limite è più restrittivo rispetto alla clusterizzazione di Call Bridge e quindi spesso rappresenta un fattore limitante nelle distribuzioni geograficamente disperse.

Il ruolo del database per il CMS presenta una serie di requisiti unici. A differenza di altri ruoli, richiede un certificato sia per il client che per il server, in cui il certificato del client deve avere un campo CN specifico che viene presentato al server.

Il CMS utilizza un database Postgres con un nodo principale e diverse repliche completamente identiche. In un dato momento, esiste solo un database principale (il "server del database"). Gli altri membri del cluster sono repliche o "clienti del database".

Per un cluster di database sono necessari un certificato del server dedicato e un certificato del cliente. Devono essere firmati da certificati, solitamente da un'autorità di certificazione privata interna. Poiché qualsiasi membro del cluster di database può diventare primario, le coppie di certificati del server del database e del cliente (contenenti chiavi pubbliche e private) devono essere copiate su tutti i server, in modo che possano accettare l'identità del cliente o del server del database. Inoltre, il certificato radice della CA deve essere caricato per garantire che i certificati del cliente e del server possano essere verificati.

Ora generiamo la richiesta per il certificato che sarà utilizzato da tutti i servizi del server ad eccezione di database (per questo ci sarà una richiesta separata) con il comando:

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

Nel CN scriviamo il nome generico dei nostri server. Ad esempio, se i nomi host dei nostri server sono server01, server02, server03, quindi il CN sarà server.example.com

Facciamo lo stesso sugli altri due server con la differenza che i comandi conterranno i rispettivi "hostname".

Formiamo due richieste per i certificati che verranno utilizzati dal servizio database con comandi del tipo:

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

pki csr dbclusterclient CN:postgres

dove dbclusterserver e dbclusterclient i nomi delle nostre richieste e futuri certificati, hostname1(2)(3) i nomi dei server corrispondenti.

Questa procedura viene eseguita solo su un server(!), e caricheremo i certificati e i relativi file .key sui server aggiuntivi.

Attivazione della modalità certificato client in AD CS

È inoltre necessario unire in un unico file i certificati per ciascun serverIn *NIX:

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

In Windows/DOS:

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

E caricare su ogni server:
1. Il certificato 'individuale' del server.
2. Il certificato radice (insieme ai certificati intermedi, se presenti).
3. I certificati per il database ('server' e 'client') e i file con estensione .key, generati durante la creazione della richiesta per il certificato 'server' e 'client' nel database. Questi file devono essere identici su tutti i server.
4. Il file contenente tutti e tre i certificati 'individuali'.

Alla fine, dovremmo avere un'immagine dei file simile su ogni server.

Cluster di Database

Ora che hai caricato tutti i certificati sui server CMS, puoi configurare e attivare la clustering del database tra i tre nodi. Il primo passo è selezionare un server come nodo principale del cluster di database e configurarlo completamente.

Database Master

Il primo passo per configurare la replica del database è specificare i certificati da utilizzare per il database. Questo si fa con un comando del tipo:

database cluster certs

Ora indichiamo al CMS quale interfaccia utilizzare per il clustering dei database con il comando:

database cluster localnode a

Poi inizializziamo il database del cluster sul server principale con il comando:

database cluster initialize

Nodi Database Client

Ripetiamo la stessa procedura, solo che invece del comando database cluster initialize inseriamo un comando del tipo:

database cluster join

dove l'ip address existing master è l'indirizzo IP del server CMS su cui è stata effettuata l'inizializzazione del cluster, comunemente chiamato Master.

Controlliamo come funziona il nostro cluster di database su tutti i server con il comando:

database cluster status

Lo stesso lo facciamo sul terzo server rimanente.

Di conseguenza, il nostro primo server è il Master, mentre gli altri sono Slave.

Servizio Web Admin

Attiviamo il servizio web admin:

webadmin listen a 445

La porta 445 è stata scelta perché la porta 443 è utilizzata per l'accesso degli utenti al web client.

Configuriamo il servizio Web Admin con i file di certificato utilizzando un comando del tipo:

webadmin certs

E attiviamo Web Admin con il comando:

webadmin enable

Se tutto va bene, riceveremo le righe SUCCESS, che indicano che Web Admin è correttamente configurato per la rete e il certificato. Verifichiamo il funzionamento del servizio tramite un browser web inserendo l'indirizzo del web admin, ad esempio: cms.example.com:445

Call Bridge Cluster

Il Call Bridge è l'unico servizio presente in ogni distribuzione CMS. Il Call Bridge è il principale meccanismo di conferenza. Fornisce anche un'interfaccia SIP, in modo che le chiamate possano essere instradate verso di esso o da esso, ad esempio tramite Cisco Unified CM.

I comandi descritti di seguito devono essere eseguiti su ogni server con i rispettivi certificati.
Quindi:

Colleghiamo i certificati al servizio Call Bridge con un comando del tipo:

callbridge certs  []

Colleghiamo i servizi CallBridge all'interfaccia desiderata con il comando:

callbridge listen a

E riavviamo il servizio con il comando:

callbridge restart

Ora che abbiamo configurato i Call Bridge, possiamo impostare il clustering del Call Bridge. Il clustering del Call Bridge è diverso da quello di un database o di XMPP. Un cluster di Call Bridge può supportare da 2 a 8 nodi senza alcuna restrizione. Non solo fornisce ridondanza, ma anche bilanciamento del carico, consentendo alle conferenze di essere attivamente distribuite tra i server Call Bridge tramite una distribuzione intelligente delle chiamate. Il CMS ha funzionalità aggiuntive, gruppi di Call Bridge e funzioni correlate che possono essere utilizzate per una gestione ulteriore.

Il clustering del Call Bridge viene configurato principalmente tramite l'interfaccia del web amministratore.
La procedura descritta di seguito deve essere eseguita su ogni server del cluster.
Quindi,

1. Accedere tramite web in Configurazione > Cluster.
2. In Identità Call Bridge inseriamo come nome unico callbridge[01,02,03] corrispondente al nome del server. Questi nomi sono arbitrari, ma devono essere unici per questo cluster. Hanno una natura descrittiva, poiché indicano che si tratta di identificatori dei server [01,02,03].
3.V Clustered Call Bridges inseriamo gli URL delle interfacce web di amministrazione dei nostri server nel cluster, cms[01,02,03].example.com:445, nel campo Address. Assicurati di specificare la porta. Puoi lasciare vuoto il campo Peer link SIP domain.
4. Aggiungiamo al CallBridge di ogni server il certificato, il cui file contiene tutti i certificati dei nostri server che abbiamo unito in questo file all'inizio, con un comando del tipo:

callbridge trust cluster

E riavviamo il servizio con il comando:

callbridge restart

Il risultato su ogni server dovrebbe apparire come segue:

XMPP Cluster

Il servizio XMPP in CMS viene utilizzato per gestire tutta la registrazione e l'autenticazione per le Cisco Meeting Apps (CMA), incluso il client web CMA WebRTC. Anche il Call Bridge agisce come cliente XMPP per scopi di autenticazione e deve quindi essere configurato come gli altri client. La tolleranza agli errori di XMPP è una funzione supportata in ambienti di produzione a partire dalla versione 2.1.

I comandi descritti di seguito devono essere eseguiti su ogni server con i rispettivi certificati.
Quindi:

Colleghiamo i certificati al servizio XMPP con il comando:

xmpp certs  []

Poi definisci l'interfaccia di ascolto con il comando:

xmpp listen a

Per il servizio XMPP è necessario un dominio unico. Questo è il login per gli utenti. In altre parole, quando un utente tenta di accedere tramite l'app CMA (o attraverso un client WebRTC), inserisce userID@logindomain. Nel nostro caso, sarà userid@conf.example.com. Perché non semplicemente example.com? Nel nostro specifico deployment abbiamo scelto il nostro dominio Unified CM, che gli utenti Jabber utilizzeranno in Unified CM, come example.com, quindi abbiamo bisogno di un altro dominio per gli utenti CMS per instradare le chiamate in CMS e da CMS attraverso i domini SIP.

Configura il dominio XMPP con il comando:

xmpp domain

E abilitiamo il servizio XMPP con il comando:

xmpp enable

Nel servizio XMPP è necessario creare delle credenziali per ogni Call Bridge che verranno utilizzate per la registrazione nel servizio XMPP. Questi nomi sono arbitrari (e non collegati a nomi unici che avete configurato per la clustering dei ponti di chiamata). Su un server XMPP si devono aggiungere tre ponti di chiamata, e poi inserire queste credenziali sugli altri server XMPP nel cluster, poiché questa configurazione non viene memorizzata nel database del cluster. In seguito configureremo ogni Call Bridge per utilizzare questo nome e segreto per la registrazione nel servizio XMPP.

Ora dobbiamo configurare il servizio XMPP sul primo server con tre Call Bridge: callbridge01, callbridge02 e callbridge03. A ciascun account verranno assegnate delle password casuali. In seguito saranno inserite sugli altri server Call Bridge per accedere a questo server XMPP. Inseriamo i seguenti comandi:

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

Alla fine verifichiamo cosa è stato creato con il comando:

xmpp callbridge list

La stessa configurazione deve apparire sugli altri server dopo le azioni descritte di seguito.

Successivamente aggiungiamo sugli altri due server esattamente le stesse impostazioni, solo con i comandi

xmpp callbridge aggiungi-segreto callbridge01
xmpp callbridge aggiungi-segreto callbridge02
xmpp callbridge aggiungi-segreto callbridge03

Aggiungiamo il segreto con molta attenzione, per evitare che ad esempio ci siano spazi extra.


Alla fine, su ogni server dovrebbe esserci la stessa situazione:

Successivamente, su tutti i server del cluster indichiamo il file fidato contenente tutti e tre i certificati, creato in precedenza con il comando:

xmpp cluster trust

Attiviamo la modalità xmpp cluster su tutti i server del cluster con il comando:

xmpp cluster enable

Sul primo server del cluster, iniziamo la creazione del cluster xmpp con il comando:

xmpp cluster initialize

Sugli altri server aggiungiamo al cluster xmpp con il comando:

xmpp cluster join

Verifichiamo su ogni server il successo della creazione del cluster XMPP con i comandi:

xmpp status
xmpp cluster status

Primo server:

Secondo server:

Terzo server:

Collegamento Call Bridge a XMPP

Ora che il cluster XMPP è attivo, è necessario configurare i servizi Call Bridge per connettersi al cluster XMPP. Questa configurazione avviene tramite l'amministratore web.

Accediamo su ogni server a Configuration > General e nel campo Nome Call Bridge unico scriviamo i nomi unici di Call Bridge corrispondenti al server callbridge[01,02,03]. Nel campo Dominio conf.example.it e le relative password, è possibile visualizzarle
su qualsiasi server del cluster con il comando:

xmpp callbridge list

Lasciamo vuoto il campo "Server", Callbridge eseguirà una ricerca DNS SRV per _xmpp-component._tcp.conf.example.com, per trovare un server XMPP disponibile. Gli indirizzi IP di connessione delle callbridge a XMPP possono variare su ciascun server, a seconda dei valori restituiti dalla query per il record _xmpp-component._tcp.conf.example.com a callbridge, che a sua volta dipende dalle impostazioni delle priorità per questo record DNS.

Successivamente, andiamo a Status > General, per assicurarci che il servizio Call Bride sia connesso correttamente al servizio XMPP.

Web Bridge

Su ogni server del cluster attiviamo il servizio Web Bridge con il comando:

webbridge listen a:443

Configuriamo il servizio Web Bridge con i file dei certificati utilizzando un comando del tipo:

webbridge certs

Web Bridge supporta HTTPS. Redirigerà HTTP su HTTPS, se configurato per utilizzare «http-redirect».
Per abilitare il reindirizzamento HTTP, usa il seguente comando:

webbridge http-redirect enable

Per far capire a Call Bridge che Web Bridge può fidarsi delle connessioni da Call Bridge, usa il comando:

webbridge trust

dove questo è il file che contiene tutti e tre i certificati di ogni server del cluster.

Questa immagine dovrebbe essere presente su ogni server del cluster.


Ora dobbiamo creare un utente con il ruolo di «appadmin», necessario per configurare il nostro cluster(!) e non ogni server del cluster singolarmente, in modo che le impostazioni vengano applicate in modo uniforme a ciascun server, poiché verranno eseguite una sola volta.


Per ulteriori configurazioni utilizzeremo Postman.

Per l'autenticazione, selezioniamo Basic nella sezione Autorizzazione

Per inviare correttamente i comandi ai server CMS, è necessario impostare la codifica corretta

Indichiamo Webbridge con il comando POST con il parametro url e valore cms.example.com



Nel webbridge stesso indichiamo i parametri richiesti: accesso guest, accesso protetto e altro.

Call Bridge Groups

Per impostazione predefinita, il CMS non utilizza sempre in modo ottimale le risorse disponibili per la conferenza.

Ad esempio, per una riunione con tre partecipanti, ogni partecipante può trovarsi su tre diversi Call Bridge. Affinché questi tre partecipanti possano comunicare tra loro, i Call Bridge stabiliranno automaticamente connessioni tra tutti i server e i clienti nello stesso Space, in modo che sembri che tutti i clienti siano su un unico server. Sfortunatamente, questo comporta che una conferenza di 3 persone now consumerà 9 porte multimediali. È chiaramente un uso inefficiente delle risorse. Inoltre, quando un Call Bridge è realmente sovraccarico, il meccanismo predefinito è continuare a ricevere chiamate e fornire servizi con qualità ridotta a tutti gli abbonati di quel Call Bridge.

Questi problemi vengono risolti con la funzione Call Bridge Group. Questa funzione è stata introdotta nella versione 2.1 del software Cisco Meeting Server e ampliata per supportare il bilanciamento del carico sia per le chiamate in entrata che in uscita, Cisco Meeting App (CMA), inclusi i partecipanti WebRTC.

Per risolvere il problema del riavvio, sono stati introdotti tre limiti di carico configurabili per ogni Call Bridge:

LoadLimit — è il valore numerico massimo per un determinato Call Bridge. Ogni piattaforma ha un valore di carico massimo raccomandato, ad esempio 96000 per CMS1000 e 1,25 GHz per un processore virtuale per la macchina virtuale. Le diverse chiamate consumano una certa quantità di risorse a seconda della risoluzione e del frame rate del partecipante.
NewConferenceLoadLimitBasisPoints (default 50% loadLimit) — imposta il limite di carico del server oltre il quale le nuove conferenze vengono rifiutate.
ExistingConferenceLoadLimitBasisPoints (default 80% del loadLimit) — valore di carico del server oltre il quale i partecipanti che si uniscono a una conferenza esistente saranno rifiutati.

Sebbene questa funzione sia stata progettata per distribuire le chiamate e il carico, altri gruppi come i server TURN, i server Web Bridge e i dispositivi di registrazione possono anche essere assegnati ai gruppi Call Bridge, in modo che possano essere correttamente raggruppati per un utilizzo ottimale. Se uno di questi oggetti non è assegnato a un gruppo di chiamata, si presume che siano disponibili a tutti i server senza alcuna priorità specifica.

Questi parametri possono essere configurati qui: cms.example.com:445/api/v1/system/configuration/cluster

Successivamente, specifichiamo a quale gruppo di callbridge appartiene ogni callbridge:

Primo callbridge

Secondo callbridge

Terzo callbridge


In questo modo abbiamo configurato il gruppo Call Bridge per un utilizzo più efficiente delle risorse del Cisco Meeting Server.

Importa utenti da Active Directory

Il servizio Web Admin ha una sezione di configurazione LDAP, ma non fornisce opzioni di configurazione avanzate e le informazioni non vengono salvate nel database del cluster, quindi la configurazione dovrà essere eseguita manualmente su ciascun server tramite l'interfaccia Web o tramite API, e per evitare di ripetere il lavoro, utilizzeremo comunque l'API.

Utilizzando l'URL per accedere cms01.example.com:445/api/v1/ldapServers creiamo un oggetto LDAP Server specificando parametri come:

• Indirizzo IP del server
• numero di porta
• nome utente
• password
• sicuro

Sicuro — true o false, a seconda della porta: 389 — non sicura, 636 — sicura.


Mappiamo i parametri LDAP sulle proprietà nel Cisco Meeting Server.
La mappatura LDAP associa gli attributi nel catalogo LDAP con gli attributi nel CMS. Gli attributi in questione sono:

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Descrizione degli attributiJID rappresenta l'identificatore di accesso dell'utente nel CMS. Poiché si tratta di un server LDAP Microsoft Active Directory, il JID CMS è associato a sAMAccountName in LDAP, che è essenzialmente l'identificatore di accesso dell'utente in Active Directory. Tieni presente che prendi sAMAccountName e aggiungi il dominio conf.pod6.cms.lab alla fine, poiché questo è il login che i tuoi utenti utilizzeranno per accedere al CMS.

nameMapping associa ciò che è contenuto nel campo displayName di Active Directory al campo nome dell'utente CMS.

coSpaceNameMapping crea il nome dello space CMS sulla base del campo displayName. Questo attributo, insieme all'attributo coSpaceUriMapping, è ciò che è necessario per creare lo space per ogni utente.

coSpaceUriMapping definisce la parte utente dell'URI associata allo space personale dell'utente. Alcuni domini possono essere configurati per l'inserimento nello space. Se la parte utente corrisponde a questo campo per uno di questi domini, la chiamata sarà indirizzata allo space di quell'utente.

coSpaceSecondaryUriMapping definisce un secondo URI per raggiungere lo spazio. Può essere utilizzato per aggiungere un alias numerico per instradare le chiamate nello spazio dell'utente importato, come alternativa all'URI alfanumerico definito nel parametro coSpaceUriMapping.

Il server LDAP e la mappatura LDAP sono configurati. Ora è necessario collegarli insieme creando una sorgente LDAP.

Utilizzando l'URL per accedere cms01.example.com:445/api/v1/ldapSource creiamo l'oggetto LDAP Source, specificando parametri come:

• server
• mapping
• baseDn
• filter

Ora che la configurazione LDAP è completata, è possibile eseguire l'operazione di sincronizzazione manuale.

Facciamo questo o nell'interfaccia Web di ciascun server cliccando su Sync now nella sezione Active Directory


oppure tramite l'API con il comando POST utilizzando l'URL per accedere cms01.example.com:445/api/v1/ldapSyncs

Ad-Hoc conference

Cos'è?Nel concetto tradizionale, una conferenza è quando due partecipanti parlano tra di loro e uno dei partecipanti (utilizzando un dispositivo registrato in Unified CM) preme il pulsante "Conferenza", chiama un'altra persona e, dopo aver parlato con questo terzo, preme di nuovo il pulsante "Conferenza" per unirsi a tutti i partecipanti della conferenza a tre.

Una conferenza Ad-Hoc si distingue da una conferenza pianificata nel CMS in quanto non è semplicemente una chiamata SIP per il CMS. Quando l'iniziatore della conferenza preme il pulsante "Conferenza" per la seconda volta per invitare tutti a una stessa riunione, il Unified CM deve eseguire una chiamata API per il CMS per creare una conferenza "al volo", alla quale vengono poi trasferite tutte le chiamate. Tutto questo avviene senza che i partecipanti se ne accorgano.

Ciò significa che il Unified CM deve configurare le credenziali API e l'indirizzo / porta WebAdmin del servizio, così come il SIP-Trunk direttamente sul server CMS per continuare la chiamata.

Se necessario, il CUCM può creare dinamicamente uno spazio nel CMS affinché ogni chiamata possa raggiungere il CMS e soddisfare la regola delle chiamate in ingresso destinata agli spazi.

Integrazione con CUCM è impostata come descritto nell'articolo in precedenza eccetto che su Cisco UCM è necessario creare tre trunk per CMS, tre Conference Bridge, specificare tre Subject Name nel SIP Security Profile, Route Group, Route List, Media Resource Group e Media Resource Group List, e aggiungere alcune regole di instradamento su Cisco Meeting Server.

SIP Security Profile:


Trunk:


Ogni trunk appare identico:




Conference Bridge


Ogni Conference Bridge appare identico:


Gruppo di Route


Elenco delle Route


Gruppo di Risorse Multimediali


Elenco del Gruppo di Risorse Multimediali

Regole di Chiamata

A differenza dei sistemi di gestione delle chiamate più avanzati, come Unified CM o Expressway, per le nuove chiamate CMS esamina il dominio solo nel campo SIP Request-URI. Quindi, se SIP INVITE è destinato a sip:user@domain.com, CMS si occupa solo di domain.com. CMS segue queste regole per determinare dove indirizzare la chiamata:

1. Inizialmente, CMS cerca di abbinare il dominio SIP con i domini configurati nelle regole di elaborazione delle chiamate in arrivo. Dopodiché, queste chiamate possono essere dirette a spazi ('target') specifici o a utenti, IVR interni o destinatari integrati direttamente come Microsoft Lync/Skype for Business (S4B).
2. Se non ci sono corrispondenze nelle regole di gestione delle chiamate in ingresso, il CMS cercherà di abbinare il dominio configurato nella tabella di inoltro delle chiamate. Se viene stabilito un abbinamento, la regola può esplicitamente rifiutare la chiamata o inoltrarla. In questo momento, il CMS può riscrivere il dominio, il che è talvolta utile per le chiamate verso domini Lync. Puoi anche scegliere l'opzione pass throw, che significa che nessun campo sarà ulteriormente modificato, oppure utilizzare un gruppo di abbonati interni del CMS. Se non ci sono corrispondenze nelle regole di inoltro delle chiamate, per impostazione predefinita viene utilizzato il rifiuto della chiamata. Tieni presente che nel CMS, sebbene la chiamata sia "inoltrata", i multimedia sono ancora vincolati al CMS, il che significa che sarà in transito nel segnale e nel traffico multimediale.
Solo le chiamate inoltrate sono soggette alle regole delle chiamate in uscita. Queste opzioni definiscono i destinatari verso cui inviare le chiamate, il tipo di linea di connessione (sia essa una nuova chiamata Lync o un SIP standard) e qualsiasi trasformazione che può essere effettuata se nella regola di inoltro delle chiamate non è selezionato il passaggio.

Ecco il log di ciò che accade durante la conferenza Ad-Hoc

Sul screenshot si vede male (non so come fare meglio), quindi scriverò il log così:

Info	127.0.0.1:35870: Utente API "api" ha creato un nuovo spazio 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	richiama la creazione non riuscita a trovare coSpace -- tentativo di recupero dal database

Info	API "001036270012" GUID Spazio: 7986bb6c-af4e-488d-9190-a75f16844e44  GUID Chiamata: 93bfb890-646c-4364-8795-9587bfdc55ba  GUID Correlatore Chiamata: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66  Interno G

Info	127.0.0.1:35872: Utente API "api" ha creato una nuova chiamata 93bfb890-646c-4364-8795-9587bfdc55ba

Info	chiamata 7: chiamata SIP in arrivo da "sip:672@172.x.x.x" a URI locale "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"

Info	leg della chiamata API bc0be45e-ce8f-411c-be04-594e0220c38e nella chiamata 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (chiamata API 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	conferenza 434f88d0-8441-41e1-b6ee-6d1c63b5b098 ha GUID di controllo/media: fb587c12-23d2-4351-af61-d6365cbd648d

Info	conferenza 434f88d0-8441-41e1-b6ee-6d1c63b5b098 denominata "001036270012"

Info	chiamata 7: configurata - leg della chiamata API bc0be45e-ce8f-411c-be04-594e0220c38e con ID chiamata SIP "7e309680-cd217a6a-f237-e88214ac@172.x.x.x"

Info	chiamata 7: configurazione della sessione RTP UDT per DTLS (media e controllo combinati)
Info	conferenza "001036270012": leg delle chiamate non crittografate ora presenti

Info	partecipante "672@172.x.x.x" ha partecipato allo spazio 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	partecipante "672@172.x.x.x" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) ha partecipato alla conferenza 434f88d0-8441-41e1-b6ee-6d1c63b5b098 tramite SIP

Info	chiamata 8: chiamata SIP in arrivo da "sip:690@172.x.x.x" a URI locale "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"

Info	leg della chiamata API db61b242-1c6f-49bd-8339-091f62f5777a nella chiamata 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (chiamata API 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	chiamata 8: configurata - leg della chiamata API db61b242-1c6f-49bd-8339-091f62f5777a con ID chiamata SIP "7e309680-cd217a6a-f238-e88214ac@172.x.x.x"

Info	chiamata 8: configurazione della sessione RTP UDT per DTLS (media e controllo combinati)

Info	chiamata 9: chiamata SIP in arrivo da "sip:673@172.x.x.x" a URI locale "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"

Info	leg della chiamata API 37a6e86d-d457-47cf-be24-1dbe20ccf98a nella chiamata 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (chiamata API 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	chiamata 9: configurata - leg della chiamata API 37a6e86d-d457-47cf-be24-1dbe20ccf98a con ID chiamata SIP "7e309680-cd217a6a-f239-e88214ac@172.x.x.x"

Info	chiamata 9: configurando la sessione RTP UDT per DTLS (media e controllo combinati)
Info	chiamata 8: compensazione per il lato remoto che non corrisponde ai tipi di payload

Info	partecipante "690@172.x.x.x" ha partecipato allo spazio 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	partecipante "690@172.x.x.x" (289e823d-6da8-486c-a7df-fe177f05e010) ha partecipato alla conferenza 434f88d0-8441-41e1-b6ee-6d1c63b5b098 tramite SIP

Info	chiamata 7: compensazione per il lato remoto che non corrisponde ai tipi di payload
Info	chiamata 8: modalità di tipi di payload non corrispondenti 1/0
Info	chiamata 8: risposta all'offerta in modalità di tipi di payload non corrispondenti
Info	chiamata 8: offerta di codec singolo successivo ricevuta
Info	chiamata 8: modalità di tipi di payload non corrispondenti 1/0
Info	chiamata 8: risposta all'offerta in modalità di tipi di payload non corrispondenti
Info	chiamata 8: invio della risposta all'offerta aggiuntiva di codec singolo
Info	chiamata 9: compensazione per il lato remoto che non corrisponde ai tipi di payload

Info	partecipante "673@172.x.x.x" ha partecipato allo spazio 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	partecipante "673@172.x.x.x" (d27e9a53-2c8a-4e9c-9363-0415cd812767) ha partecipato alla conferenza 434f88d0-8441-41e1-b6ee-6d1c63b5b098 tramite SIP

Info	chiamata 9: BFCP (ruolo client) ora attivo
Info	chiamata 9: invio di BFCP hello come client dopo la ricezione di hello quando BFCP non è attivo
Info	chiamata 9: BFCP (ruolo client) ora attivo
Info	chiamata 7: terminazione; teardown SIP remoto - connesso per 0:13
Info	chiamata 7: distruzione della leg della chiamata API bc0be45e-ce8f-411c-be04-594e0220c38e

Info	partecipante "672@x.x.x" ha lasciato lo spazio 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	chiamata 9: in attesa
Info	chiamata 9: modalità di tipi di payload non corrispondenti 1/0
Info	chiamata 9: risposta all'offerta in modalità di tipi di payload non corrispondenti
Info	chiamata 8: in attesa
Info	chiamata 8: offerta di codec singolo successivo ricevuta
Info	chiamata 8: modalità di tipi di payload non corrispondenti 1/0
Info	chiamata 8: risposta all'offerta in modalità di tipi di payload non corrispondenti
Info	chiamata 8: invio della risposta all'offerta aggiuntiva di codec singolo
Info	chiamata 9: terminazione; teardown SIP remoto - connesso per 0:12

La conferenza Ad-Hoc:


Regole per le chiamate in entrata
La configurazione dei parametri delle chiamate in entrata è necessaria per ricevere chiamate in CMS. Come avete visto nella configurazione LDAP, tutti gli utenti sono stati importati con il dominio conf.pod6.cms.lab. Pertanto, almeno, desiderate che le chiamate a questo dominio siano destinate agli spazi. Sarà inoltre necessario impostare regole per tutto ciò che è destinato al nome di dominio completo (e, forse, anche per l'indirizzo IP) di ciascuno dei server CMS. Nella nostra gestione esterna delle chiamate, Unified CM, saranno configurate le linee SIP destinate a ciascuno dei server CMS individualmente. A seconda che la destinazione di queste linee SIP sia un indirizzo IP o il nome di dominio completo del server, sarà determinato se configurare CMS per ricevere chiamate destinate al suo indirizzo IP o al nome di dominio completo.

Il dominio con la regola di traffico in entrata di massima priorità viene utilizzato come dominio per qualsiasi spazio utente. Quando gli utenti si sincronizzano tramite LDAP, CMS crea automaticamente gli spazi, ma solo la parte utente dell'URI (coSpaceUriMapping), ad esempio, user.space. Parte dominio l'URI completo viene generato sulla base di questa regola. Infatti, se accedessi a Web Bridge in questo momento, vedresti che l'URI di spazio non ha un dominio. Impostando questa regola come priorità massima, definisci il dominio per gli spazi generati come conf.example.com.


Regole per le chiamate in uscita

Per consentire agli utenti di effettuare chiamate in uscita nel cluster Unified CM, è necessario configurare le regole per le connessioni in uscita. Il dominio degli endpoint registrati in Unified CM, come Jabber, è example.com. Le chiamate a questo dominio devono essere instradate come normali chiamate SIP ai nodi di elaborazione delle chiamate Unified CM. Il server principale è cucm-01.example.com, mentre il secondario è cucm-02.example.com.

La prima regola descrive la più semplice instradamento delle chiamate tra i server del cluster.

Campo Local from domain gestisce ciò che verrà visualizzato nel SIP-URI dell'utente che riceve la chiamata dopo il simbolo "@". Se lo lasciamo vuoto, dopo il simbolo "@" ci sarà l'indirizzo IP del CUCM attraverso il quale passa questa chiamata. Se indichiamo un dominio, allora dopo il simbolo "@" ci sarà il dominio. Questo è necessario per consentire la possibilità di richiamare, altrimenti sarà impossibile richiamare al SIP-URI nome@indirizzo-ip.

Chiamata quando è specificato Local from domain


Chiamata quando NO specificato Local from domain


È obbligatorio specificare esplicitamente Encrypted o Unencrypted per le chiamate in uscita; altrimenti, con il parametro Auto, nulla funziona.

Registrazione

La registrazione delle videoconferenze è gestita dal server Record. Il Recorder è esattamente lo stesso Cisco Meeting Server. Il Recorder non richiede alcuna licenza installata. Le licenze di registrazione sono necessarie per i server su cui sono in esecuzione i servizi CallBridge, cioè la licenza Recording deve essere applicata al componente CallBridge e non al server su cui è in esecuzione il Recorder. Il Recorder si comporta come un client del protocollo di messaggistica estensibile e presenza (XMPP), quindi il server XMPP deve essere abilitato sul server in cui è ospitato CallBridge.

Poiché abbiamo un cluster e la licenza deve essere "distribuita" su tutti e tre i server del cluster, nel pannello di controllo associamo (aggiungiamo) gli indirizzi MAC delle interfacce a di tutti i server CMS che fanno parte del cluster.

E questa dovrebbe essere l'immagine su ogni server del cluster.

In realtà ci sono diversi scenari per posizionare il Recorder, ma ci atteniamo a questo:


Prima di configurare il Recorder, è necessario preparare un luogo dove verranno registrate le videoconferenze. Ecco qua: link, come configurare l'intero sistema di registrazione. Porrei l'accento su aspetti e dettagli importanti:

1. È meglio fornire il certificato dal primo server del cluster.
2. L'errore "Recorder unavailable" può verificarsi se il certificato non corretto è stato specificato nel Recorder Trust.
3. La registrazione potrebbe non avvenire se non è specificata la directory principale in NFS.

A volte è necessario registrare automaticamente la conferenza di un utente specifico o di uno spazio.

Per questo si creano due profili di chiamata:
Con la funzione di registrazione disattivata.


E con la funzione di registrazione automatica.


Successivamente, associamo il profilo di chiamata con la funzione di registrazione automatica allo spazio desiderato.


Nella CMS è consuetudine che se un CallProfile è esplicitamente associato a uno o più space, allora questo CallProfile funziona solo per quegli specifici space. Se invece il CallProfile non è collegato a nessuno space, per impostazione predefinita si applica a quegli space ai quali non è esplicitamente associato alcun CallProfile.

La prossima volta cercherò di descrivere in che modo si accede alla CMS al di fuori della rete interna dell'organizzazione.

Fonti:

• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-5/Cisco-Meeting-Server-2-5-Single-Combined-Server-Deployment.pdf
• www.cisco.com/c/en/us/support/docs/conferencing/meeting-server/202722-Configure-Recorder-in-CMS-Acano-Call-Bri.html
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-3/Cisco-Meeting-Server-MMP-Command-Reference-2-3.pdf
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-5/Cisco-Meeting-Server-API-Reference-Guide-2-4-and-later.pdf

Fonte: habr.com