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.
sábado, 22 de dezembro de 2012
sábado, 1 de dezembro de 2012
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:
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
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
domingo, 18 de novembro de 2012
Captura de pacotes (CUCM | Voice Gateway | IP Phone)
A novidade do dia é que mudei a cor do blog, e aumentei a largura do quadro de postagens, acatando sugestões que recebi. Realmente, acredito que a tela branca seja menos cansativa para leitura. Embora o conteúdo não ajude muito! hehehe
Semana retrasada participei de um evento do TAC da Cisco, e a engenheira Michelle Jardim (primeira CCIE Voice que eu conheço que passou na primeira tentativa) nos apresentou algumas formas de fazer capturas de pacotes no CUCM e no Router, para serem analisados em um Wireshark da vida. Eu já precisei fazer essas capturas várias vezes nos meus troubleshootings, e quem não sabe o procedimento, sugiro que leia. Capturas de pacotes são ótimas para troubleshootings, especialmente naqueles que você tem que provar por A + B para o cliente que o CUCM ou gateway não está recebendo determinados pacotes, colocando a culpa no cara de redes/firewall! hahaha... Geralmente esse pessoal não confia muito nos traces do CUCM, mas quando você mostra no Wireshark, aí não tem erro! hehehehe
Outra situação bem comum de utilizar isso é em troubleshooting de One-Way Audio ou No Audio, para saber onde os RTPs estão parando.
Lógico, esse post não se aplica muito ao exame do CCIE Voice em si. Afinal, se você estiver na prova e tiver que fazer um troubleshooting desse nível, é porque tem alguma coisa muito errada nos seus métodos! hahaha... mas certamente um dia você vai precisar na vida real.
1. Captura no CUCM
O jeito mais fácil de fazer capturas no CUCM é simplesmente capturar tudo que passa pela interface. Isso é feito via CLI através do comando:
Com esse comando, o CUCM vai armazenar no arquivo capture.cap tudo o que passar pela interface eth0. Para parar a captura, aperte Ctrl C. Então, para rodar essa captura, execute o comando via SSH, reproduza o problema e depois pare com o Ctrl C.
Para listar os arquivos de capturas disponíveis no servidor, utilize:
Ele vai listar todos os arquivos do diretório, mostrando a data de criação. Escolha o arquivo desejado e faça o download dele via SFTP com o comando
O software que costumo usar como SFTP Server é o FreeFTPd (http://www.freesshd.com/freeFTPd.exe). Ele é free (como vocês já devem ter percebido), e o melhor que tem... mas cuidado ao utilizá-lo como ferramenta de backup do CUCM, porque existem alguns bugs conhecidos e a Cisco não o recomenda mais para essa finalidade. Mas para baixar coisas do CUCM via CLI, é perfeito.
2. Captura no IOS
Para capturar pacotes em uma interface do roteador, defina um profile de captura, por exemplo:
E aplique na interface desejada:
3. Captura no telefone
Bom, no telefone é de boa, né? Você tem que espetar o seu notebook com um Wireshark na PC Port do IP Phone, e habilitar a opção Span to PC Port do telefone em questão. Com isso, o telefone vai espelhar todo o tráfego para o PC, que vai coletar os pacotes.
E pronto. Agora temos a captura no IP Phone, CUCM e Gateway, ou seja, o caminho completo. Aí é só abrir os arquivos no Wireshark e fazer as suas análises.
Semana retrasada participei de um evento do TAC da Cisco, e a engenheira Michelle Jardim (primeira CCIE Voice que eu conheço que passou na primeira tentativa) nos apresentou algumas formas de fazer capturas de pacotes no CUCM e no Router, para serem analisados em um Wireshark da vida. Eu já precisei fazer essas capturas várias vezes nos meus troubleshootings, e quem não sabe o procedimento, sugiro que leia. Capturas de pacotes são ótimas para troubleshootings, especialmente naqueles que você tem que provar por A + B para o cliente que o CUCM ou gateway não está recebendo determinados pacotes, colocando a culpa no cara de redes/firewall! hahaha... Geralmente esse pessoal não confia muito nos traces do CUCM, mas quando você mostra no Wireshark, aí não tem erro! hehehehe
Outra situação bem comum de utilizar isso é em troubleshooting de One-Way Audio ou No Audio, para saber onde os RTPs estão parando.
Lógico, esse post não se aplica muito ao exame do CCIE Voice em si. Afinal, se você estiver na prova e tiver que fazer um troubleshooting desse nível, é porque tem alguma coisa muito errada nos seus métodos! hahaha... mas certamente um dia você vai precisar na vida real.
1. Captura no CUCM
O jeito mais fácil de fazer capturas no CUCM é simplesmente capturar tudo que passa pela interface. Isso é feito via CLI através do comando:
utils network capture eth0 file capture count 100000 size all
Com esse comando, o CUCM vai armazenar no arquivo capture.cap tudo o que passar pela interface eth0. Para parar a captura, aperte Ctrl C. Então, para rodar essa captura, execute o comando via SSH, reproduza o problema e depois pare com o Ctrl C.
Para listar os arquivos de capturas disponíveis no servidor, utilize:
file list activelog platform/cli detail
Ele vai listar todos os arquivos do diretório, mostrando a data de criação. Escolha o arquivo desejado e faça o download dele via SFTP com o comando
file get activelog platform/cli/capture.cap
O software que costumo usar como SFTP Server é o FreeFTPd (http://www.freesshd.com/freeFTPd.exe). Ele é free (como vocês já devem ter percebido), e o melhor que tem... mas cuidado ao utilizá-lo como ferramenta de backup do CUCM, porque existem alguns bugs conhecidos e a Cisco não o recomenda mais para essa finalidade. Mas para baixar coisas do CUCM via CLI, é perfeito.
2. Captura no IOS
Para capturar pacotes em uma interface do roteador, defina um profile de captura, por exemplo:
ip traffic-export profile test mode capture
bidirectional
length 512
E aplique na interface desejada:
interface fa 0/0Antes de começar a captura, recomenda-se limpar o buffer:
ip traffic-export apply test size 2000000
traffic-export interface fa 0/0 clearInicie a captura com o comando (no modo enable):
traffic-export interface fa 0/0 startApós reproduzir o problema, pare parar a captura com o comando:
traffic-export interface fa 0/0 stopAgora é só exportá-la via TFTP ou FTP:
traffic-export interface fa 0/0 copy tftp:
Address or name of remote host []? X.X.X.X
Capture buffer filename []? cisco.cap
3. Captura no telefone
Bom, no telefone é de boa, né? Você tem que espetar o seu notebook com um Wireshark na PC Port do IP Phone, e habilitar a opção Span to PC Port do telefone em questão. Com isso, o telefone vai espelhar todo o tráfego para o PC, que vai coletar os pacotes.
E pronto. Agora temos a captura no IP Phone, CUCM e Gateway, ou seja, o caminho completo. Aí é só abrir os arquivos no Wireshark e fazer as suas análises.
sexta-feira, 2 de novembro de 2012
Missão: CCIE Voice
Como prometi no post anterior, vou comentar um pouco sobre como foi a minha preparação para o CCIE. Quando eu estava começando, lia blogs e blogs sobre pessoas postando as suas experiencias, estratégias, métodos de estudo. E é exatamente o que farei agora. E o primeiro conselho que dou é: não siga as estratégias alheias! hehehe
Então o que vou escrever aqui não necessariamente se aplica a você. Leia sim posts sobre pessoas relatando a sua saga, mas não tome uma como um caminho ideal a seguir, mas sim pegue o melhor de cada uma para montar o seu próprio caminho. Cada pessoa é cada pessoa, e você tem que descobrir como é a sua melhor forma de trilhar o percurso, conciliando trabalho, vida pessoal e estudo.
Senta que lá vem história . . .
Bom, antes de começar o CCIE, você tem que ter ciência se vai poder terminá-lo. Não adianta nada comprar equipamentos e materiais de estudo, no impulso do momento, sendo que não vai ter tempo de estudar, não vai querer se sacrificar um pouco, e principalmente, não vai ter grana.
O material é caro, e mais caro que isso são as tentativas. Estime mais ou menos 7 mil reais por tentativa (1.500 dolares da prova, 1.500 dolares da passagem e uns 500 dolares com gastos de hotel, alimentação e taxi, sem muito luxo). E saiba que as chances de passar na primeira são virtualmente 0. Claro, pode ser que você seja uma exceção, mas não conte com isso ao estimar os seus gastos. A média de aprovação no CCIE Voice, se não me engano, é de 3,6 tentativas. Então tenha dinheiro para pelo menos umas 3 ou 4 (21 a 28k reais). Se passar de primeira ou segunda, lucro seu, e você vai lá se acabar na Best Buy quando passar! hehehe
Quanto aos materiais de estudo, eu usei os da IP Expert. Recomendo que ache um parceiro de estudo para rachar, senão fica muito caro (não me lembro o valor, e deve ter mudado também). E caso você não tenha um lab completo em casa, vai precisar de alugar lab remoto na ProctorLabs (ou outra empresa). Apesar do custo alto, recomendo que alugue o rack, e não passe muito tempo tentando montar o seu completo. Cada sessão de 8 horas custa 25 dolares (mas fique de olho nas promoções que eles lançam toda hora). No meu caso, usei cerca de 70 sessões. Para o lab remoto você vai precisar de ter pelo menos 3 telefones 7965/7970/7975 (de preferência 4, mas se não conseguir, pode usar 1 IP Communicator), 1 telefone 7960 para a PSTN, 1 switch PoE e um roteador para fechar a VPN (a lista de modelos suportados estão no site da Proctor Labs. Mas num adianta pegar um pau véio 2600 que num vai rolar).
Por isso que um apoio da empresa é sempre muito bem vindo... bancar o CCIE do próprio bolso é insano! Então a primeira coisa que você deve fazer quando decidir entrar nessa é ver no que a sua empresa pode te ajudar (inclusive com tempo de estudo, senão também num adianta nada).
Com a grana reservada, diposição para se sacrificar e tempo, é hora de começar! Eu comecei a minha jornada em Dezembro do ano passado, aproveitando que o movimento no trabalho estava mais tranquilo. Nas horas que conseguia, ficava assistindo aos vídeos do Internetwork Expert (acho que foi o único material do INE que eu usei, pois eu tinha uma conta que havia rachado com uns amigos). Os vídeos foram um ótimo começo para mim... bem tranquilo, estudava quando dava, onde dava, sem muita pressão. Quando tinha um tempo, me aprofundava em alguns tópicos lendo os Guides da Cisco ou fazendo testes nas minhas VMs em casa... E comecei a escutar no carro também os Audio on Demand da IP Expert, da ex-instrutora Amy Ryan. Esses áudios são bem tranquilos de ouvir, bem fáceis de entender, e você acaba aproveitando um tempo que seria morto, como no trânsito. E a voz dela é bem agradável também! hehe
Isso durou mais ou menos dois meses. Nesse meio tempo eu comecei a escrever esse blog, o que foi muito bom para mim. Durante os estudos com os vídeos/guides, eu costumava tomar muita nota em um caderno. Foi aí que eu tive a ideia de começar a passar algumas dessas notas para o blog. Recomendo! Quando você escreve em blog, apesar de tomar muito do seu tempo, você é obrigado a pesquisar um pouco melhor aquilo, fazer uns testes para ver se o que você tá falando está certo, e me ajudou a fixar melhor alguns conceitos, como os de QoS, que foram os primeiros posts e nunca mais esqueci.
Ao término dos vídeos, acho que no final de janeiro, me bateu um certo desespero, porque tive que sair da zona de conforto e começar a pegar mais firme. Porque até então, assistir uns videozinhos com o cara explicando tudo para você é muito fácil! hehehe... Comecei então a estudar o Volume 1 dos Workbooks da IP Expert. Esse volume 1 são vários labs curtos, fáceis, e que dão mais a base de todo o negócio. Mas percebi que mais importante que praticar os labs, era você entender o conceito por trás de cada questão. Nesse momento, você não tem que se preocupar com estratégia de prova, velocidade e tal. Precisa entender o negócio. Mas entender mesmo, de cabo a rabo. Então o volume 1 serve mais como um guia de estudo... você tem que saber fazê-lo, mas a cada capítulo, você tem que se aprofundar mais no assunto. Um exemplo: Lab de gatekeeper. Não basta você configurar o gatekeeper e fazer 2 sites se falarem... tem que pensar: "ah, mas e se eu configurar 2 zones diferentes? e se eu fizer com uma zone só usando tech-prefix? e se eu usar VIA zone? E se eu configurar assim, como fica o meu output do sh gatekeeper endpoints? E se eu usar VIA, como fica o sh gatekeeper calls? Mas por que eu vejo 2 call legs?". Entende? É muito mais do que resolver uma questão. Então eu estudava o volume 1 junto com guides da Cisco, e no final eu não fiz nem se quer uma sessão de lab para esse workbook. Eu respondia tudo escrevendo mesmo, escrevendo script no caderno e tal. No máximo simulava alguma coisa no meu lab em casa, usando VMWare e GSN3, por exemplo os labs de RSVP, que eu nunca tinha configurado.
Ah, um detalhe importante sobre guides. Muitos dizem que você tem que ler o SRND e decorá-lo de ponta a ponta. Eu não concordo... você tem que ter uma noção do que tem nele e tal, mas eu não cheguei a ler o SRND. O que eu li de cabo a rabo, e recomendo fortemente é o feature guide do CUCM e o admin guide do CME. Esse último em especial é muito bom que leia e teste tudo, porque tem umas coisas de CME que eu pelo menos nunca nem tinha ouvido falar.
Bom, essa minha luta com o Volume 1 foi até maio, ou seja, 3 a 4 meses. Acho que foi o período que eu mais aprendi coisas novas, e que, consequentemente, o estudo mais fluiu. Nessa fase você fica super empolgado, eu ficava até de madrugada estudando (porque gosto mais de estudar a noite), finais de semana, feriados... e aí em Maio, quando acabei de estudar o volume 1 e todos os itens do Blueprint, e tirei 1 semana de "férias", e viajei para Fortaleza com a minha namorada! hehehe... dar aquela relaxada! =P
Voltei de lá na pegada de começar o Volume 2. A essa altura, eu já tinha marcado o meu Bootcamp para Julho, e a minha prova para Setembro. Eu sabia que tinha 2 meses para o bootcamp, e nesses 2 meses eu precisaria destruir o Volume 2, para chegar preparado no curso. Nessa época a Dimension Data me ajudou bastante, me dando todas as sextas-feiras livres para estudar. Então foram 2 meses estudando de sexta, sábado e domingo, e mais alguns dias de folga que acabei pegando. Até o dia 1 de julho eu tinha feito cada um dos 10 labs do volume 2 pelo menos 2 ou 3 vezes. Eu costumava dar uma lida em 2 labs durante a semana (de segunda a quinta), e sexta, sábado e domingo eu fazia eles. A cada lab eu ía aprendendo coisas novas, e procurava também me aprofundar em alguns pontos (se necessário) ao longo da semana seguinte. Foram 2 meses super intensos e cansativos. Mas eu ficava satisfeito quando conseguia terminar o lab dentro da sessão de 7h45min da ProctorLabs.O objetivo maior do Volume 2, para mim, é você definir uma estratégia sua. Tem gente que recomenda usar o Device-Based Approach (procure no youtube, vale a pena), tem gente que acha melhor fazer por tecnologia. Eu fiz meio que uma mescla dos dois... mas acho que estratégia é um ponto muito pessoal, e cada um tem que bolar a sua. Num existe uma receita de bolo. A Device-Based approach acho que é a mais eficiente mesmo, mas eu pelo menos não consigo fazer a prova usando ela. Tem gente que consegue... então depende muito.
Até que chegou Julho e eu fui para San Jose, fazer o Bootcamp. Posso dizer que o que mais me ajudou para a prova foi esse Bootcamp. Lá você fica 2 semanas completamente imerso naquilo, sendo instruído por um cara muito, muito foda que é o Vik Malhi. Aprendendo formas muito mais rápidas de configurar as coisas e tal. Na primeira semana do curso foi mais teoria, e a segunda era só lab. Se você pensa em fazer esse curso, aconselho que vá tecnicamente preparado... você tem que ir já com um conhecimento muito bom de cada vírgula do blueprint. Isso porque o instrutor não vai te pegar na mão e ensinar a configurar um Device Pool, por exemplo... ele vai te falar como é a forma mais rápida de configurar o Device Pool sem ter que resetar os telefones. Saca? É muito mais focado na prova em si.
Depois do Bootcamp eu peguei 1 mês de férias (mês de agosto inteiro) para estudar. Aí eu marquei labs de segunda a sábado, e descansava domingo. Confesso que na metade do mês já estava pedindo água! hahaha... não conseguia mais ver um Call Mananager na frente!!! hehehe... Tinha dia que eu começava a sessão e simplesmente não conseguia fazer nada, não conseguia mais pensar naquilo... Aí eu parava, dava uma descansada e depois retomava. Ou largava mão de fazer lab aquele dia, e estudava algum item do blueprint, ou fazia alguns testes de troubleshooting.
Chegando no dia da prova, num fatídico 6 de Setembro, estava muito nervoso. Em RTP a prova começa às 7h15, e o candidato deve chegar umas 7h. Então acordei às 5h para sair às 6h, e não consegui pregar os olhos antes das 3h! haha... Cheguei lá bem cansado, e isso me deu um certo desespero. Na entrada, quando os candidatos ficam sentados no sofá esperando o Proctor, fica um silêncio mortal, e esse momento acho que é o pior do dia. Ainda bem que fui com um amigo, e ficamos conversando, o que me ajudou a relaxar um pouco. O proctor David chegou, passou um briefing do dia, e começamos o lab. A adrenalina era tanta que o sono nem pesou. Então se você for e não conseguir dormir um dia antes, não se preocupe... você definitivamente não vai sentir sono e não vai estar menos concentrado por causa disso! hehehe
No lab eu senti algumas dificuldades. Por exemplo, o terminal que eles te disponibilizam não faz copy/paste com o botão direito do mouse, como no Putty. O atalho Windows + D para exibir o Desktop não funciona... então essas pequenas coisinhas que você está acostumado no seu home lab acabam atrapalhando. E outra coisa é o endereçamento IP, que é diferente dos labs da ProctorLabs também... mas de resto, o lab foi tranquilo. Não ocorreu nenhum bug na minha prova, e consegui terminar ela com bastante tempo para revisar. Saí de lá com a impressão que havia passado. Porém, no dia seguinte recebi o resultado e FAIL. Até hoje não sei exatamente onde perdi tantos pontos na prova...
Isso é bastante desanimador. Não tanto por não passar, mas sim por ter que voltar ao Brasil e começar tuuudo denovo. Chegando aqui, marquei a segunda tentativa para a data mais próxima que consegui, no dia 23 de outubro. E fiquei 2 semanas sem estudar absolutamente nada. Depois comecei a fazer uns labs nos finais de semana. Só nas duas semanas que antecederam a prova que a Dimension Data novamente me deu vários dias de folga, e pude ficar 14 dias estudando direto, para retomar a velocidade.
Embarquei para os EUA no dia 21, descansei dia 22 e fiz a prova no dia 23. Novamente, não consegui dormir muito bem na noite anterior, mas isso não me preocupou muito porque sabia que não me atrapalharia no exame. E foi a mesma coisa. Acordei cedo. Silêncio mortal. Proctor. E a prova começou. Dessa vez fiz o lab mais tranquilo... eu sabia que o Windows + D num ía funcionar, e que o jeito certo de dar copy/paste era com o Shift + Insert. Já sabia o esquema de endereçamento IP, já sabia como a prova era estruturada, como vinham as tabelas. Então nesse sentido, a segunda tentativa foi bem mais tranquila. Terminei a prova agora com a certeza que tinha passado... mas ainda assim estava receoso, porque você nunca sabe como a sua prova será corrigida.
Voltei para o hotel acabado de cansado. É engraçado porque quando você termina a prova, parece que tomou uma surra daquelas... fica com o corpo todo dolorido. Até as minhas pernas doíam como se eu tivesse corrido quilometros! Bem estranho... Mas nesse dia dormi cedão. E no dia seguinte fiquei no hotel a manhã toda apertando F5, esperando o resultado da prova! Passou 9h, 10h, 11h e nada, e foi batendo o desespero. Até que às 11h10 chegou o e-mail, e o meu coração foi parar no teto. Mas a minha cabeça soh explodiu mesmo quando vi o resultado de que havia passado!
É esse o momento mais foda, que você sente um peso gigantesco saindo das suas costas, e uma sensação de alívio absurda. É esse momento que te faz pensar que todo o sacrifício valeu a pena.
Se você está pensando seriamente em tirar o CCIE, e viu que tem condições e vontade de ir até o fim, cara... vá em frente! Vai que no final vale a pena!
Boa sorte!
Então o que vou escrever aqui não necessariamente se aplica a você. Leia sim posts sobre pessoas relatando a sua saga, mas não tome uma como um caminho ideal a seguir, mas sim pegue o melhor de cada uma para montar o seu próprio caminho. Cada pessoa é cada pessoa, e você tem que descobrir como é a sua melhor forma de trilhar o percurso, conciliando trabalho, vida pessoal e estudo.
Senta que lá vem história . . .
Bom, antes de começar o CCIE, você tem que ter ciência se vai poder terminá-lo. Não adianta nada comprar equipamentos e materiais de estudo, no impulso do momento, sendo que não vai ter tempo de estudar, não vai querer se sacrificar um pouco, e principalmente, não vai ter grana.
O material é caro, e mais caro que isso são as tentativas. Estime mais ou menos 7 mil reais por tentativa (1.500 dolares da prova, 1.500 dolares da passagem e uns 500 dolares com gastos de hotel, alimentação e taxi, sem muito luxo). E saiba que as chances de passar na primeira são virtualmente 0. Claro, pode ser que você seja uma exceção, mas não conte com isso ao estimar os seus gastos. A média de aprovação no CCIE Voice, se não me engano, é de 3,6 tentativas. Então tenha dinheiro para pelo menos umas 3 ou 4 (21 a 28k reais). Se passar de primeira ou segunda, lucro seu, e você vai lá se acabar na Best Buy quando passar! hehehe
Quanto aos materiais de estudo, eu usei os da IP Expert. Recomendo que ache um parceiro de estudo para rachar, senão fica muito caro (não me lembro o valor, e deve ter mudado também). E caso você não tenha um lab completo em casa, vai precisar de alugar lab remoto na ProctorLabs (ou outra empresa). Apesar do custo alto, recomendo que alugue o rack, e não passe muito tempo tentando montar o seu completo. Cada sessão de 8 horas custa 25 dolares (mas fique de olho nas promoções que eles lançam toda hora). No meu caso, usei cerca de 70 sessões. Para o lab remoto você vai precisar de ter pelo menos 3 telefones 7965/7970/7975 (de preferência 4, mas se não conseguir, pode usar 1 IP Communicator), 1 telefone 7960 para a PSTN, 1 switch PoE e um roteador para fechar a VPN (a lista de modelos suportados estão no site da Proctor Labs. Mas num adianta pegar um pau véio 2600 que num vai rolar).
Por isso que um apoio da empresa é sempre muito bem vindo... bancar o CCIE do próprio bolso é insano! Então a primeira coisa que você deve fazer quando decidir entrar nessa é ver no que a sua empresa pode te ajudar (inclusive com tempo de estudo, senão também num adianta nada).
Com a grana reservada, diposição para se sacrificar e tempo, é hora de começar! Eu comecei a minha jornada em Dezembro do ano passado, aproveitando que o movimento no trabalho estava mais tranquilo. Nas horas que conseguia, ficava assistindo aos vídeos do Internetwork Expert (acho que foi o único material do INE que eu usei, pois eu tinha uma conta que havia rachado com uns amigos). Os vídeos foram um ótimo começo para mim... bem tranquilo, estudava quando dava, onde dava, sem muita pressão. Quando tinha um tempo, me aprofundava em alguns tópicos lendo os Guides da Cisco ou fazendo testes nas minhas VMs em casa... E comecei a escutar no carro também os Audio on Demand da IP Expert, da ex-instrutora Amy Ryan. Esses áudios são bem tranquilos de ouvir, bem fáceis de entender, e você acaba aproveitando um tempo que seria morto, como no trânsito. E a voz dela é bem agradável também! hehe
Isso durou mais ou menos dois meses. Nesse meio tempo eu comecei a escrever esse blog, o que foi muito bom para mim. Durante os estudos com os vídeos/guides, eu costumava tomar muita nota em um caderno. Foi aí que eu tive a ideia de começar a passar algumas dessas notas para o blog. Recomendo! Quando você escreve em blog, apesar de tomar muito do seu tempo, você é obrigado a pesquisar um pouco melhor aquilo, fazer uns testes para ver se o que você tá falando está certo, e me ajudou a fixar melhor alguns conceitos, como os de QoS, que foram os primeiros posts e nunca mais esqueci.
Ao término dos vídeos, acho que no final de janeiro, me bateu um certo desespero, porque tive que sair da zona de conforto e começar a pegar mais firme. Porque até então, assistir uns videozinhos com o cara explicando tudo para você é muito fácil! hehehe... Comecei então a estudar o Volume 1 dos Workbooks da IP Expert. Esse volume 1 são vários labs curtos, fáceis, e que dão mais a base de todo o negócio. Mas percebi que mais importante que praticar os labs, era você entender o conceito por trás de cada questão. Nesse momento, você não tem que se preocupar com estratégia de prova, velocidade e tal. Precisa entender o negócio. Mas entender mesmo, de cabo a rabo. Então o volume 1 serve mais como um guia de estudo... você tem que saber fazê-lo, mas a cada capítulo, você tem que se aprofundar mais no assunto. Um exemplo: Lab de gatekeeper. Não basta você configurar o gatekeeper e fazer 2 sites se falarem... tem que pensar: "ah, mas e se eu configurar 2 zones diferentes? e se eu fizer com uma zone só usando tech-prefix? e se eu usar VIA zone? E se eu configurar assim, como fica o meu output do sh gatekeeper endpoints? E se eu usar VIA, como fica o sh gatekeeper calls? Mas por que eu vejo 2 call legs?". Entende? É muito mais do que resolver uma questão. Então eu estudava o volume 1 junto com guides da Cisco, e no final eu não fiz nem se quer uma sessão de lab para esse workbook. Eu respondia tudo escrevendo mesmo, escrevendo script no caderno e tal. No máximo simulava alguma coisa no meu lab em casa, usando VMWare e GSN3, por exemplo os labs de RSVP, que eu nunca tinha configurado.
Ah, um detalhe importante sobre guides. Muitos dizem que você tem que ler o SRND e decorá-lo de ponta a ponta. Eu não concordo... você tem que ter uma noção do que tem nele e tal, mas eu não cheguei a ler o SRND. O que eu li de cabo a rabo, e recomendo fortemente é o feature guide do CUCM e o admin guide do CME. Esse último em especial é muito bom que leia e teste tudo, porque tem umas coisas de CME que eu pelo menos nunca nem tinha ouvido falar.
Bom, essa minha luta com o Volume 1 foi até maio, ou seja, 3 a 4 meses. Acho que foi o período que eu mais aprendi coisas novas, e que, consequentemente, o estudo mais fluiu. Nessa fase você fica super empolgado, eu ficava até de madrugada estudando (porque gosto mais de estudar a noite), finais de semana, feriados... e aí em Maio, quando acabei de estudar o volume 1 e todos os itens do Blueprint, e tirei 1 semana de "férias", e viajei para Fortaleza com a minha namorada! hehehe... dar aquela relaxada! =P
Voltei de lá na pegada de começar o Volume 2. A essa altura, eu já tinha marcado o meu Bootcamp para Julho, e a minha prova para Setembro. Eu sabia que tinha 2 meses para o bootcamp, e nesses 2 meses eu precisaria destruir o Volume 2, para chegar preparado no curso. Nessa época a Dimension Data me ajudou bastante, me dando todas as sextas-feiras livres para estudar. Então foram 2 meses estudando de sexta, sábado e domingo, e mais alguns dias de folga que acabei pegando. Até o dia 1 de julho eu tinha feito cada um dos 10 labs do volume 2 pelo menos 2 ou 3 vezes. Eu costumava dar uma lida em 2 labs durante a semana (de segunda a quinta), e sexta, sábado e domingo eu fazia eles. A cada lab eu ía aprendendo coisas novas, e procurava também me aprofundar em alguns pontos (se necessário) ao longo da semana seguinte. Foram 2 meses super intensos e cansativos. Mas eu ficava satisfeito quando conseguia terminar o lab dentro da sessão de 7h45min da ProctorLabs.O objetivo maior do Volume 2, para mim, é você definir uma estratégia sua. Tem gente que recomenda usar o Device-Based Approach (procure no youtube, vale a pena), tem gente que acha melhor fazer por tecnologia. Eu fiz meio que uma mescla dos dois... mas acho que estratégia é um ponto muito pessoal, e cada um tem que bolar a sua. Num existe uma receita de bolo. A Device-Based approach acho que é a mais eficiente mesmo, mas eu pelo menos não consigo fazer a prova usando ela. Tem gente que consegue... então depende muito.
Até que chegou Julho e eu fui para San Jose, fazer o Bootcamp. Posso dizer que o que mais me ajudou para a prova foi esse Bootcamp. Lá você fica 2 semanas completamente imerso naquilo, sendo instruído por um cara muito, muito foda que é o Vik Malhi. Aprendendo formas muito mais rápidas de configurar as coisas e tal. Na primeira semana do curso foi mais teoria, e a segunda era só lab. Se você pensa em fazer esse curso, aconselho que vá tecnicamente preparado... você tem que ir já com um conhecimento muito bom de cada vírgula do blueprint. Isso porque o instrutor não vai te pegar na mão e ensinar a configurar um Device Pool, por exemplo... ele vai te falar como é a forma mais rápida de configurar o Device Pool sem ter que resetar os telefones. Saca? É muito mais focado na prova em si.
Depois do Bootcamp eu peguei 1 mês de férias (mês de agosto inteiro) para estudar. Aí eu marquei labs de segunda a sábado, e descansava domingo. Confesso que na metade do mês já estava pedindo água! hahaha... não conseguia mais ver um Call Mananager na frente!!! hehehe... Tinha dia que eu começava a sessão e simplesmente não conseguia fazer nada, não conseguia mais pensar naquilo... Aí eu parava, dava uma descansada e depois retomava. Ou largava mão de fazer lab aquele dia, e estudava algum item do blueprint, ou fazia alguns testes de troubleshooting.
Chegando no dia da prova, num fatídico 6 de Setembro, estava muito nervoso. Em RTP a prova começa às 7h15, e o candidato deve chegar umas 7h. Então acordei às 5h para sair às 6h, e não consegui pregar os olhos antes das 3h! haha... Cheguei lá bem cansado, e isso me deu um certo desespero. Na entrada, quando os candidatos ficam sentados no sofá esperando o Proctor, fica um silêncio mortal, e esse momento acho que é o pior do dia. Ainda bem que fui com um amigo, e ficamos conversando, o que me ajudou a relaxar um pouco. O proctor David chegou, passou um briefing do dia, e começamos o lab. A adrenalina era tanta que o sono nem pesou. Então se você for e não conseguir dormir um dia antes, não se preocupe... você definitivamente não vai sentir sono e não vai estar menos concentrado por causa disso! hehehe
No lab eu senti algumas dificuldades. Por exemplo, o terminal que eles te disponibilizam não faz copy/paste com o botão direito do mouse, como no Putty. O atalho Windows + D para exibir o Desktop não funciona... então essas pequenas coisinhas que você está acostumado no seu home lab acabam atrapalhando. E outra coisa é o endereçamento IP, que é diferente dos labs da ProctorLabs também... mas de resto, o lab foi tranquilo. Não ocorreu nenhum bug na minha prova, e consegui terminar ela com bastante tempo para revisar. Saí de lá com a impressão que havia passado. Porém, no dia seguinte recebi o resultado e FAIL. Até hoje não sei exatamente onde perdi tantos pontos na prova...
Isso é bastante desanimador. Não tanto por não passar, mas sim por ter que voltar ao Brasil e começar tuuudo denovo. Chegando aqui, marquei a segunda tentativa para a data mais próxima que consegui, no dia 23 de outubro. E fiquei 2 semanas sem estudar absolutamente nada. Depois comecei a fazer uns labs nos finais de semana. Só nas duas semanas que antecederam a prova que a Dimension Data novamente me deu vários dias de folga, e pude ficar 14 dias estudando direto, para retomar a velocidade.
Embarquei para os EUA no dia 21, descansei dia 22 e fiz a prova no dia 23. Novamente, não consegui dormir muito bem na noite anterior, mas isso não me preocupou muito porque sabia que não me atrapalharia no exame. E foi a mesma coisa. Acordei cedo. Silêncio mortal. Proctor. E a prova começou. Dessa vez fiz o lab mais tranquilo... eu sabia que o Windows + D num ía funcionar, e que o jeito certo de dar copy/paste era com o Shift + Insert. Já sabia o esquema de endereçamento IP, já sabia como a prova era estruturada, como vinham as tabelas. Então nesse sentido, a segunda tentativa foi bem mais tranquila. Terminei a prova agora com a certeza que tinha passado... mas ainda assim estava receoso, porque você nunca sabe como a sua prova será corrigida.
Voltei para o hotel acabado de cansado. É engraçado porque quando você termina a prova, parece que tomou uma surra daquelas... fica com o corpo todo dolorido. Até as minhas pernas doíam como se eu tivesse corrido quilometros! Bem estranho... Mas nesse dia dormi cedão. E no dia seguinte fiquei no hotel a manhã toda apertando F5, esperando o resultado da prova! Passou 9h, 10h, 11h e nada, e foi batendo o desespero. Até que às 11h10 chegou o e-mail, e o meu coração foi parar no teto. Mas a minha cabeça soh explodiu mesmo quando vi o resultado de que havia passado!
É esse o momento mais foda, que você sente um peso gigantesco saindo das suas costas, e uma sensação de alívio absurda. É esse momento que te faz pensar que todo o sacrifício valeu a pena.
Se você está pensando seriamente em tirar o CCIE, e viu que tem condições e vontade de ir até o fim, cara... vá em frente! Vai que no final vale a pena!
Boa sorte!
quinta-feira, 25 de outubro de 2012
CCIE Voice #37170
Após quase 1 ano de muito estudo, mais de 500 horas de lab, 2 semanas de BootCamp e guides lidos e relidos, finalmente completo essa jornada do CCIE Voice. Fiz a prova no dia 23 e recebi ontem a notícia de que havia sido aprovado. É um momento único, uma sensação indescritível de alívio e missão cumprida. Só quem já passou por isso mesmo para saber!
Não posso deixar de compartilhar aqui no blog o ocorrido, e agradecer a todos pela torcida. Nesse post não vou falar sobre a prova em si, mas sim agradecer as pessoas importantes que fizeram parte disso. Depois faço um outro post falando mais da prova e da minha preparação. Obviamente, não quebrarei nada do NDA (non disclosure agreement).
O CCIE não é um projeto que você conduz sozinho. Quando você decide se dedicar para essa certificação, deve ter consciência que se sacrificará muito por isso. E não só você se sacrificará, mas as pessoas com quem convive. Você vai privar muito do seu tempo que passaria com esposa/namorada, filhos, familiares e amigos para ficar dias trancado num lab durante 8 horas, muitas vezes sem nem almoçar/jantar. Vai passar finais de semanas inteiros estudando (muitos!), ou mesmo vai tirar 30 dias de férias para ficar todos os 30 dias focado (como foi o meu caso). Vai também tirar dias de folga do trabalho para estudar, sobrecarregando o time. Então, é necessário realmente muito apoio e compreensão das pessoas que te rodeiam.
Por isso, primeiramente, gostaria de agradecer a minha namorada, que me apoiou desde o começo e entendeu a importancia disso para a minha vida. Certamente, sem o apoio e compreensão dela, não teria tido forças para ir até o fim. Acredito que ela tenha sido quem mais sofreu com a minha ausência. Agradeço também aos familiares, ao meu pai, irmã, cunhado (também CCIE), ... por todas as não-idas a eventos familiares.
Agradeço os meus colegas de trabalho, principalmente os meus chefes, por conseguirem aprovar o custeio de todo o processo, e por me darem tempo para estudar. A Dimension Data realmente foi uma mãe!!! Poucas empresas fariam isso por seus funcionários, sendo que ela nem precisa de um novo CCIE na companhia, por conta da auditoria da Cisco (é claro que para uma integradora, quanto mais melhor). E agradeço muito o pessoal da área que seguraram as pontas fodamente enquanto o bonitão aqui ficava estudando! ehauehauehaue
Agradeço os clientes, um em especial que me emprestou um roteador para que eu pudesse estudar! Roteador este que foi fundamental para que eu pudesse utilizar o lab remoto da Proctor Labs. E aos demais clientes (todos!) por sempre estarem torcendo por mim e me incentivando.
Ao pessoal que se preparou para a prova junto comigo (ainda que alguns nem consigam ler essa mensagem em Português! hahaha!), ao Vik Malhi, instrutor da IP Expert (FODA!). Aos leitores do blog, que para a minha surpresa, descobri que eram muitos! Bom, não muuuuitos, mas mais do que eu imaginava. E a todos os amigos que fizeram parte desse projeto.
E finalmente agradeço a minha mãe, que infelizmente não está mais aqui para presenciar esse momento, mas certamente estaria bastante orgulhosa do filho. E orgulhosa de si mesma, por ter quase que me obrigado a fazer um tal cursinho de Net Academy para uma tal certificação de uma tal empresa chamada Cisco em meados de 2002. Quem diria que isso iria me levar tão longe! hahaha
É isso aí galera, agora é relaxar e voltar a vida normal. Amanhã, ou hoje, ou algum outro dia eu posto mais sobre a minha preparação. Pretendo continuar com o blog, porém não mais focado na prova em si... espero que o que eu tenha postado até hoje ajude alguém no seu CCIE.
Valeu!!
Bruno Nonogaki, CCIE #37170
Não posso deixar de compartilhar aqui no blog o ocorrido, e agradecer a todos pela torcida. Nesse post não vou falar sobre a prova em si, mas sim agradecer as pessoas importantes que fizeram parte disso. Depois faço um outro post falando mais da prova e da minha preparação. Obviamente, não quebrarei nada do NDA (non disclosure agreement).
O CCIE não é um projeto que você conduz sozinho. Quando você decide se dedicar para essa certificação, deve ter consciência que se sacrificará muito por isso. E não só você se sacrificará, mas as pessoas com quem convive. Você vai privar muito do seu tempo que passaria com esposa/namorada, filhos, familiares e amigos para ficar dias trancado num lab durante 8 horas, muitas vezes sem nem almoçar/jantar. Vai passar finais de semanas inteiros estudando (muitos!), ou mesmo vai tirar 30 dias de férias para ficar todos os 30 dias focado (como foi o meu caso). Vai também tirar dias de folga do trabalho para estudar, sobrecarregando o time. Então, é necessário realmente muito apoio e compreensão das pessoas que te rodeiam.
Por isso, primeiramente, gostaria de agradecer a minha namorada, que me apoiou desde o começo e entendeu a importancia disso para a minha vida. Certamente, sem o apoio e compreensão dela, não teria tido forças para ir até o fim. Acredito que ela tenha sido quem mais sofreu com a minha ausência. Agradeço também aos familiares, ao meu pai, irmã, cunhado (também CCIE), ... por todas as não-idas a eventos familiares.
Agradeço os meus colegas de trabalho, principalmente os meus chefes, por conseguirem aprovar o custeio de todo o processo, e por me darem tempo para estudar. A Dimension Data realmente foi uma mãe!!! Poucas empresas fariam isso por seus funcionários, sendo que ela nem precisa de um novo CCIE na companhia, por conta da auditoria da Cisco (é claro que para uma integradora, quanto mais melhor). E agradeço muito o pessoal da área que seguraram as pontas fodamente enquanto o bonitão aqui ficava estudando! ehauehauehaue
Agradeço os clientes, um em especial que me emprestou um roteador para que eu pudesse estudar! Roteador este que foi fundamental para que eu pudesse utilizar o lab remoto da Proctor Labs. E aos demais clientes (todos!) por sempre estarem torcendo por mim e me incentivando.
Ao pessoal que se preparou para a prova junto comigo (ainda que alguns nem consigam ler essa mensagem em Português! hahaha!), ao Vik Malhi, instrutor da IP Expert (FODA!). Aos leitores do blog, que para a minha surpresa, descobri que eram muitos! Bom, não muuuuitos, mas mais do que eu imaginava. E a todos os amigos que fizeram parte desse projeto.
E finalmente agradeço a minha mãe, que infelizmente não está mais aqui para presenciar esse momento, mas certamente estaria bastante orgulhosa do filho. E orgulhosa de si mesma, por ter quase que me obrigado a fazer um tal cursinho de Net Academy para uma tal certificação de uma tal empresa chamada Cisco em meados de 2002. Quem diria que isso iria me levar tão longe! hahaha
É isso aí galera, agora é relaxar e voltar a vida normal. Amanhã, ou hoje, ou algum outro dia eu posto mais sobre a minha preparação. Pretendo continuar com o blog, porém não mais focado na prova em si... espero que o que eu tenha postado até hoje ajude alguém no seu CCIE.
Valeu!!
Bruno Nonogaki, CCIE #37170
quinta-feira, 11 de outubro de 2012
Hunt Groups no CUCM
Vamos hoje a um post mais tranquilo, que será sobre os Hunt Groups no CUCM. Configurar o basicão todo mundo sabe, né? Line Group, Hunt List e Hunt Pilot. Mas existem algumas configurações um pouco mais complexas, que podem ser aplicadas na vida real, tornando os Hunt Groups mais funcionais.
Então, fazendo a configuração do zero, temos:
1. Line Group
A primeira coisa a ser criada é um Line Group. Nele, vamos associar todas as linhas que fazem parte de um grupo. Mas nessa tela, podemos configurar algumas outras coisas:
- RNA Reversion Timeout: É o tempo que o ramal do grupo ficará tocando até que passe para o próximo membro. Ou seja, no hunt group, o sistema não respeita a configuração de "No answer ring duration" do ramal.
- Distribution Algorithm: Algoritmo que o CUCM vai usar para fazer o hunt entre os ramais do grupo. Pode ser top down (respeitando a ordem na lista, sempre começando pelo primeiro), circular (respeitando a ordem na lista, começando de onde parou), longest idle (CUCM entrega a chamada para o usuário que estiver livre há mais tempo), broadcast (todo mundo toca ao mesmo tempo)
- Hunt options (no answer, busy, not available): Aqui podemos definir algumas regras para quando um usuário não atender ou estiver ocupado. Por padrão, o CUCM vai tentar o próximo da lista (baseado no algoritmo de distribuição) até que acabe as opções dentro do Line Group, e depois vai passar para o próximo Line Group dentro da mesma Hunt List. Mas podemos deixar com que as opções fiquem limitadas a apenas os ramais desse Line Group, sem transbordar para o outro. Podemos também forçar o CUCM a parar de procurar o próximo ramal dentro desse Line Group e pular para o seguinte, ou podemos falar para o CUCM parar de tentar rotear a chamada para um próximo membro, e retornar como ocupado.
Obs: No caso do algoritmo Longest Idle, nunca vai acontecer de cair no caso Busy ou Not Available, porque o sistema já sabe quando ele não está disponível para atender a chamada, e tira ele das opções possíveis.
2. Hunt List
Agora configuramos uma Hunt List, e associamos um ou mais Line Groups. A ordem dos Line Groups dentro de uma Hunt List é importante para o caso de uma chamada ter que transbordar de um Line Group para outro (explicado acima, na opção Hunt options do Line Group).
3. Hunt Pilot
E finalmente configuramos o Hunt Pilot, que será o número piloto do grupo, e associamos a uma Hunt List. É aqui que algumas configurações confundem as pessoas, mais especificamente as configurações de "Hunt Forward Settings".
Nessa tela, podemos configurar o que o sistema vai fazer quando ninguém do grupo atender (no answer ou busy). Nesses casos, as configurações de forward dos ramais do grupo não tem efeito nenhum, pois é o que estiver configurado no Hunt Pilot que será usado.
Podemos encaminhar a chamada para o voice mail, ou desviar um outro número. Portanto, no campo Destination, colocamos esse número destino (se for para o voice mail, colocamos o número do voice mail pilot). E obviamente, configuramos uma CSS com as devidas permissões.
Agora, quando a chamada for desviada para o voice mail pilot, o que acontece? O CUCM vai mandar para a Unity como se o próprio hunt pilot tivesse desviado a chamada. Em outras palavras, a Unity vai buscar na base dela o número desse hunt pilot. Mas provavelmente o piloto não tem nenhum voice mail configurado, certo? Aí você vai cair no Greeting inicial da Unity. Para que você caia no voice mail de algum usuário, você deve cadastrar o Hunt Pilot como Alternate Extension de um usuário na Unity Connection, e pronto.
Nesse quadro também, temos a opção de desvio "Use Personal Preferences". Isso vai servir quando tivermos um ramal desviando as suas chamadas para o Hunt Pilot. Aí nesse caso, se ninguém no hunt group atender, e essa opção estiver marcada, a chamada vai ser desviada para o que tiver configurado no Forward No Coverage do ramal.
4. HLog
Com a softkey HLog, podemos fazer com que um ramal consiga logar ou deslogar de um Hunt Group. Assim, quando ele quiser entrar/sair do atendimento, ele só precisa apertar esse botão. Não precisa do Extension Mobility, e muito menos pedir pro usuário desligar o telefone dele! hahaha... é só habilitar essa softkey para ele.
Então, fazendo a configuração do zero, temos:
1. Line Group
A primeira coisa a ser criada é um Line Group. Nele, vamos associar todas as linhas que fazem parte de um grupo. Mas nessa tela, podemos configurar algumas outras coisas:
- RNA Reversion Timeout: É o tempo que o ramal do grupo ficará tocando até que passe para o próximo membro. Ou seja, no hunt group, o sistema não respeita a configuração de "No answer ring duration" do ramal.
- Distribution Algorithm: Algoritmo que o CUCM vai usar para fazer o hunt entre os ramais do grupo. Pode ser top down (respeitando a ordem na lista, sempre começando pelo primeiro), circular (respeitando a ordem na lista, começando de onde parou), longest idle (CUCM entrega a chamada para o usuário que estiver livre há mais tempo), broadcast (todo mundo toca ao mesmo tempo)
- Hunt options (no answer, busy, not available): Aqui podemos definir algumas regras para quando um usuário não atender ou estiver ocupado. Por padrão, o CUCM vai tentar o próximo da lista (baseado no algoritmo de distribuição) até que acabe as opções dentro do Line Group, e depois vai passar para o próximo Line Group dentro da mesma Hunt List. Mas podemos deixar com que as opções fiquem limitadas a apenas os ramais desse Line Group, sem transbordar para o outro. Podemos também forçar o CUCM a parar de procurar o próximo ramal dentro desse Line Group e pular para o seguinte, ou podemos falar para o CUCM parar de tentar rotear a chamada para um próximo membro, e retornar como ocupado.
Obs: No caso do algoritmo Longest Idle, nunca vai acontecer de cair no caso Busy ou Not Available, porque o sistema já sabe quando ele não está disponível para atender a chamada, e tira ele das opções possíveis.
2. Hunt List
Agora configuramos uma Hunt List, e associamos um ou mais Line Groups. A ordem dos Line Groups dentro de uma Hunt List é importante para o caso de uma chamada ter que transbordar de um Line Group para outro (explicado acima, na opção Hunt options do Line Group).
3. Hunt Pilot
E finalmente configuramos o Hunt Pilot, que será o número piloto do grupo, e associamos a uma Hunt List. É aqui que algumas configurações confundem as pessoas, mais especificamente as configurações de "Hunt Forward Settings".
Nessa tela, podemos configurar o que o sistema vai fazer quando ninguém do grupo atender (no answer ou busy). Nesses casos, as configurações de forward dos ramais do grupo não tem efeito nenhum, pois é o que estiver configurado no Hunt Pilot que será usado.
Podemos encaminhar a chamada para o voice mail, ou desviar um outro número. Portanto, no campo Destination, colocamos esse número destino (se for para o voice mail, colocamos o número do voice mail pilot). E obviamente, configuramos uma CSS com as devidas permissões.
Agora, quando a chamada for desviada para o voice mail pilot, o que acontece? O CUCM vai mandar para a Unity como se o próprio hunt pilot tivesse desviado a chamada. Em outras palavras, a Unity vai buscar na base dela o número desse hunt pilot. Mas provavelmente o piloto não tem nenhum voice mail configurado, certo? Aí você vai cair no Greeting inicial da Unity. Para que você caia no voice mail de algum usuário, você deve cadastrar o Hunt Pilot como Alternate Extension de um usuário na Unity Connection, e pronto.
Nesse quadro também, temos a opção de desvio "Use Personal Preferences". Isso vai servir quando tivermos um ramal desviando as suas chamadas para o Hunt Pilot. Aí nesse caso, se ninguém no hunt group atender, e essa opção estiver marcada, a chamada vai ser desviada para o que tiver configurado no Forward No Coverage do ramal.
4. HLog
Com a softkey HLog, podemos fazer com que um ramal consiga logar ou deslogar de um Hunt Group. Assim, quando ele quiser entrar/sair do atendimento, ele só precisa apertar esse botão. Não precisa do Extension Mobility, e muito menos pedir pro usuário desligar o telefone dele! hahaha... é só habilitar essa softkey para ele.
domingo, 7 de outubro de 2012
Multicast MoH em SRST
Nossa, esse post estava há um tempão aqui nos meus Drafts, e acabei esquecendo de terminá-lo. Hoje é o dia de colocar ele no ar. Domingão de eleições, uma maravilha.
Bom, digamos que você tenha um site principal (HQ) e um Branch Office (BrO). E o seu cluster de CUCM fica no HQ. Quando um IP Phone do HQ ligar para um IP Phone do BrO e colocá-lo em espera, por padrão o stream de audio vai vir do CUCM, ocupando a sua WAN com musiquinha... Bom, na verdade isso só vai funcionar se os dois sites estiverem se falando em G711. Como geralmente dois sites se falam em G729 na WAN, para o MOH funcioanar você deve habilitar G.729 para Music on Hold (feito em Service Parameters >> Cisco IP Voice Media Streaming App).
Para evitar esse consumo inutil de banda na sua rede, podemos configurar o roteador do BrO para fazer streaming do Music on Hold via Multicast para os IP Phones locais, e dessa forma a música não passará pela WAN.
O que acontece na prática é que vamos "enganar" o telefone e o CUCM. Na verdade, o Gateway é que vai enganar todo mundo, safadinho. Quando o IP Phone do BrO for colocado em espera, ele vai solicitar o audio para um IP Multicast, que ele pensa que é do Call Manager. E de fato, é o IP configurado no Call Manager. Mas aí entra toda a malandragem do gateway, e ele responde primeiro, de forma que essa solicitação nunca chega no CUCM.
Para isso funcionar, vamos ter que configurar o CUCM fazendo Music on Hold via Multicast e em G711. No gateway, vamos ter que colocar um arquivo de audio na flash e habilitar o Multicast de Music on Hold dentro das configurações de SRST (mesmo que o site nem tenha um SRST operacional). Vamos ver as configurações passo-a-passo.
1. Habilitar G711 no MoH
- Crie uma nova Region que fala G711 com todo mundo
- Crie um novo Device Pool com essa Region
- Coloque um dos MOH Servers nesse Device Pool. No exemplo, vou usar o MOH_2 (Publisher).
2. Habilitar o Multicast MoH
- Media Resources >> Music on Hold Audio Source >> Allow Multicasting
- Media Resources >> Music on Hold Server >> MOH_2 (Publisher) >> Enable Multicast Audio Sources on this MOH Server (IP 239.1.1.1, Port 16384), e o Max Hops do Music on Hold, deixe como 1
- Media Resources >> Media Resource Groups >> Crie um MRG com o MOH_2, e habilite o Multicast. Coloque o MRG no MRGL dos telefones.
3. Configurar o roteador remoto
interface Loopback 0
ip address 1.1.1.1 255.255.255.255 ! -- Qualquer IP. É necessário para o MoH funcionar
com a PSTN.
ccm-manager music-on-hold
call-manager-fallback ! -- ou telephony-service
ip source-address x.x.x.x
max-ephone x
max-dn x
moh music-on-hold.au ! -- Arquivo deve estar na Flash
multicast moh 239.1.1.1 port 16384 route 1.1.1.1 <ips das outras interfaces do roteador>
O que fizemos foi:
Habilitamos o Multicast MoH no CUCM com o IP 239.1.1.1 e porta 16384.
Habilitamos o Multicast MoH no Roteador com o mesmo IP e porta.
Quando o telefone dessa localidade for colocado em Hold, ele vai solicitar o stream para esse IP e porta configurado. Mas o Roteador é quem vai responder, tocando o audio music-on-hold.au da flash.
4. Baixar um arquivo de MoH do CUCM
Se quiser pegar um arquivo de Music on Hold do seu CUCM para jogar na Flash do roteador, você pode fazer via CLI. Primeiramente, liste os arquivos de MoH existentes:
file list activelog mohprep
Uma listagem dos arquivos de audio será exibida:
admin:file list activelog mohprep
CiscoMOHSourceReport.xml SampleAudioSource.alaw.wav
SampleAudioSource.g729.wav SampleAudioSource.ulaw.wav
SampleAudioSource.wb.wav SampleAudioSource.xml
dir count = 0, file count = 6
Para cada MoH no sistema, esses 4 arquivos wav serão criados. Faça o download do arquivo desejado. Para o Multicast MoH, vamos pegar o arquivo no formato ulaw:
file get activelog mohprep/SampleAudioSource.ulaw.wav
Para essa transferência, será necessário um servidor SFTP, que você pode instalar na sua própria estação.
Bom, digamos que você tenha um site principal (HQ) e um Branch Office (BrO). E o seu cluster de CUCM fica no HQ. Quando um IP Phone do HQ ligar para um IP Phone do BrO e colocá-lo em espera, por padrão o stream de audio vai vir do CUCM, ocupando a sua WAN com musiquinha... Bom, na verdade isso só vai funcionar se os dois sites estiverem se falando em G711. Como geralmente dois sites se falam em G729 na WAN, para o MOH funcioanar você deve habilitar G.729 para Music on Hold (feito em Service Parameters >> Cisco IP Voice Media Streaming App).
Para evitar esse consumo inutil de banda na sua rede, podemos configurar o roteador do BrO para fazer streaming do Music on Hold via Multicast para os IP Phones locais, e dessa forma a música não passará pela WAN.
O que acontece na prática é que vamos "enganar" o telefone e o CUCM. Na verdade, o Gateway é que vai enganar todo mundo, safadinho. Quando o IP Phone do BrO for colocado em espera, ele vai solicitar o audio para um IP Multicast, que ele pensa que é do Call Manager. E de fato, é o IP configurado no Call Manager. Mas aí entra toda a malandragem do gateway, e ele responde primeiro, de forma que essa solicitação nunca chega no CUCM.
Para isso funcionar, vamos ter que configurar o CUCM fazendo Music on Hold via Multicast e em G711. No gateway, vamos ter que colocar um arquivo de audio na flash e habilitar o Multicast de Music on Hold dentro das configurações de SRST (mesmo que o site nem tenha um SRST operacional). Vamos ver as configurações passo-a-passo.
1. Habilitar G711 no MoH
- Crie uma nova Region que fala G711 com todo mundo
- Crie um novo Device Pool com essa Region
- Coloque um dos MOH Servers nesse Device Pool. No exemplo, vou usar o MOH_2 (Publisher).
2. Habilitar o Multicast MoH
- Media Resources >> Music on Hold Audio Source >> Allow Multicasting
- Media Resources >> Music on Hold Server >> MOH_2 (Publisher) >> Enable Multicast Audio Sources on this MOH Server (IP 239.1.1.1, Port 16384), e o Max Hops do Music on Hold, deixe como 1
- Media Resources >> Media Resource Groups >> Crie um MRG com o MOH_2, e habilite o Multicast. Coloque o MRG no MRGL dos telefones.
3. Configurar o roteador remoto
interface Loopback 0
ip address 1.1.1.1 255.255.255.255 ! -- Qualquer IP. É necessário para o MoH funcionar
com a PSTN.
ccm-manager music-on-hold
call-manager-fallback ! -- ou telephony-service
ip source-address x.x.x.x
max-ephone x
max-dn x
moh music-on-hold.au ! -- Arquivo deve estar na Flash
multicast moh 239.1.1.1 port 16384 route 1.1.1.1 <ips das outras interfaces do roteador>
O que fizemos foi:
Habilitamos o Multicast MoH no CUCM com o IP 239.1.1.1 e porta 16384.
Habilitamos o Multicast MoH no Roteador com o mesmo IP e porta.
Quando o telefone dessa localidade for colocado em Hold, ele vai solicitar o stream para esse IP e porta configurado. Mas o Roteador é quem vai responder, tocando o audio music-on-hold.au da flash.
4. Baixar um arquivo de MoH do CUCM
Se quiser pegar um arquivo de Music on Hold do seu CUCM para jogar na Flash do roteador, você pode fazer via CLI. Primeiramente, liste os arquivos de MoH existentes:
file list activelog mohprep
Uma listagem dos arquivos de audio será exibida:
admin:file list activelog mohprep
CiscoMOHSourceReport.xml SampleAudioSource.alaw.wav
SampleAudioSource.g729.wav SampleAudioSource.ulaw.wav
SampleAudioSource.wb.wav SampleAudioSource.xml
dir count = 0, file count = 6
Para cada MoH no sistema, esses 4 arquivos wav serão criados. Faça o download do arquivo desejado. Para o Multicast MoH, vamos pegar o arquivo no formato ulaw:
file get activelog mohprep/SampleAudioSource.ulaw.wav
Para essa transferência, será necessário um servidor SFTP, que você pode instalar na sua própria estação.
Assinar:
Postagens (Atom)