Primeiro lab remoto

Nesse final de semana fiz os meus primeiros labs remotos da ProctorLabs (Lab1, Volume 2 do IPExpert). E achei interessante compartilhar aqui o resultado. Como toda "primeira vez", estava meio atrapalhado... fui bem mal no sábado, não consegui terminar toda a prova e fiquei meio perdido algumas horas. Despesperante! Eu li o lab, sabia mais ou menos o que tinha que fazer, mas não consegui organizar os meus pensamentos de forma a bolar uma estratégia para atacá-lo.
Todo mundo fala que tem que ser rápido, não pode perder tempo e bla bla bla, então eu tentei fazer tudo o mais rápido que pude. Tipo, vou configurar um telefone no CUCM? Então já buscava na prova todos os requisitos para configurar o telefone de forma que eu tivesse que entrar na tela de config dele apenas uma vez! Então eu ía alternando entre as questões, tentando otimizar o meu tempo, e no final me perdi todo, não sabia direito o que tinha feito, o que faltava... foi um lixo.
Aí pensei... "não é possível... não pode ser assim que as pessoas otimizam o tempo! A não ser que você consiga organizar o seu raciocínio de uma maneira completamente foda".

Resolvi ver alguns comentários na Internet, mais especificamente esse post aqui do Vik Malhi: http://blog.ipexpert.com/2011/01/03/the-big-day-hour-1/

Recomendo fortemente a leitura! Com uma frase ele me entender o meu erro... "Walk before you can run". É isso! Não adianta você começar a prova já pensando como o Phone 1 do HQ vai apresentar o ANI em uma chamada de emergência, se você nem tem ainda o seu Phone 1 registrado! O importante é manter a calma, e se organizar. Se tiver que voltar na config do telefone para mudar uma CSS, tudo bem! Você num vai perder mais do que 15 segundos nisso... Percebi que não adianta economizar tempo com coisas idiotas como essas. Claro, tem coisa que é mais simples, então da pra ganhar uns minutinhos... tipo, configuração dos Softkeys templates, Phone Button templates, Service Parameters... isso só de vc ler a prova uma vez já da pra ter uma idéia do que você vai precisar alterar. Então faça uma vez só. Mas coisas mais complexas, principalmente as que envolvem Dial Plan, eu iria com mais calma.

