Implementar GeoLocation em todos os clusters do CUCM

Introduction

Este documento trata de como estender a Geolocalização através da implantação de vários clusters com a Location Conveyance. Com essas novas informações sobre como fazer com que o Grupo de Usuários Fechados (CUG) funcione entre um cluster que é regulado e não regulamentado com configuração mínima. Garante igualmente a forma de cumprir as regras regulamentares.

Termos associados à localização geográfica

GeoLocation

Por definição, GeoLocation é uma descrição da área geográfica física onde algo existe atualmente. No CUCM, a geolocalização atribui os detalhes da localização a dispositivos como telefone IP, tronco SIP, Gateway de tronco Inter CLuster (ICT), etc., que podem dar significado em toda a empresa, nos clusters e locais.

O RFC 4119 especifica 17 elementos de localização cívica e recurso de particionamento lógico UCM implementado a configuração manual desses 17 campos/elementos das configurações de administração. Recomendou que você preenchesse todos os 17 campos. Os campos devem ser nomeados lógicos e curtos.

Filtro de localização geográfica

O Filtro de Geolocalização é uma regra para selecionar determinados campos da Geolocalização a fim de construir a String de Geolocalização, que pode ser usada para corresponder políticas para o recurso Particionamento Lógico. i.e.  ele daria conjuntos de campos de localização geográfica para os quais as políticas devem ser configuradas

Identificador de localização geográfica

Identificador construído a partir de uma combinação do tipo Geolocalização, Filtro e Dispositivo. Este identificador é usado para comparar com LP e a chamada seria permitida ou negada

Um filtro de localização geográfica do dispositivo + tipo de dispositivo = Identificador de localização geográfica

ou seja, um tronco SIP no CUCM pode ser logicamente representado como

Fronteira:País:IN:A1:KAR:A2:BAN 

Registro de Política de Geolocalização (GLP - Geolocation Policy Record)

As políticas não são configuradas diretamente entre localizações, pois as localizações geralmente têm todos os 17 campos configurados e possivelmente seriam exclusivas para cada dispositivo UCM em um cluster. Portanto, configurar políticas entre localizações geográficas pode ser muita sobrecarga para um administrador, dado o número de localizações. 

Para fazer políticas, o administrador precisa construir registros com dados necessários para campos de localização geográfica. Para essa finalidade, a configuração fornece a provisão para selecionar os dados dos menus suspensos mostrando campos de geolocalização.

Esses registros são chamados de registros de GeolocationPolicy (GLP).

Note: Os registros de GeolocationPolicy devem ser feitos para que os dados correspondentes correspondam aos campos selecionados nos filtros. A hierarquia de campos é importante e os campos não devem ser perdidos no começo ou no meio, mas podem ser perdidos no final.

Se os campos específicos do filtro não estiverem na política, o algoritmo de pesquisa retira o campo do final e procura uma possível correspondência nas políticas.  

Exemplo: Se eu selecionei um campo C, A1, A2, A6 para um LP e outro LP só tem C, A1, A6, então o CUCM entre esse 2 LP só usa C, A1 mesmo que A6 esteja presente em ambos os CUCM ignora-o.

Conversão de local

• A transferência de GeoLocation de um agente de usuário SIP para outra entidade que usa SIP é chamada de Location Conveyance.
  
  
• Para suportar os requisitos de LP, a implementação do UCM comunica adicionalmente informações do tipo de dispositivo no PIDF-LO. Isso é baseado no Status de Presença do Agente de Usuário, conforme a especificação na extensão SIP draft-ietf-simple-prescaps-ext-08. 
  
  
• O tronco SIP do UCM suporta a transferência de localização de acordo com essas especificações.
  
  
• Para permitir que a ICT seja compatível com Tronco SIP e permita os mesmos recursos, o Tronco ICT/H225 também suporta a transferência de localização no cluster usando PIDF-LO. 
  
  
• O UCM suporta a transmissão de informações de localização no estabelecimento da chamada, bem como alterações de localização devido à alteração na parte conectada na participação em associações e redirecionamentos de chamada média.  

Implementar a localização geográfica no cluster do CUCM

Hipótese: Ter uma compreensão básica da geolocalização e porque ela é necessária. 

