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

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


TeoriaEsistono tre tipi di distribuzione del server CMS:

• Single Combined(Unico combinato), cioè un singolo server su cui sono in esecuzione tutti i servizi necessari. Nella maggior parte dei casi, questo tipo di distribuzione è applicabile solo per l'accesso ai clienti interni e in ambienti piccoli, dove le limitazioni di scalabilità e ridondanza di un singolo server non rappresentano un problema critico, oppure in situazioni in cui il CMS svolge solo determinate funzioni, come conferenze speciali su Cisco UCM.

  Schema di lavoro approssimativo:
  

• Single Split(Unico diviso) espande il tipo di distribuzione precedente, aggiungendo un server separato per l'accesso esterno. Nelle distribuzioni obsolete significava distribuire il server CMS in una rete demilitarizzata (DMZ), dove i clienti esterni potevano accedervi, e un singolo server CMS nel nucleo della rete, a cui accedono i clienti interni. Questo modello specifico di distribuzione è ora sostituito dal cosiddetto tipo Single Edge, composto da server Cisco Expressway, che hanno o avranno molte delle funzionalità di bypass del firewall, quindi ai clienti non è necessario aggiungere un server perimetrale CMS dedicato.

  Schema di lavoro approssimativo:
  

• Scalable and Resilient(Scalabile e resiliente) 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 tratteremo in questo episodio. Se comprendiamo come distribuire un cluster di questo tipo, non solo comprenderemo altri tipi di distribuzione, ma saremo anche in grado di capire come creare cluster di server CMS tenendo conto della potenziale crescita delle esigenze.

Prima di passare alla distribuzione, è necessario comprendere alcune nozioni di base, in particolare

Componenti software principali del CMS:

• Database: consente di unire alcune configurazioni, come gruppi di abbonati, spazi utente e utenti stessi. Supporta la clusterizzazione solo per alta disponibilità (un master).
• Call Bridge: servizio per conferenze audio e video, che mantiene il completo controllo sulla gestione e l'elaborazione delle chiamate e dei processi multimediali. Supporta la clustering per alta disponibilità e scalabilità.
• server XMPP: è responsabile della registrazione e dell'autenticazione dei clienti che utilizzano l'applicazione Cisco Meeting Application e\/o WebRTC (comunicazione in tempo reale, o semplicemente nel browser), così come la segnalazione tra componenti. Può essere clusterizzato solo per alta disponibilità.
• Web Bridge: fornisce accesso ai clienti in WebRTC.
• Loadbalancer: garantisce un'unica punto di accesso per le applicazioni Cisco Meeting App in modalità Single Split. Monitora l'interfaccia e la porta esterne per le connessioni in entrata. In egual misura, il bilanciatore di carico accetta connessioni in ingresso TLS dall'XMPP server, tramite le quali può instradare le connessioni TCP da clienti esterni.
  Nel nostro scenario non sarà necessario.
• TURN server: fornisce tecnologia di bypass per firewall, permettendo
  di esporre il nostro CMS dietro un firewall o NAT per connettere clienti esterni che utilizzano Cisco Meeting App o dispositivi SIP. Nel nostro scenario non sarà necessario.
• Web Admin: interfaccia di amministrazione e accesso all'API, inclusi 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 configurazione iniziale e certificati.
• Web Administrator: principalmente per la configurazione relativa a CallBridge, specialmente nella configurazione di un singolo server non clusterizzato.
• REST API: utilizzato per i compiti di configurazione più complessi e per le attività legate al database cluster.

Oltre a quanto sopra, viene utilizzato il protocollo SFTP per il trasferimento di file - di solito licenze, certificati o registri - al server CMS e da esso.

Nelle guide di distribuzione di Cisco è scritto chiaramente in inglese che il cluster deve essere implementato con un minimo di tre server (nodi) nel contesto dei database. Poiché 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 un collegamento con la maggior parte del database del server CMS.

