RSS

CME FEATURES – Cisco B-ACD

Esse post sobre features de IP Telephony Express, será divididos em duas partes: JOGO RÁPIDO e VISÃO DETALHADA. Abaixo segue uma explicação de cada parte:

EXPLICAÇÃO DAS PARTES DESSE TÓPICO

JOGO RÁPIDO: Para quem já sabe do assunto e/ou está apenas interessado em ver um exemplo de configuração sobre uma determinada feature, essa parte será a indicada, pois basicamente conterá um breve resumo do que é a feature e um exemplo (ou mais de um) de como configurar essa determinada Feature.

VISÃO DETALHADA: Para quem não conhece a feature ou quer aprender um pouco mais sobre ela, pode ir direto para essa parte (sem precisar ler nada do Jogo rápido) pois esta conterá o máximo de informações que eu puder concatenar sobre o assunto, além dos mesmos exemplos da parte anterior.

JOGO RÁPIDO

Esse é um recurso que, ao receber uma chamada em um número pré-determinado, direciona o usuário chamador para um auto-atendimento onde uma saudação é tocada para o usuário. Após essa saudação inicial, o usuário é redirecionado para um menu de opções. Além disso, esse recurso também gerencia uma fila de usuários, para o caso de os atendentes estarem ocupados. É um excelente recurso para o Cisco CME.

COMO CONFIGURAR O CISCO B-ACD:

Passo 1: Transferir um arquivo de Music on Hold para a flash: do CUCME e configurar esse serviço de MoH (lembrando que o arquivo tem que estar no formato .au):

!
telephony-service
moh “flash:music-on-hold.au”
multicast moh 239.10.16.4 port 16384
no create cnf-files
create cnf-files
!
!

Passo 2: Criar um dial-peer para ser usado como entrada e saída para o MoH (Obs: Poderiam ser 2 dial-peers mas, para otimizar será configurado apenas 1 com os comandos para entrada e saída).

!
dial-peer voice 5000 voip
service aa   !! O nome “aa” deve ser o idêntico ao nome do serviço.
destination-pattern 5000   !! Esse deverá ser o ramal do auto-atendimento.
session target ipv4:172.22.10.1   !! Esse deverá ser o IP do próprio CUCME
incoming called-number 5000   !! Esse comando é para indicar que esse dial-peer é de entrada quando a chamada for para o 5000.
dtmf-relay h245-alphanumeric
codec g711ulaw
no vad
!

Passo 3: Baixar os scripts no site da Cisco e transferir para a flash do CUCME. Os arquivos são: app-b-acd-3.0.0.2.tcl (que contém o script gestor de filas) e o app-b-acd-aa-3.0.0.2.tcl (que contém o script de auto atendimento).

Passo 4: Transferir os arquivos de áudio que farão parte do auto-atendimento. Existem alguns arquivos padrões no próprio site da Cisco (dentro da pasta complete file set que foi usado para pegar os arquivos de firmware dos telefones). Para alterar o idioma do AA (Auto-Attendant), o administrador precisará obter os arquivos de audio, convertê-los para o formato .au e renomeá-los para os nomes abaixo:

Obs: Os únicos nomes que podem ser alterados para outro qualquer (lembrando que devem ser referenciados corretamente no scritpt) são os nomes do arquivo de saudação inicial e o nome do script de filas.

  1. Saudação inicial: Quando o script receber a chamada, tocará para o usuário uma saudação inicial. Seria algo do tipo: Olá, obrigado por ligar para nossa empresa. O nome do arquivo é: en_bacd_welcome.au.
  2. Menu de opções: Após a saudação o sistema “dará” aos usuários algumas opções como: Para Suporte técnico, pressione 1 (E desvia para um número que tocará nos telefones desse grupo). Para Financeiro, pressione 2 (e ocorre o mesmo). Para entrar com um ramal desejado pressione 9 (e o usuário poderá discar diretamente um número de ramal). O nome do arquivo é en_bacd_options_menu.au.
  3. Mensagem solicitando o ramal: Quando o usuário selecionar essa opção, o sistema tocará uma mensagem, como por exemplo, “por favor, entre com o ramal desejado”). O nome do arquivo é: en_bacd_enter_dest.au.
  4. Informação de opção incorreta: Se o usuário discar um ramal errado, poderá ouvir uma mensagem de “opção inválida”. O nome do arquivo é: en_bacd_invalidoption.au.
  5. Informação de atendentes ocupados: Se os atendentes estiverem ocupados, o usuário será direcionado para uma fila onde irá ouvir uma música em espera e uma mensagem informando que todos os atendentes estão ocupados. Quando o atendente (ou o primeiro atendente do grupo) desocupar, o sistema tocará no telefone desse atendente automaticamente e encaminhará a chamada quando o mesmo for atendido. O nome do arquivo é: en_bacd_allagentsbusy.au.
  6. Mensagem de desconexão: Por fim, se depois de um período de tempo na fila, o usuário não for atendido ou não pressionar nenhuma opção quando ligar para o número, o sistema tocará outra mensagem informando que não pode atender a solicitação, pede para ligar novamente mais tarde e agradece a ligação. O nome do arquivo é: en_bacd_disconnect.au.

Abaixo, segue a saída do comando dir flash: aqui no CUCME que foi usado para testar essa funcionalidade (destacando em negrito os arquivos que mencionei acima):

CME-PRINCIPAL#dir flash:
Directory of flash0:/

1 -rw- 99098648 Sep 16 2013 08:39:48 +00:00 c2900-universalk9-mz.SPA.152-4.M5.bin
2 -rw- 1930 Nov 1 2013 19:40:06 +00:00 GK1
3 -rw- 4096 Nov 1 2013 16:56:52 +00:00 ._.Trashes
4 drw- 0 Nov 1 2013 16:56:52 +00:00 .Trashes
5 drw- 0 Nov 1 2013 16:56:52 +00:00 .Spotlight-V100
108 -rw- 4096 Nov 1 2013 16:58:44 +00:00 ._c2900-universalk9-mz.SPA.152-4.M5.bin
109 -rw- 130552 Jul 6 2011 21:56:34 +00:00 P0030801SR02.bin
110 -rw- 30421 Apr 2 2014 16:13:16 +00:00 app-b-acd-3.0.0.2.tcl
111 -rw- 458 Jul 6 2011 22:18:14 +00:00 P0030801SR02.loads
112 -rw- 55599 Apr 2 2014 16:13:16 +00:00 app-b-acd-aa-3.0.0.2.tcl
113 -rw- 708460 Jul 6 2011 22:02:24 +00:00 P0030801SR02.sb2
114 -rw- 75650 Apr 2 2014 16:13:18 +00:00 en_bacd_allagentsbusy.au
115 -rw- 130956 Jul 6 2011 21:56:38 +00:00 P0030801SR02.sbn
116 -rw- 83291 Apr 2 2014 16:13:18 +00:00 en_bacd_disconnect.au
117 -rw- 174 Jul 7 2011 14:03:00 +00:00 P0030801SR02.txt
118 -rw- 63055 Apr 2 2014 16:13:20 +00:00 en_bacd_enter_dest.au
119 -rw- 37952 Apr 2 2014 16:13:20 +00:00 en_bacd_invalidoption.au
120 -rw- 496521 Apr 2 2014 16:13:20 +00:00 en_bacd_music_on_hold.au
121 -rw- 123446 Apr 2 2014 16:13:22 +00:00 en_bacd_options_menu.au
123 -rw- 42978 Apr 2 2014 16:13:22 +00:00 en_bacd_welcome.au
122 -rw- 496521 Apr 2 2014 17:44:32 +00:00 music-on-hold.au

Passo 5: Configurar os hunt-groups que irão receber as chamadas, quando o usuário discar uma determinada opção. Como eu utilizei os arquivos padrões da Cisco, no menu de opções eu tenho: Sales (opção 1), Customer Service (opção 2), Dial by extension (opção 3) e falar com um operador (opção 0).
Com base nisso, eu criei no meu CUCME dois hunt-groups, com os ramais 7098 e 7099:

OBS: O ephone-hunt group deve ser configurado sem o comando final, pois esse destino final é determinado pelas configurações do B-ACD, que pode ser um voice-mail, outro ramal ou mesmo a própria desconexão da chamada.

!
ephone-hunt 10 sequential
description Sales
pilot 7098
list 7000, 7001
timeout 10
!
ephone-hunt 11 sequential
description Customer Service
pilot 7099
list 7002, 7003
timeout 10
!

 Passo 6: Configurar a fila onde os usuários ficarão aguardando atendimento, caso os operadores estejam ocupados:

!
application
service queue flash:app-b-acd-3.0.0.2.tcl   !! Comando para “chamar” o script de fila.
param queue-len 15   !! Indica a quantidade de usuários que poderá ficar ao mesmo tempo nessa fila.
param aa-hunt1 7098   !! Comando para indicar a fila do grupo 7098.
param aa-hunt2 7099   !! Comando para indicar a fila do grupo 7099.
param number-of-hunt-grps 2
!
!

 Passo 7: Configurar a auto-atendimento,  onde os usuários receberão a gravação de saudação e as opções do menu.

!
application
service aa flash:app-b-acd-aa-3.0.0.2.tcl   !! Comando para “chamar” o script de auto-atendimento.
paramspace english index 1
param number-of-hunt-grps 2
param menu-timeout 5
param handoff-string aa
param dial-by-extension-option 3   !! Aqui você define o dígito que o usuário vai pressionar para discar direto para uma extensão.
paramspace english language en
param max-time-vm-retry 2
param aa-pilot 5000   !! Define o número usado para auto-atendimento. Deve ser o mesmo do dial-peer criado no passo 2.
param max-extension-length 4
param queue-overflow-extension 3999   !! Número alternativo, caso a quantidade de usuário ultrapasse o máximo para a fila.
paramspace english location flash:
param second-greeting-time 45
param welcome-prompt _bacd_welcome.au
param send-account true
param call-retry-timer 10
param max-time-call-retry 90
param voice-mail 3999   !! Ramal de voice-mail que será usado caso o usuário fique muito tempo na fila de espera.
param service-name queue
!

OBS: Se não existir um voice-mail na rede, você precisa determinar qualquer valor, senão o script não funcionará.

 Passo 8: Testar a URA e correr pro abraço!!!!

VISÃO DETALHADA

Cisco Basic Automatic Call Distribution, carinhosamente chamado de Cisco B-ACD atua em conjunto com o Auto-Attendant (AA). Esses dois serviços são usados para atendimento automático de chamadas (incluindo saudações, menu de opções e a nossas boas e velhas músicas de espera), estatísticas de chamadas e gerenciamento de chamadas em filas baseadas nos grupos de atendimentos que foram configurados. É composto basicamente de 2 scripts TCL (Tool Command Language), um para gerenciamento de saudações e opções e outro para gerenciamento de filas.

Esse serviço é muito útil e pode ser completamente personalizado, independente de qual o ramo empresarial do cliente em questão. Abaixo, coloco dois exemplos de utilização desse serviço:

Exemplo 1: O usuário liga para o número 3131-3649 de uma empresa de TI (fictícia) chamada TI.Com. Quando o CME dessa empresa receber a chamada, desviará para o número piloto de auto-atendimento, onde o cliente ouvirá: “Obrigado por ligar para a TI.Com. Para falar um consultor de vendas, tecle 1; para falar com suporte técnico, tecle 2; para entrar com um ramal específico tecle 3 ou pressione 0 para ser direcionado para um atendente”.

Exemplo 2: O usuário liga para o número 3232-3214 de uma empresa do ramo de doces e salgados (fictícia) chamada Bom Gosto. Quando o CME dessa empresa receber a chamada, desviará para o número piloto de auto-atendimento, onde o cliente ouvirá: “Seja bem vindo ao Bom Gosto. Desde já agradecemos sua ligação. Se deseja fazer uma encomenda, pressione 1; se deseja falar sobre alguma encomenda já feita, pressione 2; para reclamações, dúvidas ou sugestões, pressione 3”.

A quantidade de opções são 10 ao todo seguindo as regras:

  • 10 opções para grupos de atendimentos.
  • 9 opções para grupos de atendimentos com 1 opção para entrar com um ramal desejado.

