segunda-feira, 8 de julho de 2013

Translation Pattern ou Transformation Pattern? (Parte 2/2)

No post passado falei sobre Translation Pattern, que é realmente mais simples e parte do nosso dia-a-dia. Recebi até um feedback de que o assunto estava muito fácil! hahaha! A minha ideia inicial era fazer um único texto abordando Translations e Transformations Patterns, mas como estava ficando muito grande, resolvi quebrar em dois. Hoje, portanto, continuo o assunto iniciado na semana passada, e começo as minhas considerações sobre Calling Party Transformation Patterns e Called Party Transformation Patterns, que são igualmente de extrema importancia para a prova.

Transformation Patterns

Existem dois tipos de Transformation Patterns no CUCM, a Called e a Calling. A primeira serve para alterar o número de destino (DNIS) e a segunda para alterar o número de origem (ANI) da chamada. Veja que a única que teria potencial para alterar o roteamento da chamada dentro do Call Manager é a Called, pois todas as entidades do sistema analisam o DNIS para tomar essa decisão, e nunca o ANI.

Bom, no post passado eu disse que se fosse para resumir a diferença entre Translations e Transformations Patterns em uma frase, eu diria que as Transformations Patterns não alteram a decisão de roteamento no CUCM. Pois bem, como vimos anteriormente, as Translations de fato alteram essa decisão de roteamento. Mas as transformations, por sua vez, não. As Called Party Transformation Patterns são utilizadas depois que o Call Manager fez a sua escolha de encaminhamento da chamada, logo antes de ele enviar os digítos para o device de destino, seja ele um Gateway ou um Trunk (Called Party Transformation Patterns não são suportadas para IP Phones). Vejamos graficamente essa difença.

- Translations Patterns (imagem do post anterior):



- Called Party Transformation Patterns:


Repare a diferença. As translations são verificadas primeiro em uma chamada, e elas podem alterar o DNIS (Called Number) e ANI (Calling Number), para depois dar match em uma Route Pattern ou DN. Já as Called Party Transformation Patterns são usadas para alterar o DNIS depois que o Call Manager já decidiu para onde vai a chamada, e é invocada pelo próprio Device (Gateway ou Trunk) no sentido Outbound.

Então por exemplo, você ligou para o número 001123232000 a partir de um IP Phone. Os dígitos deram match em uma Route Pattern, que encaminha para um Gateway H.323 de IP 10.10.1.1. Então a decisão do CUCM já está tomada: ele vai mandar para o 10.10.1.1 e ponto final. Mas antes disso, o Gateway pode chamar uma Called Party Transformation Pattern, e alterar o DNIS para 023232000. Veja que isso não vai mudar em nada as coisas para o CUCM, ele vai continuar mandando a chamada para o 10.10.1.1, só que com o DNIS manipulado.

Ok, falamos das Called Party Transformation Patterns. Mas e as Calling Party Transformation Patterns? Bom, elas servem para alterar o número de origem (ANI), e isso também não vai alterar nada com relação ao roteamento da chamada dentro do CUCM. Os devices que podem chamar uma Calling Party Transformation Pattern são os IP Phones no sentido outbound  e os Gateways/Trunks no sentido inbound ou outbound. Lembrando que Outbound é quando o CUCM envia a chamada para algum lugar, e Inbound é quando alguém envia a chamada para o CUCM. Vejamos as figuras que representam essas situações:

- Calling Party Transformation Patterns (Gateway/Trunk Outbound)


Nessa situação, o CUCM pode modificar o número de origem antes de encaminhar a chamada para um Gateway ou Trunk. Por exemplo, o ramal de origem é o 2000, e ele ligou para o número 022225555 da PSTN. Os dígitos deram match em uma Route Pattern, que encaminha a chamada para um Gateway via H.323. Logo antes de a chamada ser encaminhada, o CUCM muda o ANI de 2000 para 23232000. Veja que o roteamento da chamada não alterou em nada, o CUCM apens mudou o Calling Number antes de encaminhar para o roteador.

Ok, poderíamos fazer isso na propria Route Pattern, certo? Ou até na Route List / Route Group. Mas fazendo no gateway é mais fácil, porque ele aplicaria a regra para TODAS as chamadas que fossem encaminhadas para aquele gateway/trunk específico. Caso seja essa a nossa vontade, é muito mais fácil do que configurar a regra rota a rota, né? No entanto, como já disse um milhão de vezes no post anterior, caso o gateway seja H.323, esse tipo de manipulação é preferível que se faça no IOS, aplicando nas dial-peers, para que continue funcionando em SRST.
Então para a prova, acho difícil você precisar usar a Calling Party Transformation Pattern como Outbound no Gateway/Trunk.