Bom, o resultado do segundo lab (que eu acabei de acabar) foi bem melhor. Fiz novamente o Lab 1 (que acredito que seja mais facinho que os outros mesmo), e consegui acabar em 5h30. E ainda sobrou umas 2h pra revisar tudo e 15 minutos pra tomar banho! hauhauhau
Isso num lab real estaria ótimo! Claro, fazendo pela segunda vez eu já estava bem mais familiarizado com ele e tudo mais, mas mesmo assim fiquei satisfeito com o progresso.
Ao contrário da minha primeira tentativa, fiz a prova com mais calma e adotando a estratégia "technology-based approach", isto é, resolvendo as questões separando por assuntos (call routing, qos, high availability, ...). Acho que é bem mais fácil de você não se perder com essa estratégia. Tem gente que prefere o método device-based (http://www.youtube.com/watch?v=c1OKIJDDcaE), que é realmente bem interessante, só que acho que é muito fácil para você acabar se perdendo.

Comecei a prova da seguinte forma:
1. Infraestrutura e registro de devices: Faça isso o mais rápido que puder, porque é a parte mais fácil da prova
2. QoS: Acho melhor fazer no começo, porque se você zoar a sua WAN no final da prova, já era!
3. Call Routing: Depois de terminar Call Routing, você tira um peso das costas, e o resto flui mais fácil.


É isso aí, conforme eu for fazendo mais labs, vou colocando aqui o que aprendo com eles com relação a estratégia. Às vezes é a estratégia que define o seu sucesso ou fracasso.

E pra fechar o post, uma fotinha do meu home-lab, agora com telefones coloridos! hehehe
E feliz dia das mães! Graças à minha que estou aqui atrás desse desafio... quem diria, há 10 anos a minha mãe me incentivava a fazer o curso da Net Academy e hoje estou aqui estudando para um CCIE. Mãe sabe o que faz mesmo... hehehe

Ah, ontem lendo outros blogs, vi esse aqui do Matthew Berry (o cara do device-based approach):
http://ciscovoiceguru.com/548/ccie-voice-lab-strategy/
Ele diz: "make a commitment to keep an online blog"! uhu, acho que estou no caminho certo! hauhauhauhua...

WAN QoS (Frame Relay) - AutoQoS

Estava devendo esse post já há uns meses. No post que fiz em Janeiro sobre WAN QoS, abordei o MQC-Based, onde colocávamos o Traffic Shapping dentro de uma Policy-Map que era chamada pelo map-class frame-relay e etc, etc, etc. Na verdade, você só vai precisar configurar aquela forma de QoS se no enunciado ele for claro quanto a isso, ou se ele disser que você não pode usar o AutoQoS. Caso contrário, o jeito mais fácil e rápido de configurar o QoS na WAN é usando o nosso bom e velho amigo AutoQoS.


Então vamos para a primeira regra. SEMPRE antes de configurar qualquer coisa do seu auto qos, defina a banda do link na sua interface física. É baseado nesse valor que ele vai definir os seus parâmetros do Frame-Relay e do Traffic Shapping. Se você não colocar nada, ele vai considerar que a sua banda é de 1544Kbps, e aí ele não vai configurar o Traffic Shapping, pois ele só configura para links menores que 768Kbps.
Uma vez definida a banda na interface, entre na configuração do seu dlci e aplique um dos comandos abaixo:

auto qos voip trust

auto qos voip trust fr-atm

auto qos voip

auto qos voip fr-atm

Quatro comandos? Sim, quatro tipos de AutoQoS, e temos que saber bem a diferença entre eles... Mas é bem fácil! Os comandos com fr-atm configuram o AutoQoS usando MLPPP e os comandos sem o fr-atm configuram usando o FRF.12. Basicamente são duas formas de se configurar o LFI (Link Fragmentation and Interleaving). Então se o enunciado pedir MLP, coloque o fr-atm. Se pedir FRF.12, não coloque o fr-atm. Simples assim... Eventualmente no mesmo enunciado ele pode pedir para você configurar o link HQ - BR1 com MLP e HQ - BR2 com FRF.12... isso é perfeitamente possível. Em uma interface você configura com o fr-atm e na outra não. Bom, e o trust tá na cara, né? Com o trust ele vai confiar na marcação, e as suas class-maps vão dar match apenas no DSCP. Sem o trust ele não vai confiar na marcação vinda do Switch, e as suas class-maps vão reclassificar os pacotes novamente através de access-lists.

Vamos ver um pouco de configuração... fica mais fácil explicar:


Aplicando o AutoQoS

interface Serial0/0.1 point-to-point

 bandwidth 384                     ! -- Primeiro definimos a banda

 frame-relay interface-dlci 101    ! -- Depois aplicamos um dos

  auto qos voip trust              ! -- comandos de AutoQoS


Com o trust ou sem o trust?
Se você aplicar o trust no seu comando de auto qos, independente de usar ou não o fr-atm, a sua class-map ficará assim:
class-map match-any AutoQoS-VoIP-RTP-Trust
 match ip dscp ef
class-map match-any AutoQoS-VoIP-Control-Trust
 match ip dscp cs3
 match ip dscp af31
Repare que ele apenas deu match no DSCP e boa.

Se você não aplicar o trust, fica assim:

class-map match-any AutoQoS-VoIP-Remark ! -- Pode ignorar essa
 match ip dscp ef
 match ip dscp cs3
 match ip dscp af31
class-map match-any AutoQoS-VoIP-Control-UnTrust
 match access-group name AutoQoS-VoIP-Control
class-map match-any AutoQoS-VoIP-RTP-UnTrust
 match protocol rtp audio
 match access-group name AutoQoS-VoIP-RTCP

ip access-list extended AutoQoS-VoIP-Control
 permit tcp any any eq 1720
 permit tcp any any range 11000 11999
 permit udp any any eq 2427
 permit tcp any any eq 2428
 permit tcp any any range 2000 2002
 permit udp any any eq 1719
 permit udp any any eq 5060
ip access-list extended AutoQoS-VoIP-RTCP
 permit udp any any range 16384 32767
Repare que agora ele criou umas access lists para classificar o tráfego de RTP e Sinalização. Eventualmente o enunciado pode pedir para você não usar Access Lists. Nesse caso seria só remover tudo isso e configurar as class-maps com NBAR (match protocol XXX).


MLP 
Para os exemplos, vou considerar links menores que 768Kbps. Porque se for maior que isso, tanto faz porque o roteador não vai configurar LFI.
Quando configuramos MLPPP, o roteador cria uma interface virtual chamada Vitual-Template. Se o enunciado pedir para configurar MLP, nem pense em criar isso na mão porque vai dar um trabalhão!!! Deixe que o AutoQoS faça tudo por você. Detalhe que geralmente é necessário um reboot no router depois de aplicar essa config, senão você perde acesso a tudo... um bom motivo para nunca deixar QoS para o final da prova, porque se você quebrar a WAN nos 47 do segundo tempo, meu amigo...
Bom, a configuração usando MLPPP vai ficar assim:

policy-map AutoQoS-Policy-Trust
 class AutoQoS-VoIP-RTP-Trust
  priority percent 70        ! -- Essa é a sua LLQ, que provavel-

                             ! mente você tenha que modificar
                             ! depois. --

  compression header ip rtp  ! cRTP. Eu que adicionei essa linha

                             ! Por padrão o AutoQoS não habilita

                             ! o Class-Based cRTP. Se a prova 

                             ! pedir, é assim que faz. --
 class AutoQoS-VoIP-Control-Trust
  bandwidth percent 5
 class class-default
  fair-queue

interface Serial0/0.1 point-to-point
 description Connection to BranchOffice1
 bandwidth 384
 snmp trap link-status
 frame-relay interface-dlci 101 ppp Virtual-Template200
  class AutoQoS-FR-Se0/0-101
  auto qos voip trust fr-atm

interface Virtual-Template200  ! -- O AutoQoS que configurou isso
 bandwidth 384
 ip address 10.10.10.1 255.255.255.252
 ppp multilink
 ppp multilink interleave
 ppp multilink fragment delay 10

 service-policy output AutoQoS-Policy-Trust

map-class frame-relay AutoQoS-FR-Se0/0-101
 frame-relay cir 384000     ! -- Aqui um detalhe. O SRND diz que
 frame-relay bc 3840        ! esses valores devem ser 95% do CIR. 
 frame-relay be 0           ! ou seja, no caso, 36480. Então  
 frame-relay mincir 384000  ! teriamos que alterá-los na mão.
                            ! Mas se a prova não disser nada, deixe
                            ! assim ou confirme com o Proctor. --

FRF.12
Configuração de FRF.12 é bem mais tranquila. Da até para fazer na mão, se quiser. Tipo, você configura o HQ com auto qos, copia as configurações modificadas e cola na outra ponta da sua WAN. É uma boa tática para economizar um pouco de tempo.

policy-map AutoQoS-Policy-Trust ! -- Mesma coisa que lá em cima
 class AutoQoS-VoIP-RTP-Trust
  priority percent 70

 class AutoQoS-VoIP-Control-Trust
  bandwidth percent 5
 class class-default
  fair-queue

interface Serial0/0.1 point-to-point
 description Connection to HQ
 bandwidth 384
 ip address 10.10.10.6 255.255.255.252
 snmp trap link-status
 frame-relay interface-dlci 203
  class AutoQoS-FR-Se0/0-203
  auto qos voip trust
 frame-relay ip rtp header-compression ! -- Remova isso se for 

                                       ! usar  class-based cRTP --

map-class frame-relay AutoQoS-FR-Se0/0-203
 frame-relay cir 384000    ! -- Mesma coisa. Confirme com o 
 frame-relay bc 3840       ! Proctor se tem que seguir o SRND e
 frame-relay be 0          ! mudar esses valores para 95% --
 frame-relay mincir 384000
 frame-relay fragment 480
 service-policy output AutoQoS-Policy-Trust

Cálculo da Banda
Pode ser que a prova peça para você permitir na LLQ x chamadas usando G.729 por exemplo. Nesse caso, usar MLPPP ou FRF.12 vai mudar as suas contas. Se você usar MLPPP, o seu overhead de Layer 2 será de 13 bytes. Se usar FRF.12, o overhead é de 6 bytes, de acordo com o SRND. Então atenção com isso na hora de fazer as suas contas.
Se você tiver que configurar FRF.12 e MLPPP no mesmo router, tipo um para a comunicação HQ-BR1 e outra para HQ-BR2, e tiver que configurar bandas diferentes nas suas LLQs, vc vai precisar criar uma segunda Policy-Map e mudar no Virtual-Template.
Para mais informações sobre a continha para fazer o cálculo da banda, veja o meu primeiro post, do dia 30/12.

CME Call Blocking

Uma feature muito útil no CME é o Call Blocking. Com essa feature, podemos definir patterns que podem ser bloqueadas pelo sistema em alguns horários... Por exemplo, eu posso fazer com que o sistema bloqueie chamadas DDI nos finais de semana. E o melhor de tudo é que para configurar é meia dúzia de comandinho... às vezes me pergunto por que diabos algumas features tão legais do CME não são implantadas no CUCM. Para fazer isso no CUCM precisamos criar os Time Schedules, Time Periods, criar Partitions, criar Translation Patterns, ordenar a partition nas Calling Search Spaces... mó trabalho! E no CME se faz com alguns comandos...
Enfim, vamos lá. Para configurar os bloqueios, faremos tudo dentro de telephony-services (mas vai funcionar também para telefones SIP)... Então, pegando até um exemplo de um dos labs do IPExpert, digamos que eu queira permitir que os usuários façam chamadas internacionais (Pattern 900T) apenas de Segunda a Sexta das 7h às 19h, e aos sábados das 7h às 13h. Fora disso, essas chamadas devem ser bloqueadas. Para isso, fariamos o seguinte:

telephony-service

 after-hours block pattern 1 900   ! -- Primeiro definimos a pattern

                                   ! -- a ser bloqueada

 after-hours day Sun 12:00 07:00   ! -- E depois criamos os horários

 after-hours day Mon 19:00 06:59   ! -- de bloqueio.
 after-hours day Tue 19:00 06:59
 after-hours day Wed 19:00 06:59
 after-hours day Thu 19:00 06:59
 after-hours day Fri 19:00 06:59
 after-hours day Sat 13:00 12:00

A sintaxe do comando que define os horários de bloqueio é:

after-hours day <Dia da Semana> <Horario de Inicio> <Horario de Fim>

Quando o horário de fim for menor que o horário de início, como no exemplo, ele considera o dia seguinte. Então nesses casos o bloqueio vai até às 06h59 do dia seguinte. 07h em ponto o bloqueio deixa de valer.
Uma outra forma de configurar os horário de bloqueio é com o comando:

after-hours date <Mes> <Dia> <Horario de Inicio> <Horario de Fim>

Dessa forma, conseguimos definir uma data recorrente de bloqueio, ideal para feriados. Tipo:

after-hours date dec 25 0:00 23:59  ! -- Aplica o bloqueio no Natal

Até aqui tudo tranquilo, né? Mas e se um diretor está no escritório de noite e precisa fazer uma chamada internacional? Para isso existe as opções de Call Blocking Override, isto é, podemos definir algumas formas de certos usuários passarem por cima desse bloqueio:

1. PIN Code
É possível criarmos um PIN Code que fará o override do Call Blocking. No exemplo abaixo, o meu PIN será 1234.

telephony-service

 after-hours override-pattern 1234

Feito isso, quando um usuário discar o número bloqueado com um 1234 na frente, o Call Blocking não terá efeito. Então ele deverá discar 1234 + número internacional (900T) para efetuar a chamada. Isso funcionará independente do ramal, quem souber a senha vai conseguir fazer...

2. Liberação por telefone
Digamos que não queremos criar um PIN global, pois depois de 2 dias todo mundo já sabe o esquema. Então podemos configurar a liberação por telefone, e aplicamos apenas nos usuários mais críticos:

ephone X

 after-hours exempt  ! -- Libera o ephone dos bloqueios

3. Liberação temporária
E agora vamos ao nosso terceiro caso. Digamos que agora não querem que o telefone do pessoal mais crítico fique liberado o tempo todo. Eles querem que seja liberado apenas através de um PIN, e que o login fique ativo por um tempo limitado. Para isso configuramos o seguinte:

telephony-service

 login timeout 180 clear 22:00  ! -- O PIN ficará ativo por 180  

                                  -- minutos, e às 22h os logins  

                                  -- serão liberados -- !

ephone X

 pin 12345

Agora nessa situação, o usuário vai precisar apertar o botão Login nos Softkeys do telefone e digitar o seu PIN individual. Feito isso, o telefone vai estar liberado para fazer as chamadas bloqueadas por 3 horas, sendo que às 22h todos serão deslogados.


E agora que está tudo esclarecido sobre Call Blocking e Override no CME, nos passaram mais um requisito. Querem que especificamente a rota 900T nunca seja liberada através dos PINs (situação 1 e 3). E agora? Para isso, adicione o parâmetro 7-24 no seu comando de block pattern:

telephony-service

 after-hours block pattern 1 900 7-24

Assim, essa rota estará sempre bloqueada, exceto para quem tiver o after-hours exempt configurado no ephone.

CUBE - Parte 2 (Configuração)

Agora que já estamos manjando tudo dos conceitos de CUBE (ô!), veremos que a configuração não é nenhum bicho de 7 cabeças. Vamos implementar o exemplo do post anterior. Ou seja, um CUCM, um CME e ambos registrados num Gatekeeper com função de CUBE. O CUCM tem a faixa de ramal 1XXX e o CME 2XXX.

Os endereçamentos IPs do exemplo serão:
CUCM: 172.16.10.10
CME: 192.168.20.10 (loopback 0)
GK: 172.16.10.230

1. CUCM
No CUCM precisaremos primeiramente declarar um Gatekeeper em Device > Gatekeeper. Utilizaremos o IP 172.16.10.230.
Feito isso, criaremos um Inter-Cluster Trunk (Gatekeeper Controlled) chamado gk-trunk (esse é o nome que vai aparecer no gatekeeper identificando o CUCM). Configuramos o Significant Digits em 4, e definimos a CSS apropriada para que as chamadas entrem corretamente. Amarramos o Gatekeeper criado acima, usando como Zone o nome CUCM, e tech-prefix 1#. Para este exemplo, não mexeremos muito com os tech-prefix... isso fica para assunto num próximo post.
Bom, agora é só criarmos uma Route Pattern 2XXX apontando para o gk-trunk.

2. CME
No CME precisaremos configurar a interface para que ela se registre no Gatekeeper. Então vamos aplicar os comandos abaixo:

interface loopback 0
 ip address 192.168.20.10 255.255.255.0
 h323-gateway voip interface
 h323-gateway voip id CME ipaddr 172.16.10.230 1719
 h323-gateway voip h323-id CME

 h323-gateway voip tech-prefix 1#


Pronto, agora que o CME está configurado para se registrar no GK, temos que criar as dial-peers. Bem, precisamos de uma dial-peer de entrada (para as chamadas que chegam do GK) e uma de saída (para as chamadas que vão para o CUCM através do GK). Poderíamos criar 2 dial-peers separadas, para por exemplo, manipular os codecs diferentemente em uma situação e outra. Aqui no exemplo vamos usar tudo G.711 para evitar o uso de transcodes, portanto vou criar tudo em uma única dial-peer:

dial-peer voice 1 voip 

 incoming called-number . ! -- Entrada

 destination-pattern 1... ! -- Saída

 session target ras       ! -- Aponta a saída para o GK

 codec g711ulaw           ! -- Lembre-se que o default é G.729

 no vad                   ! -- "vad is bad"

Certo! O nosso CME já está configurado. Depois que subirmos o Gatekeeper, só não podemos esquecer de voltar aqui e dar o comando gateway, para que ele se registre com o GK. Ah, não se esqueça também de colocar um no-reg nos ephone-dn, para que os ramais do CME não se registrem no GK!

3. CUBE/Gatekeeper
E agora o mais importante: o GK. Primeiramente vamos configurar a interface FastEthernet dele para que o CUBE se registre no Gatekeeper. Sim, ele vai se registrar nele mesmo, mas lembre-se de que devemos encarar os dois como entidades separadas.

interface FastEthernet1/0
 ip address 172.16.10.230 255.255.255.0
 h323-gateway voip interface
 h323-gateway voip id CUBE ipaddr 172.16.10.230 1719
 h323-gateway voip h323-id CUBE

Feito isso, vamos configurar o gatekeeper em si:

gatekeeper
 zone local CUBE ngk.com                   
 zone local CME ngk.com outvia CUBE      ! -- Depois explico o
 zone local CUCM ngk.com outvia CUBE     ! -- invia e outvia
 zone prefix CUCM 1...
 zone prefix CME 2...
 gw-type-prefix 1#* default-technology
 no shutdown

Agora as dial-peers de entrada e saída, que mais uma vez juntei em uma só. Obs: Se você não criar a dial-peer, o CUBE não registra.

dial-peer voice 1 voip
 destination-pattern [12]...
 session target ras
 incoming called-number .
 codec g711ulaw


Bom, agora é só dar comando gateway que você vai ver tudo registrado no gatekeeper:

CUBE#sh gatekeeper endpoints
                    GATEKEEPER ENDPOINT REGISTRATION
                    ================================
CallSignalAddr  Port  RASSignalAddr   Port  Zone Name         Type    Flags
--------------- ----- --------------- ----- ---------         ----    -----
172.16.10.10    1720  172.16.10.10    32793 CUCM              VOIP-GW
    H323-ID: gk-trunk_1
    Voice Capacity Max.=  Avail.=  Current.= 0
192.168.20.10   1720  192.168.20.10   61476 CME               H323-GW
    H323-ID: CME
    Voice Capacity Max.=  Avail.=  Current.= 0
172.16.10.230   1720  172.16.10.230   57128 CUBE              H323-GW
    H323-ID: CUBE
    Voice Capacity Max.=  Avail.=  Current.= 0
Total number of active registrations = 3

Antes de fazermos os testes, recomendo colocarmos esses comandos no CME e no GK:
voice service voip
 allow-connections h323 to h323
 allow-connections h323 to sip
 allow-connections sip to h323
 allow-connections sip to sip
O h323 to h323 é fundamental! Os demais é só se você tiver algum telefone SIP registrado.

Agora sim, hora de testar!
Do jeito que configuramos, tanto no sentido CUCM >> CME quanto no sentido CME >> CUCM, o CUBE será utilizado. Isso por causa daqueles comandos outvia que colocamos ao declarar as Zones. Daqui a pouco vou explicar melhor sobre esse comando. Mas veja que quando fizermos uma chamada do CUCM para o CME, o seguinte output será mostrado:

CUBE#sh gatekeeper calls
Total number of active calls = 2.
                         GATEKEEPER CALL INFO
                         ====================
LocalCallID                        Age(secs)   BW
33-44                              10          128(Kbps)
 Endpt(s): Alias                 E.164Addr
   src EP: gk-trunk_1            1001
           CallSignalAddr  Port  RASSignalAddr   Port
           172.16.10.10    1720  172.16.10.10    32793
 Endpt(s): Alias                 E.164Addr
   dst EP: CUBE                  2002
           CallSignalAddr  Port  RASSignalAddr   Port
           172.16.10.230   1720  172.16.10.230   57128
LocalCallID                        Age(secs)   BW
34-44                              10          128(Kbps)
 Endpt(s): Alias                 E.164Addr
   src EP: CUBE                  1001
           CallSignalAddr  Port  RASSignalAddr   Port
           172.16.10.230   1720  172.16.10.230   57128
 Endpt(s): Alias                 E.164Addr
   dst EP: CME                   2002
           CallSignalAddr  Port  RASSignalAddr   Port
           192.168.20.10   1720  192.168.20.10   61476

Repare que essa é apenas 1 chamada, porém o CUBE exibe como se fosse duas! Uma do CUCM (gk-trunk) para o CUBE e outra do CUBE para o CME. Se fizessemos a chamada do CME para o CUCM, o output seria similar.

Legal, mas por que isso? É que quando declaramos as zones, colocamos o comando outvia CUBE na frente. O que esse comando faz é instruir o GK a enviar a chamada para a zone CUBE quando ela sair do GK. Existe duas formas de configurarmos isso, uma é dessa forma com o comando outvia e outra é com o comando invia.
O outvia, como eu disse, é quando a chamada sai do GK. E o invia, por sua vez, é quando a chamada entra no GK. Poderiamos ter sido orientados a utilizar o CUBE apenas nas chamadas do CUCM para o CME, por exemplo. Nesse caso, o fluxo seria assim: CUCM >> GK >> CME, certo? Então, poderíamos configurar isso aplicando o invia CUBE na zone CUCM ou aplicando o outvia CUBE na zone CME. Funcionaria das duas formas... só que o invia CUBE no CUCM forçaria o uso do CUBE para tooodas as chamadas que chegassem no GK pela zone CUCM, assim como o comando outvia CUBE na zone CME aplicaria o CUBE para tooodas as chamadas que saíssem para o CME.

Se aplicassemos uma dessas configurações, o nosso gatekeeper ficaria assim, por exemplo:
gatekeeper
 zone local CUBE ngk.com
 zone local CME ngk.com
 zone local CUCM ngk.com invia CUBE
 zone prefix CUCM 1...
 zone prefix CME 2...
 gw-type-prefix 1#* default-technology
 no shutdown

Portanto nessa situação, o CUBE seria utilizado apenas nas chamadas que entrassem no GK pelo CUCM. Logo, apenas nas chamadas CUCM >> GK >> CME. Se tivessemos uma outra zone CME2, por exemplo, as chamadas para ela também utilizariam o CUBE. O output do show gatekeeper calls seria o mesmo que o mostrado acima.
Agora, nessa situação, quando fizermos uma chamada do CME para o CUCM, o CUBE não será chamado, e a ligação vai passar direto, veja:

CUBE#sh gatekeeper calls

Total number of active calls = 1.
                         GATEKEEPER CALL INFO
                         ====================
LocalCallID                        Age(secs)   BW
37-46133                           4           128(Kbps)
 Endpt(s): Alias                 E.164Addr
   src EP: CME                   2002
           CallSignalAddr  Port  RASSignalAddr   Port
           192.168.20.10   1720  192.168.20.10   61476
 Endpt(s): Alias                 E.164Addr
   dst EP: gk-trunk_1            1001
           CallSignalAddr  Port  RASSignalAddr   Port
           172.16.10.10    1720  172.16.10.10    32793

E com isso termino a explicação sobre CUBE. Recomendo fortemente que faça isso em um lab, que o entendimento fica bem mais fácil! :)
E recomendo também esse artigo! O cara é foda... e explica só um pouquinho melhor que eu! hauhauhua!

