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! :)

Montando um Home Lab (Parte 2 - GNS3)

Continuando o post anterior, vou falar agora sobre a parte do GNS3, que é uma interface gráfica para o Dynamips. Você pode baixar o software gratuitamente no site deles (http://www.gns3.net/download/). Baixe o pacote all-in-one.

1. Configurando o GNS3

A instalação é Next, Next, Finish. Ele vai pedir para instalar junto o PCAP e o Wireshark. Pode instalar se quiser. Se você já tiver instalado na sua máquina, pode manter a sua versão mesmo.
Depois de instalado, ele vai entrar em um Setup Wizard com 3 passos.

O primeiro é para checar o diretório do Dynamips. Execute esse Step, e aponte o caminho do Dynamips.exe, por exemplo C:\Program Files\GNS3\dynamips.exe
E defina um working directory, por exemplo C:\Temp

O segundo passo vai pedir para você apontar o diretório onde estão as IOSs. Defina o Project Directory e OS Image, por exemplo C:\Users\Bruno\GNS3\Projects e C:\Users\Bruno\GNS3\Images

O passo 3 pode ignorar por enquanto.


2. Criando a topologia

No meu lab, criei a seguinte topologia:
1 x Router 2691 para o Head Quarters
1 x Router 2691 para o Branch Office 1
1 x Router 7200 para o Branch Office 2 (porque é o único que roda CME 7.0)

Esses routers estão ligados em um Switch Frame Relay, e eles trocam rotas via OSPF.

O Router do Head Quarters liguei na minha rede doméstica (que faz bridge com as minhas VMs). O router do Br1 liguei na VMNet1 e o do Br2 na VMNet2. Dessa forma, cada router está em uma LAN diferente.

A rede do HQ é 172.16.10.0/24
A rede do Br1 é 172.16.20.0/24
A rede do Br2 é 172.16.30.0/24

Eu também tinha colocado um outro router para simular a PSTN, e aí eu mandava a chamada para esse router usando Dial-Peers VOIP. Mas sinceramente, não me ajudou muito. Mas você pode fazer, se quiser.

3. Configurações

Bom, agora vamos configurar tudo isso. Começando pelas nuvenzinhas. Cada nuvenzinha representa uma interface de rede. Arraste 3 itens desse para a sua tela de desenvolvimento, clique com o botão direito e depois em Configure. Em Generic Ethernet NIO você verá pelo menos 3 interfaces: A sua Local Area Connection (interface de rede normal), a VMNet1 e a VMNet2. Pode ter mais do que isso caso você tenha uma placa wireless, ou outras VMNets configuradas, mas não vamos utilizá-las. Crie as 3 "nuvens", cada uma em uma interface de rede.

Agora crie 3 Ethernet Switches, e ligue cada nuvem em um switch diferente usando uma conexão FastEthernet. Não precisa configurar nada de VLAN, deixe tudo default.

Depois disso, vamos criar os routers. Mas antes disso, precisamos declarar as IOSs que cada um vai utilizar. Para isso, acesse Edit >> IOS Images and Hypervisor, procure a IOS, selecione a plataforma e adicione à lista. Adicione 1 para o 2691 e uma para o 7200, conforme a figura abaixo:

Feito isso, crie os 3 routers, um de cada site, da seguinte forma:

Router HQ: (Adapters) - Slot0: GT-96100-FE; (WICs) - wic0: WIC-2T
Router Br1: (Adapters) - Slot0: GT-96100-FE; (WICs) - wic0: WIC-2T
Router Br2: (Adapters) - Slot0: C7200-IO-2FE; Slot1: PA-4T +


Conecte cada roteador ao seu respectivo Switch usando uma conexão FastEthernet. E finalmente, adicione um Frame Relay Switch ao desenho. E configure esse cara da seguinte forma:

Faça uma conexão Serial do HQ para a interface 1 do Frame Relay Switch, do Br1 para a interface 10 e do Br2 para a interface 11.

E finalmente, vamos começar as configs do Frame Relay e OSPF de cada roteador:

- HQ

interface FastEthernet0/0
 ip address 172.16.10.1 255.255.255.0
 duplex auto
 speed auto
!
interface Serial0/0
 no ip address
 encapsulation frame-relay
 clock rate 2000000
!
interface Serial0/0.1 point-to-point
 description Connection to BranchOffice1
 ip address 10.10.10.1 255.255.255.252
 snmp trap link-status
 frame-relay interface-dlci 101  
!
interface Serial0/0.2 point-to-point
 description Connection to BranchOffice2
 ip address 10.10.10.5 255.255.255.252
 snmp trap link-status
 frame-relay interface-dlci 102  
!
router ospf 1
 log-adjacency-changes
 network 10.10.10.0 0.0.0.3 area 0
 network 10.10.10.4 0.0.0.3 area 0
 network 172.16.10.0 0.0.0.255 area 0

- Branch Office 1

interface FastEthernet0/0
 ip address 172.16.20.1 255.255.255.0
 duplex auto
 speed auto
!
interface Serial0/0
 no ip address
 encapsulation frame-relay
 clock rate 2000000
!
interface Serial0/0.1 point-to-point
 ip address 10.10.10.2 255.255.255.252
 snmp trap link-status
 frame-relay interface-dlci 202 
!
router ospf 1
 log-adjacency-changes
 network 10.10.10.0 0.0.0.3 area 0
 network 172.16.20.0 0.0.0.255 area 0
!

- Branch Office 2

interface FastEthernet0/0
 ip address 172.16.30.1 255.255.255.0
 speed auto
 half-duplex
!
interface Serial0/0
 no ip address
 encapsulation frame-relay
 serial restart-delay 0
 clock rate 2000000
 frame-relay lmi-type ansi
!
interface Serial0/0.1 point-to-point
 description Connection to HQ
 ip address 10.10.10.6 255.255.255.252
 snmp trap link-status
 frame-relay interface-dlci 203   
!
router ospf 1
 log-adjacency-changes
 network 10.10.10.4 0.0.0.3 area 0
 network 172.16.30.0 0.0.0.255 area 0

Pronto. Agora você tem 3 sites se falando via Frame Relay, como na prova. Você pode criar uma VM Windows XP e colocar na VMNet 1 com um IP Communicator, e uma outra VM Windows XP e colocar na VMNet 2 com outro IP Communicator. Pode também configurar o router do Branch2 como CME, e registrar o IP Communicator nele. Enfim, aí você mexe no seu laboratório do jeito que ficar melhor.

Have fun! :-)