E come mostra l'esperienza, avere due server (nodi) non è veramente sufficiente. Il meccanismo di selezione si attiva durante il riavvio del Master, il server Slave diventa Master esclusivamente dopo che il server riavviato è attivo. Tuttavia, se nel cluster di due server il server Master si spegne, il server Slave non diventerà Master, e se il Slave si spegne, l'unico server Master rimasto diventerà Slave.

Nel contesto di XMPP è realmente necessario configurare un cluster di tre server, dato che, ad esempio, disattivando il servizio XMPP su uno dei server in cui XMMP è in stato di Leader, l'altro server XMPP rimarrà in stato di Follower e le connessioni di CallBridge a XMPP si interromperanno, dato che CallBridge si connette esclusivamente a XMPP con stato di Leader. Questo è critico, poiché nessuna chiamata verrà correttamente gestita.

In queste stesse guide di deployment viene anche dimostrato un cluster con un solo server XMPP.

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

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

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

Record DNS

Prima di procedere con la configurazione dei server, è necessario creare i record DNS. A 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 loro URI tutti gli utenti di Cisco Unified Communication Manager, che probabilmente è presente nella vostra infrastruttura o molto probabilmente lo sarà. Oppure il dominio example.com corrisponde allo stesso dominio che gli utenti utilizzano per i loro indirizzi e-mail. O ancora, il client Jabber sul vostro laptop può avere l'URI user@example.com. Il dominio conf.example.com è il dominio che sarà configurato per gli utenti del Cisco Meeting Server. Il dominio del Cisco Meeting Server sarà conf.example.com, pertanto 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 mostrate su un singolo server, ma devono essere eseguite su ogni server del cluster.

QoS

Poiché il CMS genera real-time Il traffico sensibile ai ritardi e alla perdita di pacchetti dovrebbe in genere essere ottimizzato tramite la qualità del servizio (QoS). A tal fine, il CMS supporta la marcatura dei pacchetti con i codici dei servizi differenziati (DSCP) che genera. Anche se la priorità del traffico basata su DSCP dipende da come il traffico viene gestito dai componenti di rete della vostra infrastruttura, in questo caso configureremo il nostro CMS con una distribuzione tipica delle priorità DSCP basata sulle migliori pratiche QoS.

Su ciascun server inseriamo questi 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 è stato contrassegnato come AF41 (DSCP 0x22), tutto il traffico vocale è contrassegnato come EF (DSCP 0x2E), mentre altri tipi di traffico a bassa latenza, come SIP e XMPP, utilizzano AF31 (DSCP 0x1A).

Controlliamo:

NTP

Il protocollo di rete del 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 della vostra infrastruttura con il comando del tipo

ntp server add

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

E impostiamo il fuso orario per il nostro server.

DNS

Aggiungiamo i server DNS al CMS con il comando del tipo:

dns add forwardzone

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

Configurazione dell'interfaccia di rete

Configuriamo l'interfaccia con il comando del tipo:

ipv4  add 
 /

Controlliamo:

Nome del server (Hostname)

Impostiamo il nome del server con il comando del tipo:

hostname

E riavviamo.


A questo punto, la configurazione di base è completa.

Certificati

TeoriaCisco Meeting Server richiede comunicazioni crittografate tra i vari componenti, e di conseguenza i certificati X.509 sono necessari per tutte le implementazioni di CMS. Aiutano a garantire la fiducia nei servizi/server da parte di altri server/servizi.

Ogni servizio richiede un certificato, ma creare certificati separati per ogni servizio può portare a confusione e complessità superflua. Fortunatamente, possiamo generare una coppia di chiavi pubbliche e private per il 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 per ogni server nel cluster.

