Estrategias - As tabelas

Hoje farei um post exclusivamente sobre estrategia, direcionado mais àqueles que já estão quase no finalmente. Não adianta nada você manjar tudo do blueprint tecnicamente se não tem uma estrategia para atacar a prova. E volto a dizer que estrategia é uma questão MUITO pessoal, que cada um deve desenvolver a sua. O importante é ter uma. Por favor, não considere o que vou escrever aqui como uma receita de bolo a ser seguida! Pode pegar como base, mas crie a sua própria receita...

Bom, mas que raios é ter uma estrategia?

Ter uma estrategia é desenvolver um método seu para fazer a prova. Qualquer prova. Não importa como vai ser o exame, e nem o que vai cair. Você tem que seguir uma ordem para fazê-lo, tipo um script. E essa ordem definitivamente não será questão por questão, 1 por 1. Desse jeito não vai dar tempo de fazer tudo.

Um método bastante difundido na Internet é o Device-Based Approach, que realmente acredito que seja o mais rápido. Mas eu particularmente não consegui fazer desse jeito... até tentei algumas vezes nos labs da IP Expert, mas num tem como. Para dar um nó na cabeça é facinho facinho. De qualquer forma, vale a pena ver como é essa estrategia, porque de repente você pode se sentir a vontade com ela.

Bom, a estrategia que usei foi quase um Device-Based approach, uma variação que eu desenvolvi. Seguindo o conselho do Vik Malhi, tentei bolar algumas tabelas para transpor o máximo de informações para um papel, e usar o caderno de questão o menos possível. A ideia é evitar ficar indo e voltando no caderno de questões atrás de informações. Fato é que independente da sua prova, algumas coisas você SEMPRE vai ter que configurar, como Media Resources, H.323/MGCP/SIP, DHCP, NTP, SRST, CUE, etc. O que vai mudar é como a prova vai te pedir para configurar. Os gateways podem ser H.323/MGCP/SIP, o DHCP pode ser na IOS ou no CUCM, o NTP pode apontar para um site, ou para o router da PSTN, enfim... mas qualquer prova sempre vai te dar essas informações para você configurar. Então, ao invés de ficar lendo o enunciado várias vezes, jogue tudo em tabelas de fácil visualização. Tente mapear o máximo que conseguir da prova...

O que eu fazia era, antes de iniciar o exame, pegar o caderno de questões e perder exatos 30 minutos lendo e transpondo os dados. Eu conseguia transpor praticamente tudo nessa primeira leitura, exceto Call Routing, SRST, QoS, UCCX e Presence (e algumas coisinhas mais de features de CUCM e tal). As configurações dos gateways, telefones, Service Parameters, algumas coisas de messaging, eu mapeava tudo. As minhas tabelas ficavam mais ou menos assim:

1) A primeira tabela eu colocava as infos gerais da prova. Era o suficiente para configurar tipo 80% dos roteadores. Praticamente só ficava faltando call routing. Com essas infos eu já conseguia configurar as E1s e T1s, o H.323/ MGCP / SIP, os Media Resources, o NTP, DHCP, e até o setup inicial da CUE. Quando eu começava a de fato fazer a prova, abria um notepad (três, na verdade) e com base nessa tabela já configurava os 3 gateways. Em questão de 15 minutinhos no máximo, os 3 gateways já estavam prontos, e a CUE já estava dando o primeiro boot.

2) A segunda tabela eu colocava as informações dos telefones e ramais. Aí quando eu criava os phones, já tentava deixar o máximo de configuração possível pronta. A ideia era entrar na página de config do telefone 1 vez só. Claro, antes de configurar o telefone, configurava device pools, phone button templates, softkey templates, PTs/CSSs (quando necessário), etc.

3) E a terceira tabela eu colocava basicamente os Service Parameters e Enterprise Parameters, porque sabemos como essas telas demoram para carregar (principalmente Service Parameters). Então já alterava tudo que precisava de uma vez só. Eu também costumava colocar algumas infos de QoS (WAN), mas isso confesso que pensando bem agora, não me ajudava muito... e eu colocava algumas outras coisas também, que seriam mais peculiares de cada prova. Às vezes enquanto você lê o exame, percebe que já é bom deixar algumas coisas no radar, como por exemplo a criação de um Device Pool para o MoH quando tiver Multicast MoH, e tal... aí quando você tiver criando os DPs, já cria esse também.