Montando um Home Lab (Parte 1 - VMWares)

Criar um Home Lab pode te poupar muitas horas de lab remoto durante a sua preparação. Não precisa criar um home lab completo, com gateways de verdade, PVDMs, E1s, telefones... claro, se você tiver condições, melhor! Mas montar um lab completo sai caro e toma tempo... a sugestão que eu dou é criar um lab simples, sem muito (ou nenhum) investimento, para poder testar algumas coisas. E dá para testar bastante coisa! No lab que vou mostrar nos próximos posts utilizaremos basicamente VMWare e GNS3/Dynamips.

Primeiramente, você precisa das ISOs de instalação do CUCM, CUC, UCCX e CUPS. Você pode comprar da Cisco uma versão para lab, ou usar métodos alternativos por sua conta em risco! hehehe... O caso do UCCX é um pouco mais complicado porque precisa de licença, precisa da ISO de instalação do Windows, etc. Para os outros servidores, existe uma forma de transformar um ISO de upgrade (que você pode baixar do site da Cisco) em "bootável". Veja aqui.

Fora as ISOs, você precisa de uma máquina relativamente boa. Mas não precisa exagerar! A minha por exemplo é um Intel QuadCore 2.66GHz, 8GB de RAM, rodando um Windows 7 64bits. E rodava bem... isso porque durante o seu lab, você não precisa subir as 4 VMs ao mesmo tempo. Sobe apenas as que você precisa e deixa as outras em Suspended. E a dica que eu dou também é usar processador da Intel. Já tive vários problemas rodando em AMD.

E finalmente, você vai precisar de um VMWare Workstation (que é pago... mas aí você dá os seus pulos! hehehehe), do GNS3 (que é gratuito e você pode baixar aqui), e de algumas IOSs.

Com tudo isso em mãos, vamos começar a montar o lab, que terá a seguinte topologia:

Nesse post falarei apenas do Site HQ, que vai ser basicamente subir os 4 servidores. Não vou entrar na parte de GNS3 ainda, senão vai ficar muita coisa.


1. Rede

