Estrategias - Dial Plan

Meio que continuando o post anterior, hoje falarei sobre Dial Plan. De longe, é o tema mais trabalhoso da prova. Veja que trabalhoso é diferente de difícil! Não é nem um pouco difícil, só tem que fazer tudo com muita atenção. O que vai contar aqui é mais o seu poder de concentração. A minha sugestão é fazer Call Routing antes do almoço, porque aí você vai pro seu lanchinho muito mais leve. Bom, mas tem gente que acha ao contrário... tem gente que prefere fazer tudo antes e deixar o Dial Plan pro final. Mas aí de novo, cada um é cada um.

O problema do Dial Plan é que a prova te dá muita informação, e tudo jogado. Num vai vir assim tudo bonitinho em uma tabela para você ver e configurar. As questões são grandes e a leitura cansativa. Se você chega despreparado, a hora de você lê uma questão dessas bate até um desespero. Mas no fundo é só saber interpretar, e aí novamente entram as tabelas!

Eu baseei a minha estratégia principalmente nas valiosas lições do Vik Malhi no Bootcamp. Tomei como base também esse vídeo do Mathew Berry (o mesmo cara do Device-Based Approach). Incorporei algumas coisas que aprendi fazendo labs, adaptando para uma forma que eu me sentia mais confortável de fazer, principalmente nas dial-peers, como veremos mais adiante. Então repito, nenhuma estratégia é definitiva! Use o que existe na Internet apenas como uma base para você desenhar o seu próprio caminho.

Bom, algumas coisas a saber sobre o Dial Plan:

1) O dial plan da prova não é necessariamente completo. Pode ser que o Site A faça apenas chamadas Locais e DDD, o Site B faça apenas Internacionais e o Site C faça DDD e Emergência. Se a prova te falar isso, configure APENAS isso. Se eles não falarem nada de chamadas Internacionais no Site A, é porque não precisa. Não perca o seu tempo. O Dial Plan da prova não é pra ter sentido mesmo.

2) Na prova, eles pedem para você marcar o Plan e Type do ISDN nas chamadas, coisa que não fazemos no Brasil (especialmente se o link for R2-Digital). Eles geralmente especificam qual é a marcação necessária pra cada tipo de chamada. O que vou escrever aqui é algo que EU acho e não li em lugar nenhum: sugiro que, mesmo que a prova não te peça, marque as chamadas Locais como Subscribe, DDD como National e DDI como International, e plan ISDN (exceto se pedirem para não marcar nada, ou marcar como unknown). É uma sugestão! Até porque perder ponto você num vai... Mas não sei dizer se você perde ponto se deixar de fazer.

3) Mesmo que a prova não fale nada, considere que tudo tem que sair marcado da mesma forma quando o site estiver em SRST. Está implícito!

4) Os tipos de chamadas possíveis na prova são: Emergência, Local, Long Distance (DDD) e International (DDI). E os respectivos TEHOs/Transbordos, ou seja, quando a chamada é originada de um site e sai por outro. E as manipulações incluem o Called Number e o Calling Number.


Tendo isso em mente, vamos às nossas tabelas!

Assim como o Mathew Berry, eu criava uma tabela para cada site. Só que já especificava todos os tipos possíveis de chamadas de cada localidade (incluindo os TEHOs). Ela ficava mais ou menos assim:

Essa tabela lista todas as chamadas possíveis de cada site. Como o dial plan não é completo, a maior parte dela ficará em branco. Sem problemas! Na coluna do Calling, eu escrevo qual é a manipulação do número de origem que a prova quer. E na do Called, a manipulação do número de destino. Veja que independente de onde a chamada vier (do próprio site ou dos outros dois), o Called vai ser o mesmo. Afinal, se a E1 é a mesma, não tem sentido manipular o número de destino dependendo do número de origem.

Bom, e embaixo (na mesma folha) eu fazia uma outra tabela assim:

Basicamente aqui vamos escrevendo o dial plan no Call Manager. Qual consistirá na route pattern, partition, route list, route groups e as manipulações dentro de cada Route Group. Eu não criava nada no CUCM, jogava apenas na tabela e criava tudo de uma vez depois.

A dica do dia é (isso você pode tomar como regra): Sempre que o gateway for H.323, não manipule no Call Manager (a não ser que seja um requerimento da prova). Porque se você fizer isso, a chamada não vai mais funcionar em SRST. Então sempre que possível jogue a manipulação no IOS através de translation-profiles. Quando o gateway for MGCP, aí não tem jeito.

A outra dica (essa já é opcional) é: sempre que for fazer a manipulação no CUCM, faça na Route List/Route Group, e nunca na Route Pattern. Porque às vezes dentro de uma Route List você tem 2 ou mais Route Groups, e para cada um a manipulação ter que ser diferente. Se você fizer na Route Pattern, vai valer para os dois. Use a manipulação na Route Pattern apenas para mudar a forma como a chamada é exibida na tela do telefone, como explicado nesse post.

