IPPA (IP Phone Agent)

O IPPA (IP Phone Agent) é uma aplicação que roda no IP Phone, e é uma ferramenta bastante útil na prova, principalmente se as suas questões de CCX precisarem de agentes e filas. Isso porque provavelmente não vai ter um CAD (Cisco Agent Desktop) lá para você colocar um agente em Ready/Not Ready para atender a fila.

Esse serviço funciona como o CAD: o agente pode fazer o Login/Logout, mudar seu status para Ready/Not Ready, ver estatísticas da fila, etc. Tudo através da tela do telefone. É super importante que você saiba como configurar, e principalmente, onde pegar as referências para essa configuração. Afinal, como veremos adiante, você precisa configurar um Phone Service com uma URL, e não faz sentido você decorá-la.

1. Configuração do End User

Depois de você ter o CUCM e o CCX integrados, a primeira coisa que devemos fazer é configurar um usuário como Agente do Contact Center. Para isso, basta entrarmos na configuração do End User, e preencher o campo IPCC Extension:

Aqui cabe uma observação: Como os labs trabalham com Snapshots de VMWare, pode acontecer de o seu CCX estar integrado, mas o campo IPCC Extension não existir. Isso ocorria comigo às vezes nos labs da IP Expert. Se isso acontecer, vale a pena saber como resolver.
Entre na página de documentações da Cisco, que você terá acesso no lab, e navegue em:

Products >> Voice and Unified Communications >> Customer Collaboration >> Cisco Unified Contact Center Products >> Cisco Unified Contact Center Express >> Configuration Examples and TechNotes

Busque por "Extension", e ache o link ICD Extension Option Does Not Appear on the Cisco CallManager Global Directory User Page. Dentro do documento, faça uma busca por "run sql", e você encontrará o seguinte comando para ser executado na CLI do Publisher:

run sql update processconfig set paramvalue="T" where paramname like 'IAQInstalledFlag'

2. Configurando o IPPA

Para configurar o IPPA, entre na página de documentações da Cisco, que você terá acesso no lab, e navegue em:

Products >> Voice and Unified Communications >> Customer Collaboration >> Cisco Unified Contact Center Products >> Cisco Unified Contact Center Express >> Configuration Examples and TechNotes

Busque por "Login", e ache o link Configure a "One Button Login" for IP Phone Agents. Esse link tem o procedimento para configurar o IPPA Normal, e o IPPA com One Button Login, que falarei mais pra frente. Para configurar o IPPA normal, basta criar um novo Phone Service no CUCM: Device >> Device Settings >> Phone Services, da seguinte forma:

A Service URL você pode encontrar no documento acima, no capítulo Procedure. Essa URL é:

http://xxx.xxx.xxx.xxx:yyyy/ipphone/jsp/sciphonexml/IPAgentInitial.jsp

Onde xxx.xxx.xxx.xxx é o IP do CCX e yyyy é a porta, que no caso do IPCC Express, é a 6293.

Depois de associar o serviço no telefone, você poderá vê-lo dentre os serviços do aparelho. Ao ingressar a aplicação, ela pedirá o login, ramal e senha. Assim como também é pedido no CAD:

3. Configurando o One-Button Login


Para evitar de o usuário ter que digitar essas informações (que convenhamos, é bem trabalhosa usando o teclado do telefone), podemos configurar o One-Button Login, onde o usuário, ao ingressar o serviço, já é logado diretamente na aplicação, sem ter que inputar esses dados. O procedimento para isso está no mesmo documento. Procure por "AgentLogin", e ache a URL abaixo:

http://xxx.xxx.xxx.xx:yyyy/ipphone/jsp/sciphonexml/IPAgentLogin.jsp

O IP e porta seguem as mesmas regras acima. IP do CCX e porta 6293.

Crie o serviço exatamente como o procedimento do IPPA normal, mas usando essa outra URL.

E agora precisaremos criar três parâmetros nessa aplicação, que serão: Ext, Pwd e ID. Clique em New Parameter, e configure os parâmetros conforme abaixo (da mesma forma para as 3):

O serviço ficará assim:

Agora basta fazermos o Subscribe do serviço no telefone. Mas veja que teremos alguns campos para preencher:

Agora quando o usuário entrar nesse serviço, ele já fará o login automaticamente, sem a necessidade de entrar o ramal, usuário e senha.

Gravando áudio para os seus prompts

Uma das coisas que a prova pode te pedir em uma questão de CCX é a personalização de um fluxo de atendimento. E consequentemente, você terá que gravar algum áudio (sim, com a sua lindíssima voz falando em inglês). Existem algumas formas de você fazer isso, como por exemplo, criando um Call Handler na Unity, e editando o greeting através de um telefone (através daquela interface Java horrível, que só da pau). Mas a mais fácil e rápida para mim é pelo próprio UCCX. Vamos ver como!

Primeiramente, abra o CCX Script Editor. Crie apenas uma variável do tipo Document chamada rec:
 

E depois disso, crie o seu script assim:

Isso mesmo. Simples assim!
Lembre-se que os steps Accept e Terminate estão dentro do menu Contact, e via de regra, todo script seu deve começar com um Accept e terminar com um Terminate. E o Recording está dentro de Media.

Ao configurar o Recording, você deve basicamente escolher qual será a variável de destino da gravação e colocar em Result Document:

E recomendo mudar o Duration para 30 segundos, na aba Filter, no caso de você ter que gravar um prompt muito grande:

Feito isso, crie uma nova Application referenciando o seu script e configure um Trigger qualquer para ela (obviamente, que não dê conflito com o seu Dial Plan):

Agora basta pegar o seu telefone e ligar para o Trigger. Você ouvirá um beep, e depois disso o áudio já estará sendo gravado. Ao terminar, entre na pasta C:\Program Files\wfavvid\temp do IPCC, e o arquivo WAV estará lá. Ele vai salvar 2 arquivos... o que tiver tamanho maior é o que deve ser usado:

Renomeie o arquivo e ele já estará pronto para ser "uppado" nos prompts para ser usado em outra aplicação. Dessa forma, você não vai gastar nem 3 minutos para gravar um áudio personalizado.

Dicas da vida real

Na vida real evitamos usar esse tipo de mecanismo, pois ao gravar um áudio para um Call Center, a pessoa pode depois processar a empresa exigindo direitos de uso sobre a voz e tal. Ouvi dizer... não sei se é verdade. Em todo caso, recomenda-se a utilização de empresas ou softwares especializados para isso. Se quiser fazer um teste, recomendo o demo do Loquendo, que é free e bastante bom! Se você souber de algum outro, poste nos comentários!

E para edição de áudio, tem um ótimo programa (free) chamado GoldWave. Uma das coisas boas que ele faz é converter qualquer arquivo de áudio para o padrão utilizado pelos produtos da Cisco (CUCM MoH, CCX, Unity Connection). É só abrir o áudio com esse programa, e salvar como Wave, uLaw, 8000 Hz, 64 kbps, mono:

Estrategias - Dial Plan

Meio que continuando o post anterior, hoje falarei sobre Dial Plan. De longe, é o tema mais trabalhoso da prova. Veja que trabalhoso é diferente de difícil! Não é nem um pouco difícil, só tem que fazer tudo com muita atenção. O que vai contar aqui é mais o seu poder de concentração. A minha sugestão é fazer Call Routing antes do almoço, porque aí você vai pro seu lanchinho muito mais leve. Bom, mas tem gente que acha ao contrário... tem gente que prefere fazer tudo antes e deixar o Dial Plan pro final. Mas aí de novo, cada um é cada um.

O problema do Dial Plan é que a prova te dá muita informação, e tudo jogado. Num vai vir assim tudo bonitinho em uma tabela para você ver e configurar. As questões são grandes e a leitura cansativa. Se você chega despreparado, a hora de você lê uma questão dessas bate até um desespero. Mas no fundo é só saber interpretar, e aí novamente entram as tabelas!

Eu baseei a minha estratégia principalmente nas valiosas lições do Vik Malhi no Bootcamp. Tomei como base também esse vídeo do Mathew Berry (o mesmo cara do Device-Based Approach). Incorporei algumas coisas que aprendi fazendo labs, adaptando para uma forma que eu me sentia mais confortável de fazer, principalmente nas dial-peers, como veremos mais adiante. Então repito, nenhuma estratégia é definitiva! Use o que existe na Internet apenas como uma base para você desenhar o seu próprio caminho.

Bom, algumas coisas a saber sobre o Dial Plan:

1) O dial plan da prova não é necessariamente completo. Pode ser que o Site A faça apenas chamadas Locais e DDD, o Site B faça apenas Internacionais e o Site C faça DDD e Emergência. Se a prova te falar isso, configure APENAS isso. Se eles não falarem nada de chamadas Internacionais no Site A, é porque não precisa. Não perca o seu tempo. O Dial Plan da prova não é pra ter sentido mesmo.

2) Na prova, eles pedem para você marcar o Plan e Type do ISDN nas chamadas, coisa que não fazemos no Brasil (especialmente se o link for R2-Digital). Eles geralmente especificam qual é a marcação necessária pra cada tipo de chamada. O que vou escrever aqui é algo que EU acho e não li em lugar nenhum: sugiro que, mesmo que a prova não te peça, marque as chamadas Locais como Subscribe, DDD como National e DDI como International, e plan ISDN (exceto se pedirem para não marcar nada, ou marcar como unknown). É uma sugestão! Até porque perder ponto você num vai... Mas não sei dizer se você perde ponto se deixar de fazer.

3) Mesmo que a prova não fale nada, considere que tudo tem que sair marcado da mesma forma quando o site estiver em SRST. Está implícito!

4) Os tipos de chamadas possíveis na prova são: Emergência, Local, Long Distance (DDD) e International (DDI). E os respectivos TEHOs/Transbordos, ou seja, quando a chamada é originada de um site e sai por outro. E as manipulações incluem o Called Number e o Calling Number.


Tendo isso em mente, vamos às nossas tabelas!

Assim como o Mathew Berry, eu criava uma tabela para cada site. Só que já especificava todos os tipos possíveis de chamadas de cada localidade (incluindo os TEHOs). Ela ficava mais ou menos assim:

Essa tabela lista todas as chamadas possíveis de cada site. Como o dial plan não é completo, a maior parte dela ficará em branco. Sem problemas! Na coluna do Calling, eu escrevo qual é a manipulação do número de origem que a prova quer. E na do Called, a manipulação do número de destino. Veja que independente de onde a chamada vier (do próprio site ou dos outros dois), o Called vai ser o mesmo. Afinal, se a E1 é a mesma, não tem sentido manipular o número de destino dependendo do número de origem.

Bom, e embaixo (na mesma folha) eu fazia uma outra tabela assim:

Basicamente aqui vamos escrevendo o dial plan no Call Manager. Qual consistirá na route pattern, partition, route list, route groups e as manipulações dentro de cada Route Group. Eu não criava nada no CUCM, jogava apenas na tabela e criava tudo de uma vez depois.