Primeiro, você tem que decidir se vai por os servidores na mesma LAN da sua casa, ou se vai criar uma rede isolada dentro do seu computador. Eu acho mais legal colocar na LAN da sua casa, porque aí você pode colocar outros notebooks na rede e subir vários IP Communicators e tal, vai poder acessar os servidores via Wireless de um outro local... enfim, fica melhor!Para isso não precisamos fazer nada com relação a configuração de rede no VMWare. Mas como teremos os sites Branch1 e Branch 2 (esses sim criados como uma rede isolada dentro da sua máquina), vamos criar essas duas redes usando a ferramenta Network Editor, que vem junto na instalação da VMWare. Essa ferramenta tem essa cara:

Vamos colocar os servidores na VMnet0 (que está como Bridged, ou seja, vai usar a rede que está conectada na interface selecionada, entrando na LAN da sua casa), e criaremos a VMnet1 e VMnet2, cada uma em uma rede diferente, onde colocaremos o Branch1 e Branch2, respectivamente.
Para isso, em cada uma delas, selecione a opção Host-Only, habilite o DHCP e defina o IP da rede, como mostra abaixo:

No meu exemplo, defini como sendo 172.16.20.0/24 a rede da VMnet1 (Branch1) e 172.16.30.0/24 a rede da VMnet2 (Branch2).

Repare que o Windows criou 2 placas de redes virtuais. Atribua a elas os IPs 172.16.20.100 e 172.16.30.100, por exemplo:

Agora finalmente vamos começar a criar as VMs.


2. Criando as Máquinas Virtuais

Com a rede preparada, é hora de começarmos a criar as máquinas virtuais. Criaremos inicialmente 4 VMs, uma para cada servidor. No lab real, tem mais uma que é o CUCM Subscriber. Mas para o nosso home lab, ele não é necessário.

No VMWare Workstation, vá em File >> New >> Virtual Machine. Selecione a opção Custom (advanced) e depois Next.

Quando ele pedir para escolher o driver ou ISO de instalação, selecione a opção "I will install the operating system later", e clique Next.

O wizard vai pedir para você escolher o Sistema Operacional. Se for alguma versão antes da 8.6, escolha Linux >> Red Hat Enterprise Linux 4. Após a 8.6, o sistema operacional passa a ser Red Hat Linux 5. Mas como estamos montando um lab de CCIE, com os servidores na versão 7.0, vamos escolher o Red Hat 4.

Escolha um nome para a máquina, e um diretório para armazená-la. Veja se você tem bastante espaço em disco!

Deixe o número de processadores e core, como 1, e aloque 2048 MB de RAM para cada VM.

Selecione o opção "Use bridged networking" como Network Type, para que a VM utilize a LAN da sua casa.

 

Use o disco LSI Logic e crie um novo disco virtual do tipo SCSI com 80GB. Não aloque o espaço, deixe que a VM cresça sozinha... dificilmente vai chegar nos 80GB. E recomendo que divida o disco em arquivos de 2GB, no caso de você ter que copiar a VM para um HD externo que por acaso esteja formatado em FAT32 (já aconteceu comigo! hehe).

 

Pronto, a sua VM foi criada, e você vai vê-la na barra da esquerda. Clique com o botão direito nela e vá em Settings. Veja se a configuração está ok, depois clique em CD/DVD, marque a opção "Connected at power on", e selecione "Use ISO image file", selecionando o ISO de instalação.

Pronto, é só ligar a VM que ela já vai iniciar a instalação. Instale normalmente, como você faz no dia-a-dia. No caso das versões 8.x, é obrigatório você ter um servidor NTP, aí você pode usar um externo (ntp.br), ou subir um roteador no GSN3, como veremos nos próximos posts.

No caso do CCX é quase a mesma coisa, mas você deve selecionar como sistema operacional o Windows 2003 Server.

Nos próximos posts continuarei com a montagem desse Home Lab.

Instalando locales no CME

E ai pessoal!
Primeiramente, Feliz Ano Novo!!! Espero que 2013 seja um ano de muitas conquistas para você, assim como foi 2012 para mim!

Bom, começo o ano escrevendo sobre como instalar uma nova locale no CME a partir da versão 7.0. Você pode encontrar o procedimento completo neste link. Mas resumidamente, os passos são:

