2 June 2019

Translations no Cisco Voice Gateway

Voice translation, translation rules, translation profiles… Não sabe o que é isso, ou está tentando entender como toda essa coisa funciona? Então vamos lá.

Conceito

Voice Translation é a capacidade que um voice gateway tem de transformar uma sequência numérica em outra sequência numérica. Existem diversos cenários onde a utilização de voice translation pode ser necessária, já que ela é capaz de manipular tanto o número de origem (ANI) quanto o número de destino (DNIS) de uma ligação.

O conceito de voice translation compreende a configuração de rules e profiles.

  • Rules são expressões regulares que possibilitam a transformação de uma sequência numérica em outra sequência numérica. As rules são os elementos principais de uma voice translation.
  • Profiles são conjuntos de rules. Um profile pode conter uma ou mais rules.

Uma vez configurado corretamente, com todas as rules necessárias, um profile pode ser associado aos seguintes componentes:

  • Dial peers
  • Voice ports
  • Trunk groups
  • Voice source groups (VSG)
  • Callmanager fallback (SRST)
  • Qualquer chamada inbound (voip-incoming)

Embora seja possível associar profiles a qualquer um dos componentes acima, as voice translations são mais usadas em dial peers e voice ports.

Expressões regulares

As rules de uma voice translation nada mais são do que expressões regulares que possibilitam a manipulação dos dígitos.

Os caracteres mais usados nas expressões regulares das rules estão listados na tabela abaixo.

Caractere Descrição
^ Começa a analisar no início da sequência
$ Estabelece o fim da expressão
/ Delimitador que marca o início e o fim de uma expressão
\ Caractere de escape, usado para number slicing
- Usado para intervalos numéricos, junto com os caracteres [ e ]
[lista] Dá match em um caractere da lista
[^lista] Não dá match em qualquer caractere da lista
. Dá match em qualquer caractere (representa um único caractere)
* O caractere anterior deve ocorrer zero ou mais vezes
+ O caractere anterior deve ocorrer uma ou mais vezes
? O caractere anterior deve ocorrer zero ou uma vez
& Copia o campo de match no campo de substituição

Vamos entender como esses caracteres são usados através exemplos que simulam a vida real. Tenha em mente que, a partir de agora, vamos analisar como as voice translations usam as suas rules para realizar a manipulação de dígitos.

Usaremos três exemplos com base em uma empresa fictícia, que será a nossa cliente, é claro. São eles:

  1. O cliente solicita que os ramais dos usuários da empresa sejam mascarados nas ligações para a PSTN. Quando um usuário ligar para a PSTN, seu ramal deve ser alterado para o tronco-chave: (21) 3684-4000, onde 4000 é o ramal da recepção.
  2. O cliente solicita que, quando uma ligação DDD for realizada, independentemente do código de operadora inserido, a ligação deve sair com o código de operadora 21.
  3. O cliente solicita que, provisoriamente, as ligações da matriz para a filial utilizem a PSTN. Os usuários continuarão digitando 8XXXX, onde 8 é o código da filial (site access code) e XXXX é o ramal de destino. O prefixo da filial é 2330XXXX, com DDD 11.

Exemplo 1

No primeiro exemplo, o cliente solicita que os ramais da empresa sejam mascarados com o tronco-chave nas ligações destinadas à PSTN.

A primeira coisa que devemos fazer é definir uma voice translation-rule:

Router(config)# voice translation-rule 1

Uma voice translation-rule é um conjunto de uma ou mais rules. Em versões de IOS mais antigas, é possível configurar até 15 rules em cada voice translation-rule. Em versões mais recentes, a quantidade máxima é 100.

Nota: Existe uma diferença entre translation-rule e voice translation-rule. As translation-rules são legadas; elas foram substituídas pelas voice translation-rules. O uso de translation-rules não é recomendado.

O número 1 que definimos na voice translation-rule é apenas um identificador. Esse número pode variar na casa dos bilhões, indicando que podemos configurar uma boa quantidade de voice translation-rules.

Quando aplicamos o comando acima, entramos no modo de configuração de voice translation-rule. A partir daí podemos configurar nossa rule:

Router(config)# voice translation-rule 1
Router(cfg-translation-rule)# rule 1 /^.*/ /36844000/

Uma rule possui dois campos: o campo de match e o campo de substituição. Na rule 1 que configuramos acima:

  • /^.*/ é o campo de match
  • /36844000/ é o campo de substituição

Campo de match é a expressão que vai ser comparada com a sequência numérica original. Por exemplo, um campo de match igual a /..../ corresponde a qualquer sequência formada por 4 dígitos (o que poderia ser um ramal formado por quatro números). Essa sequência, que combinou (deu match) na expressão contida no campo de match, vai ser manipulada de acordo com o que está definido no campo de substituição.

Campo de substituição é a expressão que define como a sequência numérica vai ser manipulada. Antes de chegar no campo de substituição, a sequência numérica deve dar match no campo de match.

Vamos começar analisando o campo de match da nossa rule 1, que é o mais complicado:

/^.*/

Os dois caracteres / (barra), usados no início e no fim da sequência, são os delimitadores do campo. Eles servem apenas para indicar onde o campo começa e onde termina.

Os dois primeiros // de uma rule delimitam o campo de match, e os dois últimos // delimitam o campo de substituição. Por mais complexa que uma rule possa ser, ela sempre terá dois conjuntos de // para delimitar os dois campos.