Beleza! Já temos as nossas duas tabelas. Uma resume todo o dial plan (e é muito útil depois para fazer os testes) e a outra resume as suas rotas no CUCM. Agora falta o gateway (para quando ele for H.323 ou SIP). Nesse caso eu não fazia tabela, eu abria um notepad e ía configurando tudo junto enquanto montava essas duas tabelas.

Primeiro, eu montava um template de configuração, como já falei em posts passados. Assim:

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

Todas as minhas dial-peers tinham uma translation-rule para Calling (XXX), uma para Called (1XXX), que estavam associadas a um translation-profile XXX. Pode ser que algumas translation-rules ficassem vazias? Sim. Pode ser que tivesse 2 iguais? Sim. Mas não tem problema... a sua configuração não tem que ficar bonita, tem que funcionar. Então antes de começar o Dial Plan, eu digitava esse template no notepad, e ía fazendo as dial-peers na base do Ctrl C, Ctrl V.

Vamos aplicar tudo isso na prática para entendermos melhor.

Vamos supor o seguinte enunciado:

Site A é  H.323. Site B é MGCP.
Ramais no Site A estão no range 3XXX, e E.164 +551123233XXX.
Ramais no Site B estão no range 4XXX, e E.164 +552134344XXX.
Para não extender muito, não vou considerar o Site C nesse exemplo.

Quando o Site A faz chamadas de emergência (190), o número de origem deve ser de 8 dígitos, type subscribe e plan ISDN. Você deve mandar 3 dígitos para a PSTN, com Plan e Type Unknown.

Lendo isso, eu já preencho as minhas tabelas:

E crio a dial-peer no Notepad para o Site A (dica: utilize o Ctrl H para substituir XXX por 190):

voice translation-rule 190
 rule 1 /^\(3...\)$/ /2323\1/ type any subscribe plan any isdn
voice translation-rule 1190
 rule 1 // // type any unknown plan any unknown
voice translation-profile 190
 translate calling 190
 translate called 1190
dial-peer voice 190 pots
 translation-profile outgoing 190
 destination-pattern 190
 no digit-strip
 port 0/0/0:15
 
E o enunciado segue:

As chamadas Locais do Site A devem ser encaminhadas para a PSTN com 8 dígitos, sendo o primeiro de 2 a 9, type subscribe e plan ISDN. O número de origem deve ser os 4 dígitos do ramal, plan isdn e type unkown. Para as chamadas locais, os usuários utilizam o código de acesso 0.

 Aí eu vou la na tabela:

E depois crio a Dial-Peer:

voice translation-rule 29
 rule 1 // // type any unknown plan any isdn
voice translation-rule 129
 rule 1 // // type any subscribe plan any isdn
voice translation-profile 129
 translate calling 29
 translate called 129
dial-peer voice 29 pots
 translation-profile outgoing 129
 destination-pattern 0[2-9].......
 port 0/0/0:15 

E o enunciado segue:

Quando o Site B ligar para algum número do código de área 11 (0011 + 8 dígitos), a chamada deve sair como uma chamada Local no Site A. Nesses casos, o número de origem será 10 dígitos, type national e plan ISDN. Se a chamada falhar, ela deve transbordar para o gateway do Site B como uma chamada DDD. Nesse caso, o número de origem será de 8 dígitos, plan ISDN e type subscribe, e o número de destino será 10 dígitos, type national e plan ISDN.

Aí eu volto pra tabela e faço:

Veja que no Site A, a dial-peer de chamada local já está pronta. O que precisamos é criar a regra do Calling de quando a chamada vem do Site B. Basta alterarmos a translation-rule que faz isso:

voice translation-rule 29
 rule 1 // // type any unknown plan any isdn
 rule 2 /^\(4...\)$/ /3434\1/ type any subscribe plan any isdn


Note que no caso do Site B, como é MGCP, temos que fazer as traduções direto no Route Group. Esse é um exemplo que não poderíamos manipular na Route Pattern, porque afetaria as chamadas que usassem o Route Group RG_SA, e não é isso que queremos. Na Route Group do RG_SA eu apenas manipulei o Called para que o gateway receba a chamada já no formato de chamada Local, para não precisarmos criar outra dial-peer.

Depois que terminamos de preencher todas as tabelas e as dial-peers, o trabalho pesado acabou. Basta aplicar o script das dial-peers nos roteadores, e criar as Partitions, Route Patterns, Route Lists e Route Groups no CUCM. Dá trabalho, mas é braçal, e não precisamos mais usar tanto o cérebro. Coisa de 10 minutos temos tudo pronto.

No começo pode parecer tudo muito complicado, mas vai por mim... não é! É questão de analisar tudo com calma e praticar, praticar e praticar.