1. Baixe o pacote de línguas do CME do site da Cisco. É um arquivo ZIP com todas as locales disponíveis em formato TAR. Escolha os TARs que você deseja, e jogue na flash do roteador, dentro da pasta its/

copy tftp://x.x.x.x/CME-locale-xx_XX-Xxxxxx-8.6.2.4.tar flash:/its/

2. Defina o cnf-file como "perphone", dentro de telephony-service

telephony-service
 cnf-file perphone

3. Defina o cnf-file location na flash

telephony-service
 cnf-file location flash:

4. Defina a locale default do sistema.

telephony-service
 user-locale U1 load CME-locale-pt_BR-Portuguese-8.6.2.4.tar

Essa vai ser a locale default, definida na "user-locale 0". Dessa forma, todos os telefones estarão em Portugues. Se é isso que você deseja, pode parar por aqui. Mas caso você queira alguns telefones em outras línguas, execute os passos abaixo.

5. Defina as locales adicionais.

telephony-service
 user-locale 1 U2 load CME-locale-en_US-English-8.6.2.4.tar
 user-locale 2 U3 load CME-locale-ja_JP-Japanese-8.6.2.4.tar

Agora, definimos na "user-locale 1" a lingua inglesa e na "user-locale 2" a lingua japonesa.

6. Aplique as linguas em ephone-templates, e os templates nos ephones.
ephone-template 1
 user-locale 1

ephone-template 2
 user-locale 2

ephone 1
 ephone-template 1

ephone 2
 ephone-template 2

Atualize os arquivos CNF:
telephony-service
 create cnf-file

E resete os telefones.


Troubleshooting

Você não precisa adicionar nada no tftp-server, porque ele cria o binding automaticamente. Você pode verificar isso com o comando show telephony-service tftp-bindings:

tftp-server flash:/its/user_define_1_7905-dictionary.xml alias User_Define_1/7905-dictionary.xml
tftp-server flash:/its/user_define_1_7905-kate.xml alias User_Define_1/7905-kate.xml
tftp-server flash:/its/user_define_1_7921-dictionary.xml alias User_Define_1/7921-dictionary.xml
tftp-server flash:/its/user_define_1_7921-font.dat alias User_Define_1/7921-font.dat
tftp-server flash:/its/user_define_1_7921-kate.utf-8.xml alias User_Define_1/7921-kate.utf-8.xml
tftp-server flash:/its/user_define_1_7921-kate.xml alias User_Define_1/7921-kate.xml
tftp-server flash:/its/user_define_1_7960-dictionary.xml alias User_Define_1/7960-dictionary.xml
tftp-server flash:/its/user_define_1_7960-dictionary-ext.xml alias User_Define_1/7960-dictionary-ext.xml
tftp-server flash:/its/user_define_1_7960-font.xml alias User_Define_1/7960-font.xml
tftp-server flash:/its/user_define_1_7960-kate.xml alias User_Define_1/7960-kate.xml
tftp-server flash:/its/user_define_1_be-sccp.jar alias User_Define_1/be-sccp.jar
tftp-server flash:/its/user_define_1_g3-tones.xml alias User_Define_1/g3-tones.xml
tftp-server flash:/its/user_define_1_gp-sccp.jar alias User_Define_1/gp-sccp.jar
tftp-server flash:/its/user_define_1_ipc-sccp.jar alias User_Define_1/ipc-sccp.jar
tftp-server flash:/its/user_define_1_mk-sccp.jar alias User_Define_1/mk-sccp.jar
tftp-server flash:/its/user_define_1_SCCP-dictionary.utf-8.xml alias User_Define_1/SCCP-dictionary.utf-8.xml
tftp-server flash:/its/user_define_1_SCCP-dictionary.xml alias User_Define_1/SCCP-dictionary.xml
tftp-server flash:/its/user_define_1_SCCP-dictionary-ext.xml alias User_Define_1/SCCP-dictionary-ext.xml
tftp-server flash:/its/user_define_1_tags_file alias User_Define_1/tags_file
tftp-server flash:/its/user_define_1_tc-sccp.jar alias User_Define_1/tc-sccp.jar
tftp-server flash:/its/user_define_1_td-sccp.jar alias User_Define_1/td-sccp.jar
tftp-server flash:/its/user_define_1_rp-sccp.jar alias User_Define_1/rp-sccp.jar
tftp-server flash:/its/user_define_1_utf8_tags_file alias User_Define_1/utf8_tags_file
tftp-server flash:/its/user_define_1_rtl-sccp.jar alias User_Define_1/rtl-sccp.jar
tftp-server flash:/its/user_define_1_g4-tones.xml alias User_Define_1/g4-tones.xml

