Conheci o Emanuel durante a minha jornada do CCIE. Trocamos muitos e-mails, ligações no Skype, GTalk, Facebook, e sem dúvida ele me ajudou muito na minha conquista. O Emanuel é o exemplo de garra, perseverança, do brasileiro que não desiste nunca, que não abaixa a cabeça diante de um resultado negativo da Cisco. Pelo contrário, se empenhava cada vez mais na conquista desse objetivo. Fiquei muito feliz no sábado quando eu vi o post dele no Facebook comemorando a certificação! Parabéns Emanuel, e bem-vindo de volta à vida! hahaha
################################################################################
Cara, eu não vou iniciar desde a primeira tentativa, pois todo mundo vai ficar cansado de ler. A minha última falha foi em Agosto, no dia 6. Fui com o meu amigo Victor Cavalcante (que continua na pegada do IE Voice), apesar de ter tocado em todos os tópicos do exame, não consegui passar. Eu já saí da Cisco sabendo que não tinha passado.
Então, fui mandado embora do emprego. Resolvi pegar a rescisão e o FGTS e focar 100% no CCIE. Recusei algumas propostas de emprego, pois sabia que não era a hora, e passei a estudar em um ritmo bacana, onde eu me condicionei a trabalhar 8 horas por dia, em dois intervalos de 4 horas. Isto foi essencial... No começo eu não conseguia terminar os simulados, mas chegando mais próximo ao exame eu estava conseguindo terminar os simulados da em 4, 5, e até 5 horas e meia.
Viajei... Cheguei muito baqueado. O fuso de 5 horas para frente é pesado. Reservei o primeiro dia para descansar e me acostumar com o fuso. No segundo dia, já fiz uma sessão via teamviewer no meu lab de casa. Não deu pra cronometrar legal, pois o lag era imenso. No terceiro dia (um dia antes do exame), comecei a estudar, mas comecei a pensar... Para que estudar agora? Se eu não estou preparado, não é agora que irei conseguir me preparar.... Fiquei jogando videogame a tarde inteira. Fui para o centro de Bruxelas, passeei um pouco. Voltei para o hotel cansado, e fui direto dormir.
Acordei as 4 da manhã. Ainda com jetlag da viagem. Apesar de ter passado dois dias, ainda não tinha me acostumado com o fuso. Tomei banho, tomei café, e fiquei aguardando a hora de ir para a Cisco jogando videogame (estava com o meu guerreiro PSP). Chegada a hora, fui caminhando até a Cisco. No caminho, vi um rapaz indo para a Cisco também, e mal sabia eu que era outro Brasileiro. Quando entramos, geralmente nos apresentamos para os outros candidatos, e foi quando o Henrique falou "Sou do Rio de Janeiro!", rachei o bico junto com ele. O Henrique estava em sua primeira tentativa, e eu já na quinta...
Fomos chamados então para o moedor. Estava completamente confortável! Sentei no meu pod, esperei o Proctor dar início, e começamos. Comecei a mentalizar que estava em casa, praticando para o lab para que eu não ficasse aperriado e mudasse de estratégia no começo do exame. Acreditem, o nervosismo faz com que você mude seus planos. Fui configurando tudo utilizando o método "Device Based Approach", onde configuramos um dispositivo por vez, na sua totalidade. Depois de configurar os três roteadores e o switch, olhei para o relógio e vi que só tinha passado 1 hora e 10 minutos. Fiquei feliz, mas me contive. Comecei a configurar o CUCM, e fui. Chegando no registro dos telefones, houve um problema com dois telefones que não se registravam. Ao invés de ficar nervoso, diagnostiquei rápido o problema, mas como não resolvi rápido, não deixei aquilo me quebrar. Utilizei um paleativo e coloquei no meu papel "CHECK PROBLEM XXXXX". Continuei na luta, com todos os telefones registrados (dois no modo em que não estava sendo pedido no exame, ou seja, perdendo pontos). Não me abalei, pois iria olhar aquilo no final. Fiz o Unity e o mesmo foi tranquilo, redondo. Sem nenhum problema. Passei então para o Presence e quando terminei de configurá-lo, o proctor nos chamara para almoçar. Neste momento, eu não me contive e estava sorrindo com o vento, com o papel que caia no chão, ou seja, com tudo.
No caminho para o almoço, o Proctor deixa claro que só podemos conversar em Inglês, e nada sobre o exame. Mas é claro que não fere em nada perguntar uns aos outros como estamos indo. Perguntei a alguns candidatos como eles estavam, e a maioria respondia que não estava bem, e só um de Routing e Switching estava tão alegre como eu estava. O Henrique estava preocupado, mas manteve a postura guerreira. Éramos os únicos Brasileiros fazendo prova de Voz! :)
Voltamos do almoço, testei o Presence, e tudo funcionou divinamente. Sem problemas! Passei pro UCCX, e esse também não demorou muito. Ao terminar o UCCX, testei e tudo também estava redondo. Nesta hora, olhei para o relógio, olhei para o quadro onde estava nosso horário de término do exame. Eu estava com 2 horas e 45 minutos. Fiquei muito feliz, mas mantive a postura de guerreiro. Neste momento falei para mim mesmo "Você ainda não conseguiu! Bora revisar, negão!" Comecei a revisão, e vi que ainda tinham umas coisinhas que deixei para trás. Acho que é isso que faz com que percamos todos os pontos e falhemos. Fui checando erros nas minhas show runs, mas nada muito grave. Depois da primeira checagem, ainda tinha uma 1 hora e 40 minutos. Não hesitei, e chequei TUDO novamente. Da primeira até a última questão, sem preguiça. Terminado a segunda checagem, ainda faltavam 50 minutos para o término do exame. Chequei tudo novamente! No fim da terceira checagem, ainda faltavam 15 minutos. Salvei tudo! Chamei o Proctor e falei "Você quer as questões assim e assado? Pois da última vez que estive aqui vocês me zeraram!" O Proctor respondeu como ele queria o output de certas questões, e eu fiz a questão ficar em conformidade com o que ele queria.
Quando o proctor deixou o meu pod, eu não contive mais a alegria. Mesmo sem o resultado, eu já sabia que tinha conseguido. Nesta hora, um candidato de CCIE Routing e Switching olhou para mim e eu estava sorrindo com o monitor. Então ele levantou sua mão e me mandou um "legal"! Respondi com um sorriso imenso!
Na saída, todo mundo pergunta como foi. Falei: "Se eu não for aprovado dessa vez, eu não sei o que a Cisco quer..." Mas o sentimento era de ter passado, de missão cumprida, mesmo sem ter o resultado. Ao sair da Cisco, começaram as "nóias", do tipo: "Meu Deus, será que fiz tudo certo", "Putz, esqueci de checar aquilo, será?". Foi então que pensei, Putz, se eu ficar pensando nisso, vou ficar doido! Saímos então da Cisco, e com um novo amigo ao lado, Henrique, fomos jantar no centro de Bruxelas, junto com um outro amigo que havia conhecido (Rafael, que não trabalha na área)!
No outro dia, dia de voltar para casa, resolvi ligar para minha mãe. Liguei, falei que sentia que tinha passado, mas não havia recebido o resultado ainda. Apenas pedi sua bênção pois estava indo para o aeroporto para voltar para o Brasil.
Como eu havia comprado um chip 3G lá, fiquei ligado na internet. Foi quando meu telefone avisou que tinha um e-mail. Pensei "Putz, bem que poderia ser o e-mail com o resultado". Quando abri a caixa de correio estava lá "Congratulations on becoming Cisco CCIE certified...". Minhas pernas cambalearam e eu tive que sentar... Liguei imediatamente para minha mãe e soltei um grito, PASSEI! A euforia era muito grande... Minha mãe pediu para eu me controlar.... kkkkkkk foi muito engraçado! Liguei também para minha esposa logo em seguida! Acordei todo mundo! Depois veio o sentimento de dever cumprido!!!
Depois de uma longa viagem de volta ao Brasil, cheguei hoje em SP (dia 20/10). Zoado de jetlag, sono, e fome, minha esposa foi me buscar, e ela me perguntou se eu queria dormir. Falei: "Não, vamos buscar a Zoey (nossa cachorrinha), e vamos para o Parque Villa Lobos!" A vida havia voltado ao normal!
É isso aí!! Agora eu posso jogar videogame sem remorso!!!!!!!!!!!!!!! :D
Emanuel Damasceno
################################################################################
segunda-feira, 21 de outubro de 2013
sábado, 19 de outubro de 2013
Horario de verão
É galera, chegamos a mais um fatídico terceiro domingo do mês de Outubro. E o que isso quer dizer para as pessoas que trabalham com TI no Brasil: Horário de Verão! Ê delícia... quantos finais de semana não tive que ficar trabalhando, vendo se os telefones iam subir com o horário certo, ou se teria que mudar o horário na mão. Era sempre aquele plantão que ninguém queria pegar.
Por causa disso, resolvi fazer um post totalmente off topic sobre o horário de verão no Brasil.
Afinal, tem como saber previamente se o meu CUCM vai mudar de horário na data certa ou não?
Sim! E é muito fácil!
Dê um SSH no seu CUCM e rode o comando:
Esse comando vai listar todos os time zones do CUCM, incluindo as informações do summer time, direto da base de dados. Para buscarmos apenas o de São Paulo, podemos filtrar pelo campo enum:
Esse será o output (cole num notepad, e desabilite o Word Wrap):
enum name description moniker bias stddate stdbias dstdate dstbias abbreviation legacyname
==== ================= ==================== ========================== ==== =================== ======= ==================== ======= ============ =======================================
17 America/Sao_Paulo (GMT-03:00) Brasilia TIMEZONE_AMERICA_SAO_PAULO 180 0/2/0/3,00:00:00:00 0 0/10/0/3,00:00:00:00 -60 BST E. South America Standard/Daylight Time
Por causa disso, resolvi fazer um post totalmente off topic sobre o horário de verão no Brasil.
Afinal, tem como saber previamente se o meu CUCM vai mudar de horário na data certa ou não?
Sim! E é muito fácil!
Dê um SSH no seu CUCM e rode o comando:
run sql select * from typetimezone
Esse comando vai listar todos os time zones do CUCM, incluindo as informações do summer time, direto da base de dados. Para buscarmos apenas o de São Paulo, podemos filtrar pelo campo enum:
run sql select * from typetimezone where enum=17
Esse será o output (cole num notepad, e desabilite o Word Wrap):
enum name description moniker bias stddate stdbias dstdate dstbias abbreviation legacyname
==== ================= ==================== ========================== ==== =================== ======= ==================== ======= ============ =======================================
17 America/Sao_Paulo (GMT-03:00) Brasilia TIMEZONE_AMERICA_SAO_PAULO 180 0/2/0/3,00:00:00:00 0 0/10/0/3,00:00:00:00 -60 BST E. South America Standard/Daylight Time
O importante aqui é vermos os campos stddate e dstdate, que informam, respectivamente, o dia/hora que acaba o horário de verão, e o dia/hora que inicia.
No caso acima, temos:
stddate = 0/2/0/3,00:00:00:00
dstdate = 0/10/0/3,00:00:00:00
Não tenho certeza sobre os dois primeiros 0s. Talvez indique o dia da semana, sendo 0 = domingo. Not sure... se alguém souber, comenta aí. Mas o importante (pelo menos no Brasil) são os valores em vermelho. O primeiro é o mês e o segundo é a semana. Ou seja, nesse caso acima, o horário de verão acabará no terceiro domingo de fevereiro e começará no terceiro domingo de outubro.
Assim você já pode de antemão saber se vai ter que alterar algo na mão ou não.
E para os voice gateways, eu sempre uso os seguintes comandos:
clock timezone BRST -3
clock summer-time BRDT recurring 3 Sun Oct 0:00 3 Sun Feb 0:00
Isso porque no Brasil o horário de verão sempre começa no terceiro domingo de Outubro e acaba no terceiro domingo de Fevereiro. Se não me engano, a fixação dessas datas é coisa recente, do governo Lula, acho. Enfim... mas o problema é que, pelo que eu li, se o terceiro domingo de Fevereiro cai no Carnaval, aí o horário de verão acaba no quarto domingo. Foda, né? Nesses casos você (ou o plantonista azarado) tem que ficar esperto, porque provavelmente vai ter que ajustar na mão.
Tá, mas e a prova?
Ok, mas isso não tem absolutamente NADA a ver com a prova, né? Não, não tem! hehehe...
Mas para a prova você precisa saber configurar o NTP nos gateways e servidores, e se preocupar com o horário de cada site. E aqui eu dou algumas dicas.
NTP todo mundo está careca de saber como se configura, né? Por exemplo, se o horário é PST -8, colocamos no roteador:
ntp server x.x.x.x
! NÃO coloque o NTP master, a não ser que o roteador tenha
! o clock local, sem puxar de uma fonte externa. Ao colocar
! o comando ntp server, o roteador já estará pronto para
! fornecer o horário para outro servidor. Não precisa do comando
! ntp master.
clock timezone PST -8
A dica que eu dou também é sempre configurar o summer-time. Eles descontam ponto se não configurar? Não sei... tem gente que especula que sim, e tem gente que diz que não. Mas é uma linha de comando, e não vale a pena corrermos o risco. Portanto:
clock summer-time PDT recurring
Se o horário do Site A é PST -8, quer dizer que o Date/Time Group desse site tem que estar certo (obvio), para os telefones aparecerem com o horário correto.
E o que mais? Isso, o horário dos usuários da Unity Connection, olha só! Muita gente esquece disso!!
E já que estamos considerando o horário dos subscribers na Unity, nada mais lógico do que configurar o NTP também nesse servidor, o que muita gente deixa de fazer (e não sei se perdem ponto ou não, mas é melhor pecar pelo excesso, né?)
Então é isso. Não me vá perder ponto de NTP por uma besteira, heim!
Além disso, lembre-se que a falta de sincronia de NTP do Publisher e Subscriber é a causa número 1 para problemas de replicação de base de dados.
Tá, mas e a prova?
Ok, mas isso não tem absolutamente NADA a ver com a prova, né? Não, não tem! hehehe...
Mas para a prova você precisa saber configurar o NTP nos gateways e servidores, e se preocupar com o horário de cada site. E aqui eu dou algumas dicas.
NTP todo mundo está careca de saber como se configura, né? Por exemplo, se o horário é PST -8, colocamos no roteador:
ntp server x.x.x.x
! NÃO coloque o NTP master, a não ser que o roteador tenha
! o clock local, sem puxar de uma fonte externa. Ao colocar
! o comando ntp server, o roteador já estará pronto para
! fornecer o horário para outro servidor. Não precisa do comando
! ntp master.
clock timezone PST -8
A dica que eu dou também é sempre configurar o summer-time. Eles descontam ponto se não configurar? Não sei... tem gente que especula que sim, e tem gente que diz que não. Mas é uma linha de comando, e não vale a pena corrermos o risco. Portanto:
clock summer-time PDT recurring
Se o horário do Site A é PST -8, quer dizer que o Date/Time Group desse site tem que estar certo (obvio), para os telefones aparecerem com o horário correto.
E o que mais? Isso, o horário dos usuários da Unity Connection, olha só! Muita gente esquece disso!!
E já que estamos considerando o horário dos subscribers na Unity, nada mais lógico do que configurar o NTP também nesse servidor, o que muita gente deixa de fazer (e não sei se perdem ponto ou não, mas é melhor pecar pelo excesso, né?)
Então é isso. Não me vá perder ponto de NTP por uma besteira, heim!
Além disso, lembre-se que a falta de sincronia de NTP do Publisher e Subscriber é a causa número 1 para problemas de replicação de base de dados.
Feliz início de horário de verão pra vocês!
sábado, 12 de outubro de 2013
Cluster em Mixed Mode
Já que o assunto da moda é a espionagem digital que os EUA andaram fazendo e tal, tive a ideia de começar a fazer uns posts sobre segurança. Até onde eu sei, não faz parte do blueprint atual do CCIE Voice, mas certamente é um conhecimento importante para qualquer profissional da área no dia-a-dia de projetos.
No primeiro post da série, vou mostrar como deixar o cluster em Mixed Mode, ou seja, habilitar a criptografia da sinalização e áudio nos telefones. É bem fácil de fazer, mas existe um pré-requisito, que é adquirir pelo menos dois tokens de segurança (part number KEY-CCM-ADMIN-K9=). Tendo isso, o resto é muito fácil. Vamos lá!
1. Primeiramente, você deve habilitar os serviços de CTL Provider e Certificate Authority Proxy Function (CAPF) no CUCM.
2. Feito isso, baixe do CUCM e instale no seu notebook o CTL Client. O caminho para baixar o plugin é indo em Applications >> Plugins. O notebook deve estar na rede para executar o programa, com o CUCM acessível.
3. Ao executar o CTL Client, insira o IP do Publisher, login e senha
4. Após a autenticação, a seguinte tela aparecerá. Escolha a opção "Set Cisco Unified CallManager Cluster to Mixed Mode"
5. O aplicativo pedirá para você inserir um Security Token. Faça isso e pressione OK. (obs: Insira apenas 1 dos tokens!)
6. As informações do Token serão exibidas. Pressione Add.
7. O programa vai coletar todos os certificados (CAPF, CCM e TFTP) dos servidores do cluster e exibir na tela, juntamente com o próprio Token, mostrando os certificados do CTL. Removi as informações do cliente no print screen abaixo:
8. Clique em Add Tokens para adicionar o seu segundo Token no CTL. O programa o alertará para remover o primeiro token antes de inserir o segundo:
9. As informações do segundo Token serão exibidas. Clique Add.
10. E o segundo token será adicionado ao CTL. Clique em Finish.
11. O programa vai pedir agora a senha do eToken. Você tem apenas 15 tentativas, e depois disso o Token é inutilizado. A senha default é Cisco123.
12. Com isso, a chave privada do eToken será utilizada para assinar o arquivo CTL, que será "upado" para cada servidor do cluster.
No primeiro post da série, vou mostrar como deixar o cluster em Mixed Mode, ou seja, habilitar a criptografia da sinalização e áudio nos telefones. É bem fácil de fazer, mas existe um pré-requisito, que é adquirir pelo menos dois tokens de segurança (part number KEY-CCM-ADMIN-K9=). Tendo isso, o resto é muito fácil. Vamos lá!
1. Primeiramente, você deve habilitar os serviços de CTL Provider e Certificate Authority Proxy Function (CAPF) no CUCM.
2. Feito isso, baixe do CUCM e instale no seu notebook o CTL Client. O caminho para baixar o plugin é indo em Applications >> Plugins. O notebook deve estar na rede para executar o programa, com o CUCM acessível.
4. Após a autenticação, a seguinte tela aparecerá. Escolha a opção "Set Cisco Unified CallManager Cluster to Mixed Mode"
5. O aplicativo pedirá para você inserir um Security Token. Faça isso e pressione OK. (obs: Insira apenas 1 dos tokens!)
6. As informações do Token serão exibidas. Pressione Add.
7. O programa vai coletar todos os certificados (CAPF, CCM e TFTP) dos servidores do cluster e exibir na tela, juntamente com o próprio Token, mostrando os certificados do CTL. Removi as informações do cliente no print screen abaixo:
8. Clique em Add Tokens para adicionar o seu segundo Token no CTL. O programa o alertará para remover o primeiro token antes de inserir o segundo:
9. As informações do segundo Token serão exibidas. Clique Add.
10. E o segundo token será adicionado ao CTL. Clique em Finish.
11. O programa vai pedir agora a senha do eToken. Você tem apenas 15 tentativas, e depois disso o Token é inutilizado. A senha default é Cisco123.
12. Com isso, a chave privada do eToken será utilizada para assinar o arquivo CTL, que será "upado" para cada servidor do cluster.
13. Reinicie os serviços de CallManager e TFTP (ou dê logo um boot no servidor, afinal, um bootzinho sempre vai bem, né! hehe)
14. Agora o seu cluster já está em Mixed Mode! Para habilitar a criptografia em um telefone, você deve criar um Security Profile (System >> Security >> Phone Security Profile), como abaixo, habilitando a criptografia:
15. Aplicar o profile no telefone, e configurar as opções de CAPF nele. Para os telefones novos, que já vem de fábrica com um certificado MIC, você pode usar a o método "Por certificado existente (prioridade para MIC)". Caso seja um telefone antigo, modelo 7940, 7960, você tem que usar o "By Authentication String", e aí é muito mais trabalhoso, pois você tem que ir telefone por telefone e digitar uma senha para ele poder baixar os certificados. Ou seja, para deployments grandes, é inviável! No exemplo, estou considerando um dos telefones de modelo mais recente.
16. Após o reset do telefone, você verá que o Certificate Operation Status está como Upgrade Sucess:
17. Agora se você fizer uma chamada com esse telefone, ele mostrará um desenho de cadeado na tela, indicando que a chamada está sendo criptografada.
18. Uma observação. Quando você deixa o Cluster em Mixed Mode, o Auto-Registration deixa de funcionar!
18. Uma observação. Quando você deixa o Cluster em Mixed Mode, o Auto-Registration deixa de funcionar!
Esse foi um post super simples. Tem diversas referências na Internet mostrando como se faz isso, e os guias da Cisco também são bem explicativos. Nos próximos posts da série de segurança, abordarei outros temas como SIP over TLS, Secure Conference Bridges, VG224, utilizando um Certificate Authority da empresa (e não os Self Signed do Call Manager). Esses são temas que eu pelo menos não encontrei nada muito explicativo na Internet. Até a próxima!
sexta-feira, 27 de setembro de 2013
Peterson Cristovam, CCIE #40728
Pessoal, com muita satisfação anuncio um novo CCIE Voice brasileiro. É o Peterson Cristovam, engenheiro de redes na PromonLogicalis. Pedi ao Peterson que escrevesse um pouquinho sobre ele e sobre a sua saga, e aqui está! Parabéns Peterson, e obrigado pelo depoimento! :)
################################################################################
"Perseverar significa continuar uma ação sem se importar com a oposição, desânimo ou fracasso anterior". Hitch. :)
Bruno, obrigado pelo convite.
Nem sei por onde começar. É dificil escrever sobre a gente, lembra aquelas entrevistas de emprego na qual lhe pedem para escrever sobre si.
Eu nasci no extremo leste da Zona Leste, no bairro do Itaim Paulista e la morei por 20 dos meus quase 33 anos.
Eu fiz o Curso Técnico-Profissionalizante de Processamento de Dados no Colégio Cruzeiro do Sul, em São Miguel Paulista, na época, para ter o diploma técnico desta área era necessário concluir 4 anos de curso. Nesta época eu gostava mais de programação. Depois fui pra Faculdade de Engenharia da Computação, na São Judas, repeti alguns anos, as mensalidades eram altas e faltava grana no final do mês, então parei, dei um tempo, mas sempre pensando em voltar. Um tempo depois pedi transferencia pra FASP, mesmo curso, cabendo no meu bolso, mas logo depois parei novamente por grana. Neste interim, entrei como funcionário concursado na Sabesp, na cidade de Itaquaquecetuba, Itaquá para os íntimos, como Praticante de escritório, ganhando uns 300 reais e poucos, se nao era o mínimo da época era bem próximo. Depois fui promovido a Auxiliar de Escritório, isto na carteira, pois sempre fazia os serviços de informática, me desenvolvi em programação, VB 6.0 e algumas brincadeiras no Access 97. Em um dado momento, pedi transferencia para área de cobrança da Sabesp, lá fiz alguns programas legais que ajudavam em nosso cotidiano. Alguns meses antes desta transferência, realizei um curso de SQL à noite, após o expediente. Em um dia deste curso, no intervalo, entrei na Internet e vi um anúncio do CIEE sobre o programa Cisco NetAcademy. Fiz a prova online, passei, e fui me apresentar, quando descobri que o curso era de 1 ano e meio, todas as segundas-feiras de manhã. Alinhei com minhas chefias, a reposição destas horas e comecei a cursar, toda segunda, lá no Itaim Bibi e depois ia correndo pra Itaquá e a noite ia pra faculdade. neste época eu já havia me transferido para a Unisantanna, mesmo curso, nesta finalmente consegui concluir e pegar meu CREA
Com o NetAcademy concluído, fiz a prova do CCNA, bombei por 2 pontos, fiz novamente e passei. Por esta empatia com a área de redes e por questões financeiras decidi largar a estabilidade do emprego público. Então, ao passar numa seleção em outra empresa, me desliguei da Sabesp. Fui trabalhar na Phonoway Soluções, uma empresa de telefonia, parceira Siemens, que estava entrando no mundo Cisco, lá a oportunidade de conhecer e aprender sobre PABX Siemens, além de colocar em prática meus conhecimentos de Cisco. Por esta empresa fiz alguns cursos de Cisco para certificação tanto da empresa quando minha. Lá eu poderia ter me tornardo um CCVP na época, mas não era o que eu almejava. Ter a certificação Professional é diferente de ser um profissional com tal qualificação e eu não me sentia um "CCVP" na época pois não tinha tanto tempo de mão-na-massa. Da Phonoway, fui para a Telsinc Informática, lá tive outros grandes desafios e depois de um certo tempo de experiência e suor decidi fazer as provas faltantes do CCVP pois já me sentia um profissional com o conhecimento para tal. Também na Telsinc, fiz minha primeira tentativa no CCIE-V no final de 2010 e falhei. Um tempo depois sai da Telsinc e fui para a PromonLogicalis. Lá tentei mais 2 vezes a prova e novamente não passei. Depois do leite derramado, percebo que hoje, não faria a segunda e terceira tentativa. pois não tive o tempo adequado de preparo, mas agora já é tarde Inês é morta.
Então depois de quase 3 anos da primeira tentativa, tentei uma última vez, pois agora, a prova irá mudar de versão e desta vez, diferentemente das outras vezes, além de casado, já tenho filho e já vem mais um herdeiro pela frente. Quem já fez a prova ou procurou na internet, já percebeu que esta prova não afeta só você, afeta tudo ao seu redor, você vê menos seus parentes, seus amigos, e deixa um pouco em "segundo plano" sua esposa e filhos, isto mexe muito com você e com todos à volta.
Nesta última vez, após vários F5 na página da Cisco vi o resultado que eu havia passado. Ufa. A sensação é muito boa, de alívio, mas não somente por ter passado na prova, por ter perseverado ou por ter recebido um número, mas sim de você poder olhar para trás e vê o que você fez, as decisões, escolhas e as apostas, enfim um conjunto de coisas ter valido a pena. Me lembro lá nos anos 90, na época de colégio que havia uma coleção de revistas da InfoExame sobre certificações, falava além de outras das Certificações Cisco, dos seus profissionais e empresas, me lembro de ter dito a mim mesmo, eu vou trabalhar nesta área e vou tirar o CCIE. Tenho comigo Bruno, um pensamento de Max Heindel: "Só existe um fracasso, deixar de lutar"
Amplexos
Peterson
################################################################################
"Perseverar significa continuar uma ação sem se importar com a oposição, desânimo ou fracasso anterior". Hitch. :)
Bruno, obrigado pelo convite.
Nem sei por onde começar. É dificil escrever sobre a gente, lembra aquelas entrevistas de emprego na qual lhe pedem para escrever sobre si.
Eu nasci no extremo leste da Zona Leste, no bairro do Itaim Paulista e la morei por 20 dos meus quase 33 anos.
Eu fiz o Curso Técnico-Profissionalizante de Processamento de Dados no Colégio Cruzeiro do Sul, em São Miguel Paulista, na época, para ter o diploma técnico desta área era necessário concluir 4 anos de curso. Nesta época eu gostava mais de programação. Depois fui pra Faculdade de Engenharia da Computação, na São Judas, repeti alguns anos, as mensalidades eram altas e faltava grana no final do mês, então parei, dei um tempo, mas sempre pensando em voltar. Um tempo depois pedi transferencia pra FASP, mesmo curso, cabendo no meu bolso, mas logo depois parei novamente por grana. Neste interim, entrei como funcionário concursado na Sabesp, na cidade de Itaquaquecetuba, Itaquá para os íntimos, como Praticante de escritório, ganhando uns 300 reais e poucos, se nao era o mínimo da época era bem próximo. Depois fui promovido a Auxiliar de Escritório, isto na carteira, pois sempre fazia os serviços de informática, me desenvolvi em programação, VB 6.0 e algumas brincadeiras no Access 97. Em um dado momento, pedi transferencia para área de cobrança da Sabesp, lá fiz alguns programas legais que ajudavam em nosso cotidiano. Alguns meses antes desta transferência, realizei um curso de SQL à noite, após o expediente. Em um dia deste curso, no intervalo, entrei na Internet e vi um anúncio do CIEE sobre o programa Cisco NetAcademy. Fiz a prova online, passei, e fui me apresentar, quando descobri que o curso era de 1 ano e meio, todas as segundas-feiras de manhã. Alinhei com minhas chefias, a reposição destas horas e comecei a cursar, toda segunda, lá no Itaim Bibi e depois ia correndo pra Itaquá e a noite ia pra faculdade. neste época eu já havia me transferido para a Unisantanna, mesmo curso, nesta finalmente consegui concluir e pegar meu CREA
Com o NetAcademy concluído, fiz a prova do CCNA, bombei por 2 pontos, fiz novamente e passei. Por esta empatia com a área de redes e por questões financeiras decidi largar a estabilidade do emprego público. Então, ao passar numa seleção em outra empresa, me desliguei da Sabesp. Fui trabalhar na Phonoway Soluções, uma empresa de telefonia, parceira Siemens, que estava entrando no mundo Cisco, lá a oportunidade de conhecer e aprender sobre PABX Siemens, além de colocar em prática meus conhecimentos de Cisco. Por esta empresa fiz alguns cursos de Cisco para certificação tanto da empresa quando minha. Lá eu poderia ter me tornardo um CCVP na época, mas não era o que eu almejava. Ter a certificação Professional é diferente de ser um profissional com tal qualificação e eu não me sentia um "CCVP" na época pois não tinha tanto tempo de mão-na-massa. Da Phonoway, fui para a Telsinc Informática, lá tive outros grandes desafios e depois de um certo tempo de experiência e suor decidi fazer as provas faltantes do CCVP pois já me sentia um profissional com o conhecimento para tal. Também na Telsinc, fiz minha primeira tentativa no CCIE-V no final de 2010 e falhei. Um tempo depois sai da Telsinc e fui para a PromonLogicalis. Lá tentei mais 2 vezes a prova e novamente não passei. Depois do leite derramado, percebo que hoje, não faria a segunda e terceira tentativa. pois não tive o tempo adequado de preparo, mas agora já é tarde Inês é morta.
Então depois de quase 3 anos da primeira tentativa, tentei uma última vez, pois agora, a prova irá mudar de versão e desta vez, diferentemente das outras vezes, além de casado, já tenho filho e já vem mais um herdeiro pela frente. Quem já fez a prova ou procurou na internet, já percebeu que esta prova não afeta só você, afeta tudo ao seu redor, você vê menos seus parentes, seus amigos, e deixa um pouco em "segundo plano" sua esposa e filhos, isto mexe muito com você e com todos à volta.
Nesta última vez, após vários F5 na página da Cisco vi o resultado que eu havia passado. Ufa. A sensação é muito boa, de alívio, mas não somente por ter passado na prova, por ter perseverado ou por ter recebido um número, mas sim de você poder olhar para trás e vê o que você fez, as decisões, escolhas e as apostas, enfim um conjunto de coisas ter valido a pena. Me lembro lá nos anos 90, na época de colégio que havia uma coleção de revistas da InfoExame sobre certificações, falava além de outras das Certificações Cisco, dos seus profissionais e empresas, me lembro de ter dito a mim mesmo, eu vou trabalhar nesta área e vou tirar o CCIE. Tenho comigo Bruno, um pensamento de Max Heindel: "Só existe um fracasso, deixar de lutar"
Amplexos
Peterson
################################################################################
sábado, 7 de setembro de 2013
IPPA (IP Phone Agent)
O IPPA (IP Phone Agent) é uma aplicação que roda no IP Phone, e é uma ferramenta bastante útil na prova, principalmente se as suas questões de CCX precisarem de agentes e filas. Isso porque provavelmente não vai ter um CAD (Cisco Agent Desktop) lá para você colocar um agente em Ready/Not Ready para atender a fila.
Esse serviço funciona como o CAD: o agente pode fazer o Login/Logout, mudar seu status para Ready/Not Ready, ver estatísticas da fila, etc. Tudo através da tela do telefone. É super importante que você saiba como configurar, e principalmente, onde pegar as referências para essa configuração. Afinal, como veremos adiante, você precisa configurar um Phone Service com uma URL, e não faz sentido você decorá-la.
1. Configuração do End User
Depois de você ter o CUCM e o CCX integrados, a primeira coisa que devemos fazer é configurar um usuário como Agente do Contact Center. Para isso, basta entrarmos na configuração do End User, e preencher o campo IPCC Extension:
Aqui cabe uma observação: Como os labs trabalham com Snapshots de VMWare, pode acontecer de o seu CCX estar integrado, mas o campo IPCC Extension não existir. Isso ocorria comigo às vezes nos labs da IP Expert. Se isso acontecer, vale a pena saber como resolver.
Entre na página de documentações da Cisco, que você terá acesso no lab, e navegue em:
Busque por "Extension", e ache o link ICD Extension Option Does Not Appear on the Cisco CallManager Global Directory User Page. Dentro do documento, faça uma busca por "run sql", e você encontrará o seguinte comando para ser executado na CLI do Publisher:
2. Configurando o IPPA
Para configurar o IPPA, entre na página de documentações da Cisco, que você terá acesso no lab, e navegue em:
Busque por "Login", e ache o link Configure a "One Button Login" for IP Phone Agents. Esse link tem o procedimento para configurar o IPPA Normal, e o IPPA com One Button Login, que falarei mais pra frente. Para configurar o IPPA normal, basta criar um novo Phone Service no CUCM: Device >> Device Settings >> Phone Services, da seguinte forma:
A Service URL você pode encontrar no documento acima, no capítulo Procedure. Essa URL é:
http://xxx.xxx.xxx.xxx:yyyy/ipphone/jsp/sciphonexml/IPAgentInitial.jsp
Depois de associar o serviço no telefone, você poderá vê-lo dentre os serviços do aparelho. Ao ingressar a aplicação, ela pedirá o login, ramal e senha. Assim como também é pedido no CAD:
3. Configurando o One-Button Login
Para evitar de o usuário ter que digitar essas informações (que convenhamos, é bem trabalhosa usando o teclado do telefone), podemos configurar o One-Button Login, onde o usuário, ao ingressar o serviço, já é logado diretamente na aplicação, sem ter que inputar esses dados. O procedimento para isso está no mesmo documento. Procure por "AgentLogin", e ache a URL abaixo:
http://xxx.xxx.xxx.xx:yyyy/ipphone/jsp/sciphonexml/IPAgentLogin.jsp
O IP e porta seguem as mesmas regras acima. IP do CCX e porta 6293.
Crie o serviço exatamente como o procedimento do IPPA normal, mas usando essa outra URL.
E agora precisaremos criar três parâmetros nessa aplicação, que serão: Ext, Pwd e ID. Clique em New Parameter, e configure os parâmetros conforme abaixo (da mesma forma para as 3):
O serviço ficará assim:
Agora quando o usuário entrar nesse serviço, ele já fará o login automaticamente, sem a necessidade de entrar o ramal, usuário e senha.
Esse serviço funciona como o CAD: o agente pode fazer o Login/Logout, mudar seu status para Ready/Not Ready, ver estatísticas da fila, etc. Tudo através da tela do telefone. É super importante que você saiba como configurar, e principalmente, onde pegar as referências para essa configuração. Afinal, como veremos adiante, você precisa configurar um Phone Service com uma URL, e não faz sentido você decorá-la.
1. Configuração do End User
Depois de você ter o CUCM e o CCX integrados, a primeira coisa que devemos fazer é configurar um usuário como Agente do Contact Center. Para isso, basta entrarmos na configuração do End User, e preencher o campo IPCC Extension:
Aqui cabe uma observação: Como os labs trabalham com Snapshots de VMWare, pode acontecer de o seu CCX estar integrado, mas o campo IPCC Extension não existir. Isso ocorria comigo às vezes nos labs da IP Expert. Se isso acontecer, vale a pena saber como resolver.
Entre na página de documentações da Cisco, que você terá acesso no lab, e navegue em:
Products >> Voice and Unified Communications >> Customer Collaboration >> Cisco Unified Contact Center Products >> Cisco Unified Contact Center Express >> Configuration Examples and TechNotes
Busque por "Extension", e ache o link ICD Extension Option Does Not Appear on the Cisco CallManager Global Directory User Page. Dentro do documento, faça uma busca por "run sql", e você encontrará o seguinte comando para ser executado na CLI do Publisher:
run sql update processconfig set paramvalue="T" where paramname like 'IAQInstalledFlag'
2. Configurando o IPPA
Products >> Voice and Unified Communications >> Customer Collaboration >> Cisco Unified Contact Center Products >> Cisco Unified Contact Center Express >> Configuration Examples and TechNotes
Busque por "Login", e ache o link Configure a "One Button Login" for IP Phone Agents. Esse link tem o procedimento para configurar o IPPA Normal, e o IPPA com One Button Login, que falarei mais pra frente. Para configurar o IPPA normal, basta criar um novo Phone Service no CUCM: Device >> Device Settings >> Phone Services, da seguinte forma:
http://xxx.xxx.xxx.xxx:yyyy/ipphone/jsp/sciphonexml/IPAgentInitial.jsp
Onde xxx.xxx.xxx.xxx é o IP do CCX e yyyy é a porta, que no caso do IPCC Express, é a 6293.Depois de associar o serviço no telefone, você poderá vê-lo dentre os serviços do aparelho. Ao ingressar a aplicação, ela pedirá o login, ramal e senha. Assim como também é pedido no CAD:
3. Configurando o One-Button Login
Para evitar de o usuário ter que digitar essas informações (que convenhamos, é bem trabalhosa usando o teclado do telefone), podemos configurar o One-Button Login, onde o usuário, ao ingressar o serviço, já é logado diretamente na aplicação, sem ter que inputar esses dados. O procedimento para isso está no mesmo documento. Procure por "AgentLogin", e ache a URL abaixo:
http://xxx.xxx.xxx.xx:yyyy/ipphone/jsp/sciphonexml/IPAgentLogin.jsp
O IP e porta seguem as mesmas regras acima. IP do CCX e porta 6293.
Crie o serviço exatamente como o procedimento do IPPA normal, mas usando essa outra URL.
E agora precisaremos criar três parâmetros nessa aplicação, que serão: Ext, Pwd e ID. Clique em New Parameter, e configure os parâmetros conforme abaixo (da mesma forma para as 3):
O serviço ficará assim:
Agora basta fazermos o Subscribe do serviço no telefone. Mas veja que teremos alguns campos para preencher:
Agora quando o usuário entrar nesse serviço, ele já fará o login automaticamente, sem a necessidade de entrar o ramal, usuário e senha.
segunda-feira, 2 de setembro de 2013
Gravando áudio para os seus prompts
Uma das coisas que a prova pode te pedir em uma questão de CCX é a personalização de um fluxo de atendimento. E consequentemente, você terá que gravar algum áudio (sim, com a sua lindíssima voz falando em inglês). Existem algumas formas de você fazer isso, como por exemplo, criando um Call Handler na Unity, e editando o greeting através de um telefone (através daquela interface Java horrível, que só da pau). Mas a mais fácil e rápida para mim é pelo próprio UCCX. Vamos ver como!
Primeiramente, abra o CCX Script Editor. Crie apenas uma variável do tipo Document chamada rec:
E depois disso, crie o seu script assim:
Isso mesmo. Simples assim!
Lembre-se que os steps Accept e Terminate estão dentro do menu Contact, e via de regra, todo script seu deve começar com um Accept e terminar com um Terminate. E o Recording está dentro de Media.
Ao configurar o Recording, você deve basicamente escolher qual será a variável de destino da gravação e colocar em Result Document:
E recomendo mudar o Duration para 30 segundos, na aba Filter, no caso de você ter que gravar um prompt muito grande:
Feito isso, crie uma nova Application referenciando o seu script e configure um Trigger qualquer para ela (obviamente, que não dê conflito com o seu Dial Plan):
Agora basta pegar o seu telefone e ligar para o Trigger. Você ouvirá um beep, e depois disso o áudio já estará sendo gravado. Ao terminar, entre na pasta C:\Program Files\wfavvid\temp do IPCC, e o arquivo WAV estará lá. Ele vai salvar 2 arquivos... o que tiver tamanho maior é o que deve ser usado:
Renomeie o arquivo e ele já estará pronto para ser "uppado" nos prompts para ser usado em outra aplicação. Dessa forma, você não vai gastar nem 3 minutos para gravar um áudio personalizado.
Dicas da vida real
Na vida real evitamos usar esse tipo de mecanismo, pois ao gravar um áudio para um Call Center, a pessoa pode depois processar a empresa exigindo direitos de uso sobre a voz e tal. Ouvi dizer... não sei se é verdade. Em todo caso, recomenda-se a utilização de empresas ou softwares especializados para isso. Se quiser fazer um teste, recomendo o demo do Loquendo, que é free e bastante bom! Se você souber de algum outro, poste nos comentários!
E para edição de áudio, tem um ótimo programa (free) chamado GoldWave. Uma das coisas boas que ele faz é converter qualquer arquivo de áudio para o padrão utilizado pelos produtos da Cisco (CUCM MoH, CCX, Unity Connection). É só abrir o áudio com esse programa, e salvar como Wave, uLaw, 8000 Hz, 64 kbps, mono:
Primeiramente, abra o CCX Script Editor. Crie apenas uma variável do tipo Document chamada rec:
E depois disso, crie o seu script assim:
Isso mesmo. Simples assim!
Lembre-se que os steps Accept e Terminate estão dentro do menu Contact, e via de regra, todo script seu deve começar com um Accept e terminar com um Terminate. E o Recording está dentro de Media.
Ao configurar o Recording, você deve basicamente escolher qual será a variável de destino da gravação e colocar em Result Document:
E recomendo mudar o Duration para 30 segundos, na aba Filter, no caso de você ter que gravar um prompt muito grande:
Feito isso, crie uma nova Application referenciando o seu script e configure um Trigger qualquer para ela (obviamente, que não dê conflito com o seu Dial Plan):
Agora basta pegar o seu telefone e ligar para o Trigger. Você ouvirá um beep, e depois disso o áudio já estará sendo gravado. Ao terminar, entre na pasta C:\Program Files\wfavvid\temp do IPCC, e o arquivo WAV estará lá. Ele vai salvar 2 arquivos... o que tiver tamanho maior é o que deve ser usado:
Renomeie o arquivo e ele já estará pronto para ser "uppado" nos prompts para ser usado em outra aplicação. Dessa forma, você não vai gastar nem 3 minutos para gravar um áudio personalizado.
Dicas da vida real
Na vida real evitamos usar esse tipo de mecanismo, pois ao gravar um áudio para um Call Center, a pessoa pode depois processar a empresa exigindo direitos de uso sobre a voz e tal. Ouvi dizer... não sei se é verdade. Em todo caso, recomenda-se a utilização de empresas ou softwares especializados para isso. Se quiser fazer um teste, recomendo o demo do Loquendo, que é free e bastante bom! Se você souber de algum outro, poste nos comentários!
E para edição de áudio, tem um ótimo programa (free) chamado GoldWave. Uma das coisas boas que ele faz é converter qualquer arquivo de áudio para o padrão utilizado pelos produtos da Cisco (CUCM MoH, CCX, Unity Connection). É só abrir o áudio com esse programa, e salvar como Wave, uLaw, 8000 Hz, 64 kbps, mono:
quinta-feira, 15 de agosto de 2013
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:
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:
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:
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.
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.
Assinar:
Postagens (Atom)