Vamos à expressão propriamente dita:

  • O caractere ^ (circunflexo) determina que a sequência numérica deve ser analisada a partir do primeiro dígito, ou seja, do início.
  • O caractere . (ponto) define um dígito qualquer.
  • O caractere * (asterisco) indica que o caractere anterior (ponto) deve ocorrer zero ou mais vezes.

Reunindo todas essas informações, podemos definir o campo de match da seguinte forma: Dá match em zero ou mais dígitos, a partir do início da sequência”.

Observe o termo zero, que está destacado propositadamente. O campo de match da nossa rule vai combinar qualquer coisa, qualquer coisa mesmo — inclusive nada (null). Se por algum motivo o voice gateway receber um ramal vazio, sem nenhum dígito, ele dará match em nossa rule.

Se quiséssemos que apenas os ramais com dígitos (não vazios) dessem match, deveríamos ter usado a seguinte rule:

Router(config)# voice translation-rule 1
Router(cfg-translation-rule)# rule 1 /^.+/ /36844000/

A única alteração que fizemos foi substituir o caractere * (asterisco) pelo caractere + (soma). O caractere + (soma) indica que o caractere anterior (ponto) deve ocorrer uma ou mais vezes, e não zero ou mais vezes, como acontece com o uso do * (asterisco).

Qualquer sequência que combinar com a expressão do campo de match será manipulada de acordo com a expressão do campo de substituição:

/2136844000/

A expressão do campo de substituição da nossa rule é simplesmente uma sequência de 8 dígitos. Esse número é o tronco-chave do cliente (21 é o código DDD do Estado, 3684 é o prefixo, e 4000 é o ramal da recepção).

Qualquer sequência que passar pelo campo de match será substituída pela sequência 2136844000. Dessa forma, qualquer ligação originada no escritório do cliente com destino à PSTN terá como origem o número 2136844000, ou seja, o destino vai visualizar, no identificador de chamada, que o número 2136844000 está ligando (quando, na realidade, o número original é um ramal qualquer, como por exemplo 4322 ou 4888). Se o destinatário da PSTN retornar a ligação, a chamada não será feita para o ramal do usuário (que a PSTN desconhece por causa da translation), e sim para o ramal da recepção (4000).

Exemplo 2

No segundo exemplo, o cliente solicita que todas as ligações DDD sejam feitas com o código de operadora 21, independentemente de qual código o usuário digite.

Vamos à configuração:

Router(config)# voice translation-rule 2
Router(cfg-translation-rule)# rule 1 /^00..\(.*\)/ /021\1/

Agora a nossa rule está um pouco mais complexa se comparada ao primeiro exemplo. Isso porque estamos usando uma técnica chamada number slicing.

Vamos analisar o campo de match:

/^00..\(.*\)/

A expressão começa com o caractere ^ (circunflexo), indicando que a sequência deve ser analisada a partir do primeiro dígito. Em seguida temos dois zeros, o primeiro representando o código de acesso à PSTN e o segundo representando o prefixo nacional (usado antes do código da operadora para identificar chamadas DDD). Logo depois temos dois pontos, que representam quaisquer dois dígitos.

Resumidamente, o usuário começa digitando 0021, por exemplo, para realizar uma chamada DDD. O detalhe é que o usuário pode digitar também 0012, 0041, 0049 — enfim, qualquer código de operadora disponível. O que o cliente deseja é que, independentemente de qual código de operadora o usuário digite, a ligação DDD seja roteada à PSTN usando sempre o código 21.

O campo de match continua com o caractere de escape  (contrabarra), usado para alterar o significado do caractere imediatamente posterior. É aqui que ocorre o number slicing. Vamos analisar a última parte do campo de match um pouco mais de perto:

\(.*\)

Os caracteres ( ) representam literalmente os parênteses. A expressão ^0(888) dará match em qualquer sequência que começar com 0(888). Se o usuário digitar 0(888), 0(888)12 ou 0(888)1545442, dará match; mas se ele digitar 0888 ou 088850, não dará match.

Os caracteres \( e \) são usados como delimitadores de um grupo de caracteres. Quando usamos o caractere de escape (contrabarra) antes do caractere de parêntese, o significado do caractere de parêntese é alterado de literalmente parêntese para delimitador de grupo de caracteres. Ou seja, a expressão \(.*\) dará match em qualquer coisa, com ou sem parênteses, inclusive nada (null).

Mas para entendermos por que é necessário agrupar um conjunto de caracteres, precisamos analisar o campo de substituição da nossa rule:

/021\1/

O que o usuário digitar e passar no campo de match será substituído por uma sequência de dígitos iniciada com 021. É aqui que forçamos todas as chamadas DDD a serem roteadas com o código de operadora 21. Observe que o código de acesso à PSTN (o primeiro zero de 0021) foi retirado, pois o roteador já sabe que a ligação é destinada à PSTN.

Depois da inclusão do 021, os caracteres \1 determinam que a sequência deve ser completada com os dígitos que combinaram com o primeiro grupo de caracteres no campo de match. Ficou um pouco confuso? Vamos entender melhor:

/^00..\(.*\)/ /021\1/