CARACTERÍSTICAS E LIMITES

As principais características e limites são:

  • Pode ter o máximo de 10 opções.
  • O dígito zero “0” que é a décima opção é reservado para o operator hunt-group, que será explicado na próxima seção.
  • Pode atuar em conjunto com um serviço de correio de voz, onde o usuário poderá ser direcionado para esse correio de voz, caso fique muito tempo na fila de espera.
  • Quando o usuário seleciona uma opção, é direcionado para o grupo referente à opção que ele escolheu. Se algum ramal estiver disponível, passará a tocar automaticamente. Se não houver ramais desocupados, o usuário é direcionado para uma fila, onde ouvirá uma música em espera e, quando um ramal desocupar a chamada, receberá automaticamente a primeira chamada da fila.
  • Se o usuário passar muito tempo na chamada sem escolher nenhuma opção (4 minutos por padrão), ouvirá uma mensagem de desconexão e a chamada cairá.
  • Não há como colocar alguma opção diferente dos tipos disponíveis (por exemplo, não há como pedir para o usuário digitar um código e o sistema buscar esse código em uma base de dados).
  • Enquanto o usuário está na fila de espera, fica ouvindo a música em espera (MoH) e fica ouvindo uma mensagem de áudio informando que todos os usuários estão ocupados durante intervalos de tempo pre-determinados.
  • Esse serviço usa o mesmo codec em dial-peers de entrada e saída, pois o IOS não ativa transconders para chamadas que estão usando aplicações TCL. Não há como utilizar codecs diferentes (por isso que é interessante usar o mesmo dial-peer como dial-peer de entrada e de saída, pois o codec já está definido).
  • Música em espera, através de uma fonte ao vivo não é suportado pelo CME 3.3.
  • Somente pode haver um script de fila por CME com o máximo de 10 filas. Cada fila comporta no máximo 30 chamadas em espera.

ITENS DE INTERESSE

É importante saber o que você está configurando, e entender todos os componentes envolvidos. Aqui no Cisco B-ACD temos:

  • Auto-Attendant: É o principal item do B-ACD. É o script que irá responder as chamadas através de um número piloto, tocar os arquivos de áudio necessários e enviar os usuários para as filas de atendimento. Um AA precisa ter um número piloto que seja único na rede e é composto de uma mensagem de saudação, menu de opções (com o máximo de 10 opções), mensagem de erro de digitação e mensagem de desconexão.
  • Múltiplos Auto-Attendants: Existe a possibilidade de configurar múltiplos AAs, cada um com o seu número piloto específico. Porém, como pode-se ter apenas 1 script de fila por CUCME, o máximo de 10 opções no menu vale para todos os AA. Isso significa que podemos configurar 3 AAs, cada um com 3 grupos diferentes neles ou podemos configurar vários AAs e compartilhar os grupos de atendimentos entre eles. Não importa como você queira fazer, sempre pode-se usar no máximo 10 grupos de atendimento diferentes. Detalhe importante: Com múltiplos AAs, deve-se criar um arquivo de welcome diferente para cada um, ou seja, nesse caso, pode-se alterar o nome padrão dos arquivos (apenas o welcome) para diferenciá-los. Por exemplo, pode-se ter um AA atendendo no ramal 5000 com o arquivo en_bacd_welcome5000.au e um no ramal 5999 com o arquivo en_bacd_welcome5999.au. Os demais arquivos de áudio permanecem com os mesmo nomes.
  • Menu de opções: É o arquivo de áudio composto pelas instruções para guiar o usuário dentro do sistema de auto-atendimento. Pode conter no máximo 10 opções. Entre essas opções o dígito zero (0) sempre irá mapear o operador (explicado no próximo item) e a discagem direta para ramal.
  • Operator hunt group: Um tipo diferente de operador, normalmente usado para atender aos clientes que não se “encaixaram” em nenhuma opção ou não souberam qual escolher. O script determina que o hunt-group com maior valor de dígito será o operator hunt-group. Por exemplo, se temos a opção 1 para vendas e a opção 2 para suporte e o usuário selecionar 0 (para falar com o operador) o script mandará a chamada para o grupo da opção 2 (pois tem o dígito de maior valor). É importante saber disso, para organizar suas opções de menu.
  • Discagem direta para ramal: Opção em que o usuário pode discar diretamente para um ramal, sem precisar falar com nenhum operador. O comando param dial-by-extension-option 1 (onde o número é o dígito que o usuário selecionará) é o que define o que o usuário deve pressionar para acionar essa opção.
  • Filas de atendimento: É um script que comanda um hunt-group do CUCME, transformando-o em uma fila com o máximo de 30 chamadas em espera. O número máximo de hunt-groups que o script aceita é 9. Quando o AA recebe uma chamada e o usuário seleciona uma opção para falar com algum grupo de atendimento (como suporte técnico, por exemplo), o script AA desvia a chamada para o Scritp de filas (queue) e esse script irá tentar acionar algum ramal do hunt-group associado à opção que o usuário digitou. Caso tenha algum disponível, o script toca esse telefone e desvia quando a chamada é atendida. Caso não tenha nenhum usuário disponível, o script coloca o usuário em uma fila onde o mesmo ouvirá uma música em espera e uma mensagem informando que todos os atendentes estão ocupados. Paralelo a isso, o script continuará tentando acionar algum ramal do grupo. Caso nenhum ramal fique disponível no tempo configurado ou ninguém atenda, o script de fila utiliza o método de encerramento que pode ser enviando para uma caixa postal compartilhada ou simplesmente toca uma mensagem de desconexão de encerra a chamada. Se a fila de um determinado grupo estiver completamente ocupada (ou seja, o máximo de chamadas em espera foi atingido), o usuário receberá um tom de ocupado. Se todos os atendentes de um grupo não estiverem disponíveis (desligados, por exemplo) o script enviará o usuário diretamente para um destino alternativo configurado. Com o script de fila, você também tem a opção de ativar um debug de chamadas.
  • Forma de saída da fila: Caso todos os atendentes estejam ocupados e o número máximo de usuários estiver sido alcançados, você pode usar a segunda saudação (usada para informar que todos os atendentes estão ocupados) para criar um segundo menu com até 3 opções para o usuário sair da fila. Por exemplo, pode-se dizer: “no momento, todos os nossos operadores estão ocupados. Caso deseje ouvir outras opções, pressione 5, para deixar uma mensagem pressione 6, ou pressione 7 para falar com um operador (e direciona para o operator hunt group). Isso é feito usando a mensagem de atendentes ocupados e deve ser nomeada da forma como será indicada mais a frente.
  • Destino Alternativo: É um ramal que receberá a chamada caso todos os operadores estejam indisponíveis, caso o tempo máximo na fila tenha sido atingido pelo usuário ou o número máximo de chamadas na fila de espera foi atingido. Nesse caso, esse destino alternativo pode ser um correio de voz acessível por todos os usuários do grupo em questão. Quando a chamada é direcionada para esse destino, ela não será mais controlada pelos scripts do B-ACD. Se até mesmo o destino alternativo não estiver disponível, então a chamada é desconectada. Vale lembrar que o número configurado como destino alternativo deve ser especificado como um dial-peer alcançável pelo CME.
  • Pilot Number: Especificado no comando param aa-pilot, esse é o número que ativará o auto atendimento. Para cada auto-atendimento, um número único deverá ser especificado. Lembrando que podemos ter vários auto-atendimentos com opções diferentes, mas obrigatoriamente números diferentes.
  • Arquivos de áudio: Quando a chamada é atendida pelo pilot number o usuário escuta uma saudação que nada mais é do que um arquivo de áudio contendo uma gravação. O mesmo vale para o menu de opções e demais itens que os usuários escutam. Quando você baixa os arquivos, eles vêm com nomes específicos que não devem ser alterados (pois já foram escritos no script que não deve ser alterado a não ser que você queira ter muito trabalho). A exceção para essa mudança é o arquivo _bacd_welcome.au, pois ele é definido em um comando. Ou seja, se quiser gravar arquivos de áudio personalizados, você deve nomeá-los da mesma forma que os arquivos padrões e os substituir na flash do CUCME. Os arquivos de áudio possuem as seguintes características: formato .au (G.711) com 8-bit, mu-law e codificação de 8 khz. Os programas indicados pela Cisco para gravação desses arquivos de áudio são: Adobe Audition for Microsoft Windows e AudioTool for Solaris.
  • Ephone hunt group: É principal item usado como  “destino” dos usuários que selecionam alguma opção do menu. O máximo de 10 hunt-groups pode ser usado com o serviço de filas do B-ACD. Para associar um dígito a um grupo, o comando é param aa-hunt1 XXXX, onde hunt1 indica que o digito 1 será utilizado para o ramal XXXX (que deverá ser um número :D).
  • Modo drop-through: O usuário ouve uma saudação e já cai direto em um hunt-group, sem precisar selecionar nenhuma opção. Pode ser configurado em conjunto com um outro menu de opções, mas precisará ter um AA específico com um pilot number diferente.

COMO CONFIGURAR

Para essa configuração, eu resolvi fazer um menu contendo desvio para 5 grupos diferentes, opção de ligar diretamente para um ramal específico e a opção 0 (padrão) desviando para o operator hunt group (que nada mais é do que o grupo com o maior número de identificação). O número associado ao meu Auto-Attendant é o 8999. Eu organizei essa parte da seguinte forma:

  • TOPOLOGIA DESSA CONFIGURAÇÃO: Onde explico como ficou, logicamente, a disposição dos meus usuários e ramais.
  • ESQUEMA DO MENU: Onde mostro quais as opções que os usuários irão ouvir, bem como quais os seus destinos.
  • PASSO A PASSO: Onde mostro o script e explico os itens de maior importância.

TOPOLOGIA DESSA CONFIGURAÇÃO

TOPOLOGIA

Observe na topologia que foram criados 5 grupos com 2 ramais dentro de cada. Há também um sistema de correio de voz, que irá receber as chamadas que não forem atendidas. O número do voice mail é 7000.

ESQUEMA DO MENU

Abaixo segue o esquema explicativo do Menu. O AA irá atender no ramal 8999. Quando isso ocorrer, tocará a saudação inicial e depois seguirá o esquema abaixo:

ESQUEMA DO MENU

PASSO A PASSO

Para a configuração, estou partindo do pressuposto que os seus ramais já estejam configurados e comunicando entre si normalmente. Afinal, normalmente esse serviço é um adicional a uma rede já existente.

Então, vamos que vamos!!! Estou utilizando aqui, 11 telefones 7940 e 1 SoftPhone.

Passo 1: Primeiro, temos que decidir os principais pontos da configuração:

  1. Nome do serviço de call-queueAqui, resolvi deixar no padrão.
  2. Decidir quantos Auto-Atendimentos serão configurados. Decidi fazer apenas um AA.
  3. Decidir o nome e o número para cada auto-atendimento. Decidi deixar com o nome aa e o número piloto 8999.
  4. Pensar nos parâmetros de call retry. Deixei um callretry de 10 segundos e um maximum call-retry de 90 segundo. Ou seja, o script de fila tentará 9 vezes reenviar a chamada para um atendente até “desisitir” e enviar para um destino alternativo.
  5. Escolher um destino alternativo, caso o grupo esteja indisponível ou o maximum call retry expire. Nesse caso, usarei uma rota para um serviço de correio de voz, cujo ramal é o 7000. Obs: Se não houver nenhum servidor de correio de voz ou mesmo um ramal para essa funcão, você deverá escolher um ramal (mesmo que não exista na sua rede), pois esse é um comando obrigatório e somente é aceito se no final houver um número de ramal.
  6. Escolher quantas chamadas em espera as filas comportarão. Nesse caso deixarei o máximo de 10 chamadas por fila.
  7. Decidir se haverá a opção para discar diretamente para um ramal. SIM!!!
  8. Decidir se haverá um menu de opções ou se apenas tocará um prompt. Nesse exemplo, será com menu.