CUBE - Parte 1 (Conceitos)

Configuração de CUBE é um dos temas mais complicados da prova, na minha opinião. Isso porque quase não implementamos no dia-a-dia, e também porque esse assunto estava lá no finalzinho do livro do CVOICE... hehehe! Aí passamos meio batido. Nesse post vou tentar esclarecer um pouquinho sobre os conceitos de CUBE e Via Zones.

Vamos supor que temos duas empresas distintas, uma com um CUCM e outra com um CME. E elas querem fazer a integração da telefonia. Bom, isso seria bem tranquilo, não? Poderiamos criar um trunk H.323 e apontar direto as rotas de um sistema para o outro. Só que a vida não é assim tão fácil... nos passaram um requisito de que eles não querem que seja trocada sinalização diretamente entre os dois dispositivos... O que é bem aceitável, pois poderiamos ter problemas de segurança, roteamento, etc. Então precisamos de um cara que fique no meio do caminho, interceptando a comunicação entre as duas pontas, e fazendo com que o CUCM e CME não se falem diretamente.  É justamete aí que entra o CUBE (Cisco Unified Border Element). Esse produto no mercado é também conhecido como SBC (Session Border Controller). Logo, o CUBE é o SBC da Cisco.

O CUBE essencialmente é um Gatekeeper... e nele vamos configurar 3 zones: ZoneCUCM, ZoneCME e ZoneCUBE. Em termos de configuração, o CUBE é o mesmo device físico que o Gatekeeper, porém é mais fácil pensarmos nele como se fosse uma entidade separada.