La clustering del database presenta requisiti particolari per i certificati e richiede pertanto certificati propri, diversi da quelli delle altre servizi. Il CMS utilizza un certificato del server simile a quello utilizzato da altri server, ma c'è 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 collegare il cliente al database, esso presenta un certificato del cliente di cui il server si fida. Ogni server nel cluster del database utilizzerà la stessa coppia di chiavi pubbliche e private. Ciò consente a tutti i server nel cluster di crittografare i dati in modo che possano essere decrittografati solo da altri server che utilizzano la stessa coppia di chiavi.

Per il funzionamento del backup, i cluster del database devono essere composti da almeno 3 server, ma non più di 5, con un tempo massimo di latenza bidirezionale di 200 ms tra qualsiasi membro del cluster. Questo limite è più restrittivo rispetto alla clustering del Call Bridge e spesso rappresenta un fattore limitante nelle distribuzioni geograficamente distribuite.

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

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

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

Quindi, formiamo una richiesta per il certificato che verrà utilizzato da tutti i servizi del server, ad eccezione di database (per questo ci sarà una richiesta separata) con il comando del tipo:

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

In CN scriviamo un nome generico dei nostri server. Ad esempio, se i nomi host dei nostri server server01, server02, server03, allora CN sarà server.example.com

Facciamo la stessa cosa sugli altri due server con la differenza che nei comandi ci saranno i corrispondenti nomi '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 dei futuri certificati. hostname1(2)(3) i nomi dei corrispondenti server.

Questa procedura la eseguiamo solo su un server(!), e caricheremo i certificati e i relativi file .key sugli altri server.

Abilitazione della modalità certificato cliente in AD CS

È necessario unire in un file unico i certificati per ogni server.In *NIX:

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

In Windows/DOS:

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

E carica su ogni server:
1. Il certificato 'individuale' del server.
2. Il certificato radice (insieme a eventuali intermedi).
3. I certificati per il database ('server' e 'cliente') e i file con estensione .key, che si sono formati durante la creazione della richiesta per il certificato 'server' e 'cliente' del database. Questi file devono essere gli stessi su tutti i server.
4. Il file di tutti e tre i certificati 'individuali'.

Alla fine, dovrebbe risultare un quadro di file simile su ogni server.

Database Cluster

Ora che hai tutti i certificati caricati sui server CMS, puoi configurare e abilitare il clustering del database tra tre nodi. Il primo passo è selezionare un server come nodo principale del cluster del database e completarne la configurazione.

Database Master

Il primo passo per configurare la replica del database è specificare i certificati che verranno utilizzati 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 Client Database

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

database cluster join

dove è l’indirizzo IP del server CMS sul quale è stata effettuata l’inizializzazione del cluster, semplicemente il Master.

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

database cluster status

Facciamo la stessa cosa anche sul terzo server rimanente.

Il risultato finale è che il nostro primo server è il Master, mentre gli altri sono Slave.

Servizio di amministrazione web

Abilitiamo il servizio di amministrazione web:

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 dei certificati usando un comando del tipo:

webadmin certs

E abilitiamo il Web Admin con il comando:

webadmin enable

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

Cluster Call Bridge

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

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

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 dal clustering del database o XMPP. Il Cluster Call Bridge può supportare da 2 a 8 nodi senza alcuna limitazione. Fornisce non solo ridondanza, ma anche bilanciamento del carico, il che consente alle conferenze di essere distribuite attivamente tra i server Call Bridge tramite una distribuzione intelligente delle chiamate. CMS ha funzionalità aggiuntive, gruppi Call Bridge e relative funzioni che possono essere utilizzate per una gestione ulteriore.

Il clustering dei ponti di chiamata viene configurato principalmente tramite l'interfaccia amministrativa web
La procedura descritta di seguito deve essere eseguita su ciascun server del cluster.
Quindi,