A dica do dia é (isso você pode tomar como regra): Sempre que o gateway for H.323, não manipule no Call Manager (a não ser que seja um requerimento da prova). Porque se você fizer isso, a chamada não vai mais funcionar em SRST. Então sempre que possível jogue a manipulação no IOS através de translation-profiles. Quando o gateway for MGCP, aí não tem jeito.

A outra dica (essa já é opcional) é: sempre que for fazer a manipulação no CUCM, faça na Route List/Route Group, e nunca na Route Pattern. Porque às vezes dentro de uma Route List você tem 2 ou mais Route Groups, e para cada um a manipulação ter que ser diferente. Se você fizer na Route Pattern, vai valer para os dois. Use a manipulação na Route Pattern apenas para mudar a forma como a chamada é exibida na tela do telefone, como explicado nesse post.

Beleza! Já temos as nossas duas tabelas. Uma resume todo o dial plan (e é muito útil depois para fazer os testes) e a outra resume as suas rotas no CUCM. Agora falta o gateway (para quando ele for H.323 ou SIP). Nesse caso eu não fazia tabela, eu abria um notepad e ía configurando tudo junto enquanto montava essas duas tabelas.

Primeiro, eu montava um template de configuração, como já falei em posts passados. Assim:

voice translation-rule XXX
 rule 1 // //
voice translation-rule 1XXX
 rule 1 // //
voice translation-profile XXX
 translate calling XXX
 translate called 1XXX
dial-peer voice XXX pots
 translation-profile outgoing XXX

Todas as minhas dial-peers tinham uma translation-rule para Calling (XXX), uma para Called (1XXX), que estavam associadas a um translation-profile XXX. Pode ser que algumas translation-rules ficassem vazias? Sim. Pode ser que tivesse 2 iguais? Sim. Mas não tem problema... a sua configuração não tem que ficar bonita, tem que funcionar. Então antes de começar o Dial Plan, eu digitava esse template no notepad, e ía fazendo as dial-peers na base do Ctrl C, Ctrl V.

Vamos aplicar tudo isso na prática para entendermos melhor.

Vamos supor o seguinte enunciado:

Site A é  H.323. Site B é MGCP.
Ramais no Site A estão no range 3XXX, e E.164 +551123233XXX.
Ramais no Site B estão no range 4XXX, e E.164 +552134344XXX.
Para não extender muito, não vou considerar o Site C nesse exemplo.

Quando o Site A faz chamadas de emergência (190), o número de origem deve ser de 8 dígitos, type subscribe e plan ISDN. Você deve mandar 3 dígitos para a PSTN, com Plan e Type Unknown.

Lendo isso, eu já preencho as minhas tabelas:

E crio a dial-peer no Notepad para o Site A (dica: utilize o Ctrl H para substituir XXX por 190):

voice translation-rule 190
 rule 1 /^\(3...\)$/ /2323\1/ type any subscribe plan any isdn
voice translation-rule 1190
 rule 1 // // type any unknown plan any unknown
voice translation-profile 190
 translate calling 190
 translate called 1190
dial-peer voice 190 pots
 translation-profile outgoing 190
 destination-pattern 190
 no digit-strip
 port 0/0/0:15
 
E o enunciado segue:

As chamadas Locais do Site A devem ser encaminhadas para a PSTN com 8 dígitos, sendo o primeiro de 2 a 9, type subscribe e plan ISDN. O número de origem deve ser os 4 dígitos do ramal, plan isdn e type unkown. Para as chamadas locais, os usuários utilizam o código de acesso 0.

 Aí eu vou la na tabela:

E depois crio a Dial-Peer:

voice translation-rule 29
 rule 1 // // type any unknown plan any isdn
voice translation-rule 129
 rule 1 // // type any subscribe plan any isdn
voice translation-profile 129
 translate calling 29
 translate called 129
dial-peer voice 29 pots
 translation-profile outgoing 129
 destination-pattern 0[2-9].......
 port 0/0/0:15 

E o enunciado segue:

Quando o Site B ligar para algum número do código de área 11 (0011 + 8 dígitos), a chamada deve sair como uma chamada Local no Site A. Nesses casos, o número de origem será 10 dígitos, type national e plan ISDN. Se a chamada falhar, ela deve transbordar para o gateway do Site B como uma chamada DDD. Nesse caso, o número de origem será de 8 dígitos, plan ISDN e type subscribe, e o número de destino será 10 dígitos, type national e plan ISDN.

Aí eu volto pra tabela e faço:

Veja que no Site A, a dial-peer de chamada local já está pronta. O que precisamos é criar a regra do Calling de quando a chamada vem do Site B. Basta alterarmos a translation-rule que faz isso:

voice translation-rule 29
 rule 1 // // type any unknown plan any isdn
 rule 2 /^\(4...\)$/ /3434\1/ type any subscribe plan any isdn


Note que no caso do Site B, como é MGCP, temos que fazer as traduções direto no Route Group. Esse é um exemplo que não poderíamos manipular na Route Pattern, porque afetaria as chamadas que usassem o Route Group RG_SA, e não é isso que queremos. Na Route Group do RG_SA eu apenas manipulei o Called para que o gateway receba a chamada já no formato de chamada Local, para não precisarmos criar outra dial-peer.

