Aggiungere partecipanti a una conferenza o a uno spazio esistente nella distribuzione del cluster CMS con il bilanciamento del carico abilitato

Introduzione

In questo documento viene descritto come aggiungere partecipanti a una conferenza CMS esistente nella distribuzione di CMS in cluster con il bilanciamento del carico abilitato.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Bilanciamento del carico CMS (Cisco Meeting Server)
• Conferenze ad-hoc CUCM (Cisco Unified Communications Manager)

In questo documento si presume che il bilanciamento del carico sia già configurato per i bridge di chiamate in cluster (CB) e funzioni per le chiamate dirette a questi server CMS (chiamate dirette a uno spazio CMS esistente). Ciò significa che questi requisiti sono già configurati:

• Tutti i server CMS da utilizzare per le conferenze ad hoc vengono aggiunti a CUCM > Risorse multimediali > Bridge di conferenza e vengono registrati
• Viene creato un elenco dei gruppi di risorse multimediali (MRGL) che contiene un gruppo di risorse multimediali (MRG), che contiene solo i server CMS ed è il primo gruppo nel MRGL
• Viene creato un elenco route contenente un gruppo route che contiene i server CMS e l'algoritmo di distribuzione selezionato è Circolare

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

• CMS 2.9.1
• CUCM 12.5.1

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Metodi per aggiungere un partecipante alla conferenza CMS esistente

Nota: sono disponibili tre metodi principali per aggiungere un partecipante a una conferenza CMS esistente: aggiungere un partecipante tramite API, aggiungere un partecipante tramite Controllo attivo e aggiungere un partecipante senza Controllo attivo.

1. Aggiungere un partecipante tramite API

Per utilizzare questo metodo, è necessario abilitare LoadbalanceOutgoingCalling nel gruppo Callbridge.

Per aggiungere il partecipante utilizzando questo metodo, è necessario eseguire una richiesta API POST a /calling/<active-call-id>/Participants/. La richiesta POST deve includere l'ID partecipante del partecipante che viene aggiunto alla conferenza come valore del parametro remoteParty, che fa parte della richiesta POST.

Questa richiesta POST indica al CMS di effettuare una chiamata in uscita al partecipante che viene aggiunto. Se l'opzione LoadbalanceOutgoingCalling sul gruppo Callbridge è abilitata e il servizio CMS ha raggiunto il limite di carico, trova un server CMS libero nel cluster per effettuare una chiamata in uscita al partecipante che viene aggiunto e viene creata una chiamata distribuita tra i due server. Questo è lo stesso metodo utilizzato da CMM per aggiungere partecipanti a una conferenza CMS.

2. Aggiungere un partecipante tramite il controllo attivo

Per utilizzare l'aggiunta di un partecipante al controllo attivo, è necessario prima negoziare il controllo attivo tra il server CMS e l'utente che sta aggiungendo il partecipante.

È necessario abilitare il controllo attivo sul SIP Trunk Profile configurato sul SIP Trunk che connette CUCM con CMS per abilitare il parametro Allow IX application media, e notare che il profilo SIP standard per TelePresence Conferencing lo ha abilitato per impostazione predefinita. Inoltre, è necessario abilitare LoadbalanceOutgoingCalling sul gruppo Callbridge.

Quando un partecipante viene aggiunto mediante il controllo attivo a una conferenza CMS esistente, CMS1 viene istruito dall'utente (mediante un messaggio di controllo attivo) di effettuare una chiamata in uscita al nuovo partecipante. Se viene raggiunto il valore del limite di carico configurato su CMS1 e l'utente tenta di aggiungere un nuovo partecipante con controllo attivo, CMS1 visualizza questo messaggio di errore (fino alla versione 2.9.1 di CMS):

add participant "<participant-uri>" request failed: call bridge unavailable

Ciò vale per entrambi i casi di utilizzo: quando il partecipante viene aggiunto a una conferenza ad hoc e quando viene aggiunto a uno spazio CMS esistente tramite controllo attivo. 

Questo è un comportamento difettoso e viene rilevato sotto il difetto: CSCvu72374

3. Aggiungere un partecipante senza controllo attivo

