Meccanismo di distribuzione delle chiamate CUCM nel trunk SIP/H323

Introduzione

Questo documento descrive il modus operandi utilizzato da Cisco Unified Communications Manager per decidere quali nodi CUCM vengono utilizzati per inviare chiamate tramite il protocollo SIP (Session Initiation Protocol) o i trunk basati su H.323.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Concetti base di Cisco Unified Communications Manager (CUCM) routing delle chiamate

Componenti usati

 Il riferimento delle informazioni contenute in questo documento è Cisco Unified Communications Manager (CUCM) versione 8.x e successive.

 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.

Premesse

I trunk SIP e i gateway H.323 non si registrano con CUCM (a differenza dei gateway MGCP). Al contrario, il gruppo CUCM associato al pool di dispositivi collegato al trunk o al gateway determina dove saranno attivi. Ad esempio, se sono attivi su 2 o 3 nodi, quale meccanismo viene utilizzato da CUCM per decidere a quale server inviare la chiamata.

L'obiettivo di questo documento è spiegare come vengono prese le decisioni relative al routing delle chiamate e come è possibile raggiungere il bilanciamento del carico per le chiamate in uscita tramite SIP Trunk o H.323.

Meccanismo di routing della chiamata precedente a CUCM 8.5 (non utilizzando la funzione Esegui su tutti i nodi CM unificati attivi)

Logica generale: Per una chiamata in uscita, una volta che CUCM ha eseguito l'analisi della cifra, estende la chiamata al RouteList o al dispositivo terminale.  (RouteList viene registrato in un particolare nodo, che dipende dal gruppo CUCM)

Il controllo RouteList identifica l'elenco di dispositivi e interroga Gestione dispositivi.
Gestione dispositivi fornisce l'ID processo (PID) del dispositivo (esempio: (2,100,25,45), in questo esempio il dispositivo è attivo sul nodo 2)

Il controllo RouteList controlla lo stato del dispositivo (è il dispositivo di destinazione attivo, inattivo o occupato) ed estende la chiamata al trunk o al gateway.

Poiché i trunk SIP / H.323 gateway possono essere attivi su più nodi, la domanda inizia ora da quale nodo viene selezionato come PID attivo dal gestore dei dispositivi?

Questi scenari di utilizzo forniscono ulteriori informazioni:

Caso di utilizzo 1: Telefoni IP registrati nel nodo 1. Nessun RouteList configurato.

In questo SIP, il trunk è attivo sui nodi 1 e 4.

• La logica generale rimane la stessa, CUCM esegue l'analisi della cifra sul nodo 1 dove il telefono è registrato. Poiché non è configurato alcun RouteList, il modello di route è associato direttamente al trunk SIP.
  
  
• CUCM nel nodo 1 esegue una query su Gestione dispositivi nel nodo 1.
  
  
• In Gestione periferiche (DM) controllare sempre prima la tabella locale e restituire l'eventuale periferica locale per evitare comunicazioni/traffico tra cluster non necessari.

In questo caso, il trunk SIP è attivo sul nodo 1 dove il telefono è registrato, quindi CUCM estende la chiamata dal nodo 1 (ogni volta). La logica casuale non viene applicata in questo caso e non è presente alcun bilanciamento del carico poiché la chiamata viene estesa dal nodo 1 in ogni caso.

Caso di utilizzo 2: Telefoni IP registrati al nodo 1. RouteList registrato al nodo 2.

In questo SIP Trunk è attivo sui nodi 2 e 4.

• Dopo i risultati dell'analisi della cifra (DA), il nodo 1 CUCM estende la chiamata al controllo RouteList nel nodo 2.
  
  
• Il controllo RouteList nel nodo 2 esegue una query su Gestione dispositivi nel nodo 2.
  
  
• DM controlla sempre prima la tabella locale e restituisce un dispositivo locale se ne esiste uno, in questo caso il trunk SIP è locale rispetto al nodo 2.