Depois que terminamos de preencher todas as tabelas e as dial-peers, o trabalho pesado acabou. Basta aplicar o script das dial-peers nos roteadores, e criar as Partitions, Route Patterns, Route Lists e Route Groups no CUCM. Dá trabalho, mas é braçal, e não precisamos mais usar tanto o cérebro. Coisa de 10 minutos temos tudo pronto.

No começo pode parecer tudo muito complicado, mas vai por mim... não é! É questão de analisar tudo com calma e praticar, praticar e praticar.

Estrategias - As tabelas

Hoje farei um post exclusivamente sobre estrategia, direcionado mais àqueles que já estão quase no finalmente. Não adianta nada você manjar tudo do blueprint tecnicamente se não tem uma estrategia para atacar a prova. E volto a dizer que estrategia é uma questão MUITO pessoal, que cada um deve desenvolver a sua. O importante é ter uma. Por favor, não considere o que vou escrever aqui como uma receita de bolo a ser seguida! Pode pegar como base, mas crie a sua própria receita...

Bom, mas que raios é ter uma estrategia?

Ter uma estrategia é desenvolver um método seu para fazer a prova. Qualquer prova. Não importa como vai ser o exame, e nem o que vai cair. Você tem que seguir uma ordem para fazê-lo, tipo um script. E essa ordem definitivamente não será questão por questão, 1 por 1. Desse jeito não vai dar tempo de fazer tudo.

Um método bastante difundido na Internet é o Device-Based Approach, que realmente acredito que seja o mais rápido. Mas eu particularmente não consegui fazer desse jeito... até tentei algumas vezes nos labs da IP Expert, mas num tem como. Para dar um nó na cabeça é facinho facinho. De qualquer forma, vale a pena ver como é essa estrategia, porque de repente você pode se sentir a vontade com ela.

Bom, a estrategia que usei foi quase um Device-Based approach, uma variação que eu desenvolvi. Seguindo o conselho do Vik Malhi, tentei bolar algumas tabelas para transpor o máximo de informações para um papel, e usar o caderno de questão o menos possível. A ideia é evitar ficar indo e voltando no caderno de questões atrás de informações. Fato é que independente da sua prova, algumas coisas você SEMPRE vai ter que configurar, como Media Resources, H.323/MGCP/SIP, DHCP, NTP, SRST, CUE, etc. O que vai mudar é como a prova vai te pedir para configurar. Os gateways podem ser H.323/MGCP/SIP, o DHCP pode ser na IOS ou no CUCM, o NTP pode apontar para um site, ou para o router da PSTN, enfim... mas qualquer prova sempre vai te dar essas informações para você configurar. Então, ao invés de ficar lendo o enunciado várias vezes, jogue tudo em tabelas de fácil visualização. Tente mapear o máximo que conseguir da prova...

O que eu fazia era, antes de iniciar o exame, pegar o caderno de questões e perder exatos 30 minutos lendo e transpondo os dados. Eu conseguia transpor praticamente tudo nessa primeira leitura, exceto Call Routing, SRST, QoS, UCCX e Presence (e algumas coisinhas mais de features de CUCM e tal). As configurações dos gateways, telefones, Service Parameters, algumas coisas de messaging, eu mapeava tudo. As minhas tabelas ficavam mais ou menos assim:

1) A primeira tabela eu colocava as infos gerais da prova. Era o suficiente para configurar tipo 80% dos roteadores. Praticamente só ficava faltando call routing. Com essas infos eu já conseguia configurar as E1s e T1s, o H.323/ MGCP / SIP, os Media Resources, o NTP, DHCP, e até o setup inicial da CUE. Quando eu começava a de fato fazer a prova, abria um notepad (três, na verdade) e com base nessa tabela já configurava os 3 gateways. Em questão de 15 minutinhos no máximo, os 3 gateways já estavam prontos, e a CUE já estava dando o primeiro boot.

2) A segunda tabela eu colocava as informações dos telefones e ramais. Aí quando eu criava os phones, já tentava deixar o máximo de configuração possível pronta. A ideia era entrar na página de config do telefone 1 vez só. Claro, antes de configurar o telefone, configurava device pools, phone button templates, softkey templates, PTs/CSSs (quando necessário), etc.

3) E a terceira tabela eu colocava basicamente os Service Parameters e Enterprise Parameters, porque sabemos como essas telas demoram para carregar (principalmente Service Parameters). Então já alterava tudo que precisava de uma vez só. Eu também costumava colocar algumas infos de QoS (WAN), mas isso confesso que pensando bem agora, não me ajudava muito... e eu colocava algumas outras coisas também, que seriam mais peculiares de cada prova. Às vezes enquanto você lê o exame, percebe que já é bom deixar algumas coisas no radar, como por exemplo a criação de um Device Pool para o MoH quando tiver Multicast MoH, e tal... aí quando você tiver criando os DPs, já cria esse também.

E por fim, conforme ía lendo a prova, eu listava todas as questões com uma breve (BREVE) descrição e os pontos associados a ela, tipo:

1.1 VLAN (2)
1.2 DHCP (3)
1.3 NTP (3)
(...)

Isso era bem útil porque eu não fazia as questões na ordem (aqui entra um pouco do Device Based Approach). De repente configurando os gateways, eu já matava as questões 3.1, 4.5 e 5.2 por exemplo... aí eu ía lá e marcava um check. Só para saber o que já fiz e o que eu não fiz... e no final me ajudava também para somar os pontos que eu achava que tinha ganho.

