Embed Size (px)
Citation preview
Centro Universitário Positivo - UNICENP Núcleo de Ciências Exatas e Tecnológicas - NCET
Engenharia da Computação Humberto Vinicius Aparecido de Campos
PBX-IP: GERENCIANDO TECNOLOGIAS DE TELECOMUNICAÇÃO
Curitiba
2007
Centro Universitário Positivo - UNICENP Núcleo de Ciências Exatas e Tecnológicas - NCET
Engenharia da Computação Humberto Vinicius Aparecido de Campos
PBX-IP: GERENCIANDO TECNOLOGIAS DE TELECOMUNICAÇÃO
Monografia apresentada à disciplina de Projeto
Final, como requisito parcial à conclusão do Curso
de Engenharia da Computação. Orientador: Prof.
Alessandro Brawerman.
Curitiba
2007
TERMO DE APROVAÇÃO
Humberto Vinicius Aparecido de Campos
PBX-IP: Gerenciando Tecnologias de Telecomunicação
Monografia aprovada como requisito parcial à conclusão do curso de Engenharia da
Computação do Centro Universitário Positivo, pelos componentes da banca examinadora:
Prof. Alessandro Brawerman (Orientador)
Prof. Edson Pedro Ferlin
Prof. Amarildo Geraldo Reichel
Curitiba, 10 de Dezembro de 2007.
AGRADECIMENTOS
Sobre tudo, agradeço a Deus, que além de me dar a vida pôs no meu caminho as diversas pessoas
que me apoiaram e me apóiam nos momentos mais complexos.
Dentre elas, Maria Filomena de Campos, minha querida mãe, uma mulher de fibra, que me
ensinou os princípios para uma vida justa, solidária e honesta.
Meu pai, Lázaro Francisco de Campos (in memória), que me ensinou que o homem é fruto do
seu esforço e suor, e me foi exemplo de que o trabalho é a maior herança que podemos deixar
aos nossos filhos.
Às minhas sete irmãs Margarida, Ozana, Antonia, Sonia, Lucilene, Lucenir e Eva, que
demonstram que garra e bom caráter não têm sexo. Aos meus irmãos Romeu e Jefferson, que
sempre me instigaram a desbravar o novo. Aos meus sobrinhos, responsáveis pelos diversos
momentos de felicidade.
Aos meus colegas, que além de companheiros mostraram o significado real de cooperativismo,
em especial ao Jeronymo, Ricardo, Eduardo e a Andressa, eternos amigos!
Aos meus professores, que mostraram que o conhecimento é fruto da prática e do esforço
continua.
E a você Joelma, meu amor, a quem dedico minhas obras e meu destino.
RESUMO
Este documento apresenta um sistema para gerenciamento de tecnologias de telecomunicação e
reúne metodologias e estudos realizados para construção de ambientes que integram as formas
mais comuns de telefonia. O projeto foi baseado no software Asterisk, ferramenta integrante da
comunidade Linux, sobre os aspectos de GNU de software livre. O Asterisk é um software que
revolucionou o mundo das telefonias modificando completamente o conceito de PBX-IP. Ele não
somente é uma solução inovadora na integração comunicação de voz, mas é, sobretudo, a
solução completa para as diversas formas (modernas) de se comunicar. O projeto utiliza o
Asterisk para desenvolver uma solução de integração entre telefonias convencionais e VoIP (voz
sobre IP), a fim de gerar rotas de menor custo de chamadas telefônicas. O projeto ainda
apresenta a construção de um módulo de tarifagem que mostra informações de tempo e custo de
tarifa que um ramal gastou.
Palavras-chave: Asterisk, PBX-IP, Telecomunicações, Display, TCP-IP.
ABSTRACT
This document holds information, concerning the academic project developed on
Telecommunication Technology Management, which gathers methodologies and studies
accomplished for the construction of environments which integrates the most common ways of
communication. The project uses at software Asterisk structure result, Linux community
integrated tool, about the aspects of GNU of (loose, free, detached, etc.) software. Asterisk is
software which has revolutionized the world of telephony modifying completely the concept of
PBX-IP. It is not only an innovative solution in the integration if voice communication, but it is,
above all, a complete solution for the many (modern) ways of communicating. The project uses
Asterisk to develop an integrated solution between conventional telephones and VoIP (Voice
under IP), in order to generate routes of lower cost for telephone calls. Besides monitoring,
through a LCD display, the expenses of a PBX-IP caller.
Keywords: Asterisk, PBX-IP, Telecomunicações, Display, TCP-IP.
SUMÁRIO
LISTA DE FIGURAS ................................................................................................................... 8
LISTA DE TABELAS................................................................................................................. 11
LISTA DE ABREVIAÇÕES...................................................................................................... 12
CAPÍTULO 1 - INTRODUÇÃO................................................................................................ 14
CAPÍTULO 2 - FUNDAMENTAÇÃO TEÓRICA.................................................................. 16
2.1 - Contexto literário ............................................................................................................... 16
2.2 - A rede de comutação de circuitos...................................................................................... 17
2.3 - PABX................................................................................................................................. 20
2.3.1 - PABX Tradicional....................................................................................................... 20
2.3.2 - PBX IP ........................................................................................................................ 20
2.4 - Redes de computadores ..................................................................................................... 22
2.4.1 - Tipos de redes ............................................................................................................. 22
2.5 - Internet ............................................................................................................................... 24
2.5.1 - Protocolos da Internet.................................................................................................. 25
2.6 - Protolo IP ........................................................................................................................... 26
2.7 - Protocolo TCP ................................................................................................................... 30
2.8 - A interligação em redes TCP/IP ........................................................................................ 32
2.9 - Protocolo RTP ................................................................................................................... 33
2.10 - Protocolo RTPC............................................................................................................... 36
2.11 - VoIP................................................................................................................................. 36
2.12 - Telefonia IP ..................................................................................................................... 37
2.13 - Protocolo H.323............................................................................................................... 39
2.14 - Asterisk ............................................................................................................................ 41
2.14.1 - Redução de Custo extrema........................................................................................ 42
2.14.2 - Ter controle do Sistema Telefônico .......................................................................... 42
2.14.3 - Ambiente de Desenvolvimento ................................................................................. 43
2.14.4 - Provendo recursos dinâmicos por telefone................................................................ 43
2.14.5 - O mercado para o Asterisk ........................................................................................ 43
2.14.6 - Plano de discagem flexível e poderoso ..................................................................... 43
2.14.7 - Asterisk e a comunidade GNU.................................................................................. 43
2.14.8 - Limitações da arquitetura do Asterisk....................................................................... 43
2.15 - Protocolo SIP ................................................................................................................... 43
2.16 - Bilhetagem e Tarifação.................................................................................................... 44
2.17 - Trabalhos Realizados....................................................................................................... 44
CAPÍTULO 3 - ESPECIFICAÇÃO DO PROJETO ............................................................... 46
3.1 - Software............................................................................................................................. 47
3.1.1 - Asterisk ....................................................................................................................... 49
3.1.2 - Canais .......................................................................................................................... 50
3.1.3 - Ramais......................................................................................................................... 51
3.1.4 - Modulo CDR............................................................................................................... 51
3.1.5 - Tarifagem com MySQL .............................................................................................. 51
3.1.6 - Extensions.conf ........................................................................................................... 52
3.1.7 - Interface WEB............................................................................................................. 53
3.2 - Hardware ........................................................................................................................... 54
3.2.1 - Módulo de controle ..................................................................................................... 55
3.2.2 - Módulo de conversão Ethernet/Serial ......................................................................... 58
3.2.3 - Display LCD ............................................................................................................... 60
3.3 - Custos do Projeto............................................................................................................... 61
3.4 - Cronograma ....................................................................................................................... 62
CAPÍTULO 4 - DESENVOLVIMENTO E IMPLEMENTAÇÃO ........................................ 63
4.1 - Lógica ................................................................................................................................ 63
4.1.1 - Diagrama de contexto.................................................................................................. 63
4.1.2 - - Diagrama de fluxo de chamadas ............................................................................... 64
4.2 - Software............................................................................................................................. 65
4.2.1 - Configuração do Asterisk............................................................................................ 65
4.2.2 - Gera_rotas ................................................................................................................... 67
4.2.3 - Estrutura de Banco de Dados ...................................................................................... 73
4.2.4 - Interface WEB para manipulação do usuário.............................................................. 73
4.3 - Hardware ........................................................................................................................... 74
4.3.1 - Coletagem e envio das informações............................................................................ 75
4.3.2 - Módulo de Conversão Ethernet/Serial ........................................................................ 77
4.3.3 - Módulo de controle e display...................................................................................... 77
4.4 - Firmwares .......................................................................................................................... 79
CAPÍTULO 5 - VALIDAÇÃO E RESULTADOS................................................................... 81
CAPÍTULO 6 - CONCLUSÃO.................................................................................................. 84
CAPÍTULO 7 - BIBLIOGRAFIA ............................................................................................. 87
APÊNDICE A .............................................................................................................................. 89
APENDICE B .............................................................................................................................. 90
LISTA DE FIGURAS
FIGURA 1 – CLIENTE SERVIDOR ...........................................................................................16
FIGURA 2 – ESTRUTURA DE COMUNICAÇÃO DE DADOS...............................................17
FIGURA 3 - TECNOLOGIA ANALÓGICA ...............................................................................18
FIGURA 4 – MULTIPLEXAÇÃO POR DIVISÃO DE TEMPO................................................19
FIGURA 5 – MULTIPLEXAÇÃO POR DIVISÃO DE TEMPO................................................19
FIGURA 6 - ARQUITETURA DE UM PABX IP .......................................................................21
FIGURA 7 – EXEMPLO DE UMA REDE PONTO-A-PONTO,................................................23
FIGURA 8 – CLIENTE/SERVIDOR ...........................................................................................23
FIGURA 9 – PILHA DE PROTOCOLOS....................................................................................25
FIGURA 10 - CABEÇALHO DO IPV4 .......................................................................................26
FIGURA 11 - CABEÇALHO DO IPV6 .......................................................................................28
FIGURA 12 - CABEÇALHO TCP...............................................................................................31
FIGURA 13 - POSIÇÃO DO RTP NA PILHA DE PROTOCOLOS. .........................................34
FIGURA 14 – CABEÇALHO DO RTP .......................................................................................34
FIGURA 15 – TRAFEGO RTP NÃO CRESCE COM O NÚMERO DE PARTICIPANTES ....36
FIGURA 16 – TELEFONIA IP PC/PC.........................................................................................38
FIGURA 17 - TELEFONIA IP COM USO DE GATEWAY ......................................................39
FIGURA 18 - TELEFONIA IP TELEFONE/TELEFONE...........................................................39
FIGURA 19 - PROCESSO GENÉRICO DE ESTABELECIMENTO DE CHAMADAS ..........40
FIGURA 20 - SINALIZAÇÃO GENÉRICA DO SIP ..................................................................44
FIGURA 21 – TOPOLOGIA DA REDE LAN.............................................................................46
FIGURA 22 – ESTRUTRA DE RELACIONAMENTO DO SISTEMA COM O MÓDULO DE
CONTROLE..................................................................................................................................48
FIGURA 23 - EXTENSÕES PARA EXECUÇÃO DE QUERYS NO ASTERISK ....................51
FIGURA 24 – ESTRUTURA DA TABELA CDR.......................................................................52
FIGURA 25 – EXEMPLO DE EXTENSÕES DO EXTENSIONS.CONF..................................53
FIGURA 26 - SINTAXE EXTENSION .......................................................................................53
FIGURA 27 - FLUXO DO HARDWARE ...................................................................................54
FIGURA 28 – ESQUEMÁTICO DO MÓDULO DE CONTROLE ............................................56
FIGURA 29 – SIMULAÇÃO DAS INFORMAÇÕES DO DISPLAY........................................60
FIGURA 30 – DIAGRAMA DE CONTEXTO ............................................................................64
FIGURA 31 – FLUXOGRAMA DE CHAMADAS EFETUADAS ............................................65
FIGURA 32 – DIAGRAMA DA ESTRUTURA – ASTERISK NO PROJETO..........................66
FIGURA 33 – TRECHO DA CONFIGURAÇÃO DO EXTENSIONS.CONF ...........................67
FIGURA 34 – FLUXOGRAMA DE GERAÇÃO DAS EXTENSÕES DE MENOR CUSTO ...68
FIGURA 35 – CLÁUSULA SQL PARA IMPORTAÇÃO PARA TABELA ALL_RATES ......70
FIGURA 36 – CLÁUSULA SQL PARA ORDENAÇÃO DA TABELA ALL_RATES ............70
FIGURA 37 – FLUXOGRAMA COMPLETO DO PROGRAMA GERA_ROTAS...................71
FIGURA 38 –PARÂMETROS PARA CRIAÇÃO DO ARQUIVO ROTAS.TXT .....................72
FIGURA 39 – DIAGRAMA DE RELACIONAMENTO DA BD COM AS APLICAÇÕES .....73
FIGURA 40 – DIAGRAMA DE CASO DE USO PARA CADASTRO DE RAMAL................74
FIGURA 41 – DIAGRAMA DE CASO DE USO PARA CADASTRAMENTO TRONCOS....74
FIGURA 42-MÓDULO TARIFADOR ........................................................................................75
FIGURA 43 – RELACIONAMENTO ENTRE AS PARTES DO SOFTWARE ........................75
FIGURA 44 – TELA PARA AUTERAÇÃO DOS PARÂMETROS DO MÓDULO .................77
FIGURA 45 – ESQUEMÁTICO DA PLACA DO MÓDULO DE CONTROLE .......................78
FIGURA 46 – ESQUEMA ELÉTRICO DO MÓDULO DE CONTROLE E DISPLAY............78
FIGURA 47 – TRECHO DO FIRMWARE..................................................................................80
LISTA DE TABELAS
TABELA 1 – ESPECIFICAÇÃO TÉCNICA DO TIBBO EM202-EV .......................................58
TABELA 2 – PINAGEM DO LCD ..............................................................................................60
TABELA 3 – GASTOS COM PROJETO ....................................................................................61
TABELA 4 – CRONOGRAMA DE ATIVIDADES....................................................................62
TABELA 5 –ESTRUTURA DE DIRETÓRIOS DO ASTERISK................................................66
TABELA 6 – PARTE DO CONTEÚDO DO ARQUIVO E TABELA ALL_RATES................69
TABELA 7 – CENÁRIO DE TESTES REALIZADOS PARA VALIDAÇÃO DO PROJETO .81
TABELA 8 – RESULTADOS DA VALIDAÇÃO DAS ROTAS DE MENOR CUSTO............81
TABELA 9 – RESULTADOS DOS TESTES DE VALIDAÇÃO DO MÓDULO DE
CONTROLE..................................................................................................................................82
LISTA DE ABREVIAÇÕES
ACD – Automatic Call Delivery (Entrega Automática de Chamadas).
API - Application Programming Interface (Interface de Programação de Aplicativos).
CDR - Call Detail Records (Gravação de Detalhes de Chamadas).
DNS – Domain Name System (Sistema de Resolução de Nomes).
DSP – Digital Signal Processor (Processador de Sinal Digital).
FTP – File Transfer Protocol (Protocolo de Transferência de Arquivos).
FXO - Foreign eXchange Office (Interface de conexão com operadora).
FXS - Foreign eXchange Subscriber (Interface de conexão com a linha do assinante).
GNU – Gnu is Not Unix. (GNU não é Unix)
GPL – General Public License (Licença Pública Geral).
IAX – Inter-Asterisk eXchange (Interface Asterisk de Troca).
IP – Internet Protocol (Protocolo de Internet).
IVR – Interactive Voice Response (Resposta Interativa de Voz).
LAN - Local Area Network (Rede Local).
LCD - Liquid Crystal Display (Display de Cristal Líquido)
PABX – Private Automatic Branch Exchange (Troca Automática de Ramais).
PBX - Private Branch Exchange (Troca de Ramais).
PCI - Peripheral Component Interconnect (Interconector de Componentes Periféricos)
POTS – Plain Old Telephony System (Sistema de Telefonia Convencional).
RTP - Real Time Transport Protocol (Protocolo de Transporte em Tempo Real).
RTPC – Rede Pública de Telefonia Comutada.
SIP - Session Initiation Protocol (Protocolo de Inicialização de Sessão).
SMTP – Simple Mail Transfer Protocol (Protocolo de Transferência Simples de
Correspondência).
STFC – Sistema de Telefonia Fixa Comutada.
TCP – Transmission Control Protocol (Protocolo de Controle de Transmissão).
TDM – Time Division Multiplexing (Multiplexação por Divisão de Tempo).
TFTP - Trivial File Transfer Protocol (Protocolo de Transferência de Arquivos Triviais).
UDP – User Datagram Protocol (Protocolo de Datagrama de Usuário).
VoIP – Voz sobre IP.
14
CAPÍTULO 1 - INTRODUÇÃO
A Telecomunicação é o segmento que integra as diversas tecnologias desenvolvidas para
interligar as pessoas ao redor do mundo.
Partindo desse objetivo, as indústrias do segmento lançam constantemente novidades no
mercado.
No entanto, a falta de informação (dentre outros motivos) ocasiona a restrição de uma parcela de
usuários na utilização de tecnologias que podem agregar soluções de redução de custos.
Em virtude disso ainda é de grande escala a utilização a Rede Pública de Telefonia Comutada
(RTPC – serviço de telefonia analógica convencional), que oferece poucas vantagens e soluções
ao usuário que viabilizem a redução de tarifas telefônicas.
Outro fato é a utilização de centrais de PABX convencionais (Private Automatic Branch
Exchange - Troca Automática de Ramais), principalmente em empresas de médio e grande porte.
Apesar de terem surgido há mais de 20 anos como uma grande facilitadora das comunicações no
mundo corporativo, atualmente as centrais PABX de grande porte são de alto custo e necessitam
de técnicos especializados para realização de manutenções. Por outro lado as centrais de pequeno
porte não oferecem todos os recursos necessários para integrar os serviços de telecomunicações.
Com a Internet novos serviços de telecomunicações foram desenvolvidos com o intuito de
acelerar a velocidade da informação e viabilizar os custos.
Uma das tecnologias desenvolvidas a partir da Internet foi o VoIP (voz sobre IP – Internet
Protocol), que digitaliza, codifica, empacota e envia dados de voz em datagramas IP (protocolo
de envio de pacotes de dados) em uma rede que utiliza a pilha de protocolos TCP/IP. Dessa
forma essa tecnologia consegue unificar em uma única rede de serviços a transmissão de voz e
de dados.
A partir da tecnologia VoIP especialistas do segmento de telecomunicações criaram o conceito
de Telefonia IP, que agrega além do VoIP outras soluções em telecomunicações. Com este
conceito novos sistemas foram desenvolvidos para o gerenciamento de telecomunicações, dentre
eles o Asterisk.
15
O Asterisk é considerado a peça de integração de telecomunicações mais potente, flexível e
extensível disponível atualmente no mercado. Ele é um software livre de código fonte aberto e
gratuito, que possui as funcionalidades de uma central PBX-IP (Private Branch Exchange -
Troca de Ramais) e é reconhecido pela comunidade GNU como solução Linux para Telefonia-
IP.
Acompanhando a crescente utilização da Telefonia-IP e também com o intuito de combater
tarifas abusivas praticadas no mercado.
Este projeto defende a implantação de um sistema que contraponha a utilização de centrais
PABX de alto custo e limitadas, ao mesmo tempo em que proporcione ao usuário a redução e o
controle dos custos de telefonia sem a necessidade de grandes recursos financeiros, prezando
pela alta qualidade dos serviços ofertados.
No desenvolvimento do sistema foram utilizados os seguintes componentes: o Asterisk, rotas
telefônicas de menor custo, dispositivo tarifador e interfaces WEB para manutenção da central
PBX-IP.
Com a utilização da arquitetura disponível no sistema Asterisk, é possível criar um sistema
híbrido de telefonia que garante as funcionalidades existentes nas telefonias convencionais e IP.
As Rotas de Menor Custo são geradas, a partir de tabelas que contém tarifas praticadas por
operadoras telefônicas convencionais e VoIP. Dessa forma o sistema reconhece e separa
automaticamente as rotas de menor custo agrupando-as ao plano de discagem do Asterisk,
utilizando como critério o valor das tarifas.
O Módulo Tarifador é um hardware que tem a finalidade de coletar a duração e o custo de uma
ligação realizada em um ramal (cada ramal possui um módulo). Ele é composto, dentre outros
componentes, de um display LCD que mostra ao usuário, ao término de cada ligação efetuada, as
informações coletadas.
A interface WEB desenvolvida tem a função de minimizar os esforços para manutenção da
central PBX-IP, pois, o Asterisk, por ser um software desenvolvido para o sistema operacional
Linux, possui um o ambiente de manutenção não amigável à maioria dos usuários.
O projeto desenvolvido além de proporcionar novos serviços com qualidade em relação à
telefonia atual, tem como grande atrativo a redução de custos com tarifas telefônicas.
16
CAPÍTULO 2 - FUNDAMENTAÇÃO TEÓRICA
O projeto foi desenvolvido mediante pesquisas voltadas para telecomunicações, telefonia
analógica e digital, telefonia IP (Internet Protocol), redes de computadores, protocolos de redes e
de telefonia, sockets, centrais PABX (Private Automatic Branch Exchange), banco de dados,
programação em linguagens C e Java Script, sistema operacional Linux, software de
gerenciamento e controle de telefonia Asterisk, microcontroladores, programação de
microcontroladores, funcionamento de display LCD, comunicação serial, conversão
serial/ethernet.
A pesquisa foi realizada em livros, manuais, artigos, periódicos, e Internet que formaram a base
técnico-científica deste projeto.
2.1 -Contexto literário
Nos dias atuais é quase inconcebível praticar uma atividade sem que esteja de alguma forma
vinculada às redes de computadores. A constate evolução e os vários estudos e teses sobre redes,
foram motivados por diversas necessidades. Uma delas foi a segurança das informações.
Pois, o fato de um determinado arquivo ou banco de dados pode ser armazenada de forma
distribuída em locais remotos, o que garante uma maior segurança na preservação das
informações (TORRES, 2001).
FIGURA 1 – CLIENTE SERVIDOR
A Figura 1 mostra o fluxo de informações da rede Cliente/Servidor. A vantagem dessa topologia
reside na concentração de serviços em apenas uma máquina. A partir desta, os serviços podem
ser distribuídos para as demais estações (DANTAS, 2002).
17
Existem, ainda, diversas outras topologias de rede, dentre as quais as: ponto-a-ponto, estrela e
anel.
Apesar das diversidades, prós e contras, todas tem a mesma característica: distribuição de
recursos e informações para todos que estejam interligados (DANTAS, 2002).
FIGURA 2 – ESTRUTURA DE COMUNICAÇÃO DE DADOS
A Figura 2 mostra como é a estrutura primária de comunicação de dados em redes. Apesar da
grande evolução, os princípios dos sistemas de comunicação de dados são basicamente
representados por cinco componentes: fonte da informação, que é a responsável pela produção
dos dados a serem transmitidos; transmissor que é o responsável em converter os dados a serem
transmitidos em um sinal apropriado; a rede de transmissão que corresponde ao meio físico no
qual a informação irá trafegar; receptor, que é o responsável em converter a informação recebida
em uma forma inteligível ao destinatário que é o elemento no qual foi destinada a informação
transmitida (DANTAS, 2002).
2.2 -A rede de comutação de circuitos
Redes de comutação de circuitos correspondem às telefonias convencionais analógicas e digitais.
Atualmente, a mais utilizada em residências, empresas e diversos setores sociais é a telefonia
analógica por deter a maior malha de cabeamento em quase todo mundo (HERSENT, GUIDE e
PETIT, 2002).
18
FIGURA 3 - TECNOLOGIA ANALÓGICA
A Figura 3 mostra de forma simplificada o funcionamento de ligações por meio de tecnologias
analógicas. As extremidades se comunicam por cabos que transmitem os sinais modulados em
pacotes de voz.
“Apesar de ser uma tecnologia muito antiga, a transmissão analógica
tem muitas vantagens: ela é simples e mantém o atraso de fim a fim de
transmissão de voz muito baixo, uma vez que o sinal se propaga ao longo
do cabo quase na velocidade da luz. Também é barata quando há
relativamente poucos usuários falando ao mesmo tempo, e quando eles
não estão muito distantes entre si. Entretanto, a tecnologia analógica
mais básica requer um par de cabos por conversão ativa, o que se torna
rapidamente impraticável e caro” (HERSENT, GUIDE e PETIT, 2002).
O recurso utilizado pela tecnologia analógica é baseado na multiplexação dos sinais em
diferentes freqüências compartilhando o mesmo cabo. Este recurso não impede a transmissão de
ruídos, uma vez que os mecanismos e componentes geram interferências eletromagnéticas.
Aos poucos a tecnologia analógica está sendo substituída pela digital. Atualmente, em muitos
países a tecnologia é inteiramente digital, e em outras localidades a linha é analógica, mas o
serviço é digital (HERSENT, GUIDE e PETIT, 2002).
19
FIGURA 4 – MULTIPLEXAÇÃO POR DIVISÃO DE TEMPO
Assim, vários canais de voz podem ser multiplexados na mesma linha de transmissão, usando
uma tecnologia chamada multiplexação por divisão no tempo (Time Division Multiplexing –
TDM). Nessa tecnologia, o fluxo dos dados digitais são divididos em blocos (geralmente um
octeto, também chamado de amostra). Os blocos dos vários canais de voz que foram previamente
multiplexados, são intercalados em intervalos de tempo na linha de transmissão, como pode ser
visto na Figura 4 (HERSENT, GUIDE e PETIT, 2002).
Com essa tecnologia digital, o ruído adicionado na transmissão não influencia a qualidade da
comunicação, uma vez que os sinais digitais podem ser recuperados. Além disso, a
multiplexação digital por divisão de tempo torna possível a comutação digital. O equipamento de
comutação precisa copiar o conteúdo das diversas linhas de transmissão para uma única linha
dentro de um canal. As informações são ordenadas de acordo com o intervalo de tempo
originalmente indicado pelas linhas, conforme mostra a Figura 4. Com base nesse princípio, a
comutação pode ser executada por um computador (PETIT, 2002).
FIGURA 5 – MULTIPLEXAÇÃO POR DIVISÃO DE TEMPO
A Figura 5 mostra a multiplexação por divisão de tempo (TDM) trabalhando com circuitos
eletrônicos e sinais digitais. Como as centrais locais trabalham com sinais analógicos, estes
sinais passam por codecs (codificador-decoficador) que produzem 8.000 amostras de séries de
números de 8 bits por segundo o necessário e suficiente para captar as informações de um canal
de banda de voz (4 KHz).
20
Estas 8.000 amostras por segundo equivalem a 125 microssegundos por amostra, e em
conseqüência, todos os intervalos são múltiplos de 125 microssegundos (PETIT, 2002).
2.3 -PABX
Um PABX (Private Automatic Branch Exchange) é uma central de distribuição telefônica. Ele
permite efetuar ligações internas entre ramais sem intervenção manual e, também, receber e
efetuar telefonemas externos. Outra funcionalidade atribuída ao equipamento é controlar o
acesso individual de usuários.
As centrais PABX são formadas por plataformas de hardwares e softwares, nas centrais mais
atuais os softwares são utilizados, dentre outras funções, para a interação com a telefonia IP
(SPENCER, RHODES, 2003).
2.3.1 -PABX Tradicional
Em meados dos anos 80, quando os PABXs tradicionais foram desenvolvidos, tanto os
computadores quanto os microprocessadores eram limitados e com custo elevado, a rede de
dados desconhecida e formada pela comutação de circuitos (SATO, 2004).
O PABX tradicional utiliza tecnologia proprietária e os usuários ficam sempre limitados ao
mesmo fabricante para adicionar outras funcionalidades. Quaisquer modificações na
programação ou conserto, normalmente dependem de técnicos especializados, o que onera o
custo de manutenção e operação.
2.3.2 -PBX IP
As centrais PBX-IP (Private Branch Exchange) interligam a telefonia convencional com os
serviços disponibilizados pela telefonia IP. Este aspecto diferencia estas centrais das centrais
PABX tradicionais.
Após 15 de estabilidade, fabricantes e vendedores de PABXs estão introduzindo no mercado um
novo conceito de telefonia, que por meio da arquitetura VoIP, possiblita a utilização de infra-
estruturas de redes TCP/IP que agrega outros serviços com qualidade, segurança e flexibilidade
(SATO, 2004).
21
Telefone Analógico
Telefone Digital
Módulo Módulo de Interconexão
Controlador de processo
Telefone Digital
Gateway
Internet
RTPC
Ramal
FIGURA 6 - ARQUITETURA DE UM PABX IP
Esta nova tecnologia está redefinindo a arquitetura de um PABX. Muitos dos componentes são
distribuídos ao longo da rede IP para transmitir informações de voz e controle da ligação, a
arquitetura é mostrada e esquematizada na Figura 6 (SATO, 2004).
1. Controlador de processo: servidor que executa uma aplicação num sistema operacional
padrão (Microsoft, Unix ou Linux). Existe um grande benefício em se utilizar um hardware e
software comercial, permitindo uma grande redução nos custos de desenvolvimento e
fabricação (SATO, 2004);
2. Os dispositivos de ponta (endpoints): são os telefones IPs que conectam-se diretamente na
Internet ao invés de interligar nos cartões de interfaces dedicadas dos módulos. Esses
equipamentos necessitam de um endereço IP e podem ser atualizados (firmware) por meio de
um servidor TFTP com novas funcionalidades. Diferente do PABX tradicional, dois
telefones IPs conversam diretamente, sem utilizar recursos do servidor (SATO, 2004);
3. Gateway: são interfaces ou equipamentos que convertem a sinalização e o canal de voz para
a rede IP, fazendo a integração com a rede STFC e para permitir utilizar os telefones
analógicos ou digitais existentes, reduzindo os custos da migração para a nova arquitetura
(SATO, 2004);
4. Módulos de interconexão: é realizado em redes IP e ocasiona em uma degradação na
qualidade da voz, se acontecer algum congestionamento ao longo do trajeto dos dados,
normalmente no link WAN (SATO, 2004);
22
5. Mobilidade de ramais: é possível que uma central telefônica esteja num estado e o telefone
em outro estado, por meio de recurso citado acima é possível ter ramais remotos em uma
PABX (SATO, 2004).
2.4 -Redes de computadores
As redes de computadores surgiram da necessidade de troca de informação. Com elas é possível
ter acesso a informações em locais remotos. As redes existem desde a época dos primeiros
computadores, antes mesmo dos primeiros computadores pessoais (PC).
Entretanto, novas padronizações e tecnologias permitiram que comutadores pudessem se
comunicar melhor por um custo menor (TORRES, 2001).
As redes de computadores têm crescido explosivamente. Há duas décadas, poucas pessoas
tinham acesso a uma rede. Agora, a comunicação via computador transformou-se em uma parte
essencial de qualquer infra-estrutura (COMER, 2001).
2.4.1 -Tipos de redes
Existem dois tipos basicos de uma rede compartilhar os dados : ponto-a-ponto e cliente/servidor.
O primeiro tipo é usado em redes pequenas, enquanto o segundo tipo é largamente usado tanto
em redes pequenas quanto em redes grandes.
Essa classificação independe da estrutura física usada pela rede, isto é, como a rede está
fisicamente montada, mas depende da maneira com que ela está configurada por meio de
softwares (TORRES, 2001).
− Redes Ponto-a-ponto: esse é o tipo mais simples de rede que pode ser montada. Praticamente
todos os sistemas operacionais já vêm com suporte à rede ponto-a-ponto (TORRES, 2001).
23
FIGURA 7 – EXEMPLO DE UMA REDE PONTO-A-PONTO,
Na rede ponto-a-ponto, exemplificada na Figura 7, os micros compartilham dados e periféricos
sem muita “burocracia”. Qualquer micro pode facilmente ler e escrever arquivos armazenados
em outros micros da rede bem como usar periféricos que estejam instalados em outros PC’s.
Obviamente, tudo isso depende da configuração que é feita em cada micro individualmente, ou
seja, não há o papel de um micro “servidor” como nas redes cliente/servidor, qualquer um dos
micros da rede pode ser um servidor de dados e periféricos (TORRES, 2001).
− Redes Cliente/Servidor: esta arquitetura normalmente é usada para redes com mais de 10
micro-computadores ou no caso de redes pequenas, nas quais a segurança seja uma questão
importante (TORRES, 2001).
FIGURA 8 – CLIENTE/SERVIDOR
Nesse tipo de rede, ilustrada na Figura 8, há um servidor que gera recursos para os demais
clientes da rede. Com uma máquina dedicada a uma tarefa consegue-se ter uma resposta rápida
aos pedidos dos demais micros da rede, não comprometendo ao desempenho do serviço
(TORRES, 2001).
24
Existem soluções para servidores no mercado onde computadores são substituídos por aparelhos
desenvolvidos exclusivamente para uma atividade específica (TORRES, 2001).
Existem soluções para servidores no mercado onde computadores são substituídos por aparelhos
desenvolvidos exclusivamente para uma atividade específica (TORRES, 2001).
Nas redes cliente/servidor, a administração e configuração da rede são centralizadas, o que
melhora a organização e segurança da rede. Além disso, há possibilidade de serem executados
programas cliente/servidor, com um banco de dados que pode ser manipulado por diversos
usuários ao mesmo tempo.
2.5 -Internet
A Internet pode ser definida como um conjunto de redes diferentes que utilizam certos
protocolos comuns e fornecem determindados serviços comuns (TANENBAUM, 2003).
A Internet teve sua origem a partir da ARPANET, que era a rede de computadores desenvolvida
pelo Departamento de Defesa dos Estados Unidos. Logo após o surgimento da ARPANET
surgiu a NSFNET com o objetivo de ser sua sucessora, já que para fazer parte da ARPANET
necessitava-se um contrato com o Departamento de Defesa dos Estados Unidos, o que inibia a
participação de outros centros de pesquisa no projeto (TANENBAUM, 2003).
A partir do momento em que a pilha de protocolos TCP/IP tornou-se o protocolo oficial da
ARPANET e ocorreu sua conexão com a NSFNET, o número de usuários e máquinas
conectados a rede cresceu de forma exponencial. Muitas redes regionais passaram a ser
integradas, foram criadas conexões com redes no Canadá, Europa e no Pacífico. Apesar de não
ter havido nenhuma data específica de surgimento da Internet, foi em meados dos anos 80 que
conjuntos de redes começam a ser tratados como inter redes, e mais tarde como Internet.
Os elementos básicos que formaram a Internet foram o modelo de referência TCP/IP e a pilha de
protocolos TCP/IP, elementos estes que permitiram que diferentes redes com diferentes
tecnologias pudessem se comunicar. Pode-se definir, segundo Tanenbaum, que uma máquina
está na Internet quando executa a pilha de protocolos TCP/IP, tem um endereço IP e pode enviar
pacotes IP a todas as outras máquinas da Internet (TANENBAUM, 2003).
25
2.5.1 -Protocolos da Internet
“Protocolo pode ser definido como um conjunto de regras que controla
o formato e o significado dos pacotes ou mensagens trocadas por
entidades.” (TANENBAUM, 2003)
A arquitetura nas redes de computadores consiste na existência de diversas camadas e cada
camada possui um protocolo.
Figura 10 mostra uma pilha de protocolos que compõe um pacote de informações trafegados
pela Internet, uma interface e prestando um serviço a uma camada logo acima. Os protocolos que
caracterizam a Internet são: IP, TCP e UDP.
FIGURA 9 – PILHA DE PROTOCOLOS
A Figura 9 representa um dos vários estilos de representação de pilhas de protocolos. Na
primeira linha, ou primeira camada, aparecem os protocolos para aplicativos que utilizam os
recursos de rede para efetuar comunicação (Telnet, FTP, SMTP, DNS) (TANENBAUM, 2003).
Na segunda camada aparecem os protocolos de transporte, TCP e UDP, que de um modo bem
abrangente enviam o pacote de dados sem obter o retorno do destino sobre o recebimento.
Esta camada é executada na terceira camada, ainda por um protocolo, porém, agora, pelo IP,
protocolo que monitora o caminho do transporte, indicando se há conectividade e se o destino
recebeu as informações enviadas. Este recurso reduz a perda de pacotes e dificulta o envio para
destinos errados.
A última camada, representada na Figura 9, é meio de transporte, o caminho físico pelo qual
trafega os dados dos protocolos. O mais popular e comumente usual é a ethernet, utilizado na
grande maioria das redes locais (TANENBAUM, 2003).
26
2.6 -Protolo IP
O IP (Internet Protocol) é o protocolo que mantem a Internet unida. Sua principal tarefa é
transportar datagramas da origem para o destino independente da localização das máquinas,
podendo elas estarem na mesma rede ou em redes diferentes (TANENBAUM, 2003).
Um datagrama IP é composto por um cabeçalho e uma parte de dados, tendo o cabeçalho uma
parte de tamanho fixo de 20 bytes e uma parte opcional de tamanho variável. Atualmente, o
datagrama IP mais utilizado é o IPv4, no entanto, devido ao aumento de hosts conectados a
Internet, a tendência para um futuro breve é a utilização predominante do IPv6, que é uma versão
que mantém os recursos do IP, simplifica o cabeçalho permitindo uma maior rapidez no
processamento, aumenta significantemente o número de endereços e descarta ou reduz
características ruins da versão anterior (TORRES, 2001).
FIGURA 10 - CABEÇALHO DO IPV4
O cabeçalho de um datagrama IPv4 é composto por 13 campos é representado na Figura 10 e
explicado a seguir (SMETANA, 2005):
− Version: campo que dá o nome ao protocolo, pois corresponde a sua versão, 4.
− Length: corresponde ao comprimento do datagrama, limita o tamanho das palavras até 32-
bits.
− Type of service: Contém 5 subcampos que específica à procedência, o delay, a forma de
transporte, a conectividade e o custo desejado pelo pacote (na internet não há garantias desse
recurso).
27
− Total Length: comprimento total de todo o datagrama, o tamanho máximo do pacote
transportado.
− Identification: 16 bits. Número de identificação do datagrama para permitir que o destino
remonte os datagramas.
− Flags: 3 bits. Bits que identificam a transmissão de sinais de controle.
− Fragment offset: Esse campo indica a posição desse fragmento em relação ao do datagrama
original. O valor desse campo é expresso em unidades de 8 octetos (64 bits), portanto o
tamanho mínimo do campo de dados de um fragmento é de 64 bits. O primeiro fragmento
tem valor 0 nesse campo.
− Time to live: 13 bits. 8 bits. Indica o tempo máximo que o datagrama pode permanecer na
rede. Se o valor nesse campo for 0, o datagrama deve ser destruído. A intenção desse campo
é não permitir que datagramas cujo destino seja inalcançável fiquem eternamente circulando
pela rede. Inicialmente, a duração do TTL é era em fração de segundos, mas como cada
unidade processadora de datagramas (roteadores, switches de camada 3, etc.) deve diminuir o
TTL de uma unidade e o tempo de processamento de pacotes é muito inferior a 1 s, o TTL
passa a ser somente um limite superior da existência de cada datagrama.
− Protocol: 8 bits. Indica o protocolo da camada superior que está utilizando os serviços da
camada IP. Esses valores estão definidos no RFC 790 – Assigned Network Numbers
(Números de Redes Designados) de 1981. Esse RFC foi substituído pelo RFC 1700 –
Assigned Numbers. O número do TCP, por exemplo, é 6. Quando o IP estiver encapsulado
em outra camada IP, como em uma Virtual Private Network, por exemplo, o valor desse
campo é 4.x
− Header checksum: 16 bits. Esse checksum é calculado somente sobre o cabeçalho IP. Como
alguns campos mudam freqüentemente, como o TTL, esse valor tem que ser recalculado.
Para se calcular esse checksum, faz-se o complemento de um de cada palavra de 16 bits do
cabeçalho, soma-se elas e faz-se o complemento de um da soma total (para feitos de cálculo,
o campo Header Checksum vale 0). Embora esse algoritmo seja simples, ele é suficiente e
seguro para a maioria das situações. Pode ser que ele seja substituído por um algoritmo do
tipo CRC.
− Source address: 32 bits. Informa o endereço de origem.
28
− Destination address: 32 bits. Informa o endereço de destino. Essa informação é utilizada
pelos roteadores para o encaminhamento (roteamento) do datagrama. Alguns equipamentos
podem utilizar os campos IP de origem, de destino e até mesmo informações de protocolos
de níveis superiores e o tipo de dado sendo transmitido para realizar o roteamento de pacotes
e juntamente realizar algum tipo de priorização ou QoS.
− Options: Tamanho variávgfel, entre 0 e 320 bits (40 octetos). O que é opcional é a
transmissão desse campo, não sua implantação. Todos os roteadores e gateways devem
utilizar meios de codificação/decodificação desse campo. Pode haver mais de uma opção
nesse campo. As opções servem, entre outras coisas, informar se o próprio campo option
deve ou não ser copiado para os fragmentos, caso o pacote venha a ser fragmentado, para
embutir um timestamp da rede, adicionar informações relativas ao nível de segurança do
pacote (confidencialidade) ou para especificar uma rota para um determinado destino. Mais
informações sobre esse campo pode ser encontrado no RFC 791.
− Padding: Tamanho variável, entre 0 e 31 bits. O campo Padding serve apenas para que o
cabeçalho IP tenha um tamanho múltiplo de 32 bits. Só se faz o enchimento
(obrigatoriamente com 0), se o tamanho do campo Option não for múltiplo de 32 bits.
FIGURA 11 - CABEÇALHO DO IPV6
O cabeçalho de um datagrama IPv6 é representado na Figura 11, é composto por 8 campos e
diferente do IPv4 com um tamanho fixo de 40 bytes (SMETANA, 2005).
− Version (Versão): 4 bits. Para essa versão, o valor é 6.
− Traffic Class (Classe de Tráfego): 8 bits. Esse campo ainda é experimental e pode vir a ser
modificado. Na primeira especificação do IPv6, RFC 1883, esse campo não existia. Em seu
lugar havia um campo de 4 bits chamado Priority (Prioridade). A função desse campo é
29
permitir diferenciação de tráfego (classes de tráfego) e mecanismos de prioridade, para que
os roteadores possam prover tratamento apropriado em cada caso.
− Flow Label (Identificação do Fluxo): 20 bits. Um flow é uma seqüência de pacotes enviados
a partir de uma determinada origem, para um determinado destino (unicast ou multicast),
requerendo um tratamento especial pelos roteadores, como QoS ou reserva de banda (RSVP
– Resource Reservation Protocol), por exemplo. O campo Flow Label ainda é experimental e
pode vir a ser modificado, como já ocorreu desde a primeira especificação do IPv6, onde ele
possuía 24 bits. As mudanças dependem da identificação das características que forem
surgindo do tráfego na Internet. A intenção do Flow Label é permitir que a origem possa
atribuir uma identificação (padronizada) aos pacotes, para que eles recebam tratamento
especial por um roteador (fazer QoS, tráfego de tempo real, etc.). Roteadores e hosts que não
são capazes de identificar o Flow Label de um pacote devem deixar o campo com valor igual
a 0, quando originá-lo, deixá-lo inalterado, quando retransmiti-lo, ou ignorá-lo, quando
recebê-lo.
− Payload Length (Comprimento da Carga): 16 bits. Informa o comprimento dos dados, em
octetos, encapsulados pela camada de rede, isto é quantos bytes vêm depois do cabeçalho
IPv6 (os campos de extensão são contabilizados). Caso esse campo seja 0, indica que o
comprimento do payload é superior a 65.535 octetos e é informado em um Extension
Header.
− Next Header (Próximo Cabeçalho): 8 bits. Informa qual o protocolo da camada superior que
está utilizando os serviços da camada IP. A numeração também segue o RFC 1700. O UDP,
por exemplo, é número 17. No IPv6, pode haver um campo opcional após o cabeçalho. Nesse
caso, o valor de Next Header informa qual o tipo de extensão que vem após o cabeçalho
IPv6.
− Hop Limit (Limite de Hop): 8 bits. Semelhante ao TTL do IPv4, cada unidade processadora
de pacotes (nó) subtraí o valor de uma unidade e quando esse valor chegar a 0, o pacote é
descartado.
− Source Address (Endereço de Origem): 128 bits. Informa o endereço de origem do pacote.
− Destination Address (Endereço de Destino): 128 bits. Informa o endereço de destino. O
endereço de destino pode não ser o endereço do hosts final, porque pode ser um cabeçalho de
roteamento.
30
− Extension Header (Cabeçalho de Extensão): Tamanho variável, mas sempre múltiplo de 8
octetos (64 bits). Pode haver mais de um campo de extensão. A presença de um campo de
extensão pode ser determinada pelo valor do campo Next Header. Cada Extension Header
tem um campo Next Header informando o próximo protocolo.
− Upper-Layer Packet Length (Comprimento do Pacote da Camada Superior): 32 bits.
Corresponde ao comprimento em bytes da camada superior, incluindo o cabeçalho e os dados
(PDU e SDU). Para protocolos de camada superior que carregam seu comprimento no
próprio cabeçalho, como o UDP, o valor desse campo é o mesmo do presente na camada
superior.
− Next Header (Próximo Cabeçalho): O Next Header do pseudo-cabeçalho será diferente do
Next Header do cabeçalho IPv6, somente no caso em que houver Extension Headers após o
IPv6. Nesse caso, o Next Header do IPv6 informa o valor do Extension Header.
2.7 -Protocolo TCP
O TCP (Transmission Control Protocol) é o protocolo de transporte
destinado a aplicações que necessitam de uma entrega confiável e em
seqüência. O protocolo utiliza o estabelecimento de uma conexão entre o
transmissor e o receptor (TANENBAUM, 2003).
Uma conexão TCP é full-duplex e ponto a ponto. Consiste em um fluxo
de bytes e cada byte em uma conexão TCP tem seu próprio número de
seqüência de 32 bits. As entidades transmissoras e receptoras trocam
dados na forma de segmentos, sendo um segmento TCP composto por um
cabeçalho de tamanho fixo de 20 bytes que pode ser seguido por opções
de cabeçalho, seguido por um conjunto de bytes de dados
(TANENBAUM, 2003).
31
FIGURA 12 - CABEÇALHO TCP
O cabeçalho TCP é composto por 16 campos, e está representado na Figura 12. Conforme
Tanenabum, 2003:
− Porta origem e porta destino: Identificam os pontos terminais da conexão: processos ou
threads .
− Número de seqüência: Identifica a posição deste segmento no fluxo de dados e cada conexão
possui um fluxo de dados particular .
− Número de confirmação: Utilizado para confirmar o recebimento de segmentos enviados
anteriormente e especifica o próximo segmento aguardado .
− Tamanho do cabeçalho: Tamanho do cabeçalho TCP (números de palavras de 32 bits) .
− Urgent Point: Seu valor é igual a 1 se houver informação no campo Urgent Pointer.
− ACK: Se seu valor for 1: indica que o segmento é parte de uma conversação e que o valor do
campo Acknoledgement number é válido,`se seu valor for 0 e o flag SYN for 1: indica que o
segmento é uma solicitação de conexão .
− PSH: Campo usado pelo remetente do segmento para indicar ao receptor que o segmento em
questão deve ser entregue imediatamente ao nível superior .
− RST: Utilizado para reiniciar uma conexão que tenha ficado confusa devido a uma falha na
estação ou por qualquer outra razão .
− SYN: Usado em conjunto com o ACK para solicitar ou aceitar uma conexão .
− SYN=1 ACK=0: requisição de conexão;
32
− SYN=1 ACK=1: conexão aceita;
− SYN=0 ACK=1: “confirmação do recebimento”.
− FIN: Usado para encerrar uma conexão e indica que o transmissor não tem mais dados para
enviar .
− Tamanho da janela deslizante: Indica o tamanho (disponível) do buffer do receptor e é usado
pelo receptor para indicar ao transmissor que diminua o fluxo de transmissão de dados .
− Checksum: Verificação de erros.
− Urgent pointer: Usado pela origem para indicar onde se encontra algum dado urgente dentro
do segmento .
− Opções: Campo para configuração de opções .
− Dados: Dados das aplicações .
2.8 -A interligação em redes TCP/IP
“A Pilha de Protocolos de interligação em redes denominado TCP/IP
pode ser utilizada para comunicação em qualquer conjunto de redes
interconectadas. Algumas empresas, por exemplo, utilizam o TCP/IP
para interconectar todas as redes de sua organização, ainda que a
empresa não se comunique com redes externas. Outros grupos utilizam o
TCP/IP para estabelecer comunicações entre sites geograficamente
distantes” (COMER, 2001).
O TCP/IP é, sem dúvidas, a tecnologia mais importante para interligar computadores e redes, ela
é a base para o funiconamento da Internet. Ela é responsável pelo transporte de pacotes de
informações e pela garantia de comunicação extremidades.
Como a utilização da Internet tende a expandir cada vez mais durante os próximos anos, o
dispositivo ou aplicativo que não estiverem preparados para agregar este conjunto de protocolos
estará fadado ao fracaço, porque chegará um momento que ele não terá interface com diversos
outros recursos.
33
Contudo, a exploração e o desenvolvimeno de aplicações que utilizem essa tecnologia é um
grande mistério, pois as literaturas existentes tratam cada protocolo separadamente ao invés de
integrados (COMER, 2001).
“A tecnologia TCP/IP abrange vários protocolos que interagem. Para
preencher completamente os detalhes e a implementação de um
protocolo, uma pessoa precisa levar em consideração a interpretação de
tal protocolo com outros protocolos em conjunto (COMER, 2001).”
Quando se programa para TCP/IP utiliza-se de recursos do sistema operacional onde se está
programando. O recurso mais usado sempre serão as portas utilizadas pelos aplicativos nativos
do sistema.
Este, acaba sendo o método utilizado pelos desenvolvedores para ativar novos recursos de rede
com a utilização de TCP/IP.
O modelo mais usado atualmente em sistemas de uma rede TCP/IP é o de cliente/servidor, com
interface gráfica e multimídia, sem sessão, implementado por meio de tecnologia existente no
WWW (World Wide Web): o cliente WWW (browser), o protocolo HTTP e o servidor WWW
(VILLAS, 2007).
Normalmente cliente e servidor estão em computadores diferentes, ambos conectados à mesma
rede TCP/IP, como por exemplo a Internet (VILLAS, 2007).
2.9 -Protocolo RTP
O RTP (Real Time Transport Protocol - Protocolo de Transporte em Tempo Real) é um
protocolo que funciona no espaço de usuário do sistema operacional, vinculado à camada de
aplicação, porém é um protocolo genérico e independente de aplicações, comum aos protocolos
da camada de transporte, por isso pode ser definido como um protocolo de transporte
implementado na camada de aplicação (TANENBAUM, 2003).
No espaço de usuário está contida a biblioteca RTP, na qual são armazenados fluxos de mídia.
Esta biblioteca faz a multiplexação destes fluxos e os codifica em pacotes RTP que são
colocados em um soquete. Na outra extremidade do soquete, já no núcleo do sistema
operacional, são gerados os pacotes UDP e inseridos em pacotes IP. A Figuras 13 e 14
34
demonstram a posição do RTP num pacote de dados e como é a disposição de seu cabeçalho
(TANENBAUM, 2003).
FIGURA 13 - POSIÇÃO DO RTP NA PILHA DE PROTOCOLOS.
FIGURA 14 – CABEÇALHO DO RTP
A Figura 13 mostra a posicionamento da interface socket que ficam entre o aplicativo virtual e o
sistema operacional, este último onde estam alocados as camadas de transporte e comunicação.
Já a Figura 14 demonstra o encapsulamento do protocolo RTP. Que possui no campo Ethernet
hearder um espaço para identificação, no cabeçalho (TANENBAUM, 2003):
− V (Versão) - 2 bits: Identifica a versão de RTP utilizada. Este item descreve a versão "dois"
do protocolo. A versão 0 foi inicialmente desenvolvida para o VAT (ferramenta de
transmissão de áudio).
− P (Acolchoamento ou Padding) - 1 bit: Este bit é "um" quando existem um ou mais octetos
adicionais ao final do pacote que não fazem parte dos dados. Estes deverão ser ignorados
pois estão ali apenas devido a certos algoritmos de encriptação necessitarem um tamanho
fixo dos blocos. O último octeto de acolchoamento possuirá a informação de quantos octetos
foram inseridos.
35
− X (Extensão) - 1 bit: Se este bit for "um", o cabeçalho fixo será seguido de apenas uma
extensão de cabeçalho .
− Conta de CSRC - 4 bits: Quantidade de identificadores CSRC presentes no cabeçalho. Estes
serão explicados mais à frente. O número de CSRC's está limitado entre 0 e 15 .
− M (Marcador) - 1 bit: Este bit pode ser usado pela aplicação para marcar determinados
pacotes .
− Tipo de dados - 7 bits: Este campo define que tipo de dados há no pacote e como devem ser
interpretados pela aplicação .
− Número Seqüencial - 16 bits: Este campo serve para ordenar os pacotes de uma
comunicação, sendo que o primeiro pacote recebe um número seqüencial aleatório e os
seguintes recebem o número seqüencial do pacote imediatamente anterior incrementado de
um .
− Carimbo de Tempo - 32 bits: Ilustra o momento em que o primeiro octeto dos dados foi
gerado.
− Identificador SSRC (Fonte de Sincronização ou Synchronization Source) - 32 bits: Identifica
as fontes de sincronização. Cada participante de uma sessão RTP escolhe de forma aleatória
um identificador SSRC que irá identificá-lo dentro desta sessão frente aos outros
participantes. A probabilidade de duas fontes escolherem o mesmo SSRC é quase nula, mas
mesmo assim, todas as aplicações RTP devem estar preparadas para detectar e solucionar
colisões .
− Identificador CSRC (Fonte Contribuinte ou Contributing Source) - 32 bits: Identifica as
fontes que contribuíram para a formação dos dados contidos no pacote. Este identificador se
aplica a pacotes gerados por Misturadores .
A função básica do RTP é a multiplexação de vários fluxos de dados de tempo real em um fluxo
UDP (HART, 2005).
Cada pacote de um fluxo RTP recebe um número de seqüência, permitindo assim, que caso um
pacote se perca, o receptor perceba sua falta e por meio de interpolação gere um valor
aproximado para substituir o pacote perdido (TANENBAUM, 2003).
36
2.10 -Protocolo RTPC
RTPC é usado para transmitir aos participantes, de tempos em tempos, pacotes de controle
relativos a uma versão RTP em particular. Esses pacotes de controle podem incluir informações
a respeito dos participantes (seus nomes, endereços de e-mail, etc.) e informações sobre o
mapeamento dos participantes em suas fontes de fluxo individuais (HERSENT, GUIDE e
PETIT, 2002).
Todos os participantes devem enviar pacotes RTPC, o que causa um problema de
dimensionamento em potencial para grandes conferências multicast: o tráfego RTPC deve
crescer linearmente com o número de participantes. Esse problema não existe com fluxos RTP
em conferências com apenas áudio que usem supressão de silêncio, por exemplo, uma vez que as
pessoas geralmente não falam ao mesmo tempo (veja Figura 15) (HERSENT, GUIDE e PETIT,
2002).
FIGURA 15 – TRAFEGO RTP NÃO CRESCE COM O NÚMERO DE PARTICIPANTES
A taxa de envio média é obtida pelo participante a partir do tamanho dos pacotes RTCP que ele
deseja enviar e a partir do número de transmissores e receptores que aparece nos pacotes RTPC
que ele recebe (HERSENT, GUIDE e PETIT, 2002).
2.11 -VoIP
“VoIP é o setor de telecomunicaçoes que mais cresce. Seu crescimento
está ocorrendo a uma taxa mais veloz do que o crescimento da telefonia
móvel. Fabricantes, operadoras e gerentes precisam se adaptar mais
rápido do que nunca, mas a curva de aprendizado é bastante íngreme e
requer de fato um estratégia educacional (HERSENT, GUIDE e PETIT,
2002) ”
37
VoIP é uma tecnologia utilizada para digitalizar, codificar, empacotar e enviar dados de voz em
datagramas IP numa rede que utiliza a pilha de protocolos TCP/IP (HART, 2005).
A tecnologia surgiu tendo como um de seus objetivos unificar em uma única rede de serviço a
transmissão de voz e de dados. Mas para que o sistema funcionasse foi necessário o
desenvolvimento de um protocolo comum. Então, várias partes interessadas se uniram e sob o
patrocínio da ITU (International Telecommunication Union) foi emitida a recomendação H.323
que consiste em um conjunto de protocolos que permitem a comunicação de terminais utilizando
aplicações de áudio, vídeo e dados multimídia (HART, 2005).
Em março de 1999 a IETF (Internet Engineering Task Force) apresenta sua solução denominada
SIP (Session Initiation Protocol), que é uma forma mais simples e modular de utilizar voz sobre
IP.
O MGCP (Media Gateway Control Protocol) é o protocolo presente nos gateways dos sistemas
VoIP. Foi definido pela IETF em conjunto com a ITU e tem a função de controle de chamadas,
transmissões e sinalização, monitorando os troncos de telefonia e enviando mensagens de mídia
para endereços específicos (HART, 2005).
2.12 -Telefonia IP
O conceito de telefonia IP atual não resume-se somente ao estabelecimento de comunicação de
voz pela Internet, pois agregam-se a este sistema diversos outros serviços como correio de voz,
e-mail, conferência e diversas outras funcionalidades (HART, 2005).
À primeira vista, a tecnologia por trás da telefonia IP pode parecer quase trivial. Mas não é. Em
particular, ela é muito mais complexa do que a transmissão unidirecional (streaming) de mídia
(usada na transmissão de TV ou de rádio na rede), porque a latência entre locutor e ouvinte é
muito baixa, ao passo que aplicações tipo streaming podem usar buffers muito grandes
(HERSENT, GUIDE e PETIT, 2002).
A velocidade com que a telefonia IP se transformou em uma indústria é realmente
impressionante, mas ainda está longe de ter atingido a maturidade (HERSENT, GUIDE e PETIT,
2002).
38
A telefonia IP tem redefinido o sistema de telefonia apresentando como principais características
(HART, 2005):
− Segurança - utilizando-se os protocolos de transporte de fluxos de mídia na Internet, como
por exemplo o RTP, tem-se a possibilidade de criptografar estes fluxos, impossibilitando os
”grampos telefônicos”;
− Serviços e personalização - a telefonia IP permite que o próprio usuário inclua novos
serviços de forma fácil e consistente, o que na telefonia convencional é permitido somente a
adição de serviços pela companhia telefônica e, ainda assim, não são todos os serviços
disponíveis;
− Preço - os custos da telefonia IP são reduzidos em relação a telefonia convencional,
referindo-se aos custos de ligações interurbanas e utilização de serviços. Esta redução de
custos se dá pelo fato de que a comunicação passa a ser feita pela Internet, não havendo mais
a cobrança de pulsos ou ligações interurbanas pela companhia telefônica.
A telefonia IP se apresenta em três cenários (HART, 2005):
− PC para PC: Todo o tratamento de voz (amostragem, compressão, empacotamento)
ocorre nos PCs, chamadas baseadas em endereços IP ou nomes associados, ambiente
totalmente IP, sem conexões com o sistema telefônico convencional, conforme mostra a
Figura 16;
FIGURA 16 – TELEFONIA IP PC/PC
− PC para telefone: funciona com intervenção de um gateway (Figura 17);
39
FIGURA 17 - TELEFONIA IP COM USO DE GATEWAY
− Telefone para telefone: há a necessidade de usar um gateway em cada ponta. As redes de
telefonia podem ser formadas por centrais de PBXs ou operadoras públicas, cenário
esquematizado na Figura 18.
FIGURA 18 - TELEFONIA IP TELEFONE/TELEFONE
2.13 -Protocolo H.323
O H.323 define principalmente a sinalização necessária para estabelecer chamadas e
conferências, para excolher codec. O núcleo do RTP/RTCP ainda é usado para transportar fluxos
isócronos e obter retorno sobre a qualidade da rede, mas apsectos mais peculiares do RTP, como
distribuição de alias de e-mail, geralmente não são usados pelo H.323 (HERSENT, GUIDE e
PETIT, 2002).
De um modo geral, o processo de estabelecimento de chamada pode ser representado na Figura
19. Onde a esquerda são demonstrados os protocolos disponíveis para transmissão do terminal 1
ao terminal 2, entre os dois há o gatekeeper que interage com a transmissão oferecendo, sobre
tudo, segurança à conexão.
40
FIGURA 19 - PROCESSO GENÉRICO DE ESTABELECIMENTO DE CHAMADAS
O H.323 utiliza vários canais para a estruturação e troca de informações durante a comunicação.
Um canal é uma ligação a nível de camada de transporte, podendo ser uni ou bi-direcional
(NUNES, 2004).
Para o estabelecimento de uma chamada existe a necessidade da utilizaçao de canais de ligação.
O H.323 utiliza para este propósito alguns canais. O canal RAS (Registration, Admission e
Status) tem a função de estabelecer e encerrar uma conexão entre um terminal e um gatekeeper.
Pelo canal RAS o terminal faz a requisição para dar início a uma chamada ao gatekeeper que é
encontrado pela transmissão de um pacote UDP na porta 1718. O gatekeeper verifica se é
possível a prestação do serviço, verifica se o número máximo de chamadas ainda não foi
atingido, se a largura de banda requisitada pelo terminal está disponível e retorna ao terminal o
endereço do canal de sinalização de chamada do destinatário (NUNES, 2004).
O canal de sinalização de chamada transporta a informação para a sinalização da chamada e
todas as outras funções da telefonia padrão, como estabelecimento de conexão, sons de
discagem, entre outros. O serviço de sinalização é realizado com a utilização de protocolos TCP
e utiliza o protocolo Q.931 (NUNES, 2004).
Após a chamada estabelecida, o gatekeeper está fora do loop, os pacotes subseqüentes vão
diretamente ao endereço IP do gateway, utiliza-se o canal de controle de chamada que utiliza o
protocolo H.245. Tendo em vista que diversos protocolos podem ser usados para a realização da
41
compactação da voz, o protocolo H.245 é responsável pela negociação de qual algoritmo deve
ser usado e negocia outros aspectos da transmissão, como taxa de bits (TANENBAUM, 2003).
Após efetuada a negociação e estabelecidos os parâmetros, são requisitados os canais lógicos
para o transporte de dados de mídia, utilizando-se os protocolos RTP e RTCP.
Para o encerramento da chamada são requisitados novamente os canal de controle H.245, que
tratará do encerramento entre os terminais, e o canal RAS que tratará do encerramento com o
gatekeeper.
2.14 -Asterisk
Asterisk é um software TDM híbrido de Código Aberto, uma plataforma de pacotes de voz PBX
e uma plataforma IVR com funcionalidades ACD(Automatic Call Delivery – usados call
centeres para gerenciar chamadas).
A ferramenta possui um recurso denominado Interactive Voice Response (IVR), que é um
sistema de voz automatizada que permite provedores implantarem menus em que o usuário
navegue usando o teclado do telefone ou via comandos falados.
Informalmente o Asterisk é, possivelmente, a peça de integração de telecomunicações mais
potente, flexível e extensível disponível no mercado de software. Seu nome vem do símbolo
asterisco, *, o qual em UNIX (incluindo Linux e DOS) representa um wildcard, significando
qualquer nome de arquivo. Similarmente, Asterisk o PBX é destinado a integrar qualquer peça
de telefonia, seja hardware ou software, a aplicações, com facilidade e consistência.
Tradicionalmente, produtos de telefonia são desenvolvidos para atender a uma necessidade
específica em uma comunidade. No entanto, muitas aplicações da telefonia compartilham de um
grande acordo tecnológico. O Asterisk toma vantagem desta sinergia para criar um único
ambiente que pode ser moldado para agregar qualquer aplicação particular, ou uma coleção de
aplicações, como o usuário achar melhor.
O Asterisk é geralmente distribuído sob os termos do GNU (termo usado a qualquer sistema
operacional baseado em UNIX) ou GPL (General Public License - Licença Pública Geral). Esta
licença permite a distribuição do código e dos binários do Asterisk com ou sem modificações e
sem qualquer restrição de uso ou redistribuição do código.
42
A GPL não se extende para o hardware ou software utilizados pelo Asterisk. Por exemplo, se
você estiver usando um telefone IP como cliente pelo Asterisk, não é requerido que este
programa também seja distribuído sob GPL. Adicionalmente, aplicações AGI são simplesmente
carregadas pelo Asterisk e comunicam-se por essas aplicações nas quais o GNU-GPL não é
apropriado. A Digium é a única capaz de licenciar o Asterisk fora dos termos da GPL, em sua
discrição.
O Asterisk é desenvolvido para permitir que novas interfaces e tecnologias sejam
adicionadas/agregadas facilmente. Essa sublime meta é para suportar qualquer tipo de
tecnologias telefônicas possíveis.
As diversas tecnologias agregadas ao Asterisk são divididas em três grupos gerais:
− Interface Pseudo TDM Zaptel: Esta interface permite a integração com o sistema telefônico
digital e analógico e possui suporte à Pseudo-TDM switching, o que permite a realização
realização de video conferência.
− Interface não Zaptel: Esta interface permite a integração com o sistema telefônico digital e
analógico, mas não dá suporte à Pseudo-TDM switching, permitindo assim somente a
realização de chamadas telefônicas.
− Protocolos de pacotes de voz: São os protocolos padrões para a comunicação por meio da
tecnologia VoIP (SIP, IAX, H.323, etc.), e não necessitam de nenhum hardware adicional.
2.14.1 -Redução de Custo extrema
Ao comparar o Asterisk com um PABX convecional, talvez a diferença seja pequena,
principalmente pelo custo do hardware e dos telefones IP. Entretanto, ao adicionar recursos
avançados como VoIP, URA e DAC, a diferença vai à mais de dez para um (GONÇALVES,
2005).
2.14.2 -Ter controle do Sistema Telefônico
Este é um dos benefícios mais citados, porque a configuração não necessita de técnicos
autamente especializados, o proprio usuário pode configurar o Asterisk de acordo com sua
necessidade (GONÇALVES, 2005).
43
2.14.3 -Ambiente de Desenvolvimento
O Asterisk pode ser programado em C com as API’s nativas ou em outra linguagem usando AGI
(GONÇALVES, 2005).
2.14.4 -Provendo recursos dinâmicos por telefone
Como o Asterisk é programado em C ou outras linguagens de domínio da maioria dos
programadores, as possibilidades de prover conteúdo dinâmico por telefone são bastante
expansíveis.
2.14.5 -O mercado para o Asterisk
O mercado vem se adaptando aos novos conceitos de tecnologia e apresentando soluções mais
baratas e eficientes utilizando o conceito de telefonia IP e encontrando o Asterisk como a melhor
ferramenta (GONÇALVES, 2005).
2.14.6 -Plano de discagem flexível e poderoso
Outro aspecto que destaca o Asterisk dentre as outras centrais telefônicas é rota de menor custo,
que nas centrais convencionais não possui e no Asterisk este processo se torna simples e prático
(GONÇALVES, 2005).
2.14.7 -Asterisk e a comunidade GNU
A comunidade GNU há muito tempo tem se mostrado muito cooperada, os softwares
desenvolvidos são de códigos abertos e atraem diversos colaboradores em todo mundo. O
Asterisk por sua vez tem se tornado dos softwares livres o que mais tem recebido colaboradores
e adeptos, enriquecendo ainda mais suas funcionalidades (GONÇALVES, 2005).
2.14.8 -Limitações da arquitetura do Asterisk
O Asterisk usa a CPU do servidor para processar os canais de voz em contra partida de um DSP
(processador de sinais digitais).
2.15 -Protocolo SIP
O SIP tem a função de iniciar, configurar, gerenciar e encerrar sessões multimídia, como
chamadas telefônicas ou conferências multimídia. O SIP é um protocolo da camada de aplicação
44
e baseia-se em outros protocolos como o SMTP (Simple Mail Transport Protocol) e HTTP
(Hyper Text transport Protocol), e pode funcionar sobre o UDP ou TCP (TANENBAUM, 2003).
O principal papel do SIP é o estabelecimento de sessões ou associações, que posteriormente são
utilizadas para troca de dados de mídia. A Figura 20 demonstra este conceito (NUNES, 2004).
FIGURA 20 - SINALIZAÇÃO GENÉRICA DO SIP
2.16 -Bilhetagem e Tarifação
O CDR (Call Detail Record) é um registro que contém informações sobre uso recente de
sistema, como a identificação de fontes (pontos de origem), as identidades de destinos
(extremidades), a duração de cada telefonema, a quantia faturada para cada telefonema, o tempo
de uso total no período de faturamento, o tempo livre total permanecendo no período de
faturamento, e o corrente total carregado durante o período de faturamento.
A utilização desse recurso serve para formar toda estrutura necessária para gerar os arquivos e
tabelas para envio das informações de tarifação aos módulos de tarifagem, que estarão próximos
de cada ramal.
Haverá uma tabela com os valores das rotas que será extraído do site da Agencia Nacional de
Telecomunicações (ANATEL) e de empresas prestadores de serviços de coletas de valores de
rotas telefônicas.
2.17 -Trabalhos Realizados
No decorrer do desenvolvimento da pesquisa foram descobertas algumas monografias que
utlizaram o mesmo princípio de pesquisa deste projeto e todas adotando o Asterisk como
recurso.
45
Um dos trabalhos estudou o desenvolvimento de solução de voz sobre ip (VoIP) baseada em
software livre e foi apresentado para o curso de graduação de Ciências da Computação. Outro
trabalho, também de graduação, do curso de Bacharelado em Informática, desenvolveu uma
estrutura de telefonia que interligava filias em localizações remotas com a matriz, com a
utlização do Asterisk como central PBX-IP.
Esses trabalhos mostram como a Telefonia-IP vem sendo explorada e como o Asterisk pode
contribuir o desenvolvimentos de novas alternativas de telecomunicações.
46
CAPÍTULO 3 - ESPECIFICAÇÃO DO PROJETO
O projeto consiste no desenvolvimento de um sistema PBX-IP que fornece o serviço de
telecomunicações para uma rede local, oferencendo o recurso de gerenciamento de telefonias
convencionais e IP, por meio de rotas de menor custo e do controle de ligações realizadas nos
ramais telefonicos com links no servidor pela rede.
A topologia foi baseada na estrutura de uma rede cliente/servidor e demonstra o tráfego de dados
e voz com a utlização da mesma estrutura.
INTERNET
VOIP
Estação de Trabalho(Página e X-Lite) MÓDULO TARIFADOR
com Display LCD
RTPC
Asterisk
FXO
ETH
ETH
FXS
Router ADSL
Hub
FIGURA 21 – TOPOLOGIA DA REDE LAN
A Figura 21 representa a topologia da rede desenvolvida. É uma rede ethernet com velocidade de
100Mbps, contém dois servidores, um para realizar o papel de DNS, DHCP e Gateway e outro
para prover os serviços relacionados ao Asterisk.
47
Estão agrupados à rede, 3 tipos de clientes: telefone IP, estação de trabalho e o módulo tarifador,
porém o telefone IP pode ser substituído por um softfone (software para telefone) representado
na Figura 21.
O módulo tarifador é o hardware desenvolvido, ele é formado, dentre outros componentes, por
um display LCD, contém um endereço IP e um mac-address. O módulo tarifador mostra
informações correspondentes à realização de ligações externas por um ramal vinculado a ele.
A Figura 21 mostra o link com a operadora VoIP, por meio da Internet e o link com a RTPC
(Rede Pública de Telefonia Pública Comutada) que fornece o tronco de telefonia convencional .
Os links garantem que o sistema terá as opções para realização da rota de menor custo. Ambas as
conexões estão ligadas no servidor PBX-IP.
O servidor consegue conectar–se a RTPC, devido a uma placa PCI denominada X100P,
fabricada pela Digium com o objetivo de efetuar conexões do tipo FXS/FXO.
O PBXIP é um computador que não necessita de muito recurso de memória, mas precisa que o
processador tenha um clock rápido, pois o Asterisk executa muitas interrupções na execução dos
processos no ato das ligações telefônicas.
A máquina utilizada como servidor tem a seguinte configuração: Sistema Operacional Linux,
com kernel 2.6, distribuição Fedora release 6. Foi utilizado um microcomputador com
processador AMD Athlon 64, 1600 MHz (8 x 200) 2600+, placa mãe ASUS K8V – X, memória:
256 MB (PC3200 DDR SDRAM).
Sua principal funcionalidade é controlar o fluxo de ligações realizadas pelos ramais e determinar
a melhor rota entre os troncos de telefonia IP e convencional, com a utilização do software
desenvolvido pela empresa Digium Asterisk, que está na versão 1.2.17.
O Asterisk tem recurso de integrar suas funções ao banco de dados MySQL. No projeto foi
utilizado este recurso para armazenar as informações de tarifas telefônicas e relacionar o IP do
módulo tarifador com o ramal correspondente, além da funcionalidade já existente para o
armazenamento do histórico na tabela CDR das ligações efetuadas.
3.1 -Software
O projeto é composto por hardware e software, no entanto, o desenvolvimento do software
utilizou mais tempo no projeto. Foram desenvolvidos aplicativos para gerar Rotas de Menor
48
Custo, coletagem da duração de uma ligação em um ramal e o cálculo para o valor da tarifa, e o
desenvolvimento de três páginas com o objetivo de facilitar a manutenção na central PBX-IP.
Todos os módulos se relacionam com intermediação do Asterisk que realiza uma interligação
com banco de dados MySQL.
RTPC
ASTERISKGERA_ROTAS EnviaLCD
SIMPLESERVER
SIMPLECLIENT
BDASTERISK
INTERNET
VOIP
LAN
ENVIA_LCD
ALL_RATES
CDRDISPRAMAL
MÓDULO TARIFADOR com Display LCD
FIGURA 22 – ESTRUTRA DE RELACIONAMENTO DO SISTEMA COM O MÓDULO DE CONTROLE
A Figura 22 mostra o fluxo de informações entre os aplicativos do sistema. Nela pode-se
visualizar o Asterisk como centralizador do fluxo. Ele faz o tratamento dos troncos para
realização das ligações, conforme representam as nuvens da Internet e da RTPC (Rede de
Telefonia Pública comutada). O tronco VoIP existe após a criação de uma conta em uma
operadora e o acesso a ela é por meio da Internet.
O Asterisk tem um relacionamento com o banco de dados MySQL que alimenta a base de dados
Asterisk no MySQL, esta base tem três tabelas: all_rates, cdr, dispramal. A tabela all_rates
contém os valores de tarifas praticadas por diversas operadoras convencionais e uma operadora
VoIP para diversas localidades ao redor do mundo.
49
A tabela CDR é conseqüência do relacionamento do Asterisk com a base de dados Asterisk, ela
contém informações de todas as ligações efetuadas que, passaram pelo Asterisk. Essa tabela é
usada para verificação do ramal que a realizou a ligação e o tempo utilizado na ligação efetuada.
A tabela all_rates contém informações de tarifas praticadas por operadoras convencionais e VoIP
da cidade de Curitiba-PR para diversas localidades, inclusive locais para telefones fixos e
móveis. Essa tabela é utilizada para aplicar valor às ligações realizadas e para rotas de menor
custo.
A tabela dispramal contém informações do relacionamento entre o número do ramal e o IP do
módulo tarifador, sendo que cada ramal deve utilizar um módulo tarifador.
A Figura 22 demonstra, também, que o aplicativo desenvolvido Gera_Rotas recebe as
informações da tabela all_rates e as trata de forma a separar as operadoras com as menores
tarifas, em seguida estes dados são enviados ao plano de discagem do Asterisk.
Ao término de uma ligação realizada e atendida pelo destinatário, o Asterisk chama o aplicativo
Envia_LCD, este software busca as informações na tabela CDR da última ligação
realizada,calcula o valor com base na rota utilizada e na duração da ligação. Partindo desta linha
são separadas todas as ligações efetuadas pelo ramal em um período de 20 dias, período de
cobrança de uma fatura praticado em uma operadora.
Em seguida, para enviar ao módulo tarifador, são preparadas strings com as informações de:
duração da ligação, valor da ligação efetuada, quantidade de ligações e o valor gasto pelo ramal
até o momento.
O Envia_LCD busca ainda, com o número do ramal usado, o IP do módulo de controle.
Logo após o aplicativo chama o software desenvolvido simple_server que abre a conexão com a
porta 1001, utilizada pelo módulo tarifador.
O Envia_LCD chama o aplicativo simple_client que recebe as strings preparadas com as
informações das ligações do ramal e envia-as para o IP do módulo tarifador pela porta 1001.
3.1.1 -Asterisk
Grande parte das funcionalidades do servidor existem devido os recursos do Asterisk, o
aplicativo está arquitetado com APIs, codecs e canais.
50
As APIs (Application Programming Interface) são usadas na conectividade com outros
aplicativos e dispositivos. As API’s são utilizadas nas situações:
• Para tradução de CODECS: interfaces já desenvolvidas no Linux para tratamento de som
protocolos de mídias de um modo geral.
• Aplicações Asterisk: interfaces entre os arquivos de configuração do Asterisk
• Formato de arquivo Asterisk: GSM, WAV, MP3.
• Canais Asterisk: o Asterisk vincula suas ligações aos canais conectados ao servidor devido
essa API.
Toda configuração do Asterisk, incluso de canais, contém um arquivo “.conf” correspondente,
que estão localizados por padrão na pasta /etc/asterisk que interagem entre si por meio de API’s.
O arquivo mais importante para arquitetura do Asterisk é o extension.conf, que reune todas as
informações necessárias para o funcionamento do PBX-IP, inclusive o plano de discagem,
originado da rota de menor custo.
3.1.2 -Canais
Todas as linhas telefonicas agrupadas ao Asterisk são consideradas troncos telefônicas ou canais
de comunicação, e cada um representa uma operadora telefonica.
Eles são as portas de saída do sistema e o fato de ter mais de um canal possibilita a realização da
rota de menor custo, pois a finalidade da rota é utilizar o valor mais baixo de tarifa entre as
operadoras.
No projeto foram utilizadas os canais convencionais (analógico/digital) e VoIP.
O canal VoIP utiliza a Internet para usar a conta criada na operadora VoIP, que prove os serviços
telefônicso. No Asterisk as configurações correspondentes a esta ação são realizadas no arquivo
USERS.CONF e SIP.CONF
Canal analógico/digital utiliza a Rede Pública de Telefonia Comutada. A interface enre a rede o
PBX-IP é uma placa para conexão com troncos telefônicos denomindas, X100P desenvolvida
pela mesma empresa do Asterisk, digium. As configurações atribuidas a este canal são relizadas,
no arquivo Zapata.conf e os drives da placa X100P no arquivo Zaptel.conf.
Essa placa tem interface PCI (Peripheral Component Interconnect), com um canal de
comunicação. Ela contem um chip Motorola que controla a interface PCI e oferece uma
51
comunicação bi-direcional. No sistema a comunicação é unidirecional, isto quer dizer que a
placa não é utilizada como ramal.
3.1.3 - Ramais
No Asterisk os ramais são configurados sobre o mesmo aspecto de uma conta de usuário. Nesta
configuração são determinados quais os acessos do ramal e as regras para efetuar e receber
chamadas.
Cada ramal é trasnportável a qualquer local da rede, pois, o acesso é realizdo após a autenticação
do usuário e senha.
3.1.4 -Modulo CDR
CDR significa Call Detail Records (gravação de detalhes de chamadas), neste módulo define-se
a forma de registro da chamadas telefônicas do Asterisk e o formato que serão gravadas.
O módulo é alterado no arquivo CDR.conf, este contém as informações para armazenagem na
base de dados.
3.1.5 -Tarifagem com MySQL
Existem "infinitas" possibilidades do que pode ser realizado com o Asterisk. Algo que pode ser
muito útil é a conexão com banco de dados, que pode ser feita via aplicações AGI, System() e
MYSQL(). No sistema foi utilizado a conexão com o MySQL.
Antes de executar as querys MySQL no Asterisk é necessário que o pacote relacionado a ação
esteja instalado. As claúsulas SQL são usadas pelo Gera_Rotas, que após executar envia o
resultado para o plano de discagem no arquivo extensions.conf.
FIGURA 23 - EXTENSÕES PARA EXECUÇÃO DE QUERYS NO ASTERISK
Antes de usar o MySQL deve-se editar o arquivo cdr_mysql.conf com configurações de acesso,
como mostra a Figura 23.
hostname=127.0.0.1 dbname=asterisk table=cdr password= user=root port=3306 sock=/tmp/mysql.sock userfield=1
52
FIGURA 24 – ESTRUTURA DA TABELA CDR
Além da configuração de conexão entre o Asterisk e o MySQL, é necessário criar uma base de
dados “Asterisk” e as tabelas descritas, principalmente a CDR, que é utilizada para aramazenar o
histórico das ligações realizadas. A Figura 24 mostra cláusula utilizada para a criação dessa
tabela.
3.1.6 -Extensions.conf
Alguns autores consideram o extensions.conf o principal arquivo do Asterisk. Nele é
efetivamente usado o plano de discagem e onde são definidas as regras de discagem.
Ele consiste de uma lista de instruções ou passos disparados a partir dos dígitos recebidos de um
canal ou aplicação.
O arquivo pode ser seprado em quatro partes:
• Aplicações: as aplicações são chamadas com opções que afetam a sua forma de
funcionamento.
• Contextos: são definidos entre conchetes ([]), eles tem um papel importante no Asterisk na
organização e segurança das ligações. Os contextos também definem o escopo e permitem
separar diferentes partes do plano de discagem. Os contextos estão ligados diretamente aos
canais. Cada canal existe dentro de um contexto e quando uma ligação entra no Asterisk ela é
processada em um contexto.
CREATE DATABASE asterisk; GRANT INSERT ON asterisk.* TO asterisk@localhost IDENTIFIED BY 'yourpassword'; USE asterisk; CREATE TABLE `cdr` ( `calldate` datetime NOT NULL default '0000-00-00 00:00:00', `clid` varchar(80) NOT NULL default '', `src` varchar(80) NOT NULL default '', `dst` varchar(80) NOT NULL default '', `dcontext` varchar(80) NOT NULL default '', `channel` varchar(80) NOT NULL default '', `dstchannel` varchar(80) NOT NULL default '', `lastapp` varchar(80) NOT NULL default '', `lastdata` varchar(80) NOT NULL default '', `duration` int(11) NOT NULL default '0', `billsec` int(11) NOT NULL default '0', `disposition` varchar(45) NOT NULL default '', `amaflags` int(11) NOT NULL default '0', `accountcode` varchar(20) NOT NULL default '', `userfield` varchar(255) NOT NULL default '', `vallig` flow NOT NULL default '' ); ALTER TABLE `cdr` ADD INDEX ( `calldate` ); ALTER TABLE `cdr` ADD INDEX ( `dst` ); ALTER TABLE `cdr` ADD INDEX ( `accountcode` );
53
Todas as instruções colocadas após a definição são partes dos contexto e Para iniciá-los é
necessário simplesmente digitar o novo contexto ([novocontexto]).
• Extensões: em cada contexto serão definidas diversas extensões. No Asterisk uma extensão é
uma string que dispara um evento.
FIGURA 25 – EXEMPLO DE EXTENSÕES DO EXTENSIONS.CONF
A Figura 25 mostra como as extensões são configuradas nos Extensions.conf. A instrução
“exten =>” descreve qual o próximo passo para a ligação. O “8580” é o conjunto de dígitos
que foi recebido (número discado). O “1”, “2” e “101” são prioridades que determinam a
ordem de execução dos comandos. Neste exemplo, discando “8580” irá tocar o telefone IP
registrado como “8580” se não atender em 20 segundos será desviados para prioridade 2.
Extensões determinam o fluxo das chamadas e podem ser para diversas aplicações.
FIGURA 26 - SINTAXE EXTENSION
A Figura 26 mostra a sintaxe de uma extensão, nela observa-se que a extensão pode chamar
uma outra aplicação. O comando “exten=>” é seguido por um número da extensão, a
prioridade, e a aplicação.
• Prioridades: são passos numerados na execução de cada extensão. Cada prioridade chama
uma aplicação especifica. Normalmente estes números de prioridade começam com 1 e
aumentam de um em um para cada extensão. Os números de prioridade não são
necessariamente consecutivos. As prioridades são executadas em ordem numérica.
3.1.7 -Interface WEB
No sistema foram desenvolvidas três páginas para facilitar a manutenção da central PBX-IP,
todas elas estão armazenadas no servidor Asterisk.
O acesso à interface de manutenção é feita por um navegador de internet em qualquer estação de
trabalho da rede local, o endereço de acesso é o IP do servidor.
54
As páginas foram desenvolvidas em liguagens Java Script, C e HTML. E tem as seguintes
funcionalidades:
• Atenticação de usuários: realiza consulta no arquivo manager.conf do Asterisk que contém o
cadastro dos usuários que podem realizar a manutenção do sistema.
• Manutenção de ramais: página que altera as configurações do arquivo sip.conf e user.conf do
Asterisk necessárias para inclusão e exclusão de ramais.
• Manutenção de troncos: altera as configurações dos arquivos zapata.conf e sip.conf, cada
arquivo contém informações dos troncos telefônicos.
3.2 -Hardware
A finalidade do hardware é informar aos usuários dos ramais interligados à central telefônica a
duração e o custo das ligações efetuadas para fora da rede.
O circuito projetado está preparado para receber quatro “strings” da central PBX-IP (por
Ethernet) e imprimir em um display de LCD (Liquid Crystal Display) as seguintes informações:
• Valor da ligação efetuada;
• Duração da última ligação efetuada;
• Quantidade de ligações efetuadas em um período;
• Valor total gasto pelo ramal dentro em um período.
O dispositivo é composto por um módulo de controle, um modulo conversor de Ethernet-serial
(Tibbo EM202 EV) e um display de LCD 20 X 4.
MÓDULO DE CONVERSÃO ETHERNET/SERIAL DISPLAY LCDMÓDULO DE CONTROLE
FIGURA 27 - FLUXO DO HARDWARE
55
A Figura 27 mostra o fluxo correspondente à comunicação entre os estágios do hardware. O
módulo de conversão Ethernet/Serial se comunica com o módulo de controle para enviar as
informações que chega da rede para o display.
3.2.1 -Módulo de controle
Foi desenvolvido para o sistema uma placa de circuito integrado que contém um
microcontrolador PIC16F877A, um MAX 232, um cristal de 20MHz, um regulador de tensão
L7805, um resistor de 10Ω, cinco capacitores eletrolíticos de 1µF, 2 capacitores de porcelana de
15pF, uma conexão fêmea DB9 serial e um conector de 16 pinos.
56
U1
PIC16F877
OSC1/CLKIN13
OSC2/CLKOUT14
MCLR/Vpp/THV1
RA0/AN02
RA1/AN13
RA2/AN2/VREF-4
RA3/AN3/VREF+5
RA4/T0CKI6
RA5/AN4/SS7
RE0/AN5/RD8
RE1/AN6/WR9
RE2/AN7/CS10
RB0/INT33
RB134
RB235
RB3/PGM36
RB437
RB538
RB6/PGC39
RB7/PGD40
RC0/T10S0/T1CKI15
RC1/T10S1/CCP216
RC2/CCP117
RC3/SCK/SCL18
RC4/SDI/SDA23
RC5/SDO24
RC5/TX/CK25
RC7/RX/DT26
RD0/PSP019
RD1/PSP120
RD2/PSP221
RD3/PSP322
RD4/PSP427
RD5/PSP528
RD6/PSP629
RD7/PSP730
VDD11
VSS12
VDD32
VSS31
U3
MAX232
C1+1
C1-3
C2+4
C2-5
VCC
16
GND
15
V+2
V-6
R1OUT12
R2OUT9
T1IN11
T2IN10
R1IN13
R2IN8
T1OUT14
T2OUT7
+
C14
1uF
+
C15
1uF
+
C16
1uF
+
C17
1uF
GND
Y1
CRYSTAL
C2
15pFC3
15pF
GND
+ C410uF
R110K
J1
CON9
123456789
J2
DISPLAY LCD
123456789
10111213141516
GND
LO
FIGURA 28 – ESQUEMÁTICO DO MÓDULO DE CONTROLE
57
No esquemático da Figura 28 aparece a placa desenvolvida para módulo de controle. No
bloco U1, o qual que representa o PIC16F877A, os pinos 13 e 14 estão conectados a um
cristal de 20MHz, representado pelo bloco Y1, e é responsável por gerar os pulsos
precisos para o bom funcionamento do microcontrolador. Ao cristal estão conectados
dois capacitores de 15pF ligados ao negativo da fonte (terra).
O pino 1 é o pino de reset do PIC. Os pinos 11 e 12, 31 e 32 do microcontrolador
recebem a alimentação da fonte. Os pinos 11 e 32 recebem a alimentação positiva e os 12
e 31 ligados no terra.
O pino 33 está conectado ao display (no esquemático, bloco CON16) e habilita o sinal
para inicializar transmissão quando estiver em nível lógico alto. O pino 34, também
conectado ao display, emite um sinal para seleção de registro e o pino 35 é responsável
por definir o módulo em leitura ou gravação.
Os pinos 37, 38, 39 e 40 juntos formam um pacote de 4 bits denominado “nible” por onde
são transmitidos os dados ao display.
O pino 25 está conectado ao bloco U3 que representa o conversor MAX232, esta ligação
é uma comunicação TX, ou seja, do qual são enviados os dados do PIC para o conversor.
Esta configuração é utilizada para dar resposta à rede quando o broadcast ou cliente
envia um sinal para identificá-lo.
O MAX 232 é um conversor CMOS (Complementary Metal Oxide Semicondutor) / TTL
(Transistor-Transistor Logic) utilizado para fazer conexão entre o microcontrolador e o
ambiente externo com a utilização da porta serial.
Observa-se na Figura 28 que o pino 7 do MAX232 está conectado ao pino 2 do conector
fêmea serial (representado por J1) a fim de receber as informações enviadas a partir de
uma conexão RX. O pino 8 envia as informações (TX) para ambiente externo.
3.2.1.1 - PIC16F877A
Neste projeto o microcontrolador é responsável por interpretar um sinal TTL e imprimir a
informação no display.
Existem vários microcontroladores no mercado, a razão que levou à escolha do
PIC16F877A foi seu baixo custo e a versatilidade em adaptá-lo em diversas interfaces de
comunicação
58
Ele é um microcontrolador de 8 bits, tem 40 pinos, é do tipo DIP com 8Kbytes de
memória para programa. Ele tem dois barramentos internos independentes, sendo um
para memória de dados e outro para memória de programa.
3.2.2 -Módulo de conversão Ethernet/Serial
Toda estrutra do módulo de controle (apresentado na seção 3.2.1) foi projetado para
interpretar um sinal TTL enviado por uma conexão serial. No entanto, prezando pela
praticidade e mobilidade do dispositivo, foi utilizado o conversor Ethernet/Serial EM202
da Tibbo para transformar o sinal dos protocolos TCP/IP em TTL, de forma que o
módulo de controle entenda.
O módulo possibilitou que o hardware obtivesse um endereço IP e um mac address, com
isto o hardware consegue operar na rede local.
Específicações:
TABELA 1 – ESPECIFICAÇÃO TÉCNICA DO TIBBO EM202-EV
Item Especificação Interface ethernet Ethernet 100BaseT Protocolos de rede suportados UDP, TCP, ARP, ICMP (PING) e DHCP
Interface serial e pinos I/Os RS232 (TX, RX, RTS, CST, DTR, DSR)
Velocidade da porta serial Até 115200bps Porta serial UART -none/even/odd/mark/space parity, 7/8 bits/character,
full-duplex com opcional para controle de fluxo RTS/CTS, half-duplex com controle de direção automático.
Buffer de roteamento 12Kbytes x 2 Alimentação 10 ~ 25VDC, 500mA Temperatura (ambiente) -5 à 70ºC Umidade relativa 10 - 90% Dimensão 125x95x52 mm Peso 110g.
FONTE: Site Akiyama (2007)
Nas específicações do EM202-EV da Tabela 1 nota-se uma interface ethernet de
100BaseT, isto significa que a velocidade máxima das informações que trafegam pelo
módulo são 100 Mbps. Ele suporta os principais protocolos de transporte da rede, no
entanto, neste projeto o dipositivo foi configurado para utilizar o protocolo TCP
(transmission control protocol).
59
A conexão ethernet possui 8 pinos, cada um com uma funcionalidade específica para
conexão. O pino 1 de TX+, o 2 de TX-, o 3 de RX+, o 6 de RX e o 4, 5, 7 e 8 não tem
funcionalidade.
O conversor tem um RS232 que efetua a comunicação serial utilizando os pinos
correspondentes ao RX para recepção das informações da rede e o TX para envio, os
outros pinos não são utilizados. O módulo contém uma porta serial com os recursos de
full-duplex e hal-duplex, no projeto utilizou-se o full-duplex porque por causa da rápidez
contida no recurso (MANUAL TIBBO, 2007).
A conexão serial, com nove pinos e a função de cada um é: 2 RX (input); 3 TX (output);
4 DTR (output); 5 Ground; 6 DSR (input); 7 RTS (output); 8 CTS (input). Os pinos 1 e 9
não possuem funcionalidade.
A placa é alimentada com tensão que varia entre 10 e 25 V e corrente de 500mA, contém
um buffer de 12Kbytes, utilizado para armazenagem de dados até que toda a informação
seja processada pelo dispositivo agrupado ao módulo (MANUAL TIBBO, 2007).
A Tibbo disponibiliza no site da companhia os softwares de configuração e controle do
dispositivo, usados para comunicação Ethernet, endereçamento IP e comunicação serial.
Dentre eles, foram utilizados:
• DS Manager: são configurados os aspectos da comunicação, como, a conexão
utilizada para enviar ou receber as informações (serial ou ethernet) o módulo será
identificado na rede. Definição do IP do módulo, se o endereço será fixo ou dinâmico,
qual a “port” utilizada, o protocolo de envio, o estado na rede local como servidor
TCP-IP (escuta a rede e recebe as requisições), cliente (envia requisições à rede) ou
ambos, máscara de rede e o endereço IP do Gateway, dentre outras funcionalidades de
controle de informações (MANUAL TIBBO, 2007).
No DS Manager as características da serial, sobre a interface (full-duplex, half-duplex
ou automático), velocidade (baud rate), paridade e bits de dados (MANUAL TIBBO,
2007).
No projeto as configurações foram:
Ethernet:
− DHCP: Desabilitado
60
− IP-Address: 192.168.1.5
− Port: 1001
− Gateway: 192.168.1.1
− Máscara de Rede: 255.255.255.0
− Protocolo de Transporte: TCP
Serial:
− Interface Serial: Automática
− Baud Rate: 9600 bps
− Paridade: 0
− Bits de Dados: 1-8 bits
• VSP Manager: relaciona o IP a uma porta serial virtual (COM1, COM2 e etc.).
• Tibbo Monitor: monitora o estado da porta, mostrando o estado e o que está pelo
módulo.
3.2.3 -Display LCD
O Display no escopo do hardware encaixa-se como o receptor das informações geradas
pelo servidor, convertidas de TCP-IP para serial pelo módulo de conversão e interpretada
pelo módulo de controle. A finalidade é informar ao usuário o valor, a duração da última
ligação realizada, a quantidade e o valor total gasto em um determinado período, pré-
estabelecido no PBX-IP.
FIGURA 29 – SIMULAÇÃO DAS INFORMAÇÕES DO DISPLAY
A Figura 29 simula como as informações são dispostas no display e quais pinos são
utilizados durante a comunicação, indicados com o ponto azul. O display utilizado é de
LCD (liquid crystal display), contém 20 colunas e 4 linhas,e backlight (luz de contraste),
16 pinos. A utilidade de cada pino é mostrada na Tabela 2.
TABELA 2 – PINAGEM DO LCD
61
PINO Símbolo FUNÇÃO
1 Vss GND 2 Vdd +3V ou +5V 3 Vo Ajuste Contraste 4 RS H/L Sinal de Seleção de Registro 5 WR / H/L Sinal de Leitura/Escrita
6 E H->L Sinal de Habilitação 7 DB0 H/L Linha de Barramento de Dados 8 DB1 H/L Linha de Barramento de Dados 9 DB2 H/L Linha de Barramento de Dados 10 DB3 H/L Linha de Barramento de Dados 11 DB4 H/L Linha de Barramento de Dados 12 DB5 H/L Linha de Barramento de Dados 13 DB6 H/L Linha de Barramento de Dados 14 DB7 H/L Linha de Barramento de Dados 15 A/Vee +4,2V para LED/Saída com tensão negativa 16 K Power supply for B/L (0V)
FONTE: Datasheet do Fabricante (WinStar)
De acordo com a Tabela 2 são utilizados para alimentação o pino 1 e 2, para contraste o
pino 3 e do pino 7 ao 14 para os dados, oito pinos um para cada bit de dados,
acompanhando a capacidade do microcontrolador descrito no item 3.2.1.1. No
desenvolvimento do projeto foram utilizados dos pinos 11 ao 14, quatro bits de dados.
3.3 -Custos do Projeto
Foram adiquiridos recursos excênciais, como os componentes usados para o
desenvolvimento do hardware e geração da documentação e recursos que facilitaram o
desenvolvimento do projeto, como notebook.
A Tabela 3 mostra a lista de itens e os valores investidos. Os softwares não estão listados
porque foram utilizados aplicativos de laboratórios e programas gratuítos como o Linux,
o Asterisk e o MySQL. O valor total investido foi de R$ 3.907,33 (três mil, novecentos e
sete reais e trinta e três centavos).
TABELA 3 – GASTOS COM PROJETO
62
FONTE: AUTOR, 2007
3.4 -Cronograma
O trabalho durou 238 dias e mesclando as atividades sendo 14,70% do tempo voltado
para desenvolvimento do software, 6% para o hardware e 78,99% voltado para pesquisa e
construção da documentação. Conforme mostra Tabela 4.
TABELA 4 – CRONOGRAMA DE ATIVIDADES
ATIVIDADE DESCRIÇÃO DATA INCIODEPENDECIA DAATIVIDADE FIM DURAÇÃO (DIA)
1 Proposta do Projeto 05/03/07 05/03/07 -
2 Pesquisa Asterisk 04/03/07 1 29/03/07 25
3 Pesquisa Linux 04/03/07 1 29/03/07 25
4 Coleta Bibliográfica 04/03/07 1 29/03/07 25
5 Especificação Técnica (Capitulos 1, 2 e 3) 04/03/07 2 - 3 - 4 02/04/07 29
6 Instalação e Configuração do Asterisk 03/04/07 03/04/07 -
7 Instalação e Configuração do MySQL 03/04/07 6 03/04/07 -
8 Desenvolvimento de rotas 04/04/07 6 - 7 19/04/07 15
9 Desenvolvimento do módulo tarifador 04/04/07 19/04/07 15
10 Desenvolvimento do envio Tarifagem 19/04/07 8 - 9 02/06/07 13
11 Integração Asterisk Módulo de Controle 19/05/07 10 02/06/07 14
12 Teste preliminares 03/06/07 11 29/05/07 56
13 Capítulo 4 30/05/07 5 - 12 11/06/07 12
14 Ajustes 11/06/07 12 19/10/07 38
15 Finalizar monografia 29/10/07 13 - 14 29/10/07 - 238 DURAÇÃO DO PROJETO
FONTE: AUTOR, 2007
INVESTIMENTOS VALOR (R$) Telefonia (ADSL, assinatura básica, provedor e tarifa) 1.040,00 Energia elétrica 227,33 Documentação (encadernação, impressão e tinta de impressão) 168,00 Notebook 2.000,00 Componentes eletrônicos e acessórios (resistor, capacitores, placa de circuito impresso, MAX 232, Cristal, etc.)
230,00
PIC16F877A 15,00 Display 40,00 Módulo de conversor Serial/Ethernet 187,00 TOTAL 3.907,33
63
CAPÍTULO 4 - DESENVOLVIMENTO E IMPLEMENTAÇÃO
Foi densevolvido todo método e aplicação para rota de menor custo, hardware e
softwares para o módulo tarifador e páginas de Internet para interface de manutenção.
No entanto, além dos atributos criados, foram realizadas modificações nas configurações
do Asterisk para adaptá-lo à estrutura do sistema.
Na base de dados padrão do MySQL para Asterisk foram criadas duas tabelas: all_rates e
dispramal e a inclusão do campo valor na tabela CDR, criada para armazenar históricos
de ligações do Asterisk.
4.1 -Lógica
O PBX-IP recebe e envia informações para outras redes de telecomunicações por meio de
links com as operadoras de telefônia convecional e IP. Todo o fluxo de ligações
efetivadas e recebidas é tratada pelo Asterisk.
As ligações realizadas são discadas por meio de um ramal. O Asterisk identifica onúmero
discado e este é comparado com o plano de discagem.
Por sua vez, o plano de discagem é formado pelo processo da rota de menor custo que é
executado sempre que a tabela de tarifas sofre alguma modificação.
Se a ligação for atendida pelo destinatário e finalizada, o Asterisk executa uma chamada
para rotina de coleta e envio das informações para o módulo tarifador que mostra as
informações ao usuário .
4.1.1 -Diagrama de contexto
O Diagrama de Contexto mostra o fluxo dos serviços providos pelo servidor PBX-IP. A
Figura 30 mostra o servidor PBX-IP representado pelo Asterisk que identifica a chamada
realizada por um ramal compara o prefixo do número discado com os valores do plano de
discagem e identifica qual a melhor rota a ser usada entre: tronco VoIP ou convecional e,
se for convecional, identifica qual a melhor operadora a ser utilizada.
64
O ramal no projeto foi um softfone, aplicativo utilizado em estações de trabalho. Este
perfil foi escolhido pela praticidade e flexibilida em comparação ao telefone VoIP.
RTPC Ramais / DisplaysASTERISK
Internet
FIGURA 30 – DIAGRAMA DE CONTEXTO
4.1.2 -- Diagrama de fluxo de chamadas
As chamadas descritas são realizadas através de ramais para o meio externo à rede. A
Figura 31 mostra o processo de tratamento das ligações efetivadas.
Quando o usuário retira o telefone do gancho é emitido um tom de discagem para então
efetuar chamada. Este processo é conhecido como off-hook (fora do gancho), neste estado
o usuário retira o telefone do gancho que fecha um loop elétrico e indica ao Asterisk que
o usuário deseja efetuar uma chamada. Nesse ponto o servidor fica pronto para receber o
endereço de destino. Para ligações interurbanas ou internacionais, o número discado não
pode conter a operadora, mas apenas o código de localidade e o número de destino.
Quando recebe o endereço de destino, o Asterisk, por meio das extensões definidas no
extensions.conf, determina qual a melhor rota dentre os dois canais de comunicação, além
de indicar qual a operadora, entre as convencionais, que pratica a tarifa mais baixa.
Quando a outra ponta atende a chamada é estabelecida e os arquivos cdr.conf e
cdr_mysql.conf são utilizado para atualizar em just time a tabela CDR, até o término da
ligação.
Quando a ligação é finalizada o Asterisk aciona o aplicativo Envia_LCD, que coleta da
base de dados as informações necessárias para enviar tarifador.
65
INICIO
Estabelecendo Conexão
Conexão Estabelecida?
Verificar Endereço de destino
Não
Sim
Definir Rota
Efetua Chamada
Bilhetagem
INICIO1
1
FIGURA 31 – FLUXOGRAMA DE CHAMADAS EFETUADAS
4.2 -Software
As atividades que mais utilizaram tempo no projeto são atribuídas ao desenvolvimento
dos softwares, configuração do Asterisk e tratamento de banco de dados. O
desenvolvimento originou as rotas de menor custo, ambiente de manutenção via web e a
tarifagem das ligações realizadas. As configurações do Asterisk formaram a base e
caracterizaram o projeto como PBX-IP. O banco de dados MySQL formou o acervo de
consulta para as ações da rota e tarifagem.
A programação foi realizada de forma estruturada, basicamente utilizando a liguagem C.
A base de dados criada e alterada por cláusulas SQL.
As páginas para interface web para manutenção do sistema foi realizada em linguagem
HTML e Java Script, o princípio fundamental do desenvolvimento foi atribuir e consultar
valores dos arquivos de configuração do Asterisk.
4.2.1 -Configuração do Asterisk
OAsterisk segue o padrão dos sofwares Linux, suas configurações nativas são realizadas
em ambiente modo texto, forma que oferece flexibilidade e expansão das atividades do
66
servidor. Ele é criado com o objetivo de organizar e dividir por categorias estes arquivos,
conforme Tabela 5.
TABELA 5 –ESTRUTURA DE DIRETÓRIOS DO ASTERISK
DIRETÓRIO DESCRIÇÃO
/etc./Asterisk Arquivos de configurações zaptel.conf e digivoice.conf
/usr/sbin Executáveis /usr/lib/asterisk/modules Módulos dos aplicações, codec, drivers /var/lib/asterisk/agi-bin Diretório das aplicações AGI /var/lib/asterisk/astdb Banco de dados /var/lib/asterisk/mohmp3 Arquivos de áudio utilizados para Música de Espera /var/lib/asterisk/sounds Arquivos de áudio /var/spool/asterisk/outgoing Diretório das gravações de ligações /var/spool/asterisk/vm Diretório das Caixas Postais
FONTE: GONZALES (2007)
Para adaptação do sistema foram alteradas as configurações dos seguintes arquivos:
cdr.conf, cdr_mysql.conf, extensions.conf, sip.conf, users.conf e zapata.conf.
EXTENSIONS.CONF
CDR.CONF CDR_MYSQL.CONF
ZAPATA.CONFSIP.CONF/
USERS.CONFTRONCOS E RAMAIS
CENTRALIZADOR DE INFORMAÇÕES
COLETAGEM
FIGURA 32 – DIAGRAMA DA ESTRUTURA – ASTERISK NO PROJETO
A Figura 32 mostra como está estruturado o Asterisk para as tarefas executadas no
sistema. O Zapata.conf é o arquivo que contém as configurações relacionadas ao tronco
analógico. Ele está diretamente relacionado aos drives da placa X100P, dessa forma, se o
periférico não estiver instalado o Zapata.conf não terá efeito e o acesso a rede pública de
telefonia comutadas não será realizada.
O SIP.conf contém as configurações para habilitar o uso de VoIP. As configurações a
respeito das operadoras VoIP são realizadas no arquivo USERS.conf
67
O CDR.conf é o arquivo que define a forma que será realizada o registro das chamadas,
contudo, com a escolha de armazenamento dessas informações em base MySQL é
necessário configurar o arquivo CDR_MySQL.conf com dados de acesso à base.
O EXTENSIONS.conf é o arquivo que concentra todas configurações do Asterisk. As
APIs entre os outros módulos de configuração do sistema são muito utilizadas neste
arquivo. É neste arquivo que as rotas de menor custo são concatenadas formando os plano
de discagem.
FIGURA 33 – TRECHO DA CONFIGURAÇÃO DO EXTENSIONS.CONF
A Figura 33 mostra o conteúdo do contexto “DID_trunk_3”, este é um trecho das
configurações das rotas de menor custo geradas a partir do aplicativo gera_rotas.
4.2.2 -Gera_rotas
O gera_rotas foi desenvolvido com a finalidade de gerar as extensões que definem
efetivamente a rota de menor custo. Ele foi desenvolvido em linguagem C e compilado
pelo GCC apartir de “make file”. O aplicativo foi desenvolvido para realizar chamadas
nas bibliotecas padrões do “C” (stdio.h, stdlib.h, conio.h) e na biblioteca mysql.h que
contém funções de acesso, consultas e manipulação no banco de dados MySQL.
O software foi armazenado no diretório \etc\rotas, e é executado automática pelo Asterisk
apartir de uma chamada no extensions.conf por uma macro alocada no contexto [default].
[DID_trunk_3] exten=_00119X.,1,Dial(Zap/g3/$EXTEN:0) exten=_0011X.,1,Dial(SIP/$EXTEN) exten=_00219X.,1,Dial(Zap/g3/$EXTEN:0) exten=_0021X.,1,Dial(SIP/$EXTEN) exten=_00319X.,1,Dial(Zap/g3/$EXTEN:0) exten=_0031X.,1,Dial(SIP/$EXTEN) exten=_00519X.,1,Dial(Zap/g3/$EXTEN:0) exten=_0051X.,1,Dial(SIP/$EXTEN) exten=_00619X.,1,Dial(Zap/g3/$EXTEN:0) exten=_0061X.,1,Dial(SIP/$EXTEN)
68
ARQUIVO ALL_RATES.SCV
IMPORTAÇÃO DO ARQUIVO PARA TABELA ALL_RATES NA BASE DE DADOS ASTERISK
AGRUPAMENTO DE PREFIXOS IGUAIS
CÁLCULO PARA DEFINIÇÃO DA ROTA DE MENOR CUSTO
GERAÇÃO DE ARQUIVO ROTAS.TXT COM A LISTA DE
CAMINHOS
CONCATENAÇÃO DO CONTEÚDO DE ROTAS.TXT COM EXTENSIONS.CONF
INICIO
FIM
FIGURA 34 – FLUXOGRAMA DE GERAÇÃO DAS EXTENSÕES DE MENOR CUSTO
No fluxograma representado na Figura 34, mostra o algoritmo para geração da rota de
menor custo. Um arquivo All_rates.scv, armazenado no diretório /etc./rotas, contém as
informações completas de custos das ligações, da origem ao destino, de todas as
operadoras VoIP e convencionais.
As tarifas são constituídas pelo minuto cobrado pelas operadoras de ligações efetuada
da cidade de Curitiba-PR para diversas localidades em todo o mundo. Estas informações
foram coletadas do site da Agência Nacional de Telecomunicações (ANATEL) e
pesquisas em sites de coleta de valores de rotas.
Cabe aqui uma observação: no mercado há empresas que fornecem base de dados com
informações de valores de tarifas telefônicas que poderiam substituir as pesquisas, no
entanto, o serviço não é gratuito e devido ao custo da assinatura não foi utilizado.
69
TABELA 6 – PARTE DO CONTEÚDO DO ARQUIVO E TABELA ALL_RATES
PREFIXO DECRICAO OPERADORA MOEDA TARIFA
11 Sao PauloSP\Fixo 25 BRZ 0,50468 11 Sao PauloSP\Fixo 14 BRZ 0,50843 11 Sao PauloSP\Fixo 21 BRZ 0,57005 11 Sao PauloSP\Fixo 31 BRZ 0,61244 11 Sao PauloSP\Fixo 23 BRZ 0,72098 11 Sao PauloSP\Fixo 15 BRZ 0,90869
119 Sao PauloSP\Móvel 21 BRZ 1,56986 119 Sao PauloRJ\Móvel 23 BRZ 2,45133 119 Sao PauloRJ\Móvel 15 BRZ 2,54220 11 Sao PauloSP\Fixo Voip BRZ 0,14
119 Sao PauloSP\Móvel Voip BRZ 0,70 21 Rio de JaneiroRJ\Fixo 25 BRZ 0,50468 21 Rio de JaneiroRJ\Fixo 14 BRZ 0,50843 21 Rio de JaneiroRJ\Fixo 21 BRZ 0,57005 21 Rio de JaneiroRJ\Fixo 31 BRZ 0,61244 21 Rio de JaneiroRJ\Fixo 23 BRZ 0,72098 21 Rio de JaneiroRJ\Fixo 15 BRZ 0,90869
219 Sao PauloRJ\Móvel 14 BRZ 1,76752 219 Sao PauloRJ\Móvel 31 BRZ 2,05459 219 Rio de JaneiroRJ\Móvel 21 BRZ 1,56986 219 Rio de JaneiroRJ\Móvel 14 BRZ 1,76752 219 Rio de JaneiroRJ\Móvel 31 BRZ 2,05459 219 Rio de JaneiroRJ\Móvel 23 BRZ 2,45133 219 Rio de JaneiroRJ\Móvel 15 BRZ 2,54220 21 Rio de JaneiroRJ\Fixo Voip BRZ 0,14
219 Rio de JaneiroRJ\Móvel Voip BRZ 0,70 41 CuritibaPR\Fixo Voip BRZ 0,14
419 CuritibaPR\Móvel Voip BRZ 0,70 41 CuritibaPR\Fixo 14 BRZ 0,32
419 CuritibaPR\Móvel 14 BRZ 0,19 51 Porto AlegreRS\Fixo 25 BRZ 0,50468 51 Porto AlegreRS\Fixo 14 BRZ 0,50843 51 Porto AlegreRS\Fixo 21 BRZ 0,57005 51 Porto AlegreRS\Fixo 31 BRZ 0,61244 51 Porto AlegreRS\Fixo 23 BRZ 0,72098 51 Porto AlegreRS\Fixo 15 BRZ 0,90869
519 Porto AlegreRS\Móvel 21 BRZ 1,56986 519 Porto AlegreRS\Móvel 14 BRZ 1,76752 519 Porto AlegreRS\Móvel 31 BRZ 2,05459 519 Porto AlegreRS\Móvel 23 BRZ 2,45133 519 Porto AlegreRS\Móvel 15 BRZ 2,54220 51 Porto AlegreRS\Fixo Voip BRZ 0,20
519 Porto AlegreRS\Móvel Voip BRZ 0,70 FONTE: ANATEL, COMPARATEL E ONDA (2007)
A Tabela 4 mostra parte do conteúdo do arquivo all_rates.csv, alimentado pelas
informações coletadas. A tabela está estruturada com as informações: de prefixo e
70
descrição do destino, operadora convencional (cada número representa uma operadora
diferente) e VoIP, moeda e valor da tarifa.
FIGURA 35 – CLÁUSULA SQL PARA IMPORTAÇÃO PARA TABELA ALL_RATES
O arquivo all_rates.csv foi criado exclusivamente para ser a fonte da tabela all_rates. A
Figura 35 mostra a clausula SQL usada para inserção do conteúdo do arquivo. O
comando SELECT seleciona a tabela para a execução do comando LOAD DATA INFILE,
que carrega um arquivo dentro de uma tabela, neste caso o arquivo é o “all_rates.csv” e a
tabela “all_rates”, o parâmetro FIELDS TERMINATED BY indica o que determina o
limite dos campos, nesta clausula o caractere “,” (vírgula) e o LINES TERMINATED BY
define o final da linha, na clausula o “\n” (marcador de final de linha).
FIGURA 36 – CLÁUSULA SQL PARA ORDENAÇÃO DA TABELA ALL_RATES
A Figura 36 mostra o próximo passo, referente à ordenação da tabela pelo campo
“prefixo”. Esta função é necessária para realizar o cálculo da rota de forma seqüencial.
O cálculo da rota inicia com a ordenação da tabela pelos prefixos, quando os prefixos
forem iguais é realizado uma simples subtração do valor da tarifa da linha corrente com o
da linha anterior, dessa forma o menor valor é indexado e assim para todos outros
prefixos.
O agrupamento são as rotas de menor custo no formato das extensões do arquivo
extensions.conf e resultando no arquivo Rotas.txt.
SELECT * FROM `asterisk`.`all_rates` ORDER BY `prefixo`;
SELECT * FROM `asterisk`.`all_rates` LOAD DATA INFILE '/etc/rotas/all_rates.csv' INTO TABLE all_rates FIELDS TERMINATED BY ',' LINES TERMINATED BY '\n';
71
INÍCIO
Conecta na base
Abre Tabela
Ordena Prefixo
Final Tabela?Enviar
Conteúdo[Pos] para nRotas.txt
Sim
Linha <- Linha + 1
Linha <- 1
Prefixo[Linha]= Prefixo [Linha-1]? Nao
Enviar Conteúdo[Pos] para Rotas.txt
Sim
Result <-(Tarifa[linha] –
Var)
Result < 0?
Var <-Tarifa[Linha]
Pos <- Linha
Não
Sim
NaoFim
1
1
FIGURA 37 – FLUXOGRAMA COMPLETO DO PROGRAMA GERA_ROTAS
A Figura 37 mostra o fluxograma completo do processo de geração de rotas, contido no
algoritmo gera_rotas.
O programa conecta-se a base de dados Asterisk no MySQL, abre a tabela All_Rates,
ordena o campo Prefixo.
Atribui à variável ‘Linha’ o valor 1, à variável ‘Var’ o valor da primeira linha da coluna
correspondente à tarifa o valor da tabela.
72
Atribui à variável ‘Pos’ o valor da variável ‘Linhas’, utilizando desse recurso com a
finalidade de assegurar a posição do último valor válido.
Incrementa a variável Linha para ler a próxima linha da tabela e verificar se chegou ao
final da Tabela. Se estiver no final da tabela envia o conteúdo da última linha registrada
indexada pela variável ‘Pos’ para o arquivo Rotas.txt.
FIGURA 38 –PARÂMETROS PARA CRIAÇÃO DO ARQUIVO ROTAS.TXT
Antes propriamente de enviar a linha indexada para o arquivo o programa gera uma string
no formato necessário para execução das rotas pelo extensions.conf, conforme ilustrado
na Figura 46, que mostra o trecho do código do Gera_Rotas, no qual é criado o conteúdo
do Rotas.txt.
Na Figura 38 a primeira providência, mostrada, é a atribuição de um select à variável
prefixo, que retorna o valor do campo prefixo da tabela indexado na posição indicada em
pos.
Na mesma figura, a variável "op" recebe a identificação da operadora na posição de
indicada pela variável pos.
Em seguida o código verifica se a operadora é VoIP ou convencional atribuindo, então, o
resultado em “str_1_rota”. A principal diferença entre as duas possibilidades é que, para a
operadora VoIP a string não necessita do código da operadora.
A última instrução é adicionar ao Rotas.txt o valor de str_1_rota. Para finalizar o
Gera_rotas, é usado o comando cat /etc./rotas/Rotas.txt >> /etc./asterisk/extensions.conf,
que concatena o conteúdo do arquivo Rotas.txt no extensions.conf
Prefixo = mysql_query(strcat("SELECT `OPERADORA` FROM `asterisk`.`cdr` limit,",pos,"1;"));
op = mysql_query(strcat("SELECT `OPERADORA` FROM `asterisk`.`cdr` limit,",pos,"1;"));
if (op = VoIP) then
str_1_rota = strcat("_00 ",prefixo,"Dial(SIP/$EXTEN)")
else
str_1_rota = strcat("_0",operadora,prefixo,"Dial(Zap/g3/$EXTEN:0)")
end if;
cat str_1_rota >> /etc./rotas/Rotas.txt
73
4.2.3 -Estrutura de Banco de Dados
O banco de dados está estruturado de forma a atender as necessidades do sistema, as três
tabelas estão organizadas com as informações para ativação das rotas de menor custo e
tarifagem.
Como já dito anteriormente, a base possuí um vinculo direto com o Asterisk, o que faz
com que o processo seja mais dinâmico.
MySQL
GERA_ROTAS ASTERISK ENVIA_LCD
DBAsterisk
ALL_RATES
CDR
DISPRAMAL
FIGURA 39 – DIAGRAMA DE RELACIONAMENTO DA BD COM AS APLICAÇÕES
A Figura 39 mostra o relacionamento do BD e as três tabelas contidas nas base:
all_rates, cdr e dispramal. As consultas são realizadas pelos softwares: Gera_rotas,
Asterisk e envia LCD
4.2.4 -Interface WEB para manipulação do usuário
O ambiente de programação do Asterisk não é amigável à maioria dos usuários, para
minimizar o impacto que isto proporciona em relação ao custo com pessoal especialisado
foram desenvolidas três páginas para: autenticação de usuários, manutenção de ramais e
manutenção de troncos. Estas ações realizam modifiações e consultas no arquivos de
74
configuração do Asterisk: manager.conf (para autenticação), users.conf, sip.conf,
zapata.conf e extensions.conf.
CADASTRA RAMAL
FIGURA 40 – DIAGRAMA DE CASO DE USO PARA CADASTRO DE RAMAL
A Figura 40 mostra o relacionamento do usuário com a página para cadastramento de
novos ramais
CADASTRA TRONCO
USUÁRIO
FIGURA 41 – DIAGRAMA DE CASO DE USO PARA CADASTRAMENTO TRONCOS
A Figura 41 mostra o relacionamento do usuário com a página para cadastramento de
troncos, no caso de novas operadoras VoIP ou aumento nos troncos convencionais
4.3 -Hardware
O hardware desenvolvido é denominado módulo tarifador, mostrado na Figura 42, que
recebe as informações de tempo e custo das ligações realizadas por um ramal. Na Figura
aparece o display LCD, a conexão RJ45 para interface de rede, pino para fonte de
alimentação e push button de reset.
EÉ alimentado por tensão de 5 a 12 volts e está preparado para trabalhar em redes TCP/IP
com velocidade de até 100Mbps.
75
FIGURA 42-MÓDULO TARIFADOR
Ele é divido em três partes, como mostra a Figura 43: conversor serial/ethernet que
recebe as informações da rede e converte em sinal TTL, módulo de controle que trata as
informações recebidas e o display que mostra as informações tratadas pelo módulo de
controle.
DISPLAY LCD
PIC 16F877A CONEXÃO SERIAL CONVERSORSERIAL/TCP
FIGURA 43 – RELACIONAMENTO ENTRE AS PARTES DO SOFTWARE
A interface do conversor com a o módulo de controle é realizada por meio de
comunicação serial, com um conector DB9 macho para o conversor e fêmea para o
módulo. O módulo de controle com um microcontrolador de PIC de 8 bits que efetua o
tratamento das informações recebidas e as imprime no display LCD.
4.3.1 -Coletagem e envio das informações
A coletagem das informações são realizadas por um aplicativo denominado Envia_LCD,
que é executado por uma chamada no Asterisk ao término de cada ligação.
76
O processo consiste na busca, na base de dados, das informações relacionadas ao tempo
e ao valor de tarifa da última ligação realizada. A partir deses resultados são separadas as
chamadas atendidas no período de vinte dias, utilizado como filtro o ramal que efetuou a
última ligação.
A valorização da ligação é feita de acordo com a duração e com a rota utilizada, cada
chamada contém o seu valor de tarifa, estas infomações são usadas no algorítmo para
calcular o total gasto pelo ramal.
O processo de envio das informações coletados em duas fases: abrir a conexão com a
porta do módulo de controle (1001), por meio do aplicativo desenvolvido denominado
simple_server e envio, propriamente dito, para o endereço IP do módulo, por meio do
aplicativo simple_client.
O Envia_LCD, forma quatro strings com as iformações a respeito: da duração da última
chamada, do valor dessa chamada, da quantidade de ligações realizadas pelo ramal e do
valor total das tarifas. O aplicativo busca o endereço IP do módulo na tabela dispramal,
de acordo com o ramal utilizado, pois cada ramal possuí um disposistivo.
O Envia_LCD executada a chamada ao simple_server e quando executa a chamada ao
simple_client envia as informações coletadas, inclusive o IP do módulo.
O simple_client atribui no início das strings caracteres para impressão do cabeçalho no
display: caracter “_ “ correspondente ao cabeçalho “Dura.:”, caracter “>”correspondente
ao cabeçalho “Tari.:”, o caracter “-“correspondente ao cabeçalho “QLig.:” e o caracter
“<” correspondente ao cabeçalho “Vtot.:”. Estes caracteres são necessários para o
tratamento do firmware.
Em seguida o simple_client envia as informações com os caracteres ao módulo
correspondente ao endereço IP.
Os programas foram desenvolvidos em C, compilados em gcc e executados por
intermédio de makefile. Eles estão preparados para utilização de sockets e transportam os
dados via o protocolo TCP.
77
4.3.2 -Módulo de Conversão Ethernet/Serial
O módulo de conversão Ethernet/Serial recebe as informações por TCP-IP e converte
para serial para impressão no display. Este módulo tem a função de reset da impressão do
display As configurações de rede são gerenciadas por um software do fabricante,
mostrado na Figura 44.
FIGURA 44 – TELA PARA AUTERAÇÃO DOS PARÂMETROS DO MÓDULO
4.3.3 -Módulo de controle e display
O módulo de controle é a principal parte do hardware, ele faz o tratamento das
informações do servidor PBX-IP enviadas para o hardware.
O módulo é composto por uma placa de circuito impresso, alimentada por 5 volts, contém
um converso TTL/R232 (MAX232), um crital de 20MHz, resitores, capacitores,
regulador de função (LM78L05), conector serial e microcontroaldor PIC 16F877A.
O microncontrolador recebe as informações da entrada serial por meio da interação com o
MAX232, que converte o sinal da porta serial em TTL.
78
FIGURA 45 – ESQUEMÁTICO DA PLACA DO MÓDULO DE CONTROLE
A Figura 45 mostra o esquemático projetado para a placa do módulo de controle, com
detalhes das trilhas criadas e da pinagem para integração dos componentes.
A interface de comunicação entre o display e o módulo de controle é realizada entre o
microcontrolador e os pinos de habilitação e de dados do display LCD. Conforme ilustara
o esquema elétrico mostrado na Figura 46
RA0/AN02
RA1/AN13
RA2/AN2/VREF-4
RA4/T0CKI6
RA5/AN4/SS7
RE0/AN5/RD8
RE1/AN6/WR9
RE2/AN7/CS10
OSC1/CLKIN13
OSC2/CLKOUT14
RC1/T1OSI/CCP216
RC2/CCP117
RC3/SCK/SCL 18
RD0/PSP019
RD1/PSP120
RB7/PGD40
RB6/PGC 39RB5 38RB4
37RB3/PGM
36RB2
35RB1
34RB0/INT
33
RD7/PSP730
RD6/PSP629
RD5/PSP528
RD4/PSP4 27RD3/PSP3 22RD2/PSP2 21
RC7/RX/DT26
RC6/TX/CK25
RC5/SDO 24RC4/SDI/SDA 23
RA3/AN3/VREF+5
RC0/T1OSO/T1CKI15
MCLR/Vpp/THV1
U1
PIC16F877
R1(2)
X120000000
C1
15p
C2
15p
R1
10k
C3
10u
D7
14
D6
13
D5
12
D4
11
D3
10
D2
9D1
8D0
7
E6
RW
5RS
4
VSS
1
VDD
2
VEE
3
LM041L
RXD
RTS
TXD
CTS
FIGURA 46 – ESQUEMA ELÉTRICO DO MÓDULO DE CONTROLE E DISPLAY
79
Na Figura 46 é mostrado a comunicação direta entre o microcontrolador e display. Os
pinos utilizados são referentes a transmissão Rx e Tx, habilitação das ações e envio de
dados. O restante dos componentes são usados para regular a alimentação e freqüência,
no caso do cristal 20MHz
4.4 -Firmwares
O firmware foi desenvolvido em C e compilado no MPLAB. O código está alocado no
microcontrolador e é ativado sempre que uma interrupção for realizada. Sua função é
tratar as informações recebidas pelo módulo tarifador e imprimi-las no display.
A Figura 47 mostra o trecho do firmware no qual são executados os comandos para
tratamento a distribuição das informações no display. O case é realizado a partir do
primeiro caracter da string.
Estes caracteres “chaves” são incluídos na informação pelo simple_client, aplicativo
executado pelo Envia_LCD.
80
FIGURA 47 – TRECHO DO FIRMWARE
switch (uReceive) case 0x12: if (fgetc(PC) == 0x34 & fgetc(PC) == 0x56 & fgetc(PC) ==0x78 & fgetc(PC) == 0x90) reset_cpu(); // Reserar CPU Remotamente break; case ':': fgets(string,PC); printf("%s",string); break; case '_': i = 0; a=0; lcd_putc("\f"); fgets(StrDados,PC); lcd_putc("Dura.: "); i = strlen(StrDados); while(a < i) caractere = StrDados[a]; a = a + 1; lcd_putc(caractere); ///led = !led; delay_ms(2); /// output_bit (pin_a5, led); caractere = StrDados[0]; lcd_putc("\n"); break; case '>': i = 0; a=0; fgets(StrDados,PC); lcd_putc("Tari.: "); i = strlen(StrDados); while(a < i) caractere = StrDados[a]; a = a + 1; lcd_putc(caractere); //led = !led; delay_ms(2); //// output_bit (pin_a5, led); lcd_putc("\n"); lcd_putc("\b\b\b\b"); break; case '-': i = 0; a=0; fgets(StrDados,PC); lcd_putc("QLig.: "); i = strlen(StrDados); while(a < i) caractere = StrDados[a]; a = a + 1; lcd_putc(caractere); //led/ = !led; delay_ms(2); //output_bit (pin_a5, led); lcd_putc("\n"); lcd_putc("\b\b\b\b"); break; case '<': i = 0; a=0; fgets(StrDados,PC); lcd_putc("VTot.: "); i = strlen(StrDados); while(a < i) caractere = StrDados[a]; a = a + 1; lcd_putc(caractere); // led = !led; delay_ms(2); // output_bit (pin_a5, led); lcd_putc("\n"); lcd_putc("\b\b\b\b"); break;
81
CAPÍTULO 5 - VALIDAÇÃO E RESULTADOS
A validação do projeto foi realizada apartir de dois cenários: ligações locais e
interurbanas, ambos com ligações realizadas para telefones fixos e móveis e com origem
da cidade de Curitiba-PR.
TABELA 7 – CENÁRIO DE TESTES REALIZADOS PARA VALIDAÇÃO DO PROJETO
CENÁRIO CLASSIFICAÇÃO DURAÇÃO
1 – Local Fixo 59 segundos 1 – Local Fixo 1 minuto 1 – Local Fixo 47 segundos 1 – Local Móvel 40 segundos 2 – DDD Fixo 57 segundos 2 – DDD Móvel 46 segundos
FONTE: AUTOR (2007)
A tabela 7 mostra a constituição dos cenários criados para realização dos testes. O cenário
1 foi formado por ligações locais: três ligações locais para números fixos e uma ligação
local para telefone móvel. As ligações para os números fixos duraram respectivamente 59
segundos, 1 minuto e 47 segundos e para o telefone móvel 40 segundos.
O cenário 2 foi formado por ligações interurbanas para cidade de São Paulo (DDD 11).
Uma ligação para um número fixo e uma ligação para um número de telefone móvel. Os
tempos de duração de cada ligação foram respectivamente de 57 segundos e 46 segundos.
Neste cenário as ligações foram realizadas sem o código de operadora, uma vez que a
rota de menor custo deverá ou não atribuí-lo, de acordo com o tronco utilizado.
TABELA 8 – RESULTADOS DA VALIDAÇÃO DAS ROTAS DE MENOR CUSTO
CENÁRIO TABELA ALL_RATES CONSOLE ASTERISK
1 – LOCAL Fixo: Tronco VoIP Celular: Tronco convencional
Fixo: Tronco VoIP Celular: Tronco convencional
2- DDD
Fixo: Tronco VoIP Celular: Tronco convencional da operadora 23
Fixo: Tronco VoIP Celular: Tronco convencional, o número discado continha 023119(...)
FONTE: AUTOR (2007)
A Tabela 8 mostra o resultado dos testes realizados, para validação da rota de menor
custo. Esta tabela mostra a comparação dos valores das tarifas praticadas pelas
82
operadoras de telefonia convencional e IP, a partir da tabela ALL_RATES, e as
informações geradas no console do Asterisk durante as ligações efetuadas.
A Tabela 8 mostra que a tabela ALL_RATES indica a utilização do tronco VoIP para
ligações realizadas para telefones fixos (locais e interurbanos) e a utilização do tronco
convencional para ligações para telefones móveis (locais e interurbanos).
O console do Asterisk confirma a utilização das rotas de menor custo, mostrando os
mesmos troncos indicados na tabela ALL_RATES. O console confirmou, no caso da
ligação interurbana a utilização da operadora 23, uma vez que o número discado não
tinha estes dígitos.
TABELA 9 – RESULTADOS DOS TESTES DE VALIDAÇÃO DO MÓDULO DE CONTROLE
CENÁRIO CLASSIFICAÇÃO DURAÇÃO TARIFA TABELA ALL_RATES
MÓDULO TARIFADOR
1 – Local Fixo 59 0,14
Dura.: 0,983 Tari.: 0,14 Qlig.: 1 Vtot.: 0,14
1 – Local Fixo 60 0,14
Dura.: 1 Tari.: 0,14 Qlig.: 3 Vtot.: 0,98
1 – Local Fixo 47 0,14
Dura.: 0,783 Tari.: 0,14 Qlig.: 4 Vtot.: 1,12
1 – Local Móvel 40 0,7
Dura.: 0,666 Tari.: 0,7 Qlig.: 2 Vtot.: 0,84
2 – DDD Fixo 57 0,14
Dura.: 0,95 Tari.: 0,14 Qlig.: 5 Vtot.: 1,26
2 – DDD Móvel 46 0,7
Dura.:0,766 Tari.: 0,7 Qlig.: 6 Vtot.: 1,96
FONTE: AUTOR (2007)
A Tabela 9 mostra a comparação entre os valores de tarifas de menor custo indicadas a
partir da tabela ALL_RATES e o valor mostrado no display do Módulo Tarifador após as
ligações descritas acima.
Pode-se observar uma linearidade nos valores indicados pela tabela ALL_RATES e os
valores mostrados no Módulo Tarifador. Observa-se também que a cada ligação realizada
83
o acréscimo da quantidade ligações aumenta numa progressão de 1 e o valor total mostra
a soma de todas as ligações realizadas até o momento.
Uma coincidência foi observada, tanto nas ligações locais quanto nas interurbanas: os
valores de tarifas para fixo e móveis foram os mesmos, assim pode-se afirmar que
ligações interurbanas de menor custo tem o mesmo valor praticado nas ligações locais.
Estes testes validam o desenvolvimento do projeto uma vez que comprova-se o objetivo
proposto.
84
CAPÍTULO 6 - CONCLUSÃO
O projeto de gerenciamento de tecnologias de telecomunicações por meio de um PBX-IP,
foi composto pelo desenvolvimento de mecanismos de separação de rotas de menor
custo, de controle dos gastos com as ligações telefonicas e desenvolvimento de interface
WEB para manutenção do sistema. Todas estas aplicações sobre a estrutura da arquitetura
do software híbrido de telefonia: Asterisk, solução Linux para telefonia-IP.
Foi estudado para o desenvolvimento desse projeto literaturas a respeito de:
Telecomunicações, redes de computadores, VoIP, telefonia IP, redes de telefonia pública
comutada, Linux, banco de dados MySQL, conceitos de PABX, programação em Java
Script, Asterisk, arquitetura de microcontroladores PIC, funcionamento de display LCD,
comunicação em redes e envio de protocolos TCP/IP via sockets.
O Asterisk é um software formado por arquivos do tipo conf, cada ação é ativada e
configurada por meio de linhas de comandos contidas em cada arquivo específico para
aquela ação, o estudo dessas atividades utilizou maoir tempo na constituíção do projeto.
No entanto, o desenvolvimento não sofreu nenhum impacto considerável em razão das
dificuldades citadas , comprovando-se isto por meio dos testes de validação.
O desenvolvimento das Rotas de Menor Custo baseou-se nas tarifas praticadas por
operadoras de telefonia fixa e IP. A base do desenvolvimento desse mecaismo foi
realizada, primeiramente, por meio da integração oferecida pelo Asterisk e o Mysql, que
resulta na tabela de históricos de ligações efetuadas, CDR.
O controle dos gastos das ligações é apoiado pelo dispositivo desenvolvido denominado
Módulo Tarifador. Ele mostra as informações: de duração e tarifagem de uma ligação,
quantidade e valor total das ligações realizadas no período de 20 dias.
Para facilitar a manutenção do PBX-IP, uma vez que o Asterisk dispõe de um ambiente
amigável, foram desenvolvidas interfaces WEB, compostas por três páginas. Uma para
autenticar o usuário homologado para manutenção, uma para realizar inclusão e exclusão
de ramais e outra para realizar a inclusão e a manutenção de troncos de telefonia fixa e
85
IP. Com as interfaces espera-se que não haja gastos execívos com pessoal especializado,
já que o próprio usuário poderá executar estas funções.
O desenvolvimento realizado neste projeto contribuiu com a exploração da Telefonia-IP,
que oferece recursos integrados à Internet e disponibiliza serviços de alta qualidade. O
projeto explorou recursos para redução de custos e controle de tarifas telefonicas.
A vantagem oferecida pelo sistema desenvolvido foi a atribuição automática de rotas de
menor custo ao plano de discagem do Asterisk e o módulo de tarifagem das ligações
realizadas pelos usuários nos ramais da central.
O sistema pode ser utilizado por empresas de diversos segmentos e de todos os portes e
por usuários residenciais, para gerenciamento dos serviços de telefônia. O diferencial
desse sistema é que ele oferece no ato da discagem de uma ligação telefônica a rota de
menor custo e isto acarreta na redução dos valores gastos nas contas. O Módulo
Tarifador, possibilita ao usuário monitorar a utilização dos telefones por meio da
demonstração do tempo e do valor gasto pelo usuário.
A validação do projeto ocorreu a partir de dois cenários de ligações efetuadas: ligações
locais e ligações interurbanas para cidade de São Paulo-SP (os teste foram originados da
cidade de Curitiba-PR), ambas com ligações para números de telefones fixos e móveis.
Os testes tiveram como principio a comparação dos valores das tarifas praticadas pelas
operadoras de telefonia convencional e VoIP com o tronco utilizado no momento da
ligação, mostrados no console do Asterisk.
Os testes permitiram validar, também, o Módulo Tarifador que mostrou em seu display
os valores praticados pelas operadoras utlizadas, convertidos nos valores reais, de acordo
com o tempo de duração da ligação.
Os resultados foram comprovaram o uso das Rotas de Menor Custo e a função do
Módulo Tarifador validando o objetivo proposto neste projeto .
Dessa forma, o projeto cumpriu com o objetivo esperado e disponibiliza um conjunto de
ferramentas que podem ser usadas para redução e controle das tarifas telefônicas, sem
que haja acréscimo nos recursos financeiros e, ainda, aumentando a qualidade dos
serviços oferecidos pelo atual cenário de redes e telecomunicações.
86
Melhorias propostas para o o sistema são: aquisição automática da tabela de tarifas em
sites de empresas especializadas na coleta dessa informações (esta atividade não foi
agregada ao projeto pois o serviço ofertado não é gratuíto); ativar os serviços do Asterisk
como conferência e música em espera e compactar o hardware do Módulo de Controle de
forma a ocupar um menor espaço físico, emissão de relatórios, dos gastos através da
interface Web,integração com outras plataformas de comunicação como sistemas de
mensagens instantaneas , mensagens SMS (mensagem para celular) e servidores de
e.mail. Estes recursos agregados contribuiriam para melhorar ainda mais os custos
O projeto é viável economicamente, pois o valor investido na implantação é absorvido
em um curto espaço de tempo pelo benefício originado pela redução nos custos com
tarifas telefônicas.
87
CAPÍTULO 7 - BIBLIOGRAFIA
<http://www.produtronica.pucpr.br/publico/ppgeps/conteudo/dissertacoes/pdf/JonerlamCarvalho.pdf> Acesso em 27/03/07 - 03h00
<http://www.rogercom.com/PortaSerial/ControleAcesso/Controle.htm > Acesso em 31/10/2007 - 04h16
Akiyama. Disponível em: <http://www.akiyama.com.br/tibbo.asp> Acesso em - 31/10/2007 - 23h23
CARVALHO, Jonerlam. Disponível em:
DENVER, Allen: Comunicação Serial: Disponível em: <http://www.cpdee.ufmg.br/~seixas/PáginaSDA/Download/DownloadFiles/Serial.PDF> Acesso em 25/10/2007 – 22h55
Disponível em: <http://www.asteriskbrasil.org/tiki/tiki-index.php?>. Acesso em 28/03/07.
Engecomp. Disponível em: <http://www.engcomp.ufrn.br/sinec/view/arquivos/cap1a.pdf> Acesso - 31/10/2007 - 02h48
MORIMOTO, Carlos E. Disponível em: <http://www.guiadohardware.net/tutoriais/tutoriais-bios/> Acesso em 31/10/2007 - 08h09
ROGERIO, Antonio Messias. Disponível em:
SATO, A. M. Tutoriais Banda larga e VOIP. Disponível em: <http://www.teleco.com.br/tutoriais/tutorialpabx/default.asp >. Acesso em 28/03/07.
ANSELMO, Fernando. PHP 4 e MySQL : maior, melhor e sem cortes. Florianópolis: Visual Books, 2002.
COMER, Douglas E. Interligação em rede com TCP/IP, Volume 1. Rio de Janeiro: Editora Campus, 2001.
COMER, Douglas E; STEVENS, David L. Interligação em rede com TCP/IP . Rio de Janeiro: Campus, 1999
DANTAS, M. Tecnologias de Redes de Comunicação e Computadores. 1. ed. Rio de Janeiro: Axcel Books, 2002.
Escola regional de redes de computadores, Anais da 4ª Escola Regional de Redes de Computadores. Passo Fundo, 2006.
HART, Diogo Leidens. Estudo e desenvolvimento de solução de voz sobre IP (VOIP). Baseada em software livre
HAYKIN, Simon S.; VAN VEEN, Barry. Sinais e sistemas . Porto Alegre: Bookman, 2001.
88
HERSENT, OLIVER; GUIDE, DAVID; PETIT, JEAN-PIERRE. Telefonia IP – Comunicação Multimídia baseada em pacote, 1ª ed. São Paulo: Adilson Wesley, 2002.
HILTON, Craig; WILLIS, Jeff. Building database : applications on the web using PHP3. Addison-Wesley, 2001.
IFIP WORLD COMPUTER CONGRESS. Design and analysis of distributed embedded systems : IFIP 17th World Computer Congress : TC10 stream on distributed and parllel embedded systems (DIPES 2002), August 25-29, 2002, Montréal, Québec, Canada, 2002.
KOHIYAMA, Fred Akira. Análise estrutural de torres de telefonia celular . Curitiba, 2002.
KUROSE, James F; ROSS, Keith W; MARQUES, Arlete Simille. Redes de computadores e a internet : uma nova abordagem. São Paulo: Addison Wesley, 2003.
MELONI, Julie C. Fundamentos de PHP . Rio de Janeiro: Ciência Moderna, 2000.
NEGRINO, Tom; SMITH, Dory. JavaScript Para a World Wide Web . Rio de Janeiro: Campus, 2000
NICOLOSI, Denys Emilio Campeou. Microcontrolador São Paulo: Erica, 2000.
NICOLOSI, Denys Emilio Campeou. Microcontrolador São Paulo: Erica, 2001.
NIEDERAUER, Juliano. Desenvolvendo Websites com PHP 4 . São Paulo: Novatec, 2001.
PAIXÃO, Renato; HONDA, Renato. Processadores INTEL . São Paulo: Erica, 1999.
PEREIRA, Fábio. Microcontroladores PIC : técnicas avançadas. 2. ed. São Paulo: Erica, 2002.
SPENCER, M.; ALLISON, M.; RHODES, C. MAHLER, PAUL. The Asterisk Handbook. VoIP Telephony with Asterisk, 2003
STEVENS, W. Richard. Unix Network programming : net working APIs : sockets and XTI. 2. nd.ed. -. Upper Saddle River, NJ: Prentice Hall PTR, 1998.
TANENBAUM, ANDREW S. Redes de Computadores. 4ª ed. São Paulo: Campus, 2003.
TITTEL, Ed; GAITHER, Mark. 60 Minutos para aprender Java . São Paulo: 1996.
TORRES, Gabriel. Redes de Computadores – Curso Completo. 1ª ed. Rio de Janeiro: Axcel Books do Brasil, 2001.
WERNECK, Marcelo Martins. Transdutores e interfaces . Rio de Janeiro: LTC, 1996.
89
APÊNDICE A
90
APENDICE B