Di conseguenza, indipendentemente dalla posizione in cui il telefono è registrato, dal momento che RouteList è registrato nel nodo 2 e Sip trunk è attivo sullo stesso nodo, tutte le chiamate sono sorgente dal nodo 2. Di nuovo, la logica casuale non viene applicata.

Caso di utilizzo 3: Telefoni IP registrati al nodo 1. RouteList registrato al nodo 2.

In questo gateway H323 è attivo sui nodi 1 e 4.

• Dopo i risultati di DA, CUCM sul nodo 1 estende la chiamata al controllo RouteList sul nodo 2.
  
  
• Il controllo RouteList nel nodo 2 esegue una query su Gestione dispositivi nel nodo 2.
  
  
• In Gestione periferiche (DM) la tabella locale viene sempre controllata per prima e la periferica locale non viene restituita.
  
  
• Gestione dispositivi cerca RemoteTable e rileva il gateway H.323 attivo sui nodi 1 e 4.

Applica la logica casuale e fornisce un PID attivo in modo casuale al controllo RouteList. Poiché viene inviato casualmente tra i nodi 1 e 4, le chiamate vengono bilanciate in CUCM.

Conclusioni

CUCM verifica se il gateway SIP trunk/H.323 è attivo sullo stesso nodo del dispositivo chiamante. In tal caso, utilizza sempre il nodo locale per inviare la chiamata in uscita.
Se il gateway SIP trunk/H.323 non è attivo sullo stesso nodo del dispositivo chiamante, l'origine avviene in modo casuale dai nodi in cui il trunk/dispositivo è attivo.

Nota: Il dispositivo chiamante può essere un telefono o un RouteList.  Se il modello di route corrisponde a un oggetto RouteList, la parte chiamante sarà RouteList. Se il percorso è associato direttamente al dispositivo SIP/H.323, la persona che chiama è il telefono.

Bilanciamento del carico

Se si desidera ottenere il bilanciamento del carico, non è consigliabile co-individuare RouteList o il telefono con i nodi CUCM a cui sono associati i gateway SIP/H.323, ovvero se sono entrambi attivi sullo stesso nodo, le chiamate verranno inviate dal nodo locale (sempre).

In altre parole, il gateway SIP trunk/H.323 deve essere configurato in modo che non sia attivo sui nodi in cui sono registrati il RouteList o i telefoni.

A partire dalla versione 8.6 di CUCM, CUCM ha introdotto una nuova funzionalità chiamata Run su tutti i nodi CM unificati attivi per entrambi i trunk RouteList/SIP.     

Questo è un altro modo per bilanciare in modo efficiente il carico delle chiamate in uscita e ridurre il numero di segnali scambiati all'interno del cluster.

Meccanismo di routing delle chiamate post-CUCM 8.5 (eseguito su tutte le funzionalità dei nodi CM unificati attivi in uso)

In CUCM 8.5 e versioni successive Cisco ha introdotto una nuova funzione sui trunk sip e Route List chiamata Run su tutti i nodi CM unificati attivi. In questo modo viene rimossa la dipendenza del trunk sip e dell'elenco di route dal gruppo CUCM assegnato. Ciò significa che è possibile disporre di più di tre server CUCM che generano e terminano chiamate da e verso un trunk SIP.

Trunk SIP - Esegui su tutti i nodi e regola locale route

Quando l'opzione Esegui su tutti i nodi CM unificati attivi è selezionata su un trunk SIP, CM unificato crea un'istanza del daemon trunk SIP su ogni sottoscrittore di elaborazione delle chiamate all'interno del cluster, consentendo in tal modo di effettuare o ricevere una chiamata trunk SIP su qualsiasi sottoscrittore di elaborazione delle chiamate. (Prima di questa funzione, era possibile selezionare fino a tre nodi per trunk utilizzando Unified CM Groups.)

Se l'opzione Esegui su tutti i nodi CM unificati attivi è abilitata, le chiamate trunk SIP in uscita hanno origine dallo stesso nodo in cui viene ricevuta la chiamata in entrata, ad esempio da un telefono o da un trunk, in base alla regola locale route. La funzionalità Esegui su tutti i nodi CM unificati attivi ha la precedenza sulla configurazione del gruppo CM unificato del trunk.

