IMPLANTAÇÃO DE SISTEMA DE CALL CENTER BASEADO EM ASTERISK

EM ALTA DISPONIBILIDADE: UM ESTUDO DE CASO1

Günter Fischborn

Resumo: A busca por alta disponibilidade de serviços de TIC (Tecnologia da

Informação e Comunicação) tem despertado atenção especial por parte das organizações
e prestadores de serviço de datacenter. Esta atenção se deve em grande parte à
necessidade de utilização dos serviços pelo cliente em tempo integral, e também a perda
ocasionada para a organização em caso de indisponibilidade dos serviços, tanto em bens
tangíveis quanto na degradação da sua imagem. A necessidade de disponibilidade é
igualmente importante para serviços de call center, que em muitas aplicações
necessitam atender demandas de clientes vinte e quatro horas por dia e, com isso,
buscam por soluções que ofereçam recursos de alta disponibilidade. Este trabalho
apresenta um estudo de caso de implementação do sistema de call center RCX VM
Contact Center, baseado em Asterisk, em um projeto desenvolvido para prover recursos
de contact center com alta disponibilidade. Estes objetivos são alcançados através da
adoção de recursos de contingência implementados para proporcionar baixo tempo de
indisponibilidade.

Palavras-chave: Asterisk. Call Center. Continuidade de Negócios. Alta

Disponibilidade. SIP. VoIP.

1
Artigo apresentado como Trabalho de Conclusão do Curso de Especialização em Datacenter: projeto,
operação e serviços, da Universidade do Sul de Santa Catarina, como requisito parcial para a obtenção do
título de Especialista em Datacenter: projeto, operação e serviços.
1 INTRODUÇÃO

A continuidade de negócios é um tema que vem ganhando uma atenção especial

das empresas já há alguns anos. Segundo uma pesquisa realizada em (Continuity
Central, 2017), para cerca de 32% das organizações entrevistadas, quatro horas de
interrupção dos seus serviços ou menos podem ser fatais, podendo resultar no seu
desaparecimento. Esta necessidade por disponibilidade não é diferente para empresas
que possuem o atendimento a clientes como seu principal negócio, como no caso de
empresas especializadas em call center.

A implantação de plataformas de call center visando alta disponibilidade, com

contingenciamento de recursos geograficamente distribuídos, possuem um custo
elevado, devido principalmente a aquisição de equipamentos e licenças em quantidades
muitas vezes dobradas ou até mesmo triplicadas, além da complexidade de implantação
e atendimento a diversos cenários de desastres.

O projeto de continuidade dos serviços para uma estrutura de call center pode
ser extremamente complexo, pois precisa contemplar possíveis falhas em diversos
recursos e processos que compõem o sistema, como falha em hardware, equipamentos
de rede, software, banco de dados, links de dados e voz, bem como a forma como será
acionada a contingência para cada tipo de falha. Em uma estrutura de call center
simples, ou seja, não planejada para a continuidade de negócios, a falha de qualquer dos
itens acima pode acarretar na indisponibilidade parcial ou até mesmo total dos serviços,
isso sem contar uma falha de operação do datacenter, como por exemplo a falta de
energia elétrica.

O custo de operação e de manutenção de uma plataforma de alta disponibilidade

é um fator também a ser considerado em uma estrutura de telefonia. Recursos com
redundância precisam ser considerados para garantir a maior disponibilidade possível, e
em casos de utilização de plataformas de telefonia tradicional, com ramais analógicos e
digitais, o processo de implementação de alta disponibilidade pode ser oneroso se a
própria plataforma não disponibiliza destes recursos.

Tecnologias VoIP (Voice over Internet Protocol), que permitem a transmissão

de recursos de multimídia como voz e vídeo através da rede de dados convencional,
possibilitam a implantação de uma estrutura de comunicação sem a necessidade de
cabeamentos exclusivos para este fim, permitindo assim que usuários do sistema
possam usar seus recursos tanto localmente quanto em um local remoto. Esta
característica permite a construção de estruturas de telefonia convergentes e com
ambientes contingenciados em sites distantes da operação ou até mesmos dividir a
operação em diferentes localidades.

Este trabalho foi elaborado através de um estudo de caso de implantação do

sistema de call center RCX VM Contact Center2, baseado em Asterisk3, visando a
continuidade de negócios através da utilização de sistemas e recursos redundantes entre
dois datacenters. Os dados apresentados neste trabalho são frutos dos resultados desta
implementação e de testes de disaster recovery realizados para validação do ambiente
configurado.