Digamos que o usuário digite 00991136699000. Essa sequência numérica vai combinar com o campo de match. De acordo com o campo de substituição, o 0099 será substituído por 021, e todo o restante da sequência será repetida. O resultado final será: 0211136699000. Ou seja, o identificador \1 apenas referencia o grupo de caracteres .*.

Para fixar, vamos usar alguns outros exemplos:

rule 2 /^8\(.*\)/ /832\1/
Dá match em qualquer sequência que começa com 8 e inclui 32 entre o 8 e o resto da sequência (ex.: de 8544 para 832544).
rule 3 /^\(77\)0\(.*\)/ /6\1\2/
Dá match em qualquer sequência que começa com 770, retira o terceiro 0 e inclui 6 no início da sequência (ex.: de 770355 para 677355).
rule 4 /\(^9...\)2\(..\)3..$/ /\22\1300/
Dá match em qualquer sequência de 10 dígitos que começa com 9, cujo caractere é igual a 2 e o caractere é igual a 3. Os e dígitos tornam-se os dois primeiros, e os quatro primeiros dígitos tornam-se os , , e dígitos. Os dois últimos dígitos são substituídos por 00. O caractere $ (cifrão) representa o fim da sequência (ex.: de 9677244388 para 4429677300).

Exemplo 3

No terceiro exemplo, o cliente solicita, em caráter provisório, que todas as ligações originadas na matriz com destino à filial sejam encaminhadas via PSTN, e não através de WAN. Os usuários devem continuar digitando 8XXXX, onde 8 é o código da filial (site access code) e XXXX é o ramal de destino. O prefixo da filial é 2330, e o DDD é 11.

Para atender a essa necessidade podemos usar a seguinte voice translation-rule:

Router(config)# voice translation-rule 3
Router(cfg-translation-rule)# rule 1 /^8\(....$\)/ /021112330\1/

Agora que já passamos por dois exemplos que explicavam em detalhes as expressões das rules, podemos compreender facilmente o que a rule acima está fazendo. Qualquer sequência de cinco dígitos que começa com 8 será manipulada de acordo com o campo de substituição, que basicamente substitui o 8 por 021112330. Os quatro últimos dígitos permanecem intactos.

Se o usuário digitar 83355, a sequência será alterada para 0211123303355. Com isso, a ligação poderá ser roteada via PSTN como uma chamada DDD (usando 21 como código de operadora).

Testando e verificando as rules

Okay, até aqui configuramos todas as rules que precisamos. Mas como podemos saber se elas funcionarão corretamente quando aplicadas? Não podemos arriscar a aplicar uma rule para só depois descobrir que ela não está funcionando corretamente devido a algum erro de configuração.

Felizmente, o IOS possui um comando que possibilita testar as rules configuradas. Vamos testar primeiro a rule do Exemplo 1:

voice translation-rule 1
 rule 1 /^.*/ /36844000/

Podemos testar a rule acima da seguinte forma:

Router# test voice translation-rule 1 5330
Matched with rule 1
Original number: 5330   Translated number: 36844000

No comando acima, comparamos a sequência 5330 com todos os campos de match disponíveis na voice translation-rule 1. Como temos apenas uma rule, há apenas um campo de match.

O output do comando mostra que a sequência deu match com a rule 1, e o 5330 original foi transformado em 36844000. Ou seja, nossa rule está funcionando corretamente.

Vamos à rule do Exemplo 2:

voice translation-rule 2
 rule 1 /^00..\(.*\)/ /021\1/

Ao realizar o teste, obtemos:

Router# test voice translation-rule 2 00191122605599
Matched with rule 1
Original number: 00191122605599 Translated number: 0211122605599

A sequência 00191122605599 deu match com a rule 1 da voice translation-rule 2. O código de acesso à PSTN foi retirado e o código da operadora foi alterado para 21. A rule do Exemplo 2 também está funcionando corretamente.

Por fim, no Exemplo 3 temos:

voice translation-rule 3
 rule 1 /^8\(....$\)/ /0112330\1/

O resultado do teste é o seguinte:

Router# test voice translation-rule 3 83355         
Matched with rule 1
Original number: 83355  Translated number: 01123303355

A sequência 83355 deu match com a rule 1 da voice translation-rule 3. O código da filial (site access code) foi retirado e a sequência 0112330 foi incluída antes do ramal. A rule do Exemplo 3 está correta.

Caso queiramos visualizar todas as rules configuradas no voice-gateway, podemos usar o seguinte comando:

Router# show running-config | section voice translation-rule             
voice translation-rule 1
 rule 1 /^.*/ /36844000/
voice translation-rule 2
 rule 1 /^00..\(.*\)/ /021\1/
voice translation-rule 3
 rule 1 /^8\(....$\)/ /0112330\1/

E para uma visão mais intuitiva:

Router# show voice translation-rule

Translation-rule tag: 1

        Rule 1:
        Match pattern: ^.*
        Replace pattern: 36844000
        Match type: none                Replace type: none
        Match plan: none                Replace plan: none

Translation-rule tag: 2

        Rule 1:
        Match pattern: ^00..\(.*\)
        Replace pattern: 021\1
        Match type: none                Replace type: none
        Match plan: none                Replace plan: none

Translation-rule tag: 3

        Rule 1:
        Match pattern: ^8\(....$\)
        Replace pattern: 0112330\1
        Match type: none                Replace type: none
        Match plan: none                Replace plan: none

Aplicando as rules

