Implementazione di GeoLocation tra cluster CUCM

Introduzione

In questo documento viene illustrato come estendere la georilevazione in una distribuzione a più cluster con Trasporto posizione. Con queste nuove informazioni su come ottenere il funzionamento del gruppo di utenti chiuso (CUG) tra un cluster regolamentato e non regolamentato con configurazione minima. Garantisce inoltre il rispetto delle norme regolamentari.

Termini associati alla geolocalizzazione

Posizione geografica

Per definizione, GeoLocation è una descrizione dell'area geografica fisica in cui esiste attualmente qualcosa. In CUCM, la geolocalizzazione assegna i dettagli della posizione a dispositivi come telefoni IP, trunk SIP, gateway ICT (Inter Cluster Trunk), ecc. che potrebbero avere un significato in tutta l'azienda, attraverso i cluster e i siti.

La RFC 4119 specifica 17 elementi di posizione civica e la funzione di partizionamento logico UCM ha implementato la configurazione manuale di questi 17 campi/elementi dalle configurazioni di amministrazione. Si consiglia di compilare tutti i 17 campi. I campi devono essere denominati logici e brevi.

Geolocalizzazione, filtro

Filtro georilevazione è una regola per selezionare determinati campi di georilevazione al fine di costruire una stringa di georilevazione, che può essere utilizzata per soddisfare i criteri per la funzione di partizionamento logico. cioè  fornirebbe set di campi di geolocalizzazione per i quali è necessario configurare le politiche

Identificatore geolocalizzazione

Identificatore costituito da una combinazione di tipo geolocalizzazione, filtro e dispositivo. Questo identificatore viene utilizzato per il confronto con LP e la chiamata verrà consentita o negata

Un filtro di geolocalizzazione di dispositivo + tipo di dispositivo = identificatore di geolocalizzazione

ovvero un trunk SIP in CUCM può essere rappresentato logicamente come

Bordo:Paese:IN:A1:KAR:A2:BAN 

Record criterio di geolocalizzazione (GLP)

I criteri non vengono configurati direttamente tra le georilevazioni, poiché in genere le georilevazioni hanno tutti e 17 i campi configurati e potrebbero essere univoci per ogni dispositivo UCM in un cluster. Pertanto, la configurazione delle policy tra le georilevazioni può comportare un notevole sovraccarico per un amministratore, dato il numero di georilevazioni. 

Allo scopo di definire le politiche, l'amministratore deve creare record con dati obbligatori per i campi di geolocalizzazione. A tale scopo, la configurazione fornisce il provisioning per selezionare i dati dagli elenchi a discesa che mostrano i campi di geolocalizzazione.

Questi record sono denominati record GPL (Geolocation Policy).

Nota: I record GeolocationPolicy devono essere creati in modo che i dati corrispondenti corrispondano ai campi selezionati nei filtri. La gerarchia dei campi è importante e i campi non devono essere omessi all'inizio o al centro, ma potrebbero mancare alla fine.

Se i campi specifici del filtro non sono presenti nei criteri, l'algoritmo di ricerca rimuove il campo dalla fine e cerca una possibile corrispondenza nei criteri.  

Esempio: Se è stato selezionato un campo C, A1, A2, A6 per un LP e un altro LP ha solo C, A1, A6, il CUCM tra questi 2 LP prende solo C, A1 anche se A6 è presente in entrambi i CUCM lo ignora.

Trasporto posizione

• Il trasferimento di GeoLocation da un agente utente SIP a un'altra entità tramite SIP è denominato Location Conveyance.
  
  
• Per supportare i requisiti LP, l'implementazione UCM comunica inoltre le informazioni sul tipo di dispositivo in PIDF-LO. Questo si basa sullo stato della presenza di capacità dell'agente utente, come da specifica nell'estensione SIP draft-ietf-simple-prescaps-ext-08. 
  
  
• Il trunk SIP dell'UCM supporta il trasporto della posizione in base a queste specifiche.
  
  
• Per consentire la compatibilità ICT con SIP Trunk e consentire le stesse funzionalità, ICT/H225 Trunk supporta anche il trasferimento della posizione attraverso il cluster utilizzando PIDF-LO. 
  
  
• L'UCM supporta la trasmissione di informazioni sulla posizione sia al momento della chiamata che in caso di modifiche della posizione dovute alla modifica della parte connessa nella partecipazione ai join e ai reindirizzamenti midcall.  

Implementazione della georilevazione in un cluster CUCM

Presupposto: Avere una conoscenza di base della geolocalizzazione e del perché è necessaria. 

