O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve todas as perguntas frequentes relacionadas à implementação da Geolocalização no Cisco Unified Communications Manager (CUCM).
Este é um mecanismo para selecionar uma localização geográfica para um dispositivo:
Etapa 1. Selecione a localização geográfica na configuração do dispositivo.
Etapa 2. Se não estiver configurado na página do dispositivo:
Etapa 3. No DP selecionado, leia o valor da geolocalização da configuração do DP. Se o DP não estiver configurado com um valor para Geolocalização, o dispositivo usará um valor de Geolocalização em branco.
Etapa 4. Se o dispositivo ler um valor de Geolocalização em branco, o próximo nível é Default Geolocation Enterprise Param, que é acessado no momento da verificação de política ou da transferência de localização.
Este é o mecanismo que é seguido para selecionar um filtro de localização geográfica para um dispositivo:
Se nenhum valor estiver configurado, leia do DP:
A política padrão do sistema deve ser Negar para uma empresa, de modo que as chamadas ou funcionalidades sejam bloqueadas entre participantes de dispositivos VoIP, ou seja, um telefone e um gateway, um gateway e outro gateway, uma TIC e um telefone, uma TIC e um gateway.
Para permitir a comunicação VoIP, com base na topologia de rede VoIP, as políticas Allow devem ser configuradas navegando para System > Logical Partitioning Configuration.
Por exemplo, tipicamente um Gateway em um site terá permissão para se comunicar com telefones ou outro Gateway nesse site, de modo que, de acordo com isso, as políticas /por site serão permitidas.
O administrador precisará garantir que essa configuração esteja presente na configuração de Parâmetros empresariais:
BlankGeolocation - Isso precisa ser configurado no System > Geolocation Configuration e não preencher nenhum dado.
Além disso, o administrador precisará configurar as políticas de permissão na tela Roteamento de chamada > Configuração da política de particionamento lógico.
Isso evita qualquer tráfego Public Switched Telephone Network (PSTN) para VoIP ou PSTN, a menos que uma política Allow esteja configurada na configuração desse dispositivo.
A razão pela qual o BlankGeolocation é configurado é para cobrir os dispositivos em um cluster que não são associados a nenhuma Geolocalização por meio da configuração do dispositivo ou do DP.
Por padrão, a localização geográfica não especificada significa que o dispositivo não participará de nenhuma verificação de LP.
O BlankGeolocation garante que não ocorra nenhum cenário contra a regulamentação.
No momento da pesquisa de política, uma política como essa seria pesquisada sem nenhum campo de localização geográfica e não haverá nenhuma configuração desse tipo no sistema:
A transferência de GeoLocation de um agente de usuário SIP para outra entidade com o uso do SIP é chamada de Location Conveyance.
Aqui GeoLocation é uma descrição da área geográfica física onde algo existe atualmente.
O IETF RFC 3693 (requisitos Geopriv) descreve a localização geográfica no formato PIDF-LO (Presence Information Data Format) e draft-ietf-sip-location-transportadora-10 descreve a transferência de localização.
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 com o uso de PIDF-LO.
O UCM suporta a transmissão de informações de localização tanto no estabelecimento da chamada quanto alterações de localização devido a alterações na parte conectada na participação em associações e redirecionamentos de chamada média.
Se esse dispositivo fizer ou receber uma chamada, a localização geográfica associada será transmitida pelo tronco ou pela ICT.
O recurso Particionamento lógico é baseado em uma estrutura de Geolocalizações. Desde que os dispositivos participantes em um recurso estejam dentro do cluster, o UCM recebe as informações de localização associadas das configurações locais.
Se os dispositivos dos participantes estiverem em clusters, então para a finalidade de verificar a política, serão necessárias informações de localização geográfica com dispositivos em todo o cluster.
Há duas opções possíveis:
Chamadas recebidas - O cluster remoto se enviar PIDF-LO na sinalização de chamada, a localização real está disponível para verificação de política e será usada mesmo antes de fazer/tocar a chamada para o dispositivo UCM.
Chamadas de saída - O dispositivo UCM que faz uma chamada para Tronco SIP ou ICT precisaria de uma política de LP, para que a chamada possa ser estendida para um cluster remoto. Essa política será igual a 1. A localização "real" de um dispositivo (telefone ou gateway VoIP) no cluster deve ser recebida durante a fase de alerta. O UCM "deve" ter uma política de "permissão" correspondente (o Interior para o Interior não precisará de nenhuma política. Sim, se um ou ambos os dispositivos envolvidos forem Borda)
A transferência de localização oferece uma oportunidade para fazer cenários com base na localização real e nos tipos de dispositivos.
Basicamente, as informações de localização geográfica são transportadas de ponta a ponta em uma empresa.
Esse tipo de implementação é importante para implantações, em que as chamadas são redirecionadas para frente e para trás nos clusters e a verdadeira Geolocalização, precisa ser levada junto com a chamada, o que ajudaria na verificação correta do LP.
SIP: CONVITE, ATUALIZAR.
Tronco ICT/H225: Configuração, Alerta, Progresso, Notificar, Conectar.
O administrador precisa seguir estas etapas:
Roteamento de chamada > Configuração de particionamento lógico.
Essas informações são transportadas em um elemento de tampa do dispositivo PIDF-LO.
Atualmente, as informações são comunicadas na tag proprietária:
<caps:devcaps>
<cisco:gateway>false
</caps:devcaps>
Quando essas informações são recebidas, o UCM as mapeia para a enumeração interna do UCM para representá-las para o tipo de dispositivo do CallManager.
Esse requisito é importante principalmente para um cluster habilitado para LP, onde é necessário permitir/negar o tráfego de telefones VoIP para ICT ou Gateway PSTN para ICT.
A localização geográfica e o filtro asseguram que o identificador seja feito para participação na verificação de LP. Em correspondência, uma política de LP (políticas) deve ser configurada.
A relevância da geolocalização do dispositivo de tronco SIP na transferência de localização (aquela configurada no tronco SIP):
A localização geográfica associada a um chamador ou dispositivo chamado é aquela usada para a transferência de localização. Diga que o telefone A (geoloc1) faz uma chamada através do SIPTrunk/ICT (configurado com geoloc2). A Geolocalização que é enviada na transferência de local é geoloc1.
Suponha que um tronco SIP, um tronco1 (geoloc3) que aponte para um gateway SIP receba uma chamada PSTN. Diga que a chamada é encaminhada pelo UCM para SIPTrunk/ICT (geoloc2). A Geolocalização que é enviada na transferência de local é geoloc3 (que é configurada no tronco1).
Não. As políticas de LP são específicas somente para o cluster local. Não há comunicação entre clusters de políticas de LP.
Yes. O LP não é um pré-requisito para a conversão de local. Na verdade, o LP é um dos recursos que usa a funcionalidade de transporte de local.
A verificação de política é implementada como um mecanismo de pesquisa em árvore, que é uma comparação de cadeia de caracteres para cada campo da localização geográfica. Se os filtros forem usados em campos curtos, digamos 4 a 5, eles serão mais rápidos em comparação com o uso de todos os 17 campos nas configurações de filtro e política.
Há duas maneiras de usar o LP:
Ambas as implementações são consideradas razoáveis em termos de desempenho.
Os campos de localização geográfica podem ser configurados como Unicode e com limites máximos de tamanho. Isso pode não ser recomendado para a verificação da política de LP.
Selecione de 2 a 3 telefones com o uso de uma única linha, em cada local, para realizar testes piloto:
Como você não associou Geolocations a todos os dispositivos, ele não participaria da verificação de política de LP.
Teste os cenários suplementares com telefones piloto e outros telefones de produção para garantir que as coisas funcionem conforme esperado.