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.
terça-feira, 25 de setembro de 2012
MGCP - Parte 4 (Troubleshooting 3 - Failover)
E finalmente vamos ver o último troubleshooting de MGCP. Dessa vez, falarei sobre uma situação de failover. Ou seja, o call-agent principal cai e o secundário assume no meio de uma chamada. Continuamos utilizando os dois debugs abaixo:
3. MGCP Failover
Então nesse cenário, temos uma chamada em andamento entre um IP Phone e a PSTN. O subscriber (10.10.210.11), que é o call-agent principal, fica down. E o publisher (10.10.210.10) assume.
! -- Após perceber que o Subscriber está fora, o gateway bloqueia os circuitos em idle e espera que as conexões ativas sejam encerradas.
Sep 15 21:59:27.524: MGCP Packet sent to 10.10.210.11:2427--->
RSIP 622536905 *@SiteA-RTR MGCP 0.1
RM: graceful
<---
! -- O call-agent backup assume e inicia um processo de restart, desbloqueando os canais ativos.
Sep 15 21:59:27.528: MGCP Packet sent to 10.10.210.10:2427--->
RSIP 622536907 *@SiteA-RTR MGCP 0.1
RM: restart
<---
! -- O Publisher agora envia mensagens do tipo AUEP (Audit End Point) para o gateway a fim de verificar os status dos canais da E1/T1. Ele manda um AUEP para cada canal. Para não ficar muita coisa, vou mostrar apenas ele pedindo as informações do Canal 1, 2 e 8 (onde temos uma chamada ativa):
! -- Canal 1. Nenhuma chamada ativa.
Sep 15 21:59:27.688: MGCP Packet received from 10.10.210.10:2427--->
AUEP 1 S0/SU0/DS1-0/1@SiteA-RTR MGCP 0.1
F: X, A, I
<---
Sep 15 21:59:27.692: MGCP Packet sent to 10.10.210.10:2427--->
200 1
I:
X: 0
L: p:10-20, a:PCMU;PCMA;G.nX64, b:64, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;
SiteA-RTR(confFXR
L: p:10-220, a:G.729;G.729a;G.729b, b:8, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-110, a:G.726-16;G.728, b:16, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-70, a:G.726-24, b:24, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-50, a:G.726-32, b:32, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:30-270, a:G.723.1-H;G.723;G.723.1a-H, b:6, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:30-330, a:G.723.1-L;G.723.1a-L, b:5, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
M: sendonly, recvonly, sendrecv, inactive, loopback, conttest, data, netwloop, netwtest
<---
! -- Canal 2. Nenhuma chamada ativa.
Sep 15 21:59:27.692: MGCP Packet received from 10.10.210.10:2427--->
AUEP 2 S0/SU0/DS1-0/2@SiteA-RTR MGCP 0.1
F: X, A, I
<---
Sep 15 21:59:27.692: MGCP Packet sent to 10.10.210.10:2427--->
200 2
I:
X: 0
L: p:10-20, a:PCMU;PCMA;G.nX64, b:64, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-220, a:G.729;G.729a;G.729b, b:8, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-110, a:G.726-16;G.728, b:16, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-70, a:G.726-24, b:24, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-50, a:G.726-32, b:32, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:30-270, a:G.723.1-H;G.723;G.723.1a-H, b:6, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:30-330, a:G.723.1-L;G.723.1a-L, b:5, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
M: sendonly, recvonly, sendrecv, inactive, loopback, conttest, data, netwloop, netwtest
<---
! -- Canal 8. Uma chamada ativa. Sabemos disso porque na resposta do gateway para o CUCM, ele preenche o campo I com o valor C, que é um identificador da chamada.
Sep 15 21:59:27.708: MGCP Packet received from 10.10.210.10:2427--->
AUEP 8 S0/SU0/DS1-0/8@SiteA-RTR MGCP 0.1
F: X, A, I
<---
Sep 15 21:59:27.712: MGCP Packet sent to 10.10.210.10:2427--->
200 8
I: C
X: 8
L: p:10-20, a:PCMU;PCMA;G.nX64, b:64, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-220, a:G.729;G.729a;G.729b, b:8, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-110, a:G.726-16;G.728, b:16, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-70, a:G.726-24, b:24, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-50, a:G.726-32, b:32, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:30-270, a:G.723.1-H;G.723;G.723.1a-H, b:6, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:30-330, a:G.723.1-L;G.723.1a-L, b:5, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
M: sendonly, recvonly, sendrecv, inactive, loopback, conttest, data, netwloop, netwtest
<---
! -- Como no exemplo temos uma T1, o Publisher vai checar todos os 23 canais, independente se ele está idle, block, active. Caso a gente esteja utilizando uma T1 fracionada, os canais não configurados no gateway serão retornados ao CUCM como Endpt Unknown (no exemplo, o canal 9 não está configurado):
Sep 15 21:59:27.712: MGCP Packet received from 10.10.210.10:2427--->
AUEP 9 S0/SU0/DS1-0/9@SiteA-RTR MGCP 0.1
F: X, A, I
<---
Sep 15 21:59:27.712: MGCP Packet sent to 10.10.210.10:2427--->
500 9 Endpt Unknown
<---
! -- Agora o CUCM sabe que tem uma chamada ativa na porta 8. Então ele vai pedir mais informações sobre essa conexão com a mensagem AUCX (audit conection), e o gateway vai passar o Call Identification Number (C) e o Connection Mode (M):
Sep 15 21:59:27.732: MGCP Packet received from 10.10.210.10:2427--->
AUCX 24 S0/SU0/DS1-0/8@SiteA-RTR MGCP 0.1
I: C
F: C, M
<---
Sep 15 21:59:27.732: MGCP Packet sent to 10.10.210.10:2427--->
200 24
C: D000000002520877000000F50000000a
M: sendrecv
<---
! -- CUCM envia um RQNT (request notification) porque a conexão notificou um ICMP Unreachable (R/iu). E o gateway envia um 200 OK.
Sep 15 21:59:27.772: MGCP Packet received from 10.10.210.10:2427--->
RQNT 25 S0/SU0/DS1-0/8@SiteA-RTR MGCP 0.1
X: 8
R: R/iu, FXR/t38
Q: process,loop
<---
Sep 15 21:59:27.772: MGCP Packet sent to 10.10.210.10:2427—>
200 25 OK
<—
! -- O CUCM confirma o status da chamada com a PSTN para ver se ela foi preservada. Essa verificação é feita via Q.931
cmbh_rcv_callback: <-- Receiving backhaul msg for Se0/0/0:23 :
| bk_msg_type = DATA_REQ
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 5
| Q.931 message type: STATUS ENQ
| Q.931 message = 0802000A75
Sep 15 21:59:27.792:
cmbrl_send_pak: --> Sending backhauled msg for Se0/0/0:23 :
| bk_msg_type = DATA_IND
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 12
| Q.931 message type: STATUS
| Q.931 message = 0802800A7D0802809E14010A
! -- A chamada foi preservada e continua ativa com o Publisher sendo o call-agent ativo.
E assim encerro os posts sobre MGCP! :)
1. debug ccm-manager backhaul packets
2. debug mgcp packets
3. MGCP Failover
Então nesse cenário, temos uma chamada em andamento entre um IP Phone e a PSTN. O subscriber (10.10.210.11), que é o call-agent principal, fica down. E o publisher (10.10.210.10) assume.
! -- Após perceber que o Subscriber está fora, o gateway bloqueia os circuitos em idle e espera que as conexões ativas sejam encerradas.
Sep 15 21:59:27.524: MGCP Packet sent to 10.10.210.11:2427--->
RSIP 622536905 *@SiteA-RTR MGCP 0.1
RM: graceful
<---
! -- O call-agent backup assume e inicia um processo de restart, desbloqueando os canais ativos.
Sep 15 21:59:27.528: MGCP Packet sent to 10.10.210.10:2427--->
RSIP 622536907 *@SiteA-RTR MGCP 0.1
RM: restart
<---
! -- O Publisher agora envia mensagens do tipo AUEP (Audit End Point) para o gateway a fim de verificar os status dos canais da E1/T1. Ele manda um AUEP para cada canal. Para não ficar muita coisa, vou mostrar apenas ele pedindo as informações do Canal 1, 2 e 8 (onde temos uma chamada ativa):
! -- Canal 1. Nenhuma chamada ativa.
Sep 15 21:59:27.688: MGCP Packet received from 10.10.210.10:2427--->
AUEP 1 S0/SU0/DS1-0/1@SiteA-RTR MGCP 0.1
F: X, A, I
<---
Sep 15 21:59:27.692: MGCP Packet sent to 10.10.210.10:2427--->
200 1
I:
X: 0
L: p:10-20, a:PCMU;PCMA;G.nX64, b:64, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;
SiteA-RTR(confFXR
L: p:10-220, a:G.729;G.729a;G.729b, b:8, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-110, a:G.726-16;G.728, b:16, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-70, a:G.726-24, b:24, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-50, a:G.726-32, b:32, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:30-270, a:G.723.1-H;G.723;G.723.1a-H, b:6, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:30-330, a:G.723.1-L;G.723.1a-L, b:5, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
M: sendonly, recvonly, sendrecv, inactive, loopback, conttest, data, netwloop, netwtest
<---
! -- Canal 2. Nenhuma chamada ativa.
Sep 15 21:59:27.692: MGCP Packet received from 10.10.210.10:2427--->
AUEP 2 S0/SU0/DS1-0/2@SiteA-RTR MGCP 0.1
F: X, A, I
<---
Sep 15 21:59:27.692: MGCP Packet sent to 10.10.210.10:2427--->
200 2
I:
X: 0
L: p:10-20, a:PCMU;PCMA;G.nX64, b:64, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-220, a:G.729;G.729a;G.729b, b:8, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-110, a:G.726-16;G.728, b:16, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-70, a:G.726-24, b:24, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-50, a:G.726-32, b:32, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:30-270, a:G.723.1-H;G.723;G.723.1a-H, b:6, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:30-330, a:G.723.1-L;G.723.1a-L, b:5, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
M: sendonly, recvonly, sendrecv, inactive, loopback, conttest, data, netwloop, netwtest
<---
! -- Canal 8. Uma chamada ativa. Sabemos disso porque na resposta do gateway para o CUCM, ele preenche o campo I com o valor C, que é um identificador da chamada.
Sep 15 21:59:27.708: MGCP Packet received from 10.10.210.10:2427--->
AUEP 8 S0/SU0/DS1-0/8@SiteA-RTR MGCP 0.1
F: X, A, I
<---
Sep 15 21:59:27.712: MGCP Packet sent to 10.10.210.10:2427--->
200 8
I: C
X: 8
L: p:10-20, a:PCMU;PCMA;G.nX64, b:64, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-220, a:G.729;G.729a;G.729b, b:8, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-110, a:G.726-16;G.728, b:16, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-70, a:G.726-24, b:24, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-50, a:G.726-32, b:32, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:30-270, a:G.723.1-H;G.723;G.723.1a-H, b:6, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:30-330, a:G.723.1-L;G.723.1a-L, b:5, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
M: sendonly, recvonly, sendrecv, inactive, loopback, conttest, data, netwloop, netwtest
<---
! -- Como no exemplo temos uma T1, o Publisher vai checar todos os 23 canais, independente se ele está idle, block, active. Caso a gente esteja utilizando uma T1 fracionada, os canais não configurados no gateway serão retornados ao CUCM como Endpt Unknown (no exemplo, o canal 9 não está configurado):
Sep 15 21:59:27.712: MGCP Packet received from 10.10.210.10:2427--->
AUEP 9 S0/SU0/DS1-0/9@SiteA-RTR MGCP 0.1
F: X, A, I
<---
Sep 15 21:59:27.712: MGCP Packet sent to 10.10.210.10:2427--->
500 9 Endpt Unknown
<---
! -- Agora o CUCM sabe que tem uma chamada ativa na porta 8. Então ele vai pedir mais informações sobre essa conexão com a mensagem AUCX (audit conection), e o gateway vai passar o Call Identification Number (C) e o Connection Mode (M):
Sep 15 21:59:27.732: MGCP Packet received from 10.10.210.10:2427--->
AUCX 24 S0/SU0/DS1-0/8@SiteA-RTR MGCP 0.1
I: C
F: C, M
<---
Sep 15 21:59:27.732: MGCP Packet sent to 10.10.210.10:2427--->
200 24
C: D000000002520877000000F50000000a
M: sendrecv
<---
! -- CUCM envia um RQNT (request notification) porque a conexão notificou um ICMP Unreachable (R/iu). E o gateway envia um 200 OK.
Sep 15 21:59:27.772: MGCP Packet received from 10.10.210.10:2427--->
RQNT 25 S0/SU0/DS1-0/8@SiteA-RTR MGCP 0.1
X: 8
R: R/iu, FXR/t38
Q: process,loop
<---
Sep 15 21:59:27.772: MGCP Packet sent to 10.10.210.10:2427—>
200 25 OK
<—
! -- O CUCM confirma o status da chamada com a PSTN para ver se ela foi preservada. Essa verificação é feita via Q.931
cmbh_rcv_callback: <-- Receiving backhaul msg for Se0/0/0:23 :
| bk_msg_type = DATA_REQ
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 5
| Q.931 message type: STATUS ENQ
| Q.931 message = 0802000A75
Sep 15 21:59:27.792:
cmbrl_send_pak: --> Sending backhauled msg for Se0/0/0:23 :
| bk_msg_type = DATA_IND
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 12
| Q.931 message type: STATUS
| Q.931 message = 0802800A7D0802809E14010A
! -- A chamada foi preservada e continua ativa com o Publisher sendo o call-agent ativo.
E assim encerro os posts sobre MGCP! :)
sábado, 22 de setembro de 2012
MGCP - Parte 3 (Troubleshooting 2 - Chamada entrante)
Hoje vamos ver mais um troubleshooting de MGCP, continuando o post anterior. Lembrando que os dois debugs no gateway que estamos utilizando são:
2. Chamada entrante
Nesse cenário, um telefone da PSTN faz uma chamada para o IP Phone. Vamos ver o que acontece.
! -- Nesse momento, sabemos que o IP Phone está tocando, então o CUCM instrui o gateway através de um RQNT a tocar um ringback tone para a PSTN. A instrução S: G/rt que diz isso (rt = ringback tone). E o gateway responde com um 200 OK
! -- Nesse momento, a chamda está ativa. Telefone e gateway trocam RTP.
1. debug ccm-manager backhaul packets
2. debug mgcp packets
2. Chamada entrante
Nesse cenário, um telefone da PSTN faz uma chamada para o IP Phone. Vamos ver o que acontece.
! -- Primeiramente, a PSTN envia um SETUP via método Q.931, que como podemos ver, é encaminhado para o CUCM. Novamente podemos pegar a informação contida em "message" e extrair o número de destino, removendo os "3" da string 32303235353532303032: 2025552002. No CUCM, o gateway MGCP está configurado para considerar os últimos 4 dígitos apenas.
cmbrl_send_pak: --> Sending backhauled msg for Se0/0/0:23 :
| bk_msg_type = DATA_IND
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 43
| Q.931 message type: SETUP
| Q.931 message = 080200800504038090A21803A983811E0285836C09418034363738313234700BA132303235353532303032
| bk_msg_type = DATA_IND
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 43
| Q.931 message type: SETUP
| Q.931 message = 080200800504038090A21803A983811E0285836C09418034363738313234700BA132303235353532303032
! -- Recebendo essa solicitação, o CUCM envia uma mensagem ao Gateway solicitando a criação de uma nova conexão (CRCX).
Sep 15 22:23:36.920: MGCP Packet received from 10.10.210.11:2427--->
CRCX 230 S0/SU0/DS1-0/1@SiteA-RTR MGCP 0.1
C: D00000000252087e000000F580000080
X: 1
L: p:20, a:PCMU, s:off, t:00
M: recvonly
R: D/[0-9ABCD*#]
Q: process,loop
<---
CRCX 230 S0/SU0/DS1-0/1@SiteA-RTR MGCP 0.1
C: D00000000252087e000000F580000080
X: 1
L: p:20, a:PCMU, s:off, t:00
M: recvonly
R: D/[0-9ABCD*#]
Q: process,loop
<---
! -- E o gateway responde com um 200 OK, enviando junto o SDP, com as informações de mídia (IP, porta para o RTP, Codec, etc)
Sep 15 22:23:36.936: MGCP Packet sent to 10.10.210.11:2427--->
200 230 OK
I: D
v=0
o=- 13 0 IN IP4 10.10.200.3
s=Cisco SDP 0
c=IN IP4 10.10.200.3
t=0 0
m=audio 18878 RTP/AVP 0 100
a=rtpmap:100 X-NSE/8000
a=fmtp:100 200-202
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 200-202
a=X-cap: 2 image udptl t38
<---
Sep 15 22:23:36.936: MGCP Packet sent to 10.10.210.11:2427--->
200 230 OK
I: D
v=0
o=- 13 0 IN IP4 10.10.200.3
s=Cisco SDP 0
c=IN IP4 10.10.200.3
t=0 0
m=audio 18878 RTP/AVP 0 100
a=rtpmap:100 X-NSE/8000
a=fmtp:100 200-202
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 200-202
a=X-cap: 2 image udptl t38
<---
! -- O CUCM agora faz a conexão com o IP Phone destino, e envia via Q.931 as sinalizações de CALL PROCEEDING e ALERTING para a PSTN.
bh_rcv_callback: <-- Receiving backhaul msg for Se0/0/0:23 :
| bk_msg_type = DATA_REQ
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 10
| Q.931 message type: CALL PROCEEDING
| Q.931 message = 08028080021803A98381
cmbh_rcv_callback: <-- Receiving backhaul msg for Se0/0/0:23 :
| bk_msg_type = DATA_REQ
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 9
| Q.931 message type: ALERTING
| Q.931 message = 08028080011E028088
| bk_msg_type = DATA_REQ
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 10
| Q.931 message type: CALL PROCEEDING
| Q.931 message = 08028080021803A98381
cmbh_rcv_callback: <-- Receiving backhaul msg for Se0/0/0:23 :
| bk_msg_type = DATA_REQ
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 9
| Q.931 message type: ALERTING
| Q.931 message = 08028080011E028088
! -- Nesse momento, sabemos que o IP Phone está tocando, então o CUCM instrui o gateway através de um RQNT a tocar um ringback tone para a PSTN. A instrução S: G/rt que diz isso (rt = ringback tone). E o gateway responde com um 200 OK
Sep 15 22:23:36.944: MGCP Packet received from 10.10.210.11:2427--->
RQNT 231 S0/SU0/DS1-0/1@SiteA-RTR MGCP 0.1
X: 1
R: D/[0-9ABCD*#]
S: G/rt
Q: process,loop
RQNT 231 S0/SU0/DS1-0/1@SiteA-RTR MGCP 0.1
X: 1
R: D/[0-9ABCD*#]
S: G/rt
Q: process,loop
Sep 15 22:23:36.948: MGCP Packet sent to 10.10.210.11:2427--->
200 231 OK
200 231 OK
! -- Quando a PSTN atende, ela envia um CONNECT via Q.931, que é respondido com um CONNECT_ACK:
cmbh_rcv_callback: <-- Receiving backhaul msg for Se0/0/0:23 :
| bk_msg_type = DATA_REQ
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 12
| Q.931 message type: CONNECT
| Q.931 message = 080280800728054851504832
| bk_msg_type = DATA_REQ
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 12
| Q.931 message type: CONNECT
| Q.931 message = 080280800728054851504832
cmbrl_send_pak: --> Sending backhauled msg for Se0/0/0:23 :
| bk_msg_type = DATA_IND
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 5
| Q.931 message type: CONNECT ACK
| Q.931 message = 080200800F
| bk_msg_type = DATA_IND
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 5
| Q.931 message type: CONNECT ACK
| Q.931 message = 080200800F
! -- O CUCM agora fala para o gateway MGCP as informações de mídia (SDP), enviando o IP do telefone, porta, codec, etc:
Sep 15 22:23:44.552: MGCP Packet received from 10.10.210.11:2427--->
MDCX 233 S0/SU0/DS1-0/1@SiteA-RTR MGCP 0.1
C: D00000000252087e000000F580000080
I: D
X: 1
L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38
M: sendrecv
R: D/[0-9ABCD*#], FXR/t38
S:
Q: process,loop
v=0
o=- 13 0 IN EPN S0/SU0/DS1-0/1@SiteA-RTR
s=Cisco SDP 0
t=0 0
m=audio 24686 RTP/AVP 0
c=IN IP4 192.168.14.12
a=X-sqn:0
a=X-cap:1 image udptl t38
<---
MDCX 233 S0/SU0/DS1-0/1@SiteA-RTR MGCP 0.1
C: D00000000252087e000000F580000080
I: D
X: 1
L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38
M: sendrecv
R: D/[0-9ABCD*#], FXR/t38
S:
Q: process,loop
v=0
o=- 13 0 IN EPN S0/SU0/DS1-0/1@SiteA-RTR
s=Cisco SDP 0
t=0 0
m=audio 24686 RTP/AVP 0
c=IN IP4 192.168.14.12
a=X-sqn:0
a=X-cap:1 image udptl t38
<---
! -- Nesse momento, a chamda está ativa. Telefone e gateway trocam RTP.
! -- O IP Phone desconecta a chamada, e o CUCM instrui o gateway a parar de enviar RTP, que é respondido com um 200 OK:
Sep 15 22:23:55.832: MGCP Packet received from 10.10.210.11:2427--->
MDCX 234 S0/SU0/DS1-0/1@SiteA-RTR MGCP 0.1
C: D00000000252087e000000F580000080
I: D
X: 1
M: recvonly
R: D/[0-9ABCD*#]
Q: process,loop
<---
MDCX 234 S0/SU0/DS1-0/1@SiteA-RTR MGCP 0.1
C: D00000000252087e000000F580000080
I: D
X: 1
M: recvonly
R: D/[0-9ABCD*#]
Q: process,loop
<---
Sep 15 22:23:55.836: MGCP Packet sent to 10.10.210.11:2427--->
200 234 OK
<---
200 234 OK
<---
! -- Agora, via Q.931, o CUCM manda um DISCONNECT para a PSTN, que é respondido com um RELEASE:
cmbh_rcv_callback: <-- Receiving backhaul msg for Se0/0/0:23 :
| bk_msg_type = DATA_REQ
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 9
| Q.931 message type: DISCONNECT
| Q.931 message = 080280804508028290
Sep 15 22:23:55.852:
cmbrl_send_pak: --> Sending backhauled msg for Se0/0/0:23 :
| bk_msg_type = DATA_IND
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 5
| Q.931 message type: RELEASE
| Q.931 message = 080200804D
| bk_msg_type = DATA_REQ
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 9
| Q.931 message type: DISCONNECT
| Q.931 message = 080280804508028290
Sep 15 22:23:55.852:
cmbrl_send_pak: --> Sending backhauled msg for Se0/0/0:23 :
| bk_msg_type = DATA_IND
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 5
| Q.931 message type: RELEASE
| Q.931 message = 080200804D
! -- O CUCM informa o gateway que a conexão deve ser deletada (DLCX), e o gateway responde com um 250 OK, como falamos no post anterior:
Sep 15 22:23:55.852: MGCP Packet received from 10.10.210.11:2427--->
DLCX 235 S0/SU0/DS1-0/1@SiteA-RTR MGCP 0.1
C: D00000000252087e000000F580000080
I:
SiteA-RTR#D
X: 1
S:
<---
Sep 15 22:23:55.880: MGCP Packet sent to 10.10.210.11:2427--->
250 235 OK
P: PS=564, OS=90240, PR=560, OR=89600, PL=0, JI=7, LA=0
<---
DLCX 235 S0/SU0/DS1-0/1@SiteA-RTR MGCP 0.1
C: D00000000252087e000000F580000080
I:
SiteA-RTR#D
X: 1
S:
<---
Sep 15 22:23:55.880: MGCP Packet sent to 10.10.210.11:2427--->
250 235 OK
P: PS=564, OS=90240, PR=560, OR=89600, PL=0, JI=7, LA=0
<---
! -- E finalmente, o CUCM responde o RELEASE com um RELEASE_COMPLETE:
cmbh_rcv_callback: <-- Receiving backhaul msg for Se0/0/0:23 :
| bk_msg_type = DATA_REQ
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 5
| Q.931 message type: RELEASE COMPLETE
| Q.931 message = 080280805A
| bk_msg_type = DATA_REQ
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 5
| Q.931 message type: RELEASE COMPLETE
| Q.931 message = 080280805A
quinta-feira, 20 de setembro de 2012
MGCP - Parte 2 (Troubleshooting 1 - Chamada sainte)
Uma parte muito importante do atual Blueprint de voz é o Troubleshooting. Diferente da prova de R&S, essa sessão não é uma parte separada da prova. As questões de troubleshooting estão misturadas dentro do próprio exame. Nesses items, a prova pode te pedir para corrigir alguma coisa (ou pode nem te pedir tão claramente, mas você tem que sacar que está errado), ou coletar debugs/traces e postar em um txt com a sua explicação dos fatos.
Hoje vou falar sobre o troubleshooting do MGCP no gateway de voz. Mas antes de começar, precisamos lembrar que o MGCP trabalha com uma arquitetura centralizada, isto é, ele depende de um call-agent (no nosso caso, o Call Manager) para controlá-lo. Com o MGCP, o gateway repassa as informações de Layer 3 (Q.931) do ISDN vindas da PSTN para o CUCM (backhaul), que por sua vez envia mensagens ao roteador orientando-o sobre o que fazer. Em outras palavras, o gateway se torna um dispositivo burro, e o CUCM é quem coordena toda a comunicação.
Então por exemplo, em uma chamada entrante, a PSTN envia a sinalização Q.931 (aquela que contém os métodos de SETUP, CALL_PROC, ALERTING, etc.) e o gateway repassa tudo para o CUCM (no gateway, conseguimos ver essas mensagens com o comando debug ccm-manager backhaul packets). O CUCM trata as mensagens e orienta o gateway a criar a conexão e trocar mídia (RTP) com o telefone destino (conseguimos ver essas mensagens com o comando debug mgcp packets).
Portanto, os dois debugs que utilizaremos para o troubleshooting de MGCP no gateway são:
Então vamos ao nosso nosso primeiro cenário:
1. Chamada saínte
Nesse cenário, um IP Phone qualquer vai fazer uma chamada para a PSTN. Vamos ver o que acontece:
C: D000000002520875000000F500000009
X: 8
L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38
M: recvonly
R: D/[0-9ABCD*#]
Q: process,loop
Hoje vou falar sobre o troubleshooting do MGCP no gateway de voz. Mas antes de começar, precisamos lembrar que o MGCP trabalha com uma arquitetura centralizada, isto é, ele depende de um call-agent (no nosso caso, o Call Manager) para controlá-lo. Com o MGCP, o gateway repassa as informações de Layer 3 (Q.931) do ISDN vindas da PSTN para o CUCM (backhaul), que por sua vez envia mensagens ao roteador orientando-o sobre o que fazer. Em outras palavras, o gateway se torna um dispositivo burro, e o CUCM é quem coordena toda a comunicação.
Então por exemplo, em uma chamada entrante, a PSTN envia a sinalização Q.931 (aquela que contém os métodos de SETUP, CALL_PROC, ALERTING, etc.) e o gateway repassa tudo para o CUCM (no gateway, conseguimos ver essas mensagens com o comando debug ccm-manager backhaul packets). O CUCM trata as mensagens e orienta o gateway a criar a conexão e trocar mídia (RTP) com o telefone destino (conseguimos ver essas mensagens com o comando debug mgcp packets).
Portanto, os dois debugs que utilizaremos para o troubleshooting de MGCP no gateway são:
1. debug ccm-manager backhaul packets
2. debug mgcp packets
Para facilitar, vou marcar de azul tudo que for referente ao primeiro, e de verde tudo que for referente ao segundo.Então vamos ao nosso nosso primeiro cenário:
1. Chamada saínte
Nesse cenário, um IP Phone qualquer vai fazer uma chamada para a PSTN. Vamos ver o que acontece:
! -- O gateway recebe uma solicitação de criar uma conexão (CRCX) do CUCM (10.10.210.11). O CUCM está informando, entre outras coisas, as features de mídia:
L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38 (p = sampling rate, a = codec, s = vad, t = type of service)
Sep 15 21:58:03.892: MGCP Packet received from 10.10.210.11:2427--->
CRCX 197 S0/SU0/DS1-0/8@SiteA-RTR MGCP 0.1C: D000000002520875000000F500000009
X: 8
L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38
M: recvonly
R: D/[0-9ABCD*#]
Q: process,loop
! -- O gateway envia uma confirmação (200 OK), juntamente com o SDP. No SDP o gateway vai informar qual é o IP que ele vai falar mídia (definido no comando mgcp bind media source <interface>), a porta que ele vai falar RTP, e codec. O 0 ao lado de RTP/AVP significa G.711u).
Sep 15 21:58:03.908: MGCP Packet sent to 10.10.210.11:2427--->
200 197 OK
I: B
v=0
o=- 11 0 IN IP4 10.10.200.3
s=Cisco SDP 0
c=IN IP4 10.10.200.3
t=0 0
m=audio 17952 RTP/AVP 0 100
a=rtpmap:100 X-NSE/8000
a=fmtp:100 200-202
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 200-202
a=X-cap: 2 image udptl t38
200 197 OK
I: B
v=0
o=- 11 0 IN IP4 10.10.200.3
s=Cisco SDP 0
c=IN IP4 10.10.200.3
t=0 0
m=audio 17952 RTP/AVP 0 100
a=rtpmap:100 X-NSE/8000
a=fmtp:100 200-202
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 200-202
a=X-cap: 2 image udptl t38
! -- E aí vemos o SETUP sendo enviado para a PSTN por uma mensagem "backhauled" do CUCM. Veja que no corpo do SETUP, temos um número gigante terminado por: "34363738313234". E veja também que sempre tem um "3" intercalando cada número dessa string. Olha o que acontece se apagarmos todos os 3: "4678124". Esse é o número que o IP Phone está ligando!
Outra coisa importante a se observar nesse debug é o "sending" e "receiving". Essa comunicação é entre gateway e CUCM, e é na visão do gateway. Ou seja, quando é "Sending backhaul msg" quer dizer que a PSTN mandou, e o gateway está encaminhando para o CUCM. Quando é "Receiving backhaul msg" quer dizer que o CUCM mandou, e o gateway está encaminhando para a PSTN.
Outra coisa importante a se observar nesse debug é o "sending" e "receiving". Essa comunicação é entre gateway e CUCM, e é na visão do gateway. Ou seja, quando é "Sending backhaul msg" quer dizer que a PSTN mandou, e o gateway está encaminhando para o CUCM. Quando é "Receiving backhaul msg" quer dizer que o CUCM mandou, e o gateway está encaminhando para a PSTN.
cmbh_rcv_callback: <-- Receiving backhaul msg for Se0/0/0:23 :
| bk_msg_type = DATA_REQ
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 43
| Q.931 message type: SETUP
| Q.931 message = 080200090504038090A21803A98388280548515048326C090081353535323030327008C134363738313234
| bk_msg_type = DATA_REQ
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 43
| Q.931 message type: SETUP
| Q.931 message = 080200090504038090A21803A98388280548515048326C090081353535323030327008C134363738313234
! -- Depois da PSTN receber o SETUP, ela responde com um CALL PROCEEDING e ALERTING, como ocorre normalmente nas chamadas ISDN. Essas mensagens são todas encaminhadas para o CUCM:
cmbrl_send_pak: --> Sending backhauled msg for Se0/0/0:23 :
| bk_msg_type = DATA_IND
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 10
| Q.931 message type: CALL PROCEEDING
| Q.931 message = 08028009021803A98388
Sep 15 21:58:03.960:
cmbrl_send_pak: --> Sending backhauled msg for Se0/0/0:23 :
| bk_msg_type = DATA_IND
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 9
| Q.931 message type: ALERTING
| Q.931 message = 08028009011E028188
Sep 15 21:58:04.320: MGCP Packet received from 10.10.210.11:2427--->
| bk_msg_type = DATA_IND
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 10
| Q.931 message type: CALL PROCEEDING
| Q.931 message = 08028009021803A98388
Sep 15 21:58:03.960:
cmbrl_send_pak: --> Sending backhauled msg for Se0/0/0:23 :
| bk_msg_type = DATA_IND
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 9
| Q.931 message type: ALERTING
| Q.931 message = 08028009011E028188
Sep 15 21:58:04.320: MGCP Packet received from 10.10.210.11:2427--->
! -- Como a PSTN mandou um ALERTING, sabemos que o lado de lá está chamando. Então o CUCM manda um MDCX (Modify Connection) para o Gateway, mudando o status de recvonly para sendrecv, orientando o Gateway a começar a enviar mídia. E depois o gateway responde com um 200 OK. O CUCM também informa qual é o IP do telefone e porta, para eles falarem RTP (192.168.14.12 / 24682).
Sep 15 21:58:04.320: MGCP Packet received from 10.10.210.11:2427--->
MDCX 198 S0/SU0/DS1-0/8@SiteA-RTR MGCP 0.1
C: D000000002520875000000F500000009
I: B
X: 8
L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38
M: sendrecv
R: D/[0-9ABCD*#], FXR/t38
S:
Q: process,loop
v=0
o=- 11 0 IN EPN S0/SU0/DS1-0/8@SiteA-RTR
s=Cisco SDP 0
t=0 0
m=audio 24682 RTP/AVP 0
c=IN IP4 192.168.14.12
a=X-sqn:0
a=X-cap:1 image udptl t38
MDCX 198 S0/SU0/DS1-0/8@SiteA-RTR MGCP 0.1
C: D000000002520875000000F500000009
I: B
X: 8
L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38
M: sendrecv
R: D/[0-9ABCD*#], FXR/t38
S:
Q: process,loop
v=0
o=- 11 0 IN EPN S0/SU0/DS1-0/8@SiteA-RTR
s=Cisco SDP 0
t=0 0
m=audio 24682 RTP/AVP 0
c=IN IP4 192.168.14.12
a=X-sqn:0
a=X-cap:1 image udptl t38
Sep 15 21:58:04.324: MGCP Packet sent to 10.10.210.11:2427--->
200 198 OK
200 198 OK
! -- Agora a PSTN atende a chamada, e envia um CONNECT, que é enviado ao CUCM:
cmbrl_send_pak: --> Sending backhauled msg for Se0/0/0:23 :
| bk_msg_type = DATA_IND
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 5
| Q.931 message type: CONNECT
| Q.931 message = 0802800907
Sep 15 21:58:13.324:
cmbh_rcv_callback: <-- Receiving backhaul msg for Se0/0/0:23 :
| bk_msg_type = DATA_REQ
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 5
| Q.931 message type: CONNECT ACK
| Q.931 message = 080200090F
| bk_msg_type = DATA_IND
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 5
| Q.931 message type: CONNECT
| Q.931 message = 0802800907
Sep 15 21:58:13.324:
cmbh_rcv_callback: <-- Receiving backhaul msg for Se0/0/0:23 :
| bk_msg_type = DATA_REQ
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 5
| Q.931 message type: CONNECT ACK
| Q.931 message = 080200090F
! -- Nesse momento, o telefone está trocando RTP com o Gateway, e a chamada está em andamento.
! -- Agora a PSTN desconecta a chamada, e envia um DISCONNECT via Q.931, que é enviado para o CUCM:
cmbrl_send_pak: --> Sending backhauled msg for Se0/0/0:23 :
| bk_msg_type = DATA_IND
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 9
| Q.931 message type: DISCONNECT
| Q.931 message = 080280094508028290
| bk_msg_type = DATA_IND
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 9
| Q.931 message type: DISCONNECT
| Q.931 message = 080280094508028290
! -- O CUCM inicia o processo de desconexão, enviando um MDCX ao gateway mudando o status dele para recvonly. Ou seja, ele está falando para o gateway parar de mandar RTP. E o roteador manda um 200 OK confirmando:
Sep 15 21:58:27.516: MGCP Packet received from 10.10.210.11:2427--->
MDCX 199 S0/SU0/DS1-0/8@SiteA-RTR MGCP 0.1
C: D000000002520875000000F500000009
I: B
X: 8
M: recvonly
R: D/[0-9ABCD*#]
Q: process,loop
MDCX 199 S0/SU0/DS1-0/8@SiteA-RTR MGCP 0.1
C: D000000002520875000000F500000009
I: B
X: 8
M: recvonly
R: D/[0-9ABCD*#]
Q: process,loop
Sep 15 21:58:27.520: MGCP Packet sent to 10.10.210.11:2427--->
200 199 OK
200 199 OK
! -- Agora o CUCM solicita a deleção da conexão com um DLCX (Delete Conection):
Sep 15 21:58:27.524: MGCP Packet received from 10.10.210.11:2427--->
DLCX 200 S0/SU0/DS1-0/8@SiteA-RTR MGCP 0.1
C: D000000002520875000000F500000009
I: B
X: 8
S:
DLCX 200 S0/SU0/DS1-0/8@SiteA-RTR MGCP 0.1
C: D000000002520875000000F500000009
I: B
X: 8
S:
! -- E o gateway agora manda um 250 OK. Esse 250 é um pouco diferente dos outros ACKs. Nessa mensagem, ele manda uma estatística da chamada, informando a quantidade de Pacotes Enviados (PS), Recebidos (PR), Octetos enviados (OS), recebidos (OR), pacotes perdidos (PL), Jitter (JI) e Latencia (LA):
Sep 15 21:58:27.552: MGCP Packet sent to 10.10.210.11:2427--->
250 200 OK
P: PS=1160, OS=185600, PR=1154, OR=184640, PL=0, JI=6, LA=0
250 200 OK
P: PS=1160, OS=185600, PR=1154, OR=184640, PL=0, JI=6, LA=0
! -- E finalmente uma mensagem Q.931 de Release é enviada para a PSTN:
cmbh_rcv_callback: <-- Receiving backhaul msg for Se0/0/0:23 :
| bk
SiteA-RTR#_msg_type = DATA_REQ
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 5
| Q.931 message type: RELEASE
| Q.931 message = 080200094D
Sep 15 21:58:27.568:
cmbrl_send_pak: --> Sending backhauled msg for Se0/0/0:23 :
| bk_msg_type = DATA_IND
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 5
| Q.931 message type: RELEASE COMPLETE
| Q.931 message = 080280095A
| bk
SiteA-RTR#_msg_type = DATA_REQ
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 5
| Q.931 message type: RELEASE
| Q.931 message = 080200094D
Sep 15 21:58:27.568:
cmbrl_send_pak: --> Sending backhauled msg for Se0/0/0:23 :
| bk_msg_type = DATA_IND
| bk_chan_id (slot:port) = 0:0
| Q.931 length = 5
| Q.931 message type: RELEASE COMPLETE
| Q.931 message = 080280095A
Com isso, concluímos a análise de uma chamada sainte. Nos próximos posts veremos uma chamada entrante, e situações de failover, quando um call-agent fica fora no meio de uma chamada.
sábado, 15 de setembro de 2012
MGCP - Parte 1 (Configuração)
Hoje vou falar um pouco sobre a configuração do MGCP. É um post relativamente simples para quem já está estudando para o CCIE. Mas o objetivo dele é fazer uma introdução, porque no próximo post falarei sobre o troubleshooting do MGCP, que aí sim é um tema um pouco mais complexo.
Muita gente prefere configurar o MGCP com o modo automático do "ccm-manager config". Com essa feature, o gateway baixa toda a sua configuração do CUCM via TFTP, e teoricamente, com 2 comandos você tem tudo up and running. Mas não é bem assim que as coisas são... vou falar sobre as desvantagens desse método logo mais.
Bom, basicamente para configurar o MGCP dessa forma, você precisa primeiro provisionar o gateway no CUCM. Informações como Domain Name, Switch Type, Channel Selection Order são importantes. Feito isso, basta executar os seguintes comandos no roteador:
E pronto! Mas olha só que coisa... O comando colocou lá um monte de comando no seu roteador, mas alguns importantes não foram colocados, e você vai ter que se lembrar de fazer isso na mão. Esses comandos são:
E além disso, o comando sempre vai configurar a sua E1 ou T1 como full. Ou seja, ele sempre vai configurar a E1 com 30 canais e a T1 com 23. Se por algum motivo você quiser uma E1/T1 fracionada, você vai ter que ajustar isso na mão. E aí para alterar isso dá o maior trabalho... você tem que "shutar" a voice-port, depois a interface serial, depois remover o comando isdn bind-l3 ccm-manager, depois "shutar" a controller, e finalmente remover o pri-group e criar denovo. E aí adicionar o bind-l3 novamente na serial.
Por esses motivos, eu não acho uma boa ideia utilizar esse modo automatico de configuração. Sim, pode te salvar algum tempo, mas se você tiver os comandos do MGCP na veia (o que é esperado de um candidato a CCIE), você não vai levar mais do que 2 minutos para configurar tudo. E acaba sendo até mais rápido do que o modo automático, que você tem que ajustar um monte de coisa.
A configuração de MGCP que eu costumo fazer nos gateways é:
Se você ficar praticando isso, verá que é extremamente rápido de se configurar. O macete que eu uso para me lembrar de todos os comandos é saber que são 5 de ccm-manager e 6 de mgcp. Então quando eu termino a config (no notepad!), eu sempre conto antes de aplicar no gateway para ver se não está faltando nada.
No próximo post falarei sobre troubleshooting de MGCP, que é bem mais interessante...
Muita gente prefere configurar o MGCP com o modo automático do "ccm-manager config". Com essa feature, o gateway baixa toda a sua configuração do CUCM via TFTP, e teoricamente, com 2 comandos você tem tudo up and running. Mas não é bem assim que as coisas são... vou falar sobre as desvantagens desse método logo mais.
Bom, basicamente para configurar o MGCP dessa forma, você precisa primeiro provisionar o gateway no CUCM. Informações como Domain Name, Switch Type, Channel Selection Order são importantes. Feito isso, basta executar os seguintes comandos no roteador:
ccm-manager config server <PUB> ! -- TFTP Server
ccm-manager config ! -- Instrui o Gateway a baixar
o arquivo <Hostname>.cnf.xml do CUCM
E pronto! Mas olha só que coisa... O comando colocou lá um monte de comando no seu roteador, mas alguns importantes não foram colocados, e você vai ter que se lembrar de fazer isso na mão. Esses comandos são:
network-clock-select 1 T1 0/0/0
mgcp bind control source <interface>
mgcp bind media source <interface>
ccm-manager switchback <immediate/graceful>
ccm-manager fallback-mgcp ! - Opcional. Só se o GW for SRST
mgcp dtmf-relay voip codec all mode out-of-band
E além disso, o comando sempre vai configurar a sua E1 ou T1 como full. Ou seja, ele sempre vai configurar a E1 com 30 canais e a T1 com 23. Se por algum motivo você quiser uma E1/T1 fracionada, você vai ter que ajustar isso na mão. E aí para alterar isso dá o maior trabalho... você tem que "shutar" a voice-port, depois a interface serial, depois remover o comando isdn bind-l3 ccm-manager, depois "shutar" a controller, e finalmente remover o pri-group e criar denovo. E aí adicionar o bind-l3 novamente na serial.
Por esses motivos, eu não acho uma boa ideia utilizar esse modo automatico de configuração. Sim, pode te salvar algum tempo, mas se você tiver os comandos do MGCP na veia (o que é esperado de um candidato a CCIE), você não vai levar mais do que 2 minutos para configurar tudo. E acaba sendo até mais rápido do que o modo automático, que você tem que ajustar um monte de coisa.
A configuração de MGCP que eu costumo fazer nos gateways é:
network-clock-participate wic 0
network-clock-select 1 T1 0/0/0
isdn switch-type primary-ni
controller t1 0/0/0
pri-group timeslots 1-X service mgcp ! - X dependendo se for
fracionada ou não
interface serial 0/0/0:23
isdn bind-l3 ccm-manager
isdn outgoing display-ie
ccm-manager music-on-hold
ccm-manager redundant-host <PUB>
ccm-manager switchback immediate
ccm-manager fallback-mgcp
ccm-manager mgcp
mgcp call-agent <SUB>
mgcp dtmf voip codec all mode out
mgcp bind control source <interface>
mgcp bind media source <interface>
mgcp ip qos dscp cs3 sig
mgcp
Se você ficar praticando isso, verá que é extremamente rápido de se configurar. O macete que eu uso para me lembrar de todos os comandos é saber que são 5 de ccm-manager e 6 de mgcp. Então quando eu termino a config (no notepad!), eu sempre conto antes de aplicar no gateway para ver se não está faltando nada.
No próximo post falarei sobre troubleshooting de MGCP, que é bem mais interessante...
Assinar:
Postagens (Atom)