A implantação de voice translations compreende duas etapas:

  1. Configuração das rules a nível global;
  2. Aplicação das rules através de profiles.

O processo é semelhante à implantação de ACLs: primeiro configuramos, depois aplicamos. Durante a configuração, nenhuma alteração causará qualquer impacto. As rules só começam a ter efeito quando aplicadas via profiles.

Um voice translation-profile é um conjunto de uma ou mais voice translation-rules. As voice translation-rules são inseridas nos profiles para manipular calling number ou called number:

  • Calling number: manipula o número de origem da ligação.
  • Called number: manipula o número de destino da ligação.

Existem outras manipulações que as voice translation-rules podem fazer em um profile, como callback number, redirect called ou redirect target, mas aqui vamos focar apenas em manipulação de calling number e called number.

Podemos configurar no máximo 1000 profiles em um voice gateway.

No Exemplo 1, criamos a seguinte rule:

voice translation-rule 1
 rule 1 /^.*/ /36844000/

Agora vamos criar um profile para essa rule:

Router(config)# voice translation-profile Change_ANI
Router(cfg-translation-profile)# translate calling 1

Criamos um profile chamado Change_ANI. Não é possível inserir espaço no nome do profile, por isso usamos o underscore para separar as palavras. Também não é possível exceder 31 caracteres no nome do profile.

O nome que configuramos indica que o profile altera o número de origem (ANI) de uma ligação.

No modo de configuração de voice translation-profile, inserimos a voice translation-rule 1 para manipular o número de origem (calling) das ligações.

Agora podemos aplicar a nossa rule através do profile Change_ANI. Neste caso, temos duas opções: a primeira é aplicar o profile na(s) voice port(s), e a segunda é aplicar o profile em todos os dial peer POTS necessários. A escolha entre uma ou outra opção vai depender dos requisitos do cliente.

  1. Se o cliente desejar que todas as ligações com destino à PSTN tenham o número de origem modificado, podemos aplicar o profile na(s) voice port(s).
  2. Se o cliente desejar que apenas algumas ligações com destino à PSTN tenham o número de origem modificado, temos que aplicar o profile nos dial peers POTS necessários.

É possível, por exemplo, que o cliente queira alterar o número de origem apenas quando os usuários fizerem ligações para números fixos Locais e DDD; neste caso o profile deve ser aplicado somente nos dial peers POTS correspondentes.

De qualquer modo, vamos analisar a aplicação nos dois componentes, voice port e dial peer:

Router(config)# voice-port 0/0/0:0
Router(config-voiceport)# translation-profile outgoing Change_ANI
Router# show running-config | section dial-peer voice 260
dial-peer voice 2601 pots
 description FIXO LOCAL
 destination-pattern 0[2-6].......$
 port 0/0/0:0
 forward-digits 8
dial-peer voice 2602 pots
 description FIXO DDD
 destination-pattern 00[^0][^0][^0][^0][2-6].......$
 port 0/0/0:0
 forward-digits 13

Router(config)# dial-peer voice 2601 pots
Router(config-dial-peer)# translation-profile outgoing Change_ANI
Router(config-dial-peer)# dial-peer voice 2602 pots
Router(config-dial-peer)# translation-profile outgoing Change_ANI

Os profiles podem ser aplicados no sentido incoming (ligação entrando) ou outgoing (ligação saindo).

O profile Change_ANI foi aplicado na voice port 0/0/0:0 para ser usado sempre que houver uma ligação saindo (outgoing) pela voice port (ou seja, do gateway para a PSTN). Como resultado, o número de origem de todas as ligações saindo pela voice port será alterado para 36844000.

A outra opção é aplicar o profile Change_ANI nos dial peers necessários. Para entender o uso de incoming e outgoing nos dial peers, precisamos analisar os call legs:

Figura 01

Quando um usuário pega o telefone IP para fazer uma ligação com destino à PSTN, a chamada é direcionada ao gateway tendo como alvo um dial peer VOIP (observe que não estamos nos preocupando se existe um CUCM na rede ou se o cliente usa Callmanager Express). Ou seja, a chamada está entrando (INcoming) no gateway através de um dial peer VOIP.

Em seguida, o gateway direciona a ligação para a PSTN tendo como alvo um dial peer POTS. Ou seja, a chamada está saindo (OUTgoing) do gateway através de um dial peer POTS. É por isso que aplicamos o profile Change_ANI em dois dial peers POTS (um com rota Fixo Local e o outro com rota Fixo DDD) no sentido outgoing, de modo que todas as ligações que saírem do gateway através desses dois dial peers POTS tenham o número de origem alterado.

Na aplicação de profiles em dial peers, com um mínimo descuido podemos incorrer em algum erro:

  • Se aplicássemos o profile Change_ANI nos dois dial peers POTS com sentido incoming, o profile nunca seria usado, visto que os dois dial peers POTS em questão são usados no Call Leg OUT.
  • Se aplicássemos o profile Change_ANI no dial peer VOIP com sentido incoming, qualquer ligação entrando no gateway por esse dial peer VOIP teria seu número de origem alterado, e não apenas as ligações para números fixos Local e DDD.
  • Se aplicássemos o profile Change_ANI no dial peer VOIP com sentido outgoing, as ligações originadas na PSTN para a rede do cliente teriam o número de origem (ou seja, o número de quem está ligando da PSTN) alterado para 36844000.