Passo 2: Garantir que o serviço de música em espera esteja ativo e funcionando. Para isso, caso esse serviço não esteja ativo, basta transferir um arquivo de Music on Hold para a flash: do CUCME (tem um arquivo padrão da cisco dentro do complete file set) e configurar esse serviço de MoH (lembrando que o arquivo tem que estar no formato .au):

!
telephony-service
moh “flash:music-on-hold.au”   !! Habilita o serviço de Moh para as chamadas oriundas da PSTN.
multicast moh 239.10.16.4 port 16384   !! Habilita o serviço para chamadas internas.
no create cnf-files
create cnf-files
!
!

Passo 3: Criar um dial-peer para ser usado como entrada e saída para o MoH (Obs: Poderiam ser 2 dial-peers mas, para otimizar será configurado apenas 1 com os comandos para entrada e saída).

!
dial-peer voice 8999 voip
service aa   !! O nome “aa” deve ser o idêntico ao nome do serviço.
destination-pattern 8999   !! Esse deverá ser o ramal do auto-atendimento.
session target ipv4:172.22.10.1   !! Esse deverá ser o IP do próprio CUCME
incoming called-number 8999   !! Esse comando é para indicar que esse dial-peer é de entrada quando a chamada for para o 5000.
dtmf-relay h245-alphanumeric
codec g711ulaw
no vad
!

Passo 4: Criar um dial-peer apontando para o serviço de correio de voz. Obs: Embora o ramal de rota alternativa seja obrigatório, a rota em si não é. Ou seja, se você não tiver um servidor de correio de voz, precisará indicar um ramal qualquer no comando de rota alternativa, mas NÃO precisará criar um dial-peer para isso.

!
dial-peer voice 7000 voip
destination-pattern 7000
session target ipv4:172.22.10.10   !! Esse deverá ser o IP do servidor de Voice Mail.
dtmf-relay sip-notify   !! Esse servidor usa SIP.
session protocol sipv2 !! Esse servidor usa SIP.
codec g711ulaw
no vad
!

Passo 5: Baixar os scripts no site da Cisco e transferir para a flash do CUCME. Os arquivos são: app-b-acd-3.0.0.2.tcl (que contém o script gestor de filas) e o app-b-acd-aa-3.0.0.2.tcl (que contém o script de auto atendimento).

Passo 6: Transferir os arquivos de áudio que farão parte do auto-atendimento. Existem alguns arquivos padrões no próprio site da Cisco (dentro da pasta complete file set que foi usado para pegar os arquivos de firmware dos telefones). Para alterar o idioma dos arquivos de áudio do AA (Auto-Attendant), o administrador precisará obter os arquivos de audio (gravando-os preferencialmente com os programas que a Cisco indica, que são o Adobe Audition e o Solaris Audio Tool), convertê-los para o formato .au e renomeá-los para os nomes abaixo:

Obs: Os únicos nomes que podem ser alterados para outro qualquer (lembrando que devem ser referenciados corretamente no scritpt) são os nomes do arquivo de saudação inicial e o nome do script de filas.

  1. Saudação inicial: Quando o script receber a chamada, tocará para o usuário uma saudação inicial. Seria algo do tipo: Olá, obrigado por ligar para nossa empresa. O nome que o arquivo que usei foi o en_bacd_welcome.au.
  2. Menu de opções: Após a saudação o sistema “dará” aos usuários algumas opções como: Para Suporte técnico, pressione 1 (E desvia para um número que tocará nos telefones desse grupo). Para Financeiro, pressione 2 (e ocorre o mesmo). Para entrar com um ramal desejado pressione 9 (e o usuário poderá discar diretamente um número de ramal). O nome do arquivo deverá ser en_bacd_options_menu.au.
  3. Mensagem solicitando o ramal: Quando o usuário selecionar essa opção, o sistema tocará uma mensagem, como por exemplo, “por favor, entre com o ramal desejado”). O nome do arquivo é: en_bacd_enter_dest.au.
  4. Informação de opção incorreta: Se o usuário discar um ramal errado, poderá ouvir uma mensagem de “opção inválida”. O nome do arquivo é: en_bacd_invalidoption.au.
  5. Informação de atendentes ocupados: Se os atendentes estiverem ocupados, o usuário será direcionado para uma fila onde irá ouvir uma música em espera e uma mensagem informando que todos os atendentes estão ocupados. Quando o atendente (ou o primeiro atendente do grupo) desocupar, o sistema tocará no telefone desse atendente automaticamente e encaminhará a chamada quando o mesmo for atendido. O nome do arquivo é: en_bacd_allagentsbusy.au.
  6. Mensagem de desconexão: Por fim, se depois de um período de tempo na fila, o usuário não for atendido ou não pressionar nenhuma opção quando ligar para o número, o sistema tocará outra mensagem informando que não pode atender a solicitação, pede para ligar novamente mais tarde e agradece a ligação. O nome do arquivo é: en_bacd_disconnect.au.

Abaixo, segue a saída do comando dir flash: aqui no CUCME que foi usado para testar essa funcionalidade (destacando em negrito os arquivos que mencionei acima):

CME-PRINCIPAL#dir flash:
Directory of flash0:/

1 -rw- 99098648 Sep 16 2013 08:39:48 +00:00 c2900-universalk9-mz.SPA.152-4.M5.bin
2 -rw- 1930 Nov 1 2013 19:40:06 +00:00 GK1
3 -rw- 4096 Nov 1 2013 16:56:52 +00:00 ._.Trashes
4 drw- 0 Nov 1 2013 16:56:52 +00:00 .Trashes
5 drw- 0 Nov 1 2013 16:56:52 +00:00 .Spotlight-V100
108 -rw- 4096 Nov 1 2013 16:58:44 +00:00 ._c2900-universalk9-mz.SPA.152-4.M5.bin
109 -rw- 130552 Jul 6 2011 21:56:34 +00:00 P0030801SR02.bin
110 -rw- 30421 Apr 2 2014 16:13:16 +00:00 app-b-acd-3.0.0.2.tcl
111 -rw- 458 Jul 6 2011 22:18:14 +00:00 P0030801SR02.loads
112 -rw- 55599 Apr 2 2014 16:13:16 +00:00 app-b-acd-aa-3.0.0.2.tcl
113 -rw- 708460 Jul 6 2011 22:02:24 +00:00 P0030801SR02.sb2
114 -rw- 75650 Apr 2 2014 16:13:18 +00:00 en_bacd_allagentsbusy.au
115 -rw- 130956 Jul 6 2011 21:56:38 +00:00 P0030801SR02.sbn
116 -rw- 83291 Apr 2 2014 16:13:18 +00:00 en_bacd_disconnect.au
117 -rw- 174 Jul 7 2011 14:03:00 +00:00 P0030801SR02.txt
118 -rw- 63055 Apr 2 2014 16:13:20 +00:00 en_bacd_enter_dest.au
119 -rw- 37952 Apr 2 2014 16:13:20 +00:00 en_bacd_invalidoption.au
120 -rw- 496521 Apr 2 2014 16:13:20 +00:00 en_bacd_music_on_hold.au
121 -rw- 123446 Apr 2 2014 16:13:22 +00:00 en_bacd_options_menu.au
123 -rw- 42978 Apr 2 2014 16:13:22 +00:00 en_bacd_welcome.au
122 -rw- 496521 Apr 2 2014 17:44:32 +00:00 music-on-hold.au

Passo 7: Configurar os hunt-groups que irão receber as chamadas, quando o usuário discar uma determinada opção. Para esse exemplo eu configurei os seguintes grupos: Como eu utilizei os arquivos padrões da Cisco, no menu de opções eu tenho: Vendas (opção 1), Suporte (opção 2), Recursos Humanos (opção 3), Financeiro (opção 4), Service Desk (opção 5), Discar direto para um ramal (opção 6) e falar com um operador (opção 0).
Com base nisso, eu criei no CUCME cinco hunt-groups, com os ramais 8000, 8010, 8020, 8030 e 8040:

OBS: O ephone-hunt group deve ser configurado sem o comando final, pois esse destino final é determinado pelas configurações do B-ACD, que pode ser um voice-mail, outro ramal ou mesmo a própria desconexão da chamada.

!
ephone-hunt 10 sequential
description Vendas
pilot 8000
list 8001, 8002
timeout 10   !! Tempo que a chamada permanecerá em um número do grupo. Após isso, tentará no próximo número do grupo.
!
ephone-hunt 11 sequential
description Suporte
pilot8010
list 8011, 8012
timeout 10
!
ephone-hunt 12 sequential
description Recursos Humanos
pilot 8020
list 8021, 8022
timeout 10
!
ephone-hunt 13 sequential
description Financeiro
pilot 8030
list 8031, 8032
timeout 10
!
ephone-hunt 14 sequential
description Service Desk
pilot 8040
list 8041, 8042
timeout 10
!

Passo 8: Configurar a fila onde os usuários ficarão aguardando atendimento, caso os operadores estejam ocupados. Esse mesmo script também indica qual a opção de cada grupo de atendimento. Por isso, muita atenção nesse ponto.

Obs: Vale informar que estamos trabalhando com scripts TCL. De acordo com a Cisco (e os meus testes 😀 ) esses comandos não possuem os mesmos comportamentos dos outros comandos de IOS. A Cisco destaca o seguinte:

  • Não suportam tab para completar o comando automáticamente.
  • Você não recebe uma informação de erro com o nosso bom e velho “^” informando o local do erro.
  • Você não tem o recurso de ajuda quando digita interrogação “?”.
  • Se você não colocar o script com as letras (case sensitive!) e os parâmetros corretos, o script simplesmente não funciona sem dar nenhum vestígio do o porque!!! Chatinho né!!! Mas vale a pena o esforço, é simplesmente muito legal esse recurso.

 

!
application
service queue flash:app-b-acd-3.0.0.2.tcl   !! Comando para “chamar” o script de fila. Esse
queue, é exatamente o local onde indicamos o nome o serviço. Pode ser alterado, mas deve ser referenciado corretamente em outro comando mais abaixo.
param queue-len 10   !! Indica a quantidade de usuários que poderá ficar ao mesmo tempo nessa fila.
param aa-hunt1 8000   !! Comando para indicar a fila do grupo 7098. O range do aa-huntX é 1 a 10.
param aa-hunt2 8010   !! Comando para indicar a fila do grupo 7099.
param aa-hunt3 8020    !! Comando para indicar a fila do grupo 7098.
param aa-hunt4 8030   !! Comando para indicar a fila do grupo 7099.
param aa-hunt5 8040   !! Comando para indicar a fila do grupo 7099.
param number-of-hunt-grps 5   !! Atenção a esse comando pois deve coincidir com a quantidade de filas que estamos criando.
!

COMANDOS OPCIONAIS

param queue-manager-debugs 1   !! Comando que indica se será habilitado ou não a coleta de debugs. “0” desabilita e “1” habilita. Para capturar esses logs, deve-se usar o comando debug voip application script no modo de configuração privilegiado, router#.

Passo 9: Configurar a auto-atendimento,  onde os usuários receberão a gravação de saudação e as opções do menu.

