sexta-feira, 28 de junho de 2013

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

Uma dúvida que muita gente tem é sobre a diferença entre Translations e Transformation Patterns no Call Manager. Quando eu uso uma e quando eu uso outra? Se for para dar uma resposta curta, eu diria que as Transformations Patterns não alteram decisão de roteamento no CUCM. Hmmm, um pouco vago, né? Então acho que a melhor forma de explicar é dando exemplos de utilização.

Nesse post eu abordarei os usos mais comuns das Translations Patterns, e no próximo eu falo mais sobre Transformation Patterns, para o texto não ficar muito grande...

Translation Patterns

As Translation Patterns são as que a gente está mais acostumado a usar no dia a dia. Elas são usadas para modificar o Calling ou Called Number com base no número discado, e isso é feito antes de o CUCM escolher o destino da chamada. Então por exemplo, você pegou o seu IP Phone e discou "2000". Com esse número discado (called number), o Call Manager vai olhar nas suas rotas para escolher o destino. Basicamente, ele pode dar match em um DN, em uma Route Pattern ou em uma Translation Pattern. Note que ele não vai buscar nas Transformation Patterns!

Dando match em uma Translation Pattern, ela pode alterar o número de origem, o número de destino e a Calling Seach Space (influenciando no roteamento). Depois que a chamada passar pela Translation, o Call Manager ainda não vai ter escolhido o destino da chamada, então ele vai pegar o número de destino resultante da transformação, e fazer uma nova busca pelos DNs, Route Patterns e Translation Patterns. Quando os dígitos resultantes finalmente derem match em um DN ou Route Pattern, aí sim o Call Manager vai escolher o destino da chamada, que pode ser um telefone, um gateway, um trunk, etc.

Então vale dizer que o fluxo de uma chamada quando usamos a Translation Pattern fica assim:



É importante perceber que o match na Translation Pattern é sempre pelo Called Number. Não tem como compararmos o número de origem, por exemplo. É sempre, sempre pelo número de destino da chamada. E outra coisa importante a se notar é que a Translation Pattern tem uma Calling Search Space. Essa CSS tem que ter acesso ao destino final, seja ele uma Route Pattern ou um DN.

Tendo isso tudo em mente, vamos começar a falar sobre alguns casos onde uma TP é necessária. :

1. Esconder o número de origem

Um caso clássico que usamos a Translation é para esconder o Caller Name e Caller ID em uma chamada ramal-ramal. Vamos direto a um exemplo:

Ramal A: 2000 (Partition PT-DN, Calling Search Space CSS-Phones)
Ramal B: 2001 (Partition PT-DN, Calling Search Space CSS-Phones)

Eu quero que quando o Ramal A ligar para o Ramal B, este não consiga ver o número e nome do Ramal A, e vice-versa. A chamada deve aparecer como "Desconhecida" em ambos sentidos.

Para fazer isso, precisamos de uma Translation Pattern no meio do caminho, manipulando o Calling ID e Calling Name, escondendo as informações. Então quando o Ramal A ligar para o 2001, a chamada deve dar match em uma Translation Pattern, e não no DN diretamente. Para fazer isso, vamos configurar as Partitions e CSSs da seguinte forma:

CSS-Phones = {PT-DN-Xlate}
CSS-Xlate = {PT-DN}

Agora vamos criar uma Translation Pattern 200X na Partition PT-DN-Xlate e com a Calling Search Space CSS-Xlate. Feito isso, quando um dos ramais ligar para o outro, a CSS deles (CSS-Phones) terá acesso apenas a Translation Pattern. Esta, por sua vez, terá uma calling search space (CSS-Xlate) que terá acesso à partition dos ramais, concluindo a chamada. Repare que nessa translation eu não fiz nenhuma manipulação no número de origem. Ou seja, entrou 2001 nela, e saiu 2001. Só o que mudamos foi o Calling Number. Veja o fluxo da chamada:



Veja como ficou a configuração da nossa Translation Pattern:



2. Alterar o número de origem

Uma outra coisa que podemos fazer, seguindo a mesma lógica, é alterar (ao invés de esconder) o número de origem. Por exemplo:

