Server riunioni Cisco 2.5.2. Cluster in modalità Scalable e Resilient con funzione di registrazione videoconferenza

In questo numero mostrerò e spiegherò alcune complessità della configurazione di un server CMS in modalità cluster di failover.


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

• Combinato singolo(Singolo combinato), cioè questo è un server su cui sono in esecuzione tutti i servizi necessari. Nella maggior parte dei casi, questo tipo di implementazione è adatto solo per l'accesso client interno e in ambienti più piccoli dove le limitazioni di scalabilità e ridondanza di un singolo server non rappresentano un problema critico, o in situazioni in cui il CMS esegue solo determinate funzioni, come ad hoc conferenze su Cisco UCM.

  Schema di lavoro approssimativo:
  

• Divisione singola(Single Split) estende il tipo di distribuzione precedente aggiungendo un server separato per l'accesso esterno. Nelle distribuzioni legacy, ciò significava distribuire un server CMS in un segmento di rete demilitarizzata (DMZ) dove i client esterni potevano accedervi e un server CMS nel nucleo della rete dove i client interni potevano accedere al CMS. Questo particolare modello di distribuzione viene ora sostituito dal cosiddetto tipo Bordo singolo, che consiste di server Cisco Expressway, che hanno o avranno molte delle stesse funzionalità di bypass del firewall in modo che i client non debbano aggiungere un server CMS edge dedicato.

  Schema di lavoro approssimativo:
  

• Scalabile e resiliente(Scalabile e tollerante ai guasti) Questo tipo include la ridondanza per ciascun componente, consentendo al sistema di crescere con le vostre esigenze fino alla sua capacità massima fornendo al contempo ridondanza in caso di guasto. Utilizza inoltre il concetto Single Edge per fornire un accesso esterno sicuro. Questo è il tipo che vedremo in questo episodio. Se capiamo come implementare questo tipo di cluster, non solo comprenderemo altri tipi di implementazioni, ma saremo anche in grado di capire come creare cluster di server CMS per soddisfare la potenziale crescita della domanda.

Prima di passare alla distribuzione, è necessario comprendere alcune cose di base, vale a dire

Principali componenti del software CMS:

• Banca Dati: consente di combinare alcune configurazioni, ad esempio dial plan, spazi utente e utenti stessi. Supporta solo il clustering per disponibilità elevata (master singolo).
• Ponte di chiamata: un servizio di audio e videoconferenza che garantisce il pieno controllo sulla gestione e l'elaborazione delle chiamate e dei processi multimediali. Supporta il clustering per alta disponibilità e scalabilità.
• Server XMPP: responsabile della registrazione e dell'autenticazione dei clienti che utilizzano l'applicazione per riunioni Cisco e/o WebRTC(comunicazione in tempo reale o semplicemente nel browser), così come la segnalazione intercomponente. Può essere raggruppato solo per la disponibilità elevata.
• Ponte Web: fornisce l'accesso client a WebRTC.
• Bilanciamento del carico: fornisce un singolo punto di connessione per le app per riunioni Cisco in modalità divisione singola. Ascolta l'interfaccia esterna e la porta per le connessioni in entrata. Allo stesso modo, il sistema di bilanciamento del carico accetta connessioni TLS in entrata dal server XMPP, attraverso il quale può commutare le connessioni TCP da client esterni.
  Nel nostro scenario non sarà necessario.
• TURN server: Fornisce la tecnologia di bypass del firewall che consente
  posiziona il nostro CMS dietro un Firewall o NAT per connettere client esterni utilizzando l'app Cisco Meeting o i dispositivi SIP. Nel nostro scenario non sarà necessario.
• Amministratore web: interfaccia amministrativa e accesso API, anche 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 per soddisfare qualsiasi tipo di implementazione.

• Riga di comando (CLI): interfaccia della riga di comando nota come MMP per la configurazione iniziale e le attività di certificato.
• Amministratore Web: Principalmente per configurazioni correlate a CallBridge, soprattutto quando si imposta un singolo server non in cluster.
• API REST: utilizzato per le attività di configurazione più complesse e per le attività relative ai database in cluster.

Oltre a quanto sopra, viene utilizzato il protocollo SFTP per trasferire file, in genere licenze, certificati o registri, da e verso il server CMS.

Nelle guide di distribuzione di Cisco è scritto in bianco e inglese che il cluster deve essere distribuito almeno tre server (nodi) nel contesto dei database. Perché Solo con un numero dispari di nodi funzionerà il meccanismo di selezione di un nuovo Database Master, ed in generale il Database Master ha una connessione con la maggior parte dei database del server CMS.