- Calling Party Transformation Patterns (Gateway/Trunk Inbound e Phone Outbound)



Aqui sim a coisa começa a ficar mais útil (e mais essencial para a prova). Nessa situação, tratamos uma chamada entrante da PSTN para um IP Phone registrado no CUCM. Veja que as regras que faremos aqui dependem do CUCM, então não funcionarão em SRST! Isso já é esperado.

Vamos lá... pela imagem podemos ver que a gente consegue manipular os dígitos do ANI em 2 lugares: No gateway, logo que o CUCM recebe a chamada, e no IP Phone, quando o CUCM envia a chamada para ele. Mas qual é a diferença? Ahá... esse é o ponto. A manipulação que ocorre no gateway, na entrada do CUCM, é o número que vai ficar marcado como ANI da chamada. Ou seja, é o que vai ficar registrado na lista de chamadas perdidas ou chamadas recebidas do telefone. Já a manipulação que ocorre no IP Phone é apenas para alterar como o ANI será apresentado ao telefone quando a chamada estiver tocando, mas não terá impacto nas listas de chamadas.

Por exemplo, uma chamada entrante do número 1122225555 da PSTN para o ramal 2000. Na manipulação do Gateway, eu posso fazer esse número de origem virar +551122225555. E na manipulação do IP Phone, eu posso fazer esse número virar 22225555. O resultado disso será o seguinte: enquanto a chamada estiver tocando no telefone, o visor vai mostrar "From: 22225555". Porém, lá na lista de chamadas perdidas/recebidas, vai estar registrado como +551122225555. Assim, o usuário consegue dar um Dial direto da lista (claro, você tem que configurar todo o call routing para suportar o formato +E.164), mas ao mesmo tempo, a chamada será apresentada de uma forma mais amigável no telefone.

Globalization e Localization

Com toda essa informação acima, junto com o post anterior, entramos em um conceito chamado Globalization e Localization, introduzida no CUCM 7, e que a Cisco pega muito pesado na prova. Globalization é isso de transformar o número em um formato global (+E.164, por exemplo +551122225555), e Localization é transformar de volta em um formato local (por exemplo 022225555). A regra é: Globalizar na entrada e Localizar na saída. Com isso, criamos um dial plan com suporte ao +E.164, e totalmente escalável.

Vamos a um exemplo, que configuraremos mais tarde. Aplicaremos de cabo a rabo essa ideia de Globalization e Localization, tanto em uma chamada entrante como em uma chamada sainte:

- Chamada entrante (PSTN --> IP Phone)


Na chamada entrante, usaremos somente o Calling Party Transformation Pattern, alterando o ANI tanto na entrada do CUCM (no Gateway) quanto na saída do CUCM (no IP Phone). A PSTN manda o ANI no formato 1122225555 (que é o caso na maioria das operadoras no Brasil), e no nosso exemplo, o Gateway não faz manipulação nenhuma. Ao chegar no CUCM, o Gateway invoca uma Calling Party Transformation Pattern e altera o ANI para +551122225555. O Call Manager, com posse do DNIS 2000 (que não sofreu nenhuma alteração), acha o DN, que está associado a um IP Phone. Quando o CUCM vai mandar a chamada para o IP Phone, ele chama uma outra Calling Party Transformation Pattern, que altera o ANI de +551122225555 para 22225555. Assim, no IP Phone vai aparecer a chamada "From: 22225555", e nas Call Lists (missed e received calls) vai ficar registrado como +551122225555.

- Chamada sainte (IP Phone --> PSTN)



Na chamada sainte, um IP Phone faz uma chamada para o número 022225555. Para Globalizarmos na entrada, contaremos com a ajuda de uma Translation Pattern, que vai transformar esse número para +551122225555. Por que precisa ser uma Translation e não uma Transformation? Porque queremos alterar isso antes de o CUCM tomar a sua decisão de roteamento. Uma vez globalizado, os dígitos darão match em uma Route Pattern genérica, do tipo \+.!, que enviará para um Gateway usando Local Route Group. A vantagem disso é que podemos ter apenas 1 única Route Pattern no sistema! Olha que beleza... E o gateway por sua vez, invocará uma Called Party Transformation Pattern para localizar os números na saída, ou seja, mudar de +551122225555 para 022225555, por exemplo. Com isso, você cria um dial plan altamente escalável e com suporte ao +E.164, que não faz parte do escopo desse post, mas vai te facilitar MUITO na configuração do AAR e do CFUR. Praticamente você vai ter essas duas features de graça.


Configuração

