Questo documento spiega come le geolocalizzazioni, i filtri di geolocalizzazione e il partizionamento logico possono essere utilizzati in paesi, come l'India, che devono separare le chiamate off-net dalle chiamate on-net. La classe di servizio fornita da Calling Search Spaces (CSS) e Partizioni potrebbe non fornire il livello di granularità necessario per conformarsi a determinate leggi e normative. È inoltre possibile che questi stessi elementi vengano utilizzati nelle configurazioni EMCC (Extension Mobility Cross Cluster). Fare riferimento alla Guida alle funzionalità e ai servizi di Cisco Unified Communications Manager per la versione 7.1(2), in cui viene spiegato come filtrare i dati in modo da individuare una posizione più specifica. Le componenti geografiche non vengono ulteriormente discusse nel presente documento. Piuttosto, l'obiettivo di questo documento è di esaminare come tutto funziona insieme dal punto di vista logistico.
Nessun requisito specifico previsto per questo documento.
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.
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
I seguenti elementi principali sono disponibili nella pagina CCMAdmin di Cisco Unified Communications Manager (CUCM) (CallManager):
In CCMAdmin passare a Parametri enterprise > Configurazione partizionamento logico. Esistono quattro parametri che possono influire sulle georilevazioni e sul partizionamento logico. Ricorda che:
Se si apportano modifiche alla configurazione e non si riesce a capire perché non funziona nel modo previsto, esaminare le georilevazioni assegnate direttamente agli endpoint, ad esempio il telefono, nonché i trunk e i gateway, ad esempio il trunk SIP. Se non esiste una georilevazione assegnata direttamente a un telefono, un trunk o un gateway, esaminare rispettivamente la georilevazione e il filtro di georilevazione assegnati ai pool di dispositivi. Se entrambi sono vuoti, esaminare il criterio predefinito elencato tra i parametri Enterprise sopra indicati.
Ora che si conoscono i dettagli assegnati al telefono (un dispositivo interno) e a un trunk o gateway (un dispositivo di bordo), è possibile corrispondere ai criteri di partizione logica. Passare a Instradamento delle chiamate > Configurazione dei criteri di partizione logica. La conoscenza e la comprensione dei criteri possono rappresentare una sfida. Uno degli obiettivi di questo documento è quello di fornire esempi utili e completi.
È possibile configurare due criteri denominati Bangalore e Chennai. Quando si apre la pagina Configurazione dei criteri di partizionamento logico, nella parte superiore della pagina è presente un nome che è sempre collegato al primo dei due tipi di dispositivo selezionati. Quando si configura il criterio di partizionamento logico Bangalore (criterio di geolocalizzazione), la relazione Consenti/Nega inizia sempre con Bangalore Interior o Bangalore Border.
Con queste due politiche, le permutazioni possibili sulla pagina Bangalore Policy includono:
Con queste due politiche, ci sono anche otto possibili permutazioni nella pagina Chennai Policy, che includono:
Nota: Non è necessario configurare così tante relazioni tra criteri per diversi motivi. La logica di relazione non esamina la direzione. Pertanto, Bangalore Interior to Chennai Border è uguale a Chennai Border to Bangalore Interior. Evitare configurazioni in conflitto.
D: Cosa succede se vi sono conflitti o criteri che si sovrappongono?
A: C'è qualche logica, ma può essere difficile da seguire. La logica è correlata all'ultimo criterio aggiunto, non un criterio modificato, ma un criterio appena aggiunto.
Se un criterio che conteneva il valore Allow viene successivamente modificato in Deny, tale criterio rimane Deny. Anche l'opposto è vero. Un criterio impostato in precedenza su Nega, successivamente modificato in Consenti è un criterio Consenti. Il Cisco Unified Reporting > Report sulle policy di geolocalizzazione consente di identificare le policy che si sovrappongono.
D: Cosa succede se Bangalore Interior to Chennai Border è configurato in modo da consentire mentre Chennai Border to Bangalore Interior è configurato in modo da negare?
A: Se il confine tra Chennai e Bangalore Interior è l'ultimo aggiunto, la sua politica ha la precedenza.
Nota: Le politiche influiscono solo sulle relazioni tra confini, tra confini interni e tra confini, non sulle relazioni tra interni.
Tenendo presenti queste informazioni aggiuntive, è possibile ridurre drasticamente i criteri di esempio di questo documento da una combinazione di sedici voci a sette voci. Ricordate, Interior-to-Interior non è influenzato. I criteri Interno-Interno e Sovrapposizione sono barrati e pertanto non saranno più visualizzati nell'elenco.
La pagina Bangalore Policy ora include:
La pagina Chennai Policy ora include:
Un IP Phone con una geolocalizzazione Chennai che corrisponde a una policy Chennai è un dispositivo Chennai Interior. Un trunk SIP con una geolocalizzazione Chennai che corrisponde a una policy Chennai è un dispositivo di confine Chennai. Non è necessario assegnare specificamente il Device-Type. CUCM classifica automaticamente trunk, gateway e telefoni. Se si desidera che il dispositivo Chennai Interior (telefono) sia in grado di chiamare un dispositivo Chennai Border (trunk SIP) senza che la chiamata venga rifiutata, ad esempio, la chiamata riceve un segnale di occupato veloce, è necessario verificare che il criterio Chennai Interior to Chennai Border sia impostato su Allow (Consenti), senza alcuna sovrapposizione di criteri configurata successivamente.
Nota: Per eseguire il commit delle modifiche apportate ai pool di dispositivi, è necessario reimpostare i pool di dispositivi. Poiché questo può influire su molti dispositivi, le modifiche devono essere configurate dopo ore.
Nota: Nelle tracce SDI (ccm.txt) di CallManager è possibile che una chiamata venga rifiutata a causa del partizionamento logico (LP) senza l'esecuzione di un'analisi della cifra (DA). Di seguito è riportato un esempio: SIP Invite, Trying, 503 Service Non disponibile senza DA nel mezzo.
Di seguito è riportato un esempio di messaggio di rifiuto completo:
09/18/2012 21:53:48.379 CCM|Cdcc::CcRejInd: ccRejInd.c.cv = -1493172161|
<CLID::KCMCS01-Cluster> <NID::10.50.1.11><CT::2,100,45,1.1290981><IP::10.50.15.127><DEV::>
<LVL::Detailed><MASK::0800>
...
CV=-1493172161 in CcRejInd refers to Logical Partitioning denial as per this
junked Defect CSCsz91044
...
09/18/2012 21:53:48.380 CCM|//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP
message to 10.50.15.127 on port 50380 index 90345
SIP/2.0 503 Service Unavailable
Questo diagramma fornisce un esempio di geolocalizzazione e partizionamento logico.
Figura 1: Esempio di rete
Il diagramma mostra il flusso di chiamate desiderato, probabilmente a causa delle normative governative che limitano TEHO (Tail-End-Hop-Off) e Toll-Bypass:
In questa sezione vengono illustrati i passaggi eseguiti per impostare e configurare le georilevazioni e le partizioni logiche in CUCM.
Passaggio 1: Configurare queste impostazioni in Parametri del servizio Enterprise. Tenere presente se si imposta il criterio predefinito di partizionamento logico su Nega o Consenti. Questa operazione è importante. Per questo esempio di configurazione, il valore è Deny (Nega).
Figura 2: Configurazione partizionamento logico CUCM
Passaggio 2: Andare alla Configurazione filtro di georilevazione e specificare un singolo filtro per questa configurazione specifica. Se la configurazione è molto avanzata, è possibile specificare un valore superiore. In questo caso, specificare che deve corrispondere solo a Country.
Figura 3: Configurazione filtro georilevazione CUCM
Passaggio 3: Andare alla configurazione della georilevazione e impostare le posizioni specifiche in base alle quali filtrare. Questa operazione è molto semplice e non deve essere configurata più di per il filtro di geolocalizzazione impostato, ma in questo esempio vengono mostrate alcune configurazioni aggiuntive.
Figura 4: Elenco georilevazioni CUCM
Figura 5: Configurazione georilevazione
Figura 6: Configurazione georilevazione pagina 2
Passaggio 4: Andare alla configurazione pool di dispositivi e individuare i parametri di configurazione georilevazione. Impostarlo nella posizione in cui si trova fisicamente il telefono.
Figura 7: Configurazione pool di dispositivi
Passaggio 5: Andare alla pagina Configurazione dispositivo del telefono e selezionare la posizione in cui si trova il telefono.
Figura 8: Configurazione telefono
Passaggio 6: Andare alla pagina Configurazione dispositivo per le interfacce PRI e configurarle come unità singole e come se fossero le stesse.
Figura 9: PRI per India
Figura 10: PRI per NOI
Passaggio 7: Questo passaggio rappresenta la parte più difficile della configurazione dei criteri di partizione logica.
Nota: Vi servono due politiche.
Figura: 11: Elenco criteri partizionamento logico
Figura 12: Politica dell'India
Figura 13: La politica indiana continua
Figura 14: Politica degli Stati Uniti
Figura 15: Politica degli Stati Uniti continua
Questa sezione spiega il significato di Bordo e Interno e come sapere quale dispositivo è Bordo versi Interno.
La terminologia utilizzata per classificare i dispositivi CUCM si basa sulla loro funzione.
I dispositivi di bordo tipici includono:
I dispositivi interni tipici includono:
Questa origine di Bordo e interno è fissa, basata sul dispositivo CUCM e non è configurabile in CUCM release 7.1.
L'intero esempio di configurazione di questo documento è stato completato con il parametro Enterprise impostato su uno stato Deny. Vedere la Figura 2. In alcune circostanze, è possibile modificare questo valore in Consenti e quindi impostare tutto ciò che si desidera negare perché è più difficile eseguire questa operazione durante la configurazione.
Per questa configurazione, è sufficiente configurare:
Revisione | Data di pubblicazione | Commenti |
---|---|---|
1.0 |
29-Apr-2013 |
Versione iniziale |