Obviamente, os arquivos devem estar na flash. O CME instala esses arquivos no passo 4/5. É automático, você não precisa descompactar o TAR manualmente

Router# sh flash | i user_define_1
178      62041 Jan 2 2013 12:48:52 +00:00 its/user_define_1_ipc-sccp.jar
186      69903 Jan 2 2013 12:48:56 +00:00 its/user_define_1_rp-sccp.jar
187      71837 Jan 2 2013 12:48:56 +00:00 its/user_define_1_tc-sccp.jar
188       2858 Jan 2 2013 12:48:54 +00:00 its/user_define_1_tags_file
189       4141 Jan 2 2013 12:48:54 +00:00 its/user_define_1_SCCP-dictionary.xml
190       6656 Jan 2 2013 12:48:54 +00:00 its/user_define_1_SCCP-dictionary.utf-8.xml
191      75004 Jan 2 2013 12:48:52 +00:00 its/user_define_1_gp-sccp.jar
192       1302 Jan 2 2013 12:48:50 +00:00 its/user_define_1_g3-tones.xml
193      61964 Jan 2 2013 12:48:50 +00:00 its/user_define_1_be-sccp.jar
194        736 Jan 2 2013 12:48:50 +00:00 its/user_define_1_7960-tones.xml
195      13326 Jan 2 2013 12:48:48 +00:00 its/user_define_1_7960-font.xml
196      23450 Jan 2 2013 12:48:48 +00:00 its/user_define_1_7960-dictionary-ext.xml
197      22811 Jan 2 2013 12:48:48 +00:00 its/user_define_1_7960-dictionary.xml
198       1820 Jan 2 2013 12:48:48 +00:00 its/user_define_1_7921-kate.xml
199     137616 Jan 2 2013 12:48:46 +00:00 its/user_define_1_7921-font.dat
200       1820 Jan 2 2013 12:48:46 +00:00 its/user_define_1_7905-kate.xml
201      20718 Jan 2 2013 12:48:46 +00:00 its/user_define_1_7905-dictionary.xml
202       1789 Jan 2 2013 12:48:58 +00:00 its/user_define_1_g4-tones.xml
203        636 Jan 2 2013 12:48:58 +00:00 its/user_define_1_CME-locale-pt_BR-Portuguese-8.6.2.4.tar.cfg
204     120131 Jan 2 2013 12:48:58 +00:00 its/user_define_1_rtl-sccp.jar
205       2839 Jan 2 2013 12:48:56 +00:00 its/user_define_1_utf8_tags_file
206      62041 Jan 2 2013 12:48:56 +00:00 its/user_define_1_td-sccp.jar
207       6557 Jan 2 2013 12:48:54 +00:00 its/user_define_1_SCCP-dictionary-ext.xml
208      61764 Jan 2 2013 12:48:52 +00:00 its/user_define_1_mk-sccp.jar
209       1820 Jan 2 2013 12:48:50 +00:00 its/user_define_1_7960-kate.xml
210       1886 Jan 2 2013 12:48:48 +00:00 its/user_define_1_7921-kate.utf-8.xml
211      60189 Jan 2 2013 12:48:46 +00:00 its/user_define_1_7921-dictionary.xml


Verifique se os arquivos estão ok na flash, e se os bindings do tftp foram criados. Caso esteja tudo ok, veja se o arquivo de configuração do telefone está com a linguagem correta. Esses arquivos ficam na flash (porque definimos nos passos 2 e 3), e tem o nome no formato SEP<MAC_Address>.cnf.xml. Para visualizá-los, faça:
Router# sh flash | i <MAC Address>
131       1475 Jan 2 2013 13:26:44 +00:00 its/vrf1/SEP0021A0D76E1B.cnf.xml
Router# more its/vrf1/SEP0021A0D76E1B.cnf.xml

No arquivo, você deve ver algo assim:
<userLocale>
<name>User_Define_1</name>
<langCode>pt_BR</langCode>
<winCharSet>utf-8</winCharSet>
</userLocale>