Para este documento, usamos 2 clusters do CUCM. Parte-se do pressuposto de que um cluster reside nos EUA e outro cluster residente na Índia. Estamos usando as versões 11.5 e 10.5 do CUCM para fins de demonstração. Temos um tronco SIP entre os Clusters. O plano de discagem é configurado de modo que somente as chamadas internas sejam permitidas neste tronco ICT/SIP de ambos os clusters usando CSS e partição. O plano de discagem foi configurado de modo que as chamadas VOIP para PSTN usam o Gateway local para fazer chamadas PSTN usando o CSS e a partição.

O cluster India é um cluster com reconhecimento/partição lógica. O cluster EUA é um cluster de partição lógica desabilitado/sem reconhecimento. O filtro de localização geográfica e localização geográfica é configurado e aplicado a todos os dispositivos em ambos os clusters. Por enquanto, configure a partição lógica somente no cluster da Índia, mais tarde uma limitação será encontrada devido à qual a localização geográfica está habilitada e configura a partição lógica mesmo no cluster dos EUA também.  

Extensão VOIP na Índia: 7XXX (7001, 7002)

Extensão VOIP dos EUA : 5XXX (5005)

Extensão PSTN: 1 XXX (1005)

Esta é a imagem com identificadores Geolocation.

Informações de Apoio

No lado da Índia, aplica-se o regulamento TRAI. Em termos simples, não combine chamada VOIP não local com chamada PSTN local. As chamadas do Grupo de Usuários Fechados (CUG) são permitidas, ou seja, chamadas VOIP dentro da mesma rede corporativa são permitidas.

Quando você tem vários clusters CUCM em diferentes localizações geográficas e um deles é regulado, o objetivo

1. Cumprimento pela TRAI ou pelas regras regulamentares
2. Faça com que o CUG funcione 

Teoria

Para que o CUG funcione, a transferência de local é usada para estender a aplicação da política de particionamento lógico, ou seja, as informações de geolocalização são enviadas para outros clusters à medida que o Send Geolocation Data é verificado em ICT e tronco SIP em ambos os clusters. Isso permite enviar e receber informações de localização geográfica de dispositivos e, junto com isso, você também pode saber se o dispositivo é um interior ou uma borda.

Para a configuração inicial da chamada, você precisa de uma política que permita a comunicação entre o telefone IP A e a ICT. Quando o CONVITE SIP é enviado para outros clusters, ele descobre o dispositivo de destino B e, uma vez que esse dispositivo esteja tocando ou/e atenda a chamada, as informações de localização geográfica do dispositivo B são enviadas ao cluster de origem por meio de uma mensagem CONVITE/ATUALIZAÇÃO SIP. Depois que o cluster de origem receber informações de geolocalização válidas na mensagem CONVITE/ATUALIZAÇÃO, que substitui a configuração local da localização do tronco SIP e substitui essa configuração pela localização recebida.

Com essas novas informações de localização geográfica, você pode ter uma política de partição lógica configurada para permitir chamadas VOIP para VOIP e negar chamada VOIP do cluster que alcança o dispositivo de borda de um cluster diferente.

Note: Neste cenário, todos os clusters devem ter Geolocations e Geolocation Filters configurados e aplicados a todos os pools de dispositivos. As chamadas entre clusters incluem dados de localização geográfica e se esse participante é considerado interior ou borda. Se os dados de localização geográfica não forem recebidos em uma chamada entre clusters, então o filtro de localização geográfica e localização geográfica na configuração de tronco ou herdado do pool de dispositivos do tronco será usado.

Projeto

Para projetar a localização geográfica e a partição lógica, pense em

• Como identificar exclusivamente o local físico do dispositivo que faz a chamada e o dispositivo que recebe a chamada?
• Colete informações sobre o local entre o qual a geolocalização/local físico devo ter restrições de chamada em vigor.
• Dos 17 campos, que são selecionados, você pode tomar uma decisão sobre se deseja permitir ou negar a chamada. 

Nos campos de localização geográfica, você tem 17 campos, que vão de A1 a A6 até o código postal. Para preencher a A1 é como aproximar um mapa. Quanto mais detalhes você colocar, mais precisamente o local do dispositivo pode ser apontado, ao qual essa geolocalização está atribuída. O que se deve considerar é, de todos os campos em geolocalização, quais campos devem ser um par de dispositivos presentes ao CUCM com os quais você pode tomar uma decisão de partição lógica efetiva.