Bom, vamos ao nosso Call Setup. Para o exemplo, vamos considerar que o range de ramal do CUCM é 1XXX e o do CME é 2XXX.
Quando o CUCM for fazer uma chamada para o CME, ele enviará um ARQ (Admission Request) para o Gatekeeper, que verificará na sua lista para qual zone irá rotear a chamada. Ele vê que as chamadas para 2XXX devem ser roteadas para a ZoneCME, mas ao invés de enviar a chamada para essa Zone, ele manda ela para ZoneCUBE (veremos o porquê nas configurações). Portanto, quando o Gatekeeper responde o ACF (Admission Confirm) para o CUCM, ele manda o IP do CUBE, e não do CME! Dessa forma, a sinalização H225 é fechada entre o CUCM e o CUBE (que é o Gatekeeper). Essa é a sacada, porque o CUCM nunca recebe o IP do CME para trocar mídia e sinalização. Se pensarmos que o CME está em uma outra empresa, com outro endereçamento, isso faz todo o sentido do mundo, não?
Continuando, quando o CUCM faz o Call Setup com o CUBE, o CUBE manda um outro ARQ para o Gatekeeper (sim, o CUBE e o GK são o mesmo roteador. Na prática, ele manda a mensagem para ele mesmo. Mas lembre-se que devemos sempre encarar o CUBE e o GK como duas entidades separadas). E o Gatekeeper agora responde um ACF, e o CUBE fecha o H225 com o CUCM. Nesse ponto da chamada, a perna CUCM - CUBE já está ok, agora ele vai estabelecer a outra perna (CUBE - CME).
O CUBE agora manda um novo ACF para o Gatekeeper solicitando uma chamada para o CME. O Gatekeeper então responde um ACF para o CUBE, que faz o setup do H225 com o CME. Ao receber esse setup, o CME manda também um ARQ para o GK perguntando se ele pode aceitar a chamada, e o GK responde um ACF autorizando o call setup.
Quando a chamada é estabelecida, o audio pode trafegar de duas formas entre as duas pontas. Uma é o media flow through (default), que separa o RTP em 2 (CUCM-CUBE e CUBE-CME) e o media flow around, que faz um bypass no CUBE e fecha direto entre as duas pontas.
A topologia abaixo mostra tudo o que eu acabei de escrever. Ela foi retirada de uma apresentação do Mark Snow para o Internetwork Expert.