Dentre as informações que serão apresentadas, estarão o método de configuração

do ambiente visando a continuidade de negócios, recursos de hardware e software
utilizados, recursos que complementam o ambiente de telefonia, topologias, cenários de
testes de disaster recovery e os resultados esperados e obtidos durante estes testes.

Este artigo está estruturado da seguinte forma: na seção 2, são detalhados através
da subseção 2.1 os conceitos e protocolos essenciais para o desenvolvimento deste
trabalho, abordando o gerenciamento de disponibilidade, sistemas telefônicos
tradicionais, o funcionamento da telefonia VoIP, o protocolo SIP e a estrutura de call
center. Através da subseção 2.2, a estrutura do ambiente de estudo de caso, estruturas de
contingência para garantir a alta disponibilidade, os planos de teste e os resultados
destes. A seção 3 apresenta a conclusão e propostas de trabalhos futuros.

2 IMPLANTAÇÃO RCX VM CONTACT CENTER

A necessidade da sociedade atual por serviços em tempo real e com a

possibilidade de realização de transações a qualquer horário do dia, trouxe desafios para
as empresas no que tange à implementação de ambientes de TIC para garantir que os
serviços estejam disponíveis o maior tempo possível.

Para proporcionar o maior tempo possível de operação de serviços, ou seja, o

menor tempo de interrupção aceitável pelo negócio, há a necessidade da configuração
2
http://www.rcxit.com.br/produtos.php?id=2
3
http://www.asterisk.org/
de ambientes em alta disponibilidade, o que demanda investimentos em infraestrutura,
equipamentos e sistemas de modo que suportem a demanda mesmo em caso de
sinistros. Em determinados casos, é necessário a duplicação de sistemas críticos para
que em casos de incidentes haja um ambiente operacional pronto para atender a
demanda dentro dos prazos considerados aceitáveis pela organização.

2.1 FUNDAMENTAÇÃO TEÓRICA

Esta seção possui como objetivo apresentar brevemente os conceitos e

protocolos essenciais para o desenvolvimento deste artigo.

2.1.1 Gerenciamento de Disponibilidade

Segundo Rosário (2016, p. 7) o processo de gerenciamento de disponibilidade

visa assegurar, através de ações proativas e reativas, que a necessidade de nível de
disponibilidade de serviços seja atendido, ou que possam exceder as expectativas atuais
ou futuras, a um custo justificável.

Para que estas necessidades sejam atendidas, é importante que seja estabelecido,
desde o nível de projeto de um novo serviço, quais as expectativas de disponibilidade,
confiabilidade e sustentabilidade para este serviço. Em paralelo, é importante também
analisar a capacidade de infraestrutura necessária, uma vez que esta análise está
diretamente relacionada a estimativa de custos e necessidade de recursos para
implantação do serviço de acordo com os níveis de serviços estabelecidos.

A disponibilidade pode ser definida como a capacidade de um serviço de

desempenhar as suas funções quando for requisitado (FILHO, 2012, p. 54). A
disponibilidade abrange não somente o serviço, mas também os demais componentes
que suportam este serviço, sendo dividido pela disponibilidade de serviço e
disponibilidade de componentes, que estão diretamente relacionados entre si, uma vez
que a disponibilidade do serviço pode ser causada pela indisponibilidade de um ou mais
componentes de TI que suportam este serviço. Porém, a indisponibilidade de um
componente pode ou não causar a indisponibilidade de um serviço, dependendo do nível
de contingenciamento de TI projetado para o mesmo.
 A confiabilidade pode ser definida como a capacidade de um serviço ou
componente de operar sem interrupções (FILHO, 2012, p. 54), ou seja, o tempo de
operação entre indisponibilidades. A confiabilidade de um serviço pode ser melhorada
através da utilização de componentes mais confiáveis, ou também através da
implementação de redundâncias de componentes.

No gerenciamento de disponibilidade ainda, a sustentabilidade é determinada

pela capacidade de tempo de recuperação de um serviço ou componente ao seu status de
operacional após a ocorrência de uma falha. (FILHO, 2012, p. 54).

Para cálculos de disponibilidade de serviços, deve ser levado em consideração a

configuração do ambiente, onde componentes ligados em serial tendem a proporcionar
um nível de disponibilidade inferior a sistemas que utilizam redundâncias em paralelo,
uma vez que se um componente falhar irá afetar um ou mais recursos do serviço.
Quando componentes em redundância são utilizados em paralelo, a indisponibilidade de
um componente pode ser suprida pelo componente que lhe contingencia. A figura 1
exemplifica estes dois cenários em um exemplo de sistemas de discos, assim como os
cálculos utilizados para ambos os ambientes.