E come dimostra la pratica, due server (nodi) non sono davvero sufficienti. Il meccanismo di selezione funziona al riavvio del Master, il server Slave diventa Master solo dopo che viene attivato il server riavviato. Tuttavia, se in un cluster di due server il server Master si spegne improvvisamente, il server Slave non diventerà il Master e se lo Slave si spegne, il restante server Master diventerà lo Slave.

Ma nel contesto di XMPP sarebbe davvero necessario mettere insieme un cluster di tre server, perché se, ad esempio, disabiliti il ​​servizio XMPP su uno dei server in cui XMMP è nello stato Leader, sul restante server XMPP rimarrà nello stato Follower e le connessioni CallBridge a XMPP cadranno, perché CallBridge si connette esclusivamente a XMPP con stato Leader. E questo è fondamentale, perché... non verrà accettata nemmeno una chiamata.

Inoltre nelle stesse guide alla distribuzione viene dimostrato un cluster con un server XMPP.

E tenendo conto di quanto sopra, diventa chiaro il motivo: 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 iniziare a configurare i server, devi creare record DNS А и SRV tipi:

Tieni presente che nei nostri record DNS sono presenti due domini example.com e conf.esempio.com. Esempio.com è un dominio che tutti gli abbonati a Cisco Unified Communication Manager possono utilizzare per i propri URI, che molto probabilmente è presente nella tua infrastruttura o è probabile che sia presente. Oppure example.com corrisponde allo stesso dominio utilizzato dagli utenti per i propri indirizzi email. Oppure il client Jabber sul tuo laptop potrebbe avere un URI [email protected]. Dominio conf.example.com è il dominio che verrà configurato per gli utenti di Cisco Meeting Server. Il dominio di Cisco Meeting Server sarà conf.example.com, quindi per lo stesso utente Jabber, sarà necessario utilizzare l'URI utente@ per accedere a Cisco Meeting Serverconf.esempio.com.

Configurazione di base

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

QoS

Poiché il CMS genera tempo reale traffico sensibile a ritardi e perdita di pacchetti, nella maggior parte dei casi si consiglia di configurare la qualità del servizio (QoS). Per raggiungere questo obiettivo, il CMS supporta l'etichettatura dei pacchetti con i codici di servizi differenziati (DSCP) che genera. Sebbene la prioritizzazione del traffico basata su DSCP dipenda da come il traffico viene elaborato dai componenti di rete della tua infrastruttura, nel nostro caso configureremo il nostro CMS con la tipica prioritizzazione DSCP basata sulle migliori pratiche QoS.

Su ogni server inseriremo questi comandi

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

Pertanto, tutto il traffico video è stato contrassegnato come AF41 (DSCP 0x22), tutto il traffico vocale è stato contrassegnato come EF (DSCP 0x2E), altri tipi di traffico a bassa latenza come SIP e XMPP utilizzano AF31 (DSCP 0x1A).

Controlliamo:

NTP

Il Network Time Protocol (NTP) è importante non solo per fornire timestamp accurati di chiamate e conferenze, ma anche per verificare i certificati.

Aggiungi server NTP alla tua infrastruttura con un comando come

ntp server add <server>

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

E imposta il fuso orario per il nostro server

DNS

Aggiungiamo i server DNS al CMS con un comando come:

dns add forwardzone <domain-name> <server ip>

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

Configurazione dell'interfaccia di rete

Configuriamo l'interfaccia con un comando del tipo:

ipv4 <interface> add <address>/<prefix length> <gateway>

Controlliamo:

Nome del server (nome host)

Impostiamo il nome del server con un comando del tipo:

hostname <name>

E riavviamo.


Questo completa la configurazione di base.

Certificati

TeoriaCisco Meeting Server richiede la comunicazione crittografata tra vari componenti e, di conseguenza, sono necessari certificati X.509 per tutte le distribuzioni CMS. Aiutano a garantire che il servizio/server sia considerato attendibile da altri server/servizi.

Ogni servizio richiede un certificato, ma la creazione di certificati separati per ciascun servizio può creare confusione e complessità inutili. Fortunatamente, possiamo generare la coppia di chiavi pubblica-privata di un certificato e quindi riutilizzarle su più servizi. Nel nostro caso lo stesso certificato verrà utilizzato per Call Bridge, XMPP Server, Web Bridge e Web Admin. Pertanto, è necessario creare una coppia di chiavi di certificato pubbliche e private per ciascun server nel cluster.