Essas 3 tabelas e a lista me ocupavam 1 frente de uma folha de rascunho que te dão na prova (para as 3 tabelas), e metade de uma frente da outra folha. O restante eu usava basicamente para Call Routing, que aí é uma outra história que deixo para um post futuro. A dica que dou é fazer Call Routing separado, vai tomar uma água antes e tal, porque o negócio exige 300% do seu poder de concentração. Então na sua primeira leitura do exame, leia call routing assim beeem por cima, porque certamente você vai ter que voltar lá depois e ler tudo de novo. O mesmo com High Availability, embora algumas coisas você já consiga adiantar na primeira leitura...

E outra coisa que fazia era abrir um notepad e listar as VLANs e IPs. Isso eu fazia no próprio lab da IP Expert para não me acostumar tanto com os IPs da ProctorLabs, que são diferentes dos da prova real. Então eu montava um notepad assim:

Aí sempre que precisava de digitar algum IP, eu fazia Ctrl C desse notepad. Mais para não cair no vicio do IP do lab, e na prova real acabar pondo o IP errado por distração. Ou você simplesmente decora os IPs da prova real, que é facilmente encontrável na Internet! hehehe

[Luto] Evandro Nunes, CCIE Voice #39680

O post de hoje não é sobre o CCIE, nem sobre tecnologia, nem nada disso... É sobre algo muito mais importante do que isso tudo. É um post sobre a vida.

Recebi hoje uma notícia muito triste. Era sobre o falecimento do recém CCIE Voice Evandro Nunes.

O Evandro foi aprovado na prova não tem nem um mês. O seu relato foi recentemente publicado no blog da IP Expert. Ele ainda devia estar vivendo um sonho, o alívio de ter passado nesse exame e conquistado a certificação. Imagino o quanto ele batalhou para concluir esse que talvez fosse o seu último desafio.

Infelizmente não o conheci, mas recebi a notícia com um baque como se fosse meu brother de anos. Talvez o fato de estarmos todos nesse mesmo barco nos aproximam de uma forma quase familiar... Conheço pessoas que o conheceram, que inclusive falaram com ele ontem, e só me dizem coisas boas sobre esse cara. Batalhador, solidário, alegre, estava ajudando muita gente a conquistar o sonho do CCIE! Realmente uma pena termos perdido esse talento.

Deixo aqui as minhas sinceras homenagens a esse cara que realmente correu atrás dos seus objetivos, e que deve servir de inspiração para a galera que está atrás do CCIE.

Descanse em paz, Evandro.

UCCX - Integração com o CUCM

Reparei que nunca fiz nenhum post sobre UCCX no Blog. Falha minha, pois é um tópico que tem muito a ser explorado! Posso cometer um engano ao dizer isso, mas na prova geralmente a integração já vem pronta. Isso não quer dizer que você não precisa saber fazer!!! Pelo contrário, como sabemos, você deve desconfiar de tudo que já vem pronto para você. Então, nesse primeiro post sobre UCCX abordarei sobre a integração com o CUCM, para então poder entrar em outros pontos como configurações de fila e scripts em posts futuros.