Quando a política de partições lógicas estiver configurada, você terá a opção de selecionar um conjunto de campos de localização geográfica, selecionar esses campos de localização, de modo que quando um dispositivo faz uma chamada apresente um conjunto de identificadores de localização geográfica para o CUCM e o dispositivo de destino recebe uma chamada que apresenta um conjunto de identificadores de localização para o CUCM. Se esses campos corresponderem a uma política de partição lógica predefinida, ele poderá aplicar restrições às chamadas.

Exemplo. Se o dispositivo A tiver uma Geolocation info A1=IN,A2=BAN,NAM=BGL14 e o dispositivo B tiver uma Geolocalização A1=IN,A2=MUM,NAM=BAN1. Crie uma política de geolocalização 1 de modo que A=IN,A2=BAN,NAM=BGL14. Criar Política 2 A=IN,A2=MUM,NAM=BAN1. Você deve permitir ou negar entre dispositivos que correspondem à política 1 e 2.

Se uma chamada for feita e o dispositivo de origem tiver informações de localização geográfica A1=IN,A2=BAN,NAM=BGL14, o CUCM saberá que a política 1 pode ser selecionada. Se o dispositivo de destino também tiver informações de localização geográfica A1=IN,A2=MUM,NAM=BAN1, então o CUCM sabe que é uma correspondência perfeita para a relação de partição lógica entre a política 1 e 2.

Note: Recomenda-se que os campos de filtro de localização geográfica e a seleção de campo de política de partição lógica tenham os mesmos campos selecionados e correspondentes ou que o campo de política de partição lógica seja um subconjunto de campos de filtro de localização geográfica para que, quando uma chamada é feita, você tenha a política de partição lógica correspondente na primeira iteração. Você deve tentar uma correspondência perfeita quando as chamadas estiverem sendo feitas.

Configuração no CUCM

A configuração do cluster da Índia pode ser dividida nestas partes:

Configurar localização geográfica

Para esse caso, são criadas três Geolocalizações.

• Para dispositivos na Índia: Índia_GL
• Para tronco SIP em ICT: Índia_ICT_GL
• Para dispositivos nos EUA: US_GL

Note: No cluster da Índia, um Empty_GL é configurado e é fornecido como geolocalização padrão. Isso é feito para que, caso você se esqueça de adicionar geolocalização a qualquer dispositivo através do pool de dispositivos, essa geolocalização seja usada para negar chamadas para qualquer dispositivo de borda.

Esta imagem mostra a Configuração do India_GL.

Esta imagem mostra a configuração India_ICT_GL.

Esta imagem mostra a configuração US_GL.

Como mostrado na imagem, para o filtro de localização geográfica, os campos Country, A1, A2, NAM são usados.

Habilitar localização geográfica

Ativar particionamento lógico no parâmetro da empresa, definir uma política padrão como Negar, aplicar a localização geográfica padrão como Empty_GL.

Atribuir localização geográfica aos dispositivos

• No pool de dispositivos CUCM para telefone IP, atribua India_GL.

• No tronco SIP ICT, atribua India_ICT_GL e marque para enviar informações de localização geográfica.

Depois disso, vá para o cluster UC. Você precisa criar uma política de geolocalização dos EUA e associá-la aos dispositivos no cluster dos EUA.  Verifique se a caixa de seleção Send Geolocation Information está marcada em SIP Trunk ou ICT entre os clusters US e India. 

Depois que a configuração no cluster dos EUA for concluída, volte para o cluster da Índia.

Configurar políticas de partição lógica

São criadas três políticas lógicas.

• Política em matéria de TIC: País=IN,A1=KAR,A2=BAN,NAM=ICT
• Política da Índia: País=IN,A1=KAR,A2=BAN,NAM=BGL14
• Política dos EUA: País=US,A1=TEX,A2=SAN,NAM=BGL1

Configurar relações entre políticas de partição lógica

Depois que a partição lógica for configurada, preencha as relações entre as duas políticas.

Política lógica de TIC

Tipo de dispositivo, política e sua relação com outras tabelas de política.