Il clustering di database, tuttavia, presenta alcuni requisiti di certificato speciali e pertanto richiede certificati propri diversi da quelli degli altri servizi. CMS utilizza un certificato server, simile ai certificati utilizzati da altri server, ma esiste anche un certificato client 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 consentire al client di connettersi al database, presenta un certificato client considerato attendibile dal server. Ciascun server nel cluster di database utilizzerà la stessa coppia di chiavi pubblica e privata. Ciò consente a tutti i server nel cluster di crittografare i dati in modo tale che possano essere decrittografati solo da altri server che condividono la stessa coppia di chiavi.

Affinché la ridondanza funzioni, i cluster di database devono essere costituiti da un minimo di 3 server, ma non più di 5, con un tempo massimo di andata e ritorno di 200 ms tra qualsiasi membro del cluster. Questo limite è più restrittivo rispetto al clustering Call Bridge, quindi spesso rappresenta il fattore limitante nelle distribuzioni distribuite geograficamente.

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

Il CMS utilizza un database Postgres con un master e diverse repliche completamente identiche. Esiste un solo database primario alla volta (il "server database"). I restanti membri del cluster sono repliche o "client di database".

Un cluster di database richiede un certificato server dedicato e un certificato client. Devono essere firmati da certificati, solitamente un'autorità di certificazione privata interna. Poiché qualsiasi membro del cluster di database può diventare il master, le coppie di certificati client e server database (contenenti le chiavi pubblica e privata) devono essere copiate su tutti i server in modo che possano assumere l'identità del client o del server database. Inoltre, è necessario caricare il certificato radice CA per garantire che i certificati client e server possano essere verificati.

Quindi, creiamo una richiesta per un certificato che verrà utilizzato da tutti i servizi del server tranne il database (ci sarà una richiesta separata per questo) con un comando come:

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

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

Facciamo lo stesso sui restanti due server con la differenza che i comandi conterranno i corrispondenti “hostname”

Generiamo due richieste di certificati che verranno utilizzati dal servizio database con comandi come:

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

pki csr dbclusterclient CN:postgres

dove dbclusterserver и dbclusterclient nomi delle nostre richieste e futuri certificati, nome host1(2)(3) nomi dei server corrispondenti.

Eseguiamo questa procedura solo su un server (!), e caricheremo i certificati e i corrispondenti file .key su altri server.

Abilita la modalità certificato client in Servizi certificati Active Directory

È inoltre necessario unire i certificati per ciascun server in un unico file.Su *NIX:

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

Su Windows/DOS:

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

E carica su ciascun server:
1. Certificato server “individuale”.
2. Certificato radice (insieme a quelli intermedi, se presenti).
3. Certificati per il database (“server” e “client”) e file con estensione .key, che sono stati generati durante la creazione di una richiesta per i certificati del database “server” e “client”. Questi file devono essere gli stessi su tutti i server.
4. File di tutti e tre i certificati “individuali”.

Di conseguenza, dovresti ottenere qualcosa di simile a questa immagine del file su ciascun server.

Cluster di database

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

Database principale

Il primo passaggio nella configurazione della replica del database consiste nello specificare i certificati che verranno utilizzati per il database. Questo viene fatto usando un comando come:

database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>

Ora diciamo al CMS quale interfaccia utilizzare per il clustering del database con il comando:

database cluster localnode a

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

database cluster initialize

Nodi del database clienti

Facciamo la stessa procedura, solo al posto del comando inizializzazione del cluster di database inserisci un comando come:

database cluster join <ip address existing master>

dove indirizzo ip indirizzo ip master esistente del server CMS su cui è stato inizializzato il cluster, semplicemente Master.

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

database cluster status

Facciamo lo stesso sul restante terzo server.

Di conseguenza, risulta che il nostro primo server è il Master, il resto sono gli Slave.

Servizio di amministrazione Web

Abilita il servizio di amministratore web:

webadmin listen a 445

È stata scelta la porta 445 perché la porta 443 viene utilizzata per l'accesso degli utenti al client Web

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

webadmin certs <keyfile> <certificatefile> <ca bundle>

E abilita Web Admin con il comando:

webadmin enable

Se tutto va bene, riceveremo le righe SUCCESS che indicano che Web Admin è configurato correttamente per la rete e il certificato. Controlliamo la funzionalità del servizio utilizzando un browser web e inseriamo l'indirizzo dell'amministratore web, ad esempio: cms.esempio.com: 445

Cluster di chiamate bridge

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

I comandi descritti di seguito devono essere eseguiti su ciascun server con gli appositi certificati.
Quindi:

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

