Cisco CUCM Bloqueio de chamadas por Calling

Cisco CUCM Bloqueio de chamadas por
Calling Party Number (ID):
Tradução por Rogerio Rodrigues
De tempos em tempos, o administrador do Cisco Unified Communications Manager (CUCM) recebe um pedido
para bloquear chamadas de entrada para uma organização com base no
calling party number (CPN). Isto é
comumente conhecido como "lista negra". Historicamente, os administradores podem usar translation profiles
nos dial-peers para atender a essa necessidade. Com o CUCM 8.0 as opções disponíveis para um administrador
foram ampliadas, aproveitando uma nova diretiva de rota nos padrões de tradução.
Background
A abordagem descrita neste blog é focado em filtragem de chamadas com base no CPN como apresentado a
partir da PSTN (via um gateway de voz ou CUBE). Ele não aborda "lista negra" para Cisco Mobility ou outros
casos de uso estação-para-estação ou estações-para-PSTN.
Um caso de uso típico é para bloquear chamadas de marketing, chamadas de recrutamento, ou qualquer outra
chamada, que geralmente é indesejada. A ideia é que o administrador cria uma lista de CPNs que devem ser
bloqueados e qualquer outra coisa é permitido. Verdadeiramente um conceito básico.
Antes de CUCM 8.0, o método mais comum para a lista negra de chamadas de entrada desconhecidas com
base em CPN era aproveitar translation-profiles em um gateway Cisco IOS. Com o lançamento do CUCM 8.0,
não há outra opção criada disponível para os administradores que eu acredito melhorar a sustentabilidade
operacional global.
O Método Translation-Profile
No exemplo acima, a chamada é apresentada ao gateway de voz pela PSTN. O gateway utiliza um translationprofile em uma entrada dial-peer POTS para "testar" o CPN contra uma lista de números "bloqueados". Se o
CPN está na lista de bloqueio, em seguida, a chamada é rejeitada utilizando uma mensagem
administrativamente definida. Se o CPN não está bloqueado, então o gateway de voz continuará processando a
chamada, correspondente a VoIP leg dial-peer, e tudo está bem no mundo.
Um exemplo de configuração de suporte do fluxo de chamadas descrito poderia ser:
!Voice Translation Rule set
voice translation-rule 69
rule 1 reject /^800.*/
rule 2 reject /2025551000/
rule 3 reject /7035551000/
!
!Voice Translation Profile Assignment
voice translation-profile all-blacklist
translate calling 69
!
! Sample POTS Dial-Peer
dial-peer voice 39001 pots
description Ingress From PSTN
incoming called-number 301555....
call-block translation-profile incoming all-blacklist
call-block disconnect-cause incoming call-reject
direct-inward-dial
port 0/0/1:23
forward-digits 10
!
O dial-peer POTS 39001 está tratando o ingresso de chamadas da PSTN e está configurado para verificar os
elementos de informação de configuração de chamada ISDN (IE) contra um translation profile para determinar se
a chamada é permitida. O translation profile "all-blacklist" identifica a translation-rule e o IE que deve ser
avaliado. Especificamente, o IE calling.
A translation-rule "69" define vários padrões que devem ser rejeitados. Ou seja, qualquer número que se inicia
com 800, as chamadas de 2025551000, e chamadas de 7035551000.
O método descrito acima é aplicável apenas às configurações de SIP e H.323. Ele não funciona com MGCP. Um
outro ponto de interesse é que há um limite de 15 regras em translation-rule. Felizmente, eu não superei esse
limite, mas eu suspeito que algumas pessoas sim.
CUCM Rota Next Hop através de Calling Party Number
No CUCM versão 8.0, a Cisco adicionou o recurso Hotline (Hotline Feature). Um elemento de configuração
adicionado para suportar esse recurso é um novo parâmetro nas Translation Patterns. Este novo parâmetro pode
ser utilizado para instruir a rotina de análise de dígitos CUCM para avaliar a chamada através de CPN, ao invés
de called party number (DNIS). Este parâmetro de configuração é chamada "Rota Next Hop através de Calling
Party Number" e pode ser usado para facilitar a "black list" CPNs sem exigir que o administrador use o recurso
de Hotline.
O diagrama a seguir ilustra um exemplo de fluxo de chamadas onde a filtragem CPN é facilitada por esta nova
capacidade.
O fluxo de chamada pode ser descrito como se segue:
1. A operadora PSTN apresenta a chamada para o gateway de voz.
2.
O gateway de voz processa a chamada e, em seguida, retransmite informações de configuração de
chamada para o CUCM.
3. O objeto gateway no CUCM está configurado para usar CL_PSTN-In_CSS, o qual é usado para o passo
inicial de análise de dígitos.
4. A translation pattern na route partition CL_PSTN-In_PT está configurada para capturar qualquer CPN
usando o padrão de dígitos "!"
o
Translation Pattern: !
o
Partition: CL_PSTN-In_PT
o
Calling Search Space: CL_PSTN-Screen_CSS
o
Route Option: Route this pattern
o
Route Option: Urgent Priority
o Route Option: Route Next Hop by Calling Party Number
5. Supondo-se que a CPN está presente, o CUCM continuará a análise de dígitos usando CL_PSTNScreen_CSS.
6. A CL_PSTN-Screen_CSS contém uma partição, CL_PSTN-Screen_PT e esta partition conterá allow and
deny patterns. Aqui que a mágica acontece.
Antes de ir para a forma como queremos alavancar CL_PSTN-Screen_PT, eu quero salientar algo sobre o que
está acontecendo no Passo 4. Eu tentei esta configuração algumas vezes no meu laboratório sem sucesso e eu
percebi duas coisas. Primeiro, eu preciso trabalhar em minhas habilidades de compreensão de leitura. Em
segundo lugar, o termo "Route Next Hop por Calling Party Number" deve ser lido literalmente.
O que está acontecendo aqui é que o pattern "!" em CL_PSTN-In_PT está dizendo a CUCM "avaliar o CPN
contra os patterns na CL_PSTN-Screen_CSS". Originalmente, eu estava tentando adicionar meus padrões de
bloqueio para CL_PSTN-In_PT com o flag "Route Next Hop" e o flag "Block this pattern"" definido no mesmo
padrão. Isso não funciona.
Em vez disso, o que você precisa fazer é criar padrões de tradução em CL_PSTN-Screen_PT que são
configurados como os padrões normais de tradução (ou seja, não marque a opção "Route Next Hop pelo Partido
Número de chamada" opção). O processo de análise de dígitos CUCM vai fazer é tomar o CPN e compará-lo
com o padrão de tradução (s) em CL_PSTN-Screen_PT.
Continuando com nosso exemplo, como você pode ver na figura, definimos os seguintes padrões de tradução
em CL_PSTN-Screen_PT:
Em vez disso, o que você precisa fazer é criar translation patterns em CL_PSTN-Screen_PT que são
configurados como os translation-patterns normais (ou seja, não marque a opção ""Route Next Hop by Calling
Party Number"). O que o processo de análise de dígitos do CUCM vai fazer é pegar o CPN e compará-lo com as
translation-pattern (s) em CL_PSTN-Screen_PT.
Continuando com nosso exemplo, como você pode ver na figura, definimos os seguintes Translation-patterns em
CL_PSTN-Screen_PT:
• "!": Este padrão é essencialmente nosso explícito "allow all" padrão e o flag Route Option "Route this pattern".
Você precisa disto para permitir a configuração de chamada para continuar por patterns que você deseja permitir
completamente.
• Os seguintes patterns são configurados com o flag Route Option "Block this pattern". Assim, as chamadas de
um CPN que corresponde a qualquer um desses patterns é bloqueado:
o "2025551000": jogo padrão específico.
o "800": Qualquer CPN que começa com 1800 ou 800 é correspondido.
Ao bloquear um pattern, o administrador pode selecionar um dos códigos de causa de desconexão para enviar
de volta para a operadora PSTN (via gateway de voz). A seleção de "Call Rejected" pode ser a opção preferida,
pois é o sistema que origina a chamada é automatizado (ou seja, discador preditivo de uma empresa de
marketing), então existe a possibilidade de o sistema atuar na mensagem de informação rejeitada e remover o
DNIS de sua tabela de marcação de destino .
Resumo dos passos de configuração
In my lab, I used the following configuration procedures.
1. Criar partitions:
o
CL_PSTN-In_PT: Esta partition realizará as translations com flag comportamento "Route Next Hop".
o
CL_PSTN-Screen_PT: Esta partição realizará as translations usadas para avaliar o CPN.
2. Criar Calling Search Spaces:
o
CL_PSTN-In_CSS: Esta é a CSS atribuida ao gateway de voz e que contém a CL_PSTN-In_PT.
o
CL_PSTN-Screen_CSS: Esta é a CSS atribuída aos patterns na CL_PSTN-In_PT. Esta CSS contém a
CL_PSTN-Screen_PT.
o
CL_Tenant-Control_CSS: Esta CSS está atribuída aos patterns in CL_PSTN-Screen_PT e contém
partitions que contém DN´s de telefones e outros patterns que faz o roteamento para dispositivos ou
aplicações no cluster CUCM.
3. Atribuir a CL_PSTN-In_CSS para o gateway de voz.
4. Adicione o "Route Next Hop" translation "!" para a CL_PSTN-In_PT. Selecione a CL_PSTN-Screen_CSS,
habilite call routing, and habilite "Route Next Hop by Calling Party Number". NOTE: Você também pode
aplicar calling or called party transformations nesta etapa, conforme necessário.
5. Adicione o "allow all" translation "!" para CL_PSTN-Screen_CSS, habilite call routing, e NÃO habilite "Route
Next Hop by Calling Party Number".
6. Adicione todas "black list" translation. Habilite call blocking, selecione disconnect cause reason, e está pronto
para testar.
Considerações
Eu não sou certo porque a Cisco optou por usar aqui uma abordagem "próxima instrução". Estou certo de que há
uma boa razão e provavelmente está relacionada à forma como o recurso Hotline é projetado para operar. Eu
tentei misturar translations que foram roteadas na called party e translations que tiveram a opção "Route Next
Hop" ativada. Desta maneira, removendo um dos passos prescritos. Isso não funciona como seria de esperar.
Em meus testes, a análise dígitos do CUCM sempre preferiu roteamento por informações de called party se você
misturar patterns na mesma CSS.
Os exemplos de configuração fornecidos assumem que as chamadas que entram no CUCM estão apresentando
um CPN válido. Se as chamadas que entram no sistema são sinalizadas como privado, CPN não é fornecido. O
padrão "!" não vai te ajudar e você pode precisar olhar para isso usando um padrão nulo (em branco), na
CL_PSTN-In_PT e CL_PSTN-Screen_PT. (Eu não testei isso).
Conclusões:
Eu ainda estou trabalhando com a execução da abordagem do CUCM descrita neste blog através de alguns de
nossos cenários de design de produção para fins de validação. Até o momento, a abordagem parece viável para
aqueles que usam MGCP gateways, gostaria de centralizar roteamento de chamada no CUCM, ou superado os
limites com o número de regras que podem ser atribuídos a uma Translation-rule definida no IOS.