1. Accediamo tramite web a Configuration > Cluster.
2. In Call Bridge identity inseriamo come nome univoco callbridge[01,02,03] corrispondente al nome del server. Questi nomi sono arbitrari, ma devono essere unici per questo cluster. Hanno un carattere descrittivo, poiché indicano che si tratta di identificatori dei server [01,02,03].
3. In Clustered Call Bridges inseriamo gli URL degli amministratori web dei nostri server nel cluster, cms[01,02,03].example.com:445, nel campo Address. Assicurati di specificare la porta. Puoi lasciare vuoto il dominio SIP del peer link.
4. Aggiungi al CallBridge di ciascun server il certificato, il file che contiene tutti i certificati dei nostri server, che abbiamo combinato in questo file all'inizio, con un comando del tipo:

callbridge trust cluster

E riavviamo il servizio con il comando:

callbridge restart

Alla fine, ogni server dovrebbe avere una configurazione simile a questa:

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. Lo stesso Call Bridge agisce anche come cliente XMPP per scopi di autenticazione e deve quindi essere configurato come altri clienti. La resilienza XMPP è una funzione supportata negli ambienti di produzione a partire dalla versione 2.1

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

Colleghiamo i certificati al servizio XMPP con un comando del tipo:

xmpp certs  []

Quindi definiamo l'interfaccia di ascolto con il comando:

xmpp listen a

Per il servizio XMPP è richiesto un dominio unico. Questo è il login per gli utenti. In altre parole, quando un utente tenta di accedere al sistema 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? Nella nostra specifica implementazione, 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 domini SIP.

Imposta il dominio XMPP con il comando del tipo:

xmpp domain

E abilitiamo il servizio XMPP con il comando:

xmpp enable

Nel servizio XMPP è necessario creare le credenziali per ogni Call Bridge, che saranno utilizzate durante la registrazione nel servizio XMPP. Questi nomi sono arbitrari (e non sono legati ai nomi unici che hai impostato per la clustering dei ponti di chiamata). Su un server XMPP è necessario aggiungere tre ponti di chiamata e quindi 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 registrarsi 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 password casuali. Successivamente, verranno 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 controlliamo cosa è uscito con il comando:

xmpp callbridge list

Deve esserci esattamente la stessa situazione sugli altri server dopo le azioni descritte di seguito.

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

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

Aggiungiamo il Secret molto attentamente, in modo che non ci finiscano accidentalmente spazi extra.


Alla fine, su ogni server deve esserci questa situazione uguale:

In seguito, su tutti i server del cluster specifichiamo nel file di fiducia contenente tutti e tre i certificati, creato in precedenza con un comando del tipo:

xmpp cluster trust

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

xmpp cluster enable

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

xmpp cluster initialize

Sugli altri server aggiungiamo al cluster xmpp con il comando del tipo:

xmpp cluster join

Controlliamo 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 è avviato, è necessario configurare i servizi Call Bridge per collegarsi al cluster XMPP. Questa configurazione viene eseguita tramite il web-amministratore.

Accediamo su ogni server a Configuration > General e nel campo Unique Call Bridge name scriviamo i nomi Call Bridge unici corrispondenti al server callbridge[01,02,03]. Nel campo Dominio conf.example.ru e le relative password, che possiamo consultare
su qualsiasi server del cluster con il comando:

xmpp callbridge list

Lasciamo vuoto il campo "Server", Callbridge effettuerà una ricerca DNS SRV per _xmpp-component._tcp.conf.example.com, per trovare un server XMPP disponibile. Gli indirizzi IP dei collegamenti delle callbridge a XMPP possono variare su ogni server, poiché dipende dai valori restituiti dalla query per la registrazione _xmpp-component._tcp.conf.example.com al callbridge, che a sua volta dipende dalle impostazioni di priorità per questa registrazione DNS.

Successivamente, passiamo a Status > General per assicurarci che il servizio Call Bridge sia stato connesso con successo 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. Reindirizzerà l'HTTP verso l'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 il Web Bridge può fidarsi delle connessioni provenienti da Call Bridge, usa il comando:

webbridge trust

dove è il file contenente tutti e tre i certificati di ciascun server nel cluster.

Questa configurazione deve essere presente su ciascun server del cluster.