Agora que temos toda a base teórica, a configuração é muito fácil. Basicamente precisamos de Partitions e Calling Search Spaces. Começaremos fazendo as Calling Party Transformations Patterns (que chamarei a partir de agora de CgPTP), e depois as Called Party Transformation Patterns (a partir de agora, CdPTP).

- Calling Party Transformation Patterns (CgPTP)

Vejamos... precisaremos usar uma no Gateway, e outra no IP Phone, certo? Vamos, portanto, criar duas partitions e duas CSSs:
- CSS-GW-CgPTP {PT-GW-CgPTP}
- CSS-Phone-CgPTP {PT-Phone-CgPTP}

E agora criaremos as Transformations.
A do gateway precisa mudar de 1122225555 para +551122225555. Portanto, podemos fazer o seguinte:


 A do phone precisamos mudar de +551122225555 para 22225555. Portanto, podemos fazer o seguinte:

E aí, basta aplicarmos as CSSs no gateway:


E no phone:


Repare que em ambos eu desmarquei a opção Use Device Pool Calling Party Transformation CSS. Uma outra opção seria aplicar a CSS no Device Pool, e deixar esse campo marcado no Gateway ou no Phone. Mas cuidado, pois a regra pode acabar sendo usada por devices que você não quer. Por isso, eu sugiro marcar no device ao invés de aplicar no Device Pool.

Obs: No gateway, eu configurei a CSS-GW-CgPTP no Number Type Unknown, que é como funciona no Brasil. Na prova, a PSTN manda os dígitos marcados como Subscribe (chamadas locais), National (chamadas DDD) e International (chamadas DDI). Assim você pode (e deve) fazer a globalização sem o uso de CgPTP e CSSs, apenas prefixando os dígitos necessários para cada tipo de chamada. Por exemplo, se a PSTN manda 1122225555 e Type Subscribe, para globalizar basta prefixarmos +55. Se quiser configurar dessa forma no Brasil, é preciso fazer a marcação no gateway através de translation-profiles, por exemplo:

voice translation-rule 10
 rule 1 /^11[2-9].......$/ /&/ type any subscriber
 rule 2 /^[1-9][1-9]/ /&/ type any national
 rule 3 /^00/ /&/ type any international


voice translation-profile ISDNType
 translate calling 10


dial-peer voice 2 voip
 description *** PSTN -> CUCM ***
 translation-profile outgoing ISDNType
 destination-pattern 2...$
 session target ipv4:10.1.1.10
 incoming called-number .
 voice-class codec 1 
 voice-class h323 1
 dtmf-relay h245-alphanumeric
 no vad


- Called Party Transformation Patterns (CdPTP)

Agora vamos fazer a parte das CdPTPs, que são usadas no Gateway, no sentido Outbound. O gateway vai localizar a chamada, mudando de +551122225555 para 022225555. Para isso, também vamos criar uma Partition e uma CSS específica:

- CSS-GW-CdPTP {PT-GW-CdPTP}

Agora a CdPTP:


E aplicamos no gateway, desmarcando a opção Use Device Pool CSS:


E assim finalizo o post sobre Translations e Transformations. Um detalhe que é bom comentar é que o dialed number analyzer do CUCM não funciona com Transformation Patterns, então não use ele para os seus troubleshootings.

2 comentários:

  1. Bom dia, pessoal,
    Tenho uma dúvida: Estou com um cliente que possui um tronco E1 com DDR, porém, ao ligar para um número externo, é binado o número do tronco chave, ou seja, não bina o DDR do cara. Alguém tem um exemplo de como fazer com que no número externo apareça o DDR que originou a ligação?
    Obrigado e parabéns pelo post!
    Abraços

    ResponderExcluir
    Respostas
    1. Esdras, isso não depende apenas de você, e sim da operadora. Primeiramente, você tem que confirmar se a operadora está tarifando por tronco ou por ramal. Para aparecer o DDR, ela tem que tarifar por ramal. E em segundo lugar (aí sim entra a sua parte), você deve manipular o número de origem antes de enviar a chamada para a operadora. Você tem que confirmar com a operadora como eles precisam receber o "Número de A", que é como eles chamam o número de origem. Geralmente eles precisam receber os 4 dígitos do ramal, mas tem operadora (especialmente GVT) que pede 8 ou 10 dígitos (incluindo o prefixo e o código da cidade).

      Se no CUCM os seus ramais são de 4 dígitos, e caso não tenha nenhuma manipulação configurada no servidor ou no GW, então por padrão você já manda os 4 dígitos do ramal. Mas se esse não for o caso, você precisa fazer algumas translations no gateway. Isso está mais bem explicado no post:
      http://ccievoicebrasil.blogspot.com.br/2013/06/voice-translation-rules-e-voice.html

      Abraços!

      Excluir