No Exemplo 2, criamos a seguinte rule:

voice translation-rule 2
 rule 1 /^00..\(.*\)/ /021\1/

Agora vamos criar um profile para essa rule:

Router(config)# voice translation-profile Apply_21
Router(cfg-translation-profile)# translate called 2

O profile Apply_21 contém a voice translation-rule 2 destinada a manipular o número de destino (called) das ligações. Vamos visualizar a configuração dos dial peers de DDD:

Router# show running-config | section dial-peer voice 2602
dial-peer voice 2602 pots
 description FIXO DDD
 translation-profile outgoing Change_ANI
 destination-pattern 00[^0][^0][^0][^0][2-6].......$
 port 0/0/0:0
 forward-digits 13
 
Router# show running-config | section dial-peer voice 2604
dial-peer voice 2604 pots
 description CELULAR DDD
 destination-pattern 00[^0][^0][^0][^0]9........$
 port 0/0/0:0
 forward-digits 13

O dial peer 2604 (Celular DDD) não possui nenhum profile configurado no sentido outgoing, então nele podemos aplicar o profile Apply_21 sem problema. Mas o dial peer 2602 (Fixo DDD) já possui o profile Change_ANI no sentido outgoing. Não é possível aplicar mais de um profile com o mesmo sentido no mesmo componente. Se aplicarmos o profile Apply_21 no dial peer 2602, o IOS vai sobrescrever o profile Change_ANI atualmente configurado.

Para resolver esse problema, temos três opções:

[Opção 1] Incluir a voice translation-rule 1 como calling no profile Apply_21 e aplicá-lo aos dois dial peers.

Router(config)# voice translation-profile Apply_21
Router(cfg-translation-profile)# translate calling 1

Router# show running-config | section voice translation-profile Apply_21
voice translation-profile Apply_21
 translate calling 1
 translate called 2

Router(config)# dial-peer voice 2602 pots
Router(config-dial-peer)# translation-profile outgoing Apply_21
Router(config-dial-peer)# dial-peer voice 2604 pots
Router(config-dial-peer)# translation-profile outgoing Apply_21

[Opção 2] Incluir a voice translation-rule 2 como called no profile Change_ANI. Aplicar o profile Apply_21 ao dial peer 2604.

Router(config)# voice translation-profile Change_ANI
Router(cfg-translation-profile)# translate called 2

Router# show running-config | section voice translation-profile Change_ANI
voice translation-profile Change_ANI
 translate calling 1
 translate called 2

Router# show running-config | section voice translation-profile Apply_21
voice translation-profile Apply_21
 translate called 2

Router(config-dial-peer)# dial-peer voice 2604 pots
Router(config-dial-peer)# translation-profile outgoing Apply_21

[Opção 3] Criar um profile, incluir a voice translation-rule 1 como calling, incluir a voice translation-rule 2 como called, e aplicá-lo ao dial peer 2602. Aplicar o profile Apply_21 ao dial peer 2604.

Router(config)# voice translation-profile CHGANI_APY21
Router(cfg-translation-profile)# translate calling 1
Router(cfg-translation-profile)# translate called 2

Router# show running-config | section voice translation-profile CHGANI_APY21
voice translation-profile CHGANI_APY21
 translate calling 1
 translate called 2

Router# show running-config | section voice translation-profile Apply_21
voice translation-profile Apply_21
 translate called 2
 
Router(config)# dial-peer voice 2602 pots
Router(config-dial-peer)# translation-profile outgoing CHGANI_APY21
Router(config-dial-peer)# dial-peer voice 2604 pots
Router(config-dial-peer)# translation-profile outgoing Apply_21

Em um profile podemos inserir uma voice translation-rule para calling e/ou uma voice translation-rule para called. A configuração de duas ou mais calling ou called no mesmo profile não é permitida.

Vamos analisar cada uma das três opções:

  1. A primeira opção pode nos trazer outro problema. Se considerarmos que o cliente solicitou a alteração do número de origem apenas para ligações destinadas a números fixos Local e DDD (motivo pelo qual aplicamos o profile Change_ANI nos dial peers POTS), o uso da primeira opção resultaria na alteração do número de origem também para as ligações destinadas a números celular DDD, já que o profile Apply_21 seria aplicado ao dial peer 2604.
  2. A segunda opção funcionaria de acordo com o que o cliente deseja. O número de origem seria alterado apenas para as ligações destinadas a números fixos Local e DDD, e o código de operadora 21 seria sempre usado nas ligações DDD para fixo e celular. O único problema da segunda opção é que o profile Change_ANI também está aplicado no dial peer 2601 (Fixo Local), onde não faria sentido existir uma rule para tratamento de chamadas DDD. O problema da segunda opção não causaria impacto negativo, pois a voice translation-rule 2 (para chamadas DDD) nunca seria usada pelo dial peer 2601 (para chamadas locais) — mas a configuração não estaria adequada cosmeticamente.
  3. A terceira opção é a solução mais viável. Um novo profile contendo as duas voice translation-rules seria aplicado apenas ao dial peer 2602. O dial peer 2604 ficaria com o profile Apply_21, e o dial peer 2601 (Fixo Local) permaneceria com o profile Change_ANI. Observe que não haveria nenhuma alteração nos dois profiles já existentes.

Com base nas análises acima, ficamos com a Opção 3 como solução.