Per i trunk SIP, questo è il funzionamento della regola locale route:

Per le chiamate trunk SIP in uscita, quando una chiamata da un telefono registrato o da un trunk in entrata arriva a un nodo CM unificato, CM unificato verifica se esiste un'istanza del trunk in uscita selezionato nello stesso nodo in cui è arrivata la chiamata in entrata. In tal caso, Unified CM utilizza questo nodo per stabilire la chiamata trunk in uscita.

Si consiglia di abilitare l'esecuzione su tutti i nodi CM unificati attivi sui trunk SIP perché questa funzionalità consente alle chiamate in uscita di avere origine e di essere ricevute su qualsiasi nodo di elaborazione delle chiamate all'interno del cluster. L'esecuzione su tutti i nodi CM unificati attivi può inoltre impedire l'impostazione di chiamate tra nodi di elaborazione delle chiamate all'interno dello stesso cluster prima di essere stabilite tramite il trunk SIP in uscita.

Come per tutti i trunk SIP di Unified CM, i daemon SIP associati al trunk accettano le chiamate in entrata solo dai sistemi terminali con indirizzi IP definiti nei campi degli indirizzi di destinazione del trunk.

Quando più trunk SIP verso la stessa destinazione o le stesse destinazioni utilizzano gli stessi nodi di elaborazione delle chiamate, è necessario definire un numero di porta di destinazione e in ingresso univoco per ciascun trunk in modo da consentire l'identificazione univoca di ciascun trunk.

Elenchi di route: esecuzione in tutti i nodi e regola locale di route

Anche se non si tratta di una funzionalità trunk SIP specifica, l'esecuzione di elenchi di percorsi su tutti i nodi offre vantaggi ai trunk negli elenchi e nei gruppi di percorsi. L'esecuzione di elenchi di route in tutti i nodi migliora la distribuzione delle chiamate in uscita utilizzando la regola locale di route per evitare traffico di installazione delle chiamate indesiderate tra cluster.

Per gli elenchi di route, questa è la modalità di funzionamento della regola locale di route:

Per le chiamate in uscita che utilizzano gli elenchi di route (e i gruppi di route e i trunk associati), quando una chiamata da un telefono registrato o da un trunk in ingresso arriva al nodo con l'istanza dell'elenco di route, CM unificato verifica se esiste un'istanza del trunk in uscita selezionato nello stesso nodo dell'elenco di route. In tal caso, Unified CM utilizza questo nodo per stabilire la chiamata trunk in uscita.

• Se sia l'elenco di route che il trunk sono eseguiti su tutti i nodi CM unificati attivi abilitati, la distribuzione delle chiamate in uscita è determinata dal nodo in cui arriva la chiamata in ingresso.
  
  
• Se il trunk in uscita selezionato utilizza Gruppi CM unificati anziché essere in esecuzione in tutti i nodi, CM unificato applica la regola Locale route se un'istanza del trunk in uscita selezionato esiste nello stesso nodo in cui arriva la chiamata in entrata.
  
  
• Se in questo nodo non esiste un'istanza del trunk, Unified CM inoltra la chiamata (all'interno del cluster) a un nodo in cui il trunk è attivo.
  
  
• Se per l'elenco di route non è abilitata l'opzione Esegui su tutti i nodi CM unificati attivi, un'istanza dell'elenco di route sarà attiva su un nodo all'interno del cluster, ovvero il nodo principale del gruppo CM unificato dell'elenco di route.
  
  
• Se il trunk in uscita selezionato è attivo anche nel nodo primario del gruppo CM unificato dell'elenco di route, viene applicata la regola Locale route, che determina una distribuzione delle chiamate in uscita non ottimale perché tutte le chiamate in uscita provengono da questo nodo.

Cisco consiglia di abilitare l'esecuzione su tutti i nodi CM unificati attivi su tutti gli elenchi di route e i trunk SIP.