Ok, ficou confuso! Mas tudo isso foi para falar que quando usamos o CUBE, o Gatekeeper intercepta a chamada através de uma zone especial chamada de via zone. E as duas pontas nunca se falam diretamente. Veremos que em uma chamada assim, quando damos um show gatekeeper calls, o output nos mostras duas chamadas ao invés de uma.

Dada essa (tentativa de) explicação, no próximo post vou escrever o que interessa mais para nós: as configurações.

Call Pickup no CME

Eu já fiz um post sobre Call Pickup no CUCM, e agora vou falar rapidamente sobre essa feature no Call Manager Express. Assim como no CUCM, existem várias formas de se configurar o Call Pickup no CME:
- Directed Call Pickup: Captura uma chamada de um ramal especifico digitando o número do ramal
- Group Pickup: Captura chamadas de outros grupos, digitando o número do grupo
- Local Group Pickup: Captura chamadas dentro de um grupo usando a tecla asterisco (*).

Para facilitar, vou pegar o exemplo do Administrator Guide e explicar as situações. Vamos supor que temos um CME com apenas 4 telefones registrados:
Phone1 (ext. 5555) - pickup-group 33
Phone2 (ext. 5556) - pickup-group 33
Phone3 (ext. 5557) - pickup-group 44
Phone4 (ext. 5558) - <nenhum pickup-group configurado>