No Exemplo 3, criamos a seguinte rule:

voice translation-rule 3
 rule 1 /^8\(....$\)/ /0112330\1/

Agora vamos criar um profile para essa rule:

Router(config)# voice translation-profile Matriz_To_Filial
Router(cfg-translation-profile)# translate called 3

Usamos a voice translation-rule 3 no profile Matriz_To_Filial para manipular o número de destino (called) das ligações.

O cliente solicitou que, provisoriamente, as ligações da matriz para a filial utilizem a PSTN ao invés da rede WAN. Os usuários da matriz devem continuar usando 8XXXX para alcançar os usuários da filial.

Vamos analisar o dial peer VOIP que encaminha as ligações entre matriz e filial para o voice gateway da filial.

Router# show running-config | section dial-peer voice 8000
dial-peer voice 8000 voip
 description TO FILIAL
 destination-pattern 8....$
 session target ipv4:10.20.0.254

Todas as ligações originadas na matriz com destino a 8XXXX (filial) são roteadas através do dial peer 8000. Essas ligações são encaminhadas para o IP 10.20.0.254 (voice gateway da filial).

No entanto, não podemos usar o dial peer 8000 para atender à necessidade do cliente. Isso por um motivo bem simples: o dial peer 8000 é VOIP. Analise novamente a imagem dos call legs acima e observe que os dial peers VOIP não são usados nos call legs conectados à PSTN. De fato, nos dial peers VOIP não podemos usar o comando port para especificar uma voice port de saída.

Para atender aos requisitos do cliente, precisamos criar um dial peer POTS que consiga rotear as chamadas destinadas à filial e associar a ele o profile Matriz_To_Filial:

Router(config)# dial-peer voice 8111 pots
 description TO FILIAL
 translation-profile outgoing Matriz_To_Filial
 destination-pattern 8....$
 port 0/0/0:0

Com o dial peer 8111 (POTS) conseguimos especificar uma saída para a PSTN (voice port 0/0/0:0), o que não era possível com o dial peer 8000 (VOIP).

Vamos visualizar a configuração:

Router# show running-config | section dial-peer voice 8
dial-peer voice 8000 voip
 description TO FILIAL
 destination-pattern 8....$
 session target ipv4:10.20.0.254
dial-peer voice 8111 pots
 description TO FILIAL
 translation-profile outgoing Matriz_To_Filial
 destination-pattern 8....$
 port 0/0/0:0

Temos dois dial peers com a mesma destination-pattern apontando para dois lugares diferentes. Ambos os dial peers também possuem a mesma preferência (padrão igual a 0). Neste caso, o dial peer POTS será usado — e é exatamente isso que queremos. Porém, apenas como boa prática, vale a pena incrementar o valor de preferência do dial peer VOIP:

Router(config)# dial-peer voice 8000 voip
 preference 1

Agora, explicitamente o dial peer POTS tem preferência menor (padrão igual a 0) que o dial peer VOIP (igual a 1), e por isso ele sempre será preferido (quanto menor o valor de preferência, melhor).

E assim finalizamos a segunda e última etapa da implantação de voice translations. Todos os requisitos do cliente foram atendidos com sucesso.

Outras aplicações de profiles

Embora seja mais comum utilizar profiles em voice ports e dial peers, também podemos aplicá-los em outros componentes.

Aplicação em trunk group. Todos os componentes membros do trunk group herdarão o profile, a menos que outro profile no mesmo sentido (incoming ou outgoing) esteja aplicado no próprio componente:

Router(config)# trunk group 1
Router(config-trunk-group)# translation-profile incoming TST-in
Router(config-trunk-group)# translation-profile outgoing TST-out

Aplicação em Voice Source Group (VSG). Todas as chamadas tratadas por um VSG serão manipuladas pelo profile. Apenas um profile incoming pode ser aplicado num VSG:

Router(config)# voice source-group BAR
Router(cfg-source-grp)# translation-profile incoming TST-in

Aplicação em Callmanager Fallback (SRST). As chamadas realizadas durante um período de sobrevivência serão manipuladas pelo profile:

Router(config)# call-manager-fallback
Router(config-cm-fallback)# translation-profile incoming TST-in
Router(config-cm-fallback)# translation-profile outgoing TST-out

Aplicação global. Todas as chamadas VoIP entrando no gateway serão manipuladas pelo profile:

Router(config)# voip-incoming translation-profile TST-in

Verificando os profiles

Podemos verificar a configuração dos profiles com o seguinte comando:

Router# show running-config | section voice translation-profile
voice translation-profile Change_ANI
 translate calling 1
voice translation-profile Apply_21
 translate called 2
voice translation-profile CHGANI_APY21
 translate calling 1
 translate called 2

E para uma visão mais intuitiva:

Router# show voice translation-profile

Translation Profile: Change_ANI
        Rule for Calling number: 1
        Rule for Called number: 
        Rule for Redirect number: 
        Rule for Redirect-target number:        Rule for Callback number: 

Translation Profile: Apply_21
        Rule for Calling number:
        Rule for Called number: 2
        Rule for Redirect number: 
        Rule for Redirect-target number:        Rule for Callback number: 

Translation Profile: CHGANI_APY21
        Rule for Calling number: 1
        Rule for Called number: 2
        Rule for Redirect number: 
        Rule for Redirect-target number:        Rule for Callback number: 