Outro comando útil para esse troubleshooting, é verificar se o telefone está conseguindo fazer o download dos arquivos via tftp. Use o debug tftp events.
Jan  2 13:50:25.671: TFTP: Looking for CTLSEP0021A0D76E1B.tlv
Jan  2 13:50:25.771: TFTP: Looking for ITLSEP0021A0D76E1B.tlv
Jan  2 13:50:25.891: TFTP: Looking for ITLFile.tlv
Jan  2 13:50:26.083: TFTP: Looking for SEP0021A0D76E1B.cnf.xml
Jan  2 13:50:26.087: TFTP: Opened flash:/its/vrf1/SEP0021A0D76E1B.cnf.xml, fd 14, size 1475 for process 30
Jan  2 13:50:26.091: TFTP: Finished flash:/its/vrf1/SEP0021A0D76E1B.cnf.xml, time 00:00:00 for process 30
Jan  2 13:50:28.703: TFTP: Looking for User_Define_2/td-sccp.jar
Jan  2 13:50:28.707: TFTP: Opened flash:/its/user_define_2_td-sccp.jar, fd 14, size 59183 for process 30
Jan  2 13:50:28.887: TFTP: Finished flash:/its/user_define_2_td-sccp.jar, time 00:00:00 for process 30

Call Park no CME

Nossa, hoje me dei conta que o blog completará 1 ano em alguns dias. Mas certamente dessa vez eu não passarei o fim do ano escrevendo posts! hehehe

Hoje vou falar de call park no CME. Como dificilmente implantamos isso na vida real, esse foi um dos tópicos que me surpreendeu durante os estudos, devido a quantidade de detalhes que se pode configurar. O que eu sabia de Call Park era apenas o comando park-slot dentro de um ephone-dn e pronto, mas tem um monte de coisa que da para configurar.

Nesse post vou focar na versão 7.0 do CME, que é o que tem na prova. Na 7.1 tem algumas coisas mais, dentre elas o suporte a SIP Phones (na prova não vai cair Call Park para SIP, porque não é suportado), reservation-groups, directed call park, ...

Bom, começando do começo. Call Park é a feature de "estacionamento de chamadas", que tinha nos antigos PBX. A recepcionista, por exemplo, atendia uma ligação, fazia o park dela em um ramal XXXX, e anunciava pro chefe: "tem uma chamada no ramal XXXX". Aí o chefe ligava nesse ramal para capturá-la. No CUCM e CME temos essa feature, mas sinceramente, nunca vi ninguém usando na vida real... É mais fácil falar pro cara ligar depois! hehehe

Para configurarmos um ramal XXXX de park, simplesmente criamos um ephone-dn, por exemplo:

ephone-dn 10 dual-line
 number 3010
 name Call park
 park-slot

Agora vamos começar a ajustar esse nosso Call Park. A primeira coisa que podemos fazer, é definir alguns timers. Podemos definir que depois de "x" segundos que um cara estiver em park, um ring de lembrete será tocado no telefone da pessoa que estacionou a chamada. Aí digamos que queremos que esse lembrete ocorra por "y" vezes, e depois disso a chamada volte para quem fez o park. Caso o ramal esteja ocupado, ele vai tentar de novo depois de "s" segundos por "z" vezes. Nesse exemplo, o nosso ephone-dn ficaria assim:

ephone-dn 10 dual-line
 number 3010
 name Call park
 park-slot timeout x limit y recall retry s limit z

Agora, digamos que queremos que o ramal a ser notificado com um ring sobre uma chamada em park não seja o que fez o estacionamento, mas sim um um outro qualquer (por exemplo, o ramal 2001), aí faríamos:

ephone-dn 10 dual-line
 number 3010
 name Call park
 park-slot timeout x limit y notify 2001 recall

O cliente mudou o requisito de novo, e agora ele quer que quando o timeout/limit acabe, ao invés de a chamada voltar para quem fez o park, ela deve tocar no ramal 2050, e depois para o 2051 caso o 2050 esteja ocupado:

ephone-dn 10 dual-line
 number 3010
 name Call park
 park-slot timeout x limit y notify 2001 transfer 2050 alternate 2051

Obs: Podemos usar o alternate também como uma segunda opção do recall, ou seja:
ephone-dn 10 dual-line
 number 3010
 name Call park park-slot timeout x limit y notify 2001 recall alternate 2050