Figura 1 – Cálculo de disponibilidade serial e paralelo

Fonte: (ROSÁRIO, 2016, p. 10)

2.1.2 Sistemas Telefônicos

Sistemas telefônicos, em sua função básica, consistem na transmissão de sinais

elétricos bidirecionais entre dois assinantes, sendo necessário para que isso ocorra, em
seu modelo mais básico, dois fios interligando os dois assinantes. A partir desta
infraestrutura e com a utilização de aparelhos telefônicos pelos dois assinantes,
aparelhos estes responsáveis por converter a voz humana e demais sons em sinais
elétricos na origem e estes sinais em som novamente no destino, é possível montar uma
estrutura de telefonia básica (JESZENSKY, 2004, p. 2).

As primeiras redes de telefonia possuíam uma topologia em malha, onde todos

os assinantes precisam estar diretamente conectados aos demais. Nesta topologia, o
custo para ampliação é alto, pois a cada novo assinante, novas conexões eram
necessárias para todos os demais assinantes.

Porém os sistemas de telefonia evoluíram muito além desta simples topologia.

Atualmente estes sistemas possuem centrais telefônicas de grande capacidade,
responsáveis pela comutação de chamadas entre assinantes de diferentes continentes
através de redes em estrela. Nestas redes, cada assinante possui somente uma conexão
com uma central de comutação que é responsável pelo roteamento da chamada para
outras centrais até o assinante de destino. A figura 2 representa as redes de telefonia em
malha e em estrela.

Figura 2 – Redes de telefonia em malha e estrela

Fonte: Adaptada de Jeszensky (2004, p. 41)

2.1.3 Telefonia IP – VoIP

Um dos fatores motivador pela pesquisa e desenvolvimento da telefonia IP

(Internet Protocol), mais conhecida como VoIP (Voice over Internet Protocol), foi a
necessidade de aproveitar recursos de rede e internet já disponíveis para transmissão de
voz, ao invés da tradicional estrutura de voz em protocolos analógicos e digitais
utilizados pelas operadoras, uma vez que dependem de alto investimento em
infraestrutura de cabeamento e de equipamentos de comutação. Outro fator é que em
muitos casos uma alta reserva de recursos é necessário para atender a demanda em datas
e momentos de pico, o que no restante do tempo era subutilizado por se tratar de uma
infraestrutura exclusiva para telefonia.

Apesar de a ideia de utilizar a internet para o encaminhamento de voz já existir

na década de 70, somente por volta do ano de 2000 esta solução começou a ser utilizada
em uma maior escala, fato este devido a evolução da estrutura e largura de banda da
internet, e no aumento de recursos de processamento dos computadores
(TANENBAUM, WETHERALL, 2011, p. 439). Estes dois fatores foram de extrema
importância para a adoção da telefonia IP em larga escala devido a sua necessidade de
transmissão em tempo real, onde os requisitos como atraso, perda de pacotes e tempo de
jitter4 devem ser baixos para que seja possível estabelecer uma comunicação com
qualidade satisfatória, uma vez que o tráfego de voz compartilha o meio de transmissão
com outros dados, diferentemente da telefonia tradicional onde os seus recursos são
exclusivamente dedicados.

Para uma comunicação completa de voz através de redes IP, diversos protocolos
são utilizados para os devidos fins. Entre eles estão o Session Initiation Protocol – SIP
(ROSENBERG e outros, 2002), responsável pelo controle geral de uma sessão, o Real-
time Transport Protocol – RTP (SCHULZRINNE e outros, 2003), que possui a função
de transporte de dados em tempo real e fornecimento de feedback referente à qualidade
do serviço, e o Session Description Protocol – SDP (HANDLEY; JACOBSON;
PERKINS, 2006), responsável por fornecer e negociar informações referente ao fluxo
de mídia da sessão. Outros protocolos podem ser utilizados em substituição destes,
porém devido as suas aplicabilidades, compatibilidade e confiabilidade, são os mais
utilizados na atualidade.

2.1.4 SIP – Session Initiation Protocol

Rosenberg e outros (2002, p. 9) definem o SIP como um protocolo de controle

da camada de aplicação responsável por estabelecer, modificar e encerrar sessões