Per questo documento sono stati utilizzati 2 cluster CUCM. Si presume che un cluster risieda negli Stati Uniti e un altro cluster residente in India. Utilizziamo CUCM versione 11.5 e 10.5 a scopo dimostrativo. Abbiamo un trunk SIP tra i cluster. Il dial plan è impostato in modo che solo le chiamate interne siano consentite su questo trunk ICT/SIP da entrambi i cluster che utilizzano CSS e partizione. Il dial plan è stato impostato in modo che le chiamate VOIP a PSTN utilizzino il gateway locale per effettuare chiamate PSTN utilizzando CSS e partizione.

Il cluster India è un cluster abilitato/abilitato alla partizione logica. Il cluster USA è un cluster con partizione logica disabilitata/non riconosciuta. La geolocalizzazione e il filtro di geolocalizzazione sono configurati e applicati a tutti i dispositivi di entrambi i cluster. Per il momento, configurare la partizione logica solo nel cluster indiano, in seguito si verificherà un limite a causa del quale la geolocalizzazione è abilitata e configura la partizione logica anche nel cluster USA.  

India VOIP extension: 7XXX (7001, 7002)

Estensione VOIP USA:  5XXX (5005)

Estensione PSTN: 1XXX (1005)

Questa è l'immagine con gli identificatori di geolocalizzazione.

Premesse

Per quanto riguarda l'India, si applica il regolamento sulle reti transeuropee di trasporto. In parole semplici, non combinare una chiamata VOIP non locale con una chiamata PSTN locale. Le chiamate ai gruppi di utenti chiusi (CUG) sono consentite, ad esempio le chiamate VOIP all'interno della stessa rete aziendale sono consentite.

Se si dispone di più cluster CUCM in posizioni geografiche diverse e uno di essi è regolamentato, l'obiettivo sarà

1. Rispetto delle norme TRAI o regolamentari
2. Con CUG funzionante 

Teoria

Per ottenere il funzionamento di CUG, il trasferimento della posizione viene utilizzato per estendere l'applicazione dei criteri di partizionamento logico, ovvero le informazioni di geolocalizzazione vengono inviate ad altri cluster quando l'opzione Invia dati geolocalizzazione viene controllata su ICT e SIP trunk su entrambi i cluster. In questo modo è possibile inviare e ricevere le informazioni di geolocalizzazione dei dispositivi e, insieme a ciò, è possibile sapere se il dispositivo è un bordo o interno.

Per la configurazione iniziale della chiamata, è necessario disporre di una policy che consenta la comunicazione tra il telefono IP A e l'ICT. Una volta inviato SIP INVITE ad altri cluster, viene individuato il dispositivo di destinazione B e, quando il dispositivo sta suonando o/e ha risposto alla chiamata, le informazioni di geolocalizzazione del dispositivo B vengono inviate al cluster di origine tramite un messaggio SIP INVITE/UPDATE. Quando il cluster di origine riceve informazioni di geolocalizzazione valide nel messaggio INVITE/UPDATE che sostituisce la configurazione di geolocalizzazione del trunk SIP locale e la sostituisce con la geolocalizzazione ricevuta.

Con queste nuove informazioni di geolocalizzazione, è possibile configurare un criterio di partizione logica per consentire a VOIP di effettuare chiamate VOIP e negare la chiamata VOIP dal cluster che raggiunge il dispositivo di bordo di un cluster diverso.

Nota: In questo scenario, tutti i cluster devono avere georilevazioni e filtri di georilevazione configurati e applicati a tutti i pool di dispositivi. Le chiamate tra cluster includono i dati di geolocalizzazione e se il partecipante è considerato interno o bordo. Se i dati di georilevazione non vengono ricevuti in una chiamata tra cluster, vengono utilizzati i filtri di georilevazione e georilevazione nella configurazione trunk o ereditati dal pool di dispositivi del trunk.

Progettazione

Per progettare la geolocalizzazione e la partizione logica, pensate a

• Come identificare in modo univoco la posizione fisica del dispositivo che effettua la chiamata e del dispositivo che riceve la chiamata?
• Raccogliere informazioni su quale geolocalizzazione/luogo fisico è necessario disporre di restrizioni di chiamata.
• Tra i 17 campi, che se selezionati, è possibile decidere se consentire o rifiutare la chiamata. 

Nei campi di geolocalizzazione sono presenti 17 campi, che vanno da A1 a A6 fino al CAP. Per riempire da A1 è come ingrandire una mappa. Maggiore è la quantità di dettagli inseriti, più accuratamente è possibile individuare la posizione del dispositivo a cui è assegnata questa geolocalizzazione. La cosa da considerare è, tra tutti i campi in geolocalizzazione quali campi dovrebbero una coppia di dispositivi presenti a CUCM con cui si è in grado di prendere una decisione di partizione logica efficace.