!
application
service aa flash:app-b-acd-aa-3.0.0.2.tcl   !! Comando para “chamar” o script de auto-atendimento. O “aa” deve ser  o mesmo que foi informado no dial-peer do Auto-Atendant, no comando service aa.
paramspace english index 1
param number-of-hunt-grps 5
param menu-timeout 5   !! Quantidade de vezes que o menu será repetido para o usuário, antes de o script “desistir” de aguardar o usuário selecionar uma opção e enviar para o operator group.
param handoff-string aa   !!! O “aa” deve ser  o mesmo que foi informado no dial-peer do Auto-Atendant, no comando service aa.
param dial-by-extension-option 6   !! Aqui você define o dígito que o usuário vai pressionar para discar direto para uma extensão.
paramspace english language en   !! Indica a linguagem dos arquivos. Melhor deixar em inglês mesmo.
param max-time-vm-retry 2
param aa-pilot 8999   !! Define o número usado para auto-atendimento. Deve ser o mesmo do dial-peer criado no passo 2.
param max-extension-length 4   !! Define a quantidade de dígitos que o usuário poderá pressionar quando selecionar a opção para discar direto para um ramal.
param queue-overflow-extension 7000   !! Número alternativo, caso a quantidade de usuário ultrapasse o máximo para a fila.
paramspace english location flash:  !! Indica o local onde os arquivos de áudio estão armazenados.
param second-greeting-time 45   !! Define o intervalo de tempo que a mensagem de que todos os agentes estão ocupados repetirá quando o usuário estiver na fila de espera.
param welcome-prompt _bacd_welcome.au   !! Indica o arquivo de saudação inicial. Embora o arquivo inicie com “en”, nesse comando você deve remover o “en” e deixá-lo iniciando por “_”.
param send-account true   !! Define que o CUCME deverá gerar CDR para chamadas que “caírem” no serviço de B-ACD.
param call-retry-timer 10   !! Define a quantidade de tempo que o script irá esperar para tentar novamente uma chamada para um grupo quando o usuário estiver na fila.
param max-time-call-retry 90  !! Define o tempo total que o usuário permanecerá na fila, antes de ser redirecionado para o voice-mail.
param voice-mail 7000   !! Ramal de voice-mail que será usado caso o usuário fique muito tempo na fila de espera.
param service-name queue   !! Aqui você indica o nome do serviço de fila. No passo anterior indicamos o nome queue. Se tiver sido colocado outro nome, deve-se colocá-lo no lugar desse nome.
!

OBS: Se não existir um voice-mail na rede, você precisa determinar qualquer valor, senão o script não funcionará.

Passo 10: Testar a URA e correr pro abraço!!!!

PARA TESTAR

Para testar, basta ligar para o número piloto (no caso o 8000) e ouvir as mensagens serem tocadas, seguir o menu e testar cada opção para verificar se o script está funcionando corretamente.

POR ENQUANTO É ISSO!!!

Como eu escrevo tanto quanto falo, se eu for continuar por aqui, o artigo vai ficar IMENSO!!! Por esse motivo, estarei encerrando por aqui. Posteriormente colocarei a parte 2 com alguns itens interessantes como, forma de atualizar o script, como trabalhar com estatísticas de chamadas, como realizar a manutenção do script e alguma coisa a mais.

Abraços!!!

!

!

!

!

!

!

!

!

!

!

 

Tags: , , , , , , ,

TELEFONIA IP EXPRESSA DA CISCO – CISCO UNITY EXPRESS

Hoje vou escrever sobre outro dos produtos voltados para empresas de pequeno e médio porte, com suporte a uma grande variedade de serviços e com um custo x benefício relativamente baixo (se comparado à solução mais completa): O Cisco Unity Express também conhecido como CUE.

Assim como o CME, o CUE também faz parte de uma solução da Cisco, chamada de Unified Communications Express.

Entre as principais funções do Cisco Unity Express estão o armazenamento de mensagens de voz e soluções de auto-atendimento. Assim como o CME também foi desenvolvido para funcionar com um roteador Cisco, com a diferença que o seu hardware é separado. Isso significa que o Cisco Unity Express é instalado em um módulo de hardware integrado a um roteador Cisco. Abaixo seguem mais características:

  • Menos robusto que a solução Cisco Unity Connection (também chamado de  CUC).
  • Opera tanto com a tecnologia digital quanto com a analógica. Isso significa, que este equipamento pode funcionar perfeitamente em ambientes híbridos, diminuindo o impacto na rede de clientes que não queiram fazer uma mudança brusca em sua rede.
  • É recomendado para pequenas e médias empresas, desde que o número de usuários não ultrapasse 500 (que é o número suportado máximo até o momento – mais detalhes na seção “Limites por modelo”)
  • Pode se integrar com servidores de e-mail, como o Microsoft Exchange.
  • Pode enviar mensagens de voz no formato .mp3 e WAV por e-mail.
  • Pode ser utilizado em ambientes centralizados ou distribuídos.
  • Gera dados que podem ser utilizados por um servidor de bilhetagem.
  • Gerenciamento pode ser feito 90% pela CLI.

CONCEITOS IMPORTANTES:

É importante lembrar que o Unity Express, apesar de ser integrado ao CME, funciona em um hardware próprio, que possui processamento, memória e armazenamento somente para o Unity. A integração é somente para comunicação entre os dois equipamentos de forma a não degradar ou sobrecarregar o roteador que possui o Cisco Callmanager. Isso é importante para casos de throubleshooting de hardware.

A forma de acesso ao Unity Express é através de uma sessão de console dentro modo de configuração privilegiado do Cisco IOS.

LIMITES POR MODELO

Existem vários modelos de módulos para instalação do Unity, cada um com sua capacidade máxima. Abaixo seguem os modelos:

AIM-CUE & AIM2-CUE-K9:
  • Suporta o máximo de 14 horas de gravação.
  • Suporta o máximo de 50 mailboxes.
ISM-SRE-300-K9:
  • Suporta o máximo de 60 horas de gravação.
  • Suporta o máximo de 100 mailboxes.
NME-CUE:
  • Suporta o máximo de 300 horas.
  • Suporta o máximo de 250 mailboxes.
SM-SER-710-K9:
  • Suporta o máximo de 600 horas de gravação.
  • Suporta o máximo de 500 mailboxes.

LICENCIAMENTO

Para utilizar os recursos do Cisco CUE, o usuário deve adquirir licenças que podem ser de 4 tipos:

MAILBOXES.
PORTS.
IVR.
TimeCardView.
.
.

ATÉ MAIS

Bem, isso foi uma pequena parte do mundo que é o Unity Express da Cisco. Nos próximos posts estarei explicando como configurar várias features nele em conjunto com o CME.

 
Deixe um comentário

Publicado por em 3 de dezembro de 2013 em VOZ e Telefonia IP

 

Tags: , , , ,

TELEFONIA IP EXPRESSA DA CISCO – CALLMANAGER EXPRESS

A Cisco possui uma grande variedade de produtos desenvolvidos para facilitar e melhorar a forma de comunicação nos ambientes empresariais e até mesmo residenciais. Hoje vou escrever sobre um dos produtos voltados para empresas de pequeno e médio porte, com suporte a uma grande variedade de serviços e com um custo x benefício relativamente baixo (se comparado à solução mais completa): O Cisco Unified Communications Manager Express também conhecido como CME.

O CME faz parte de uma solução da Cisco, chamada de Unified Communications Express. Essa solução também inclui o Cisco Unity Express (que provê entre outros serviços, mensagens de voz) além de outros produtos.

O Callmanager Express é basicamente um PABX IP proprietário da Cisco, desenvolvido para funcionar como uma aplicação dentro do IOS dos roteadores Cisco. Ou seja, em muitos casos, se a empresa já possuir roteadores Cisco, dependendo do projeto, poderá não ser necessário comprar outro equipamento para utilizar um CME (porém, cada caso é um caso). Abaixo, destaco as seguintes características principais:

  • Menos robusto que a solução Cisco Unified Communications Manager (também chamado de Callmanager ou CUCM).
  • Opera tanto com a tecnologia digital quanto com a analógica. Isso significa, que este equipamento pode funcionar perfeitamente em ambientes híbridos, diminuindo o impacto na rede de clientes que não queiram fazer uma mudança brusca em sua rede.
  • É recomendado para pequenas e médias empresas, desde que o número de usuários não ultrapasse 450 (que é o número suportado máximo até o momento – mais detalhes na seção “Limites por modelo”)
  • Pode se integrar com Gatekeeper Cisco.
  • Pode ser conectado a PSTN (a nossa Rede de Telefonia Pública).
  • Pode se conectar com aparelhos de fax.
  • Gera dados que podem ser utilizados por um servidor de bilhetagem.
  • Pode se integrar com sistemas de correio de voz.
  • Atua tanto com telefones SIP quanto com telefones SCCP.

CONCEITOS IMPORTANTES:

Ao lidar com Callmanager Express da Cisco, é importante aprender os conceitos que são a base da configuração dos telefones no CME: os conceitos físicos e os conceitos lógicos. Esses conceitos, são basicamente as formas que o CME “enxerga” o telefone. Quando você está configurando um ramal em um CME, você na verdade irá adicionar ao software um telefone físico, depois irá adicionar um telefone lógico e ligar esses dois para que o telefone se registre corretamente. Fazendo uma analogia, é como a nossa boa e velha definição de Hardware e Software, onde normalmente você adiciona um software a um hardware para que ocorra um funcionamento de praticamente todos os dispositivos eletrônicos atuais.

Conceito Físico: O CME utiliza os conceitos ephonevoice register pool (SCCP e SIP respectivamente) para representar um telefone físico. Cada telefone pode possuir vários ramais associados a eles. Um detalhe é que além de representar um telefone físico, esses conceitos podem representar portas de voz usadas em conexões com um sistema de correio de voz.

Conceito Lógico: O CME utiliza os conceitos ephone-dn voice register dn (SCCP e SIP respectivamente) para representar a o ramal. O ramal nada mais é do que a linha que conecta um canal de voz a um telefone. Essa linha é uma porta de voz virtual, dentro do CME.

LIMITES POR MODELO

Cada telefone adicionado no Callmanager Express demanda uma quantidade de memória, processamento e outros recursos físicos do roteador. Por esse motivo, a quantidade máxima de telefones suportada irá depender do modelo de roteador que está sendo utilizada. Abaixo segue uma planilha removida do site oficial da Cisco no endereço (http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/requirements/guide/cme85spc.htm.html)  que possui um detalhamento da quantidade de IP-Phones suportada por cada modelo. Até o momento, a quantidade máxima suportada é 450, porém como estão surgindo roteadores Cisco cada vez mais potentes em nível de hardware, esse número em breve poderá estar aumentando.

Captura de Tela 2013-11-11 às 16.07.44

LICENCIAMENTO

Bom, nem tudo são flores… Assim como a Microsoft, a VMWare e o Detran :D, a Cisco também trabalha com sistema de licença de uso dos seus softwares (ou nossos carros, no caso do Dentran). E, como todos os usuários de alguns desses softwares ou motoristas em geral sabemos, licença gera custo e a falta dela pode gerar multa ou processo. Por esse motivo, é importante saber que para utilizar os recursos do Cisco CME, o usuário deve adquirir licenças tanto para o próprio sistema quanto para os telefones.

ATÉ MAIS

Bem, isso foi uma pequena parte do mundo que é o Callmanager Express da Cisco. Nos próximos posts estarei explicando como configurar várias features no CME.

 

Tags: , , , , ,

CME FEATURES – PAGING – SCCP

Estarei iniciando uma série de posts sobre IP Telephony Express, colocando informações sobre determinados assuntos desse tema. Alguns posts desse assunto conterão apenas teorias e outros também conterão configurações para partes práticas. Os desse segundo tipo (como é o caso desse post aqui) serão divididos em duas partes: JOGO RÁPIDO e VISÃO DETALHADA. Abaixo segue uma explicação de cada parte:

EXPLICAÇÃO DAS PARTES DESSE TÓPICO

JOGO RÁPIDO: Para quem já sabe do assunto e/ou está apenas interessado em ver um exemplo de configuração sobre uma determinada feature, essa parte será a indicada, pois basicamente conterá um breve resumo do que é a feature e um exemplo (ou mais de um) de como configurar essa determinada Feature.

VISÃO DETALHADA: Para quem não conhece a feature ou quer aprender um pouco mais sobre ela, pode ir direto para essa parte (sem precisar ler nada do Jogo rápido) pois esta conterá o máximo de informações que eu puder concatenar sobre o assunto, além dos mesmos exemplos da parte anterior.

JOGO RÁPIDO

O paging é uma feature do CME que permite ao usuário enviar uma mensagem de voz, em tempo real, para um ou mais grupos de ramais, ligando apenas para um número piloto.

COMO CONFIGURAR O PAGING PARA SCCP:

ephone-dn 10   
 number 777    
name All-phones  
paging ip 239.1.1.1 port 2000 

Após isso, basta ir na configuração de e-phones e colocá-los nos respectivos grupos:

ephone 1
mac-address xxxx.xxxx.xxxx
button 1:1
 paging-dn 10
 Type 7960
!
ephone 2
 mac-address 000d.4132.f7e4
 button 1:4
 paging-dn 10