Quando un partecipante viene aggiunto senza utilizzare il controllo attivo (pertanto il supporto dell'applicazione Allow IX non è abilitato nel profilo SIP), CUCM effettua una chiamata tra l'utente che sta avviando l'azione e il nuovo partecipante. Quando l'utente è pronto a unirsi al nuovo partecipante alla conferenza, CUCM effettua una chiamata in uscita alla conferenza ad hoc in esecuzione su CMS1. Se il limite di carico viene raggiunto su CMS1, il partecipante non può essere aggiunto e CMS1 visualizza questo messaggio di errore (55 è un numero di chiamata di esempio):

call 55: ending; local teardown, system participant limit reached - not connected after 0:00

Questo messaggio di errore è un normale messaggio di errore che deve essere stampato da un server CMS quando riceve una chiamata in arrivo e dopo aver raggiunto il limite di carico massimo. Spetta quindi al server di controllo delle chiamate (CUCM o VCS) continuare a instradare la chiamata agli altri membri del cluster. Tuttavia, nel caso di una conferenza ad hoc, ciò non funziona e non è possibile poiché CUCM non dispone di un elenco percorsi per le conferenze ad hoc.

Configurazione

In questo documento viene descritto come configurare il sistema in modo da utilizzare il terzo modo per aggiungere un partecipante a una conferenza esistente (aggiungere un partecipante senza controllo attivo).

Il comportamento descritto nei passaggi di configurazione descritti in questo documento è il seguente:

1. L'utente crea una conferenza ad hoc, il server CMS1 la ospita

2. Una volta stabilita la conferenza ad hoc, CMS1 raggiunge gradualmente il limite di carico configurato (configurato tramite API in /system/configuration/cluster)

3. L'utente tenta di aggiungere un nuovo partecipante alla conferenza ad hoc in corso, tuttavia il nuovo utente non si connette alla conferenza

Nota: questa procedura di configurazione consente a un utente di aggiungere partecipanti a una conferenza ad hoc CMS esistente anche se il server CMS che ospita la conferenza ad hoc ha raggiunto il limite di carico. È possibile utilizzarla fino a quando il difetto di controllo attivo non viene corretto. Il controllo attivo viene disattivato nella conferenza ad hoc. 

Passaggio 1. Creare un nuovo profilo di sicurezza trunk SIP per Trunk1

• Selezionare System > Security > (Sistema > Sicurezza) Profilo di sicurezza trunk SIP
  
• Selezionare Aggiungi nuovo
• Impostare il nome come Trunk1 ricezione non protetta su 5040
• Impostare la modalità di protezione del dispositivo su Non protetta
• Impostare la porta in ingresso su 5040
• Selezionare Salva

Profilo di sicurezza Trunk1 SIP

Passaggio 2. Creare un nuovo profilo di sicurezza trunk SIP per Trunk2

• Selezionare Sistema > Protezione > Profilo di sicurezza trunk SIP
  
• Selezionare Aggiungi nuovo
• Impostare il nome per la ricezione non protetta Trunk2 su 5041
• Impostare la modalità di protezione del dispositivo su Non protetta
• Impostare la porta in ingresso su 5041
• Selezionare Salva

Profilo di sicurezza Trunk2 SIP

Passaggio 3. Creazione di un nuovo script di normalizzazione SIP 

• Selezionare Periferica > Impostazioni periferica > Script di normalizzazione SIP
  
• Selezionare Aggiungi nuovo
• Impostare Name su remove_conference_from_call_info_header
• Nel Contenuto, utilizzare questo script

M = {}
function M.outbound_INVITE(msg)
    msg:removeHeaderValue("Call-Info", "<urn:x-cisco-remotecc:conference>")
end
return M

• Selezionare Salva

Passaggio 4. Creazione di un nuovo profilo SIP

• Selezionare Device > Device settings > profilo SIP
  
• Selezionare il profilo SIP standard per TelePresence Conferencing e copiarlo
  
• Impostare il nome su No controllo attivo telepresence conferencing
• Deselezionare la casella di controllo Consenti supporto applicativo iX nella parte inferiore della pagina
• Selezionare Salva

Passaggio 5. Creazione di una nuova partizione

• Selezionare Instradamento chiamate > Classe di controllo > Partizione
  
• Selezionare Aggiungi nuovo
• Impostare Name su cms_adhoc_number
• Selezionare Salva

Passaggio 6. Creare un nuovo spazio di ricerca chiamante (CSS):

• Passa a Routing chiamate > Classe di controllo > Spazio di ricerca chiamate
  
• Selezionare Aggiungi nuovo
• Impostare il nome come CMS_adhoc_number
• Aggiungere la partizione creata al passaggio 5 cms_adhoc_number
• Selezionare Salva

Chiamata della configurazione dello spazio di ricerca

Passaggio 7. Creare un nuovo trunk SIP, Trunk1:

• Selezionare Device > Trunk
• Selezionare Aggiungi nuovo
• Selezionare SIP Trunk per il tipo di trunk
• Seleziona successivo
• Immettere questi valori e salvare

Nome dispositivo	Immettere un nome per il trunk SIP, Trunk1
Esegui su tutti i nodi CM unificati attivi	Controllato
Indirizzo di destinazione	Immettere l'indirizzo IP del server CUCM stesso, ad esempio 10.48.36.50
Porta di destinazione	Immettere la porta su cui è in ascolto Trunk2, 5041
Profilo di sicurezza trunk SIP	Selezionare il profilo creato al passaggio 1, Trunk1 ricezione non sicura su 5040
Profilo SIP	Selezionare il profilo creato al passaggio 4, No controllo attivo telepresence conferencing
Metodo di segnalazione DTMF	Selezionare RFC 2833
Script di normalizzazione SIP	Selezionare lo script creato al passaggio 3, remove_conference_from_call_info_header

Impostazioni SIP Trunk1

Passaggio 8. Creare un nuovo trunk SIP, Trunk2:

• Passa a Dispositivo > Trunk
• Selezionare Aggiungi nuovo
• Selezionare SIP Trunk per il tipo di trunk
• Seleziona successivo
• Immettere questi valori e salvare

Nome dispositivo	Immettere un nome per il trunk SIP, Trunk2
Esegui su tutti i nodi CM unificati attivi	Controllato
Spazio di ricerca chiamate	Selezionare il foglio di stile CSS creato al passaggio 6, CMS_adhoc_number
Indirizzo di destinazione	Immettere l'indirizzo IP o il nome di dominio completo (FQDN) del server CUCM, ad esempio 10.48.36.50
Porta di destinazione	Immettere la porta su cui Trunk1 è in ascolto, 5040
Profilo di sicurezza trunk SIP	Selezionare il profilo creato al passaggio 2, Trunk2 non secure receiver su 5041
Profilo SIP	Selezionare il profilo creato al passaggio 4, No controllo attivo telepresence conferencing
Metodo di segnalazione DTMF	Selezionare RFC 2833
Script di normalizzazione SIP	Selezionare lo script di normalizzazione esistente cisco-meeting-server-interop

Impostazioni SIP Trunk2

Passaggio 9. Creazione di una nuova serie di stesura

• Passare a Instradamento chiamate > Instradamento/risposta > Serie di stesura
  
• Selezionare Aggiungi nuovo
• Impostare la Serie di stesura a!
  
• Impostare la partizione di instradamento sulla partizione creata nel passaggio 5, cms_adhoc_number
• Selezionare la casella di controllo Priorità urgente
• Cambia classificazione chiamate in OnNet
• Impostare il gateway/elenco route come elenco route CMS già configurato (come indicato nella sezione Requisiti)
• Selezionare Salva

Motivo percorso

Lista route di bilanciamento del carico CMS

Gruppo route di bilanciamento del carico CMS

Passaggio 10. Modificare la configurazione di Conference Bridge ad hoc per CMS

• Passa alle risorse multimediali > Ponte per conferenze
  
• Selezionare il primo server CMS
• Modificare il SIP Trunk al Trunk1, il trunk SIP creato nel passaggio 7
• Selezionare la casella di controllo Sostituisci destinazione trunk SIP come indirizzo HTTPS
  
• Nel campo Nome host/Indirizzo IP, impostare l'FQDN CMS Webadmin per il server CMS specifico che deve esistere anche nel certificato Webadmin di tale server
• Selezionare Salva
• Eseguire la stessa operazione per tutti gli altri server CMS, impostare Trunk1 in modo che venga utilizzato su tutti i server, tuttavia modificare il campo Nome host/Indirizzo IP nel nome di dominio completo CMS specifico

CMS1

CMS2

CMS3

Passaggio 11. Reimpostare i trunk SIP Trunk1 e Trunk2

• Selezionare Device > Trunk
• Selezionare Trunk1 e Trunk2
• Selezionare Reimposta selezione
• Attendere che entrambi visualizzino il servizio Completo

Passaggio 12. Reimpostazione dei server ad hoc CMS

• Passare a Risorse multimediali > Ponte conferenze
• Seleziona tutti i server CMS
• Selezionare Reimposta selezione
• Attendere finché tutti i server non vengono visualizzati registrati

Verifica

Fare riferimento a questa sezione per verificare che la configurazione funzioni correttamente.

• Creare una conferenza ad hoc e verificare quale server CMS ospita la conferenza

CMS1 che ospita la conferenza ad hoc

• Controllare il carico di elaborazione multimediale corrente sul server CMS, utilizzare un'API GET to /system/load

Caricamento supporto corrente

• Impostare il limite di carico sul server su un valore inferiore al carico di elaborazione dei supporti inviando un POST a /system/configuration/cluster con il parametro loadlimit, ad esempio 1000

Modifica del limite di caricamento

• Aggiunge un nuovo partecipante alla riunione. Il partecipante viene aggiunto e viene creato un server distribuito tra CMS1 e un altro server CMS poiché CMS1 ha raggiunto il suo limite

Chiamata distribuita

Risoluzione dei problemi

Al momento non sono disponibili informazioni specifiche per la risoluzione dei problemi di questa configurazione.

È possibile utilizzare lo strumento Collaboration Solutions Analyzer per l'analisi dei log.

Informazioni correlate

• Logica di bilanciamento del carico su Cisco Meeting Server
• Documentazione di configurazione CMS
• Guide alla programmazione API e MMP CMS
• Documentazione di configurazione CUCM