4
Variação no atraso dos pacotes recebidos em uma rede.
multimídia, tais como chamadas telefônicas através da Internet. O SIP foi desenvolvido
para ser capaz de criar e gerenciar sessões de troca de dados entre os participantes em
uma rede IP, possibilitando estabelecer comunicações através de diferentes tipos de
mídias. Como a função do SIP está relacionada com a gerência de sessões, para a
construção de uma arquitetura multimídia completa o SIP pode ser usado
simultaneamente com outros protocolos. Estes incluem os protocolos definidos na seção
2.1.3, o RTP e o SDP. O funcionamento do SIP, porém, não depende de qualquer um
destes protocolos, mas permite que os participantes da sessão se descubram e possam
chegar a um acordo referente às características da sessão que irão iniciar
(ROSENBERG e outros, 2002, p. 10).

A estrutura do SIP é dividida em clientes, proxy e registradores. Clientes são

definidos por qualquer elemento de rede capaz de enviar, receber e responder
requisições SIP, como aparelhos telefônicos ou softphones. Os servidores proxy são
responsáveis por autenticar e autorizar serviços e recursos para clientes, além de rotear
requisições entre usuários, independente das suas localizações em uma rede local ou na
internet, garantindo assim a mobilidade oferecida pelo protocolo SIP. Registradores são
servidores responsáveis pelo recebimento de solicitações de registro de clientes e
possuem também a função de gerenciar a localização destes em um domínio SIP.

2.1.5 Call Center

Em ambientes de telefonia a busca por alta disponibilidade também é uma

tendência, principalmente em cenários em que a telefonia impacta diretamente no
cliente e está diretamente relacionada com o produto, como em ambientes de operadoras
de telefonia e também de call centers. Call center, segundo Mancini (2006, p. 13) é uma
evolução do antigo modelo telemarketing, que foi responsável por iniciar serviços como
de vendas e cobrança através de um sistema de telefonia ainda muito simples, em que
muitas vezes compreendia em pessoas com um aparelho telefônico e uma lista de
contatos realizando ligações para um determinado fim. O call center, como referido
anteriormente, foi a evolução deste modelo, onde recursos de informática foram
integrados ao sistema e a partir disso passaram a abranger uma quantidade mais ampla
de serviços, com uma maior qualidade de entrega dos serviços, a fim de atender as
demandas de um público alvo e também antecipar necessidades de clientes e manter as
marcas da empresa vivas na mente dos consumidores.

A partir da inclusão da informática nos sistemas de call center, estes ambientes

passaram a ter capacidade de cobrir grandes áreas geográficas com maior rapidez e
eficiência, reduzindo também o custo de operação. Dentre estes recursos, sistemas de
discagem automática inteligentes são utilizados para agilizar a realização e entrega de
ligações de clientes para os atendentes, evitando a necessidade de discagem manual do
contato. Unidades de resposta audíveis (URA) foram desenvolvidos para atender as
demandas de clientes sem a necessidade muitas vezes de atendimento por recurso
humano. Através de URAs de atendimento, é possível por exemplo esclarecer dúvidas,
realizar operações e contratar serviços por meio da navegação por menus audíveis, onde
as opções são acessadas e dados são informados através do teclado numérico do
telefone ou até mesmo através de reconhecimento da fala do cliente.

A gravação das ligações é outro recurso que passou a ser fundamental nestes
ambientes e em muitos casos exigida por lei. Este recurso é importante e utilizado para
comprovar a realização de transações, contratação de serviços e também para avaliação
interna do nível de atendimento. Relatórios são outro recurso muito utilizado para medir
o nível de serviço de atendimento, como tempo médio de espera, nível de abandono,
produtividade de atendentes, nível de satisfação de clientes com o produto e com o
atendimento.

2.2 ESTUDO DE CASO

A empresa de tecnologia e prestação de serviços, alvo deste estudo de caso e

denominada como empresa A, atua no mercado brasileiro, onde o seu serviço de
atendimento ao cliente está centralizado no Rio Grande do Sul e atende todo o território
nacional, suportando uma média de quatrocentas mil ligações receptivas e duzentas mil
ligações ativas por mês, dentre serviços de call center ativo e receptivo, sendo ao total
duzentos e setenta posições de atendimento.

A empesa possui seus serviços hospedados em dois datacenters localizados a

cerca de cinquenta quilômetros de distância, sendo o principal com classificação TIER
III Design Documents, certificada pela Uptime Institute5, e o secundário sem
certificação, porém com estrutura semelhante ao principal.

Este projeto teve início a partir da necessidade de redução de custos de operação