callbridge certs <keyfile> <certificatefile>[<cert-bundle>]

Associamo i servizi CallBridge all'interfaccia di cui abbiamo bisogno con il comando:

callbridge listen a

E riavvia il servizio con il comando:

callbridge restart

Ora che abbiamo configurato i nostri Call Bridge, possiamo configurare il clustering di Call Bridge. Il clustering Call Bridge è diverso dal clustering di database o XMPP. Call Bridge Cluster può supportare da 2 a 8 nodi senza alcuna restrizione. Fornisce non solo ridondanza, ma anche bilanciamento del carico in modo che le conferenze possano essere distribuite attivamente tra i server Call Bridge utilizzando la distribuzione intelligente delle chiamate. Il CMS dispone di funzionalità aggiuntive, gruppi Call Bridge e funzionalità correlate che possono essere utilizzate per un'ulteriore gestione.

Il clustering del bridge di chiamata viene configurato principalmente tramite l'interfaccia di amministrazione Web
La procedura descritta di seguito deve essere eseguita su ciascun server del cluster.
Così,

1. Passare attraverso il Web a Configurazione > Cluster.
2. In Identità del ponte di chiamata Come nome univoco, inserisci callbridge[01,02,03] corrispondente al nome del server. Questi nomi sono arbitrari, ma devono essere univoci per questo cluster. Sono di natura descrittiva perché indicano che sono identificatori di server [01,02,03].
3.B Bridge di chiamata in cluster inserisci gli URL dell'amministratore web dei nostri server nel cluster, cms[01,02,03].example.com:445, nel campo Indirizzo. Assicurati di specificare la porta. È possibile lasciare vuoto il dominio SIP collegamento peer.
4. Aggiungi un certificato al trust CallBridge di ciascun server, il cui file contiene tutti i certificati dei nostri server, che abbiamo unito in questo file all'inizio, con un comando come:

callbridge trust cluster <trusted cluster certificate bundle>

E riavvia il servizio con il comando:

callbridge restart

Di conseguenza, su ciascun server dovresti ottenere questa immagine:

Cluster XMPP

Il servizio XMPP nel CMS viene utilizzato per gestire tutta la registrazione e l'autenticazione per Cisco Meeting Apps (CMA), incluso il client Web CMA WebRTC. Lo stesso Call Bridge funge anche da client XMPP a fini di autenticazione e pertanto deve essere configurato come gli altri client. La tolleranza agli errori XMPP è una funzionalità supportata negli ambienti di produzione a partire dalla versione 2.1

I comandi descritti di seguito devono essere eseguiti su ciascun server con gli appositi certificati.
Quindi:

Associamo i certificati al servizio XMPP con un comando come:

xmpp certs <keyfile> <certificatefile>[<cert-bundle>]

Quindi definire l'interfaccia di ascolto con il comando:

xmpp listen a

Il servizio XMPP richiede un dominio univoco. Questo è il login per gli utenti. In altre parole, quando un utente tenta di accedere utilizzando l'app CMA (o tramite il client WebRTC), inserisce userID@logindomain. Nel nostro caso sarà userid@conf.esempio.com. Perché non è solo example.com? Nella nostra particolare distribuzione, abbiamo selezionato il nostro dominio Unified CM che gli utenti Jabber utilizzeranno in Unified CM come example.com, quindi avevamo bisogno di un dominio diverso per consentire agli utenti CMS di instradare le chiamate da e verso il CMS tramite domini SIP.

Configura un dominio XMPP utilizzando un comando come:

xmpp domain <domain>

E abilita il servizio XMPP con il comando:

xmpp enable

Nel servizio XMPP è necessario creare credenziali per ogni Call Bridge che verranno utilizzate al momento della registrazione al servizio XMPP. Questi nomi sono arbitrari (e non sono correlati ai nomi univoci configurati per il clustering del bridge di chiamata). È necessario aggiungere tre bridge di chiamata su un server XMPP e quindi immettere tali credenziali sugli altri server XMPP nel cluster perché questa configurazione non rientra nel database del cluster. Successivamente configureremo ciascun Call Bridge per utilizzare questo nome e segreto per registrarsi al servizio XMPP.

Adesso dobbiamo configurare il servizio XMPP sul primo server con tre Call Bridge callbridge01, callbridge02 e callbridge03. Ad ogni account verranno assegnate password casuali. Verranno successivamente immessi su altri server Call Bridge per accedere a questo server XMPP. Inserisci i seguenti comandi:

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

