UCCX Scripting: Mandando um e-mail quando o cliente desiste de esperar na fila

Olá pessoal!

Hoje vou fazer mais um post sobre UCCX Scripting, que teve origem em uma demanda real de um cliente. Basicamente o que esse cliente queria era que quando alguém estivesse na sua fila do CCX e, cansado de esperar, desligasse a chamada, um e-mail fosse enviado para o supervisor do atendimento informando o número do cliente, para que a ligação pudesse ser retornada depois.

Hmmm, tricky, heim? Pensei eu com os meus botões... "como vou fazer o script continuar o fluxo quando o cliente encerra a chamada?"

Foi aí que, procurando referências na Internet, cheguei a um exception chamado ContactInactiveException. Esse Exception consegue capturar o fluxo justamente quando o cliente do outro lado da linha encerra a ligação. E com ele, desenvolvi esse script:

/* Variáveis */
String ani
String csqID = "Fila"
Prompt pEspera = P[espera.wav]
Contact Email

ani = Get Call Contact Info (Calling Number)
Select Resource (csqID)
  Queued
    On Exception (ContactInactiveException) Goto ABANDONED
    <LABEL: QUEUE>
    Play Prompt (pEspera)
    Goto QUEUE

<LABEL: ABANDONED>
Email = Create eMail("Chamada perdida de "+ani)
Send eMail(bnonogaki@ngk.com)

E o script no editor ficou assim:

Com isso, quando o cliente desligava a chamada durante a fila, um e-mail era enviado para bnonogaki@ngk.com com o conteúdo "Chamada perdida de <ANI>"

É claro que para isso funcionar, você precisa de ter o licenciamento Premium do CCX (que tem suporte a e-mail), configurar o SMTP no servidor, e permitir o SMTP Relay do CCX no Exchange.

Um scriptzinho simples, e bastante útil... você pode pegar o ANI e alimentar uma campanha de outbound dialer, por exemplo. Aliás, outbound dialer seria um belo tópico para um post futuro! :)

UCCX Scripting: Buscando usuarios no Corporate Directory

Esse é o primeiro post da série de CCX Scripting. Algumas coisas bacanas que podemos fazer com o CCX além de pegar uma chamada e encaminhar para uma fila. Esse post surgiu de uma necessidade real em um cliente, e achei a solução bastante interessante. Fica a dica para quem também estiver precisando.

Basicamente o cliente queria que quando uma chamada entrasse no Call Center, o sistema identificasse o nome da pessoa pelo ramal, e exibisse na tela do agente. O jeito que encontrei para fazer isso é buscar o ramal no Corporate Directory do CUCM, encontrando o nome do usuário. Obvio que a premissa para isso é que os End Users do CUCM estejam propriamente configurados com o ramal certo. Geralmente em implantações com o LDAP integrado, isso já vem certinho.

Segue a lógica de programação abaixo:

/* Variáveis */
Document xmlCorpDirectory
String dirURLCorpDir
String callingNumber
String callingName

Set dirURLCorpDir = "http://X.X.X.X:8080/ccmcip/xmldirectorylist.jsp?n="
callingNumber = Get Call Contact Info (Calling Number)

