Opções de download

PDF (1.9 MB)
Ver no Adobe Reader em vários dispositivos
ePub (1.8 MB)
Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
Mobi (Kindle) (1.6 MB)
Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos

Atualizado:23 de Maio de 2017

ID do documento:211280

Sobre a tradução

Sobre esta tradução

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.

Índice

Pré-requisitos

Componentes Utilizados

Informações de Apoio

Elementos da divisão lógica

Geolocation

Filtro de Geolocation

Política lógica da separação

Configuração

Troubleshooting

Pontos a meditar

Referências

Bug conhecido

Introdução

Este documento descreve como configurar a divisão lógica e o Geolocation no gerente das comunicações unificadas de Cisco (CUCM).

Pré-requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

Cisco unificou o gerente de uma comunicação

Componentes Utilizados

Gerente 8.6 das comunicações unificadas de Cisco ou mais atrasado

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Informações de Apoio

A característica de divisão lógica assegura-se de que um único sistema possa ser usado para apoiar ambos os tipos de atendimentos enquanto os atendimentos que passam através de um gateway da rede telefônica pública comutada (PSTN) não conectam diretamente a uma Voz sobre o telefone IP (VoIP) ou o gateway PSTN de VoIP em uma outra localização geográfica (geolocation) mesmo quando uns recursos de chamada meados de são invocados.

Em alguns países tais como a Índia, há os regulamentos das telecomunicações que têm que ser encontrados no nível da empresa. Devido a qual as empresas são responsáveis estabelecer uma infraestrutura da Voz. Setup tais que o PSTN local está usado exclusivamente ao conectar chama fora da empresa. De acordo com a autoridade reguladora das telecomunicações (TRAI), a rede de telefonia PSTN na Índia deve nunca ser interconectada com rede de telefonia de VoIP com a finalidade do Toll Bypass.

Isto exige que o sistema de voz esteja dividido logicamente em dois sistemas: um VoIP dentro da empresa e de uma segunda para alcançar o PSTN local.

Era bastante difícil manter meio este sistema de voz com a característica do Calling Search Space (CSS) e da separação em CUCM. O CSS e a separação podem restringir as chamadas básicas, mas não restringe recursos de chamada meados de como reoriente e se junte.

Elementos da divisão lógica

Geolocation

CUCM exige o abastecimento dos identificadores atribuindo aos dispositivos como telefones, gateways, troncos, etc. Geolocation é um padrão que possa ser usado como um mais idenfitier na divisão lógica.

Geolocation é usado para especificar o local físico baseado em até 17 parâmetros: A abreviatura da letra do país 2, o estado (A1), o condado (A2), a cidade (A3), o distrito (A4), a vizinhança (A5), a rua (A6), o sentido (PRD), o sufixo da rua (VAGEM), o número da casa (HNO) e o número da casa Suffix (HNS) entre outros.

Filtro de Geolocation

Uma configuração das normas lógica típica da separação usa somente o subconjunto dos campos no registro da política de Geolocation. Esta seleção é reduzida para baixo pelo filtro de Geolocation. Os campos que são selecionados no filtro de Geolocation são usados pela característica de divisão lógica.

Política lógica da separação

Em CUCM, a divisão lógica é definida como uma característica do Controle de chamadas que possa ser usada para restringir a comunicação entre estas entidades de VoIP com a ajuda das políticas de divisão lógicas.

Telefone IP para/desde o gateway
Gateway ao gateway
Telefone IP para/desde o tronco (tronco ICT/SIP)
Gateway para/desde o tronco (tronco ICT/SIP)

Os dispositivos na separação lógica são categorizados como o interior e a beira. Estes são os dispositivos classificados como o interior:

Telefones (SCCP, SORVO, terceira parte)
Telefones analógicos VG224
Porta MGCP (FXS)
Correio de voz do Cisco Unity (SCCP)
Ponto de rota CTI, porta CTI
Gateway QSIG ou ICT

Estes dispositivos são categorizados como a beira:

Gateway
Tronco intercluster (ICT)
Tronco H.225
Tronco do SORVO
Porta MGCP (E1, T1, PRI, BRI, FXO)

Configuração

Etapa 1. O padrão Geolocation é aplicável para os dispositivos em que nenhum Geolocation é configurado e não participa na divisão lógica. Para ajustar a política de Geolocation do padrão joga um papel principal, se é ajustado para o permitir então é necessário apropriar políticas lógicas da separação com nega a funcionalidade e vice-versa.

Etapa 2. Vá à configuração de System-> Geolocation e adicionar o relativo à informação ao lugar. Isto atua como um identificador para os dispositivos que são associados com este Geolocation particular.