Di conseguenza, controlliamo cosa è successo con il comando:

xmpp callbridge list

Dopo i passaggi descritti di seguito, sui restanti server dovrebbe apparire esattamente la stessa immagine.

Successivamente, aggiungiamo esattamente le stesse impostazioni sui restanti due server, solo con i comandi

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

Aggiungiamo Secret con molta attenzione in modo che, ad esempio, non ci siano spazi aggiuntivi.


Di conseguenza, ogni server dovrebbe avere la stessa immagine:

Successivamente, su tutti i server del cluster, specifichiamo in trust il file contenente tutti e tre i certificati, creato in precedenza con un comando come questo:

xmpp cluster trust <trust bundle>

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

xmpp cluster enable

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

xmpp cluster initialize

Su altri server, aggiungi un cluster a xmpp con un comando come:

xmpp cluster join <ip address head xmpp server>

Controlliamo su ciascun server il successo della creazione di un cluster XMPP su ciascun server con i comandi:

xmpp status
xmpp cluster status

Primo server:

Secondo server:

Terzo server:

Connessione di Call Bridge a XMPP

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

Su ciascun server, vai su Configurazione > Generale e nel campo Nome univoco del Call Bridge scrivere nomi univoci corrispondenti al server Call Bridge ponte di chiamata[01,02,03]... In campo Dominio conf.esempio.ru e le password corrispondenti, puoi spiarli
su qualsiasi server del cluster con il comando:

xmpp callbridge list

Lascia vuoto il campo “Server”. ponte di chiamata eseguirà una ricerca DNS SRV per _xmpp-component._tcp.conf.example.comper trovare un server XMPP disponibile. Gli indirizzi IP per la connessione dei callbridge a XMPP possono differire su ciascun server, dipende da quali valori vengono restituiti alla richiesta di record _xmpp-component._tcp.conf.example.com callbridge, che a sua volta dipende dalle impostazioni di priorità per un determinato record DNS.

Successivamente, vai su Stato > Generale per verificare se il servizio Call Bride è connesso correttamente al servizio XMPP.

Ponte Web

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

webbridge listen a:443

Configuriamo il servizio Web Bridge con file di certificato con un comando del tipo:

webbridge  certs <keyfile> <certificatefile> <ca bundle>

Web Bridge supporta HTTPS. Reindirizzerà HTTP a HTTPS se configurato per utilizzare "reindirizzamento http".
Per abilitare il reindirizzamento HTTP, utilizzare il seguente comando:

webbridge http-redirect enable

Per far sapere a Call Bridge che Web Bridge può considerare attendibili le connessioni da Call Bridge, utilizzare il comando:

webbridge trust <certfile>

dove si tratta di un file contenente tutti e tre i certificati di ciascun server nel cluster.

Questa immagine dovrebbe essere su ogni server del cluster.


Ora dobbiamo creare un utente con il ruolo “appadmin”, ci serve per poter configurare il nostro cluster(!), e non ogni server del cluster separatamente, in questo modo le impostazioni verranno applicate equamente a ciascun server nonostante fatto che verranno realizzati una volta.


Per ulteriori configurazioni utilizzeremo Postino.

Per l'autorizzazione, seleziona Base nella sezione Autorizzazione

Per inviare correttamente i comandi al server CMS è necessario impostare la codifica richiesta

Specifichiamo Webbridge con il comando POST con parametro URL e significato cms.esempio.com



Nel webbridge stesso indichiamo i parametri richiesti: accesso ospite, accesso protetto, ecc.

Gruppi di chiamate in parallelo

Per impostazione predefinita, il CMS non sempre utilizza nel modo più efficiente le risorse di conferenza a sua disposizione.

Ad esempio, per una riunione con tre partecipanti, ciascun partecipante potrebbe trovarsi su tre diversi Call Bridge. Affinché questi tre partecipanti possano comunicare tra loro, Call Bridges stabilirà automaticamente connessioni tra tutti i server e client nello stesso spazio, in modo che sembri che tutti i client siano sullo stesso server. Sfortunatamente, lo svantaggio è che una singola conferenza di 3 persone ora consumerà 9 porte multimediali. Si tratta evidentemente di un uso inefficiente delle risorse. Inoltre, quando un Call Bridge è veramente sovraccarico, il meccanismo predefinito è continuare ad accettare chiamate e fornire un servizio di qualità ridotta a tutti gli abbonati di quel Call Bridge.

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

Per risolvere il problema della riconnessione sono stati introdotti tre limiti di carico configurabili per ciascun Call Bridge:

Limite di carico — è il carico numerico massimo per un particolare Call Bridge. Ogni piattaforma ha un limite di carico consigliato, ad esempio 96000 per CMS1000 e 1.25 GHz per vCPU per la macchina virtuale. Chiamate diverse consumano una certa quantità di risorse a seconda della risoluzione e del frame rate del partecipante.
NewConferenceLoadLimitBasisPoints (predefinito 50% loadLimit): imposta il limite di carico del server, dopo il quale le nuove conferenze vengono rifiutate.
ExistingConferenceLoadLimitBasisPoints (predefinito 80% di loadLimit) - il valore di carico del server dopo il quale i partecipanti che si uniscono a una conferenza esistente verranno rifiutati.

Sebbene questa funzionalità sia stata progettata per la distribuzione delle chiamate e il bilanciamento del carico, anche altri gruppi come TURN Server, Web Bridge Server e Registratori possono essere assegnati ai gruppi Call Bridge in modo che possano essere raggruppati correttamente per un utilizzo ottimale. Se uno qualsiasi di questi oggetti non è assegnato a un gruppo di chiamata, si presuppone che sia disponibile per tutti i server senza alcuna priorità particolare.

Questi parametri sono configurati qui: cms.esempio.com:445/api/v1/system/configuration/cluster

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

Primo ponte di chiamata

Secondo ponte di chiamata

Terzo ponte di chiamata


Pertanto, abbiamo configurato il gruppo Call Brdige per utilizzare in modo più efficiente le risorse del cluster Cisco Meeting Server.

Importazione di 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 sono archiviate nel database del cluster, quindi la configurazione dovrà essere eseguita manualmente su ciascun server tramite l'interfaccia Web o tramite l'API, e in modo che “tre volte “Non alzarci” imposteremo comunque i dati tramite l'API.

Utilizzo dell'URL per accedere cms01.esempio.com:445/api/v1/ldapServers crea un oggetto Server LDAP, specificando parametri come:

• Indirizzo IP del server
• numero di porta
• имя пользователя
• пароль
• sicuro

Sicuro: seleziona vero o falso a seconda della porta, 389 - non sicuro, 636 - protetto.


Mappatura dei parametri di origine LDAP sugli attributi in Cisco Meeting Server.
La mappatura LDAP mappa gli attributi nella directory LDAP agli attributi nel CMS. Gli attributi effettivi:

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

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

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

coSpaceNameMapping crea un nome di spazio CMS in base al campo displayName. Questo attributo, insieme all'attributo coSpaceUriMapping, è ciò che è necessario per creare uno spazio per ciascun utente.

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

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

Il server LDAP e la mappatura LDAP sono configurati. Ora devi collegarli insieme creando una fonte LDAP.

Utilizzo dell'URL per accedere cms01.esempio.com:445/api/v1/ldapSource crea un oggetto LDAP Source, specificando parametri come:

• server
• mappatura
• baseDn
• filtro

Ora che la configurazione LDAP è completa, puoi eseguire l'operazione di sincronizzazione manuale.

Lo facciamo nell'interfaccia Web di ciascun server facendo clic Sincronizza ora sezione Active Directory


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

Conferenze ad hoc

Che cosa è questo?Nel concetto tradizionale, una conferenza avviene quando due partecipanti parlano tra loro e uno dei partecipanti (utilizzando un dispositivo registrato con Unified CM) preme il pulsante "Conferenza", chiama l'altra persona e dopo aver parlato con quella terza parte , preme nuovamente il pulsante "Conferenza" per unire tutti i partecipanti alla conferenza tripartita.

Ciò che distingue una conferenza ad hoc da una conferenza pianificata in un CMS è che una conferenza ad hoc non è semplicemente una chiamata SIP a un CMS. Quando l'iniziatore della conferenza fa clic una seconda volta sul pulsante Conferenza per invitare tutti alla stessa riunione, Unified CM deve effettuare una chiamata API al CMS per creare una conferenza al volo alla quale verranno poi trasferite tutte le chiamate. Tutto ciò avviene senza che i partecipanti se ne accorgano.

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

Se necessario, CUCM può creare dinamicamente uno spazio nel CMS in modo che ogni chiamata possa raggiungere il CMS e corrispondere alla regola delle chiamate in entrata prevista per gli spazi.

Integrazione con CUCM configurato nello stesso modo descritto nell'articolo prima tranne che su Cisco UCM è necessario creare tre trunk per il CMS, tre Conference Bridge, nel profilo di sicurezza SIP specificare tre nomi oggetto, gruppi di instradamento, elenchi di instradamento, gruppi di risorse multimediali ed elenchi di gruppi di risorse multimediali e aggiungere alcune regole di instradamento a Cisco Meeting Server.