if ((callingNumber != null && callingNumber.trim() != "")) Then
   xmlCorpDirectory = Create XML Document(URL[dirURLCorpDir + callingNumber])
   callingName = Get XML Document Data (xmlCorpDirectory, "//Name")
   if ((callingName != null && callingName.trim() != "") Then
      /* Continue */
   else
      Set callingName = "Nao identificado"
else
   Set callingName = "Nao identificado"

E como ficou no CCX Editor:

Luciano Tamarozzi, CCIE #41857

Pessoal, abaixo um depoimento do Luciano Tamarozzi, que passou na prova no começo desse ano. Parabéns Luciano!!!

################################################################################

Primeiramente Bruno obrigado pela Oportunidade e Parabéns pelo Blog ele me ajudou muito nesta jornada.
Bom minha trajetória é semelhante a dos demais CCIEs, mas acho interessante compartilhar para que as pessoas que estão estudando tenham alguma referencia, no meu caso cada vez que via um depoimento aqui no Blog ficava mais animado e com vontade de passar.
Minha saga começou no inicio de 2012 quando comecei a montar um LAB em casa, optei por montar por que na época o único link de internet que chegava a minha casa era 3G assim não era possível usar LABs Alugados, levei até Outubro de 2012 para montar e comprei tudo pelo Ebay. Assim que terminei de montar o LAB resolvi comprar os materiais para começar estudar e junto com alguns amigos comprei os materiais do INE.
Assim que compramos o material já iniciei os estudos, a primeira fase de estudos é a hora de você aprender todas as tecnologias contidas Blueprint e nesta fase você não vai a fundo a cada item, por exemplo, você não precisa saber implementar Gatekeeper com todas as variações mas sim entender bem o conceito, esta fase durou 5 meses eu estudava cerca de 2 horas por dia durante a semana e 8 horas em cada dia de folga. 
Então em março fiz a prova escrita, pois já tinha conhecimento sobre todas as tecnologias da contidas na prova, em seguida já iniciei o Workbook 1 do INE nesta parte você aprende todas as variações de cada tecnologia você realmente vai a fundo em cada item e o importante era a precisão e não a velocidade, em paralelo ao Workbook 1 também estava lendo alguns documentos ( Admin Guides e algumas seções do SRND), acabei o workbook 1 em Julho nesta época já estava estudando 4 horas por dia durante a semana e 12 horas cada dia de folga definitivamente já não tinha mais vida Social.
No final de Julho agendei o LAB para final de novembro, comecei então Workbook 2 que são de MOC LABs usei tanto o INE quanto o IPExpert, optei pelos 2 para ser mais efetivo pois quando você faz o LAB varias vezes você acaba decorando e não é tão proveitoso. Durante a semana eu fazia 1 lab em 3 dias, os 2 primeiros eram as configurações e o terceiro era só para a correção, é muito mais efetivo quando você corrige sua prova com a cabeça fria sem o stress de ter feito um monte de configurações, você corrige a prova mais critico. Quem havia indicado esse método foi um amigo que já havia passado no LAB.
Em meados de Setembro já estava comendo tudo com farinha, porem não havia conseguido preparar uma das coisas mais importantes que é a estratégia, nessa época o Bruno lançou 2 posts interessantes sobre estratégia, com base nestes Posts e a Ajuda de outro amigo que estava Estudando consegui desenvolver minha própria estratégia e assim conseguia terminar os LABs em até 4 horas.
Chegando a época da prova peguei férias aonde trabalho e fiquei 100% dedicado ao LAB, então no final de Novembro fui para Sao Jose e fiz minha primeira tentativa, fui bem consegui terminar e testar tudo e sai de lá com a certeza de ter passado, porem quando vi o resultado que havia falhado foi uma surpresa e não sabia aonde poderia ter errado, voltando ao Brasil falei com alguns amigos e consegui entender onde errei porem desanimei, pois não havia mais vagas para fazer o LAB que mudava a versão em fevereiro. No começo de dezembro eu estava no Trem e o Peterson me ligou avisando que abriram algumas vagas em RTP, fui correndo para tentar agendar, mas como eu havia ficado a noite inteira logando para ver se havia vagas, meu login foi bloqueado e só ia liberar no dia seguinte, meus amigos ficaram monitorando as vagas e em cerca de 1 hora só sobrou uma, foi então que liguei para Cisco e pedi para eles agendarem para min depois de muita conversa eles decidiram agendar e marcaram para 05 de janeiro. 

Marcado a próxima tentativa a minha empresa me deu mais 15 dias de Férias o que me ajudou muito a pegar o Ritmo novamente. Chegou a hora do LAB e foram difíceis os primeiros 30 minutos, pois minha mão estava congelada, após isso as configurações renderam bem e consegui terminar o LAB antes do almoço (RTP foi 5 horas antes do almoço), depois foi só corrigir e checar alguns detalhes com o Proctor. Sai de lá com medo, pois na tentativa anterior também havia terminado e testado, ai para aliviar fui à casa de um amigo que mora lá e fizemos um churrasco depois cheguei ao hotel e fui dormir acordei então as 3 da manhã com um e-mail da Cisco informando que o resultado do LAB já estava disponível e para minha alegria havia passado. Não tem palavras para descrever a alegria de ter passado!

O conselho que dou para quem vai tentar é que se prepare tanto Psicologicamente e Financeiramente, como o Bruno disse antes é bom ter dinheiro para 2 ou 3 tentativas se passar antes é lucro. Não estude sozinho procure pessoas que estão estudando para compartilhar experiências, isso me ajudou muito. E não desanime quando falhar, mas sim aprenda com o erro.

Agora estou na torcida dos amigos que irão prestar a prova nos próximos dias e provavelmente teremos mais CCIEs Voice no Brasil.

Gostaria de Agradecer aos Amigos: Sergio Polizer, Peterson, Alan, Fernando Cesar e Emanuel Damasceno. Todos me ajudaram nesta Jornada!

################################################################################

Criptografando o seu SIP Trunk com TLS

Fala pessoal!!!
Primeiramente, gostaria de desejar um feliz 2014!!

Faz bastante tempo que eu num faço um post no blog que não seja relatos de pessoas que passaram na prova. Confesso que é uma forma bastante prática de manter o blog atualizado! hahaha... só que num é só disso que pode viver o blog, né? Por outro lado, o blueprint atual está quase no fim, e não tenho o intuito de ficar me atualizando no blueprint novo para postar coisas relativas à próxima prova (a não ser que eu capitalize o blog e comece a ganhar dinheiro com isso! hahaha).

Portanto, hoje farei um post sobre um assunto que num tem nada a ver com a prova (pelo menos não a atual), mas que eu achei extremamente difícil achar referências boas na Internet quando precisei fazer. É sobre a configuração de um voice gateway SIP criptografado (TLS), usando certificados da estrutura do cliente. O que tem bastante na internet é sobre como fazer usando certificados self-signed do CUCM e Gateway, mas convenhamos que num deployment real, dificilmente isso vai acontecer. Geralmente o cliente tem toda uma estrutura de certificados da empresa para os seus serviços, e pede que a gente utilize essa estrutura.

Ok, serei sincero. Isso definitivamente não é a minha área de especialidade, então certamente tem coisa que pode estar errada. O que mostro abaixo é como eu fiz e deu certo.

Importando os certificados no Roteador

1. Crie um par de chaves (pública e privada) no Voice Gateway, dando um nome qualquer. Sugiro nomear com o próprio Hostname do roteador:

crypto key generate rsa general-keys label <HOSTNAME> mod 2048 exportable

2. Crie um Trustpoint no Voice Gateway, e nomeie ele com o Hostname:

crypto pki trustpoint <HOSTNAME>
 enrollment terminal
 fqdn HOSTNAME.domain.example.com ! - hostname e domínio
 subject-name CN=HOSTNAME.domain.example.com
 revocation-check none
 rsakeypair <HOSTNAME> ! - referencia às chaves criadas  no passo 1

3. Autentique o trustpoint, incluindo certificado Root

crypto pki authenticate <HOSTNAME>

Ao dar o comando, o roteador vai pedir para você colar o certificado root. Esse certificado você deve pedir ao cliente:

Enter the base 64 encoded CA certificate
<COLE A STRING CONTENDO O CERTIFICADO ROOT>

4. Gere o CSR (Certificate Sign Request) do roteador para ser assinado pelo cliente:

crypto pki enroll <HOSTNAME>
%Start certificate enrolment ..
Include serial? No
Include IP Address? No
Display CSR? Yes

O roteador vai gerar uma string, que você deve copiar toda ela num TXT e encaminhar para o cliente assinar no CA dele. Caso seja um Windows, o template deve conter as funções TLS Web Server Authentication, TLS Web Client Authentication e IPSec End System.


5. Quando o cliente enviar o certificado assinado pelo CA dele, importe de volta para o Roteador:

crypto pki import <HOSTNAME> certificate
Enter the base 64 encoded certificate
<COLE A STRING CONTENDO O CERTIFICADO ASSINADO>

Agora vamos fazer a parte dos certificados do CUCM.

Importando os certificados no CUCM

1. No CUCM, entre no OS Administrator. Vá em Security >> Certificate Management

2. Clique em Upload Certificate, e faça upload do Certificado Root para CallManager-trust e tomcat-trust.

3. Clique em Generate CSR e gere os CSRs do CallManager e tomcat.

4. Clique em Download CSR para baixar os arquivos

5. Envie para o cliente assinar no CA dele. Caso seja um Windows, o template deve conter as funções TLS Web Server Authentication, TLS Web Client Authentication e IPSec End System.

6. Quando o cliente mandar os certificados assinados, importe novamente como CallManager e tomcat (sem o trust).

7. Faça isso em todos os servidores do cluster, e depois reinicie tudo.

Configurando o SIP Trunk no CUCM

1. Crie um SIP Trunk Security Profile, marcando a opção Encrypted, com transport type TLS. No X.509 Subject Name, coloque o Hostname e Domain name do roteador, como no exemplo abaixo

2. Crie um SIP Trunk como o usual, mas marque a opção SRTP Allowed, aplique o Security Profile criado acima, e utilize a porta 5061 como Destination Port. Como Device Name do trunk, utilize o Hostname do roteador.

Configurando o SIP Trunk no Gateway

1. Crie a dial-peer voip normalmente, porém com os dois comandos destacados abaixo:

dial-peer voice X voip
 destination-pattern <XXXX>
 session protocol sipv2
 session target ipv4:x.x.x.x:5061
 session transport tcp tls
 srtp fallback
 (...)

2. Configure o SIP-TLS:

sip-ua
 crypto signalling remote-addr <CUCM-Pub> 255.255.255.255 trustpoint <HOSTNAME> strict-cipher
 crypto signalling remote-addr <CUCM-Sub> 255.255.255.255 trustpoint <HOSTNAME> strict-cipher

E pronto!

Troubleshooting

Esses debugs são muito úteis para fazer o troubleshooting do TLS

debug ssl openssl errors
debug ssl openssl msg
debug ssl openssl state
show sip-ua connection tcp tls detail