Situação 1: Nenhum pickup-group configurado
Nessa situação, o ramal 5555 toca. O Phone4, por não estar em nenhum grupo, pressiona a tecla PickUp e depois o 5555 para capturar a chamada. (Directed Call Pickup)

Situação 2: Mesmo grupo
Nessa situação, o ramal 5555 toca. O Phone2 pressiona Pickup ou GPickup (explicarei a seguir) e depois * para capturar a chamada. (Local Group Pickup)

Situação 3: Grupos diferentes
Nessa situação, o ramal 5555 toca. O Phone3 pressiona GPickup e depois 33 para capturar a chamada. (Group Pickup)
Obs: Com o comando pickup-call any-group dentro do ephone-dn, permitimos que esse ramal consiga capturar chamadas de qualquer grupo pressionando GPickup + asterisco (*). A única limitação é que o ramal a ser capturado deve ter algum grupo configurado.

Situação 4: Todos os ramais no mesmo grupo
Se todos os ramais do CME estiverem no mesmo grupo, é possível fazer a captura de uma chamada pressionando a tecla GPickup 2 vezes. Por exemplo, se todos os 4 ramais estiverem agora no pickup-group 33 e o ramal 5555 tocar, qualquer ramal pode apertar GPickup 2 vezes para capturar a chamada.

