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

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.

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.