Figura 22.2. Sistema Híbrido Remoto
Com o Asterisk® SCF™ no cenário (circuito), a funcionalidade pode ser movida aos poucos do sistema PABX existente para o Asterisk® SCF™, que pode assumir um papel maior e comandar mais do sistema ao longo do tempo. Eventualmente, o sistema de PABX existente pode simplesmente ser usado como um método para enviar chamadas para os aparelhos existentes (analógicos, POTS), nas estações dos agentes, com aqueles sendo eliminados ao longo do tempo e substituídos por telefones baseados em SIP, à medida que a fiação é instalada e os telefones IPs são comprados.
Ao adicionar o Asterisk® SCF™ ao circuito existente, ganhamos um novo conjunto de funcionalidades e vantagens, como:
- Suporte para funcionários remotos: as chamadas são entregues pela conexão de Internet Existentes, para Gateways IPs, Telefones IPs, Softphones em Desktops, Tablets e até mesmo em Smartphones;
- Funcionalidades como conferencia e correio de voz (com a possibilidade de os usuários serem notificados por e-mail de novas mensagens);
- Linhas telefônicas expandidas usando VoIP e redução de custos de longa distancia (DDD e DDI)
Tal sistema ainda sofre de algumas desvantagens, pois todo o hardware precisa residir na instalação do Call Center, e ainda estamos restritos a usar hardware (relativamente) caro no sistema Asterisk® SCF™ para conexão ao PABX tradicional. No entanto, estamos indo na direção certa e, com o sistema Asterisk® SCF™ no circuito, podemos iniciar a migração ao longo do tempo, limitando as interrupções nos negócios e adotado uma abordagem mais gradual para treinar os usuários.
Asterisk® SCF™ Puro, Não Distribuído (Nondistributed)
O próximo passo em nossa jornada é o sistema Asterisk® SCF™ Puro (Puro que dizer, somente a linha de comando, se nenhuma interface gráfica, lembrando que a interface gráfica oficial do projeto Sangoma Digium é o FreePBX e não mais o AsteriskNow). Neste sistema, migramos com sucesso do sistema PBX existente e agora estamos lidando com todas as funcionalidades através do Asterisk® SCF™. Nosso PRI (PSTN) existente foi anexado ao Asterisk® SCF™ e expandimos nossa capacidade integrando um Provedor de Telefonia Pela Internet (ITSP) em nosso sistema. Todos os agentes/usuários agora estão usando telefones SIP (Telefones IP, e Softphones) e até adicionam0os vários funcionários remotos. Está topologia é ilustrada na Figura 22.3, "Asterisk® SCF™ Puro, Não Distribuído (Nondistributed)".
Figura 22.3. Asterisk® SCF™ Puro, Não Distribuído (Nondistributed)
Funcionários remotos podem ser uma grande vantagem para uma empresa. Permitir que seu trabalho em locais remotos (Home Office, P. Ex.) não apenas aumenta o moral dos funcionários, aliviando o fardo de uma viagem potencialmente longa, mas também permite que os funcionários trabalhem em um ambiente em que se sintam confortáveis, o que pode torná-los mais produtivos. Além disso, o gerente do Call Center não tem menos controle sobre as estatísticas dos funcionários; suas chamadas ainda podem ser monitoradas para fins de treinamento, e os dados estatísticos coletados não parecem diferentes para o gerente do que para os funcionários que residem na instalação.
Uma vantagem mensurável para a empresa é a redução na quantidade de hardware necessária a ser comprada para cada funcionário. Se os agentes puderem utilizar seus sistema de computador, redes elétricas e conexões de Internet existentes, a empresa poderá economizar uma quantia significativa de dinheiro apoiando funcionários remotos. Além disso, esses funcionários podem estar localizados em todo o mundo, para expandir o número de horas que seus agentes estão disponíveis, permitindo que você atenda a mais fusos horários.
A utilização deste sistema é simples e eficiente, mas à medida que a empresa cresce, o sistema pode chagar a um problema de capacidade.
Integração do Asterisk® SCF™ Puro ao Banco de dados.
Integrar o Asterisk® SCF™ com um banco de dados pode adicionar muitas funcionalidades ao seu sistema. Além disso, ele fornece uma maneira de construir utilitários de configuração baseados na WEB para facilitar a manutenção de um sistema Asterisk® SCF™. Além disso, permite acesso instantâneo a informações do Dialplan e outras partes do sistema do Asterisk® SCF™.
Banco de Dados Único
Adicionar integração de banco de dados ao Asterisk® SCF™ (Figura 22.4 "Integração de Banco de Dados ao Asterisk® SCF™, Banco de Dados Único") é uma maneira poderosa de obter acesso a informações que podem ser manipuladas por outros meios. Por exemplo, podemos ler informações sobre as extensões e dispositivos no sistema de um banco de dados usando a Arquitetura Realtime Asterisk - ARA, e podemos modificar as informações armazenadas no banco de dados por meio de um sistema externo, como uma pagina da Web (GUI Interface).
A integração com o banco de dados adiciona uma camada entre o Asterisk® SCF™ e a Interface Web com a qual o Web Designer está familiarizado e permite a manipulação de dados de uma forma que não requer nenhum conjunto de habilidades adicionais. O conhecimento do próprio Asterisk® SCF™ é deixado para o administrador do Asterisk® SCF™, e o desenvolvedor Web pode trabalhar alegremente com ferramentas com as quais está familiarizado.
Figura 22.4. Integração de Banco de Dados ao Asterisk® SCF™, Banco de Dados Único
Claro, isso torna o sistema Asterisk® SCF™ um pouco mais complexo de construir, mas a integração com um banco de dados via ODBC adiciona todos os tipos de possibilidades (como o hot-desking). O FUNC_ODBC é uma ferramenta poderosa para o administrador do Asterisk® SCF™, fornecendo a habilidade de construir um Dialplan estático usando dados de natureza dinâmica.
Também gostamos muito do módulo FUNC_CURL, que fornece integração com serviços da Web sobre HTTP diretamente do Dialplan.
Com os dados abstraídos diretamente do Asterisk® SCF™ agora teremos mais facilidade para avançar em direção a um sistema que está se preparando para ser agrupado (Clustered). Podemos usar algo como Linux-HA (http://www.linux-ha.org/wiki/Main_Page) para fornecer failover automático entre os sistemas. Embora, no caso de uma falha as chamadas no sistema com falha sejam perdidas, o failover levará apenas alguns instantes (menos de um segundo) para ser detectado e o sistema aparecerá para seus usuários como imediatamente disponível novamente. Nesta configuração, como nossos dados são abstraídos fora do Asterisk® SCF™ podemos usar aplicativos como UNISON (https://www.cis.upenn.edu/~bcpierce/unison/) ou até mesmo o RSYNC para manter os arquivos de configuração sincronizados entre os Sistemas Operacionais e o Backup do Sistema. Também podemos usar o SubVersion ou o Git para rastrear alterações nos arquivos de configuração, facilitando a reversão de alterações que não funcionam.
É claro que se nosso banco de dados desaparecer devido a uma falha do hardware ou do software, nosso sistema ficará indisponível a menos que seja programado de forma a poder funcionar sem a conexão com o banco de dados. Isso pode ser feito por meio do uso de um banco de dados local que simplesmente se atualiza periodicamente a partir do banco de dados primário, ou por meio de informações programadas diretamente no Dialplan. Na maioria dos casos, a funcionalidade do sistema neste modo será mais simples do que quando o banco de dados estava disponível, mas pelo menos o sistema não ficará totalmente inutilizável.
Uma solução melhor seria usar um banco de dados replicado, que permite que os dados gravados em um servidor de banco de dados sejam gravados em outro servidor ao mesmo tempo. O Asterisk® SCF™ pode então fazer o failover para o outro banco de dados automaticamente se o servidor primário ficar indisponível.
Banco de Dados Replicados
O uso de um banco de dados replicado fornece alguma redundância no back-end para ajudar a limitar a quantidade de tempo de inatividade que os chamadores e os agentes experimentam se ocorrer uma falha no banco de dados. Uma configuração de banco de dados Mestre-Mestre é necessária para que os dados possam ser gravados em qualquer banco de dados e replicados automaticamente para o outro sistema, garantindo que tenhamos uma cópia exata dos dados em duas máquinas físicas. Outra vantagem dessa abordagem é que um único sistema não precisa mais lidar com todas as transações do bando de dados; a carga pode ser dividida entre os servidores. A Figura 22.5 "Integração de Banco de Dados do Asterisk® SCF™ com Banco de Dados Distribuído" ilustra esse cenário recomendado.
Figura 22.5 Integração de Banco de Dados do Asterisk® SCF™ com Banco de Dados Distribuído
Já utilizamos em nossos cenários a replicação Mestre-Mestre do MySQL antes (agora usamos o PostgreSQL) e funciona muito bem. Não realizamos o mesmo cenário com MariaDB, logo não temos como assegurar o comportamento. Também quero dizer que não é difícil de configurar, e existem vários tutoriais na Internet. Outros sistemas de banco de dados provavelmente também conterão essa funcionalidade, especialmente se você estiver usando um sistema comercial com o Oracle ou MS SQL.
Failover pode ser feito nativamente no Asterisk® SCF™, pois res_odbc.so e func_odbc.so contêm opções de configuração que permitem especificar vários bancos de dados. Em res_odbc.so, você pode especificar a ordem preferencial para conexões de banco de dados em caso de falha. Em fun_odbc.so, você pode até especificar servidores diferentes para ler e gravar dados por meio de funções no Dialplan que você cria. Toda essa flexibilidade permite que você forneça um sistema que funcione bem para o seu negócio.
Programas externos também podem ser usados para controlar o Failover entre sistemas. O aplicativo PEN (http://siag.nu/pen/) é um balanceador de carga para aplicativos TCP simples, como HTTP ou SMTP, que permite que vários servidores apareçam como um. Isso significa que o Asterisk® SCF™ só precisa ser configurado para se conectar a um único endereço IP (ou hostname); o aplicativo PEN cuidará de controlar qual servidor será uasdo para cada solicitação.
Asterisk® SCF™ Puro e Estados de Dispositivos Distribuído
Os estados do dispositivo no Asterisk® SCF™ são importantes tanto do ponto de vista do software (o Asterisk® SCF™ pode precisar saber o estado de um dispositivo ou da linha em um dispositivo para saber se uma chamada pode ser feita para ele) quanto do ponto de vista do usuário (P. Ex., uma luz (BFL/HINT) pode ser ligada ou desligada para indicar se uma determinada linha esta em uso ou se um agente está disponível para mais chamadas). Do ponto de vista de uma fila, é extremamente importante saber o status do dispositivo que um agente está usando para determinar se o próximo chamador da fila pode ser distribuído para esse agente. Sem o conhec9imento do estado do dispositivo, a fila simplesmente faria varias chamadas para o mesmo endpoint.
Depois de começar a expandir seu sistema único em vários servidores (potencialmente em vários locais físicos, como escritórios remotos ou satélites), você precisará distribuir o estado do dispositivo dos terminais entre os sistemas. O tipo de implementação necessária dependerá se você os está distribuindo entre sistema na mesma LAN (links de baixa latência) ou em uma WAN (links de alta latência).
Bem, vamos discutir os dois métodos de distribuição de estado dos dispositivos na sequencia: OpenAIS para links de baixa latência e XMPP para links de alta latência.
Distribuindo Estados de Dispositivos em uma LAN
A implementação do OpenAIS (Using OpenAIS) foi adicionada pela primeira vez ao Asterisk na branch 1.6.1, para permitir a distribuição de informações de estado do dispositivo entre servidores. A adição do OpenAIS forneceu grandes possibilidades para sistemas distribuídos, pois a consciência do estado do dispositivo é um aspecto importante de tais sistemas. Os métodos anteriores exigiram o uso de GROUP( ) e GROUP_CONT( ) para cada canal, com essa informação consultada por DUNDi®. Embora essa abordagem seja útil em alguns cenários (podemos usar essa funcionalidade para pesquisar o número de chamadas que nossos sistemas estão processando e direcionar chamadas de forma inteligente para sistemas que lidam com menos chamadas), como um mecanismo para determinar as informações de estado do dispositivo, se está presente ou não.
Figura 22.6. Distribuição de Estado do Dispositivo com OpenAIS
O OpenAIS nos deu a primeira implementação de um sistema que permite que o estado dos dispositivos e as indicações de mensagens em espera sejam distribuídos entre vários sistemas Asterisk® SCF™ (veja a Figura 22.6, "Distribuição de Estado de Dispositivo com OpenAIS"). A desvantagem da implementação do OpenAIS é que ela exige que todos os sistemas residam em links de baixa latência, o que normalmente significa que todos precisam residir no mesmo local físico, conectados ao mesmo switch. Dito isso, embora a biblioteca OpenAIS não funcione em redes fisicamente separadas, ela permite que um Queue( ) resida em um Servidor Asterisk® SCF™ e seus membros da fila residam em outro Servidor Asterisk® SCF™ (ou vários Servidores Asterisk® SCF™). Ele faz isso sem exigir que usemos canais locais e testemos sua disponibilidade por meio de outros métodos, limitando (ou eliminando) o número de tentativas de conexão feitas na rede e o toque de vários dispositivos.
O uso do OpenAIS tem uma vantagem, pois é relativamente fácil de configurar e começar a trabalhar. A desvantagem é que não é distribuível em locais físicos. A partir da branch 1.8, porém, podemos usar o XMPP para Distribuição de Estado do Dispositivo em uma rede de longa distância, como você verá na próxima seção.
Distribuindo Estados de Dispositivos em uma WAN
Desde a branch 1.8 do Asterisk® SCF™, foi adicionado uma implementação que usa XMPP para distribuição de estado do dispositivo. Como o protocolo XMPP é projetado para (ou pelo menos permite) uso em redes de longa distância, agora podemos ter sistemas Asterisk® SCF™ em diferentes locais físicos, distribuindo informações de estado do dispositivo entre si (veja a Figura 22.7, "Distribuindo Estados de Dispositivos com XMPP"). Com a implementação do OpenAIS, a biblioteca seria usada em cada sistema, permitindo que eles distribuíssem informações de estado do dispositivo. No cenário XMPP, um servidor central (ou cluster de servidores) é usado para distribuir o estado entre todas os Servidores Asterisk® SCF™ no cluster. Atualmente, a melhor aplicação para fazer isso é o Servidor Tigase XMPP (https://tigase.net/), devido ao suporte a eventos PubSub. Embora outros servidores XMPP possam ser suportados no futuro, apenas o Tigase é conhecido por funcionar no momento.
Figura 22.7, Distribuindo Estados de Dispositivos com XMPP
Com o XMPP, as filas podem ser localizadas em diferentes locais físicos e os escritórios satélites podem receber chamadas do escritório principal ou vice-versa. Isso fornece outra camada de redundância, porque se o site principal ficar offline e o ITSP for configurado de forma a fazer failover para outro escritório, as chamadas poderão ser distribuídas entre esses escritórios satélites até que o site principal volte a ficar online. Isso é bastante empolgante para muitas pessoas, pois adiciona uma camada de funcionalidade que não estava disponível anteriormente e a maior parte pode ser feita com uma configuração relativamente mínima.
A vantagem da distribuição de estado do dispositivo com XMPP (Using XMPP), é que, é possível distribuir o estado para vários locais físicos, o que não é possível com o OpenAIS. A desvantagem é que é mais complexo de configurar (já que você precisa de um serviço externo rodando o servidor Tigase XMPP ou alternativo) do que a implementação do OpenAIS.
Múltiplas Filas, Múltiplos Sites
Agora, vamos ser criativos e usar as várias ferramentas que discutimos nas seções anteriores para criar uma infraestrutura de fila distribuída. A Figura 22.8, " Infraestrutura de Filas Distribuídas" ilustra um exemplo de configuração onde temos cinco servidores Asterisk® SCF™ sendo liderados por outro cluster usado para distribuir/rotear as chamadas para as várias filas que configuramos. Nosso ITSP envia chamadas para o clouster de roteamento (que pode ser algo como Kamailio®, ou mesmo vários servidores Asterisk® SCF™ implementando DUNDi® ou algum outro método para rotear e distribuir chamadas, P. Ex. FreeSWITCH®), que então envia as chamadas conforme apropriado para um dos três Servidores Asterisk® SCF™ nos quais temos nossas filas configuradas. Cada servidor lida com uma fila diferente, como vendas, suporte, técnico e devoluções (apenas exemplos). Esses servidores, por sua vez, usam os agentes localizados em dois locais físicos separados. os dispositivos dos agentes são registrados em seus próprios servidores de registro local (que também podem realizar outras funcionalidades).
Veja, estamos mostrando todos os aspectos do sistema para manter o diagrama simples, mas neste caso usaríamos o sistema de estado de dispositivo distribuído XMPP, pois estamos sugerindo que os agentes são distribuídos em vários sites físicos.
Figura 22.8, Infraestrutura de Filas Distribuídas
Todos os agentes nos diferentes locais podem ser carregados em uma ou mais filas e, como estamos distribuindo informações de estado do dispositivo, cada fila saberá o estado atual dos agentes na fila e distribuirá apenas os chamadores aos agentes conforme apropriado. Além disso, podemos configurar penalidades para filas e/ou para os agentes para que os chamadores cheguem aos melhores agentes se estiverem disponíveis, e só usar os outros agentes quando todos os melhores agentes estiverem em uso.Podemos adicionar mais agentes ao sistema adicionando mais servidores ao cluster no mesmo local ou em locais físico adicionais. Também podemos expandir o número de filas que suportamos adicionando mais servidores, cada um lidando com uma fila ou filas diferentes.
Uma desvantagem de usar este sistema é a forma como o aplicativo Queue( ) foi desenvolvido. Queue( ) é uma das aplicações mais antigas do Asterisk® SCF™, e infelizmente não acompanhou o ritmo de desenvolvimento no domínio da distribuição de estado do dispositivo, então não há como distribuir o mesmo Queue( ) em vários servidores. P. Ex. suponha que você tenha filas de vendas em dois servidores. Se um chamador entra na fila de vendas do primeiro servidor Asterisk® SCF™ , e então outro chamador entra na fila de vendas do segundo servidor Asterisk® SCF™, nenhuma informação será distribuída entre essas filas para indicar quem é o primeiro e quem é o segundo na fila de vendas. As duas filas são efetivamente separadas e não se conhecem a nível de sistemas. Talvez versões futuras do Asterisk® SCF™ tenham a capacidade de fazer isso, mas no momento não há suporte. Mencionamos isso para que você possa planejar seu sistema de acordo com essas limitações.
Como as filas em algumas implementações (como em Call Centers) podem ser necessárias para lidar com muitas chamadas de uma só vez, os requisitos de processamento e carga para um único servidor podem ser bastante altos. Ter a capacidade de acessar os mesmo recursos de agentes em vários servidores significa que podemos distribuir nossos chamadores entre vários servidores, reduzindo significativamente os requisitos de processamento colocados em um único sistema. Um sistema não precisa mais fazer tudo - podemos dividir vários componentes do sistema em diferentes servidores.
Um ótimo recurso para ser utilizado entre os vários servidores Asterisk® SCF™ é um Peering IAX2 mantendo assim a qualidade da chamada, bem como a distribuição das mesmas sem o uso de muito recursos. E deixando assim SIP somente para os usuários/devices/endpoint e ITSP.
Conclusão
Neste capitulo, foi explorado como você pode fazer a transição de um sistema de telefonia tradicional (não Asterisk® SCF™, ou não Softswitch PBX IP) para um Call Center distribuído. Ao logo do caminho, vimos como um Call Center com apenas algumas posições pode ser transformar em um sistema com centenas de posições em diferente locais físicos.
Embora a capacidade de expandir seus negócios e planejar o futuro seja crucial, também é importante não criar um sistema mais complexo do que o necessário. Quanto maior você for e quanto mais distribuído for um sistema que você construir, mais tempo levara para decolar e mais difícil será fazer todas as coisas que são importantes quando ocorrerem mudanças, como testar implementar as mudanças, e manter as coisas sincronizadas. Se o seu sistema nunca vai crescer além de um Call Center de 40 posições, não construa um para 500 posições. Tudo o que vc está fazendo é adicionar custos e complexidade adicionais para acomodar um sistema em uma escala que pode nunca ser totalmente realizada.
Construir um sistema simples agora e planejar para o futuro e como você vai chegar lá (especialmente se você puder fazer isso em iterações, sem ter que destruir toda a sua infraestrutura ou começar do zero) vai te colocar em funcionamento tanto mais rápido. À medida que você cresce, você pode adicionar mais peças, determinar se a abordagem que vc está adotando está correta e, se não , voltar e retrabalhar essa peça em particular. Esse tipo de abordagem pode poupar muitas dores de cabeça no futuro, quando vc percebe que não precisa refazer todo o seu sistema complexo por causa de algum novo requisito que você não previu no inicio.
Também mencionamos algumas vantagens de ter um sistema distribuído com funcionários remotos, como melhorar a moral dos funcionários e redução de custos. Você pode usar as conexões de Internet, hardware e eletricidade existentes de seus funcionários, o que pode economizar dinheiro para a empresa, e seus funcionários se beneficiarão evitando o agravamento e os custos de se deslocar para um escritório todos os dias. Embora nem todas as situações permitam esse tipo de cenário, vale a pena explorar se adicionar suporte para funcionários remotos será útil para o seu negocio.
Finalmente, o estado do dispositivo distribuído pode abrir um mundo de possibilidades para sua empresa, permitindo que ela cresça além do único sistema Asterisk que faz tudo. A divisão da funcionalidade em vários servidores agora é uma realidade e pode ser abordada com uma medida de confiança nunca vista anteriormente.
Fonte: Asterisk: The Definitive Guide (3nd Edition for Asterisk 1.8), escrito por Leif Madsen, Jim Van Meggelen, e Russell Bryant. (Capitulo 22).
