Progettazione di una soluzione SIP Trunk scalabile con vCUSP e CUBE
Sommario
Introduzione
Questo documento descrive una progettazione di rete della soluzione che consente trunk SIP (Session Initiation Protocol) scalabili per aziende e provider di servizi. In questa soluzione, viene usato un Cisco Unified SIP Proxy (CUSP) per federare le chiamate in entrata e in uscita su trunk SIP in un pool di router Cisco Unified Border Element (CUBE).
Contributo di Andres Salgado, Technical Marketing Engineer CUBE e Luis Ramirez Cisco TAC Engineer
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza dei seguenti argomenti:
- CUBO
- TCP
- SIP
- UDP
- CUSPIDE
Componenti usati
Il documento può essere consultato per tutte le versioni software o hardware.
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.
Problema
Condivisione del carico per più ambienti trunk SIP per installazioni con più elementi CUBE a causa dei requisiti di scalabilità e ridondanza di uno o più SIP fornitori.
Soluzione
Panoramica della soluzione trunk SIP scalabile con vCUSP e (v)CUBE
Segnalazione trunk SIP in ingresso da un provider di servizi terminata in CUSP. CUSP distribuisce le chiamate a un pool di router CUBE, che elaborano la segnalazione delle chiamate e configurano le sessioni multimediali in base alle esigenze. La capacità delle chiamate trunk SIP può essere scalata semplicemente aumentando le dimensioni del pool di router (v)CUBE. Pertanto, il numero di trunk SIP, indicato dal numero di indirizzi IP per il canale di segnalazione, può essere ridotto a uno solo.
È possibile aggiungere alla soluzione un secondo CUSP con il relativo trunk SIP associato per introdurre la ridondanza del trunk e il bilanciamento del carico. Il provider di servizi distribuisce le chiamate sui due trunk SIP. In caso di guasto a un CUSP, il provider di servizi indirizza tutte le chiamate ad altri trunk SIP, evitando così interruzioni del servizio. È quindi necessario che il provider di servizi abiliti il ping delle opzioni per controllare se il trunk SIP è attivo.
Inoltre, il pool di router CUBE aumenta la disponibilità complessiva della soluzione. Il guasto di qualsiasi CUBE nel pool riduce semplicemente la capacità dell'handle della chiamata della soluzione, anziché causare interruzioni del trunk SIP.
Il CUSP incorpora funzionalità del motore delle policy che consentono il routing basato su policy delle chiamate, ad esempio il routing dell'ora del giorno.
Questa guida alla progettazione illustra l'architettura e i componenti della soluzione
Descrizione della soluzione
In questa sezione viene descritta la soluzione trunk SIP scalabile di base. La soluzione di base fornisce scalabilità e bilanciamento del carico dei trunk SIP tra i CUBE.
La soluzione di base è costituita dai seguenti elementi:
·il trunk SIP del provider di servizi.
·UNA CUSPIDE
·Quattro router CUBE. Se la richiesta di chiamate in arrivo aumenta, è possibile aggiungere ulteriori CUBE senza apportare le modifiche necessarie presso il provider di servizi o Cisco Unified Communications Manager
·Cisco Unified Communications Manager
· Il percorso di segnalazione è rappresentato dalla linea blu
·Un percorso multimediale per tutti gli elementi, rappresentato dalla linea rossa
·Routing basato su tabelle supportato dalle tabelle di route CUSP
·Per la configurazione dei messaggi keepalive, usare il comando sip-options del gruppo di server. Il CUSP utilizza questi messaggi per determinare se un elemento peer è attivo o inattivo e, se determina che l'elemento è inattivo, lo contrassegna come tale e per interrompere le chiamate a esso. In questa soluzione, CUSP utilizza questo comando per verificare le connessioni con i peer Service Provider e i router CUBE
I router CUBE possono utilizzare il comando voice-class sip options-keepalive per verificare lo stato degli elementi peer. Per ulteriori informazioni sul comando, consultare:
Questa soluzione può essere sviluppata da una topologia di base a una soluzione scalabile per soddisfare l'aumento del volume delle chiamate e che ha aggiunto failover, ridondanza e routing a diversi provider di servizi. Se necessario, è possibile avere più provider di servizi, più vCUSP e più CUBE (v) in HA.
Esempio di rete - Soluzione di base
Aggiungere ridondanza trunk SIP.
In questa immagine viene mostrato un trunk SIP ridondante per lo stesso provider di servizi. I trunk SIP ridondanti garantiscono che la segnalazione SIP possa passare al trunk secondario se il trunk primario ha esito negativo e che possano essere gestite nuove richieste di chiamata. La ridondanza può essere utilizzata anche per il bilanciamento del carico.
In questo scenario vengono aggiunti questi elementi alla topologia della soluzione di base:
·Un trunk SIP aggiuntivo per il provider di servizi
·UNA CUSPIDE
Topologia per trunk SIP ridondanti dello stesso provider di servizi
sono disponibili una CUSP primaria e una secondaria. Se si verifica un errore nel trunk con il database primario, il provider di servizi contatta il database secondario CUSP.
Topologia per un trunk SIP di un secondo provider di servizi
Immagine che illustra il provider di servizi 1 e le relative connessioni in colori chiari in contrasto con il provider di servizi 2. La figura mostra che il provider di servizi può eseguire il bilanciamento del carico, la configurazione Active-Active con entrambi i CUSP. A tale scopo, è necessario che il provider di servizi riconosca gli indirizzi IP cusp1 e cusp2. Se il tentativo di raggiungere cusp1 ha esito negativo, il provider di servizi esegue il routing alla cusp2 per sostenere il carico aggiuntivo.
I criteri di routing configurati in CUSP possono essere utilizzati per controllare le chiamate in uscita verso il provider di servizi.
I provider di servizi trunk SIP possono offrire piani di assistenza che addebitano tariffe di chiamata diverse a seconda della destinazione, dell'ora del giorno. In questo caso, è possibile indirizzare le chiamate al provider di servizi di conseguenza per sfruttare la tariffa più bassa.
CUBE-to-CUSP
È possibile utilizzare metodi diversi per ottenere il bilanciamento del carico CUBE tra i proxy Cisco Unified SIP:
- È possibile configurare una destinazione di sessione basata su DNS SRV per consentire al CUBE di seguire la priorità della risposta DNS
- Gruppi di server nei peer di chiamata in uscita sul CUBE. Per utilizzare questa opzione in modo efficiente, è necessario configurare il comando voice-class sip options-keepalive profile per monitorare il CUSP associato al dial peer. Se lo stato della CUSP è inattivo, il server è contrassegnato come inattivo e il CUBO può tentare la seconda CUSP senza prima tentare di mettere la CUSP nello stato inattivo
Informazioni correlate
Feedback