Quando è configurato il criterio Partizioni logiche, è possibile selezionare un set di campi di geolocalizzazione, selezionare tali campi in modo che quando un dispositivo effettua una chiamata presenti un set di identificativi di geolocalizzazione a CUCM e il dispositivo di destinazione riceva una chiamata che presenta un set di identificativi di geolocalizzazione a CUCM. Se questi campi corrispondono a un criterio di partizione logica predefinito, è possibile applicare restrizioni alle chiamate.

Esempio. Se il dispositivo A dispone di una georilevazione A1=IN,A2=BAN,NAM=BGL14 e il dispositivo B di una georilevazione A1=IN,A2=MUM,NAM=BAN1. Creare un criterio di georilevazione 1 tale che A=IN,A2=BAN,NAM=BGL14. Creare il criterio 2 A=IN,A2=MUM,NAM=BAN1. È necessario consentire o negare l'accesso tra i dispositivi che soddisfano i criteri 1 e 2.

Se viene effettuata una chiamata e il dispositivo di origine dispone di informazioni di geolocalizzazione A1=IN,A2=BAN,NAM=BGL14, CUCM saprà che è possibile selezionare il criterio 1. Se il dispositivo di destinazione dispone anche di informazioni di geolocalizzazione A1=IN,A2=MUM,NAM=BAN1, CUCM sa che si tratta di una corrispondenza perfetta per la relazione di partizione logica tra i criteri 1 e 2.

Nota: È consigliabile che i campi Filtro georilevazione e i campi di criteri di partizione logica selezionati abbiano gli stessi campi selezionati e corrispondenti o che il campo di criteri di partizione logica sia un sottoinsieme di campi Filtro georilevazione, in modo che quando viene effettuata una chiamata vi sia un criterio di partizione logica corrispondente nella prima iterazione. È consigliabile cercare una corrispondenza perfetta durante le chiamate.

Configurazione sul CUCM

La configurazione del cluster India può essere suddivisa in queste parti:

Configura georilevazione

In questo caso, vengono create tre geolocazioni.

• Per i dispositivi in India: India_GL
• Per SIP trunk in ICT: India_ICT_GL
• Per i dispositivi negli Stati Uniti: GL_US

Nota: Nel cluster India, viene configurato Empty_GL che viene specificato come geolocalizzazione predefinita. In questo modo, se si dimentica di aggiungere la geolocalizzazione a qualsiasi dispositivo tramite pool di dispositivi, questa geolocalizzazione verrà utilizzata per negare le chiamate a qualsiasi dispositivo di confine.

Questa immagine mostra la configurazione India_GL.

Questa immagine mostra la configurazione India_ICT_GL.

Questa immagine mostra la configurazione US_GL.

Come mostrato nell'immagine, per il filtro di geolocalizzazione vengono utilizzati i campi Nazione, A1, A2, NAM.

Abilita geolocalizzazione

Abilitare il partizionamento logico nel parametro enterprise, impostare un criterio predefinito su Nega e applicare la geolocalizzazione predefinita come Empty_GL.

Assegna georilevazione ai dispositivi

• Sul pool di dispositivi CUCM per telefono IP assegnare India_GL.

• Nel trunk SIP ICT assegnare India_ICT_GL e selezionare per inviare le informazioni di geolocalizzazione.

Al termine, passare al cluster UC. È necessario creare un criterio di geolocalizzazione per gli Stati Uniti e associarlo ai dispositivi nel cluster degli Stati Uniti.  Verificare che la casella di controllo Invia informazioni di georilevazione sia selezionata nel trunk SIP o nell'ICT tra cluster USA e India. 

Al termine della configurazione nel cluster degli Stati Uniti, tornare a Cluster India.

Configura criteri di partizione logica

Vengono creati tre criteri logici.

• Politica in materia di TIC : Paese=IN,A1=KAR,A2=BAN,NAM=ICT
• La politica indiana: Paese=IN,A1=KAR,A2=BAN,NAM=BGL14
• Criteri degli Stati Uniti: Paese=IT,A1=TEX,A2=SAN,NAM=BGL1

Configura relazioni tra criteri di partizione logica

Una volta configurata la partizione logica, popolare le relazioni tra i due criteri.

Policy logica ICT

Tipo di dispositivo, criterio e relazione con altre tabelle di criteri.

Tipo di dispositivo	Policy	Tipo di dispositivo	Policy	Risultato
Bordo	Country=IN,A1=KAR,A2=BAN,NAM=ICT(Politica ICT)	Bordo	Country=IN,A1=KAR,A2=BAN,NAM=ICT(Politica ICT)	Allow (Autorizza)
Bordo	Country=IN,A1=KAR,A2=BAN,NAM=ICT(Politica ICT)	Interno	Country=IN,A1=KAR,A2=BAN,NAM=BGL14(Criteri India)	Allow (Autorizza)