Directed Call Pickup e Pickup/GPickup softkeys

No caso do directed call pickup, existe uma outra forma de configurá-lo. Dentro de telephony-service, podemos colocar a linha service directed-pickup, que vai permitir com que seja possível capturar chamadas usando Pickup + Ramal, mesmo que os ramais estejam em grupos diferentes. Caso isso esteja habilitado, na situação do Local Group Pickup (situação 2) a tecla que funcionará é o GPickup. Caso a gente desabilite o comando com um no service directed-pickup, a tecla PickUp passará a funcionar no Local Group Pickup.
No CME 7.1, há ainda outra forma de mudar o comportamento das teclas Pickup e GPickup. Esse mesmo comando service directed-pickup possui um argumento opcional que é o gpickup: service directed-pickup gpickup. Dessa forma, é o GPickup que passará a ser o softkey para invocar o directed call pickup. Ainda bem que na prova o CME é o 7.0! hehehe

B-ACD

O B-ACD é outra feature muito útil que podemos configurar no CME, e que com certeza pode ser testada no LAB. Basicamente, são scripts TCL desenvolvidos pela própria Cisco e executam duas funções: Auto Atendimento (Pressione 1 para isso, 2 para aquilo, etc) e tratamento de filas em Hunt Groups, coisa que o CUCM não faz (bom, fazia com o Auto Attendant até a versão 7.x, mas na 8.x não mais).
Portanto, o funcionamento dessa aplicação se da através de dois scripts, que você pode baixar através do seu CCO no site da Cisco. Esses dois scripts são:
app-b-acd-aa-2.x.x.x.tcl: Faz a parte do Auto Atendimento (AA)
app-b-acd-2.x.x.x.tcl: Faz o tratamento de filas
Dentro do arquivo zip, tem também alguns audios prontos, no formato .au.