e manutenção com a atual plataforma de telefonia de call center, que por ser uma
plataforma híbrida, ou seja, com suporte a telefonia tradicional e VoIP, possui uma
estrutura de trinta e quatro servidores distribuídos em três racks, o que gera um custo de
operação e manutenção elevado.

Apesar de a plataforma atual possuir servidores redundantes para todos os

serviços de telefonia, a adoção de uma plataforma secundária de contingência foi
necessária devido a necessidade de alta disponibilidade dos serviços de call center,
estando o contrato de nível de serviço em 99,95% com atendimento 24 x 7, ou seja, no
máximo 4 horas de interrupção dos serviços ao ano incluindo manutenções planejadas e
testes de disaster recovery. Esta plataforma de contingência possui uma estrutura
totalmente VoIP baseada em Asterisk e máquinas virtuais, localizada no datacenter
secundário.

O processo de procura por uma nova plataforma de call center foi iniciada pela
necessidade de redução de custos desta estrutura, sendo algumas soluções avaliadas,
inclusive outro produto da empresa atual, porém a proposta que melhor foi aceita foi a
da RCX IT, com o RCX VM Contact Center, que mantem atualmente a solução de
contingência e, portanto, já possui desenvolvido as soluções de URA necessárias para o
projeto.

Dentre os requisitos para implantação do projeto, estava a necessidade de que a

nova plataforma deveria contemplar todos os serviços operacionais já suportados pela
plataforma atual, ser 100% VoIP com suporte ao protocolo de sinalização SIP,
possibilite a utilização de máquinas virtuais, possuir replicação em tempo real de
configurações e base de dados para ambiente de disaster recovery localizado no
datacenter secundário, além de garantir os 99,95% de disponibilidade dos serviços,
através de recursos contingenciados no datacenter principal.

5
https://uptimeinstitute.com
2.2.1 Estrutura do Ambiente

Como suporte ao ambiente necessário para implantação do projeto, alguns

recursos foram aproveitados da estrutura atual:

• Gateway E1: dois gateways de E16 Audiocodes Mediant 30007 de alta

disponibilidade com suporte para 42 E1’s;
• Links de E1: Nove E1’s da operadora Oi8 no datacenter principal e nove E1’s no
datacenter secundário destinadas a ligações receptivas, com chaveamento
automático pela operadora em caso de indisponibilidade ou total ocupação das
E1’s principais. Quatro E1’s da operadora Embratel9 no datacenter principal e
quatro no datacenter secundário destinadas a ligações ativas, com chaveamento
automático pela central telefônica em caso de indisponibilidade ou total
ocupação das E1’s principais;
• Link de dados: link de 20 Gbps via duas fibras ópticas dedicadas de operadoras
distintas utilizado para tráfego de dados, voz e replicação entre datacenters;
• VMware ESXi10: Estrutura de hosts de virtualização configurados para alta
disponibilidade através do VMware vCenter Server11;
• Banco de dados: estrutura de banco de dados em rack Oracle12 replicado em
tempo real em ambos os sentidos entre os dois ambientes através da solução
Oracle Golden Gate13.

Dentro da estrutura que será implementada estarão os seguintes recursos:

• Servidores SIP: dois servidores virtuais no datacenter principal e um servidor

virtual no datacenter secundário. Ambos os servidores possuem 16 núcleos de
processamento de 2,4 Ghz, 8 GB de memória e 200 GB de disco para
armazenamento de gravações;

6
Link de 2 Mbps que suporta a transmissão de 30 canais de voz digitais.
7
http://www.audiocodes.com/products/mediant-3000
8
Concessionária de serviços de telecomunicações brasileira, herdou grande parte do sistema de telefonia
fixa nacional após a aquisição da Brasil Telecom.
9
Empresa de serviços de telecomunicações brasileira, incorporada sob a empresa Claro S.A. em janeiro
de 2015.
10
https://www.vmware.com/products/esxi-and-esx.html
11
https://www.vmware.com/br/products/vcenter-server.html
12
https://www.oracle.com/br
13
http://www.oracle.com/technetwork/middleware/goldengate/overview/index.html
 • Servidores de URA: dois servidores virtuais no datacenter principal e um
servidor virtual no datacenter secundário. Ambos os servidores possuem 8
núcleos de processamento de 2,4 Ghz e 8 GB de memória;
• Servidores de Aplicação: dois servidores virtuais no datacenter principal e um
servidor virtual no datacenter secundário. Ambos os servidores possuem 4
núcleos de processamento de 2,4 Ghz e 4 GB de memória.

2.2.2 Estrutura de Contingência