Ora dobbiamo creare un utente con il ruolo "appadmin", necessario affinché possiamo configurare il nostro cluster(!), e non ogni singolo server del cluster separatamente, così le impostazioni verranno applicate uniformemente su ogni server, mentre verranno eseguite una sola volta.


Per la configurazione successiva, utilizzeremo Postman.

Per l'autenticazione scegliamo Basic nella sezione Autorization

Per inviare correttamente comandi ai server CMS è necessaria la corretta codifica.

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



All'interno del webbridge indichiamo i parametri necessari: accesso guest, accesso protetto e altro ancora.

Gruppi di Call Bridge.

Di default, il CMS non utilizza sempre in modo ottimale le risorse disponibili per le conferenze.

Ad esempio, per una riunione con tre partecipanti, ciascun partecipante potrebbe trovarsi su tre diversi Call Bridge. Per consentire a questi tre partecipanti di comunicare tra loro, i Call Bridge stabiliranno automaticamente connessioni tra tutti i server e i client nello stesso Space, in modo che sembri che tutti i client siano su un unico server. Sfortunatamente, il lato negativo di questo è che una conferenza con 3 persone consumerà ora 9 porte media. Questo è ovviamente un utilizzo inefficiente delle risorse. Inoltre, quando il Call Bridge è realmente sovraccarico, il meccanismo di default è continuare a ricevere chiamate e fornire servizi a bassa qualità a tutti gli abbonati di quel Call Bridge.

Questi problemi vengono risolti mediante la funzione Call Bridge Group. Questa funzione è stata introdotta nella versione 2.1 del software Cisco Meeting Server ed è stata 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 della riconnessione, sono stati introdotti tre limiti di carico configurabili per ogni Call Bridge:

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

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

Queste opzioni possono essere configurate qui: cms.example.com:445/api/v1/system/configuration/cluster

Successivamente, indichiamo a ciascun callbridge a quale gruppo di callbridge appartiene:

Primo callbridge

Secondo callbridge

Terzo callbridge


Così abbiamo configurato un gruppo Call Bridge per un utilizzo più efficiente delle risorse del cluster Cisco Meeting Server.

Importa utenti da Active Directory

Il servizio Web Admin ha una sezione di configurazione LDAP, ma non fornisce opzioni di configurazione complesse e le informazioni non vengono salvate nel database del cluster, quindi la configurazione deve essere eseguita manualmente su ciascun server tramite interfaccia Web o tramite API, e per evitare di doverlo fare tre volte, inseriremo i dati tramite API.

Utilizzando l'URL di accesso cms01.example.com:445/api/v1/ldapServers creiamo un oggetto LDAP Server, indicando parametri come:

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

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


Mappiamo i parametri LDAP di origine agli attributi nel Cisco Meeting Server.
La mappatura LDAP associa gli attributi nel catalogo LDAP con gli attributi nel CMS. Gli attributi sono:

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Descrizione degli attributiJID rappresenta l'identificativo di accesso dell'utente nel CMS. Poiché questo è un server LDAP di Microsoft Active Directory, il JID CMS è mappato su sAMAccountName in LDAP, che è essenzialmente l'identificativo di accesso dell'utente in Active Directory. Si noti che si prende sAMAccountName e si aggiunge il dominio conf.pod6.cms.lab alla fine, perché questo è il login che i vostri utenti utilizzeranno per accedere al CMS.

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

coSpaceNameMapping crea il nome dello space del CMS basato sul campo displayName. Questo attributo insieme all'attributo coSpaceUriMapping sono ciò che è necessario per creare uno space per ogni utente.

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

coSpaceSecondaryUriMapping definisce un secondo URI per raggiungere lo spazio. Questo può essere utilizzato per aggiungere un soprannome numerico per il routing delle chiamate nello spazio dell'utente importato come alternativa all'URI alfanumerico definito nel parametro coSpaceUriMapping.