Bom, agora que estava todo mundo usando o call park a vontade, o cliente percebeu que muitas chamadas estavam se perdendo. Então ele quer que apenas a recepcionista no ramal 2000 consiga utilizar esse call-park. Aí utilizaremos o comando reserved-for:

 ephone-dn 10 dual-line
 number 3010
 name Call park
 park-slot reserved-for 2000 timeout x limit y recall
Mas mesmo assim, descobriram que o pessoal continua conseguindo fazer park da chamada. Só que ao invés de eles pressionarem o softkey Park para isso, eles descobriram que se eles dessem um transfer para o ramal 3010, a chamada era estacionada! Olha só que usuários safadinhos! Mas para isso podemos bloquear esse comportamento configurando dentro do ephone:

ephone X
 transfer-park blocked

Com isso, abordamos quase tudo de call park no CME, tem mais coisa, mas isso é o que eu me lembro! hahaha... Só tem mais uma coisa importante para se dizer. Por default, se existir por exemplo um ramal 1003 e um park-slot 3303, ele sempre vai tentar usar esse por causa do match dos últimos 2 dígitos. Se existisse um outro park-slot 3302, ele seria usado como segunda opção. Para desligar esse comportamento, faça:

telephony-service
 call-park select no-auto-match


Eu recomendo que façam vários testes com Call park, porque são muitos detalhes, como tudo no CME. A melhor coisa para se fazer ao estudar CME é ler o Admin Guide inteiro e ir testando feature por feature. Tenho várias páginas de anotações de CME no meu caderno (como essa), e aos poucos vou postando.

Dial-Peer Matching

Esse é um tema fácil, mas um tanto confuso. O match de dial-peer é extremamente importante para você definir a sua call leg de entrada e de saída no roteador, e fazer certo o seu dial plan.
Toda chamada que passa pelo gateway (seja ela voip ou pots) deve ter essas duas pernas: uma entrada e uma saída. Para entender melhor o que é isso, se coloque no lugar do roteador. Imagine uma chamada vindo da PSTN e tocando no IP Phone. Para o roteador, a perna que vem da PSTN é a entrada, e a que toca no telefone (ou seja, a que manda para o CUCM) é a saída. Já em uma chamada onde o IP Phone origina e toca na PSTN é ao contrário, temos uma perna de entrada que é a que vem do CUCM, e uma de saída que vai para a PSTN. Toda chamada para completar com sucesso precisa dessas duas dial-peers.
Para configurar uma dial-peer para dar matches de entrada ou saída, usamos os comandos incoming called-number, answer-address, destination-pattern e ports.

Dial-Peer de Entrada

O roteador possui 4 maneiras de verificar se uma chamada específica teve match em alguma dial-peer de entrada,  analisando o número de origem (ANI, ou Calling Number) ou destino (DNIS, ou Called Number) dessa chamada, ou a voice port que foi usada para recebê-la. E o roteador analisa nessa ordem:

1. Compara o número Destino com o incoming called-number
2. Compara o número de Origem com o answer-address
3. Compara o número de Origem com o destination-pattern
4. Verifica a Voice Port que recebeu a chamada

O que geralmente fazemos na vida real é logo de cara forçar uma dial-peer de entrada do tipo pots e do tipo voip. Assim:

dial-peer voice 1 pots
 incoming called-number .

dial-peer voice 2 voip 
 incoming called-numer .

Com isso, toda chamada que entrar da PSTN vai bater na dial-peer 1 como entrada (e aqui faria sentido você colocar o comando direct-inward-dial dentro da dial-peer); e toda chamada que entrar do CUCM vai bater na dial-peer 2 como entrada (e aqui faria sentido você definir os codecs).

Mas e se eu quiser forçar uma dial-peer de entrada que tem como destino um ramal específico para, por exemplo, chamar uma aplicação ao invés de mandar para o CUCM (sabe usamos isso, né? No MVA!). Aí eu poderia forçar assim:

dial-peer voice 4444 pots

 service mva   

 incoming called-number 4444

 no digit-strip