Etapa 3. Vá ao filtro de System-> Geolocation e verifique os campos na configuração de filtro de Geolocation baseada no que a política lógica é exigida para filtrar contra.

Etapa 4. Configurar a política lógica da separação. Esta é a maioria de parte importante da configuração como todas as decisões a reservar ou para negar os atendimentos dependem de sua configuração.

Etapa 5. Vá à página da configuração de dispositivo do telefone e aplique o geolocation segundo onde o telefone é encontrado.

Vá similarmente ao pool de dispositivos e adicionar a configuração do geolocation.

Etapa 6. Em seguida vá à página de configuração para a porta do gateway/Trunk/MGCP que atua como uma relação ao PSTN e aplique a configuração do geolocation e o filtro do geolocation.

Troubleshooting

A etapa 1.Check nos parâmetros empresariais que permitem a opção de divisão lógica é ajustada para retificar.

Etapa 2. Certifique-se de que os dispositivos estão associados com um geolocation válido a nível do dispositivo ou do pool de dispositivos.

Etapa 3. Verifique dentro a página de configuração que o dispositivo esteja associado com um filtro válido do geolocation, tendo a seleção de alguns dos campos do geolocation a nível do dispositivo ou do pool de dispositivos.

Etapa 4. Certifique-se que a detecção de letra maiúscula está correta para campos dos registros de LP GeolocationPolicy e se combine com a configuração dos registros do geolocation.

Etapa 5. A configuração do geolocation, os filtros e as políticas podem igualmente ser verificados do CLI com a ajuda destes comandos sql.

run sql select * from geolocationfilter
run sql select * from geolocationpolicy
run sql select * from geolocationpolicymatrix
run sql select * from typelogicalpartitionpolicy

Etapa 6. Depois que a configuração básica é verificada, verifique o relacionamento ajustado entre políticas do geolocation. Quando a política padrão de divisão lógica do parâmetro empresarial é ajustada para negar, para verificar se reserve políticas lógicas da separação entre a política de Geolocation de um local do gateway & do VoIP estão configurados. Pelo contrário, se a política padrão é conceda, verifique se negue políticas lógicas da separação são configurados.

Etapa 7. Certifique-se que não há nenhuma política de sobreposição ou de oposição configurada.

Exemplo.

LP-India->Interior LP-Pudong->Border reserva

LP-Pudong->Border LP-India->Interior nega

Aqui o relacionamento lógico entre políticas tem um conflito. Se uma LP-Índia interior da política lógica para limitar LP-pudong é configurada, implica que esta relação guarda verdadeiro para Beira-LP pudong à LP-Índia. Estas políticas são bidirecionais na natureza.

Assim neste exemplo, de acordo com a primeira política, os Telefones IP internos no lugar de Pudong são permitidos chamar através da PRI-Índia. Ao mesmo tempo, os atendimentos PSTN da PRI-Índia aos Telefones IP em Pudong Geolocation são permitidos.

Mas conforme a segunda política, os atendimentos do Índia-PRI aos Telefones IP no lugar de Pudong são negados e vice-versa mas este opõe a primeira política.

Nesses casos, recorde que a política que foi adicionada por último tomará a precedência.

Etapa 8. Siga as políticas de sobreposição com característica de relatório unificada para obter a matriz lógica da política da separação. É muito útil pesquisar defeitos como você pode conhecer todas as políticas lógicas da separação configuradas em CUCM de uma única tela. A política unificada CM Geolocation com relatório do filtro fornece uma lista completa dos registros da matriz de divisão lógica da política de Geolocation para políticas selecionadas de Geolocation, quando o relatório unificado da política CM Geolocation fornecer uma lista completa dos registros de todas as políticas de divisão lógicas.

Etapa 9. Faça algumas chamadas de teste e verificação se trabalha. A ferramenta do monitoramento em tempo real (RTMT) é aumentada para seguir o número de falhas devido às limitações de divisão lógicas da política em contadores novos do perfmon. Os contadores do perfmon têm um grupo novo chamado limitação do atendimento de Cisco. Lá dos nós podemos seguir um número de falhas de chamada em encenações diferentes como falhas de Tansfer, falhas ad hoc da conferência, falhas da conferência Me Encontre, enviando falhas, falhas da chamada básica, falhas do Meados de-atendimento, falhas da limitação da chamada total, etc.

Etapa 10. Recolha os traços CUCM de RTMT para a duração do atendimento. Na camada de distribuição de sinalização (SDL) segue-o pode ver a política que estão sendo selecionadas e as políticas que são configuradas entre os pares da política de Geolocation.