Il server LDAP e il mapping LDAP sono configurati. Ora è necessario collegarli insieme, creando una sorgente LDAP.

Utilizzando l'URL di accesso cms01.example.com:445/api/v1/ldapSource creiamo un oggetto LDAP Source, specificando parametri quali:

• server
• mapping
• baseDn
• filter

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

Facciamo questo sia nell'interfaccia Web di ciascun server premendo Sync now nella sezione Active Directory


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

Conferenze Ad-Hoc

Cosa è?Nel senso tradizionale, una conferenza è quando due partecipanti parlano tra 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 questa terza parte preme di nuovo il pulsante 'Conferenza' per unirsi a tutti i partecipanti della conferenza a tre.

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

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

Se necessario, CUCM può creare dinamicamente spazi nel CMS in modo che ogni chiamata possa raggiungere il CMS e rispettare la regola delle chiamate in entrata destinata agli spazi.

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

SIP Security Profile:


Trunk:


Ogni trunk appare uguale:




Conference Bridge


Ogni Conference Bridge appare uguale:


Route Group


Route List


Media Resource Group


Media Resource Group List

Regole delle chiamate

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 l'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. Per prima cosa, CMS cerca di abbinare il dominio SIP ai domini configurati nelle regole di elaborazione delle chiamate in entrata. Dopodiché, queste chiamate possono essere indirizzate a spazi ("target") o a utenti specifici, a IVR interni o direttamente ai destinatari integrati di Microsoft Lync/Skype for Business (S4B).
2. Se non ci sono corrispondenze nelle regole di elaborazione delle chiamate in entrata, 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 inoltrare la chiamata. In questo momento, CMS può riscrivere il dominio, il che è talvolta utile per le chiamate ai domini Lync. Puoi anche scegliere di utilizzare pass throw, il che significa che nessun campo verrà ulteriormente modificato, oppure utilizzare un gruppo di abonnati interno di CMS. Se non ci sono corrispondenze nelle regole di inoltro delle chiamate, per impostazione predefinita viene utilizzato il rifiuto della chiamata. Tieni presente che in CMS, anche se la chiamata è "inoltrata", i media sono ancora collegati a CMS, il che significa che rimarrà nel percorso di segnalazione e nel traffico multimediale.
Solo le chiamate inoltrate sono soggette alle regole delle chiamate in uscita. Queste opzioni definiscono i destinatari a cui inviare le chiamate, il tipo di linea (sia essa una nuova chiamata Lync o un SIP standard) e qualsiasi trasformazione che potrebbe essere eseguita se non è stata selezionata alcuna trasmissione nella regola di inoltro delle chiamate.

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

Nello screenshot è visibile male (non so come farlo meglio), quindi scriverò il log in questo modo:

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

Info	chiamata di 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: l'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 controllo/media GUID: 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: impostazione della sessione UDT RTP per DTLS (media e controllo combinati)
Info	conferenza "001036270012": leg chiamate non crittografate ora presenti

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

Info	partecipante "672@172.x.x.x" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) entrato nella 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: impostazione della sessione UDT RTP 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: impostazione della sessione UDT RTP per DTLS (media e controllo combinati)
Info	chiamata 8: compensazione per il fatto che l'estremità lontana non corrisponde ai tipi di payload

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

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

Info	chiamata 7: compensazione per il fatto che l'estremità lontana non corrisponde ai tipi di payload
Info	chiamata 8: modalità tipi di payload non corrispondenti 1/0
Info	chiamata 8: risposta all'offerta in modalità tipi di payload non corrispondenti
Info	chiamata 8: offerta singola codec successiva ricevuta
Info	chiamata 8: modalità tipi di payload non corrispondenti 1/0
Info	chiamata 8: risposta all'offerta in modalità tipi di payload non corrispondenti
Info	chiamata 8: invio della risposta all'offerta aggiuntiva a codec singolo
Info	chiamata 9: compensazione per il fatto che l'estremità lontana non corrisponde ai tipi di payload

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

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