E por fim, conforme ía lendo a prova, eu listava todas as questões com uma breve (BREVE) descrição e os pontos associados a ela, tipo:

1.1 VLAN (2)
1.2 DHCP (3)
1.3 NTP (3)
(...)

Isso era bem útil porque eu não fazia as questões na ordem (aqui entra um pouco do Device Based Approach). De repente configurando os gateways, eu já matava as questões 3.1, 4.5 e 5.2 por exemplo... aí eu ía lá e marcava um check. Só para saber o que já fiz e o que eu não fiz... e no final me ajudava também para somar os pontos que eu achava que tinha ganho.

Essas 3 tabelas e a lista me ocupavam 1 frente de uma folha de rascunho que te dão na prova (para as 3 tabelas), e metade de uma frente da outra folha. O restante eu usava basicamente para Call Routing, que aí é uma outra história que deixo para um post futuro. A dica que dou é fazer Call Routing separado, vai tomar uma água antes e tal, porque o negócio exige 300% do seu poder de concentração. Então na sua primeira leitura do exame, leia call routing assim beeem por cima, porque certamente você vai ter que voltar lá depois e ler tudo de novo. O mesmo com High Availability, embora algumas coisas você já consiga adiantar na primeira leitura...

E outra coisa que fazia era abrir um notepad e listar as VLANs e IPs. Isso eu fazia no próprio lab da IP Expert para não me acostumar tanto com os IPs da ProctorLabs, que são diferentes dos da prova real. Então eu montava um notepad assim:

Aí sempre que precisava de digitar algum IP, eu fazia Ctrl C desse notepad. Mais para não cair no vicio do IP do lab, e na prova real acabar pondo o IP errado por distração. Ou você simplesmente decora os IPs da prova real, que é facilmente encontrável na Internet! hehehe

[Luto] Evandro Nunes, CCIE Voice #39680

O post de hoje não é sobre o CCIE, nem sobre tecnologia, nem nada disso... É sobre algo muito mais importante do que isso tudo. É um post sobre a vida.

Recebi hoje uma notícia muito triste. Era sobre o falecimento do recém CCIE Voice Evandro Nunes.

O Evandro foi aprovado na prova não tem nem um mês. O seu relato foi recentemente publicado no blog da IP Expert. Ele ainda devia estar vivendo um sonho, o alívio de ter passado nesse exame e conquistado a certificação. Imagino o quanto ele batalhou para concluir esse que talvez fosse o seu último desafio.

Infelizmente não o conheci, mas recebi a notícia com um baque como se fosse meu brother de anos. Talvez o fato de estarmos todos nesse mesmo barco nos aproximam de uma forma quase familiar... Conheço pessoas que o conheceram, que inclusive falaram com ele ontem, e só me dizem coisas boas sobre esse cara. Batalhador, solidário, alegre, estava ajudando muita gente a conquistar o sonho do CCIE! Realmente uma pena termos perdido esse talento.

Deixo aqui as minhas sinceras homenagens a esse cara que realmente correu atrás dos seus objetivos, e que deve servir de inspiração para a galera que está atrás do CCIE.

Descanse em paz, Evandro.

UCCX - Integração com o CUCM

Reparei que nunca fiz nenhum post sobre UCCX no Blog. Falha minha, pois é um tópico que tem muito a ser explorado! Posso cometer um engano ao dizer isso, mas na prova geralmente a integração já vem pronta. Isso não quer dizer que você não precisa saber fazer!!! Pelo contrário, como sabemos, você deve desconfiar de tudo que já vem pronto para você. Então, nesse primeiro post sobre UCCX abordarei sobre a integração com o CUCM, para então poder entrar em outros pontos como configurações de fila e scripts em posts futuros.