• Il telefono IP interno è necessario per collegarsi all'ICT prima di ricevere l'aggiornamento del dispositivo dal lato USA, quindi si dispone di Border:Country=IN,A1=KAR,A2=BAN,NAM=ICT (ICT SIP trunk) to Interior:Country=IN,A1=KAR,A2=BAN,NAM=BGL14 (IP Phone in India) as Allow (Consenti).
  
  
• Nel caso in cui è necessario ritrasferire la chiamata agli Stati Uniti Allora è necessario ICT a chiamate ICT come consentito in modo da avere la relazione Border:Country=IN,A1=KAR,A2=BAN,NAM=ICT a Border:Country=IN,A1=KAR,A2=BAN,NAM=ICT come Consenti.
  
  

India - politica logica

Tipo di dispositivo, criterio e relazione con altre tabelle di criteri.

Con questa configurazione, la partizione logica è configurata solo nel cluster India e il trasferimento della posizione tra i cluster USA e India è assicurato. Dovrebbe essere possibile bloccare le chiamate tra cluster di Stati Uniti e India in modo che non si mescolino con PSTN e che CUG funzioni. Eseguire il test della configurazione effettuando alcune chiamate.

Scenari

• IP Phone in India chiama IP phone negli Stati Uniti.
• IP Phone in India chiama IP phone negli Stati Uniti, India IP phone Trasferisce la chiamata all'utente PSTN.
• IP Phone in India chiama IP phone negli Stati Uniti, India IP phone conferenze PSTN Utente.
• Il telefono IP in India chiama il telefono IP negli Stati Uniti, USA e Est lo trasferisce all'utente PSTN.
• IP phone in India chiama IP phone negli Stati Uniti, US Ext Conferences PSTN utente.

Scenario 1: Il telefono IP in India chiama il telefono IP negli Stati Uniti

Comportamento previsto: Consenti la chiamata

Comportamento osservato: Chiamata consentita

India IP phone Ext 7001 ci chiama Ext 5005.

Ecco il diagramma SIP trunk ladder

La chiamata può essere divisa in due parti.

• Prima di ottenere le informazioni sulla geolocalizzazione dal cluster USA.
• Dopo aver ottenuto le informazioni sulla geolocalizzazione dal cluster USA.

Se si notano i primi 200 OK e ACK per l'invito SIP iniziale. Se si guarda più da vicino alla 200 OK ottenuta dal cluster USA, si nota che la porta RTP è una porta fittizia, ad esempio 4000

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.106.97.137:5060;branch=z9hG4bK68935124bc7a
From: <sip:7001@10.106.97.137>;tag=26724~771bfd92-7ded-4e46-8bd8-6830680e49b2-18365227
To: <sip:5005@10.106.97.135>;tag=16120~7e829a6c-a04d-4a5f-8048-8b0b0ec17d7b-18364848
Date: Sat, 16 Mar 2019 19:52:55 GMT
Call-ID: 15e0cb00-c8d15417-6828-89616a0a@10.106.97.137
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence, kpml
Supported: replaces
Server: Cisco-CUCM10.5
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires:  1800;refresher=uas
Require:  timer
P-Asserted-Identity: <sip:5005@10.106.97.135>
Remote-Party-ID: <sip:5005@10.106.97.135>;party=called;screen=yes;privacy=off
Remote-Party-ID: <sip:5005@10.106.97.135;user=phone>;party=x-cisco-original-called;privacy=off
Contact: <sip:5005@10.106.97.135:5060>
Content-Type: application/sdp
Content-Length: 340
v=0
o=CiscoSystemsCCM-SIP 16120 1 IN IP4 10.106.97.135
s=SIP Call
c=IN IP4 10.65.43.112
b=TIAS:64000
b=AS:64
t=0 0
m=audio 4000 RTP/AVP 9 0 8 116 3 18
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:116 iLBC/8000
a=maxptime:60
a=fmtp:116 mode=20
a=rtpmap:3 GSM/8000
a=rtpmap:18 G729/8000
a=sendonly

Il flusso RTP non è ancora iniziato. Dopo la ACK si vede un altro SIP INVITE e in questo, si hanno le informazioni di geolocalizzazione inviato a se stessi.

INVITE sip:7001@10.106.97.137:5060 SIP/2.0
Via: SIP/2.0/UDP 10.106.97.135:5060;branch=z9hG4bK11f6de9436
From: <sip:5005@10.106.97.135>;tag=16120~7e829a6c-a04d-4a5f-8048-8b0b0ec17d7b-18364848
To: <sip:7001@10.106.97.137>;tag=26724~771bfd92-7ded-4e46-8bd8-6830680e49b2-18365227
Date: Sat, 16 Mar 2019 19:53:00 GMT
Call-ID: 15e0cb00-c8d15417-6828-89616a0a@10.106.97.137
Supported: timer,resource-priority,replaces
Cisco-Guid: 0367053568-0000065536-0000000033-2304862730
User-Agent: Cisco-CUCM10.5
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Max-Forwards: 70
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires:  1800;refresher=uac
Min-SE:  1800
Geolocation: 
     
     
       ;inserted-by="10.106.97.135" 
     