Excluindo a configuração

A exclusão da configuração de voice translation é relativamente simples, bastando apenas inserir no antes do comando usado para configuração.

Router(config)# dial-peer voice 2602 pots
Router(config-dial-peer)# no translation-profile outgoing Apply_21

Router(config)# no voice translation-profile Apply_21
Router(config)# no voice translation-rule 2

É importante mencionar aqui a ordem lógica das exclusões. Não faz sentido excluir o profile antes de desassociá-lo do dial peer, por exemplo. Se isso for feito, o comando translation-profile outgoing Apply_21 continuará aplicado no dial peer 2602. Se futuramente alguém criar um profile com o mesmo nome, as rules inseridas nesse novo profile podem impactar negativamente no dial peer 2602. A mesma ideia vale para a exclusão da voice translation-rule antes de desassociá-la do profile.

O exemplo acima ilustra a ordem lógica das exclusões. Em primeiro lugar, o profile é desassociado de todos os componentes. Logo depois o profile é excluído, seguido finalmente das voice translation-rules que não estão mais em uso.

Análise de caso

Para fixar o que aprendemos, vamos analisar o seguinte caso:

voice translation-rule 1
 rule 1 /^21\(.*\)/ /0\1/
 rule 2 /^[^0][^0].*/ /0021&/
 rule 3 /^.*/ /00021&/

voice translation-profile CSM
 translate calling 1

voice-port 0/0/0:0
 translation-profile incoming CSM

O profile CSM está aplicado na voice port 0/0/0:0 para manipular as ligações entrantes (incoming), ou seja, da PSTN para a rede local.

O profile CSM contém a voice-translation rule 1, que está sendo usada para manipular o número de origem das ligações (calling).

Até aqui concluímos que as rules da voice translation-rule 1 estão sendo usadas para manipular o número de origem (calling) de todas as ligações que entram (incoming) pela voice port 0/0/0:0. Em suma, todas as ligações da PSTN com destino à rede local terão o número de origem manipulado pelas rules.

Vamos, agora, analisar uma rule de cada vez.

rule 1 /^21\(.*\)/ /0\1/
Dá match em qualquer sequência que começa com 21. Substitui o 21 por 0 e repete o restante da sequência.
rule 2 /^[^0][^0].*/ /0021&/
Dá match em qualquer sequência cujo primeiro e/ou segundo dígito não seja igual a 0. Inclui os dígitos 0021 no início da sequência. O caractere & (ampersand) simplesmente copia toda a sequência.
rule 3 /^.*/ /00021&/
Dá match em qualquer sequência, inclusive uma sequência vazia (null). Inclui os dígitos 00021 no início da sequência.

Essas três rules são usadas para facilitar a vida do usuário final. Se o usuário precisar retornar alguma ligação vinda da PSTN, basta clicar em redial e pronto, a ligação será feita. Sem as rules acima, o usuário teria que editar o número antes de retornar a ligação.

Por exemplo, digamos que um usuário não tenha atendido uma ligação com número de origem 2122005800 e agora deseja retornar a chamada. Dois cenários são possíveis:

  1. Se as rules acima estiverem configuradas, o usuário visualizará na tela do seu telefone o número 022005800. Neste caso, basta clicar em redial para retornar a chamada.
  2. Se as rules acima não estiverem configuradas, o usuário visualizará na tela do seu telefone o número 2122005800. Neste caso, para retornar a chamada, ele terá que editar manualmente o número para 022005800.

Tudo isso leva em consideração a configuração de dial peers, é claro. Estamos suponto que os dial peers estão configurados da maneira mais simples e correta possível. Por exemplo, para ligações Fixo Local, há um único dial peer com destination-pattern igual a 0[2-6].......$. Ou seja, para fazer uma ligação Fixo Local, o usuário tem que digitar uma sequência de nove dígitos que comece com 0 e cujo dígito varie entre 2 e 6, inclusive.

O ponto importante dessa análise de caso é o entendimento da ordem das rules dentro de uma voice translation-rule. Vamos analisá-la mais de perto:

voice translation-rule 1
 rule 1 /^21\(.*\)/ /0\1/
 rule 2 /^[^0][^0].*/ /0021&/
 rule 3 /^.*/ /00021&/

A sequência 2122005800 combina com o campo de match das três rules, ou seja, qualquer uma delas pode ser usada para manipular essa sequência. O que vai determinar qual rule será usada?

Poderíamos pensar que a rule com campo de match mais específico seria a escolhida — ou seja, a rule 1. Vamos criar uma voice translation-rule de teste para verificar se o nosso pensamento está correto:

Router(config)# voice translation-rule 999
Router(cfg-translation-rule)# rule 1 /^.*/ /3333/
Router(cfg-translation-rule)# rule 2 /^21\(.*\)/ /4444/

A voice translation-rule 999 tem que transformar a sequência 2122005800 em 4444 para que o nosso pensamento seja confirmado. Vamos ver se isso acontece:

Router# test voice translation-rule 999 2122005800
Matched with rule 1
Original number: 2122005800  Translated number: 3333

A sequência 2122005800 foi transformada em 3333, o que significa que o nosso pensamento estava errado.

O que vai definir qual rule será usada não é o campo de match mais específico, e sim a tag da rule. Na voice translation-rule 999, a primeira rule tem tag igual a 1, e a segunda rule tem tag igual a 2. Como a primeira rule tem a menor tag, ela será usada.