Info	chiamata 9: BFCP (ruolo client) ora attivo
Info	chiamata 9: invio del saluto BFCP come client dopo aver ricevuto un saluto quando BFCP non era attivo
Info	chiamata 9: BFCP (ruolo client) ora attivo
Info	chiamata 7: conclusione; teardown SIP remoto - connesso per 0:13
Info	chiamata 7: distruzione del 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à tipi di payload non corrispondenti 1/0
Info	chiamata 9: risposta all'offerta in modalità tipi di payload non corrispondenti
Info	chiamata 8: in attesa
Info	chiamata 8: offerta singola codec successiva ricevuta
Info	chiamata 8: modalità tipi di payload non corrispondenti 1/0
Info	chiamata 8: risposta all'offerta in modalità tipi di payload non corrispondenti
Info	chiamata 8: invio della risposta all'offerta aggiuntiva a codec singolo
Info	chiamata 9: conclusione; teardown SIP remoto - connesso per 0:12

La conferenza Ad-Hoc:


Regole delle chiamate in entrata
La configurazione dei parametri delle chiamate in entrata è necessaria per ricevere chiamate in CMS. Come hai visto nella configurazione LDAP, tutti gli utenti sono stati importati con il dominio conf.pod6.cms.lab. Pertanto, almeno, vorresti che le chiamate a questo dominio fossero destinate agli spazi. Avrai anche bisogno di impostare le regole per tutto ciò che è destinato al nome di dominio completo (e, forse, anche per l'indirizzo IP) di ciascun server CMS. Nei nostri controlli esterni delle chiamate, Unified CM, verranno configurati i trunk SIP, destinati a ciascun server CMS individualmente. A seconda che la destinazione di questi trunk SIP sia un indirizzo IP, o se il nome di dominio completo del server determinerà se CMS deve essere configurato per ricevere chiamate indirizzate al suo indirizzo IP o al nome di dominio completo.

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


Regole delle chiamate in uscita

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

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

Campo Locale dal dominio si occupa di ciò che verrà visualizzato nel SIP-URI del chiamante presso chi 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 invece specifichiamo un dominio, dopo il simbolo «@» ci sarà effettivamente il dominio. Questo è necessario per consentire la possibilità di richiamare, altrimenti sarà impossibile richiamare tramite SIP-URI nome@indirizzo-ip.

Chiamata quando specificata Locale dal dominio


Chiamata quando NO sia indicato Locale dal dominio


Specificare esplicitamente Encrypted o Unencrypted per le chiamate in uscita, quindi con l'impostazione Auto niente funziona.

Registrazione

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

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

Ecco come dovrebbe apparire ogni server del cluster

In generale ci sono diversi scenari per il posizionamento del Recorder, ma ci attiveremo a questo:


Prima di configurare il Recorder, è necessario preparare un luogo dove verranno effettivamente registrate le videoconferenze. Ecco qui link, come configurare tutta la registrazione. Metterò in evidenza i momenti e i dettagli importanti:

1. È meglio usare il certificato del primo server nel cluster.
2. L'errore "Recorder non disponibile" può verificarsi perché è stato specificato un certificato errato nella fiducia del Recorder.
3. La registrazione potrebbe non avvenire se non viene specificata una directory radice in NFS.

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

Per questo vengono creati due CallProfile:
Con la funzione di registrazione disabilitata


E con la funzione di registrazione automatica


Successivamente colleghiamo il CallProfile con funzione di registrazione automatica allo spazio desiderato.


Nella CMS è stabilito che se un CallProfile è chiaramente associato a determinati space o a uno specifico space, allora questo CallProfile funziona solo per quegli specifici space. Se un CallProfile non è associato a nessuno space, viene applicato per impostazione predefinita a quegli space ai quali non è chiaramente associato alcun CallProfile.

La prossima volta cercherò di descrivere in quali modi si può accedere 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