P-Asserted-Identity: <sip:5005@10.106.97.135>
Remote-Party-ID: <sip:5005@10.106.97.135>;party=calling;screen=yes;privacy=off
Contact: <sip:5005@10.106.97.135:5060>
Content-Type: multipart/mixed;boundary=uniqueBoundary
Mime-Version: 1.0
Content-Length: 1219
--uniqueBoundary
Content-Type: application/sdp
v=0
o=CiscoSystemsCCM-SIP 16120 2 IN IP4 10.106.97.135
s=SIP Call
c=IN IP4 10.65.43.112
b=TIAS:64000
b=AS:64
t=0 0
m=audio 25344 RTP/AVP 9
a=ptime:30
a=rtpmap:9 G722/8000
--uniqueBoundary
Content-Type: application/pidf+xml
Content-ID: <5005@10.106.97.135>
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:caps="urn:ietf:params:xml:ns:pidf:caps"
xmlns:cisco="http://www.cisco.com"
entity="pres:geotarget@example.com">
<dm:device id="sg89ae">
<caps:devcaps>

     
     
       false 
     
</caps:devcaps>
<gp:geopriv>
<gp:location-info>
<cl:civicAddress>

     
     
       US 
     

     
     
       TEX 
     

     
     
       SAN 
     

     
     
       BGL1 
     
</cl:civicAddress>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>yes</gp:retransmission-allowed>
<gp:retention-expiry>2019-03-17T19:53:00Z</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
<timestamp>2019-03-16T19:53:00Z</timestamp>
</dm:device>
</presence>

--uniqueBoundary--

In questo invito viene visualizzato il numero di porta RTP che verrà utilizzato dal telefono IP degli Stati Uniti. Le informazioni di geolocalizzazione del telefono IP e quelle che indicano se si tratta di un gateway o meno vengono inviate al cluster indiano. Con queste nuove informazioni di geolocalizzazione, ancora una volta le partizioni logiche vengono confrontate nel cluster India per verificare se la chiamata deve essere consentita o negata. Poiché si tratta di chiamate interne a chiamate interne, la partizione logica non viene applicata e la chiamata è consentita

Scenario 2: IP Phone in India chiama IP Phone negli Stati Uniti, India IP Phone trasferisce chiamata a PSTN utente

Comportamento previsto: Nega la chiamata

Comportamento osservato: Chiamata negata

India IP Phone Ext 7001 ci chiama Ext 5005, preme il tasto softkey per il trasferimento per la prima volta, compone il numero PSTN 1005, preme il tasto transfer ma non succede nulla.

Nelle tracce CUCM, vedete.

01192372.012 |01:51:49.984 |AppInfo  |LPPolicyManager -getLogicalPartitionPolicy, devtypeA[Border], devtypeB[Interior]
01192372.013 |01:51:49.984 |AppInfo  |LogicalPolicyTree -searchPolicy devTypeA[Border], devTypeB[Interior]
01192372.014 |01:51:49.984 |AppInfo  |GeolocNamValPair -printList: country = IN, A1 = KAR, A2 = BAN, NAM = BGL14,
01192372.015 |01:51:49.984 |AppInfo  |GeolocNamValPair -printList: country = US, A1 = TEX, A2 = SAN, NAM = BGL1,

01192372.074 |01:51:49.984 |AppInfo  |LPPolicyManager -findLogicalPartitionPolicyUsingVals, DEFAULT POLICY found is [2]
01192372.075 |01:51:49.984 |AppInfo  |LPPolicyManager -findLogicalPartitionPolicyUsingVals, POLICY found is [9]
01192372.076 |01:51:49.984 |AppInfo  |Transferring - LPPolicy Result [9]
01192372.077 |01:51:49.984 |AppInfo  |LPPolicyManager -incLogicalPPerfmon, perfMon[0]
01192372.078 |01:51:49.984 |AppInfo  |Transferring - handleTransferErrorPreStart, ERROR fid=[4], Retaining Calls, xferring[1, 18365238], xferred[1, 18365239]. infoCause=53, clearCause=63

01192668.001 |01:51:56.765 |AppInfo  |StationD:    (0000019) DisplayNotify timeOutValue=10 notify='a' content='External Transfer Restricted' ver=8560000c.

Sul cluster party indiano, A sta andando a un dispositivo PSTN, ad esempio un elemento di confine. Non è stato impostato alcun permesso tra il confine con l'India e l'interno degli Stati Uniti, quindi si utilizza il criterio predefinito impostato su Nega e la chiamata viene bloccata.