Eu quero que quando o Ramal A ligar para o Ramal B, este visualize como Número de Origem *112000. Nesse caso, não mexeríamos no campo Calling Line ID Presentation e configuraríamos
Calling Party Transformation Mask: *11XXXX ou
Prefix Digits (Outgoing Calls): *11
ou ainda, preencheríamos no Ramal A o External Phone Number Mask *11XXXX, e na Translation Pattern simplesmente marcaríamos a opção Use Calling Party's External Phone Number Mask.

São várias formas de atingir o mesmo objetivo. O Calling Party Transformation Mask serve, como o nome diz, para criarmos uma máscara, onde o X dá match no número original contando da direita para esquerda. Por exemplo:
Número Original: 2001
Calling Party Transformation Mask: 32XX
Número Resultante: 3201

O Prefix Digits (Outgoing Calls) serve simplesmente para prefixar alguma coisa ao número original. Por exemplo:
Número Original: 2001
Prefix Digits (Outgoing Calls): 55
Número Resultante: 552001

O Use Calling Party's External Phone Number Mask serve para usarmos como Calling Number o que estiver configurado no External Phone Number Mask do ramal.

Esses três parâmetros podem ser usados também em conjunto. Por exemplo:
Ramal: 2001
External Phone Number Mask: 55112323XXXX
Use Calling Party's External Phone Number Mask: Habilitado
Número Resultante: 551123232001
Calling Party Transformation Mask: XXXXXXXX
Número Resultante: 23232001
Prefix Digits (Outgoing Calls): 55
Número Resultante: 5523232001

3. Criar traduções de números (Discagens rápidas, códigos de acesso, etc)

Outro exemplo clássico de utilização das Translations é para criar traduções de dígitos, como códigos de acesso, discagens rápidas. Por exemplo, se o cliente quer que ao pressionar o 9, a chamada seja encaminhada para a recepcionista. Ou digitar *11XXXX para a chamada ser direcionada a um ramal de São Paulo. Vamos pensar nesse segundo exemplo.

Ramal RJ: 2000 (PT-DN-RJ / CSS-Phones-RJ)
Ramal SP: 3000 (PT-DN-SP / CSS-Phones-SP)

As Partitions e CSSs estão configuradas da seguinte forma:

CSS-Phones-RJ = {PT-DN-RJ}
CSS-Phones-SP = {PT-DN-SP}

Ou seja, os ramais do RJ não conseguem ligar para os ramais de SP, e vice-versa. Vamos criar códigos de acesso para eles se falarem, sendo *11XXXX para SP e *21XXXX para RJ. Para isso, vamos criar Translation Patterns em uma partition global PT-Site-Xlate, e incluir essa Partition nas CSSs:

CSS-Phones-RJ = {PT-DN-RJ, PT-Site-Xlate}
CSS-Phones-SP = {PT-DN-SP, PT-Site-Xlate}

As nossas TPs terão a seguinte cara (removi as partes de Calling, que não nos interessa agora):


E o fluxo da chamada ficará assim:



4. Hot Lines

Por fim, podemos utilizar as Translation Patterns para fazer um Hot Line, tipo um PLAR. Ou seja, o ramal tira o fone do gancho e ele já automaticamente faz uma chamada para algum número, sem o usuário precisar digitar nada. Por exemplo:

Ramal A: 2000 (Partition PT-DN, Calling Search Space CSS-HotLine)
Ramal B: 2001 (Partition PT-DN, Calling Search Space CSS-Phones)

Quando o Ramal A tirar o fone do gancho, uma chamada deve ser automaticamente feita para o Ramal B.

Usaremos uma Translation para fazer essa configuração. A ideia é a CSS do Ramal A ter acesso a uma Translation Pattern "vazia", que dá match em tudo. Queremos que apenas o Ramal A tenha acesso a essa Translation, logo, teremos que criar uma Partition e uma CSS especial:

CSS-HotLine = {PT-HotLine}
CSS-Phones = {PT-DN}

A configuração da Translation será assim:


Note que ela tem uma Partition PT-HotLine que apenas o Ramal A tem acesso. E a Translation tem uma Calling Search Space CSS-Phones que tem acesso ao Ramal 2001. E repare também que a Pattern dessa Translation está vazia, ou seja, quando o Ramal A tirar o fone do gancho, ele já dá match nessa regra, que envia a chamada para o ramal 2001. E o nosso HotLine está configurado.


Com isso encerro os casos principais onde usamos Translation Patterns. No próximo post abordarei sobre as Transformation Patterns.

Nenhum comentário:

Postar um comentário