Ah, mas e se eu quero dar match na entrada usando o número de origem, e não de destino? Aí podemos usar o answer-address ou destination-pattern (embora esse último seja um pouco complicado, já que usaremos ele também para dial-peer de saída). Mas veja que o roteador só vai partir para essa análise caso a regra 1 não tenha sido atendida.
Caso a chamada entrante não dê match em nenhuma das 3 primeiras regras, o roteador vai analisar a voice port (isso se aplica somente a dial-peers pots). Então se você tem eventualmente uma dial-peer de saída apontando para port 0/0/0:0, e a chamada entrou por essa mesma porta, o roteador pode considerar essa dial-peer como a de entrada. Se houver mais que uma dial-peer apontando para a mesma voice-port, o critério de desempate vai ser a dial-peer adicionada primeiro na configuração.
E por fim, se nenhuma das 4 regras foi atendida, finalmente o roteador vai usar a dial-peer default do sistema que é a 0. Essa dial-peer não é vista na configuração, não é configurável, e portanto queremos evitá-la a todo custo!

A dica que dou é sempre usar o incoming called-number nas suas dial-peers de entrada (a não ser que um requisito maluco da prova te obrigue a usar o answer-address). É importante você ter bastante controle da sua entrada para eventualmente aplicar regras de translations nela (que falarei mais em um outro post), e também para você não cair em caso de codec mismatch e tal, especialmente quando for implementar CUBE, onde o conceito de match de dial-peer de entrada é fundamental.


Dial-Peer de Saída

A saída é bem mais fácil, pois o roteador utiliza um único comando para isso, que é o destination-pattern, velho conhecido de todos nós. E a saída é definida pelo comando port (no caso de dial-peer pots) ou session target (no caso de dial-peer voip).O que tem mais de interessante para falar nas dial-peers de saída é como os critérios de desempate são feitos.

A regra é que por default, quando um número destino da match em vários destination-patterns, de várias dial-peers, o critério de desempate é pelo match mais específico. Porém, temos duas situações aqui:

1. Quando a dial-peer de entrada é do tipo DID (quando colocamos o comando direct-inward-dial, presente apenas em dial-peers pots), a análise dos dígitos na saída é feita com o bloco inteiro dos números. Ou seja, se o roteador recebeu 32324444, ele vai analisar toda essa string de uma só vez. Logo, uma dial-peer com destination-pattern 32324444 vai dar match, enquanto uma dial-peer com destination-pattern 32324, por exemplo, não vai dar match. Esse caso se aplica, portanto, apenas nas chamadas entrantes da PSTN.

2. Quando a dial-peer de entrada não é do tipo DID, o roteador passa a analisar os números dígito a dígito na saída. Então se, por exemplo, o roteador receber os mesmos 32324444, agora na saída a dial-peer com destination-pattern 32324 dará match antes da dial-peer com destination-pattern 32324444, e logo será usada. E se houver uma terceira dial-peer com destination-pattern 32324..., ela também não será usada porque é menos específica que a 32324444 (aí sim entra o critério de desempate da mais específica).

Você pode também alterar a forma como o roteador faz o seu critério de desempate das dial-peers com o comando dial-peer hunt. O valor default é o 0, mas você pode configurar qualquer um dos 7 abaixo:

  0 - Longest match in phone number, explicit preference, random selection.
  1 - Longest match in phone number, explicit preference, least recent use.
  2 - Explicit preference, longest match in phone number, random selection.
  3 - Explicit preference, longest match in phone number, least recent use.
  4 - Least recent use, longest match in phone number, explicit preference.
  5 - Least recent use, explicit preference, longest match in phone number.
  6 - Random selection.
  7 - Least recent use.


Debugs úteis

Um dos melhores, aliás, o melhor debug para ver matching de dial-peer é o debug voip dialpeer. Mas outros comandos também são úteis:

debug voip dialpeer

show voice call status ! -- mostra a dial-peer de entrada e saída de cada chamada ativa no roteador

debug voice ccapi inout ! -- Mostra o match de entrada, saída, número de origem, destino, debug muito útil em qualquer situação. Só que ele gera muito output.

show dialplan number XXXXX ! -- onde XXXXX é o número de destino. Ele mostra em quais dial-peers a chamada dará match na saída. Ótimo para testar se a sua dial-peer está dando match.

show dial-peer voice summary ! -- mostra o tipo de hunt configurado e o resumo das dial-peers criadas

show run | sec dial-peer !-- Muito útil! Mostra o show run apenas das suas dial-peers