Como forma de garantir os 99,95% de disponibilidade, o ambiente planejado de

forma que a indisponibilidade de recursos no datacenter principal não impacte ou
impacte o mínimo possível na disponibilidade dos serviços. Para isso todos os
componentes de TI possuem redundância com replicação em tempo real. Todas as
configurações de telefonia do Asterisk, além das demais informações geradas pelo
sistema estão armazenadas no banco de dados, e não localmente nos servidores. Todos
os servidores estão apontados para a estrutura de banco de dados do datacenter
principal, porém em caso de indisponibilidade deste o acesso é realizado no banco de
dados de contingência no datacenter secundário.

No ambiente principal, os servidores SIP, URA e de aplicação respondem por

meio de IP virtual através da ferramenta Pacemaker14 configurados nos próprios
servidores, sendo um o servidor principal e outro ficando em modo de espera para casos
de indisponibilidade do principal, ou para alguma eventual necessidade de manutenção.
A figura 4 apresenta a topologia de alta disponibilidade do ambiente.

14
http://clusterlabs.org/
Figura 4 – Topologia de alta disponibilidade

Fonte: Desenvolvida pelo autor

O ambiente no datacenter secundário entrará em operação somente em casos em

que o ambiente principal esteja totalmente indisponível. Para isso os sistemas clientes
estão programados para que em casos de incidentes onde não seja possível realizar o
registro SIP no ambiente principal, este registro seja realizado no ambiente de
contingência. Os softphones estão configurados para encaminhar pacotes SIP options
em intervalos de vinte segundos para o servidor SIP para monitorar o status do mesmo.
Em caso de transferência da operação para o servidor SIP secundário, em até vinte
segundos os softphones irão verificar a conexão e em caso de recusa do servidor SIP
encaminharão um novo pacote SIP register para efetuar novamente o registro do ramal.

Caso o softphone não tenha resposta do servidor SIP em um prazo de dois

minutos, é realizado o registro no servidor SIP de disaster recovery do datacenter
secundário. Os gateways de E1 possuem esta mesma configuração, para que nestes
casos as ligações sejam direcionadas para o servidor SIP de DR após dois minutos de
inatividade do ambiente principal. Este prazo de dois minutos foi estabelecido para
garantir que não seja uma indisponibilidade temporária no ambiente principal.
 Para atender a cenários de indisponibilidade específicos, foi adicionado um
serviço de monitoramento no sistema que monitora a disponibilidade do gateway de
rede onde estão alocados os agentes de call center. Neste monitoramento é verificado a
comunicação via protocolo ICMP (Internet Control Message Protocol) entre a
plataforma de telefonia e a rede dos agentes, onde em caso de falha nesta comunicação
os serviços de SIP do Asterisk dos servidores do ambiente principal são desativados
após dois minutos desta indisponibilidade. Este processo se faz necessário para que em
casos onde o sistema esteja totalmente operacional, porém as aplicações clientes não
consigam comunicação com a plataforma principal devido a um problema de rede, as
chamadas do gateway de E1 sejam direcionadas para o ambiente de contingência.

2.2.3 Disponibilidade

Como um dos principais requisitos deste projeto é a alta disponibilidade dos

serviços, a estrutura planejada visa atender esta necessidade através do
contingenciamento de componentes. Esta premissa é considerada não somente para os
componentes diretos do ambiente de telefonia, mas também para todos os demais
componentes dos quais o sistema é dependente, como dispositivos de rede, banco de
dados e links de comunicação.

Na figura 5 é demonstrado a topologia detalhada dos componentes que

compõem o ambiente de telefonia, bem como a disponibilidade estipulada para cada
componente e a disponibilidade total do ambiente. Foi estipulado a disponibilidade
individual de cada equipamento em um padrão de 99%, devido a dificuldade de buscar
estes índices junto aos fornecedores. Todos os componentes possuem fonte redundante
e discos redundantes no caso dos servidores.
Figura 5 – Disponibilidade ambiente de telefonia do call center

Fonte: Desenvolvida pelo autor

Para chegar ao resultado final de 99,95% de disponibilidade, o cálculo realizado

compreendeu em separar os ambientes em dois, sendo o primeiro contemplado pelo
datacenter principal e call center, onde os componentes contingenciados foram
considerados como componentes em paralelo e após realizado o cálculo em serial,
chegando ao resultado de aproximadamente 98,89%. O mesmo cálculo foi realizado
para o datacenter secundário, onde o resultado encontrado foi de aproximadamente
95,06%, sendo realizado o cálculo final os dois ambientes em paralelo.