Tipo de dispositivo	Política	tipo de dispositivo	Política	Resultado
Fronteira	País=IN,A1=KAR,A2=BAN,NAM=ICT(Política de TIC)	Fronteira	País=IN,A1=KAR,A2=BAN,NAM=ICT(Política de TIC)	Permissão
Fronteira	País=IN,A1=KAR,A2=BAN,NAM=ICT(Política de TIC)	Interior	Country=IN,A1=KAR,A2=BAN,NAM=BGL14(Política da Índia)	Permissão

• O telefone IP interno é necessário para entrar em contato com a ICT antes de você obter a atualização do dispositivo do lado dos EUA para que você tenha Border:Country=IN,A1=KAR,A2=BAN,NAM=ICT (tronco SIP da ICT) para Interior:Country=IN,A1=KAR,A2=BAN,NAM=BGL14 (telefones IP na Índia) como Permitir.
  
  
• Caso precise fazer a ligação para os EUA. Em seguida, você precisa de chamadas TIC para ICT conforme permitido para ter a relação Border:Country=IN,A1=KAR,A2=BAN,NAM=ICT to Border:Country=IN,A1=KAR,A2=BAN,NAM=ICT as Allow (Permitir).
  
  

Política Lógica da Índia

Tipo de dispositivo, política e sua relação com outras tabelas de política.

Com essa configuração, você tem a partição lógica configurada somente no cluster da Índia e tem a transferência de local entre os clusters dos EUA e da Índia. Você deve ser capaz de bloquear chamadas entre os clusters dos EUA e da Índia para que eles se misturem com a PSTN e para que o CUG funcione. Teste esta configuração fazendo algumas chamadas.

Cenários

• O telefone IP na Índia chama o telefone IP nos EUA.
• O telefone IP na Índia chama o telefone IP nos EUA, o telefone IP da Índia transfere a chamada para o usuário PSTN.
• O telefone IP na Índia chama o telefone IP nos EUA, na Índia, telefone IP Conferences PSTN User.
• O telefone IP na Índia liga para o telefone IP nos EUA, a US Ext transfere isso para o usuário da PSTN.
• O telefone IP na Índia chama o telefone IP nos EUA, usuário PSTN de conferências de saída dos EUA.

Cenário 1: O telefone IP na Índia liga para o telefone IP nos EUA

Comportamento esperado: Permitir a chamada

Comportamento observado: A chamada é permitida

O telefone IP da Índia Ext 7001 chama Us Ext 5005.

Aqui está o diagrama da escada de tronco SIP

Você pode dividir a chamada em duas partes.

• Antes de obter as informações de localização geográfica do cluster dos EUA.
• Depois de obter as informações de localização geográfica do cluster dos EUA.

Se você observar que há 200 OK e ACK para o convite SIP inicial. Se você olhar mais de perto para o 200 OK que você obteve do cluster dos EUA, percebe-se que a porta RTP é uma porta fictícia, ou seja, 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

O RTP ainda não começou a fluir. Após a ACK você ver mais um CONVITE SIP e, nesse caso, você tem informações de localização geográfica enviadas para você mesmo.

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--

Neste convite, você verá o número da porta RTP que o telefone IP dos EUA usará. As informações de localização geográfica do telefone IP e informações sobre se este é ou não um gateway são enviadas para o cluster da Índia. Com essas novas informações de localização geográfica, novamente partições lógicas são combinadas no cluster da Índia para ver se a chamada deve ser permitida ou negada. Como essas são chamadas internas, a partição lógica não é aplicada e a chamada é permitida

Cenário 2: O telefone IP na Índia chama o telefone IP nos EUA, o telefone IP da Índia transfere a chamada para o usuário PSTN

Comportamento esperado: Negar a chamada

Comportamento observado: A chamada é negada

O telefone IP da Índia Ext 7001 chama Us Ext 5005, disca a tecla de função de transferência na primeira vez, disca o número PSTN 1005 e pressiona a tecla de transferência, mas nada acontece.

Nos vestígios do CUCM, você vê.

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.

Na parte do cluster da Índia, A está indo para um dispositivo PSTN, ou seja, elemento de borda. Você não definiu nenhuma permissão entre a fronteira da Índia e o interior dos EUA, portanto, use o conjunto de políticas padrão para negar e a chamada será bloqueada.

Cenário 3: O telefone IP na Índia chama o telefone IP nos EUA, na Índia Conferência por telefone IP, usuário PSTN

Comportamento esperado: Negar a chamada

Comportamento observado: A chamada é negada