Quando terminamos de instalar o CCX pela primeira vez (lembrando que estamos falando aqui da versão 7.0, embora na 8.x não mude tanta coisa, apesar de virar um sistema baseado em Linux), a primeira coisa a fazer é ingressar na sua página de configuração WEB (http://x.x.x.x/appadmin). O usuário inicial é Administrator, e senha ciscocisco. Feito isso, seguiremos os passos abaixo:

1. Escolha o seu tipo de deployment. No caso da prova, utilizaremos o Single Node. Em casos de deployment com High Availability, utilizaríamos First Node e Add to Cluster.

2. Coloque as informações do seu CUCM:

3. Importe a licença:

4. Depois de validar as licenças e ativar os serviços, você deverá colocar as informações de integração entre o CUCM e o CCX. Essa integração utiliza 3 usuários:

Usuário AXL: Pode ser o mesmo que você usa para se logar no CUCM, ou crie um novo Application User no CUCM com permissão de AXL.

Usuário JTAPI: Usuário para se comunicar via CTI com o CUCM. Não é necessário criar manualmente o usuário no CUCM. Crie aqui no CCX, que automaticamente vai aparecer lá nos seus Application Users do Call Manager.

Usuário RmCm: Usuário para fazer o controle dos telefones. Não é necessário criar manualmente o usuário no CUCM. Crie aqui no CCX, que automaticamente vai aparecer lá nos seus Application Users do Call Manager. Lembre-se que quando for configurar um telefone para um agente, esse telefone deve estar associado ao usuário RmCm no CUCM, e essa associação deve ser feita manualmente.

Nessa tela também você deverá configurar o NTP Server, que pode ser o próprio CUCM.

Note que após esse passo, os novos usuários estarão listados no CUCM. Não precisa fazer nenhuma config nesses caras por enquanto, exceto a associação dos telefones no RmCm, como disse anteriormente!

5. Seguindo com o CCX, escolha a quantidade de sessões simultâneas de Historical Reports, Gravações e Outbound Dialer o sistema vai suportar (geralmente nada disso cai na prova), e o Codec (que geralmente é G711). Note que o CCX só suporta 1 Codec! Ou seja, se alguém tentar ligar para o CCX usando G729, vamos precisar de um Transcoder aqui.

6. Escolha a linguagem default do sistema:

7. E por fim o End User do CUCM que será usado para acessar a tela de administração do CCX. Tem que ser End User, infelizmente, e não Application User. Ou seja, se você tiver um CUCM integrado com o AD, esse usuário tem que estar no AD. E se por algum motivo ele for apagado, você perde acesso ao CCX.

8. Pronto, a integração foi feita e você pode fechar o Browser. A partir desse momento, utilize o usuário criado no passo 7 para acessar o sistema.

Ok, como eu disse, provavelmente na prova você não vai precisar fazer nada disso. Já vem tudo pronto! Mas é bom sempre ficar atento aos pontos críticos dessa integração, como os Applications Users e suas senhas (se algo não estiver funcionando, pode ser algum problema nesses usuários, por exemplo), o codec e tal.

Agora vamos criar as CTI Ports e CTI Route Points, que servirão para o CUCM conseguir se comunicar com o CCX. Isso também geralmente vem pronto, mas pode ser que você tenha que fazer algum troubleshooting nessa integração, ou mesmo apagar tudo e criar de novo... Portanto, é importante estar bem familiarizado com isso.

Primeiramente, vamos lembrar que qualquer uma dessas configurações devem ser feitas SEMPRE no CCX. Se tiver que mudar, apagar ou criar algo, é sempre pelo CCX. Este por sua vez fará a atualização das coisas no CUCM... Nunca mude as entidades diretamente no CUCM, ou você pode começar a ter problemas de sincronia.

Vamos lá... a primeira coisa que precisamos criar é um Call Control Group no CCX. Ao criá-lo, novas CTI Ports serão criadas automaticamente no Call Manager. Para isso, entre no CCX com o login definido no passo 7, e navegue até Subsystems >> Cisco Unified CM Telephony >> Call Control Group, e crie um novo. Dentre outras informações, aqui precisamos definir um ID para o grupo no CCX, a quantidade de portas (repare que lá em cima ele fala quantas licenças você tem), o ramal da primeira porta (as demais seguirão sequencialmente a partir desse número), e um prefixo, que vai servir para formar o nome do device no CUCM. Podemos definir outras coisas também como Device Pool (importante para configurar o Codec que será usado nas chamadas para o CCX), MRGL (importante no caso de precisarmos de Transcoder nas chamadas), Partition e Calling Search Space. Essas informações ele vai puxar tudo do CUCM através daquele usuário AXL que configuramos lá em cima.

Veja no CUCM as nossas 12 portas criadas. Se precisarmos alterar algo, como Device Pool, MRGL, faça tudo através do CCX:

Agora precisamos de criar um Trigger no CCX, que vai ser um CTI Route Point no CUCM. Esse Trigger será o ramal para onde os usuário vão ligar para chegar em uma Aplicação do CCX. Então antes de criar o Trigger, criaremos um Application, em Applications >> Application Management >> Add New. Como o foco do post não é a criação de Scripts, vamos utilizar um Script default que já vem no sistema:

Criamos uma aplicação chamada App01 que chama o Script icd.aef. Agora precisamos criar o Trigger, informando qual será o Ramal que estará associado a essa aplicação. Para isso, clicaremos em Add new trigger.

Aqui configuraremos, dentre outras coisas, o número do ramal, a língua, um nome (que será o nome do CTI Route Point), um Call Control Group (que usaremos aquele que criamos acima), Device Pool, Partition, Calling Search Space, etc.

Veja que ao criar esse Trigger, um novo CTI Route Point é criado no CUCM:

E veja também que esse CTI Route Point e os CTI Ports estão associados ao Application User jtapi_1. Tudo foi feito automaticamente:

Com isso, se um usuário ligar no 2000, o CUCM vai invocar uma das CTI Ports para chegar no CCX. Chegando no CCX, a aplicação App01 será invocada, utilizando o script icd.aef.

Essa é a integração básica entre CCX e CUCM. Se algo não estiver funcionando, a primeira coisa que podemos fazer é checar a sincronia e forçar a correção, indo em Subsystems >> Cisco Unified CM Telephony >> Data Resync.

Veja o que acontece por exemplo se eu remover os CTI Ports e CTI Route Points do usuário jtapi_1.

Ao rodar o Data Check, o CCX percebe que a associação não está feita. E ao rodar o Sync, a associação é feita novamente, corrigindo o problema:

Esse foi o meu primeiro post de CCX, bem básico. A partir de agora eu começarei a postar mais coisas, principalmente relacionadas a Scripts.

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.

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.

Voice translation-rules e Voice translation-profiles

Inicio o post pedindo desculpas pelo longo período sem atualizações. Uma combinação de trabalho, férias e preguiça fizeram com que eu deixasse o Blog de lado por alguns meses. Durante esse tempo, algumas coisas importantes aconteceram... a Cisco anunciou o CCIE Collaborations e a descontinuidade do CCIE Voice. Houve uma manifestação na Internet, e a Cisco mudou o track, permitindo que os atuais CCIEs Voice virassem CCIE Collab com apenas uma prova escrita. Menos mal!
E outra coisa bacana foi a parceria formada com o blog AVVID.net, liderado pelo Leonardo Nunes, mas que conta também com a colaboração de outros profissionais da área, como o Guilherme Villarinho, Elvis Araújo, Leonardo Santana, Ligia Vidal, Rafael Souza, Leonardo Silva e Paulo Souza. Um excelente blog para quem busca conhecimentos diversos na área de UC, e o mais importante, em Portugues! É ótimo ver o pessoal compartilhando conhecimento na nossa língua. Valeu pessoal!!!

Bom, voltando agora ao assunto do post, estava pensando em algo para escrever, que fosse um conhecimento extremamente necessário a qualquer candidato ao CCIE Voice. E o assunto que me veio na cabeça foi o das voice translation-rules e voice translation-profiles no gateway. Sim, é um tema relativamente simples, mas é fundamental que você domine isso por um simples motivo: procure fazer todas (TODAS!) as manipulações de dígitos possíveis no router quando o gateway for H.323. O motivo disso é que provavelmente você vai querer que todas as chamadas continuem funcionando em SRST, certo? Isso vai te poupar muito trabalho. Se o gateway for MGCP, aí whatever...
E essa ideia também é aplicável na vida real pelo mesmo motivo. Imagine que você fez uma Route Pattern no Call Manager para chamadas DDD, e essa Route Pattern inclui o código de operadora antes de mandar para o Gateway. Quando o site entrar em SRST, essa manipulação de dígito não vai existir, e as suas chamadas vão falhar.

Para começarmos a criar as nossas regras, é preciso lembrar que toda chamada tem uma call-leg de entrada e uma call-leg de saída no Voice Gateway, que são configuradas através das Dial-Peers. Podemos aplicar as manipulações de dígito em qualquer um dos sentidos, ou seja, nas dial-peers de entrada ou nas dial-peers de saída. E dentre as manipulações possíveis, podemos mudar o número de origem e o número de destino (ok, podemos mudar também o redirect, mas para esse post, focado mais em Call Routing, vamos desconsiderar isso). Com isso, temos as seguintes manipulações possíveis:
- Mudar a origem (ANI) em uma dial-peer de entrada
- Mudar o destino (DNIS) em uma dial-peer de entrada
- Mudar a origem (ANI) em uma dial-peer de saída
- Mudar o destino (DNIS) em uma dial-peer de saída

Vale lembrar que para ver se uma chamada é entrante ou sainte no gateway, coloque-se no lugar do roteador:

Por isso, é extremamente importante que você tenha claro nas suas configurações quem é a dial-peer de entrada e quem é da dial-peer de saída de cada chamada. Para exemplificar, vou criar as seguintes dial-peers:

dial-peer voice 1 voip
 description *** Dial-Peer de Entrada VOIP de chamadas vindas do CUCM ***
 incoming called-number .
 codec g711ulaw

dial-peer voice 2 voip
 description *** Dial-Peer de Saída VOIP para o CUCM ***
 destination-pattern 2...
 session-target ipv4:10.1.1.10
 codec g711ulaw
 no vad

dial-peer voice 3 pots
 description *** Dial-Peer de Entrada POTS de chamadas vindas da PSTN ***
 incoming called-number .
 direct-inward-dial

dial-peer voice 4 pots
 description *** Dial-Peer de Saída POTS para a PSTN (Emergencia) ***
 destination-pattern 0[1][9].
 port 0/0/0:15

dial-peer voice 5 pots
 description *** Dial-Peer de Saída POTS para a PSTN (Local) ***
 destination-pattern 0[2-9].......
 port 0/0/0:15

Eu poderia ter juntado a dial-peer 1 e 2 em uma só, de repente. Mas para fins de demonstração, deixarei separado para explicitar melhor o raciocínio. E as dial-peers de saída POTS costumam ser mais do que essas (chamadas de emergência, local, DDD, DDI, 0X00, etc), mas no exemplo deixaremos apenas essas duas: emergência e local.

Ok, agora vamos começar a pensar nas manipulações de dígito! Eeee! \o/

1. Call-Leg de Entrada VOIP
Começaremos pelo lado VOIP, ou seja, nas call legs que fazem a comunicação com o CUCM. Na entrada é quando um IP Phone faz uma chamada para a PSTN, certo? O CUCM manda os dígitos para o gateway, e por isso é Entrante no gateway. O que poderíamos mudar aqui?
Vamos pensar em um caso. O ramal 2000 fez uma chamada para 0190 (polícia).
ANI: 2000
DNIS: 0190

Faz sentido mudarmos o ANI aqui? Bom, até poderíamos de repente transformar o número do ramal 2000 para um formato globalizado, como 551123232000... Porém, é melhor fazermos isso antes de mandar para a PSTN, nas dial-peers de saída POTS, pois isso nos permitiria maior controle... Se aplicarmos uma translation aqui na entrada VOIP, ela vai valer para todas as chamadas que entrarem no gateway pelo CUCM. E se por acaso tivermos que modificar o ANI para 23232000 em chamadas locais e 1123232000 em chamadas de emergência? Por isso é melhor deixarmos para fazer na saída. Além disso, se fizermos aqui no lado VOIP, a regra não vai funcionar em SRST, porque a chamada não vai estar vindo do CUCM. Então não vamos mexer nada aqui.

Faz sentido mudarmos o DNIS? Também não, né? Para quê vou querer mudar o 0190 aqui? Posso deixar para fazer isso também na dial-peer de saída POTS, se tiver necessidade, onde eu tenho maior controle. Senão, de novo, as alterações surtiriam efeito para qualquer chamada que entrasse no Gateway vindas do CUCM, independente de ser de emergência, local, ou qualquer outra.

Ou seja, nada para se manipular aqui. :(

2. Call-Leg de Saída VOIP
A saída VOIP é quando a PSTN faz uma chamada entrante para um IP Phone. A PSTN manda os dígitos para o gateway, e o gateway envia para o CUCM, por isso é Sainte no lado VOIP.
Por exemplo, o número da PSTN (11) 2255-4000 faz uma chamada para o nosso ramal 2000, e a operadora manda:
ANI: 1122554000
DNIS: 2000

Faz sentido mudarmos alguma coisa aqui?

Primeiro o ANI. Vamos supor que eu não quero que o número de origem apareça como 1122554000. Eu quero que fique 022554000, para que o usuário possa dar um "Dial" direto da lista de chamadas perdidas e recebidas. Ok, tem maneiras mais elegantes de se fazer isso, mas é um caso onde poderíamos querer mudar o ANI. Na verdade, o mais lógico seria até configurar essa tradução na entrada POTS, porque aqui sim queremos que tenha efeito para qualquer chamada entrante vinda da PSTN. Mas tudo bem, é só um exemplo.

Agora o DNIS. Primeiro que a minha dial-peer está com o destination-pattern 2..., então se a operadora mandar algo diferente disso, a chamada vai dar match. Mas imagine que no Call Manager, o ramal está configurado no formato 23232XXX. Então uma das formas de isso funcionar, é fazer com que o Gateway mande nesse formato para o CUCM, e aí precisaríamos de uma translation, mudando de 2XXX para 23232XXX. Mas pense bem... se eu fizer isso, o SRST não vai funcionar para receber chamadas da PSTN, porque o telefone vai se registrar no Gateway com o ramal 23232XXX. E como colocamos a translation na saída VOIP, ela não será ativada, já que o gateway não vai mandar a chamada para o CUCM estando em SRST, certo? Por isso, esse tipo de translation também seria mais interessante de se fazer na entrada POTS, que teria efeito independente de o site estar ou não em SRST. Mas qual o problema de fazer isso? É que mudando na entrada POTS, o DNIS passa a ser 23232XXX, e não daría match na nossa dial-peer de saída VOIP. Olha que confusão... então para isso, teríamos que mudar o destination-pattern da dial-peer de saída VOIP para 23232... Acompanhou o raciocínio? Sugiro pegar um papel e caneta e tentar desenhar. Para não complicar muito, consideremos que o ramal é 2XXX mesmo.

Então não faremos a manipulação do DNIS. Aqui vamos mudar apenas o ANI de 1122554000 para 022554000. Peraí que já vamos configurar tudo isso!

3. Call-Leg de Entrada POTS
A entrada POTS é quando a PSTN faz uma chamada entrante para um IP Phone, mas dessa vez estamos vendo a call-leg do lado da PSTN.
Vamos usar o mesmo exemplo de cima:
ANI: 1122554000
DNIS: 23232000

Podemos mudar o ANI? Opa, poderíamos sim... mas a gente já decidiu que vai fazer isso na call-leg de saída VOIP, né? Então deixa assim... Eu particularmente faria essa translation aqui, mas vamos seguir com o exemplo.

E o DNIS? Aqui sim... Veja que a PSTN está mandando 23232000, sendo que a nossa dial-peer para o CUCM é 2..., e os nossos ramais no CUCM estão configurados como 2XXX. Logo quando a chamada entrar no roteador, eu quero que ele mude de 23232000 para 2000. Assim, é o DNIS 2000 que vai dar match com a call-leg de saída VOIP, que tem o destination-pattern 2... Faz sentido? Pelo fluxo da chamada, primeiro ela vai dar match nessa dial-peer 3 (entrada POTS), que vai transformar o DNIS 23232000 para 2000, e só então ela vai dar match na dial-peer 2 (saída VOIP), com o DNIS 2000.

Ou seja, aqui vamos mudar o DNIS de 23232000 para 2000.

4. Call-Leg de Saída POTS
A saída POTS é quando um IP Phone faz uma chamada para a PSTN, porém na call-leg da PSTN. O CUCM manda os dígitos para o gateway, e o gateway manda para a PSTN, por isso é sainte no lado POTS. Usando o exemplo acima:
ANI: 2000
DNIS: 0190

O que podemos mudar aqui? Hmmm, aqui podemos mudar as duas coisas. Podemos mudar o ANI, transformando ele por exemplo de 2000 para 23232000. E podemos mudar o DNIS, marcando o plan e type da chamada. Opa, isso é novo, né? Sim, e específico para o CCIE, porque no Brasil não usamos isso... na prova eles te pedem para marcar duas flags do ISDN chamadas Plan e Type. O Plan é sempre ISDN ou Unknown, e o Type pode ser Unknown, Subscribe (para chamadas locais), National (para DDD) ou International (para DDI). Você pode marcar esses campos na Route Pattern ou Route List, mas de novo... faça a marcação sempre no Gateway quando for H.323, pelo mesmo motivo do SRST... esse é um motivo clássico que as pessoas perdem ponto em High Availability! Na parte de call routing eles te pedem uma marcação específica, mas aí quando o seu site entra em SRST, as chamadas todas funcionam, porém não saem marcadas de acordo, porque o cara configurou tudo no Call Manager. Cuidado!
Bom, então aqui vamos mudar o ANI de 2000 para 23232000. E no DNIS, vamos marcar as chamada de emergência com Plan ISDN e Type Unknown, e chamadas locais com Plan ISDN e Type Subscribe.

5. Montando as expressões regulares
Finalmente entramos na parte mais interessante, que é a configuração. A ideia é primeiro criar uma voice translation-rule, onde especificaremos as regras usando expressões regulares. E depois aplicaremos essas regras a translation-profiles. E por fim, aplicaremos os translation-profiles nas dial-peers.
A parte mais complicada aqui são as regras. Existem várias expressões regulares que você pode usar... mas vamos simplificar as coisas, né? Vamos usar apenas algumas, que podem parecer complicadas a primeira vista, mas se você entender, conseguirá fazer qualquer manipulação...
As regras são:

^: começa com
$: fim da string
( ): definição de um grupo de caracteres
\: caractere de escape
.: um dígito
/: início e fim de uma expressão
.*: um dígito qualquer seguido de 0 ou mais ocorrências. Ou seja, "qualquer coisa".

Ok, vamos usar o seguinte exemplo. Eu quero transformar 44445555 em 55554444123. Uma transformação realmente sem pé nem cabeça, mas que vai nos ajudar a entender. Vamos construir a expressão regular aos poucos, passo a passo.

Primeiro, vou criar 2 expressões:
// //
O primeiro // é no que eu vou dar o match, e o segundo // é no que eu quero transformar. Lembrando que cada / é o início e fim de uma expressão. Ou seja, todo o resto vou ter que colocar dentro dos /.

Ok, agora vamos começar com o primeiro //, onde eu vou dar o match na string que eu quero transformar. Poderíamos fazer algo como /44445555/, certo? Vai dar match... Mas a string 99944445555 também daria match. Então vamos dar uma melhorada nisso:
/^44445555$/
Hmmm, ficou melhor... agora só quando começar com 44445555 e acabar nisso que vai dar match. 99944445555 não vai mais, porque não começa com 4, e 44445555999 também não vai dar, porque temos o delimitador de fim de string $ lá na regra. Ok, mas o nosso objetivo é inverter o 5555 com 4444 e depois colocar um 123 no final, certo? Então podemos juntar o 4444 em um grupo e o 5555 em outro grupo, assim:
/^(4444)(5555)$/
Ta ficando bom... mas tem um problema. O ( e o ) são caracteres especiais, e precisamos dizer para a fórmula interpretá-los para terem o sentido de delimitadores de um grupo. Para fazer isso, colocamos o caractere de escape \. Dica: Sempre coloque \ antes de ( ou ), aí não tem erro:
/^\(4444\)\(5555\)$/
Vamos colocar uma mudança aqui nos requisitos. Ao invés de ser só 44445555, digamos que a gente queira transformar qualquer número no formato 4XXX5XXX para 5XXX4XXX123. Simples:
/^\(4...\)\(5...\)$/
Veja que separamos a string em dois grupos, o 4XXX e o 5XXX. Chamaremos respectivamente de grupo 1 e grupo 2.

Agora vamos pensar no segundo //, que é no que eu quero transformar.
Eu quero então pegar a string que eu dei match, e inverter o grupo 1 com o grupo 2, e depois colocar 123 no final, certo? Olha que legal, se eu fizer \1, eu referencio o grupo 1, e se eu fizer \2, eu referencio o grupo 2. Então fica fácil:
/\2\1/
Com isso, eu transformei a string inicial em 55554444, ou seja, coloquei o grupo 2, e depois o grupo 1. Agora é só colocar 123 no final:
/\2\1123/
Então a nossa regra final ficou assim:
/^\(4...\)\(5...\)$/ /\2\1123/

6. Configurando o exemplo
Finalmente vamos por a mão na massa e configurar o nosso exemplo.

Na Call-Leg de Entrada VOIP, nada a se fazer.

Na Call-Leg de Saída VOIP, vamos mudar o ANI (calling number) de 1122554000 para 022554000:

voice translation-rule 1
 rule 1 /^11\(........\)$/ /0\1/

voice translation-profile ANI
 translate calling 1

dial-peer voice 2 voip
 description *** Dial-Peer de Saída VOIP para o CUCM ***
 destination-pattern 2...
 session-target ipv4:10.1.1.10
 codec g711ulaw
 no vad
 translation-profile outgoing ANI

Ok, aqui cabe uma explicação
Primeiro eu criei a regra, você pode ter até 15 regras dentro de um translation-rule. Note que eu peguei a parte que me interessa da String e coloquei em um grupo (Grupo 1). E na manipulação eu apenas coloquei um 0 e concatenei com o grupo 1. Com a regra criada, eu crio um translation-profile, que pode ter qualquer nome, mas sugiro colocar um intuitivo. No profile eu digo qual rule vou usar, e especifico se ele vai manipular o calling ou o called number.
E por fim, chamo o profile na dial-peer, especificando se o sentido da regra é incoming (entrada) ou outgoing (saída). Cuidado que a IOS deixa você colocar qualquer coisa no nome do profile... e é case-sensitive. Ou seja, se você criar um profile chamado ANI, e na dial-peer você chamar o profile ani, não vai dar erro na IOS, mas não vai funcionar.

Na Call-Leg de Entrada POTS, vamos mudar o DNIS (called number) de 23232000 para 2000.

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

voice translation-profile DNIS
 translate called 2

dial-peer voice 3 pots
 description *** Dial-Peer de Entrada POTS de chamadas vindas da PSTN ***
 incoming called-number .
 direct-inward-dial
 translation-profile incoming DNIS

Decore essa regra! Eu poderia ter criado uma assim /^2323\(....\)$/ /\1/, certo? Mas não preciso ser tão específico... com certeza você vai usar essa regra na prova e na vida, então simplifique. Não interessa o 2323, o que você quer é pegar qualquer string, e arrancar os últimos 4 dígitos dela. Essa regra é bem genérica, e você pode usar independente do dial-plan. O que essa regra faz é justamente isso, pegar os 4 últimos dígitos de qualquer string.

E finalmente, na Call-Leg de Saída POTS, vamos mudar o ANI (calling number) de 2000 para 23232000, e vamos marcar as chamada de emergência com Plan ISDN e Type Unknown (called number), e as chamadas locais com Plan ISDN e Type Subscribe.

voice translation-rule 3
 rule 1 /^\(2...\)$/ /2323\1/

voice translation-rule 4
 rule 1 // // type any unknown plan any isdn

voice translation-rule 5
 rule 1 // // type any subscribe plan any isdn

voice translation-profile OutPSTN-Emergencia
 translate calling 3
 translate called 4

voice translation-profile OutPSTN-Local
 translate calling 3
 translate called 5

dial-peer voice 4 pots
 description *** Dial-Peer de Saída POTS para a PSTN ***
 destination-pattern 0[1][9].
 port 0/0/0:15
 translation-profile outgoing OutPSTN-Emergencia

dial-peer voice 5 pots
 description *** Dial-Peer de Saída POTS para a PSTN ***
 destination-pattern 0[2-9].......
 port 0/0/0:15
 translation-profile outgoing OutPSTN-Local

Esse profile manipulou tanto o calling como o called. Veja que no called, não houve alteração nos dígitos, fizemos apenas a marcação do ISDN.

7. Verificações
O melhor jeito de verificar se as suas regras estão certas, é através do comando test voice translation-rule. É só colocar a string de dígitos, que a IOS vai te mostrar como que vai ficar ele traduzido, por exemplo:

router#test voice translation-rule 3 2000
Matched with rule 1
Original number: 2000    Translated number: 23232000

E também tem o debug voice translation-rule, para ver se as suas traduções estão certas em tempo real.

8. Dica para a prova
Se você entendeu tudo isso, pratique. Pratique muito, muito, muito!!! Use o test voice translation-rule e fique brincando, testando seus conhecimentos, inventando exemplos malucos.
E outra dica que eu dou, agora mais para a prova mesmo, é sempre criar um profile para cada dial-peer POTS. Mesmo que você nem use, deixe criado... Por exemplo

voice translation-rule 1
 rule 1 // //
voice translation-rule 11
 rule 1 // //
voice translation-profile 1
 translate calling 1
 translate called 11
dial-peer voice 1 pots
 translation-profile outgoing 1

Crie esse template no notepad, e faça todas as dial-peer seguindo ele. Conforme você vai lendo a seção de Call Routing, vá preenchendo as regras... tudo no notepad mesmo! Veja que tem uma regra para calling e outra para called... então é só ir preenchendo. E nem precisa dar nome bonito para os profiles não. Deixe o nome dele como sendo o mesmo que a tag da dial-peer correspondente. Dessa forma, você vai terminar a parte de Call Routing no gateway em alguns poucos minutos... e depois para arrumar alguma coisa é facinho, porque se você mexer em uma regra, é certeza que só está alterando aquela dial-peer. Enfim, fica a dica! :)