Scenario 3: IP Phone in India chiama IP Phone negli Stati Uniti, India IP Phone conferenze PSTN Utente

Comportamento previsto: Nega la chiamata

Comportamento osservato: Chiamata negata

India IP phone Ext 7001 chiama Us Ext 5005, India IP phone Ext 7001 fa clic su Confrn softkey la prima volta, chiama PSTN numero 1005, fa clic su Confrn softkey, come mostrato nell'immagine. Viene tuttavia visualizzato il messaggio Conferenza non disponibile.

Nei registri CUCM viene visualizzato quanto segue:

01213687.146 |02:00:35.806 |AppInfo  |LogicalPolicyTree -searchPolicy devTypeA[Border], devTypeB[Interior]
01213687.147 |02:00:35.806 |AppInfo  |GeolocNamValPair -printList: country = IN, A1 = KAR, A2 = BAN, NAM = BGL14,
01213687.148 |02:00:35.806 |AppInfo  |GeolocNamValPair -printList: country = US, A1 = TEX, A2 = SAN, NAM = BGL1,

01213687.207 |02:00:35.806 |AppInfo  |LPPolicyManager -findLogicalPartitionPolicyUsingVals, DEFAULT POLICY found is [2]
01213687.208 |02:00:35.806 |AppInfo  |LPPolicyManager -findLogicalPartitionPolicyUsingVals, POLICY found is [9]
01213687.209 |02:00:35.806 |AppInfo  |Conference: processGeoLocationResultListForConfRequest:ci=18365306,status=9

Sul cluster party indiano, A sta andando a un dispositivo PSTN, ad esempio un elemento di confine. Non hai impostato alcun permesso tra il confine con l'India e l'interno degli Stati Uniti, quindi utilizzi il criterio predefinito impostato su Nega e la chiamata è bloccata.

Scenario 4: IP Phone in India chiama IP Phone negli Stati Uniti, USA Ext Trasferisce questo a PSTN Utente

Comportamento previsto: Nega la chiamata

Comportamento osservato: Chiamata negata

India IP Phone Ext 7001 chiama US IP phone Ext 5005, US IP phone Ext 5005 fa clic prima sul softkey di trasferimento, compone il numero PSTN 1005, poi fa di nuovo clic sul tasto di trasferimento.

Quando l'estensione per gli Stati Uniti trasferisce la chiamata a PSTN, il cluster per gli Stati Uniti restituisce un aggiornamento.

UPDATE sip:7001@10.106.97.137:5060 SIP/2.0
Via: SIP/2.0/UDP 10.106.97.135:5060;branch=z9hG4bKbe39bb25ad
From: <sip:5005@10.106.97.135>;tag=6376~7e829a6c-a04d-4a5f-8048-8b0b0ec17d7b-18364784
To: <sip:7001@10.106.97.137>;tag=9968~771bfd92-7ded-4e46-8bd8-6830680e49b2-18365199
Date: Wed, 13 Mar 2019 10:57:03 GMT
Call-ID: b6619180-c881e1f8-26cd-89616a0a@10.106.97.137
User-Agent: Cisco-CUCM10.5
Max-Forwards: 70
Supported: timer,resource-priority,replaces
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 103 UPDATE
Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=MIXED
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires:  1800;refresher=uac
Min-SE:  1800
Geolocation: 
     
     
       ;inserted-by="10.106.97.135" 
     
P-Asserted-Identity: <sip:1005@10.106.97.135>
Remote-Party-ID: 
     
     ;party=calling;screen=yes;privacy=off
Contact: <sip:1005@10.106.97.135:5060>
Content-Type: application/pidf+xml
Content-ID: 1005@10.106.97.135
Content-Length: 872
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:caps="urn:ietf:params:xml:ns:pidf:caps"
xmlns:cisco="http://www.cisco.com"
entity="pres:geotarget@example.com">
<dm:device id="sg89ae">
<caps:devcaps>

     
     
       true 
     
</caps:devcaps>
<gp:geopriv>
<gp:location-info>
<cl:civicAddress>

     
     
       US 
     

     
     
       TEX 
     

     
     
       SAN 
     

     
     
       BGL1 
     
</cl:civicAddress>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>yes</gp:retransmission-allowed>
<gp:retention-expiry>2019-03-14T10:57:14Z</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
<timestamp>2019-03-13T10:57:14Z</timestamp>
</dm:device>
</presence>

Nell'aggiornamento si nota che il dispositivo con cui interagisce è un elemento di bordo. Con queste informazioni, CUCM sul lato India ora ancora una volta applica una partizione logica su questa chiamata e il risultato è negare la chiamata.