!
ephone-dn 1
Number 1001
name User1
 Label User1 
!
ephone-dn 2
Number 1002
name User2
 Label User2 
!

Com essa configuração, quando um usuário ligar para o ramal 777, os ramais 1001 e 1002, associados respectivamente aos ephones 1 e 2, atenderão automaticamente a chamada e o que o usuário chamador falar será ouvido pelos atendentes.

VISÃO DETALHADA

Quem nunca assistiu algum filme que envolva cenas de médicos recebendo mensagens através de um aparelho pequeno chamado pager (também chamado carinhosamente de bipe). Esse aparelho foi muito popular na década de 80 e 90 mas ainda é utilizado hoje em dia no “mundo médico” e em alguns restaurantes. Ele é feito basicamente para o envio e recebimento de mensagens curtas (antigamente, ele apenas emitia bips, onde o receptor, ao ouví-los, tinha que ligar para uma central e ouvir a mensagem destinada a ele). No caso da medicina, informa para o médico qual o quarto e o paciente que está precisando de atendimento urgente ou no caso do restaurante, informa para o cliente que o seu pedido está pronto.

Bem, avançando um pouco mais no tempo, chegamos ao nosso bom e querido amigo Cisco Unified Communications Manager Express (ou CME para os mais íntimos), onde a Cisco “pegou” essa ideia do pager de enviar mensagens e adaptou para os telefones. Surge então o audio paging da Cisco, que basicamente é uma forma de enviar mensagens de áudio para um ou mais telefones.
Então, supondo que você tenha um callcenter, com 10 atendentes e pretende mandar uma mensagem de audio para todos eles informando que o horário de saída será adiantado em 1 hora. Você liga para o número de paging e fala. Automaticamente os telefones que estiverem configurados para o grupo irão aceitar essa chamada e os usuarios ouvirão a sua voz em tempo real. Quando você terminar de falar e desligar o telefone, os demais telefones retornarão ao estado normal.

Como pré-requisito, os usuários que irão receber a mensagem precisam estar utilizando speakerphones. Outro detalhe é que, se o telefone estiver em uso, ele simplesmente ignora o paging. Porém durante uma mensagem de paging, o telefone pode ser utilizado normalmente. Isso pode parecer meio inútil, se pensarmos em e-mails ou coisas do tipo, mas é um recurso bem interessante.

CARACTERÍSTICAS E LIMITES

As principais características e limites são:

  • Essa feature foi inserida na versão 2.0 do Callmanager Express, porém apenas para suporte a SCCP. Somente na versão 9.0 do CME foi implementado o suporte a SIP.
  • Pode ser integrado a um sistema de audio paging já existente, através de interfaces analógicas como E&M por exemplo.
  • Não existe um limite determinado de IP Phones que podem ser inseridos em um Paging Group. Porém, deve-se lembrar que, dependendo do modelo de roteador que esteja utilizando, existe um número finito de ephones e ephone-dns suportados pelo equipamento. Dessa forma, o limite de IP Phones estará dentro desse limite do modelo.
  • Bem como o item anterior, levando em conta que o Paging Group é um ephone-dn e este possui um número limitado dependendo do roteador, o limite para a quantidade de Paging Groups será determinada por esse critério.
  • Cada IP Phone pode pertencer diretamente a apenas um único Paging Group. Porém pode-se mesclar os grupos (será visto isso com mais detalhes).
  • Funciona tanto para SCCP quanto para SIP (A configuração para SIP será mostrada em outro Post).
  • É recomendado utilizar o endereçamento multicast dentro da rede 239.1.1.0 e a porta 2000. Um detalhe é que, em redes pequenas há a possibilidade de não utilizar multicast. Basta, no comando paging-dn x, adicionar o comando nessa mesma linha unicast. Porém isso só pode ser feito para até 10 ramais. Além disso, deve-se utilizar multicast. (Nos exemplos, estarei utilizando multicast).

COMO CONFIGURAR

Para configurar o paging, primeiro deve-se configurar um número piloto, que será o ramal do pager. Vamos usar como exemplo o ramal 777.  Você pode também dar um nome ao paging, para o caso de serem diferentes grupos de telefones. Nesse exemplo, vamos chamar de PG_Group_1.

OBS:(em azul são apenas meus comentários dos comandos, se copiar e colar em um roteador, funcionará normalmente, pois estão precedidos de !! que nega qualquer coisa após ele, e consequentemente não aparecerá no show running do roteador e nem será reconhecido como comando errado!):

ephone-dn 10   !!(Habilita o ephone-dn).
 number 777    !!(Número que será usado para paginação).
 name PG_Group_1  !!(Apenas um nome para identificação. Opcional).
 paging ip 239.1.1.1 port 2000  !!(Endereço e porta multicast para envio da mensagem aos telefones).

Após isso, basta ir na configuração de e-phones e colocá-los nos respectivos grupos:

ephone 1  !!(Habilita o ephone).
 mac-address xxxx.xxxx.xxxx !!(Mac address ficticio para esse exemplo. Deve ser substituído).
 button 1:1  !!(associação do ephone ao ephone-dn).
 paging-dn 10 !!(associação do ephone ao grupo de paginaçao).
 Type 7960  !!(Aqui eu usei um tipo qualquer de telefone).
!
ephone 2
 mac-address 000d.4132.f7e4
 button 1:4
 paging-dn 10
!

ephone-dn 1  !!(Aqui foi criado um ramal para testes).
Number 1001
name User1
 Label User1 
!
ephone-dn 2
Number 1002
name User2
 Label User2 
!

Com essa configuração, quando um usuário ligar para o ramal 777, os ramais 1001 e 1002, associados respectivamente aos ephones 1 e 2, atenderão automaticamente a chamada e o que o usuário chamador falar será ouvido pelos atendentes.

MESCLANDO PAGING GROUPS

Um outro recurso bem interessante do audio paging da Cisco, é a possibilidade de criação de grupos e mesclagem desses grupos. Em outras palavras: Supondo que em sua empresa, você possua os setores de CallCenter, Suporte Técnico e Vendas. Você pode criar um ramal de Paging diferente para cada um desses grupos. Com isso, você pode filtrar quem irá receber a informação que você está enviando.

Além dos ramais de paging para os grupos isolados, existe ainda a possibilidade de criar um outro ramal, englobando vários grupos. Então, no exemplo de nossa empresa fictícia, podemos criar um ramal que englobe todos os outros grupos. Detalhe: Podem ser englobados no máximo 10 grupos em um mesmo ramal.