Uma comunicação da informação de Geolocation em sinais CC.

| SdlSig    | CcRegisterPartyA                      | restart0                      | LineControl(1,100,139,3)        | SIPCdpc(1,100,55,17)            | (1,100,45,1).3035-(SEP0019555CBAE3:10.76.253.14)| [R:NP - HP: 0, NP: 2, LP: 0, VLP: 0, LZP: 0 DBP: 0]CI=23624774 CI.branch=0  CSS= cssIns=0 aarCSS= aarDev=T doNotAppendLineCSS=F lrg= ccBearCap.itc=0 ccBearCap.l=3 ccBearCap.itr=1 protected=1 flushCapIns=0 geolocInfo={geolocPkid=9dc76052-3a37-78c2-639a-1c02e8f5d3a2, filterPkid=d5bdda76-6a86-56c5-b5fd-6dff82b37493, geolocVal=, devType=4} locPkid= locName=

Uma comunicação da informação de Geolocation em sinais de PolicyAndRSVP.

| SdlSig    | PolicyAndRSVPRegisterReq              | wait                          | RSVPSessionMgr(1,100,76,1)      | SIPCdpc(1,100,55,17)            | (1,100,45,1).3035-(SEP0019555CBAE3:10.76.253.14)| [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]CI= 23624774 Branch= 0  reg=Default cap=5 loc=0 MRGLPkid= PrecLev=5 VCall=F VCapa=F regiState=0 medReq=0 dataCapFl=2 ipAddrMode=0 status=0 geolocInfo={geolocPkid=9dc76052-3a37-78c2-639a-1c02e8f5d3a2, filterPkid=d5bdda76-6a86-56c5-b5fd-6dff82b37493, geolocVal=, devType=4}
| SdlSig    | PolicyRegisterReq                     | await_init                    | LPSession(1,100,26,21)          | RSVPSessionMgr(1,100,76,1)      | (1,100,45,1).3035-(SEP0019555CBAE3:10.76.253.14)| [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]CI= 23624774 Branch= 0  geolocInfo={geolocPkid=9dc76052-3a37-78c2-639a-1c02e8f5d3a2, filterPkid=d5bdda76-6a86-56c5-b5fd-6dff82b37493, geolocVal=, devType=4}

Pontos a meditar

Os dispositivos isto é (Media Termination Point) MTP dos media, (bridge de conferência) CFB, sinal luminoso, (música na posse) MoH não são exigidos ser associados com os valores do geolocation.
Não há nenhuma verificação da política de LP para VoIP ao atendimento ou à característica do dispositivo voip com somente os participantes de VoIP. Ou seja o interior à política interior é permitido sempre.
LPPolicyManager é um processo do solteirão que as relações com InMemDB e mantenham políticas no Processamento de chamadas como a árvore da política de LP. Durante CUCM preste serviços de manutenção à partida, o LPPolicyManager lê as políticas das tabelas de InMemDB e constrói a árvore da política de LP. Adicionar/supressão/atualização de uma política em resultados DB na notificação de alteração a LPPolicyManager e a mudança são afetados na árvore da política de LP.

Verificação de divisão lógica da política.

001853112| 2008/09/26 11:50:39.687| 001| AppInfo   |                                       |                               |                                 |                                 |                                         | LPPolicyManager -getLogicalPartitionPolicy, GeolocInfoA[pkid=31396408-3d83-74a9-1655-d2f0a05dd0a4, filter=d5bdda76-6a86-56c5-b5fd-6dff82b37493, val=, devType=4]
001853113| 2008/09/26 11:50:39.687| 001| AppInfo   |                                       |                               |                                 |                                 |                                         | LPPolicyManager -getLogicalPartitionPolicy, GeolocInfoB[pkid=9dc76052-3a37-78c2-639a-1c02e8f5d3a2, filter=d5bdda76-6a86-56c5-b5fd-6dff82b37493, val=, devType=8]

O DevType que aparece nos traços descreve os tipos dos dispositivos.

O devType =4 (UserDevice) é para estes dispositivos.

Telefones (SCCP, SORVO, terceira parte)
Telefones analógicos VG224
Pontos de rota e portas CTI CTI
Correio de voz do Cisco Unity (SCCP)
Porta MGCP (FXS)

O devType =3 (AccessDevice) se para estes dispositivos.

Tronco intercluster (ICT), controlado por gatekeeper e tronco non-gatekeeper-controlledH.225
Porta MGCP (E1, T1, PRI, BRI, FXO)
Gateway (por exemplo, gateway de H.323)

O devType =8 (SIPAccessDevice) para este dispositivo.