Antes de começar a configurar o B-ACD, que é o foco desse post, vamos primeiro criar a dial-peer que será usada para chegar na aplicação, lembrando que podemos chamar uma aplicação apenas nas dial-peers de entrada. No exemplo, criarei uma voip dial-peer com incoming called-number 3000 (dial-peer de entrada) e ao mesmo tempo um destination-pattern 3000 apontando de volta para o roteador (dial-peer de saída). Logo, essa dial-peer serve tanto para entrada quanto para saída. Poderiamos ter criado 2 dial-peers separadas, mas desse jeito fica mais fácil e rápido. O nome aa em service tem que ser o mesmo que o da aplicação AA que configuraremos mais pra frente.

dial-peer voice 3000 voip

 service aa

 destination-pattern 3000

 session-target ipv4:10.10.10.1 # IP do roteador

 incoming called-number 3000

 dtmf-relay h245-alphanumeric

 codec g711ulaw

 no vad

E agora vamos configurar os nossos hunt groups no CME. Lembrando que se for ter telefone SIP dentro do hunt, precisamos configurar o voice hunt-group ao invés do ephone-hunt.

ephone-hunt 1 longest-idle     #  Vendas

 pilot 3331

 list 3050, 3051, 3052, 3053

 timeout 10

ephone-hunt 2 longest-idle     # Marketing

 pilot 3332

 list 3054, 3055, 3056, 3057

 timeout 10

voice hunt-group 3 parallel    # Suporte

 pilot 3333

 list 3058, 3059, 3060

 timeout 10

Agora sim vamos configurar as aplicações de AA e Queue:

QUEUE

application

 service queue flash:app-b-acd-2.1.2.3.tcl # Apontar o diretório corretamente

  param number-of-hunt-grps 3 # Max numero de hunt groups que a aplicação suportará (1 a 10)

  param queue-len 15  # Tamanho da fila (1 a 30)

  param aa-hunt1 3331 # Opção 1 vai para o Hunt 3331

  param aa-hunt2 3332 # Opção 2 vai para o Hunt 3332

  param aa-hunt3 3333 # Opção 3 vai para o Hunt 3333

 

AA

application

 service aa flash:app-b-acd-aa-2.1.2.3.tcl  # Apontar o diretório  corretamente 

   paramspace english location flash:       # Define o pacote de linguas e a localização na flash

  paramspace english index 1                #  Define a categoria do audio para prompts dinamicos. Não usaremos isso no exemplo  

  paramspace english language en            # Define o codigo (en) para os arquivos de audio.

  param service-name queue                  # Faz a associação com a aplicação de fila criada acima (queue)

  param handoff-string aa                   # Especifica o nome do serviço AA para informar o serviço de fila

  param aa-pilot 3000                       # Declara o número do piloto (mesmo da dial-peer)

  param welcome-prompt _bacd_welcome.au     # Prompt de Welcome

  param menu-timeout 5                      # Em segundos (0 a 10)

  param dial-by-extension-option 9          # Habilita o dial-by-extension no menu 9

  param max-extension-length 4              # Limita o numero de digitos de um ramal

  param number-of-hunt-grps 3

  param queue-overflow-extension 3999       # Se a fila estiver cheia, desvia para o 3999

  param second-greeting-time 45             # Depois de 45 segundos, toca o prompt _bacd_allagentbusy.au

  param call-retry-timer 10                 # Quantos segundos a chamada espera para tentar conectar a um hunt ou alternate number

  param max-time-call-retry 90              # Quanto tempo vai esperar na fila

  param max-time-vm-retry 2                 # Quantas vezes a chamada vai tentar chegar no Alternate Number

  param voice-mail 3999                     # Alternate Number. Pode ser um voice mail ou outro ramal

  param send-account true                   # Gera o CDR das chamadas atendidas pelo B-ACD

Resumo do Exemplo: Se alguém ligar no pilot 3000, ouvirá o audio en_bacd_welcome.au. E logo em seguida o en_bacd_option_menu.au (que podemos regravar para ficar compatível com o exemplo). Esse prompt diria: "Pressione 1 para Vendas, 2 para Marketing e 3 para Suporte. Se souber o número do ramal, pressione 9". Se ele pressionar 1, 2 ou 3 e todas as pessoas do grupo estiverem ocupadas (e caso não tenha mais do que 15 pessoas na fila), ele vai tentar conectar a alguém do grupo a cada 10 segundos. Depois de 45 segundos, um novo prompt en_bacd_allagentbusy.au tocará. Se passados 90 segundos e ninguém do grupo atender, a chamada vai ser desviada para o 3999 (param voice-mail). Se o número estiver ocupado, ele vai tentar conectar novamente por 2 vezes. Se não conectar, ele será desconectado e o prompt en_bacd_disconnect.au tocará.
 
DROP THROUGH
Outra forma de configurarmos o AA é o drop throgh. Nessa configuração, o script não vai dar as opções de menu, e ao invés disso conectará diretamente em um hunt group.

application

 service aa flash:app-b-acd-aa-2.1.2.3.tcl

 (...)

  param number-of-hunt-grps 1 ! -- Tem que ser 1, afinal, teremos apenas 1 hunt

  param drop-through-option 1 ! -- Tem que ser o mesmo configurado no aa-huntX na fila

  param drop-through-prompt _dt_prompt.au

Obs: Para o B-ACD funcionar, é necessário que o Music on Hold esteja ativo no CME:

telephony-service

 moh music-on-hold.au