O telefone IP da Índia Ext 7001 chama Us Ext 5005, o telefone IP da Índia Ext 7001 clica na tecla de função Confrn na primeira vez, disca o número PSTN 1005 e clica na tecla de função Confrn, como mostrado na imagem. No entanto, você vê que a Conferência não está disponível.

Nos registros do CUCM, você vê isso:

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

Na parte do cluster da Índia, A está indo para um dispositivo PSTN, ou seja, elemento de borda. Você não definiu nenhuma permissão entre a fronteira da Índia e o interior dos EUA, portanto, use a política padrão definida para negar e a chamada será bloqueada.

Cenário 4 : O telefone IP na Índia liga para o telefone IP nos EUA, o SAT dos EUA transfere isso para o usuário PSTN

Comportamento esperado: Negar a chamada

Comportamento observado: A chamada é negada

O telefone IP da Índia Ext 7001 chama o telefone IP dos EUA Ext 5005, o telefone IP dos EUA Ext 5005 clica na tecla de função transfer da primeira vez, disca o número PSTN 1005 e clica novamente na tecla transfer.

Quando o ramal US transfere a chamada para PSTN, você recebe uma atualização do cluster US.

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>

Na atualização, você vê que o dispositivo com o qual ele interage é um elemento de borda. Com essas informações, o CUCM no lado da Índia agora novamente aplica uma partição lógica nesta chamada e o resultado é negar a chamada.

Nos registros do CUCM, você vê isso:

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]

Parte B, isto é, o dispositivo dos EUA é agora atualizado do elemento Interno para o elemento de fronteira. A política padrão é combinada e a política padrão no cluster da Índia é Negar.

Cenário 5: Telefone IP na Índia liga para o telefone IP nos EUA, usuário PSTN de conferências de saída dos EUA

Comportamento esperado: Negar a chamada

Comportamento observado: A chamada é permitida

Este último cenário em que a chamada funciona, apenas com a transferência de local, não conseguiremos bloquear a chamada de conferência iniciada nos EUA pelas partições lógicas configuradas no cluster da Índia. Esta é uma Limitação dessa configuração. Para superar essa limitação, você também precisa configurar a Partição Lógica no cluster UC.

A próxima seção da configuração deve ser feita no lado US CLuster.

Configuração do cluster dos EUA

A configuração do cluster US pode ser dividida nessas partes.

• Configurando a localização geográfica
• Habilitando a localização geográfica
• Atribuindo a localização geográfica aos dispositivos
• Configuração de políticas de partição lógica
• Configurando a relação entre as políticas de partição lógica

Configurar localização geográfica

Para esse caso, são criadas três Geolocalizações.

• Para dispositivos na Índia: Índia_GL
• Para tronco SIP em ICT: US_ICT_GL
• Para dispositivos nos EUA: US_GL

Esta imagem mostra a configuração US_GL.

Esta imagem mostra a configuração US_ICT_GL.

Esta imagem mostra a Configuração India_GL.

Para o filtro, os campos País A1, A2 e NAM são usados, como mostrado na imagem.

Habilitar localização geográfica

Ativar partição lógica no parâmetro da empresa, política padrão como Permitir.

Atribuir localização geográfica aos dispositivos

Note: Neste momento, você já teria configurado um pool de dispositivos de telefone IP US com localização geográfica US_GL.

Atribua US_ICT_GL ao tronco ICT SIP no cluster dos EUA. 

Configurar políticas de partição lógica

Duas políticas lógicas são criadas no cluster dos EUA.

• Política da Índia: País=IN,A1=KAR,A2=BAN,NAM=BGL14
• Política dos EUA: País=US,A1=TEX,A2=SAN,NAM=BGL1

Política lógica dos EUA

Tipo de dispositivo, política e sua relação com outras tabelas de política.

Esta configuração implementa o caso de telefone IP na Índia chama o telefone IP nos EUA, o usuário PSTN de conferências de telefone IP dos EUA está bloqueado agora.

Você vê esta mensagem de erro no telefone IP dos EUA quando tentamos colocar em conferência o usuário PSTN dos EUA com o telefone IP da Índia.

Depois que a localização geográfica tiver sido configurada no cluster dos EUA, o comportamento para os cenários 2 e 4 será o mesmo. O cluster da Índia não precisa esperar por uma ATUALIZAÇÃO/CONVITE SIP do cluster dos EUA, pois a negação de chamadas ocorrerá no próprio cluster dos EUA devido à entrada em vigor da partição lógica no lado dos EUA. 