Nei registri CUCM viene visualizzato quanto segue:

00443670.032 |16:27:14.830 |AppInfo  |LPPolicyManager -getLogicalPartitionPolicy, devtypeA[Interior], devtypeB[Border]
00443670.033 |16:27:14.830 |AppInfo  |LogicalPolicyTree -searchPolicy devTypeA[Interior], devTypeB[Border]
00443670.034 |16:27:14.830 |AppInfo  |GeolocNamValPair -printList: country = IN, A1 = KAR, A2 = BAN, NAM = BGL14,
00443670.035 |16:27:14.830 |AppInfo  |GeolocNamValPair -printList: country = US, A1 = TEX, A2 = SAN, NAM = BGL1,

00443670.064 |16:27:14.830 |AppInfo  |LPPolicyManager -findLogicalPartitionPolicyUsingVals, DEFAULT POLICY found is [2]
00443670.065 |16:27:14.830 |AppInfo  |LPPolicyManager -findLogicalPartitionPolicyUsingVals, POLICY found is [9]

La parte B, ossia il dispositivo proveniente dagli Stati Uniti, è ora aggiornata dall'elemento interno al bordo. Il criterio predefinito è corrispondente e il criterio predefinito nel cluster India è Nega.

Scenario 5: IP Phone in India chiama IP Phone negli USA, USA Ext Conferences PSTN Utente

Comportamento previsto: Nega la chiamata

Comportamento osservato: Chiamata consentita

Quest'ultimo scenario la chiamata funziona, solo con il trasferimento della posizione non sarà possibile bloccare la conferenza telefonica avviata negli Stati Uniti dalle partizioni logiche configurate nel cluster India. Limitazione della configurazione. Per superare questo limite, è necessario configurare anche la partizione logica nel cluster UC.

La sezione successiva della configurazione deve essere eseguita dal lato utente degli Stati Uniti.

Configurazione cluster USA

La configurazione del cluster USA può essere suddivisa in queste parti.

• Configurazione della georilevazione
• Abilitazione della geolocalizzazione
• Assegnazione della georilevazione ai dispositivi
• Configurazione dei criteri di partizione logica
• Configurazione della relazione tra i criteri di partizione logica

Configura georilevazione

In questo caso, vengono create tre geolocazioni.

• Per i dispositivi in India: India_GL
• Per SIP trunk in ICT: IT_IT_GL
• Per i dispositivi negli Stati Uniti: GL_US

Questa immagine mostra la configurazione US_GL.

Questa immagine mostra la configurazione US_ICT_GL.

Questa immagine mostra la configurazione India_GL.

Per il filtro, vengono utilizzati i campi Paese A1, A2, NAM, come mostrato nell'immagine.

Abilita geolocalizzazione

Abilita partizione logica per il parametro dell'organizzazione. Il criterio predefinito è Consenti.

Assegna geolocalizzazione ai dispositivi

Nota: A questo punto si sarebbe già configurato il pool di dispositivi dei telefoni IP degli Stati Uniti con la geolocalizzazione US_GL.

Assegnare US_ICT_GL al trunk SIP ICT nel cluster USA. 

Configura criteri di partizione logica

Nel cluster degli Stati Uniti vengono creati due criteri logici.

• La politica indiana:  Paese=IN,A1=KAR,A2=BAN,NAM=BGL14
• Criteri degli Stati Uniti: Paese=IT,A1=TEX,A2=SAN,NAM=BGL1

Criteri logici USA

Tipo di dispositivo, criterio e relazione con altre tabelle di criteri.

Questa configurazione in vigore il caso di telefono IP in India chiama IP telefono negli Stati Uniti, US IP conferenze telefoniche PSTN utente è ora bloccato.

Questo messaggio di errore viene visualizzato sul telefono IP degli Stati Uniti quando cerchiamo di comunicare tra l'utente PSTN degli Stati Uniti e l'India IP Phone.

Dopo aver configurato la geolocalizzazione nel cluster degli Stati Uniti, il comportamento per lo scenario 2 e per lo scenario 4 sarà lo stesso. Il cluster in India non deve attendere un'istruzione SIP UPDATE/INVITE dal cluster negli Stati Uniti, in quanto la negazione delle chiamate avverrà nel cluster stesso a causa dell'entrata in vigore della partizione logica sul lato degli Stati Uniti. 

In questo caso, è necessario che CUG funzioni tra il cluster indiano e quello americano e assicurarsi di non combinare la chiamata VOIP di un cluster con la chiamata PSTN di un altro cluster.

Scalabilità futura 

Aggiunta di un nuovo cluster alla rete aziendale

Per aumentare la scalabilità e ospitare nuovi cluster, si supponga di avere 2 nuovi cluster da aggiungere. UK Cluster e France Cluster.