2.2.4 Planos de Teste

Para validação do ambiente, alguns cenários de testes foram estabelecidos a fim

de validar o pleno funcionamento da estrutura de contingenciamento da plataforma. Os
testes abaixo foram realizados para validar contingenciamento dentro da estrutura do
datacenter principal.

• Teste 1: Desativação do servidor SIP 01, a fim de validar se servidor secundário

assumirá a operação. Religar servidor SIP 01 e realizar mesmo teste desativando
servidor SIP 02;
• Teste 2: Desativação somente do serviço do Asterisk do servidor SIP 01, a fim
de validar se servidor SIP 02 assumirá a operação. Reativar serviço Asterisk do
 servidor 01 e realizar mesmo teste desativando serviço Asterisk do servidor SIP
02;
• Teste 3: Desativação do servidor de APP 01, a fim de validar se servidor APP 02
assumirá a operação. Religar servidor de APP 01 realizar mesmo teste
desativando servidor APP 02;
• Teste 4: Desativação do serviço PHP do servidor de APP 01, a fim de validar se
servidor APP 02 assumirá a operação. Reativar serviço PHP do servidor APP 01
e realizar mesmo teste desativando serviço PHP do servidor de APP 02;
• Teste 5: Desativação do servidor de URA 01, a fim de validar se o servidor de
URA 02 assumirá a operação por completo. Religar o servidor URA 01 e
realizar o teste desativando servidor URA 02.
• Teste 6: Desativação do serviço do Asterisk do servidor de URA 01, a fim de
validar se servidor de URA 02 assumirá a operação por completo. Reativar
serviço do Asterisk da URA 01 e realizar o mesmo teste desativando Asterisk do
servidor URA 02;
• Teste 7: Desativação das E1’s do gateway de E1 principal para validação do
direcionamento das ligações receptivas pela operadora para o gateway de E1 no
datacenter secundário assim como o encaminhamento de ligações ativas pela
solução RCX para o gateway secundário;
• Teste 8: Alteração do IP do banco de dados principal nas configurações das
aplicações e dos servidores SIP e URA para validação do direcionamento das
conexões para banco de dados secundário.

Os testes abaixo foram realizados para validação do direcionamento do

atendimento para o ambiente de disaster recovery do datacenter secundário.

• Teste 9: Desativar os serviços do Asterisk dos dois servidores SIP do datacenter

principal, a fim de validar registro dos ramais e direcionamento das ligações dos
gateways de E1 principal e secundário para ambiente de DR no datacenter
secundário;
• Teste 10: Troca do IP monitorado do gateway de rede dos agentes de call center
para um IP inválido, a fim de validar o sistema de monitoramento da plataforma,
onde os serviços do Asterisk dos servidores SIP do ambiente principal deverão
 ser desativados a fim de direcionar os serviços para o ambiente de DR no
datacenter secundário. Os clientes SIP e gateways de E1 deverão registrar no
ambiente de DR.

2.2.5 Resultado dos Testes

Nesta seção são apresentados os resultados obtidos em cada um dos testes

especificados na seção anterior, através da tabela 1.

Tabela 1 – Resultados dos testes de disponibilidade

Teste Impacto Tempo de Indisponibilidade
Teste 1 Ligações em andamento foram Asterisk: contingência assumiu de forma imediata;
encerradas Ramais: aproximadamente 20 segundos para registro;
Agente: aproximadamente 25 segundos para registro.

Teste 2 Ligações em andamento foram Asterisk: contingência assumiu de forma imediata;

encerradas Ramais: aproximadamente 20 segundos para registro;
Agente: aproximadamente 25 segundos para registro.
Teste 3 Sem impacto Sem indisponibilidade. Acesso ao ambiente web
permaneceu ativo e sem queda perceptível.
Teste 4 Sem impacto Sem indisponibilidade. Acesso ao ambiente web
permaneceu ativo e sem queda perceptível.
Teste 5 Ligações em URA foram Sem indisponibilidade. Novas chamadas para URAs
encerradas foram direcionadas instantaneamente para servidor
reserva.
Teste 6 Ligações em URA foram Sem indisponibilidade. Novas chamadas para URAs
encerradas foram direcionadas instantaneamente para servidor
reserva.
Teste 7 Ligações externas em andamento Sem indisponibilidade. Ligações receptivas e ativas
foram encerradas encaminhadas para gateway secundário;
Teste 8 Sem acesso a dados da base de Aplicação: aproximadamente 5 segundos até virada
dados pela aplicação para banco de contingência.
Teste 9 Ligações em andamento foram Gateway E1: aproximadamente 2 minutos;
encerradas Ramais: aproximadamente 2 minutos;
Agentes: aproximadamente 2 minutos e 5 segundos.
Teste 10 Ligações em andamento foram Gateway E1: aproximadamente 4 minuto;
encerradas Ramais: aproximadamente 2 minuto;
Agentes: aproximadamente 2 minutos e 5 segundos.
Fonte: Desenvolvida pelo autor
3 CONCLUSÕES