Profilo di sicurezza SIP:


Bauli:


Ogni tronco ha lo stesso aspetto:




Ponte delle conferenze


Ogni Conference Bridge ha lo stesso aspetto:


Gruppo di percorsi


Elenco rotte


Gruppo di risorse multimediali


Elenco dei gruppi di risorse multimediali

Regole di chiamata

A differenza dei sistemi di gestione delle chiamate più avanzati come Unified CM o Expressway, CMS cerca solo il dominio nel campo URI di richiesta SIP per le nuove chiamate. Quindi, se SIP INVITE è per sip: [email protected]Il CMS si preoccupa solo di dominio.com. CMS segue queste regole per determinare dove instradare una chiamata:

1. Il CMS tenta innanzitutto di far corrispondere il dominio SIP ai domini configurati nelle regole delle chiamate in entrata. Queste chiamate possono quindi essere instradate verso spazi ("mirati") o utenti specifici, IVR interni o destinazioni Microsoft Lync/Skype for Business (S4B) direttamente integrate.
2. Se non c'è corrispondenza nelle regole delle chiamate in entrata, CMS tenterà di far corrispondere il dominio configurato nella tabella di inoltro delle chiamate. Se viene stabilita una corrispondenza, la regola può rifiutare esplicitamente la chiamata o inoltrarla. In questo momento, il CMS potrebbe riscrivere il dominio, operazione talvolta utile per chiamare domini Lync. Puoi anche scegliere di passare, il che significa che nessuno dei campi verrà ulteriormente modificato, o di utilizzare un dial plan CMS interno. Se non c'è corrispondenza nelle regole di inoltro di chiamata, l'impostazione predefinita è rifiutare la chiamata. Tieni presente che nel CMS, sebbene la chiamata venga "inoltrata", i media sono ancora vincolati al CMS, il che significa che saranno nel percorso di segnalazione e traffico multimediale.
Quindi solo le chiamate inoltrate sono soggette alle regole delle chiamate in uscita. Queste impostazioni determinano le destinazioni a cui vengono inviate le chiamate, il tipo di trunk (se si tratta di una nuova chiamata Lync o di una chiamata SIP standard) ed eventuali conversioni che possono essere eseguite se il trasferimento non è selezionato nella regola di inoltro delle chiamate.

Ecco il registro effettivo di ciò che accade durante una conferenza ad hoc

Lo screenshot lo mostra male (non so come migliorarlo), quindi scriverò il registro in questo modo:

Info	127.0.0.1:35870: API user "api" created new space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call create failed to find coSpace -- attempting to retrieve from database

Info	API "001036270012" Space GUID: 7986bb6c-af4e-488d-9190-a75f16844e44 <--> Call GUID: 93bfb890-646c-4364-8795-9587bfdc55ba <--> Call Correlator GUID: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 <--> Internal G

Info	127.0.0.1:35872: API user "api" created new call 93bfb890-646c-4364-8795-9587bfdc55ba

Info	call 7: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

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

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 has control/media GUID: fb587c12-23d2-4351-af61-d6365cbd648d

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 named "001036270012"

Info	call 7: configured - API call leg bc0be45e-ce8f-411c-be04-594e0220c38e with SIP call ID "[email protected]"

Info	call 7: setting up UDT RTP session for DTLS (combined media and control)
Info	conference "001036270012": unencrypted call legs now present

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 8: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

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

Info	call 8: configured - API call leg db61b242-1c6f-49bd-8339-091f62f5777a with SIP call ID "[email protected]"

Info	call 8: setting up UDT RTP session for DTLS (combined media and control)

Info	call 9: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

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

Info	call 9: configured - API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a with SIP call ID "[email protected]"

Info	call 9: setting up UDT RTP session for DTLS (combined media and control)
Info	call 8: compensating for far end not matching payload types

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (289e823d-6da8-486c-a7df-fe177f05e010) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 7: compensating for far end not matching payload types
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: compensating for far end not matching payload types

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (d27e9a53-2c8a-4e9c-9363-0415cd812767) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 9: BFCP (client role) now active
Info	call 9: sending BFCP hello as client following receipt of hello when BFCP not active
Info	call 9: BFCP (client role) now active
Info	call 7: ending; remote SIP teardown - connected for 0:13
Info	call 7: destroying API call leg bc0be45e-ce8f-411c-be04-594e0220c38e