Com isso, você deve ter o CUG trabalhando entre o cluster da Índia e dos EUA e garantir que não combine a chamada VOIP de um cluster com a chamada PSTN de outro cluster.

Expanda-se no futuro 

Adicionando um novo cluster à rede corporativa

Para escalar e acomodar novos clusters, suponha que você tenha dois novos clusters para adicionar. Cluster do Reino Unido e Cluster da França.

Em termos de configuração com a configuração existente, você adiciona estes

Na Índia

• Basta adicionar uma Geolocalização do Reino Unido e uma Geolocalização da França no Cluster da Índia.
• Atribua a ICT Geolocation ao tronco SIP que vai para o Reino Unido e a França.
• Verifique se a caixa de seleção Send Geolocation Information está marcada em SIP Trunk ou ICT.

Cluster do Reino Unido

• Criar Geolocalização para o Reino Unido, ICT e Índia com o mesmo filtro de outros clusters (semelhante à configuração de cluster dos EUA).
• Mantenha a política padrão como permitida.
• Verifique se a caixa de seleção Send Geolocation Information está marcada em SIP Trunk ou ICT.
• Atribua o filtro de localização geográfica e localização geográfica ao tronco SIP/ICT como ICT.
• Criar 2 políticas lógicas para a política do Reino Unido e para a política da Índia.
• Na política do Reino Unido, configure a relação lógica de partição entre a fronteira do Reino Unido para o interior da Índia como deny.

Cluster France

• Criar localização geográfica para França, ICT e Índia com o mesmo filtro de outros clusters (semelhante à configuração de cluster dos EUA).
• Mantenha a política padrão como permitida.
• Verifique se a caixa de seleção Send Geolocation Information está marcada em SIP Trunk ou ICT.
• Atribua o filtro de localização geográfica e localização geográfica ao tronco SIP/ICT como ICT.
• Criar 2 políticas lógicas, a política da França e a política da Índia.
• Em França, a política configura a relação de partição lógica entre a fronteira da França com o interior da Índia como negação.

Adicionar qualquer novo cluster de um país diferente estaria seguindo as etapas acima. Isso mantém a configuração em um nível mínimo e é capaz de escalar se você adicionar mais clusters

O que fazer se você tiver um SME?

As PME atuam como portadoras de informações sobre geolocalização sem participarem em qualquer particionamento lógico no cluster SME.

• Marque a caixa de seleção Send Geolocation Information em SIP Trunk ou ICT.
• Não há necessidade de configuração de geolocalização em SME.

.

Todas as configurações de localização geográfica e particionamento lógico são feitas somente no nó de folha. A configuração no nó folha é semelhante a uma configuração de geolocalização entre dois clusters sobre ICT. O SME simplesmente passa as informações de geolocalização que recebe em um tronco para outro, pois atua como um proxy.  

Note: A lista não é de modo algum exaustiva. Como administrador, você precisa testar estacionamento de chamadas e atendimento de chamadas (local e remoto), SNR, EM, EMCC, HuntPilot, transferência e conferência relacionadas a CTI, conferência Ad-Me, Meet-Me no cluster e testá-lo. 

Limitação

Cadeamento de conferência - por exemplo, conferência dentro em cadeia MeetMe e Adhoc pode ter participantes que são LP negados, mas não podem ser impedidos de estar em comunicação.

Recomendação - Desabilite o encadeamento de conferência de seu parâmetro de serviço. 

Caso principal de CBarge/Barge - Quando a parte conectada é uma ponte de conferência devido a um recurso ativo, como Conferência ou Meet-Me, e um dispositivo de linha compartilhada ativo se associa à geolocalização permitida para todos os dispositivos na Conferência, o dispositivo de linha compartilhada em utilização remota mostra informações sobre a instância da chamada. Nesse caso, o telefone em uso remoto sempre pode executar o recurso IntercC/Interc mesmo que um participante não autorizado participe da conferência. Para os participantes em IntercC/Interc, não existe nenhuma verificação de política de particionamento lógico e os cenários de particionamento lógico negado não podem ser evitados.  

Informações Relacionadas

• 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

• Suporte Técnico e Documentação - Cisco Systems