In termini di configurazione con le impostazioni esistenti, aggiungere questi

India

• È sufficiente aggiungere una geolocalizzazione britannica e una geolocalizzazione francese nel cluster India.
• Assegnare la geolocalizzazione ICT al trunk SIP in direzione del Regno Unito e della Francia.
• Verificare che la casella di controllo Invia informazioni sulla posizione sia selezionata in SIP Trunk o ICT.

Il cluster del Regno Unito

• Creare una geolocalizzazione per il Regno Unito, l'ICT e l'India con lo stesso filtro degli altri cluster (simile alla configurazione dei cluster USA).
• Mantenere il criterio predefinito come consentito.
• Verificare che la casella di controllo Invia informazioni sulla posizione sia selezionata in SIP Trunk o ICT.
• Assegnare il filtro di geolocalizzazione e geolocalizzazione al trunk SIP/ICT come ICT.
• Creare due criteri logici: la politica del Regno Unito e quella dell'India.
• Nel criterio Regno Unito configurare la relazione di partizione logica tra il confine del Regno Unito e l'interno dell'India come nega.

Il cluster France

• Creare una geolocalizzazione per Francia, ICT e India con lo stesso filtro degli altri cluster (simile alla configurazione cluster USA).
• Mantenere il criterio predefinito come consentito.
• Verificare che la casella di controllo Invia informazioni sulla posizione sia selezionata in SIP Trunk o ICT.
• Assegnare il filtro di geolocalizzazione e geolocalizzazione al trunk SIP/ICT come ICT.
• Creare una politica logica, una politica francese e una politica indiana.
• In Francia, la politica configura la relazione di partizione logica tra la Francia di confine con l'India interna come negazione.

Per aggiungere un nuovo cluster da un paese diverso, eseguire la procedura descritta in precedenza. In questo modo la configurazione viene mantenuta al minimo ed è possibile scalare se si aggiungono altri cluster

Cosa fare se si dispone di uno SME?

Le PMI operano come portatrici di informazioni di geolocalizzazione senza partecipare a partizionamenti logici nel cluster delle PMI.

• Selezionare la casella di controllo Send Geolocation Information (Invia informazioni geolocalizzazione) in SIP Trunk o ICT.
• Non è necessario configurare la geolocalizzazione per SME.

.

La configurazione della georilevazione e il partizionamento logico vengono eseguiti solo sul nodo foglia. La configurazione nel nodo foglia è simile a una configurazione di geolocalizzazione tra 2 cluster tramite ICT. Lo SME si limita a trasmettere le informazioni di geolocalizzazione che riceve da un trunk a un altro trunk come proxy.  

Nota: L'elenco non è affatto esaustivo. In qualità di amministratore, è necessario testare call park e Callpick up (locale e remoto), SNR, EM, EMCC, Huntpilot, trasferimento e conferenza correlati CTI, Adhoc, Meet-Me Conference sul cluster e testarlo. 

Limitazione

Concatenamento di conferenze - ad esempio, la conferenza concatenata MeetMe & Adhoc può avere partecipanti a cui viene negata la registrazione LP ma che non possono essere impediti nella comunicazione.

Consiglio: disabilitare il concatenamento delle conferenze dal relativo parametro Service. 

Caso angolare di CBarge/Barge - Quando la parte connessa è un bridge di conferenze a causa di una funzionalità attiva, ad esempio Conference o Meet-Me, e un dispositivo attivo in linea condivisa viene associato alla geolocalizzazione consentita per tutti i dispositivi della conferenza, il dispositivo in linea condivisa remoto in uso visualizza le informazioni sull'istanza della chiamata. In questo caso, il telefono remoto in uso può sempre eseguire la funzione cBarge/Barge anche se un partecipante non autorizzato partecipa alla conferenza. Per i partecipanti a cBarge/Barge, non esiste alcun controllo dei criteri di partizionamento logico e non è possibile impedire scenari di partizionamento logico negato.  

Informazioni correlate

• https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/11_5_1/sysConfig/11_5_1_SU1/cucm_b_system-configuration-guide-1151su1/cucm_b_system-configuration-guide-1151su1_chapter_01010001.html
  
  
• https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/11_5_1/sysConfig/11_5_1_SU1/cucm_b_system-configuration-guide-1151su1/cucm_b_system-configuration-guide-1151su1_chapter_01010000.html
  
  
• https://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-manager-callmanager/116038-logical-partition-geolocation-00.html
  
  
• https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/10_0_1/ccmfeat/CUCM_BK_F3AC1C0F_00_cucm-features-services-guide-100/CUCM_BK_F3AC1C0F_00_cucm-features-services-guide-100_chapter_011100.html
  
  
• https://tools.ietf.org/html/rfc6442

• Documentazione e supporto tecnico – Cisco Systems