Info	participant "[email protected]" left space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call 9: on hold
Info	call 9: non matching payload types mode 1/0
Info	call 9: answering offer in non matching payload types mode
Info	call 8: on hold
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: ending; remote SIP teardown - connected for 0:12

La conferenza ad hoc stessa:


Regole per le chiamate in entrata
La configurazione dei parametri delle chiamate in entrata è necessaria per poter ricevere una chiamata nel CMS. Come hai visto nella configurazione LDAP, tutti gli utenti sono stati importati con il dominio conf.pod6.cms.lab. Quindi, come minimo, vuoi che le chiamate a questo dominio abbiano come target gli spazi. Dovrai inoltre impostare regole per tutto ciò che è destinato al nome di dominio completo (e forse anche all'indirizzo IP) di ciascuno dei server CMS. Il nostro controllo delle chiamate esterne, Unified CM, configurerà i trunk SIP dedicati a ciascuno dei server CMS individualmente. A seconda che la destinazione di questi trunk SIP sia un indirizzo IP o l'FQDN del server, determinerà se il CMS deve essere configurato per accettare chiamate dirette al suo indirizzo IP o FQDN.

Il dominio che ha la regola in entrata con la priorità più alta viene utilizzato come dominio per qualsiasi spazio utente. Quando gli utenti si sincronizzano tramite LDAP, il CMS crea automaticamente gli spazi, ma solo la parte utente dell'URI (coSpaceUriMapping), ad esempio user.space. Parte dominio L'URI completo viene generato in base a questa regola. Infatti, se a questo punto dovessi accedere a Web Bridge, vedresti che l'URI dello spazio non ha un dominio. Impostando questa regola come priorità più alta, stai impostando il dominio per gli spazi generati conf.esempio.com.


Regole per le chiamate in uscita

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

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

Campo Locale dal dominio è responsabile di ciò che verrà visualizzato nell’URI SIP del chiamante per la persona 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 specifichiamo un dominio, dopo il simbolo “@” ci sarà effettivamente un dominio. Ciò è necessario per poter richiamare, altrimenti non sarà possibile richiamare tramite SIP-URI nome@indirizzo-ip.

Chiamare quando indicato Locale dal dominio


Chiama quando NON indicato Locale dal dominio


Assicurati di specificare esplicitamente Encrypted o Unencrypted per le chiamate in uscita, perché non funziona nulla con il parametro Auto.

Registrazione

Le videoconferenze vengono registrate dal Record server. Il registratore è esattamente uguale a Cisco Meeting Server. Il registratore non richiede l'installazione di alcuna licenza. Le licenze di registrazione sono necessarie per i server che eseguono i servizi CallBridge, ad es. è necessaria una licenza di registrazione che deve essere applicata al componente CallBridge e non al server su cui è in esecuzione Recorder. Il registratore si comporta come un client XMPP (Extensible Messaging and Presence Protocol), quindi il server XMPP deve essere abilitato sul server che ospita CallBridge.

Perché Abbiamo un cluster e la licenza deve essere "estesa" su tutti e tre i server del cluster. Quindi semplicemente nel tuo account personale nelle licenze associamo (aggiungiamo) gli indirizzi MAC delle interfacce a di tutti i server CMS inclusi nel cluster.

E questa è l'immagine che dovrebbe essere presente su ogni server del cluster

In generale, esistono diversi scenari per posizionare il registratore, ma ci limiteremo a questo:


Prima di configurare Recorder è necessario predisporre un luogo in cui verranno effettivamente registrate le videoconferenze. In realtà qui collegamento, come impostare tutte le registrazioni. Mi concentro su punti e dettagli importanti:

1. È meglio trasferire il certificato dal primo server nel cluster.
2. L'errore "Registratore non disponibile" può verificarsi perché nel Recorder Trust è specificato il certificato errato.
3. La scrittura potrebbe non funzionare se la directory NFS specificata per la registrazione non è la directory root.

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

Per questo vengono creati due CallProfile:
Con registrazione disabilitata


E con funzione di registrazione automatica


Successivamente, “alleghiamo” un CallProfile con una funzione di registrazione automatica allo spazio desiderato.


Nel CMS è così stabilito che se un CallProfile è esplicitamente legato a qualsiasi spazio o spazio, allora questo CallProfile funziona solo in relazione a questi spazi specifici. E se CallProfile non è associato ad alcuno spazio, per impostazione predefinita viene applicato a quegli spazi a cui nessun CallProfile è esplicitamente associato.

La prossima volta proverò a descrivere come si accede al 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