UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE GRADUAÇÃO EM ENGENHARIA DE COMPUTAÇÃO
MARCO ANTONIO MOREIRA CARUJO
CENTRAIS TELEFÔNICAS
TRABALHO DE CONCLUSÃO DE CURSO
NATAL 2018
MARCO ANTONIO MOREIRA CARUJO
CENTRAIS TELEFÔNICAS
Trabalho de Conclusão de Curso de Graduação, apresentado ao curso de Engenharia da Computação da Universidade Federal do Rio Grande do Norte – UFRN, como requisito parcial para a obtenção do título de Engenheiro da Computação.
Orientador: Prof. Dr. Carlos Manuel Dias Viegas
NATAL 2018
Carujo, Marco Antonio Moreira.
Centrais Telefônicas / Marco Antonio Moreira Carujo. - 2018. 34f.: il.
Monografia (Graduação)-Universidade Federal do Rio Grande do Norte, Centro de Tecnologia, Departamento de Computação e Automação, Engenharia de Computação, Natal, 2018.
Orientador: Dr. Carlos Manuel Dias Viegas.
1. VOIP - Monografia. 2. Asterisk - Monografia. 3. Telefonia - Monografia. 4. Freepbx - Monografia. I. Viegas, Carlos Manuel Dias. II. Título.
RN/UF/BCZM CDU 004.77 Universidade Federal do Rio Grande do Norte - UFRN
Sistema de Bibliotecas - SISBI
Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede
Dedico este trabalho primeiramente à minha família, a qual sempre esteve comigo no apoio da minha trajetória acadêmica e profissional que além de ser responsável por estas formações é também responsável pela formação dos valores e caráter de minha pessoa. Dedico a todos os companheiros da vida universitária tanto alunos quanto professores que juntos sempre compartilharam o conhecimento adquirido durante uma vida de estudo. Dedico também a todos os companheiros do estágio que dentro da Lógica Sistemas me ajudaram sempre que foi preciso para que esse projeto pudesse se tornar realidade.
RESUMO
CARUJO, Marco Antonio Moreira. Centrais Telefônicas. 2018. Trabalho de Conclusão de Curso (Graduação) – Engenharia de Computação. Universidade Federal do Rio Grande do Norte. Natal, 2018.
As Centrais Telefônicas desde sua invenção por volta de 1890 aos tempos de hoje estão em constante evolução. A telefonia digital vem crescendo em uso, aplicações e recursos. As chamadas VOIP são utilizadas nas plataformas de comunicação como Skype, Whatsapp, Facebook, Telegram entre outras. Por outro lado a telefonia analógica vem perdendo espaço. Com um futuro promissor para a telefonia digital, as centrais telefônicas digitais ganham espaços nesse cenário. A digitalização das ligações permite que sistemas computacionais se relacionem com essas ferramentas criando assim mecanismos modernos de ligações e interação entre usuários.
Neste contexto, este trabalho apresenta a criação de uma central telefônica digital, a qual terá que corresponder às necessidades da empresa financiadora do trabalho Logica Sistemas LTDA ME. Esta será construída com base nos softwares ‘open source’ Asterisk e Freepbx. Além disso, contemplará um back-end feito em
framework Laravel e uma interface web desenvolvida em ReactJS. O objetivo é
construir uma central telefônica que seja capaz de entregar todas as funcionalidades comuns, e integrando ao sistema de gestão de empresa aliado a uma interface de monitoramento.
ABSTRACT
CARUJO, Marco Antonio Moreira. Telephone Exchange. 2018. End of Course Work – Computer Engineering ( Graduation ). Federal University of Rio Grande do Norte. Natal, 2018.
The Telephone Exchange since its invention around 1890 to the present time are constantly evolution. The digital telephony has been growing in use, applications and resources. VOIP calls are used in communication platforms such as Skype, WhatsApp, Facebook, Telegram and others. On the other side the analogical telephony is losing space. With a promising future for digital telephony, as the digital figures gain environments in this scenario. The digitization of calls allows computer systems relate to these tools creating modern mechanisms connections and interaction between users.
In this context, this monograph presents the creation of a digital telephone exchange, which will have to correspond to the needs of the financier, the company Logica Sistemas LTDA ME. This will be built based on the open source softwares Asterisk and Freepbx. In addition, it will include a back-end made in Laravel framework and a web interface developed in ReactJS. The objective is to build a Telephone Exchange that is capable of delivering all the common functionalities, and integrating the management system of the company with a monitoring interface.
LISTA DE FiguraS
Figura 01 - Central telefônica datada de 1893... 10
Figura 02 - Central telefônica CPA datada de 1893.…... 11
Figura 03 - Central Telefônica Intelbras modelo CIP 92200…... 12
Figura 04 - Esquemático da Central em produção………...……... 14
Figura 05 - Esquemático do projeto.………...……... 15
Figura 06 - Esquemático do protocolo SIP………....………...……... 17
Figura 07 - Esquemático do modelo MVC………...……... 21
Figura 08 - Componentização do React JS………...……... 22
Figura 09 - Resposta do back-end Laravel...……... 24
Figura 10 - Esquemático da comunicação entre front-end e back-end...……... 25
Figura 11 - Página de login da Interface web... 26
Figura 12 - Página inicial da Interface web…...……... 26
Figura 13 - Página de monitoramento de ramais em tempo real……... 27
Figura 14 - Página de monitoramento de ligações………...……... 28
Figura 15 - Página de resumo de chamadas... 28
Figura 16 - Página de gravações……... 29
Figura 17 - Página de ramais... 29
Figura 18 - Página de filas..……... 30
LISTA DE ABREVIATURAS
ACK Acknowledgement
AGI Asterisk Gateway Interface AMI Asterisk Manager Interface
API Application Programming Interface CODEC Codificador/Decodificador
CPA Central de Programa Armazenado CPF Cadastro Nacional de Pessoas Físicas CSS Cascading Style Sheets
DOM Document Object Model ERP Enterprise Resource Planning HTML HyperText Markup Language HTTP HyperText Transfer Protocol
HTTPS HyperText Transfer Protocol Secure
IVR Interactive Voice Response JSON JavaScript Object Notation
LTDA Sociedade Limitada
ME Micro Empresa
MVC Model View Controller
NAT Network Address Translation
PABX Private Automatic Branch Exchange PHP Personal Home Page
RTP Real-time Transport Protocol SIP Session Initiation Protocol SPA Single Page Application
SSL Secure Sockets Layer UDP User Datagram Protocol URA Unidade de Resposta Audível VOIP Voice Over Internet Protocol
SUMÁRIO 1 INTRODUÇÃO... 09 1.1 Objetivos e Motivação……….…... 12 1.2 Metodologia...………...……... 12 1.3 Estrutura do Trabalho....………...……... 14 2 REFERENCIAL TEÓRICO...………...……... 15 3 DESENVOLVIMENTO………....………...……... 22 4 CONCLUSÃO………....………...……... 30
APÊNDICE A - FLUXOGRAMA DO SCRIPT...………...……... 31
9 1 INTRODUÇÃO
As primeiras centrais telefônicas foram criadas por volta de 1879. A comunicação era realizada por meio de comutações dos circuitos, onde um circuito físico real é formado entre os dois equipamentos que desejam se comunicar. Os elementos de comutação da rede unem (ou conectam) circuitos ponto a ponto até formar um "cabo" que interligue os dois pontos, esses procedimentos eram feitos de maneira manual por operador ou telefonista. Na Figura 1 está ilustrado como eram as primeiras centrais telefônicas, prateleiras com cabos sendo operados por telefonistas que realizavam a comutação do circuito. Já as primeiras centrais que dispensavam uma pessoa para completar uma ligação foram feitas em 1891 e funcionavam com mecanismos eletromecânicos, permitindo uma automatização do processo de comutação de circuitos que eram feitos pelos operadores, este sistema foi batizado com o nome de seu criador, O Sistema Automático de Strowger (IVO, 2017).
Figura 1 - Central telefônica datada de 1893
Fonte: Livro - "De Electriciteit" por P. van Capelle 1893
Apenas a partir dos anos 1970 as empresas de telefonia passaram a utilizar centrais digitais, também chamadas CPA (Central de Programa Armazenado). As CPAs são computadores específicos que também são chamados de “processadores
10 dedicados” para a função. Na Figura 2 é possível visualizar gabinetes de CPAs datados no ano de 1999. Estas trabalham com um software interno para execução das operações: interligar (comutar) terminais, executar controle, teste e gerenciamento do hardware, serviços adicionais (identificação de chamadas, transferência de chamadas, ligações simultâneas, etc.) aos clientes. Com o início das CPA no mundo da telefonia este ramo evoluiu junto com a tecnologia da computação. Na atualidade podemos ter centrais telefônicas dentro de computadores portáteis, servidores, em nuvem e até mesmo em sistemas embarcados (PINHEIRO, 2004).
Figura 2 - Central telefônica CPA datada de 1999
Fonte: Wikipedia
Dentro do mercado atual de centrais telefônicas foram encontrados diversos tipos de soluções, entre estas se destacam as categorias: softwares open source,
softwares comerciais, centrais completas e centrais em nuvens. Os softwares open source consistem em soluções de código aberto, com tutoriais ou manuais para a
sua utilização, além de contar com uma comunidade de usuários ativos que compartilham informações entre si. Os softwares comerciais são a categoria onde se encaixa o objetivo deste projeto, que visa a criação de um produto (central telefônica). Esta categoria é caracterizada pela comercialização de uma central telefônica desenvolvida geralmente por uma empresa, a qual fornece um software ao cliente, e oferece todo suporte de manutenção e configuração do mesmo. As centrais completas consistem em comercializar um hardware com software
pré-11 instalado. Na Figura 3 é possível visualizar um exemplo desta solução. Por fim, as centrais em nuvens se caracterizam pela utilização de softwares pagos com a utilização de computação na nuvem, ou seja, os softwares comerciais estão instalados em uma plataforma de computação em nuvem.
Figura 3 - Central Telefônica Intelbras modelo CIP 92200
Fonte: http://www.intelbras.com.br/empresarial/telefonia/pabx/ip/cip-92200
Em abril de 2018 a Anatel (Agência Nacional de Telecomunicações) anunciou que os números de telefones fixos caíram em 2,52% nos últimos 12 meses (ANATEL, 2018). Neste mesmo ano, no dia 18 de outubro, a empresa Uber apresentou recursos para comunicação na sua plataforma por meios de chamadas VOIP (Voice Over Internet Protocol) (SILVA, 2018). A revista Exame publicou em seu site uma matéria com a manchete: “Empresários adotam PABX (Private
Automatic Branch Exchange) em nuvem para diminuir os custos e aumentar a
produtividade” (DINO, 2018). Citando os motivos que levaram os empresários a investirem nesse segmento, dentre eles a possibilidade da redução de até 70% dos custos em telefonia na empresa. Dadas essas informações, nossa problemática está exatamente nos softwares open source que não são capazes de atender totalmente a nossa demanda dentro de um cenário específico: atendimento telefônico dos provedores de internet aos seus respectivos clientes. A empresa Lógica Sistemas LTDA ME, a qual é financiadora do projeto e dona dos direitos do software que será apresentado, é uma ‘software house’ que se dedica a construir softwares com fins comerciais e possui diversos produtos destinados ao público de provedores de internet.
Dentre os produtos criados pela empresa se destaca o Lógica ERP (Enterprise Resource Planning). Para o nosso projeto, este software possui os dados dos clientes (do provedor de internet) e a central deverá consultá-los para realizar um melhor atendimento. A rotina de um escritório de provedor de internet, consiste em receber ligações telefônicas de seus clientes com o contexto de: vendas, financeiro e suporte técnico. Cada chamada gera uma interatividade entre funcionário e cliente, fazendo assim que seja perdido produtividade pelos
12 funcionários do provedor. Nesse ponto a central telefônica deve ajudar a obter um melhor resultado, reduzindo essa interatividade e fornecendo mecanismos para automatizar processos mais corriqueiros, como envio de segunda via de boleto, por exemplo. Além de entregar ao provedor a capacidade de monitorar suas linhas telefônicas e ramais, o mesmo precisa ter a capacidade de resgatar uma gravação de chamada entre ele e seu cliente.
1.1 Objetivos e Motivação
O objetivo deste projeto é criar uma central telefônica que seja capaz de receber e efetuar chamadas, gravar, monitorar o comportamento da mesma e possuir integração com o Lógica ERP. As funcionalidades básicas de uma central são: PABX, IVR (Interactive Voice Response), filas de atendimento e gravação de chamada. A central criada terá que apresentar uma interface web capaz de administrar ramais e filas de atendimento.
Dentro do mercado, o que motiva é o fato de que não há nenhum produto que se adeque perfeitamente à nossa necessidade. Vários pontos das soluções que estão no mercado, precisam ser levados em consideração, entre eles, o principal é que o público alvo são pessoas que não possuem conhecimento técnico na área. A ausência de um monitoramento eficiente dentro da interface web é um dos assuntos que serão explorados no projeto. A necessidade de telas ‘dashboards’ para serem utilizadas pelos provedores faz com que elas sejam bem valorizadas, tornando a automatização do atendimento mais integrado. O envio da segunda via do boleto e a destinação do atendimento ao setor correspondente serão feitos com base nos dados do cliente presentes no Lógica ERP.
1.2 Metodologia
Dentro das necessidades apresentadas, o software construído precisou aproveitar ferramentas open source na sua construção, dentre elas o Asterisk e Freepbx. A interface web Freepbx não foi utilizada como a interface web do nosso projeto, devido à sua complexidade e linguagem técnica. Optamos por criar uma nova interface feita em ReactJS, que será uma SPA (Single Page Application) com telas mais simples e intuitiva. Esta nova interface web precisou de um API (Application Programming Interface) que será o nosso back-end para entregar os
13 dados à interface. Dentro do Asterisk será utilizado o AGI (Asterisk Gateway Interface) para uma comunicação ao Lógica ERP, que por sua vez disponibilizou uma API para que a integração seja possível. Para que tudo isso possa funcionar em conjunto, será utilizado o Docker, para que os ambientes do back-end e
front-end sejam indepfront-endentes entre si e entre o sistema operacional. Este planejamento
pode ser visualizado na Figura 4, que apresenta toda as relações entre as etapas descritas.
Figura 4 - Esquemático da Central em produção
Fonte: Autoria própria
Devido a complexidade do projeto que está relatado na Figura 4, o mesmo foi dividido em partes pelo seus respectivos focos, onde cada parte possui as suas funcionalidades. O projeto consiste em 4 partes, que entre si se comunicam, como está esquematizado na Figura 5. A parte 1, consiste na utilização dos softwares
open source Asterisk e Freepbx, como também seus derivados AGI e AMI (Asterisk
Manager Interface). A parte 2, é a utilização do framework para comunicação do AGI e da API, disponibilizada pelo Lógica ERP. A parte 3, é a API do back-end, a qual é feita em Laravel e terá a função de colher informações do Asterisk e Freepbx para serem repassadas para a interface web. E por fim a parte 4, onde a interface web é feita em ReactJS, possuindo um design moderno que basicamente funcionará recebendo informações do back-end e as exibindo.
14 Figura 5 - Esquemático do projeto
Fonte: Autoria própria 1.3 Estrutura do Trabalho
Além desta introdução, este documento está organizado em mais 3 capítulos. No Capítulo 2 são apresentadas as tecnologias usadas e suas funções dentro do projeto. Seguindo a linha de raciocínio imposta na metodologia, cada parte será descrita pelo seu funcionamento. O Capítulo 3 descreve a parte do desenvolvimento da nossa central, nela será dado mais detalhes técnicos dos recursos em funcionamento. E por fim, o Capítulo 4, que será o resultado de como ficou o funcionamento da central como um todo, avaliando pontos críticos do projeto.
15 2 REFERENCIAL TEÓRICO
Na primeira parte do projeto utilizamos o Asterisk, o qual utiliza tecnologias VOIP para a realização de um PABX convencional, contemplando recursos de ligações com ramais, filas de atendimento, URA (Unidade de Resposta Audível) e etc. Um PABX é o conceito de gerenciamento de chamadas: as requisições de chamadas chegam ao servidor e são manipuladas para que cheguem ao seu destino. Dentro dessa manipulação de chamadas podemos encontrar recursos como gravação de chamadas, reprodução de áudios pré-gravados, conferência entre ramais, entre outros.
O Asterisk permite que criemos ramais, com isso podemos nos comunicar entre os ramais. A interface de operação, conFiguração e monitoramento do Asterisk é via terminal. Essas chamadas dentro do Asterisk utilizam como base dois protocolos de rede para o seu funcionamento, o primeiro é o protocolo SIP (Session Initiation Protocol).
O protocolo SIP é responsável por inicializar uma chamada VOIP. O seu procedimento consiste em 3 etapas: agente do utilizador, registrador e proxy. O agente do utilizador é a etapa que representa um terminal SIP, onde serão recebidas as ligações, dessa maneira pode-se dizer que consiste na representação dos ramais. O registrador é a entidade que tem a função de se comunicar periodicamente com o servidor para uma troca de informações entre o agente do utilizador e servidor. Por fim, o proxy encaminha os pedidos do agente utilizador para o servidor, como por exemplo a inicialização de uma chamada (BARTSH, 2013).
As etapas para a criação de um canal de comunicação VOIP estão ilustradas na Figura 6, na qual primeiramente um agente do utilizador de origem efetua, via
proxy, um pedido ao servidor para inicialização de chamada com um outro agente do
utilizador de destino. O pedido ao ser recebido pelo servidor é confirmado pelo mesmo, e enviado para o agente do utilizador de origem para uma confirmação de que o mesmo foi recebido, e por fim também envia para o agente utilizador de destino um pedido de inicialização de chamada. Quando o destino recebe o pedido de chamada no seu próprio proxy ele altera o seu estado e confirma ao servidor que está preparado para receber a chamada. O servidor ao receber a confirmação do agente do utilizador de destino, repassa para o agente do utilizador de origem que o
16 pedido foi aceito pelo destino, sendo assim ambos mudam seu estado (BARTSH, 2013).
Neste ponto ambas extremidades estão preparadas para inicializar uma chamada, porém a mesma ainda não foi iniciada, pois falta nesse momento a confirmação da ligação pelo usuário no agente do utilizador de destino. Com a confirmação da chamada realizada no agente utilizador de destino, esta confirmação é passada para o servidor que repassa para o agente do utilizador de origem, que novamente repassa o recebimento da confirmação de reconhecimento via ACK (Acknowledgement). Dado que ambos os lados da extremidade estão prontos para começar a chamada de fato, o servidor gerencia as aberturas de portas “altas” no protocolo UDP (User Datagram Protocol) para que a transmissão do áudio possa ocorrer por via do protocolo de transmissão VOIP (BARTSH, 2013).
Figura 6 - Esquemático do protocolo SIP
Fonte: http://blog.sippulse.com/entenda-como-funciona-um-dialogo-sip-protocolo-utilizado-em-ligacoes-voip/
Para finalizar a chamada, um dos lados envia um sinal de finalização para o servidor que repassa para o outro lado da extremidade, esta por sua vez confirma a finalização da chamada e repassa ao servidor o reconhecimento desta ação. Por fim, o servidor confirma ao agente do utilizador que enviou o sinal de finalização, que o seu pedido foi realizado, sendo assim na outra extremidade a chamada está
17 encerrada (BARTSH, 2013).
Para toda transmissão de som feito no Asterisk, é utilizado o protocolo VOIP, o qual consiste em converter um sinal de áudio analógico em um sinal digital e posteriormente transformado-o em pacotes de dados, para que sejam transmitidos pela rede com o protocolo UDP. A conversão do sinal analógico para o digital é realizada com CODEC (Codificador/Decodificador), existindo a possibilidade de conversão com perdas ou sem perdas na qualidade do sinal original. A escolha do CODEC é um ponto importante para a transmissão de áudio, visto que CODECs que possuem perdas são mais leves e necessitam de uma menor largura de banda em relação aos CODECs que não possuem perdas. Um padrão de CODEC é o G.711, possuindo perdas na conversão, ficando com uma taxa de transmissão de 64 Kbit/s (quilobit por segundo). Essa transmissão é auxiliada pelo protocolo RTP (Real-time Transport Protocol), o qual define como deve ser feita essa fragmentação do sinal digital em pacote de dados (ROCHA, 2018).
Outro recurso utilizado para a central telefônica produzida, foi o Freepbx. Pelo fato do Asterisk ter uma interface a nível de terminal e o Freepbx ser uma interface
web para o Asterisk. Ambos entregam recursos que foram denominados para o
“PABX convencional”. O Freepbx torna os parâmetros do Asterisk visíveis de maneira confortável para um usuário. O seu funcionamento consiste em uma interface web com sistema de usuários e modular. O Sistema de usuários consiste em utilização de grupos de usuários onde cada determinado grupo tenha permissões distintas, o administrador tem acesso ilimitado ao servidor, já um outro determinado grupo criado pode ter acesso apenas ao módulo de históricos de chamadas.
A arquitetura web é dividida em módulos e permite que estes sejam instalados e desinstalados conforme a necessidade do usuário. Sua interface é executada pelo servidor HTTP (HyperText Transfer Protocol) Apache, adicionando a uma estrutura preparada para receber requisições e efetuar as respostas para o usuário. A capacidade de segurança da interface é adicionada pelo Apache com a implementação do protocolo HTTPS (HyperText Transfer Protocol Secure). Este protocolo acrescenta uma camada SSL (Secure Sockets Layer) para que sejam criptografados os dados transmitidos entre o cliente e o servidor, provendo maior segurança e confiabilidade dos dados (FREEPBX, 2018).
Possuindo um banco de dados relacional MySQL para intermediar as informações contidas no Asterisk. Um banco de dados é um sistema de
18
gerenciamento de dados. Como toda a interface do Freepbx é dividida por módulos e estes estão relacionados entre si. As tabelas do banco de dados estão relacionadas de maneira análoga. No MySQL, o Freepbx se divide em dois bancos: ‘asterisk’ e ‘asteriskcdrdb’. O banco chamado ‘asterisk’ consiste em toda a representação dos módulos em tabelas como também as relações dos módulos com as relações de tabelas. Como por exemplo uma URA pode destinar uma ligação para uma fila de ramais, logo o módulo de URA tem uma relação com o módulo de filas, sendo assim essa relação está presente no banco de dados. As vantagens presentes nesse modelo de representação de dados são: consistência ao dados armazenados, uma vez que muitos módulos possuem dependências de outros, a organização dos dados que possuem relação mas estão organizados em tabelas diferentes. As desvantagens são a complexidade que surge, onde um conjunto de dados precisam estar ligada a outro conjunto de dados (NETO, 2011).
Dentro dos módulos presentes, destacam-se os de ramais, filas e chamadas. O módulo de ramal disponível, lista todos os ramais e informações nos mesmos, como também possui formulário para a criação e edição de ramais. O módulo de filas permite que ramais sejam agrupados entre si, fazendo o conjunto ser uma ‘fila de atendimento’. Dentro dessa fila existem diversos aspectos a serem conFigurados, como por exemplo a estratégia de que todos os ramais tocam ao mesmo tempo, além de permitir gravações de chamadas. A área das chamadas presentes no Freepbx permite a verificação detalhada do histórico. Também permitindo que uma gravação de chamada seja reproduzida ou baixada na própria interface.
Na parte 2, temos o AGI, que será a base para o controle de chamadas do Asterisk, consequentemente dentro da central telefônica. Utilizando scripts de PHP (Personal Home Page) que conectado ao AGI se comunica com o Asterisk, permitindo acesso às variáveis de ambiente. Manipulando as variáveis do ambiente podemos ter o controle sobre os canais (chamadas). Todo esse procedimento é síncrono, e cada execução ocorre exclusivamente de maneira sequencial no script (GORNSTEIN, 2017).
O AGI é um framework que garante a comunicação de uma aplicação com o Asterisk. Este framework está disponível em diversas linguagens, entre elas a que foi utilizada, o PHP. Na prática podemos decidir o áudio que será reproduzido para o usuário, como requisitar dados do mesmo (DIGIUM, 2018).
Para a tomada de decisão durante a chamada é fundamental a identificação do cliente, e para isso é necessário se comunicar com a Lógica ERP, como foi
19 esquematizado na Figura 4. Esta comunicação foi feita por uma API, com request e
response em padrão JSON (JavaScript Object Notation) pelo protocolo HTTP. O
padrão JSON é um modelo para armazenamento e transmissão de informações no formato texto, permitindo assim que seja transmitido dados entre aplicações de linguagens diferentes (GONÇALVES, 2012).
Do lado do Lógica ERP, a API está em produção em uma determinada porta que é informada para o script e com uma pequena autenticação de usuário e senha. A API faz consultas ao banco de dados presente no lado do Lógica ERP e retorna o resultado dessas consultas para os scripts.
Na parte 3, temos a construção da API back-end com a finalidade de fornecer dados para a nossa interface web. Essa API foi feita com o framework de PHP Laravel. O framework é voltado para o cenário web e utiliza o padrão de desenvolvimento web MVC (Model, View, Controller). O Padrão MVC, consiste em que toda a sua aplicação web seja dividida em 3 partes: Model, View e Controller. O Laravel fornece ao usuário recursos que facilitam o desenvolvimento, destacando-se a comunicação com o banco de dados e a validação de dados que são utilizados na parte de model. No controller está presente as rotas que determinam qual ação da API está sendo requisitada, dado que a ação foi determinada, são enviados os dados para o controller, que pode verificar a permissão da requisição e por fim permitir que esta seja cumprida pela API. Por fim a parte de view consiste na etapa de visualização da sua aplicação web. Nela fica toda a interface que é apresentada para o usuário (RAMOS, 2015).
Toda a arquitetura MVC está representada pela Figura 7. Uma interface do Asterisk que será acionada nesta parte do projeto é o AMI (Asterisk Manager Interface). Com esta interface é possível monitorar os canais de chamadas VOIP que estão abertos. Com essa interface conseguimos fazer todo o monitoramento dos ramais, filas e chamadas que estão ocorrendo em tempo real na central telefônica (LIMA, 2017).
20
Figura 7 - Esquemático do modelo MVC
Fonte: https://tableless.com.br/mvc-afinal-e-o-que/
Na parte 4, temos a construção da interface web que receberá as informações da API presente no back-end. O ReactJS é utilizado para a criação da interface. Trata-se de uma biblioteca feita em JavaScript, totalmente destinada ao desenvolvimento de páginas web, e dentro de suas propostas encontra-se, velocidade na renderização, componentes reutilizáveis e flexibilidade. A velocidade na renderização é resultado migração do DOM (Document Object Model) que passou a ser armazenado na memória virtual do computador (LIMA, 2017).
“O DOM (Document Object Model) é uma interface que representa como os documentos HTML (HyperText Markup Language) e XML (Extensible Markup Language) são lidos pelo seu browser. Após o browser ler seu documento HTML, ele cria um objeto que faz uma representação estruturada do seu documento e define meios de como essa estrutura pode ser acessada.” (MALDONADO, 2018) Além do DOM, uma SPA feita com o ReactJS faz com que todo o conteúdo gráfico da página seja previamente baixada e armazenada no navegador do usuário. No caso de uma alternância de páginas, não é necessário que sejam baixados novamente os recursos gráficos da interface, apenas dados que preenchem as páginas na alteração de estados dos componentes DOM. Os componentes reutilizados do ReactJS permitem que o desenvolvedor crie componentes na sua interface e que estes possam ser reaproveitados em outras ocasiões do projeto, ou até mesmo que sejam compartilhados na comunidade open source. A Figura 8
21 mostra um componente filho, que é utilizado três vezes seguidas dentro do componente pai, que por sua vez está contido no componente raiz. De maneira geral a Figura 8 nos mostra como pode ser estruturado uma página ReactJS. Cada um dos três componente são uma estrutura de HTML, CSS e JavaScript, e os mesmos podem estar sendo compartilhados pela comunidade do framework ou sendo comercializados. Toda a flexibilidade do ReactJS se dá pelo fato dele não impor uma arquitetura de desenvolvimento, é possível desenvolver uma aplicação completa apenas com o ReactJS, ou utilizando diversas outras ferramentas de outras linguagens de programação (LIMA, 2017).
Figura 8 - Componentização do React JS
Fonte: https://br.udacity.com/blog/post/5-razoes-desenvolvedores-react
A etapa de produção de uma aplicação, consiste em colocar a aplicação feita em funcionamento, isto é colocá-la da maneira ideal para ser utilizada pelo usuário. O Docker é uma ferramenta que auxilia esta etapa. A produção de toda a central foi feita com o Docker, que é uma tecnologia que oferece virtualização por meio de contêineres. Esta utiliza o kernel da máquina, na qual se encontra, para ser utilizada pelo ambiente virtualizado. Além disso, esta solução consegue automatizar processos de instalação de contêineres virtualizados dentro de um servidor. Cada contêiner é executado com um ambiente independente chamado de “imagem”. O Docker também permite fazer redirecionamento de portas do servidor (portas externas) para portas de contêiner (portas internas), fazendo com que os serviços estejam rodando dentro dos mesmos e sejam acessíveis no servidor (BONAFÉ, 2015).
22 3 DESENVOLVIMENTO
Como referido no Capítulo 2, a primeira parte do projeto utiliza os softwares Asterisk e Freepbx para que a central telefônica desenvolvida seja capaz de entregar os recursos de um PABX. O Asterisk foi instalado e conFigurado, e é o responsável por implementar o protocolo SIP. Nesta etapa também são instaladas e conFiguradas as interfaces AGI e AMI, que são utilizadas por outras partes do projeto. Posteriormente, um banco de dados MySQL é instalado para que o Freepbx utilize-o para seu funcionamento. Uma vez realizadas estas etapas, a central está capacitada de entregar os recursos necessários para seu funcionamento.
Utilizando o protocolo SIP pelo Asterisk, a Central consegue criar ramais e estes são autenticados em programas (softphones) ou em telefones IP, que utilizam a mesma estratégia do anterior, porém implementados em hardware. Caso a Central receba uma chamada, é criado um canal para a comunicação VOIP para o estabelecimento da chamada, que passará por uma fila de atendimento ou uma URA, até chegar a um ramal. As gravações de chamadas são conFiguradas no Asterisk e no Freepbx. A permissão é dada de maneira individual, para um ramal ou fila específica. Dado que a permissão seja positiva, os áudios serão salvos localmente no servidor. Na interface web criada podemos acessar esses áudios e disponibilizá-los para download.
Dentre todos os módulos presentes no Freepbx, os que foram o foco da central são os módulos de ramais e filas. Essas funcionalidades estão disponíveis para conFiguração parcial na interface web. Permitindo que ramais sejam criados, editados e excluídos. As filas de atendimento permitem apenas que seus membros sejam modificados. Essas funcionalidades estão disponíveis para conFiguração parcial na interface web, onde está sendo abordado de maneira mais legível ao usuário do que o Freepbx apresenta.
A segunda parte do projeto está relacionada ao funcionamento dos scripts AGI que se comunicam por intermédio do protocolo HTTP com a API do Lógica ERP. Toda a troca de dados feita pelas partes estão formatados no padrão JSON (JavaScript Object Notation). Os scripts AGI recebem uma ligação, reproduzem áudios pré-gravados e aguardam o usuário digitar números (entrada de dados). Após receber esses dados, o script consulta a API do Lógica ERP e toma decisões com base nas informações recebidas. No apêndice A é possível ver todo o fluxograma de uma chamada controlada pelos scripts. Com essa combinação a
23 central pode identificar clientes com o número de telefone do autor da ligação ou CPF (Cadastro Nacional de Pessoas Física) digitado durante a ligação, além de permitir a automatização de procedimentos corriqueiros, como por exemplo, envio de boletos.
Na terceira parte do projeto está o back-end, que se comunicará com a primeira parte e fornecerá dados ao front-end. A API irá buscar informações presentes no banco de dados do Freepbx, como ramais, filas e gravações presentes. Toda essas informações são transmitidas com dados formatado em JSON, como está ilustrado na Figura 9, a qual mostra a resposta de uma requisição. Todo o código desenvolvido com o Laravel consiste na arquitetura de desenvolvimento web MVC, exceto a parte de visualização que não caberá ao Laravel e sim ao ReactJS. A interface AMI do Asterisk foi explorada nessa parte do projeto, onde o back-end efetua consultas a essa interface e responde em tempo real com informações de elementos como: canais, ramais e filas. O back-end também é responsável pela autenticação da interface web. A validação dos dados que chegam à API é muito importante, e o Laravel com a ferramenta Validation consegue ser eficiente, sendo assim, requisitada sempre que uma informação precisa ser recebida da interface web. Como exemplos de dados a serem validados, destacam-se um intervalo de datas para consulta no histórico de chamadas.
Figura 9 - Resposta do back-end Laravel
Fonte: Autoria própria
As conexões da central telefônica com o banco de dados do Freepbx ocorrem com o Laravel e o MySQL por meio do Eloquent. Isto é, as informações do Freepbx que estão no banco de dados são acessadas diretamente pelo back-end por meio
24 do Laravel. O Eloquent é um recurso presente dentro do Laravel para acesso a bancos de dados. O back-end espera que seja feita uma requisição pelo front-end (request) e esta será processada pelo controller e model, e por fim respondida ao
front-end (response). O front-end ao receber a resposta do back-end reproduz os
dados na interface web para o usuário. A Figura 9 mostra de maneira resumida o comportamento dessa relação entre front-end e back-end. Além disso, na Figura 7 é possível visualizar essa arquitetura, onde a view é representada pelo front-end e o
back-end é representado pelos elementos controller e model . A produção dessa API
é feita pelo servidor HTTP Apache.
Figura 10 - Esquemático da comunicação entre front-end e back-end
Fonte: Autoria própria.
Na quarta parte do projeto, temos a interface web feita com o ReactJS. Um
web template desenvolvido em Javascript, HTML e CSS que foi adquirido pela
empresa detentora dos direitos do software, a Lógica Sistemas LTDA ME, e formatado para o framework em questão. Com base nesse template foram utilizados seus recursos para a construção de oito telas funcionais compondo assim a interface
web.
A primeira tela é o de autenticação no sistema, que basicamente é um formulário com dois campos e dois botões, a qual pode ser visualizada na Figura 11.
25
Figura 11 - Página de login da Interface web
Fonte: Autoria própria
A segunda tela é a tela padrão da interface, que podendo ser visualizada na Figura 12, e que apresenta informações sobre o hardware do servidor, as chamadas ativas e últimas chamadas realizadas. Além de mostrar a barra de navegação lateral utilizada para alternância de telas, também possui uma barra superior para controle do usuário. Essas duas barras estão presentes em todas as telas após o procedimento de login.
Figura 12 - Página inicial da Interface web
Fonte: Autoria própria
26 são divididas por colunas presentes na central telefônica e em cada linha estão os ramais presentes nas suas respectivas filas. A Figura 13 visualiza a tela de monitoramento de ramais, a qual capta informação do back-end em tempo real, ou seja, monitora a situação dos ramais em tempo real. Os ramais que estão com coloração cinza estão offline, os que estão com coloração verde estão online.
Figura 13 - Página de monitoramento de ramais em tempo real
Fonte: Autoria própria
A quarta tela é nomeada de “ligações” e apresenta três pequenos gráficos que na ordem representam, resumo da situação dos ramais em filas, ligações de entradas e ligações de saídas. E abaixo dos três pequenos gráficos se encontra um gráfico em linha que mostra o número de chamadas atendidas no decorrer do dia. Esta tela pode ser visualizada na Figura 14.
27
Figura 14 - Página de monitoramento de ligações
Fonte: Autoria própria
A quinta tela é nomeada de “Chamadas” e apresenta um formulário que ao ser preenchido, gera um gráfico com o resumo das chamadas que ocorreram na central. Este gráfico pode ser visualizado na Figura 15, na qual a coluna verde representa as chamadas atendidas, a coluna azul representa as chamadas não atendidas por ausência de resposta, e por fim a coluna vermelha representa as chamadas que não foram atendidas por ocupado.
Figura 15 - Página de resumo de chamadas
28
A sexta tela é a de “gravações”, onde é possível o usuário preencher um formulário com a “data de início” e “data final” para uma consulta de todas as chamadas que foram atendidas. Após feita a consulta é preenchida uma tabela que informa campos como: data, origem, destino, duração e gravações de chamadas. Esta tela pode ser visualizada na Figura 16.
Figura 16 - Página de gravações
Fonte: Autoria própria
A sétima tela é a de “ramais”, onde o usuário poderá listar todos os ramais presentes na central, como: criar novos ramais, editar os existentes e excluí-los. Para isso esta tela tem uma tabela com as colunas: número do ramal, nome, senha e status. Cada coluna da tabela permite filtragem e ordenação. Para edição do ramal é visualizado um modal com um formulário. Esta tela pode ser visualizada na Figura 17.
Figura 17 - Página de ramais
29
E por último, a oitava, de “filas”, que consiste em uma tabela com as colunas: número da fila, nome, quantidade de membros, estratégia de toque e a conFiguração de permissões para gravação de chamadas. Também para edição dos integrantes da fila é apresentado um modal. Esta tela pode ser visualizada na Figura 18.
Figura 18 - Página de filas
Fonte: Autoria própria
O Docker foi utilizado para que back-end e front-end entrasse em produção. Por ele foram executados dois containers: um com um ambiente para o React JS e outro para o Laravel. Na Figura 19 é possível visualizar a resposta do comando ‘docker ps’, que retorna os containers do Docker em execução.
Figura 19 - Resposta do Docker no terminal do servidor
30 4 CONCLUSÃO
Este trabalho apresentou o desenvolvimento de uma central telefônica da empresa Lógica Sistemas LTDA ME, a qual permitiu de maneira eficaz a implementação de todas as funcionalidades básicas de um PABX. O armazenamento das chamadas gravadas é realizado de maneira eficiente e segura. A comunicação do script com a API do Lógica ERP ocorre em uma velocidade abaixo de 10 ms, que é um tempo de espera muito baixo para um usuário em uma ligação. O back-end feito em Laravel consegue responder a quase todas requisições em até 50 ms, o que está dentro do esperado tornando viável para exibição de dados na interface web. A validação do dados recebidos se mostrou bastante segura, permitindo que apenas seja respondido request com parâmetros dentro do padrão esperado. O front-end apresenta telas mais limpas e simples do que o Freepbx, onde formulários muito extensos foram simplificados na nova central. O
design presente no template é mais contemporâneo e intuitivo do que o Freepbx.
O resultado para a empresa Lógica Sistemas foi satisfatório, onde a necessidade de abertura de suporte para pedidos de informações relacionadas a usuário e senha de ramal foi eliminado. Para o provedor de internet, o envio de segunda via de boleto pelo script, tem o potencial de diminuir de maneira satisfatória a interação do cliente com os funcionários do provedor. As telas de dashboard têm sido usadas e permitem uma melhor administração em torno da distribuição de efetivo para atendimento telefônico de seus clientes.
Como trabalhos futuros, novas funcionalidades na interface web serão criadas para atender ao requisito da empresa de criar um produto independente, onde o cliente ao ser treinado e com um manual em mãos, seja capaz de criar a sua própria central. A estrutura por trás do produto deverá sofrer uma alteração. A necessidade de um processo de instalação será suprida pelo Docker. O Freepbx e Asterisk (parte 1 do projeto) será totalmente feita por contêineres, dando assim uma automatização e segurança de execução, pois o Docker gerencia toda a execução de seus contêineres. O que torna a central diferenciada é a integração com o Lógica ERP, e esta deve ser explorada, criando novas funcionalidades como abertura de protocolo de atendimento.
31 APÊNDICE A - FLUXOGRAMA DO SCRIPT AGI
32 REFERÊNCIAS
ANATEL. “Telefone fixo tem queda de 2,52% em 12 meses”. 2017. Disponível em: <http://www.anatel.gov.br/institucional/noticias-destaque/1984-telefone-fixo-tem-queda-de-2-52-em-12-meses>. Acesso em: 08/11/2018.
DINO. “Empresários adotam PABX em nuvem para diminuir os custos e
aumentar a produtividade”. 2018. Disponível em:
<https://exame.abril.com.br/negocios/dino/empresarios-adotam-pabx-em-nuvem-para-diminuir-os-custos-e-aumentar-a-produtividade/>. Acesso em: 14/11/2018. SILVA, Victor. “Uber libera chamadas VoIP e sugestões personalizadas de trajetos”. 2018. Disponível em: <https://tecnoblog.net/264362/uber-chamada-voip-sugestao-trajeto/>. Acesso em: 10/11/2018.
Intelbras. “Datasheet CIP 92200”. 2018. Disponível em: <http://www.intelbras.com.br/sites/default/files/downloads/datasheet_cip_92200_01-18_impressao.pdf>. Acesso em: 10/11/2018.
Laravel. Disponível em: <https://laravel.com/docs/5.6>. Acesso entre: 10 de Setembro a 10 de Novembro, 2018.
Freepbx. Disponível em: <https://wiki.freepbx.org/display/FPG/FreePBX+13.0>. Acesso entre: 10 de Setembro a 10 de Novembro, 2018.
ReactJS. Disponível em: <https://reactjs.org/docs/getting-started.html>. Acesso entre: 10 de Setembro a 10 de Novembro, 2018.
SALUTES, Bruno. “O telefone fixo está com os dias contados? O presidente da Vivo acha que sim”. 2018. Disponível em: <https://www.androidpit.com.br/o-telefone-fixo-esta-com-os-dias-contados/>. Acesso em: 19/11/2018.
IVO, Pedro. “O que um agente funerário e um telefone tem em comum?”. 2017. Disponível em: <http://www.deviante.com.br/noticias/o-que-um-agente-funerario-e-um-telefone-tem-em-comum/>. Acesso em: 19/11/2018.
PINHEIRO, Paulo Ricardo Guedes. “Ciclos Evolutivos das Telecomunicações”. 2004. Disponível em: <http://www.teleco.com.br/tutoriais/tutorialciclos/default.asp>. Acesso em: 22/11/2018.
BARTSCH, Lucien. “Protocolo SIP: Entenda como funciona uma ligação VoIP”. 2013. Disponível em: <http://blog.sippulse.com/entenda-como-funciona-um-dialogo-sip-protocolo-utilizado-em-ligacoes-voip/>. Acesso em: 22/11/2018.
33 ROCHA, Carlos Gustavo A. da. “Introdução ao VoIP Codecs”. 2013. Disponível em: <http://diatinf.ifrn.edu.br/prof/lib/exe/fetch.php? media=user:1379492:tecnologia_integracao_servicos:8-introduc_ao_ao_voip_-_codecs.pdf>. Acesso em: 22/11/2018.
NETO, Arilo Cláudio Dias. “Bancos de Dados Relacionais”. 2011. Disponível em: <https://www.devmedia.com.br/bancos-de-dados-relacionais/20401>. Acesso em: 27/11/2018.
GORNSTEIN, Marcelo. “PAGI: Quick telephony applications using AGI and
PHP”. 2015. Disponível em:
<http://marcelog.github.io/articles/pagi_tutorial_create_voip_telephony_application_f or_asterisk_with_agi_and_php.html>. Acesso em: 27/11/2018.
DIGIUM. “Asterisk Project Wiki”. 2018. Disponível em: <https://wiki.asterisk.org/wiki/display/AST/Home>. Acesso em: 27/11/2018.
GONÇALVES, Eduardo Corrêa. “JSON Tutorial”. 2012. Disponível em: <https://www.devmedia.com.br/json-tutorial/25275>. Acesso em: 27/11/2018.
RAMOS, Allan. “O que é MVC?”. 2015. Disponível em: <https://tableless.com.br/mvc-afinal-e-o-que/>. Acesso em: 24/11/2018.
BONAFÉ, Douglas. “Uma análise sobre o Docker”. 2015. Disponível em: <https://imasters.com.br/cloud/uma-analise-sobre-o-docker>. Acesso em: 24/11/2018.
LIMA, Matheus. “Enviar O Guia Completo do React e o seu Ecossistema”. 2017. Disponível em: <https://tableless.com.br/guia-completo-react-ecossistema/>. Acesso em: 24/11/2018.