Quando terminamos de instalar o CCX pela primeira vez (lembrando que estamos falando aqui da versão 7.0, embora na 8.x não mude tanta coisa, apesar de virar um sistema baseado em Linux), a primeira coisa a fazer é ingressar na sua página de configuração WEB (http://x.x.x.x/appadmin). O usuário inicial é Administrator, e senha ciscocisco. Feito isso, seguiremos os passos abaixo:

1. Escolha o seu tipo de deployment. No caso da prova, utilizaremos o Single Node. Em casos de deployment com High Availability, utilizaríamos First Node e Add to Cluster.

2. Coloque as informações do seu CUCM:

3. Importe a licença:

4. Depois de validar as licenças e ativar os serviços, você deverá colocar as informações de integração entre o CUCM e o CCX. Essa integração utiliza 3 usuários:

Usuário AXL: Pode ser o mesmo que você usa para se logar no CUCM, ou crie um novo Application User no CUCM com permissão de AXL.

Usuário JTAPI: Usuário para se comunicar via CTI com o CUCM. Não é necessário criar manualmente o usuário no CUCM. Crie aqui no CCX, que automaticamente vai aparecer lá nos seus Application Users do Call Manager.

Usuário RmCm: Usuário para fazer o controle dos telefones. Não é necessário criar manualmente o usuário no CUCM. Crie aqui no CCX, que automaticamente vai aparecer lá nos seus Application Users do Call Manager. Lembre-se que quando for configurar um telefone para um agente, esse telefone deve estar associado ao usuário RmCm no CUCM, e essa associação deve ser feita manualmente.

Nessa tela também você deverá configurar o NTP Server, que pode ser o próprio CUCM.

Note que após esse passo, os novos usuários estarão listados no CUCM. Não precisa fazer nenhuma config nesses caras por enquanto, exceto a associação dos telefones no RmCm, como disse anteriormente!

5. Seguindo com o CCX, escolha a quantidade de sessões simultâneas de Historical Reports, Gravações e Outbound Dialer o sistema vai suportar (geralmente nada disso cai na prova), e o Codec (que geralmente é G711). Note que o CCX só suporta 1 Codec! Ou seja, se alguém tentar ligar para o CCX usando G729, vamos precisar de um Transcoder aqui.

6. Escolha a linguagem default do sistema:

7. E por fim o End User do CUCM que será usado para acessar a tela de administração do CCX. Tem que ser End User, infelizmente, e não Application User. Ou seja, se você tiver um CUCM integrado com o AD, esse usuário tem que estar no AD. E se por algum motivo ele for apagado, você perde acesso ao CCX.

8. Pronto, a integração foi feita e você pode fechar o Browser. A partir desse momento, utilize o usuário criado no passo 7 para acessar o sistema.

Ok, como eu disse, provavelmente na prova você não vai precisar fazer nada disso. Já vem tudo pronto! Mas é bom sempre ficar atento aos pontos críticos dessa integração, como os Applications Users e suas senhas (se algo não estiver funcionando, pode ser algum problema nesses usuários, por exemplo), o codec e tal.

Agora vamos criar as CTI Ports e CTI Route Points, que servirão para o CUCM conseguir se comunicar com o CCX. Isso também geralmente vem pronto, mas pode ser que você tenha que fazer algum troubleshooting nessa integração, ou mesmo apagar tudo e criar de novo... Portanto, é importante estar bem familiarizado com isso.

Primeiramente, vamos lembrar que qualquer uma dessas configurações devem ser feitas SEMPRE no CCX. Se tiver que mudar, apagar ou criar algo, é sempre pelo CCX. Este por sua vez fará a atualização das coisas no CUCM... Nunca mude as entidades diretamente no CUCM, ou você pode começar a ter problemas de sincronia.

Vamos lá... a primeira coisa que precisamos criar é um Call Control Group no CCX. Ao criá-lo, novas CTI Ports serão criadas automaticamente no Call Manager. Para isso, entre no CCX com o login definido no passo 7, e navegue até Subsystems >> Cisco Unified CM Telephony >> Call Control Group, e crie um novo. Dentre outras informações, aqui precisamos definir um ID para o grupo no CCX, a quantidade de portas (repare que lá em cima ele fala quantas licenças você tem), o ramal da primeira porta (as demais seguirão sequencialmente a partir desse número), e um prefixo, que vai servir para formar o nome do device no CUCM. Podemos definir outras coisas também como Device Pool (importante para configurar o Codec que será usado nas chamadas para o CCX), MRGL (importante no caso de precisarmos de Transcoder nas chamadas), Partition e Calling Search Space. Essas informações ele vai puxar tudo do CUCM através daquele usuário AXL que configuramos lá em cima.

Veja no CUCM as nossas 12 portas criadas. Se precisarmos alterar algo, como Device Pool, MRGL, faça tudo através do CCX:

Agora precisamos de criar um Trigger no CCX, que vai ser um CTI Route Point no CUCM. Esse Trigger será o ramal para onde os usuário vão ligar para chegar em uma Aplicação do CCX. Então antes de criar o Trigger, criaremos um Application, em Applications >> Application Management >> Add New. Como o foco do post não é a criação de Scripts, vamos utilizar um Script default que já vem no sistema:

Criamos uma aplicação chamada App01 que chama o Script icd.aef. Agora precisamos criar o Trigger, informando qual será o Ramal que estará associado a essa aplicação. Para isso, clicaremos em Add new trigger.

Aqui configuraremos, dentre outras coisas, o número do ramal, a língua, um nome (que será o nome do CTI Route Point), um Call Control Group (que usaremos aquele que criamos acima), Device Pool, Partition, Calling Search Space, etc.

Veja que ao criar esse Trigger, um novo CTI Route Point é criado no CUCM:

E veja também que esse CTI Route Point e os CTI Ports estão associados ao Application User jtapi_1. Tudo foi feito automaticamente:

Com isso, se um usuário ligar no 2000, o CUCM vai invocar uma das CTI Ports para chegar no CCX. Chegando no CCX, a aplicação App01 será invocada, utilizando o script icd.aef.

Essa é a integração básica entre CCX e CUCM. Se algo não estiver funcionando, a primeira coisa que podemos fazer é checar a sincronia e forçar a correção, indo em Subsystems >> Cisco Unified CM Telephony >> Data Resync.

Veja o que acontece por exemplo se eu remover os CTI Ports e CTI Route Points do usuário jtapi_1.

Ao rodar o Data Check, o CCX percebe que a associação não está feita. E ao rodar o Sync, a associação é feita novamente, corrigindo o problema:

Esse foi o meu primeiro post de CCX, bem básico. A partir de agora eu começarei a postar mais coisas, principalmente relacionadas a Scripts.

Translation Pattern ou Transformation Pattern? (Parte 2/2)

No post passado falei sobre Translation Pattern, que é realmente mais simples e parte do nosso dia-a-dia. Recebi até um feedback de que o assunto estava muito fácil! hahaha! A minha ideia inicial era fazer um único texto abordando Translations e Transformations Patterns, mas como estava ficando muito grande, resolvi quebrar em dois. Hoje, portanto, continuo o assunto iniciado na semana passada, e começo as minhas considerações sobre Calling Party Transformation Patterns e Called Party Transformation Patterns, que são igualmente de extrema importancia para a prova.

Transformation Patterns

Existem dois tipos de Transformation Patterns no CUCM, a Called e a Calling. A primeira serve para alterar o número de destino (DNIS) e a segunda para alterar o número de origem (ANI) da chamada. Veja que a única que teria potencial para alterar o roteamento da chamada dentro do Call Manager é a Called, pois todas as entidades do sistema analisam o DNIS para tomar essa decisão, e nunca o ANI.

Bom, no post passado eu disse que se fosse para resumir a diferença entre Translations e Transformations Patterns em uma frase, eu diria que as Transformations Patterns não alteram a decisão de roteamento no CUCM. Pois bem, como vimos anteriormente, as Translations de fato alteram essa decisão de roteamento. Mas as transformations, por sua vez, não. As Called Party Transformation Patterns são utilizadas depois que o Call Manager fez a sua escolha de encaminhamento da chamada, logo antes de ele enviar os digítos para o device de destino, seja ele um Gateway ou um Trunk (Called Party Transformation Patterns não são suportadas para IP Phones). Vejamos graficamente essa difença.

- Translations Patterns (imagem do post anterior):

- Called Party Transformation Patterns:

Repare a diferença. As translations são verificadas primeiro em uma chamada, e elas podem alterar o DNIS (Called Number) e ANI (Calling Number), para depois dar match em uma Route Pattern ou DN. Já as Called Party Transformation Patterns são usadas para alterar o DNIS depois que o Call Manager já decidiu para onde vai a chamada, e é invocada pelo próprio Device (Gateway ou Trunk) no sentido Outbound.

Então por exemplo, você ligou para o número 001123232000 a partir de um IP Phone. Os dígitos deram match em uma Route Pattern, que encaminha para um Gateway H.323 de IP 10.10.1.1. Então a decisão do CUCM já está tomada: ele vai mandar para o 10.10.1.1 e ponto final. Mas antes disso, o Gateway pode chamar uma Called Party Transformation Pattern, e alterar o DNIS para 023232000. Veja que isso não vai mudar em nada as coisas para o CUCM, ele vai continuar mandando a chamada para o 10.10.1.1, só que com o DNIS manipulado.

Ok, falamos das Called Party Transformation Patterns. Mas e as Calling Party Transformation Patterns? Bom, elas servem para alterar o número de origem (ANI), e isso também não vai alterar nada com relação ao roteamento da chamada dentro do CUCM. Os devices que podem chamar uma Calling Party Transformation Pattern são os IP Phones no sentido outbound  e os Gateways/Trunks no sentido inbound ou outbound. Lembrando que Outbound é quando o CUCM envia a chamada para algum lugar, e Inbound é quando alguém envia a chamada para o CUCM. Vejamos as figuras que representam essas situações:

- Calling Party Transformation Patterns (Gateway/Trunk Outbound)

Nessa situação, o CUCM pode modificar o número de origem antes de encaminhar a chamada para um Gateway ou Trunk. Por exemplo, o ramal de origem é o 2000, e ele ligou para o número 022225555 da PSTN. Os dígitos deram match em uma Route Pattern, que encaminha a chamada para um Gateway via H.323. Logo antes de a chamada ser encaminhada, o CUCM muda o ANI de 2000 para 23232000. Veja que o roteamento da chamada não alterou em nada, o CUCM apens mudou o Calling Number antes de encaminhar para o roteador.

Ok, poderíamos fazer isso na propria Route Pattern, certo? Ou até na Route List / Route Group. Mas fazendo no gateway é mais fácil, porque ele aplicaria a regra para TODAS as chamadas que fossem encaminhadas para aquele gateway/trunk específico. Caso seja essa a nossa vontade, é muito mais fácil do que configurar a regra rota a rota, né? No entanto, como já disse um milhão de vezes no post anterior, caso o gateway seja H.323, esse tipo de manipulação é preferível que se faça no IOS, aplicando nas dial-peers, para que continue funcionando em SRST.
Então para a prova, acho difícil você precisar usar a Calling Party Transformation Pattern como Outbound no Gateway/Trunk.

- Calling Party Transformation Patterns (Gateway/Trunk Inbound e Phone Outbound)

Aqui sim a coisa começa a ficar mais útil (e mais essencial para a prova). Nessa situação, tratamos uma chamada entrante da PSTN para um IP Phone registrado no CUCM. Veja que as regras que faremos aqui dependem do CUCM, então não funcionarão em SRST! Isso já é esperado.

Vamos lá... pela imagem podemos ver que a gente consegue manipular os dígitos do ANI em 2 lugares: No gateway, logo que o CUCM recebe a chamada, e no IP Phone, quando o CUCM envia a chamada para ele. Mas qual é a diferença? Ahá... esse é o ponto. A manipulação que ocorre no gateway, na entrada do CUCM, é o número que vai ficar marcado como ANI da chamada. Ou seja, é o que vai ficar registrado na lista de chamadas perdidas ou chamadas recebidas do telefone. Já a manipulação que ocorre no IP Phone é apenas para alterar como o ANI será apresentado ao telefone quando a chamada estiver tocando, mas não terá impacto nas listas de chamadas.

Por exemplo, uma chamada entrante do número 1122225555 da PSTN para o ramal 2000. Na manipulação do Gateway, eu posso fazer esse número de origem virar +551122225555. E na manipulação do IP Phone, eu posso fazer esse número virar 22225555. O resultado disso será o seguinte: enquanto a chamada estiver tocando no telefone, o visor vai mostrar "From: 22225555". Porém, lá na lista de chamadas perdidas/recebidas, vai estar registrado como +551122225555. Assim, o usuário consegue dar um Dial direto da lista (claro, você tem que configurar todo o call routing para suportar o formato +E.164), mas ao mesmo tempo, a chamada será apresentada de uma forma mais amigável no telefone.

Globalization e Localization

Com toda essa informação acima, junto com o post anterior, entramos em um conceito chamado Globalization e Localization, introduzida no CUCM 7, e que a Cisco pega muito pesado na prova. Globalization é isso de transformar o número em um formato global (+E.164, por exemplo +551122225555), e Localization é transformar de volta em um formato local (por exemplo 022225555). A regra é: Globalizar na entrada e Localizar na saída. Com isso, criamos um dial plan com suporte ao +E.164, e totalmente escalável.

Vamos a um exemplo, que configuraremos mais tarde. Aplicaremos de cabo a rabo essa ideia de Globalization e Localization, tanto em uma chamada entrante como em uma chamada sainte:

- Chamada entrante (PSTN --> IP Phone)

Na chamada entrante, usaremos somente o Calling Party Transformation Pattern, alterando o ANI tanto na entrada do CUCM (no Gateway) quanto na saída do CUCM (no IP Phone). A PSTN manda o ANI no formato 1122225555 (que é o caso na maioria das operadoras no Brasil), e no nosso exemplo, o Gateway não faz manipulação nenhuma. Ao chegar no CUCM, o Gateway invoca uma Calling Party Transformation Pattern e altera o ANI para +551122225555. O Call Manager, com posse do DNIS 2000 (que não sofreu nenhuma alteração), acha o DN, que está associado a um IP Phone. Quando o CUCM vai mandar a chamada para o IP Phone, ele chama uma outra Calling Party Transformation Pattern, que altera o ANI de +551122225555 para 22225555. Assim, no IP Phone vai aparecer a chamada "From: 22225555", e nas Call Lists (missed e received calls) vai ficar registrado como +551122225555.

- Chamada sainte (IP Phone --> PSTN)

Na chamada sainte, um IP Phone faz uma chamada para o número 022225555. Para Globalizarmos na entrada, contaremos com a ajuda de uma Translation Pattern, que vai transformar esse número para +551122225555. Por que precisa ser uma Translation e não uma Transformation? Porque queremos alterar isso antes de o CUCM tomar a sua decisão de roteamento. Uma vez globalizado, os dígitos darão match em uma Route Pattern genérica, do tipo \+.!, que enviará para um Gateway usando Local Route Group. A vantagem disso é que podemos ter apenas 1 única Route Pattern no sistema! Olha que beleza... E o gateway por sua vez, invocará uma Called Party Transformation Pattern para localizar os números na saída, ou seja, mudar de +551122225555 para 022225555, por exemplo. Com isso, você cria um dial plan altamente escalável e com suporte ao +E.164, que não faz parte do escopo desse post, mas vai te facilitar MUITO na configuração do AAR e do CFUR. Praticamente você vai ter essas duas features de graça.


Configuração

Agora que temos toda a base teórica, a configuração é muito fácil. Basicamente precisamos de Partitions e Calling Search Spaces. Começaremos fazendo as Calling Party Transformations Patterns (que chamarei a partir de agora de CgPTP), e depois as Called Party Transformation Patterns (a partir de agora, CdPTP).

- Calling Party Transformation Patterns (CgPTP)

Vejamos... precisaremos usar uma no Gateway, e outra no IP Phone, certo? Vamos, portanto, criar duas partitions e duas CSSs:
- CSS-GW-CgPTP {PT-GW-CgPTP}
- CSS-Phone-CgPTP {PT-Phone-CgPTP}

E agora criaremos as Transformations.
A do gateway precisa mudar de 1122225555 para +551122225555. Portanto, podemos fazer o seguinte:

 A do phone precisamos mudar de +551122225555 para 22225555. Portanto, podemos fazer o seguinte:

E aí, basta aplicarmos as CSSs no gateway:

E no phone:

Repare que em ambos eu desmarquei a opção Use Device Pool Calling Party Transformation CSS. Uma outra opção seria aplicar a CSS no Device Pool, e deixar esse campo marcado no Gateway ou no Phone. Mas cuidado, pois a regra pode acabar sendo usada por devices que você não quer. Por isso, eu sugiro marcar no device ao invés de aplicar no Device Pool.

Obs: No gateway, eu configurei a CSS-GW-CgPTP no Number Type Unknown, que é como funciona no Brasil. Na prova, a PSTN manda os dígitos marcados como Subscribe (chamadas locais), National (chamadas DDD) e International (chamadas DDI). Assim você pode (e deve) fazer a globalização sem o uso de CgPTP e CSSs, apenas prefixando os dígitos necessários para cada tipo de chamada. Por exemplo, se a PSTN manda 1122225555 e Type Subscribe, para globalizar basta prefixarmos +55. Se quiser configurar dessa forma no Brasil, é preciso fazer a marcação no gateway através de translation-profiles, por exemplo:

voice translation-rule 10
 rule 1 /^11[2-9].......$/ /&/ type any subscriber
 rule 2 /^[1-9][1-9]/ /&/ type any national
 rule 3 /^00/ /&/ type any international

voice translation-profile ISDNType
 translate calling 10

dial-peer voice 2 voip
 description *** PSTN -> CUCM ***
 translation-profile outgoing ISDNType
 destination-pattern 2...$
 session target ipv4:10.1.1.10
 incoming called-number .
 voice-class codec 1 
 voice-class h323 1
 dtmf-relay h245-alphanumeric
 no vad

- Called Party Transformation Patterns (CdPTP)

Agora vamos fazer a parte das CdPTPs, que são usadas no Gateway, no sentido Outbound. O gateway vai localizar a chamada, mudando de +551122225555 para 022225555. Para isso, também vamos criar uma Partition e uma CSS específica:

- CSS-GW-CdPTP {PT-GW-CdPTP}

Agora a CdPTP:

E aplicamos no gateway, desmarcando a opção Use Device Pool CSS:

E assim finalizo o post sobre Translations e Transformations. Um detalhe que é bom comentar é que o dialed number analyzer do CUCM não funciona com Transformation Patterns, então não use ele para os seus troubleshootings.