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

Call Pickup no CUCM

Depois de mais de um mês, finalmente tomei vergonha na cara e resolvi atualizar o blog. Dessa vez vou escrever sobre uma feature que todos nós usamos muito no dia a dia, mas não costumamos aplicá-la de forma muito complexa nos clientes: os grupos de captura.
No CUCM, geralmente colocamos as pessoas de um departamento dentro de um mesmo grupo e boa. Só captura chamada quem estiver dentro do mesmo grupo. Até habilitamos o alerta visual (sonoro jamais! enche o saco! hehe) para facilitar a vida do usuário e tal. Mas e se o usuário quiser capturar chamadas de um outro grupo? Ah não não, aí num dá... hehehe!
O CUCM trabalha com 4 formas de captura, e vou descrever aqui cada uma delas.

1. Pickup
Esse é o Pickup normal. Se uma chamada estiver tocando em um ramal do mesmo grupo, o usuário simplesmente pressiona Pickup e a chamada é capturada.

2. Group Pickup
Esse pickup eu particularmente não acho nada prático, pois os usuários precisam memorizar o número de cada grupo. Mas enfim, se um ramal de outro grupo estiver tocando, o usuário pressiona a tecla GPickup e depois o número do grupo.

3. Other Pickup
Esse aqui já é mais interessante. Na configuração de Pickup Groups, adicionamos uma lista ordenada de grupos relacionados. Digamos que eu esteja no grupo Captura1, e tenha relacionado os grupos Captura2, Captura3 e Captura4 nessa ordem. Aí tem uma chamada tocando no grupo Captura2 e outra no Captura4. Quando eu aperto oPickup (tem que colocar esse softkey no template, porque não vem por default) eu vou capturar a chamada do Grupo2.
O interessante é que o Grupo2 eventualmente pode não ter o Grupo1 associado. Logo, eu vou conseguir capturar as chamadas dele, mas ele não vai conseguir capturar as minhas. Então podemos montar uns relacionamentos mais complexos, como a secretária conseguir capturar as chamadas do chefe e de um departamento X. Só que as pessoas desse departamento X não podem capturar as chamadas do chefe, por exemplo.

4. Directed Call Pickup
Esse é o melhor de todos. A configuração é a mesma que na situação anterior, ou seja, criamos grupos de capturas relacionados. Aí digamos que eu esteja lá no meu grupo Captura1 e quero capturar a chamada do ramal 2222 que está no grupo Captura3. Basta eu apertar GPickup e o Ramal 2222. A gente meio que usa esse método sem saber quando usamos os Speed Dials BLF com a Captura habilitada. Mesmo as duas pessoas não estando no mesmo grupo, se deixamos os grupos relacionados, podemos capturar a chamada simplesmente pressionando a tecla do BLF.

Por fim, para melhorar a experiência do usuário com essa feature, podemos habilitar o Service Parameter "Auto Call Pickup Enabled". Dessa forma, quando o usuário tenta capturar a chamada, ao invés de o telefone dele começar a tocar para ele atender, a chamada conecta direto. É o modo como a maioria dos usuários está mais habituada a trabalhar.

O básico de RSVP

Outra funcionalidade que dificilmente vejo implantada por ai é o RSVP. Então hoje eu vou postar um exemplo simples de configuração desse método de Call Admission Control.

Vamos supor que temos dois sites: Um Head Quarters (HQ) e um Branch Office (Br1). O CUCM fica no HQ, e todos os telefones dos dois sites se registram nesse cluster. Para interconectar esses dois sites temos um roteador em cada ponta fazendo um ponto-a-ponto. Se quiserem, é uma topologia facilmente montada no Dynamips...

Bom, seguindo as boas práticas de implantação, temos um Device Pool pra cada site, a region está setada para que eles se falem em G.729, e cada site tem uma Location também. E é nesse ponto que começa a nossa configuração.

Na Location, não vamos especificar a banda estaticamente, e deixamos o Audio Bandwidth como Unlimited. Porém, em Location RSVP Settings, marcamos a opção Mandatory (Video Desired) entre as locations. As opções que podemos setar lá são:
1. Mandatory: Se ela estiver marcada e não houver banda para uma chamada de video, ela falhará
2. Mandatory (Video Desired): Se ela estiver marcada e não houver banda para uma chamada de vídeo, ela fará o fallback para audio.
3. Optional: Se a chamada de audio ou video falhar por falta de banda, ela passará, porém com outra marcação de DSCP, que definimos dentro dos Service Parameters.
4. No Reservation: RSVP Desligado (opção default)
Obs: Caso você tenha tanto o Location-Based CAC quanto o RSVP habilitados, ele usará os dois. Primeiro checará a banda pelo Location-Based e depois fará o RSVP.

Bom, agora que habilitamos o RSVP, precisamos configurá-lo. Tanto que se nesse momento você fizer uma chamada de audio, ela falhará acusando falta de banda.

Primeiramente precisamos criar os nossos MTPs nos roteadores. Geralmente o MTP vai ser configurado em um roteador que está no meio do caminho do tráfego RTP, porque esse router vai finalizar o RTP nele, e gerar um outro fluxo para frente. No caso, aplicaremos nos nossos roteadores que fazem a conexão com os dois sites. A config do MTP será assim:

sccp local FastEthernet1/0
sccp ccm <IP CUCM> identifier 1 version 7.0+ (ou pelo menos 5.0.1)
sccp
!
sccp ccm group 1
 bind interface FastEthernet1/0
 associate ccm 1 priority 1
 associate profile 1 register mtp_hq / mtp_br1
!
dspfarm profile 1 mtp
 codec g729ar8
 codec g729r8
 rsvp
 maximum sessions software 10
 associate application SCCP

Obs 1: Você deve criar um profile para cada codec. Como aqui no caso estamos trafegando apenas G.729, apenas um profile foi criado.
Obs2: Essa configuração é de um software MTP, ou seja, não é necessário nenhum recurso de hardware, como PVDMs

Depois de criados os nossos MTPs, precisamos configurá-los no CUCM, como Enhanced IOS Software Media Termination Point. Depois colocamos eles dentro de Media Resources Groups, e depois nas Media Resources Group Lists. E aplicamos ao Device Pool de cada site.
Detalhe que o CUCM também tem um MTP dele, certo? E precisamos evitar o seu uso... temos duas alternativas: ou a gente desliga ele pelo Service Parameters >> Cisco IP Voice Media Streaming App, mudando a Run Flag para Off, ou colocamos esse MTP dentro de um MRG que ninguém tem acesso. Porque se você ele deixar fora de um MRG, a sua MRGL vai conseguir enxergá-lo.

Bom, feito isso, agora é só habilitar o rsvp na interface. Então na interface da "WAN", colocamos:
ip rsvp bandwidth X, onde X é a banda.
Para calcular esse X, utilize a fórmula:
X = (n * 24) + 16 para chamadas G.729, onde n é o número de chamadas
X = (n * 80) + 16 para chamadas G.711, onde n é o número de chamadas


Alguns debugs úteis para verificar o rsvp:
debug ip rsvp path
debug ip rsvp resv
show ip rsvp reservation