O IOS sempre vai ordenar as rules de uma voice translation-rule na ordem crescente das tags. Considere a seguinte configuração:

Router(config)# voice translation-rule 888
Router(cfg-translation-rule)# rule 3 /^.*/ /00021&/
Router(cfg-translation-rule)# rule 1 /^21\(.*\)/ /0\1/
Router(cfg-translation-rule)# rule 2 /^[^0][^0].*/ /0021&/

Apesar da ordem em que as rules foram configuradas, o IOS vai ordená-las de acordo com as suas tags:

Router# show running-config | section voice translation-rule 888
voice translation-rule 888
 rule 1 /^21\(.*\)/ /0\1/
 rule 2 /^[^0][^0].*/ /0021&/
 rule 3 /^.*/ /00021&/

Com isso em mente, tenha muito cuidado com a ordem das rules em uma voice translation-rule. Um pequeno descuido pode render a você muita dor de cabeça.

Um pouco mais sobre ^ e $

Precisamos falar um pouco mais sobre os caracteres ^ (circunflexo) e $ (cifrão). Para relembrar:

  • O caractere ^ determina que a sequência deve ser analisada a partir do primeiro dígito.
  • O caractere $ estabelece o fim da expressão.

Considere a seguinte configuração:

voice translation-rule 888
 rule 1 /2880/ /4000/

A nossa intenção é transformar a sequência 2880 em 4000. Vamos ver se isso funciona:

Router# test voice translation-rule 888 2880
Matched with rule 1
Original number: 2880   Translated number: 4000

Ótimo, alcançamos nosso objetivo. Mas, vamos fazer alguns outros testes:

Router# test voice translation-rule 888 502880
Matched with rule 1
Original number: 502880 Translated number: 504000
Router# test voice translation-rule 888 288020
Matched with rule 1
Original number: 288020       Translated number: 400020
Router# test voice translation-rule 888 11111112880111    
Matched with rule 1
Original number: 11111112880111     Translated number: 11111114000111

Contanto que em algum momento apareça 2880, a sequência dará match e será manipulada, independentemente do que eu digite. É para evitar isso que usamos os caracteres ^ e $. Vamos alterar nossa rule:

Router(config)# voice translation-rule 888
Router(cfg-translation-rule)# rule 1 /^2880$/ /4000/

Vamos testá-la agora com as mesmas sequências de antes:

Router# test voice translation-rule 888 2880
Matched with rule 1
Original number: 2880   Translated number: 4000
Router# test voice translation-rule 888 502880
502880 Didn't match with any of rules
Router# test voice translation-rule 888 288020
288020 Didn't match with any of rules
Router# test voice translation-rule 888 11111112880111
11111112880111 Didn't match with any of rules

Apenas o primeiro teste deu match, e era exatamente isso que queríamos.

Com o uso do caractere ^ (circunflexo), a rule só vai manipular sequências que comecem com 2880. O caractere $ (cifrão), por sua vez, estabelece que depois do 0 não deve haver nenhum outro dígito, pois ali é o fim da expressão. Os dois caracteres usados em conjunto possibilitam que a rule dê match apenas na sequência 2880.

Vamos a um segundo caso:

voice translation-rule 999
 rule 1 /^8\(....$\)/ /0112330\1/

A voice translation-rule 999 dará match somente em sequências de cinco dígitos que começam com 8.

  • Se o campo de match fosse igual a /8\(....$\)/, sequências como 85555, 2085555 ou 11185555 dariam match.
  • Se o campo de match fosse igual a /^8\(....\)/, sequências como 85555, 8555510 ou 85555999 dariam match.
  • Se o campo de match fosse igual a /8\(....\)/, sequências como 85555, 2085555, 8555510 ou 11185555111 dariam match.

Com isso podemos estabelecer algumas boas práticas:

  • Se você quer analisar toda a sequência no comprimento estabelecido, use os caracteres ^ e $.
  • Se você quer analisar a sequência a partir do primeiro dígito mas não tem como definir o comprimento da sequência, use apenas o caractere ^.
  • Se uma expressão terminar com . (ponto), use o caractere $.
  • Se uma expressão terminar com [ ] (colchetes), use o caractere $.
  • Se uma expressão terminar com um dígito explícito (como 1, 3 ou 0), use o caractere $.
  • Não faz sentido usar o caractere $ se uma expressão terminar em * (asterisco), + (soma) ou ? (interrogação).

Conclusão

Chegamos ao fim do nosso artigo sobre translations no voice gateway. Muito obrigado pela paciência de ter chegado até aqui. Compreendo que o assunto pode ser um pouco complicado para quem não está acostumado, mas garanto que tentei demonstrar tudo da maneira mais simples possível.

Em outros artigos falaremos sobre duas técnicas mais específicas envolvendo translations no voice gateway:

  • Blacklist
  • Type & Plan

Se você tiver qualquer crítica ou sugestão, me envie uma mensagem via carlos@wolkartt.com.

Fique à vontade para compartilhar este artigo. Peço apenas que você referencie o autor e este blog como fonte.

voice gateway cisco collab


Próximo Post
O que são Call Legs Toda chamada que passa por um voice gateway entra por um call leg e sai por outro call leg. Você pode traduzir “leg” como “perna”, mas o termo