A substituição de estruturas de telefonia tradicionais por tecnologias VoIP

trouxe diversos ganhos de recursos e de serviços, facilidades na criação e manutenção
de infraestruturas físicas, viabilidade de configuração de sistemas telefônicos de baixo
custo, e possibilidade de distribuição das operações em sites distintos através da
utilização de redes convergentes.

Usufruindo destas características de infraestruturas VoIP, e a possibilidade de

desenvolvimento de novas funcionalidades a partir do sistema de telefonia IP de código
aberto Asterisk, foi proposto a implantação de uma estrutura de telefonia para call
center em alta disponibilidade, baseada nas funcionalidades básicas de telefonia do
Asterisk porém com o desenvolvimento de novas funcionalidades operacionais e
recursos que tenham como finalidade aumentar a disponibilidade dos serviços em casos
de necessidades de manutenção ou em ocorrência de sinistros. Este objetivo é atingido
através da configuração de uma estrutura duplicada em paralelo para todos os ativos
necessários para a plena operação dos serviços, incluindo a replicação de banco de
dados em tempo real, e a configuração de um segundo ambiente em um datacenter
secundário.

Os resultados demostraram que o sistema é capaz de suportar tanto falhas de

ativos específicos, migrando a operação para o servidor reserva de forma instantânea e
recuperando a total operação em poucos minutos ou até mesmo em tempo real, assim
como suportar uma recuperação de desastre, onde existe a necessidade de migração total
da operação para um ambiente de contingência em um datacenter secundário. Outro
recurso validado com sucesso e de extrema importância é o correto direcionamento das
ligações em caso de indisponibilidades de E1, tanto de ligações ativas por parte da
central telefônica quanto de ligações receptivas em números 0800 e números únicos por
parte das operadoras.
 Como trabalho futuro, pretende-se implementar a solução de OTV15 (Overlay
Transport Virtualization) da Cisco16 em conjunto com o ambiente de VMware para
migração da estrutura completa de servidores e endereçamento de rede entre os dois
datacenters em caso de desastre do ambiente principal. Este recurso permitirá que haja
somente um ambiente operacional, e que este seja migrado por completo para o site
secundário em casos de necessidade, evitando que sistemas clientes e gateways de E1
precisem decidir para qual endereço IP devem apontar em casos de indisponibilidades
de ambientes.

15
http://www.cisco.com/c/en/us/solutions/data-center-virtualization/overlay-transport-virtualization-
otv/index.html
16
http://www.cisco.com/
REFERÊNCIAS

Continuity Central. Business Continuity Unwrapped (2006), Disponível em:

http://www.continuitycentral.com/feature0358.htm (em inglês), acessado em 10 de abr.
de 2017.

FILHO, F. C. ITIL V3 Fundamentos. Escola Superior de Redes RNP. 2012

HANDLEY, M.; JACOBSON, V.; PERKINS, C. SDP: session description protocol.

IETF, RFC 4566. Jul. 2006.

JESZENSKY, Paul Jean Etienne. Sistemas Telefônicos. Barueri: Editora Manole, 2004.

MANCINI, Lucas. Call Center: Estratégia para Vencer. São Paulo: Sumus Editorial,
2006.

ROSÁRIO, Djan de Almeida do. Disponibilidade e Qualidade Operacional de

Datacenters. Unisul Virtual. 2016.

ROSENBERG, J.; SCHULZRINNE, H.; CAMARILLO, G.; JOHNSTON, A.;

PETERSON, J.; SPARKS, R.; HANDLEY, M.; SCHOOLER, E. SIP: session initiation
protocol. IETF, RFC 3261. Jun. 2002.

SCHULZRINNE, H.; CASNER, S.; FREDERICK, R.; JACOBSON, V. RTP: a

transport protocol for real-time applications. IETF, RFC 3550. Jul. 2003.

TANENBAUM, Andrew S.; WETHERALL, David. Redes de Computadores. 5ª

Edição. São Paulo: Editora Pearson, 2011.