Para testar, podemos fazer a configuração para uma empresa fictícia, onde teremos:

  • o ramal 7000 sendo o ramal gerência (que não fará parte de nenhum grupo, apenas enviara as mensagens para os outros.
  • O ramal 7001, pertencente ao grupo CallCenter (com o Paging-DN 7777).
  • O ramal 7002, pertencente ao grupo Suporte Tecnico (com o Paging-DN 7778).
  • O ramal 7003, pertencente ao grupo Vendas (com o Paging-DN 7779).
  • Um Paging-DN 7780 que englobará os 3 grupos supracitados.

TOPOLOGIA DESSA CONFIGURAÇÃO

TOPOLOGIA

Então, vamos que gamo!!! Estou utilizando aqui, 3 telefones 7940 e 1 telefone 7960.

Primeiro, vamos preparar o roteador para receber os telefones:

!
ip dhcp excluded-address 172.22.10.1 172.22.10.99
!
ip dhcp pool VOZ
network 172.22.10.0 255.255.255.0
default-router 172.22.10.1
option 150 ip 172.22.10.1
!

!
interface GigabitEthernet0/0
ip address 172.22.10.1 255.255.255.0
duplex auto
speed auto
!

!
tftp-server flash0:/P0030801SR02.bin alias P0030801SR02.bin
tftp-server flash0:/P0030801SR02.loads alias P0030801SR02.loads
tftp-server flash0:/P0030801SR02.sb2 alias P0030801SR02.sb2
tftp-server flash0:/P0030801SR02.sbn alias P0030801SR02.sbn
!

!
telephony-service
no auto-reg-ephone
max-ephones 50
max-dn 200
ip source-address 172.22.10.1 port 2000
load 7960-7940 P0030801SR02.loads
max-conferences 8 gain -6
transfer-system full-consult
create cnf-files version-stamp Jan 01 2002 00:00:00
!

Agora, vamos configurar os 4 ramais para comunicação básica:

!
ephone-dn 1
number 7000
label User1
name User1
!
!
ephone-dn 2
number 7001
label User2
name User2
!
!
ephone-dn 3
number 7002
label User3
name User3
!
!
ephone-dn 4
number 7003
label User4
name User4
!

!

ephone  1
device-security-mode none
mac-address 0013.1978.3F66
type 7960
button  1:1
!
!
!
ephone  2
device-security-mode none
mac-address 0013.606D.4440
type 7940
button  1:2
!
!
!
ephone  3
device-security-mode none
mac-address 0013.6086.04F6
type 7940
button  1:3
!
!
!
ephone  4
device-security-mode none
mac-address 0013.6086.074D
type 7940
button  1:4
!

Nesse momento, iniciaremos a configuração dos pagings groups:

!
ephone-dn 10
number 7777
name CALLCENTER
paging ip 239.1.1.1 port 2000  !!(Note que aqui, foi usado o Multicast Ip com o final .1. Nos seguintes, serão utilizados Multicasts IPs diferentes deste).
!
!
ephone-dn 11
number 7778
name SUPORTE_TECNICO
paging ip 239.1.1.2 port 2000
!
!
ephone-dn 12
number 7779
name VENDAS
paging ip 239.1.1.3 port 2000
!
!
ephone-dn 13
number 7780
name PG-TODOS
paging ip 239.1.1.4 port 2000
paging group 10,11,12  !!(É aqui que a mágica da mesclagem acontece, com esse simples comando).
!

Agora, basta inserir os telefones nos Paging Groups:

!
ephone 2
device-security-mode none
mac-address 0013.606D.4440
paging-dn 10  !!(Inserido no grupo Callcenter, com o ramal de grupo 7777).
type 7940
button 1:2
!
!
!
ephone 3
device-security-mode none
mac-address 0013.6086.04F6
paging-dn 11  !!(Inserido no grupo Suporte Tecnico, com o ramal de grupo 7778).
type 7940
button 1:3
!
!
!
ephone 4
device-security-mode none
mac-address 0013.6086.074D
paging-dn 12  !!(Inserido no grupo Vendas, com o ramal de grupo 7779).
type 7940
button 1:4
!

PARA TESTAR

  • Com o ramal 7000, efetue uma chamada para o número 7777. Somente o ramal 7001 irá atender automaticamente a chamada. Se o telefone tiver autofalante, ele atenderá nesse modo. Se tiver um fone de ouvido, atenderá nesse modo.
  • Com o ramal 7000, efetue uma chamada para o número 7778. Somente o ramal 7002 irá atender automaticamente a chamada. Se o telefone tiver autofalante, ele atenderá nesse modo. Se tiver um fone de ouvido, atenderá nesse modo.
  • Com o ramal 7000, efetue uma chamada para o número 7779. Somente o ramal 7003 irá atender automaticamente a chamada. Se o telefone tiver autofalante, ele atenderá nesse modo. Se tiver um fone de ouvido, atenderá nesse modo.
  • Com o ramal 7000, efetue uma chamada para o número 7780. Todos os ramais irão atender automaticamente a chamada.

PARA VERIFICAÇÃO

Os comandos abaixo, são para verificação das configurações de paging:

  • show running-config
  • show telephony-service ephone-dn
  • show telephony-service ephone

LE GRAND FINALE

É isso aí!!! Tudo isso que foi informado aqui, foi testado em um LAB e funcionou muito bem! Em um próximo post, estarei fazendo isso utilizando SIP.

Abraços!!!

!

!

!

!

!

!

!

!

!

!

 

Tags: , , , , , , , , , , , , ,

INFORMAÇÃO ÚTIL: CONFIGURANDO BACKUP DE SWITCHES E ROTEADORES CISCO

Todo profissional de rede deve ter em mente a seguinte palavra, quando realizando a implementação dequalquer que seja o projeto: SEGURANÇA. Essa segurança tem que ser dos aspectos mais básicos aos mais avançados (se possível). Por exemplo:

  • Colocar senhas fortes.
  • Criptografar as senhas nos roteadores e switches.
  • Aplicar políticas de acesso aos equipamentos.
  • backup das configurações.
  • etc.

Essas informações que passei acima, melhoram a segurança da rede, ajudam no caso de uma falha e não aumentam em nada o projeto, pois a senha vai apenas da criatividade, a criptografia já é integrada no IOS, basta executar o comando service password-encryption no modo de configuração global, e ACL é bem simples de configurar.

Nesse post vou falar de como realizar a configuração de Backup nos roteadores e switches…

O QUE É NECESSÁRIO?

Para realizar o laboratório, usei os seguintes itens:

  • Um roteador Cisco 2901
  • Um switch Cisco 3560
  • Um computador com Windows 8 e um FTP server instalado nesse computador.
  • Um usuário para cada equipamento.
TOPOLOGIA
 

topologia

CONFIGURAÇÕES

  • FTP: Nesse caso, estou partindo do pressuposto de que o leitor esteja familiarizado com as tecnologias Cisco e com o servidor FTP utilizado. No meu caso estou usando o Quick’N Easy FTP server 3.2. Nesse FTP foram criados um usuário para cada equipamento, sendo estes:
    • Usuário cme, senha cme para o roteador.
    • usuário switch, senha switch para (claro!) o switch.
  • Partindo da suposição que a conectividade está toda funcional, ou seja, todos os equipamentos conseguem pingar o servidor FTP, seguem os comandos que devem ser aplicados em cada equipamento:ROTEADORConfigure Terminal
    !

    archive
     path ftp://cme:cme@172.16.10.5/$h
     write-memory
     time-period 1440

    SWITCH

    Configure Terminal
    !

    archive
     path ftp://switch:switch@172.16.10.5/$h
     write-memory
     time-period 1440

    Onde,

    Configure Terminal  !! Habilita o modo de configuração do roteador.
    !
    archive  !! Habilita o modo de configuração de backup. Lembrando que esse backup pode ser feito tanto por ftp, como por http, tftp e até mesmo na flash do próprio equipamento.

    path ftp://switch:switch@172.16.10.5/$h  !! Define o caminho, o usuário e senha, o IP e o “$h” indica ao equipamento que deve adicionar o hostname do equipamento no arquivo.

    write-memory
      !! Indica ao roteador que deve salvar um backup da configuração cada vez que a configuração do roteador for salva.

    time-period 1440  !! Indica um período, em minutos, que o equipamento deve enviar a configuração para o servidor FTP.

CONCLUSÃO

Ao acessar o servidor e entrar em cada pasta, pode ser confirmado que existem vários arquivos de configuração salvos dos equipamentos, conforme figura:

CME

cme

SWITCH

Switch

Para visualizar os arquivos, basta renomear para o mesmo nome.txt e visualizar com o notepad.

OBS: O equipamento não sobrescreve os arquivos.

 
Deixe um comentário

Publicado por em 24 de setembro de 2013 em VOZ e Telefonia IP

 

Tags: , , , , , , ,

CDR NO CALLMANAGER EXPRESS USANDO FTP

O QUE É?
 
Call Detail Records ou simplesmente CDR é um registro detalhado de chamadas que contém informações sobre cada chamada realizada pelos telefones gerenciados pelo CallManager ou CallManager Express. Neste artigo cobriremos apenas o cenário do CallManager Express (CME).
Origem da chamada, destino da chamada, data/hora em que a chamada chamada foi iniciada, tempo de duração da chamada e hora em que a chamada foi concluída estão entre as informações que compõem o CDR do CME.
PARA QUE SERVE?
 
Essa solução permite um gerenciamento mais preciso dos gastos com telefonia realizados pelos usuários do sistema, além de permitir uma auditoria dos recursos e utilizações da rede de telefonia. O arquivo com os CDR de cada chamada é gerado em um padrão de formato csv (separado por vírgulas) pelo Callmanager.
É ideal utilizar um programa de bilhetagem de terceiros que trabalhe com esses arquivos de CDR gerados pelo CME. Essas aplicações possuem muitas ferramentas que geram relatórios e gráficos de gastos mensais, semanais, diários, por usuário, por grupos, por ramal, etc.
Entre os softwares de bilhetagem, já trabalhei com o BillyBlues da empresa StoneVoice e o Summus da empresa com o mesmo nome do programa.
MAIS SOBRE…
Como dito anteriormente, o CDR é um registro detalhado das chamadas realizadas pelo CME. Quando as chamadas são realizadas, o roteador contendo o CME armazenas as informações sobre essas ligações, armazena em buffer e após um período pré-determinado de tempo, envia o montante de informações sobre as chamadas para algum local de armazenamento especificado nas configurações.
Existem 3 métodos que o CME pode utilizar para realizar o armazenamento das informações: Método de armazenamento de arquivo (FTP), Syslog e Radius. O primeiro é o mais fácil e mais barato dos 3 métodos. O Radius é exatamente o contrário. Nesse artigo, será falado sobre o método de armazenamento de arquivo. Posteriormente, estarei postando os outros 2 métodos.
Quando é utilizado esse método, as informações são armazenadas em formato (.csv) e podem ser armazenados na memória flash (O que não recomendo) ou em um servidor FTP externo.
É altamente recomendado entender como é a lógica do arquivo CDR gerado pelo Callmanager. Ele possui as seguintes características:
  • Cada arquivo CDR é armazenado em um formato .csv onde os campos são separado por vírgulas.
  • Os arquivos CDR possuem uma os campos em uma ordem predefinida, onde os campos que não possuem informação coletada são deixados em branco.
  • Um CDR é gerado para cada chamada e para cada serviço acionado durante a chamada. Por exemplo: Supondo que durante uma chamada, o serviço de transferência de chamadas é acionado, dois CDRs são gerados:
    • Um para a chamada básica.
    • Um para o serviço de transferência de chamadas.
Usando o método de armazenamento de arquivo, pode ser configurando um servidor FTP secundário. Se o primário falhar, o CME tentará enviar para o primário a quantidade de vezes definida e então passa a enviar para o secundário. Para voltar ao primário, o processo é manual (será explicado no campo “COMO FAÇO” desse artigo). Caso os dois servidores FTP parem de responder, o processo de coleta de informações pára, o roteador mostra um log de erro e novos CDR são dropados até que o FTP volte a funcionar e o processo seja reiniciado no roteador (será explicado no campo “COMO FAÇO” desse artigo).
O CME guarda as informações na própria memória antes de enviar para o servidor (esse tempo é configurável), porém pode ser forçado a enviar para o servidor através de um comando a qualquer momento (será explicado no campo “COMO FAÇO” desse artigo).
Os arquivos gerados pelo Callmanager Express podem ser de 3 formatos:
  • Formato detalhado (Detailed File Accounting Format)
  • Formato compacto (Compact File Accounting Format)
  • Templates personalizados (Customized Accounting Templates)

-> FORMATO DETALHADO

Nesse formato, o CDR é composto por 124 campos de informações sobre as chamadas. Nem sempre todos os campos são preenchidos, pois alguns são informações que muitas vezes precisam que um serviço seja acionado. Esse é o formato padrão de coleta de CDR no CME. A tabela 1, no final desse artigo, mostra todos esses campos e o que cada um significa. Abaixo tem-se um exemplo de um CDR detalhado, no formtado .csv (Pois se eu colocar como tabela ficará demasiado extenso para essa página).
11780434730,8,1,1,”9D4B0CA F74711DB 800D96DB A749148A”,”0163″,””,”11:17:23.413 pdt Tue May 1 2007″,”11:17:23.413 pdt Tue May 1 2007″,”11:17:26.023 pdt Tue May 1 2007″,”11:17:53.243 pdt Tue May 1 2007″,”10 “,”normal call clearing (16)”,””,0,””,0,0,0,0,”5105550160″,”5105550160″,”0163″,””,””,”0 ms”,20005,29,28,0,0,”0 ms”,””,””,”g711ulaw”,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,27,”Tariff:Unknown”,””,”0″,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,”ton:0,npi:0,pi:0,si:0,#:5105550160″,””,””,””,””,”ton:0,npi:0,pi:0,si:0,#:5105550160″,” “,””,””,”0163″,””,””,”RegularLine”,””,””,””,””,””,”CXFER”,”05/01/2007 11:17:53.239″,0,17,9D4B0CA F74711DB 800D96DB A749148A,”1BD61″,8,0,5,”5105550163″,”5105550160″,”3002″
-> FORMATO COMPACTO
O formato compacto, como o nome diz, possui “bem” menos informações sobre a chamada do que o anterior. Para ser mais preciso, é composto dos 23 primeiros atributos contidos na tabela 1 desse artigo. O comando para ativar esse formato é cdr-format compact.
Abaixo, segue um exemplo de CDR compacto:
11783007890,16,1,1,”36CDEBEC F99E11DB 8025D2A3 19FAB826″,”6002″,””,”10:46:26.329 pdt Fri May 4 2007″,”10:46:26.329 pdt Fri May 4 2007″,”10:46:27.149 pdt Fri May 4 2007″,”10:46:29.899 pdt Fri May 4 2007″,”10 “,”normal call clearing (16)”,””,0,””,0,0,0,0,”5105550160″,”5105550160″,”6002″,”TWC”,”05/04/2007 10:46:26.333″,”5105550160″,”6002″,0,16,36CDEBEC F99E11DB 8025D2A3 19FAB826,10,””,””,””,””
 
-> FORMATO PERSONALIZADO
Há também a opção de criar uma forma de coleta de informações baseadas nas necessidades de bilhetagem do cliente.
COMO FAÇO?
 
Mãos à obra…
Pré-requisitos:
Cisco IOS versão 12.4(20)T ou superior.
Utilizado no Lab:
Para fazer esse laboratório, foram utilizados os seguintes equipamentos:
  • Roteador: 1 x CISCO2921/K9
  • IOS: c2900-universalk9-mz.SPA.152-4.M2(1).bin
  • Telefones: 2 x 7940
  • Switch: 1 x 2960
  • FTP: FTP server instalado em um notebook Dell.
Topologia
 
A topologia é bastante simples:
 Imagem
Configurações de conectividade entre os equipamentos:
Para não tornar esse artigo extenso demais, vou focar apenas nas configurações necessárias para o funcionamento do CDR. Dessa forma, deve-se ter em mente que os telefones precisam estar registrados no Callmanager Express e deve haver conectividade entre os equipamentos, inclusive liberação de portas do FTP (20 e 21).
Comandos para ativar o serviço de Coleta de informações das chamadas:
 
enable
configure terminal
gw-accounting file
primary ftp 172.22.1.10/ username anonymous password anonymous
maximum buffer-size  15
maximum retry-count 3
maximum fileclose-timer 300
maximum cdrflush-timer 245
end
OBS: Se ao fizer esses comandos acima, você receber uma mensagem de erro no debug voip dump-file-acct como essa:
33647325: Sep 17 13:51:56.768: %VOICE_FILE_ACCT-3-DUMPFAIL: Could not dump to remote file – open ftp://cme:cme @10.10.44.106/.FNGBRDRS01TC.09_17_2013_13_51_55.240. Error=1541(Unknown error 1541)Pode ser porque o seu servidor FTP não está aceitando o formando do nome do arquivo. Então, basta alterar o comando primary ftp 172.22.1.10/ username anonymous password anonymous para “primary ftp 172.22.1.10/cdr username anonymous password anonymous” onde o “/cdr” faz com que o seu arquivo fique com o nome cdr.hostname-data.xxx, fazendo com que o nome do arquivo gerado não inicie com um “.” “ponto”.

OBS2: Esse problema aconteceu quando usei em um cliente com servidor Linux.

Explicação dos comandos:
gw-accounting file: Habilita o método de armazenamento de arquivo.
primary ftp 172.22.1.10/ username anonymous password anonymous: Define o endereço e pasta, além do usuário e senha do servidor FTP para armazenamento dos arquivos contendo os CDRs que forem coletados. Pode-se adicionar um outro servidor FTP através do mesmo comando, porém substituindo o primary por secondary.
 
maximum buffer-size: Define o tamanho máximo de buffer do arquivo, antes de ser enviado para o servidor. O valor é dado em Kbytes e varia de 6 a 40, sendo 20 o valor padrão.
maximum retry-count: Define a quantidade máxima de vezes que o roteador vai tentar conexão com o servidor FTP primário antes de mudar para o secundário ou parar de coletar informações. O valor varia de 1 a 5, sendo 2 o padrão.
maximum fileclose-timer: Define o tempo máximo de CDR, em minutos, que o roteador vai ficar gravar em um arquivo antes de iniciar outro. O valor varia de 60 a 1440 (24 horas). O valor padrão é 1440.
maximum cdrflush-timer: Define o tempo máximo, em minutos, que o roteador vai manter os dados de CDR no buffer antes de gravar em um arquivo. O Valor varia de 1 a 1435, sendo o padrão 60. Ou seja, se o padrão for mantido, o roteador mantém o CDR das chamadas no buffer por 1 hora. Passado esse tempo ele grava em um arquivo e o mantém na memória flash. Passado 24 horas ele envia para o servidor FTP que estiver disponível.
Outros comandos:
Com os comandos acima, a coleta de CDR funcionará perfeitamente. Porém, existem mais alguns comandos que são úteis:
cdr-format {compact | detailed}: Define qual o formato de CDR será utilizado. O Padrão é o detailed.
 
acct-template: {template name | callhistory-detail}: Define os atributos das chamadas que serão coletados. O nome do template define um template para padronizar o formato. o Callhistory-datailed todos os atributos do formato CDR escolhido.
 
file-acct flush {with-close | without-close}: Força a gravação dos CDRs armazenados no buffer e envia para o servidor FTP.
file-acct reset: Esse comando é altamente importante. Força o roteador a voltar a utilizar o servidor FTP primário, no caso de uma falha ter ocorrido mas já ter sido solucionada. Se o roteador perder comunicação com o FTP, ele tentará todas as vezes definidas e, se não tiver nenhum outro servidor FTP configurado, irá parar o serviço de coleta de informações. Somente volta a coletar se for aplicado esse comando.
debug voice fileacct: Usado no modo privilegiado, mostra mensagens relacionadas a coleta de atributos do CDR.
 
debug voip dump-file-acct: Também usado no modo privilegiado, mostra as mensagens relacionadas com a gravação do arquivo contendo cdr.
 
CONCLUSÃO
 
Ao ser aplicado os comandos no roteador, tendo sido previamente providenciada a conectividade entre os dispositivos envolvidos, foram geradas chamadas entre os telefones 1004 e 1005. Foi enviado para a pasta Home do servidor FTP um arquivo com o seguinte nome: .CME.07_04_2013_15_49_50.
Ao ser aberto o arquivo com o notepad, foi vista a seguinte saída:
1372952966,35,0,1,”E8AC48CD E3F711E2 802FE23D A1161059″,””,””,”15:47:47.454 UTC Thu Jul 4 2013″,””,”15:47:49.024 UTC Thu Jul 4 2013″,”15:49:26.544 UTC Thu Jul 4 2013″,””,””,”answer”,0,””,0,0,0,0,”1004″,”1004″,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,98,”Tariff:Unknown”,””,”0″,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,”ton:0,npi:0,pi:0,si:0,#:1004″,””,””,””,””,””,””,””,””,”1005″,””,””,”RegularLine”,””,””,””,””,””,”TWC”,”07/04/2013 15:47:47.456″,”1004″,””,0,19,E8AC48CD E3F711E2 802FE23D A1161059,23,””,””,””,””,”dn:unique,usr:,tag:4″,”cme”,””,””,””,””
1372952966,36,0,1,”E8AC48CD E3F711E2 802FE23D A1161059″,””,””,”15:47:48.258 UTC Thu Jul 4 2013″,””,”15:47:49.028 UTC Thu Jul 4 2013″,”15:49:26.548 UTC Thu Jul 4 2013″,””,””,”originate”,0,””,0,0,0,0,”1004″,”1004″,”1005″,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,98,”Tariff:Unknown”,””,”0″,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,”ton:0,npi:0,pi:0,si:0,#:1004″,””,””,””,””,”ton:0,npi:0,pi:0,si:0,#:1004″,””,””,””,”1005″,””,””,”RegularLine”,””,””,””,””,””,”TWC”,”07/04/2013 15:47:48.260″,”1004″,”1005″,0,20,E8AC48CD E3F711E2 802FE23D A1161059,24,””,””,””,””,”dn:unique,usr:,tag:5″,”cme”,””,””,””,””
1372952984,39,0,1,”243D4E84 E3F811E2 8034E23D A1161059″,””,””,”15:49:27.384 UTC Thu Jul 4 2013″,””,”15:49:30.284 UTC Thu Jul 4 2013″,”15:49:44.904 UTC Thu Jul 4 2013″,””,””,”answer”,0,””,0,0,0,0,”1004″,”1004″,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,15,”Tariff:Unknown”,””,”0″,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,”ton:0,npi:0,pi:0,si:0,#:1004″,””,””,””,””,””,””,””,””,”1005″,””,””,”RegularLine”,””,””,””,””,””,”TWC”,”07/04/2013 15:49:27.392″,”1004″,””,0,21,243D4E84 E3F811E2 8034E23D A1161059,27,””,””,””,””,”dn:unique,usr:,tag:4″,”cme”,””,””,””,””
1372952984,40,0,1,”243D4E84 E3F811E2 8034E23D A1161059″,””,””,”15:49:28.198 UTC Thu Jul 4 2013″,””,”15:49:30.288 UTC Thu Jul 4 2013″,”15:49:44.908 UTC Thu Jul 4 2013″,””,””,”originate”,0,””,0,0,0,0,”1004″,”1004″,”1005″,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,15,”Tariff:Unknown”,””,”0″,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,””,”ton:0,npi:0,pi:0,si:0,#:1004″,””,””,””,””,”ton:0,npi:0,pi:0,si:0,#:1004″,””,””,””,”1005″,””,””,”RegularLine”,””,””,””,””,””,”TWC”,”07/04/2013 15:49:28.196″,”1004″,”1005″,0,22,243D4E84 E3F811E2 8034E23D A1161059,28,””,””,””,””,”dn:unique,usr:,tag:5″,”cme”,””,””,””,””
1372952990
 
TABELAS
TABELA 1
ITENS DO ARQUIVO CDR
No. Field Name Type Description
0 unix_time Long System time stamp when CDR is captured.
1 call-id Long Value of the Call-ID header.
2 cdr-type Long Template used: 0=None; 1=Call history detail; 2=Custom template
3 leg-type Long Call leg type: 1= Telephony; 2=VoIP; 3=MMOIP; 4=Frame Relay; 5=ATM
4 h323-conf-id String Unique call identifier generated by the gateway. Used to identify the separate billable events (calls) within a single calling session.
5 peer-address String Number that this call was connected to in E.164 format.
6 peer-sub-address String Subaddress configured under a dial peer.
7 h323-setup-time String Setup time in Network Time Protocol (NTP) format: hour, minutes, seconds, microseconds, time_zone, day, month, day_of_month, year.
8 alert-time String Time at which call is alerting.
9 h323-connect-time String Connect time in NTP format: hour, minutes, seconds, microseconds, time_zone, day, month, day_of_month, year.
10 h323-disconnect-time String Disconnect time in NTP format: hour, minutes, seconds, microseconds, time_zone, day, month, day_of_month, year.
11 h323-disconnect-cause String Q.931 disconnect cause code retrieved from Cisco IOS call-control application programming interface (Cisco IOS CCAPI).
12 disconnect-text String ASCII text describing the reason for call termination.
13 h323-call-origin String Gateway’s behavior in relation to the connection that is active for this leg. answer= Legs 1 and 3; originate= Legs 2 and 4; callback = Legs 1 and 3
14 charged-units Long Number of charged units for this connection. For incoming calls or if charging information is not supplied by the switch, the value is zero.
15 info-type String Type of information carried by media. 1=Other 9 not described; 2=Speech; 3=UnrestrictedDigital; 4=UnrestrictedDigital56; 5=RestrictedDigital 6- audio31; 7=Audio7; 8=Video; 9=PacketSwitched
16 paks-out Long Total number of transmitted packets.
17 bytes-out Long Total number of transmitted bytes.
18 paks-in Long Total number of packets received.
19 bytes-in Long Total number of bytes received.
20 username String Username for authentication. Usually this is the same as the calling number.
21 clid String Calling number.
22 dnis String Called number.
23 gtd-orig-cic String Originating carrier identification code, used in routing to identify the network.
24 gtd-term-cic String Terminating carrier identification code.
25 tx-duration String Duration, in ms, of transmit path open from this peer to the voice gateway for the call.
26 peer-id Long ID value of the peer table entry to which this call was made. If a peer table entry for this call does not exist, the value of this object is zero.
27 peer-if-index Long ifIndex value of the peer table entry to which this call was made. If a peer table entry for this call does not exist, the value of this object is zero.
28 logical-if-index Long ifIndex value of the logical interface through which this call was made. For ISDN media, this is the ifIndex of the B channel that was used for this call.
29 acom-level Long Average ACOM level, in dB, for the call (ACOM is the combined loss achieved by the echo canceler). 1 indicates that the level cannot be determined or level detection is disabled.
30 noise-level Long Average noise level for the call, in dBm.
31 voice-tx-duration String Duration, in ms, for this call.
32 account-code String Account code entered using the Acct soft key during call setup or when connected to an active call.
33 codec-bytes Long Payload size of the voice packet.
34 codec-type-rate String Negotiated coder rate. Transmit rate of voice/fax compression to its associated call leg for the call.
35 ontime-rv-playout Long Duration, in ms, of voice playout from data received on time for this call.
36 remote-udp-port Long Remote system UDP listener port to which voice packets are transmitted.
37 remote-media-udp-port Long Remote-media gateway UDP port.
38 vad-enable String Whether or not voice-activity detection (VAD) is enabled for the voice call.
39 receive-delay String Average playout FIFO delay plus the decoder delay during the voice call.
40 round-trip-delay String Voice-packet round-trip delay, in ms, between local and remote devices on the IP backbone during a call.
41 hiwater-playout-delay String High-water mark voice playout FIFO delay during the voice call.
42 lowater-playout-delay String Low-water mark voice playout FIFO delay during the voice call.
43 gapfill-with-interpolation String Duration, in ms, of the voice signal played out with the signal synthesized from parameters or samples of data preceding and following in time because of voice data not received on time (or lost) from the voice gateway for this call.
44 gapfill-with-redundancy String Duration, in ms, of the voice signal played out with signal synthesized from redundancy parameters available because of voice data not received on time (or lost) from the voice gateway for this call.
45 gapfill-with-silence String Duration, in ms, of the voice signal replaced with the signal played out during silence because of voice data not received on time (or lost) from the voice gateway for this call
46 gapfill-with-prediction String Duration, in ms, of voice signal played out with signal synthesized from parameters or samples of data preceding in time because of voice data not received on time (or lost) from voice gateway for this call.
47 early-packets Long Number of received voice packets that arrived too early to store in the jitter buffer during the call.
48 late-packets Long Number of received voice packets that arrived too late to play out with the codec during the call.
49 lost-packets Long Number of lost voice packets during the call.
50 max-bitrate Long Maximum bandwidth used by the video call.
51 faxrelay-start-time String Fax start time in a call. Multiple fax start/stop time stamps can exist in one call. Recorded for both VoIP and telephony call legs.
52 faxrelay-stop-time String Fax stop time in a call. Multiple fax start/stop time stamps can exist in one call. Recorded for both VoIP and telephony call legs.
53 faxrelay-max-jit-buf-depth String Depth of the jitter buffer, in ms.
54 faxrelay-jit-buf-ovflow String Number of jitter buffer overflow events during the call.
55 faxrelay-init-hs-mod String Initial high-speed modulation and baud rate negotiated at the time the call is connected.
56 faxrelay-mr-hs-mod String Most recent high-speed modulation and baud rate.
57 faxrelay-num-pages String Total number of transmitted and received fax pages.
58 faxrelay-tx-packets String Number of packets transmitted.
59 faxrelay-rx-packets String Number of packets received.
60 faxrelay-direction String Whether a fax was originated (transmitted) or terminated (received) by this gateway.
61 faxrelay-pkt-conceal String Packet loss concealment; number of white scan lines inserted (nonzero for outbound gateway only).
62 faxrelay-ecm-status String Whether error correction mode is enabled.
63 faxrelay-encap-protocol String Encapsulation protocol used for fax transfer.
64 faxrelay-nsf-country-code String NSF country code of the local fax device; country name per T.35, Annex A.
65 faxrelay-nsf-manuf-code String NSF manufacturer code of the local fax device.
66 faxrelay-fax-success String Whether fax transfer was successful, the transfer failed, or indeterminate.
67 override-session-time Long Override session time.
68 h323-ivr-out String AV pairs sent from the voice gateway to the RADIUS server that you can define. You can set (write) the value with a customized Tcl IVR script.
69 internal-error-code String Cause of failed calls. For more information, see the “Internal Error Codes” section on page 91.
70 h323-voice-quality String Value representing impairment/calculated planning impairment factor (ICPIF) of the voice quality on the connection provided by lower-layer drivers (such as the digital-signal-processor). Low numbers represent better quality.
71 remote-media-address String Remote-media gateway IP address.
72 remote-media-id Long Remote-media gateway DNS name.
73 carrier-id Long ISUP carrier ID.
74 calling-party-category String Best-fit calling party category value extracted from the Generic Transparency Descriptor (GTD). Sent in start and stop accounting messages for call legs 1 and 4. Optionally, this field also contains: •3-character country code representing the country variant extracted from the GTD Protocol Name (PRN) country field; •National value extracted from the GTD Field Compatibility Information (FDC) data field.
75 originating-line-info Long Sent in start and stop accounting messages for call legs 1 and 4.
76 charge-number String Charge number used for call.
77 transmission-medium-req Long Sent in start and stop accounting records for call legs 1 and 4.
78 service-descriptor String Gatekeeper-related.
79 outgoing-area String Gatekeeper identifier, or the destination zone or area, of the outgoing VoIP call.
80 incoming-area String Gatekeeper identifier, or the source zone or area, of the incoming VoIP call.
81 out-trunkgroup-label String Trunk-group label associated with the group of voice ports from which the outgoing TDM call leaves the gateway.
82 out-carrier-id String Carrier ID of the trunk group through which the call leaves the gateway or the partnering voice services provider identifier of the outgoing VoIP call.
83 dsp-id String DSP ID used for the current call.
84 in-trunkgroup-label String Trunk group label associated with the group of voice ports from which the incoming TDM call arrived on the gateway.
85 in-carrier-id String Carrier ID of the trunk group through which the call arrived or the partnering voice service provider identifier of the incoming VoIP call.
86 cust-biz-grp-id String SIP business group ID.
87 supp-svc-xfer-by String Transferor information in the REFER/BYE/ALSO of SIP call. Used only in SIP call transfer.
88 voice-feature String Type of feature: BXFER = Blind transfer; CFA = Call forward all; CFBY = Call forward busy; CFNA = Call forward no answer; CXFER = Consultative transfer; TWC = Two-way call
89 feature-operation String Feature operation.
90 feature-op-status String Success (0) or failure (1).
91 feature-op-time String Feature operation time. Time stamp of the operation start and stop time, if applicable for a given feature.
92 feature-id String Feature ID of the invocation. Identifies a unique instance of a feature attribute within a gateway. This number is incremented for each added feature attribute.
93 gw-rxd-cdn String Called number received in the incoming signaling message before any translation rules are applied.
94 gw-rxd-cgn String Calling number received in the incoming signaling message before any translation rules are applied.
95 gtd-gw-rxd-ocn String Original calling number received by the gateway.
96 gtd-gw-rxd-cnn String GTD connected number.
97 gw-rxd-rdn String Redirection number received by the gateway.
98 gw-final-xlated-cdn String Called number to be sent out of the gateway.
99 gw-final-xlated-cgn String Calling number to be sent out of the gateway.
100 gw-final-xlated-rdn String Final translated received number.
101 gk-xlated-cdn String Called number presented by the gatekeeper in the ACF RAS message. GK/GKTMP could modify the called number by appending a prefix or leave it unchanged.
102 gk-xlated-cgn String Calling number presented by the gatekeeper in the ACF RAS message. The GK/GKTMP could modify the calling number which is carried in the ACF nonstandard parameter.
103 gw-collected-cdn String Destination number collected by the gateway (application) that is used to route the call. Only applicable for 2-stage calls.
104 ip-hop String Maximum number of hops in the SIP invite message.
105 redirected-station String Redirecting number extracted from the redirect number parameter. Sent in start accounting messages for all call legs.; noa=Nature of address; npi=Numbering plan indicator; pi=Presentation indicator; #=Address of the redirecting number
106 subscriber String T1/channel associated signaling (CAS) or E1/R2 signal information about a subscriber.
107 in-intrfc-desc String Description assigned to the voice port of the incoming call.
108 out-intrfc-desc String Description assigned to the voice port of the outgoing call.
109 session-protocol String Session protocol used for calls between the local and remote router through the IP backbone. Always equal to “sip” for SIP or “Cisco” for H.323.
110 local-hostname String Local hostname that would be accessed or used by the SNMP MIBs.
111 backward-call-id String Sent in stop accounting messages for call legs 1 and 4. Also included in interim-update packets.
112 feature-id_field1 String Feature name. Two-Way Call (TWC), Call Forward All (CFA), Call Forward Busy (CFBY), Call Forward No Answer (CFNA), Blind Transfer (BXFER), Consultive Transfer (CXFER), Hold (HOLD), Resume (RESUME).
113 feature-id_field2 String Feature invocation time.
TWC CFA, CFNA, CFBY BXFER, CXFER HOLD/RESUME
114 feature-id_field3 String calling number feature status (frs) frs frs
115 feature-id_field4 String called number feature ID (fid) fid fid
116 feature-id_field5 String frs fcid fcid fcid
117 feature-id_field6 String fid legID XconsID legID
118 feature-id_field7 String fcid frson legID hrson
119 feature-id_field8 String legID fdcnt frson holding
120 feature-id_field9 String Not used fwder xsts held
121 feature-id_field10 String Not used fwdee Xor sl
122 feature-id_field11 String Not used fwdto Xee usr
123 feature-id_field12 String Not used frm Xto tag
 
1 comentário

Publicado por em 4 de julho de 2013 em VOZ e Telefonia IP

 

Sobre Cisco Collaboration

Como o CCIE Voice da Cisco está mudando esse ano para CCIE Collaboration, é bom ficar um pouco mais antenado para o que esse Collaboration engloba. Para não ficar muito extenso, não irei comentar sobre o CCIE-Voice, apenas escreverei aqui o que a documentação da Cisco fala sobre Collaboration.

De acordo com o SRND da Cisco (um guia de design da Cisco), “Collaboration significa trabalhar junto para alcançar um determinado objetivo”. Com o grande avanço da sociedade, a forma de trabalho está mudando radicalmente. Cada vez mais, estamos trabalhando de forma mais remota e, com isso, precisamos de ferramentas que auxiliem as empresas a avançar junto com a sociedade. Para alcançar esse objetivo, as ferramentas da Cisco permitem que trabalhadores possam agora cooperar com o crescimento das corporações em qualquer hora, em qualquer lugar, com baixo custo para as corporações.

Dentre as aplicações e serviços que compõem o amplo leque de ferramentas de colaboração da Cisco, destacam-se:

  • Mensagens Instantâneas e presença: Para melhorar o fluxo de comunicação dentro das corporações, esses serviços permitem que o Cisco Jabber (uma ferramenta de mensagens instantâneas que pode ser integrado com serviço de telefonia) melhore a produtividade de funcionários de corporações, permitindo uma rápida e flexível forma de comunicação, que pode ser acessada por desktops, tablets e até celulares.
  • Conferência Colaborativa: Através do Cisco Webex, audio, vídeo em alta definição e compartilhamento de arquivos em tempo real são possíveis nas organizações. Isso permite uma facilidade no gerenciamento de reuniões e estas tornam-se totalmente interativas, podendo ser realizadas independente do local onde os participantes estejam. Poder participar de uma reunião, à beira da praia, com uma água de côco bem gelada e um tablet na mão é uma experiência e tanto!!!
  • Telepresença: A telepresença é uma outra forma de unir pessoas em tempo real, sem a necessidade de viagens, através de salas de conferências totalmente projetadas para simular um ambiente o mais perto possível do real. É como se você estivesse em uma reunião com pessoas em uma mesa, mas ao invés das pessoas, existe uma tela mas toda a comunicação ocorrendo em tempo real. Os produtos que compõem a telepresença são totalmente compatíveis com outros produtos como webex.
  • Mensagens de voz: A Cisco provê ferramentas de mensagens de voz que atendem desde pequenas corporações a até grandes corporações, podendo inclusive ser integradas a sistemas de terceiros.
  • Contato com o cliente: A ferramenta Cisco Contact Center permite de forma inteligente, realizar o tratamento de chamadas, roteamento inteligente, gerenciamento de contatos, reconhecimento de voz, URAs, de forma a atender os clientes das corporações de uma forma totalmente personalizada.
  • Gravação de chamadas: O produto Media Sense, permite a gravação, preservação e captura de chamadas, integrando-se a sistema de contact center, de forma a permitir um monitoramento da qualidade do atendimento aos clientes das corporações. É exatamente o que permite aos atendentes dizerem a famosa frase “informamos que sua ligação está sendo gravada e, caso necessário, o senhor (a) poderá solicitá-la.
 
Deixe um comentário

Publicado por em 2 de junho de 2013 em VOZ e Telefonia IP

 

Vídeos do IKE

Segue um vídeo bastante engraçado e instrutivo sobre Cisco com o personagem Ike:

 
Deixe um comentário

Publicado por em 23 de abril de 2013 em VOZ e Telefonia IP

 

Tags: , ,

Implementing AAR (site oficial Cisco)

Segue um link com uma vídeo aula muito bem explicativa, explicando sobre uma das formas de Call Admission Control em um ambiente centralizado: Automatic Alternate Routing (AAR).

 

http://www.cisco.com/web/learning/le31/le46/cln/qlm/CCVP/cipt2/implementing-aar-2/player.html

 

 

 
Deixe um comentário

Publicado por em 22 de julho de 2012 em VOZ e Telefonia IP

 

Tags: , ,

Recuperar IOS de roteador Cisco em modo rommon

rommon 2 > IP_ADDRESS=10.0.0.1 
rommon 3 > IP_SUBNET_MASK=255.255.255.0 
rommon 4 > DEFAULT_GATEWAY=10.0.0.13 
rommon 5 > TFTP_SERVER=10.0.0.13 
rommon 6 > TFTP_FILE=c3845-adventerprisek9-mz.124-21.bin 
rommon 7 > tftpdnld 
IP_ADDRESS: 10.0.0.1 
IP_SUBNET_MASK: 255.255.255.0 
DEFAULT_GATEWAY: 10.0.0.13 
TFTP_SERVER: 10.0.0.13
TFTP_FILE: c3845-adventerprisek9-mz.124-21.bin
GE_PORT: Ge0/0 
TFTP_MEDIA_TYPE: Copper 
GE_SPEED_MODE: Auto Invoke this command for disaster recovery only. 

WARNING: all existing data in all partitions on flash will be lost! 
Do you wish to continue? y/n: [n]: y 

Receiving c3845-adventerprisek9-mz.124-21.bin from 10.0.0.13 !!!!!!!!!!!!!!!!!!!!!!!!!!!! 
File reception completed.
Copying file c3845-adventerprisek9-mz.124-21.bin to flash. 
Erasing flash at 0x607c0000 
program flash location 0x60440000 
rommon 8 >

 
Deixe um comentário

Publicado por em 18 de julho de 2012 em VOZ e Telefonia IP