1 · Web viewNa Figura 12, o CA pede constantemente ao gateway R1 que verifique o terminal PABX, com o objetivo de encontrar um evento, como uma requisição de chamada. Então, R1

MURILO CÉSAR DRUMOND

MURILO PACHECO DE ALENCAR MAGALHÃES

VITOR PAULINO XAVIER DE SOUSA

VoIP-DM

VoIP PARA DISPOSITIVOS MÓVEIS

Monografia apresentada à UCB como requisito parcial para conclusão do curso de Bacharelado em Ciência da Computação. Orientadora: Profª. Flávia Estélia Silva Coelho.

BRASÍLIA, DF

2007

Resumo

A comunicação representa a disseminação do conhecimento entre indivíduos. Da forma mais direta possível, ela pode ser representada verbalmente ou de modo não-verbal através de gestos, por exemplo. De forma remota, cartas, telefonia e Internet são seus maiores representantes. É, especialmente nestes dois últimos meios de comunicação citados, que o projeto VoIP para Dispositivos Móveis estará centrado.

O termo VoIP refere-se à utilização de telefonia sobre redes baseadas em Internet TCP/IP. É proposto neste trabalho, o desenvolvimento de uma arquitetura de comunicação VoIP entre celulares,.utilizando-se do Software Livre Asterisk como responsável pela autenticação e alocação de IPs temporários para usuários.

Aplicar à telefonia celular, a tecnologia VoIP e soluções em Software Livre, representa acreditar na evolução natural de um padrão de telefonia, que atualmente se encontra deficitário e apresenta custos que não representam seus serviços. É objetivo deste trabalho, inspirar novos pesquisadores, sejam da área de computação, ou de qualquer área associada, a sempre buscar novos meios de difundir a tecnologia de comunicação.

Foi implementada uma aplicação cliente denominada SoftPhone como solução para comunicação VoIP. Os resultados contemplaram a troca de dados de forma full-duplex entre os dois lados de uma chamada telefônica, além do alcance da autenticação por meio do Asterisk.

Palavras-chave:

Internet; Telefonia; Dispositivos Móveis; VoIP; Asterisk;

2

Abstract

The communication represents the dissemination of the knowledge among individuals. In the straightest possible form, it can be represented verbally or of not-verbal way through gestures or a look, by example. In a remote form, letters, telephone technology and Internet are its bigger representatives. It’s specially in these two last means of communication cited, the project VoIP for Mobile Devices will be centered.

The term VoIP is regarding to service relative to the utilization of telephone technology over a platform of Internet. It’s proposed on this final Project, the development of a VoIP communication between mobile devices, using the Free Software Asterisk as the responsible for the users authentication and temporary IP allocation.

Applying to the cellular telephone, the VoIP technology and solutions in free software represents to believe in the natural evolution of a standard of telephone technology that at present is found deficit and presents costs that do not represent its service. It is objective of this work to inspire news researchers, being of the area of computation, or any area associated, to always seek news means to diffuse the technology of communication.

It was implemented a client application named Softphone as a solution for VoIP communication. The solution also considered an exchange of data in the use of server PABX Asterisk 1.4.4, installed and configured with the data of the users who communicate and will be authenticated for the server. The results had contemplated the exchange of data in a full-duplex way between the two sides of a telephonic call, beyond the reach of the authentication by means of the Asterisk.

Keywords:

Internet; Telephone Technology; Mobile Devices; VoIP; Asterisk.

3

Sumário

4

1. Justificativa

1.1 Motivação

Buscando a investigação de uma solução não-convencional, direcionou-se esforços, inicialmente, para um trabalho capaz de abranger um domínio da computação, o qual apresentasse possibilidades de trabalhos inovadores, seja no contexto científico ou comercial, e que representasse uma alta expectativa mercadológica diante de sua potencialidade de uso. Após reflexões e discussões acerca de vantagens e, principalmente, desvantagens de cada área da computação, foi possível determinar que o posicionamento da pesquisa teria implicações científicas no domínio das redes computacionais.

Portanto, o tema proposto integra três áreas que representaram, especialmente nos últimos cinco anos, expressivo desenvolvimento tecnológico: Telefonia celular, VoIP e Software Livre. De modo particular, a telefonia celular é disposta como responsável pela integração de VoIP e Software Livre. Inicialmente, a idéia seria contemplar tanto telefonia fixa quanto a móvel. Mas, na indisponibilidade de equipamentos específicos de distribuição telefônica nas dependências da UCB (Universidade Católica de Brasília), optou-se por restringir a proposta ao domínio dos dispositivos móveis.

Em relação aos campos de estudo, a dificuldade se apresentou naturalmente com o desenvolvimento da pesquisa e do protótipo. Apesar de VoIP, Software Livre e telefonia celular representarem tecnologias de conhecimento comum, projetos envolvendo a integração entre estes, não são tão acessíveis. De certo, uma parcela considerável dos projetos existentes, neste contexto, apresenta características tão próprias de seu ambiente de uso, que se tornaram meramente figurativos no momento da busca por informações complementares sobre a utilização de algum padrão. Não foram encontrados projetos que envolvessem a integração das três áreas, tais que pudessem ser caracterizados como fontes de consulta em caso de dúvidas ou anseios por novas idéias, trabalhos futuros e alternativas durante o desenvolvimento do trabalho.

Em se tratando dos benefícios que estimularam a escolha do tema de trabalho, além daqueles já citados, a relação de custo-benefício do emprego da tecnologia VoIP no cotidiano, apresenta-se como um destaque. O uso de alternativas VoIP baseadas em Software Livre praticamente nulificaria o custo de cobrança em operações telefônicas. Do mesmo modo, Software Livre denota uma alternativa viável aos dispendiosos contratos de licença impostos por aquelas empresas que dominam a distribuição de software proprietário. O aparelho celular, por sua vez, tende a ser um objeto de uso cada vez mais comum, e a ter seu preço médio consideravelmente reduzido em proporção ao que pode oferecer, segundo argumenta (VOIP Overview, 2006).

De forma geral, este trabalho consiste no desenvolvimento de uma aplicação cliente-servidor, que será funcional sobre uma arquitetura proposta. Esta aplicação, desenvolvida em JAVA e disposta sobre o protocolo SIP, pode ser executada em aparelhos celulares com suporte à API JSR 180 for SIP, provendo assim, uma interface para uma comunicação VoIP entre aparelhos celulares. A arquitetura abrange a recepção da voz pela linha telefônica em um terminal (celular), sua conversão em formato digital e envio para a rede até outro terminal (celular), havendo ainda, um processo de autenticação, na qual os usuários que estiverem requisitando uma chamada, terão seus endereços IP “temporários” dos celulares registrados.

A importância deste trabalho reflete-se na crescente perspectiva de uso da tecnologia VoIP, como uma possibilidade de comunicação em que se paga pelo que se utiliza de forma efetiva, e não mais proporcionalmente ao tempo de uso da conexão (VOIP Overview, 2006). Cada vez mais, um número maior de empresas investe em VoIP, conforme pode ser comprovado por incentivos de empresas influentes no mercado como Terra (Terra VOIP, 2006) e Brasil Telecom (BrTelecom Voipzone, 2007). De acordo com (VoIP Center #1, 2007), existem cerca de 1,2 milhões de usuários no Brasil, e ainda neste ano, 8% dos telefonemas no país devem ser por VoIP. A mesma fonte também revela que muitos já são usuários sem saber, uma vez que já existem alguns orelhões com esta tecnologia. De acordo com (VoIP Center #2, 2007), a franquia Hellou Global Phone é, atualmente, a única franquia de VoIP do Brasil.

Na área acadêmica, há destaque para os projetos da UFRJ (Universidade Federal do Rio de Janeiro) e UFSC (Universidade Federal de Santa Catarina). O primeiro projeto foi desenvolvido pelo Núcleo de Computação Eletrônica da UFRJ e é chamado de fone@RNP. Neste projeto, o serviço é disponibilizado a qualquer instituição de pesquisa que possua filiação à RNP (http://www.rnp.br/). De acordo com a especificação de (VoIP UFRJ), a instituição deve apresentar conectividade à RNP2, instalar um gateway VoIP para conexão do PBX (ou de sua rede de telefonia privada) à rede de dados interna, e ao serviço fone@RNP. Além disso, a instituição deve operar um servidor para registro de usuários e coleta de estatísticas de uso. Já na UFSC, o projeto apresenta disposição similar ao projeto realizado pela UFRJ, sendo também um projeto da RNP, visando utilizar o backbone da rede UFSC e da rede catarinense de Ciência e Tecnologia (VoIP UFSC). Ambos os projetos são voltados, em princípio, para a área de telefonia convencional, não tendo sido encontradas referências que pudessem explicitar seu interesse na aplicação de VoIP para uma arquitetura de dispositivos móveis e Software Livre.

1.2 Potenciais Usuários

A solução será implementada visando principalmente os usuários que demonstrem interesse pela realização de ligações VoIP através de dispositivos móveis. A pesquisa pode servir de base a desenvolvedores interessados na busca por novas soluções VoIP. Da mesma forma, empresas da área de telefonia podem adaptar o projeto para uma nova realidade, seja no incentivo ao VoIP através do desenvolvimento de um maior número de modelos que suportem este formato de comunicação, seja no incentivo de novos projetos de pesquisa visando ampliar o número de desenvolvedores da tecnologia.

1.3. Objetivos

1.3.1 Objetivos Gerais

Como objetivo geral, destaca-se o desenvolvimento de uma aplicação cliente-servidor de domínio VoIP para dispositivos móveis, usufruindo dos recursos e serviços providos por uma arquitetura proposta visando a integração das tecnologias de Telefonia Celular, Software Livre e VoIP.

1.3.2 Objetivos Específicos

Entre os objetivos específicos, consideram-se os seguintes:

Levantar o estado da arte em VoIP, ferramentas baseadas em software livre para comunicação VoIP e desenvolvimento para dispositivos móveis, em particular, para celulares;

Compreender as nuances particulares de soluções para comunicação VoIP, em software livre;

Propor uma arquitetura para a comunicação VoIP entre dispositivos móveis (celulares);

Desenvolver uma aplicação para dispositivos móveis, a ser executada considerando a arquitetura proposta;

Promover a comunicação entre dispositivos móveis (celulares) usando a infra-estrutura desenvolvida no trabalho (arquitetura e aplicação);

Analisar o comportamento da arquitetura frente à execução da aplicação a ser desenvolvida.

1.4 Cronograma

As seguintes etapas podem ser definidas durante o desenvolvimento da proposta de pesquisa:

Etapa 1 – Pesquisa Bibliográfica

O projeto teve seu início efetivo durante o mês de Setembro/2006. Após a elaboração da proposta, a orientação inicial se deu no sentido de que os primeiros meses seriam dedicados a uma extensiva pesquisa bibliográfica. O escopo desta pesquisa procurou envolver todos os aspectos atuais e eventuais perspectivas em relação à VoIP, ferramentas com conceito de software livre, que pudessem ser utilizadas neste formato de comunicação, e características da telefonia móvel e convencional. Esta pesquisa foi exposta nos capítulo 2 e 3 – capítulos concluídos em Março/2007

Etapa 2 – Proposta de Arquitetura

A partir de Novembro/2006, foram elaborados os primeiros esboços do modelo de arquitetura para comunicação VoIP. Inicialmente, a proposta também incluiu, além da telefonia móvel (celulares), a telefonia convencional, o que foi excluído ao longo dos meses. A proposta em si, foi concluída em Março/2007, e sua exposição no capítulo 4 teve sua edição finalizada em Junho/2007.

Etapa 3 – Montagem de Laboratório

Iniciada em Janeiro/2007. Ambientes próprios, como desktops e notebooks pessoais foram os meios utilizados para elaboração da solução. Houve também a disponibilização, por parte da UCB, de 2 HDs móveis, que foram utilizados na etapa de testes.

Etapa 4 – Desenvolvimento da Aplicação

Teve início em Janeiro/2007 e sua conclusão está prevista para Junho/2007.

Etapa Final – Defesa de Projeto

A defesa deste projeto final será no dia 27 de Junho de 2007.

2. Voz sobre IP

2.1 Introdução

O termo VoIP é tratado quando são explicitados serviços relativos à utilização de telefonia sobre uma plataforma baseada na Internet. No contexto, pretende-se atenuar as limitações de sua tecnologia inspiradora – a telefonia de rede pública. Altas taxas de cobrança por parte de provedores e a baixa qualidade de serviço podem ser considerados fatores de estímulo ao desenvolvimento do VoIP. Se há qualidade na conexão da Internet, existe a possibilidade de se buscar um serviço telefônico alternativo, evitando a dependência completa da companhia telefônica local. Como toda tecnologia em desenvolvimento, VoIP ainda não apresenta suas fronteiras de utilização bem definidas pelos fornecedores atuais.

2.1.1 Funcionamento Geral do VoIP

O funcionamento geral do VoIP se dá através do envio de informação de voz em formato digital dentro de pacotes de dados, ao invés do tradicional protocolo de comutação de circuitos utilizado há décadas pelas companhias telefônicas (Webinsider, 2004).

Uma de suas maiores vantagens é a redução dos custos de utilização dos serviços de telefonia comum, principalmente no que se refere a ambientes corporativos. Diversas empresas vêm oferecendo voz sobre IP corporativo; empresas com filiais em qualquer parte do mundo já estão falando entre si, a custos que podem ser nulos. Ainda de acordo com (Webinsider, 2004), também podem ser citadas empresas que oferecem VoIP para efetuar ligações para telefones fixos e móveis, envio de FAX e até vigilância remota.

É utilizado o TCP/IP para a transmissão da voz em pacotes sobre uma rede IP. Isto se dá, através do uso de protocolos VoIP, sendo que a comunicação por voz pode ser atingida seja qual for a rede IP do meio, podendo ser tanto Internet ou Intranets. Dentre os protocolos utilizados são encontrados, por exemplo SIP, H323, MGCP e MeGaCo para sinalização; RTCP, RTP para padronização do formato e qualidade de transmissão de pacotes de áudio e de vídeo; H261, H263 para codificação e decodificação de vídeos; G711, G729 para compressão da voz; outros como COPS, RTSP, SCTP, SIGTRAN e TRIP para outras funcionalidades. Todos os referidos, e outros protocolos atualmente utilizados para VoIP, podem ter suas definições encontradas em (Network Dictionary, 2007).

Segundo (What is VOIP, 2005), o primeiro passo é a digitalização da voz, ou seja, sua conversão para bits. Este processo envolve o particionamento do som analógico da voz em bits de dados, que são associados a um valor numérico. Uma vez digitalizados, os dados podem ser facilmente comprimidos. Os dados digitalizados e comprimidos são separados em pacotes de 1500 bytes, facilitando a transmissão pela Internet. Tais pacotes possuem informações sobre sua origem, destino, um timestamp (permite que o pacote seja reconstruído na ordem correta, em caso de erro), além dos dados de voz. No momento em que os pacotes chegam em seu destino, eles são reagrupados seguindo uma ordem específica, e convertidos para som analógico, para que o receptor possa entender o que está sendo dito. Segue na Figura 1, uma exemplificação do fluxo VoIP.

Figura 1 – Fluxo VoIP

De acordo com (Ejnisman, 2006), a tecnologia VoIP no Brasil ainda enfrenta dificuldades quanto à legislação e taxas de cobrança de serviços, questões estas que serão discutidas no tópico 2.1.4. Entretanto, a utilização do VoIP é cada vez mais freqüente, forçando as empresas de telefonia a reduzirem taxas e promoverem bônus, de modo a incentivar a utilização da telefonia comum e não perder mercado.

Nas próximas seções, serão discutidos alguns pontos considerados relevantes em termos de tecnologia VoIP.

2.1.2 Menor Custo

É fato que a grande maioria dos serviços de telefonia tradicional, seja no Brasil ou no resto do mundo, apresentam taxas de cobrança elevadas, e são providos por um pequeno número de empresas. Como essa associação entre o uso de VoIP e entidades dominantes ainda está um pouco dispersa, na prática, os preços desta telefonia garantem o retorno de investimentos àqueles que vêm explorando seus serviços. Outro fator que justificaria o menor custo está relacionado ao uso de uma única rede para trafegar voz e dados. Neste caso, a teoria prevê o uso de uma capacidade sub-utilizada da rede, que pode ser aproveitada pelo VoIP, sem custos adicionais. Apontando para um baixo custo extremo, chamadas telefônicas via VoIP podem ser realizadas de forma gratuita, e se de forma local isso pode ser de grande valia, quando se trata o tópico no ponto de vista de chamadas internacionais, a justificativa também é mantida. (VoIP Info, 2006).

Segundo (VOIP Overview, 2006), quando se usa uma rede PSTN, paga-se o serviço proporcionalmente ao tempo usado da linha para a companhia que a gerencia. Além disso, o sistema não é adequado para se falar com mais de uma pessoa por vez. Na tecnologia VoIP, pode-se falar na linha sem preocupação com custos, com quantas pessoas sua largura de banda permitir.

2.1.3 Complexidade da Tecnologia

Alguns tópicos devem ser considerados em relação ao uso otimizado da transmissão de voz e dados sobre uma mesma rede. Segue uma lista, de acordo com (Hersent, Guide, Petit, 2002, prefácio XVIII e XIX), a respeito de algumas das questões:

a) Como deve ser feita a compressão e o empacotamento de voz?

b) Como minimizar a existência de eco?

c) As desvantagens do protocolo IP (Internet Protocol) em relação às aplicações em tempo real: atraso, jitter e perda de pacotes. Uso de estratégias para superar tais limitações: buffers, redundância, timestamps e serviços diferenciados;

d) Características do tráfego de voz em pacote e como ele coabita com o fluxo de dados que não são em tempo real;

e) Protocolos de telefonia IP a serem adotados;

f) A transmissão de dados dentro da banda na rede telefônica;

g) Protocolos de sinalização telefônica e as seqüências de conexão (chamadas normais, chamadas para serviços inteligentes, chamadas enquanto a rede está sobrecarregada).

Conforme os tópicos referenciados, fica evidente que a tecnologia utilizada na telefonia IP, tem uma complexidade peculiar as demais tecnologias de transmissão. Comparada à transmissão por streaming, por exemplo, a latência do VoIP deve permanecer muito baixa, ao passo de que a latência daquele pode ser compensada com o uso de buffers de alta capacidade. VoIP é uma área que trouxe consigo conhecimentos especializados diferenciados nas áreas de redes, fala e telefonia (Hersent, Guide, Petit, 2002, prefácio XVIII e XIX).

2.1.4 Desafios Regulatórios

Segundo (Ejnisman, 2006), um dos desafios para a consolidação definitiva do VoIP no mercado é a questão regulatória. Algo já foi discutido no sentido de consideração da mesma, sendo que opções como interpretá-la como serviço de telecomunicações, como um serviço de valor adicionado, ou uma tecnologia, vêm sendo consideradas. De acordo com a Lei Geral de Telecomunicações (LGT), o serviço de telecomunicações é o conjunto de atividades que consiste na transmissão, emissão ou recepção, por fio, radio eletricidade, meios ópticos ou qualquer outro processo eletromagnético, de símbolos, caracteres, sinais, escritos, imagens, sons ou informações de qualquer natureza, tudo que seja caracterizado como oferta de telecomunicações. Ainda de acordo com (Ejnisman, 2006), a LGT também estabeleceu que um serviço de valor adicionado não é serviço de telecomunicações, disponibilizando novas utilidades relacionadas ao acesso, armazenamento, movimentação ou recuperação de informações a um serviço de telecomunicações que lhe dá suporte.

No mesmo artigo (Ejnisman, 2006), afirma-se que alguns especialistas defendem que a definição de serviços de telecomunicações não está vinculada a qualquer tecnologia ou a qualquer meio de prestação de serviços, mas sim ao conceito de transmissão, emissão ou recepção. Outros especialistas afirmam que pelo fato do oferecimento ser dado através de um protocolo aplicado à Internet, e sendo o serviço de acesso à Internet um serviço de valor adicionado, VoIP deveria do mesmo modo ser considerado um serviço de valor adicionado, não sujeito às regras impostas pela regulamentação de telecomunicações.

Ainda existe a questão da Agência Nacional de Telecomunicações (Anatel) que se posiciona, informalmente, no sentido de que VoIP é uma tecnologia cuja classificação não é relacionada a um novo serviço de telecomunicações, nem a serviços de Internet. Além disso, a Anatel estabelece que as empresas que ofertem VoIP, devem deter concessão,

permissão ou autorização para a prestação de Serviço Telefônico Fixo Comutado (STFC), Serviço de Comunicação Multimídia (SCM) ou Serviço Limitado Especializado (SLE).

O problema todo é que na prestação do SCM, não se permite a oferta de serviços com as características do STFC, em outras palavras, o encaminhamento de tráfego telefônico simultaneamente originado e encerrado nas redes de STFC. O SCM só é caracterizado quando iniciado ou terminado na rede pública. Este fato, e também a possibilidade de uma legislação menos ríspida, no sentido de que as autorizadoras do SCM não precisam atender aos compromissos de abrangência e atendimento estabelecidos aos prestadores de STFC, justificam um eventual aumento na busca por uma licença de SCM. Em mais um lado da questão regulatória, aparecem as empresas estrangeiras que estão ofertando VoIP à população brasileira, e, não se consideram obrigadas a cumprir as regras impostas pelo Governo Brasileiro.

Todo esse cenário, segundo (Ejnisman, 2006) incomoda principalmente aquelas prestadoras de serviços de telefonia fixa, que após o Leilão do Sistema Telebrás, são detidas pela iniciativa privada, e prestam o STFC sob forte tutela regulatória da Anatel. Tais concessionárias de STFC possuem compromissos de continuidade e universalização dos serviços, o que exige pesados investimentos complementares, a fim de assegurar à sociedade brasileira a adequada prestação dos serviços telefônicos. Independente da oferta ser realizada por empresas estrangeiras ou através de prestadoras de SCM, talvez o único meio para as concessionárias de STFC suportarem essa competição, deva ser se desdobrar para oferecer aos seus usuários descontos, novos planos e funcionalidades.

Acredita-se que a caracterização do que representa um serviço VoIP para eventual cobrança, se dará naturalmente, pois o crescimento da tecnologia não irá esperar uma demorada contemplação na busca por uma legislação justa para todos. Quanto mais tempo se prorroga a discussão do assunto, há maior chance de uma decisão ser dada de forma já defasada. Não há, entretanto, estimativa quanto ao tempo necessário, e de que forma o acordo será dado, mas é do interesse tanto dos prestadores de serviço de telefonia fixa quanto móvel, que a questão regulatória seja a mais breve e coerente possível.

2.2 Serviço Conversacional de VoIP

Denomina-se serviço conversacional de VoIP (MobileIP, 2005), aquele essencialmente destinado à comunicação de voz, de modo similar ao provido pelo Serviço Telefônico Fixo Comutado (STFC), com a participação de pelo menos um interlocutor ligado a uma rede IP. Dentro dessa classificação, incluem-se também os serviços suplementares típicos de telefonia, como áudio-conferência, retenção e redirecionamento de chamadas telefônicas, entre outros.

2.2.1 VoIP de Terminal IP para Terminal IP

Neste cenário, ilustrado na Figura 2, os interlocutores usam equipamentos dotados de codecs de áudio e interfaces ligadas a uma rede IP em suas conversações. Esses equipamentos — genericamente denominados terminais ou agentes de usuário — podem ser dos mais variados tipos. Por exemplo, pode ser empregado um software em um computador de propósito geral (tipicamente, um PC). Esse software usa APIs de captura e

reprodução de áudio e de comunicação via IP providas pelo sistema operacional para transmitir e receber amostras de áudio digitalizado empacotadas em datagramas IP (fluxos de áudio digital). Esse tipo de terminal é comumente chamado de softphone (Linux Magazine nº3). No lugar de PCs, pode-se usar equipamentos específicos, chamados telefones IP, que oferecem aos interlocutores uma interface similar a de telefones convencionais. Porém, telefones IP têm a capacidade de codificar e decodificar sinais de voz como fluxos de áudio digital, bem como transmitir e receber esses fluxos em uma rede IP, de modo análogo a softphones. Outro equipamento nessa linha são os adaptadores de telefones analógicos (Analog Telephone Adaptors – ATAs), brevemente descrito em (Terra VOIP, 2006). Um ATA permite conectar um telefone convencional a um PC ou diretamente a uma rede IP, sendo responsável pela conversão analógico-digital do sinal de voz.

Em tese, no que diz respeito a protocolos, um serviço conversacional de VoIP entre PCs não necessita de nada mais que o RTP/RTCP (ou similar) para lidar com a sincronização temporal (PUC-RIO, 2004) das amostras de áudio em um fluxo trafegando por uma rede IP. A sincronização temporal é o conceito do envio periódico e controlado de pacotes para os participantes da conexão, efetivando qualidade para a transmissão de dados em tempo real. Contudo, quando serviços de telefonia mais sofisticados são desejáveis — como redirecionamento de conversações ou áudio-conferências, por exemplo — torna-se necessário também que os terminais sejam dotados de protocolos de sinalização desses serviços. Em geral, esses protocolos de sinalização estabelecem chamadas ou sessões entre os terminais, sobre as quais possam ser oferecidos serviços variados. H.323 e SIP são os principais exemplos de padrões de sinalização VoIP entre terminais. A seguir, na Figura 2, é apresentada a comunicação utilizando ATA e softphone.

Figura 2 – Comunicação de voz de terminal IP para telefone através de ATA

2.2.1.1 Gateways de Gerência

Outro aspecto importante no estabelecimento de um serviço conversacional VoIP, ao estilo do STFC, é o oferecimento de funções que precisam estar disponíveis mesmo quando

terminais estão inoperantes. Em VoIP, um componente opcional chamado gateway de gerência (Tutorial Teleco IP, 2006) centraliza o oferecimento dessas funções, a saber:

Controle de acesso: um gateway de gerência permite controlar o estabelecimento de novas chamadas com base em limitações no número de chamadas simultâneas ou nos privilégios dos participantes. Um gateway de gerência pode ser usado também para manter informações sobre a tarifação do serviço;

Gerência de banda passante: administradores de rede podem controlar o uso de banda passante na rede pelo serviço de VoIP por intermédio do gateway de gerência, limitando o número de chamadas simultâneas, restringindo o estabelecimento de chamadas a certos horários ou usando mecanismos de provisão de QoS específicos (Magro, 2006);

Re-roteamento de chamadas (Promon5, 2005): um gateway de gerência pode re-rotear uma chamada com base na disponibilidade de banda passante, por exemplo. O re-roteamento pode ser usado também no desenvolvimento de serviços suplementares, tais como identificação universal (para terminais móveis), encaminhamento de chamadas e redirecionamento de mensagens de correio de voz.

2.2.2 VoIP de Terminal IP para Telefone

Conforme ilustra a Figura 3, a integração entre RTCCs e serviços conversacionais de VolP envolve o uso de dois componentes adicionais, chamados gateways de voz e gateways de sinalização.

Figura 3 – Comunicação de voz de terminal IP para telefone

2.2.2.1 Gateways de Voz

Os gateways de voz (Promon3, 2005) são responsáveis pelo repasse de fluxos de áudio entre a RTCC e a rede IP. Suas principais funções são a codificação e decodificação digital da voz (quando a transmissão de voz na RTCC é analógica), a transcodificação entre formatos digitais (quando a codificação usada em uma RTCC digital difere da usada na rede IP), o encerramento de chamadas telefônicas na RTCC e a transmissão e recepção de amostras de áudio digital encapsuladas em datagramas IP. Fundamentalmente, um gateway

de voz é visto pelos terminais na rede IP, como mais um terminal. Do ponto de vista da RTCC, um gateway de voz pode se apresentar sob as mais diversas formas, tais como:

Gateways residenciais: para interligação com interfaces analógicas tradicionais (RJ11) da RTPC. Esses tipos de gateways de voz apresentam-se na RTPC como um simples aparelho telefônico em uma linha de assinante;

Gateways de acesso: para interligação com CPCTs analógicas ou digitais. Tipicamente, gateways de acesso determinam certo número de linhas de assinantes que compõem um ou mais troncos na RTPC;

Gateways de trunking: para interligação com um grande número de troncos analógicos ou digitais da RTPC. Tipicamente, gateways de trunking se apresentam para a RTPC como uma central telefônica de trânsito;

Gateways de voz sobre ATM: para interligação com redes de voz sobre redes ATM;

É bastante comum o uso do termo mais geral gateway de mídia para se referir a gateways de voz, em especial no contexto de redes IP de multi-serviço.

2.2.2.2 Gateways de Sinalização

Os gateways de sinalização lidam fundamentalmente com o tratamento de pedidos de estabelecimento de chamadas partindo da RTCC e destinados a equipamentos na rede IP, e vice-versa. Entre as suas funções principais incluem-se:

Conversão da sinalização: traduz mensagens ou tons especiais de sinalização usados na RTCC, como DTMF, QSIG ou SS7 para a sinalização VolP;

Controle de gateways de mídia: efetua o controle da lógica de funcionamento dos gateways de mídia, requisitando a geração de sinais nas linhas telefônicas (tom de discagem, ocupado etc.) ou sendo notificado a respeito de eventos disparados nas mesmas (fone fora de gancho, número discado etc.), por exemplo.

Gateways de sinalização também são comumente chamados de controladores de gateway de mídia ou MGCs (Tutorial Teleco IP, 2006), agentes de chamada, ou ainda softswitches.

A Figura 3, mostrada anteriormente, representa a sinalização telefônica como sendo passada diretamente ao gateway de sinalização. Entretanto, na prática, é comum que durante o estabelecimento de uma chamada telefônica a sinalização (seja ela de canal comum ou dentro de faixa) passe pelas mesmas centrais telefônicas a serem usadas pela chamada. Isso se reflete nos cenários de integração com serviços de VoIP por meio do repasse indireto da sinalização telefônica ao gateway de sinalização, através do gateway de voz.

2.2.3 VoIP de Telefone para Telefone

Este cenário se apresenta como um caso misto dos dois cenários anteriores, em que gateways de voz e de sinalização permitem que RTCCs distintas utilizem redes IP para se

interligarem. Esse cenário ocorre tipicamente — mas não somente — em instituições e empresas que possuem instalações geograficamente dispersas, em que cada instalação possui uma CPCT própria, e a ligação entre as instalações é provida por uma rede IP. A Figura 4 ilustra tal cenário.

Figura 4 – Comunicação de voz de telefone para telefone usando redes IP

Na Figura, um gateway de sinalização é dedicado ao tratamento de pedidos de estabelecimento de chamadas provenientes de cada RTCC. Porém, esse tratamento pode ser feito por um único gateway de sinalização, eliminando a necessidade de sinalização VoIP entre gateways. Essa abordagem tem sua aplicabilidade limitada pelo número total de chamadas que o gateway de sinalização é capaz de tratar em tempo hábil.

2.3 Telefonia IP

A telefonia IP é uma modalidade de VoIP, na qual o serviço fornecido apresenta qualidade e funcionalidades, no mínimo, equivalentes aos serviços telefônicos convencionais. O usuário utiliza um telefone IP ou um adaptador IP para um telefone convencional e uma conexão IP de banda larga para se conectar à rede de telefonia IP. Adicionalmente, pode acessar o serviço utilizando um computador com um programa especial para esse fim.

A tecnologia VoIP, basicamente, converte sinal de voz (analógico) para o formato digital, utilizando tanto a infra-estrutura de dados, quanto a infra-estrutura analógica. A Telefonia IP, por sua vez, também faz uso de aparelhos telefônicos específicos e utiliza de maneira efetiva as redes computacionais (como a Internet). Tais dispositivos, geralmente, são sofisticados o suficiente para a transmissão de voz em tempo real e com qualidade, que muitas vezes supera a telefonia convencional. O fato mais interessante é que a Telefonia IP consegue essa eficiência sem necessitar de centrais telefônicas e ainda pode apresentar integração com outros serviços de dados, como vídeo e e-mail. (Alecrim, 2005)

A qualidade da conversação por meio da telefonia IP depende da velocidade do acesso à Internet, da qualidade do aparelho utilizado e da qualidade de serviço fornecida pela rede.

A lentidão no acesso pode causar a perda de pacotes de informação ou até atrasos na remessa de um computador a outro, o que, por sua vez, pode resultar em falha e baixa qualidade de som. A qualidade da voz é suscetível a perdas, atrasos e variações (jitter). A má qualidade do aparelho pode gerar eco e outros problemas na transmissão da voz. A qualidade da rede exerce importante influência no uso da telefonia IP no que diz respeito ao fluxo da rede, à carga de dados que trafega pela rede e à quantidade de banda disponível, bem como o uso desta banda.

Além de todos estes problemas, há o problema de acúmulo de amostras de dados de áudio (Figura 5) até que se atinja o tamanho do quadro que será comprimido pelo codec, o que leva tempo e atrasa a comunicação fim-a-fim. O fato é que ao invés das amostras serem comprimidas uma a uma, elas precisam ser acumuladas em quadros de tamanho fixo, para então haver o processamento do codec. Todo problema está na acumulação de amostras que leva um certo tempo. Mas, para reduzir os atrasos em uma rede ideal, não basta escolher um codec com comprimento de quadro pequeno. Diz (Hersent, Guide, Petit, p.205, 2002) que os codificadores com tamanhos de quadro maiores tendem a ser mais eficientes e a ter melhores taxas de compressão. Um outro fator é que o quadro não é transmitido através da rede sem que uma quantidade considerável de overhead seja acrescentada pelos próprios protocolos de transporte a cada pacote transmitido. Se cada quadro de voz comprimida for transmitido em um pacote próprio, esse overhead será acrescentado a cada um, e para alguns codificadores o overhead terá tamanho comparável, se não maior, aos dados úteis. Para diminuir o overhead a um nível aceitável, grande parte das soluções atuais transmitem vários quadros em cada pacote.

Se todos os quadros acumulados no pacote pertencerem ao mesmo fluxo de áudio, isso acrescentará mais atraso de acumulação. Na verdade, usar um codificador com um tamanho de quadro igual a x e três quadros por pacote é similar, em overhead e atraso de acumulação, a propor um codificador com um tamanho de quadro igual a 3x e um quadro por pacote. Como o codificador com um tamanho de quadro maior geralmente é mais eficiente, é provável que essa última solução também seja mais eficiente (Hersent, Guide, Petit, p.205, 2002).

Figura 5 – Transmissão de quadros de voz comprimidos (Hersent, Guide, Petit, 2002)

A Figura 6, a seguir, ilustra uma arquitetura simples de rede para telefonia IP. Conforme será visto, os telefones tradicionais se ligam à rede telefônica convencional e esta, por sua vez, se liga ao gateway IP que, finalmente, se liga à Internet (rede IP). As centrais telefônicas (PABX) se ligam ao gateway IP e ao sistema de telefonia fixa comutada (STFC). Os telefones IP se ligam diretamente à rede IP.

Figura 6 – Arquitetura de uma rede simples para telefonia IP (Digit-Life, 2006)

Uma das principais vantagens da implantação de uma rede de voz sobre IP em uma rede corporativa é a possível diminuição de custos com ligações telefônicas locais, interurbanas e até mesmo internacionais. Como as conversações telefônicas têm características de tempo-real, faz-se necessário utilizar uma série de subsídios extras para garantir a qualidade do serviço das ligações. Voz sobre IP pode ser uma alternativa bastante viável e confiável para empresas que necessitam reduzir seus custos com ligações de longa distância.

2.4 Equipamentos

Os equipamentos aqui listados oferecem uma base para o desenvolvimento de estruturas de redes IP, ao passo que representam o investimento inicial para a implementação de tais redes. Mas, esse investimento é rapidamente retomado ao longo dos meses de uso da rede IP. Como se vê em (VOIP Overview, 2006), (Ejnisman, 2006) e (Promon5, 2005), o custo de VoIP, comparado a uma rede PSTN tradicional, é bem reduzido.

Como pode ser visto na Figura 7, o custo/benefício da telefonia IP é mais vantajoso que um sistema telefônico tradicional. No primeiro exemplo de Telefonia IP se vê uma situação de VoIP de PC a PC, enquanto que no exemplo seguinte há a Telefonia IP completamente operacional, ou seja, possibilitando qualquer modalidade VoIP.

Figura 7 – Comparação de VoIP com telefonia tradicional (Pietrosemoli, 2006)

A seguir são apresentados alguns exemplos de equipamentos.

2.4.1 Sistema de Telefonia Fixa Comutada

É o sistema público convencional de comunicação de voz, que interliga empresas e residências nacional e internacionalmente. O sistema de telefonia móvel atual também pode ser considerado convencional ou tradicional, para os serviços de comunicação de voz.

2.4.2 Terminais

Podem ser considerados também terminais de dados (PC), terminais de multimídia (MT) e terminais de telefonia IP, todos conectados a uma infra-estrutura comum de rede de dados.

O deslocamento de pessoal é facilitado, pois os terminais podem ser conectados em qualquer localidade sem alteração de infra-estrutura e sistemas, e todas as facilidades configuradas para o perfil do usuário podem ser acessadas.

2.4.3 Terminal Telefônico Convencional

É o telefone convencional usado em residências e empresas, como é mostrado na Figura 8. Em alguns sistemas digitais mais modernos (públicos ou privados), os telefones também são digitais, para permitir um maior número de funcionalidades adicionais à comunidade de voz convencional, como correio de voz, identificação de chamadas, viva-voz, menu de funções e outras.

Figura 8 - Estrutura de uma rede de telefonia convencional (Pinheiro, 2005)

2.4.4 – Terminal Telefônico IP

É o telefone preparado para a comunicação de voz em redes IP, possuindo todas as funcionalidades e protocolos necessários instalados para suportar a comunicação bidirecional de voz em tempo real e a sinalização de chamadas. As funcionalidades adicionais integradas dependem da finalidade e do custo do terminal.

O telefone IP se liga à rede IP, assim como o gateway, o servidor, o computador que possui o software e o gerenciador de chamadas, como se vê na Figura 9.

As funcionalidades variam entre capacidade de utilizar conferência de chamadas, caixa postal de voz (voice mail), transferência de chamadas, chamadas em espera, registro de chamadas, além das funcionalidades básicas de um telefone comum (discagem rápida, re-discagem, alto-falante, mudo, etc).

Figura 9 - Estrutura para telefonia IP (Pinheiro, 2005)

2.4.5 Terminal Multimídia

São computadores preparados para a comunicação de voz em redes IP. Assim como o telefone IP, eles têm todas as funcionalidades e protocolos necessários instalados para suportar comunicação bidirecional de voz em tempo real e a sinalização de chamadas.

Esses terminais podem ser utilizados para aplicações mais complexas, tais como Postos de Atendimento de Call-Centers e estações para conferências multimídia, entre outras.

2.4.6 Roteador (ROT)

Equipamento responsável pela interface entre a rede local e o provedor de rede IP. Participa da funcionalidade de VPN e pode ter, adicionalmente, as funções de firewall e, em redes de menor porte, de gateway para interface com o STFC.

2.4.7 MCU

É o equipamento responsável pelos serviços de conferência entre 3 ou mais terminais. É composto por um Controlador Multiponto ou MC, responsável pela sinalização das chamadas, e por um Processador Multiponto ou MP, responsável pelo processamento dos pacotes de dados dos sinais de voz dos terminais envolvidos na conferência.

2.4.8 PABX

É o equipamento de uso corporativo empregado para executar os serviços privados de voz nas empresas. Geralmente são sistemas digitais e se interligam ao STFC (ou aos sistemas de telefonia móvel) para realizar as comunicações externas.

2.4.9 Gateway

É o equipamento responsável pela interoperabilidade entre a rede local (ou a rede IP) e o STFC (e/ou sistemas de telefonia móvel). Ele executa a conversão de mídia em tempo real (voz analógica x voz digital comprimida) e a conversão de sinalização para as chamadas telefônicas.

2.4.10 GC

É o equipamento responsável pelo controle das chamadas em andamento realizadas pelos GW. Também chamado de CA, o GC utiliza e gera as informações de sinalização e ainda comanda os GW’s para iniciar, acompanhar e terminar a conexão entre dois terminais distintos.

2.4.11 Zona

Zona é um conjunto de terminais, GWs e MCU’s gerenciados por um único gatekeeper. Uma zona deve ter, pelo menos, um terminal, e pode ou não conter GW’s ou MCUs.

Entretanto, uma zona tem apenas um GK. Fisicamente, a zona pode ser composta por um ou mais segmentos de rede interligados através de roteadores ou outros equipamentos semelhantes.

2.4.12 Gatekeeper

É o equipamento responsável pelo gerenciamento de um conjunto de equipamentos dedicados à telefonia IP, quais sejam telefone IP, MT, GW, GC e MCU. Suas principais funções são: executar a tradução de endereçamento dos diversos equipamentos; controlar o acesso dos equipamentos à rede dentro de sua zona, e controlar a banda utilizada.

Outras funcionalidades opcionais podem ser adicionadas, entre elas a autorização de chamadas, localização de GW, gerenciamento de banda, serviços de agenda telefônica (lista) e serviços de gerenciamento de chamadas.

A comunicação entre 2 GKs distintos normalmente é feita durante a realização de chamadas de longa distância, através de protocolos específicos para esse fim, onde são trocadas informações relativas aos terminais de cada área de atuação dos GKs.

2.4.13 CM

É o equipamento responsável pelo gerenciamento de chamadas. O gerente de chamadas (call manager) implementa as funções de gatekeeper (GK), gerenciando os elementos que fazem parte do sistema VoIP e as chamadas, fornecendo serviços de tradução de endereçamento IP, controle do GW, entre outros.

Pode ser implementado através de equipamentos redundantes e backups em locais distintos. Normalmente, existe um equipamento principal no escritório matriz (redundante e com

backup em outro local), que mantém a configuração de toda a rede, e equipamentos secundários nos outros escritórios, que conhecem apenas suas redes internas. As chamadas que envolvam escritórios distintos necessariamente envolvem o equipamento principal localizado na matriz.

2.4.14 Application ServerO servidor de aplicação é o equipamento que fornece serviços adicionais ao sistema VoIP. Dentre esses serviços, podem ser destacados: caixa postal de voz (voice mail), unidade interativa de resposta audível (IVR) e serviços de agenda telefônica.

2.5 Protocolos de Voz

A telefonia IP geralmente utiliza protocolos como o H.323, MGCP, IAX e SIP. Na maioria das implementações, o protocolo RTP é utilizado para transmitir tráfego de voz sobre IP. Uma exceção que merece destaque é o IAX, que carrega dados de sinalização e de voz através de uma única conexão UDP, que resulta em menos problemas ao passar por dispositivos como firewall e NAT. Estes problemas podem ser atrasos, variação no atraso (jitter) e perda de pacotes, de acordo com (GT VoIP, 2002).

A seguir, descrevem-se os principais protocolos de voz. Como os protocolos H.323 e o SIP são utilizados em mais larga escala, serão apresentados em detalhes.

2.5.1 H.323

O H.323 é uma recomendação reconhecida do ITU-T que define padrões para a comunicação multimídia através de redes de pacotes. Ele é conhecido com o padrão “guarda-chuva” (umbrella standard) justamente pelo fato de cobrir vários tipos de comunicações multimídia em redes locais sem qualidade de serviço garantida. Além disso, segundo (H.323, 2002), o H.323 define padrões para codificação e decodificação de fluxos de dados multimídia, de forma a garantir a interoperabilidade de produtos H.323 de fabricantes distintos.

Uma característica interessante deste protocolo é que ele não depende em nenhum aspecto relacionado à rede, assim, pode-se utilizar qualquer tecnologia de enlace (Ethernet, Fast Ethernet, FDDI, Token Ring). A disposição dos elementos da rede pode ser tanto apenas uma ligação ponto-a-ponto quanto vários segmentos conectados. Na figura 10, demonstra-se a comunicação de dois terminais H.323 em uma rede baseada em pacotes.

Figura 10 – Exemplo de rede de pacotes com dois terminais H.323 (H.323, 2002)

Segundo (H.323, 2002), mesmo sendo obrigatório apenas o suporte à mídia de áudio, cada mídia (áudio, vídeo, dados) deve estar de acordo com as especificações do padrão H.323 quando for utilizada.

Na Figura 11, componentes do padrão H.323 e a interoperabilidade com outros padrões da família H.32x (nota-se que o foco é no padrão H.323, não havendo maiores informações sobre outros componentes da família H.32x) são melhor visualizados.

Figura 11 – Componentes do padrão H.323 (H.323, 2002)

2.5.1.2 Componentes H.323

De acordo com o Padrão H.323, quatro componentes são definidos para, juntos, possibilitarem uma comunicação multimídia:

Terminais: São computadores com suporte a voz utilizados na rede, para uma comunicação em tempo real (garantida pela rede) e com a opção de suportar também vídeo e dados. Além disso, provêm uma comunicação bidirecional, em tempo real, com outros terminais H.323;

Gateways: São componentes opcionais em redes H.323, pois provêm a comunicação entre terminais H.323 e terminais de outros padrões como H.310, H.321, H.322 e outros, ou seja, a tradução entre os terminais. Os gateways provêm conectividade em nível mundial e interoperabilidade a partir da LAN (H.320 e H.324 – telefones normais), fazem o mapeamento de sinalização de chamadas (Q.931 para H.225.0), o mapeamento de controle (H.242/H.243 para H.245) e o mapeamento de meios (FEC, multiplex, rate matching, audio transcoding, T.123 translation);

Gatekeepers: São componentes centralizadores de todas as chamadas de sua respectiva zona (zona é o conjunto de todos terminais, gateways e MCUs gerenciados por um único gatekeeper. Uma zona deve incluir, pelo menos, um terminal e pode incluir segmentos de LAN conectados usando roteadores). São os gatekeepers que fazem o controle de chamadas das estações registradas, o registro dos usuários, a conversão de endereços simbólicos em endereços IP ou IPX, o controle de admissão, o gerenciamento da área e (ou) grupo e o controle da largura de banda;

MCUs: São estes componentes que possibilitam conferências com mais de dois participantes. Em uma arquitetura H.323, existe um MC e nenhum ou mais MPs. O MC é responsável pelo gerenciamento das negociações entre os terminais, de forma a definir as capacidades de processamento de áudio de vídeo. O MP é o que mescla, codifica e processa os bits de áudio, vídeo ou dados.

2.5.2 MGCP

O protocolo MGCP, definido na RFC 2705 (MGCP, 1999) do IETF, é usado para controlar as conexões (chamadas) nos GWs presentes nos sistemas VoIP.

O MGCP implementa uma interface de controle usando um conjunto de transações do tipo comando – respostas que criam, controlam e auditam as chamadas nos GWs. Estas mensagens usam como suporte pacotes UDP e são trocadas entre os GCs e GWs para o estabelecimento, acompanhamento e finalização de chamadas. Isto que dizer que os gateways (GWs) de telefonia são controlados por algum componente que, no caso do MGCP, é o CA ou MGC.

O GW MGCP é responsável pela tradução de áudio entre a rede pública (PSTN) e a rede de comutação de pacotes. O CA realiza o processamento do sinal e da chamada. Na Figura 12, são mostrados os principais componentes do MGCP, que são os terminais, os gateways e os CAs.

Figura 12 – Componentes do MGCP (VoIP MGCP, 2004)

Na Figura 12, o CA pede constantemente ao gateway R1 que verifique o terminal PABX, com o objetivo de encontrar um evento, como uma requisição de chamada. Então, R1 manda uma confirmação (ACK) para o CA. De acordo com (VoIP MGCP, 2004), o que acontece detalhadamente, desde o momento em que um determinado usuário tira o telefone do gancho até que a comunicação com outro usuário seja possibilitada, é o descrito, em seguida.

Um determinado usuário de uma empresa que utilize este protocolo tira o telefone do gancho e o gateway detecta esta ação, informando logo em seguida ao CA. Este, por sua vez, verifica se há recursos disponíveis para que seja possível a realização da chamada. Caso seja possível, ele manda R1 enviar um tom de chamada para o PABX e aguardar os dígitos. Após receber os dígitos, o gateway se reporta novamente ao CA, que direciona a chamada e, desta vez, manda R2 enviar um tom de toque para o telefone desejado. O CA também manda R2 monitorar o terminal, com o objetivo de procurar por um sinal de off-hook (fora do gancho). Quando o usuário do telefone atende, o gateway informa esta ação ao CA, que manda os gateways estabelecerem o canal de fluxo de voz. Então, a comunicação é iniciada.

2.5.3 IAX

O IAX é um protocolo padrão de uso privado (proprietário) do PABX Asterisk, sendo mais eficiente do que o RTP, no que diz respeito ao número de ligações simultâneas e reconhecimento de codecs de áudio. Ele foi projetado para substituir os protocolos H.323 e SIP. Atualmente, o protocolo está na sua segunda versão, IAX2.

2.5.3.1 Arquitetura e Componentes

Segundo (Spencer, 2004), IAX é um protocolo peer-to-peer tanto de mídia como de sinalização. Isto significa que os endpoints mantêm máquinas de estado associadas a operações do protocolo. Com respeito ao componente de sinalização, o protocolo baseado em IAX é mais análogo ao SIP do que ao MGCP, que é um protocolo controle de chamadas mestre-escravo.

Seu projeto básico proposto multiplexa a sinalização e os múltiplos streams de mídia sobre uma única associação UDP entre dois hosts. Isto é alcançado através do uso da porta UDP 4569, para todos os tipos de tráfego no IAX. Cada host usa esta porta para transmitir todos os pacotes da Internet. IAX usa um número de chamada de 15 bits para multiplexar vários streams. O valor zero é um número de chamada especial reservado em cada host. É usado quando o número de chamada do host de destino não é conhecido no momento de efetivar a conexão.

Podem ser considerados neste contexto, dois protocolos: um protocolo para sinalização e outro para transporte de mídia. Esta proposta se diferencia da arquitetura básica de protocolos baseados na IETF, os quais apresentam separação dos componentes de controle (MGCP e SIP) e o stream de mídia (RTP/RTCP) utilizando protocolos distintos. Pelo fato da sinalização e da mídia dividirem a mesma porta UDP, o IAX não sofre do problema de transversalidade de NAT quando se trata de serviços IP. Um maior detalhamento sobre este tópico é discutido em (Symmetric NAT Traversal, 2006).

A versão IAX2 apresenta componentes de segurança. Neste caso, são disponibilizados métodos múltiplos de autenticação e autorização de usuários.

A Figura 13 ilustra a relação básica entre dois hosts de Internet. Cada um fazendo uso da porta padrão UDP 4569 para a transmissão de pacotes.

Figura 13 – Chamadas multiplexadas em uma única porta UDP (Spencer, 2004)

Outra característica do IAX é a existência de algumas classes de quadros descritas a seguir:

Quadros Cheios – transportam dados de sinalização e controle; apresentam IEs que servem para descrever diferentes tipos de usuários ou dados de chamada específicos;

Mini Quadros – transportam dados stream de mídia;

Meta Quadros – são usados para transmissões de vídeos.

2.5.3.2 Funcionamento

Segundo (Spencer, 2006), o IAX apresenta ampla capacidade geral de utilização, uma vez que suporta os tipos mais comuns de streams em multimídia. Entretanto, o protocolo é otimizado para chamadas VoIP, nas quais o baixo overhead e o consumo controlado de

largura de banda são prioridade. Este aspecto torna o IAX mais eficiente para VoIP que os protocolos que consideram as possibilidades destas prioridades muito acima do que é realmente necessário, e que especificam mais detalhes do que é estritamente necessário para descrever ou transportar uma chamada ponto-a-ponto.

IAX pode registrar locações, criar, modificar, terminar sessões multimídias, e transportar conteúdo pelas sessões, as quais controla. Sua sinalização unificada e tráfego de voz permitem fluir de forma transparente por NATs e proporcionam a um administrador de firewall ter que abrir somente uma porta para permitir o seu uso. Esta unificação não requer que um cliente IAX saiba absolutamente nada a respeito da rede na qual ele está em operação (Spencer, 2006).

IAX é codificado como um protocolo binário. Um dos grandes benefícios desta característica é a eficiência no uso da largura de banda, pois a qualidade das chamadas de voz é relacionada à quantidade de banda consumida, sendo esta, uma forma de otimização do protocolo para chamadas de voz. A largura de banda para outros tipos de stream é sacrificada pelo bem das chamadas de voz individuais. Outros benefícios do protocolo binário são: robustez contra sobrecarga de bufferização e uma compacta capacidade de implementação, que reduz a questões de interoperabilidade.

Uma chamada baseada em IAX2 consiste em vários segmentos. Cada um pode ser implementado utilizando diferentes tipos de protocolos, por exemplo, SIP para IAX2 para ISDN. IAX2 é responsável por configurar todos os segmentos que compõem o caminho da chamada, não necessariamente chamadas fim-a-fim.

Se dois segmentos adjacentes da chamada utilizarem o protocolo IAX, e se o peer intermediário determinar que não precisa ficar no caminho da chamada, este pode invocar uma mudança no caminho da chamada, de tal forma que se remove do mesmo caminho. Porém, o caminho da chamada não é alterado até que todos os peers do caminho otimizado confirmem que eles podem se comunicar de forma adequada (Spencer, 2006).

2.5.4 SIP

O SIP, definido na RFC 2533 do IETF, estabelece o padrão de sinalização e controle para chamadas que não utilizam o padrão H.323, possuindo seus próprios mecanismos de segurança e confiabilidade.

O SIP se originou em meados dos anos 90 para que fosse fácil convidar pessoas para participar de uma sessão multicast via IP. Ele obteve uma adoção rápida como padrão para comunicações integradas e aplicações que usam presença (presença significa a aplicação estar consciente da sua localização e disponibilidade).

O SIP estabelece recomendações para serviços adicionais tais como transferência e redirecionamento de chamadas, identificação de chamadas, autenticação de chamadas, entre outros.

2.5.4.1 Agente do Usuário SIP

O Agente do Usuário é o terminal SIP ou o software de estação final que funciona como um cliente no pedido de inicialização de sessão e também age como um servidor quando responde a um pedido de sessão. Dessa forma, a arquitetura básica é cliente/servidor.

O Agente do Usuário é “inteligente”, com isso ele armazena e gerencia situações de chamada. O Agente do Usuário faz chamadas para endereços que parecem e-mail ou número de telefone. Ele ainda pode aceitar e receber chamadas de outro Agente do Usuário sem requerer nenhum componente adicional do SIP. Os próximos componentes restantes (servidor proxy SIP e servidor de redirecionamento SIP) fornecem gerenciamento e funcionalidades adicionais.

2.5.4.2 Servidor Proxy SIP

Um tipo de servidor intermediário do SIP é o servidor proxy SIP. Este passa requisições do Agente do Usuário para o próximo servidor SIP e também retém informações com a finalidade de contabilidade/faturamento. Além disso, o servidor proxy SIP pode operar com comunicação stateful (por exemplo, como um circuito) ou stateless (como uma conexão TCP, por exemplo).

O servidor SIP stateful pode “dividir” chamadas por ordem de chegada para que várias extensões estejam tocando de uma vez e o primeiro que atender pega a chamada. Essa capacidade significa que o usuário pode especificar que o telefone de desktop SIP, o telefone celular SIP e as aplicações de videoconferência SIP podem “tocar” todas ao mesmo tempo quando houver qualquer chamada e o usuário posse atender de algum desses locais e começar a conversar, enquanto os demais param de tocar.

O servidor proxy SIP pode utilizar múltiplos métodos para tentar resolver o pedido de endereço de host, incluindo busca de DNS, busca em base de dados ou retransmissão do pedido para o “próximo” servidor proxy.

2.5.4.3 Servidor de Redirecionamento SIP

Um outro tipo de servidor intermediário do SIP é o Servidor de Redirecionamento SIP, que tem como função fornecer a resolução de nomes e localização do usuário. O servidor de redirecionamento SIP responde ao pedido do Agente do Usuário fornecendo informações sobre o endereço do servidor para que o cliente possa contactar o endereço diretamente.

2.5.4.4 Registrador SIP

O Registrador SIP fornece um serviço de informação de localidades; ele recebe informações do Agente do Usuário e armazena essa informação de registro.

A arquitetura do SIP faz uso do SDP, que é um protocolo de conferência multicast via IP desenvolvida para descrever sessões de áudio, vídeo e multimídia. Na realidade, qualquer tipo MIME pode ser descrito, similar à habilidade do e-mail de suportar todos os tipos de anexos em mensagens. A descrição da sessão pode ser usada para negociar uma aceitação de um conjunto de tipos de mídias compatíveis.

Como resultado dessa arquitetura, o endereço do usuário SIP remoto sempre é o mesmo (ex.: SIP: [email protected]), mas ao invés de estar amarrado a um endereço estático, ele se comporta como um endereço dinâmico que reflete o endereço de localização atual da

pessoa remota. A combinação de proxy e servidor redirecionador dá ao SIP grande flexibilidade de arquitetura.

O usuário pode empregar vários esquemas simultaneamente para usuários localizados e é o que faz a arquitetura do SIP ser bem adaptada para suportar mobilidades. Mesmo quando o usuário remoto é móvel, o proxy e o redirecionar podem ser usados para passar adiante o pedido de conexão para o usuário da locação atual.

As sessões podem envolver múltiplos participantes, similar a uma chamada multiponto H.323. Comunicações dentro de uma sessão em grupo podem ser via multicast ou uma rede de chamadas unicast, ou até mesmo uma combinação dos dois. Um outro resultado da arquitetura do SIP é a sua adequação natural como um ambiente de colaboração devido a suas habilidades de apresentar múltiplos tipos de dados, aplicações, multimídia, etc. com uma ou mais pessoas.

2.5.4.5 SIP x H.323

Existem várias diferenças entre estes protocolos, como o tipo da arquitetura, quem é o responsável pelo controle de chamadas, entre outros, como pode ser visto na Tabela 1.

No protocolo SIP, as requisições e respostas são baseadas em texto puro, no H.323 são baseadas em codificação binária, baseada em ASN.1 PER. No SIP, o SDP descreve os tipos de mídia e endereços de transporte da mídia, no H.323 há diversos sub-protocolos: H.245, H.225(Q.931, RAS), H.450.x, etc. O SIP possui servidores com diferentes comportamentos: registrar, proxy, redirecionar, já o H.323, conta com um servidor único Gatekeeper, entretanto, ambos usam RTP/RTCP sobre UDP/IP.

O protocolo SIP se encontra em expansão no que diz respeito à ocupação no mercado, porém com a atual base já disseminada do H.323, surgiu a necessidade de interoperabilidade. Há soluções baseadas em Signaling Gateways. Maiores informações em (MonoVoIP, 2005).

A técnica de Signaling Gateways é uma recomendação do ITU-T para comunicações multimídia e é um componente responsável pela tradução de mensagens (informações sobre estabelecimento e encerramento de conexões) entre um meio (normalmente IP) e outro (PSTN).

Por exemplo, o sip323 permite a realização de uma chamada de um dispositivo baseado em uma arquitetura SIP para outro dispositivo baseado em uma arquitetura H.323 e vice-versa. Vide (MGCP, 1999), para obter maiores detalhes.

Critérios H.323 SIP

Padrões ITU IETF

Arquitetura Distribuída Distribuída

Versão atual H.323v4 RFC2543-bis07

Controle de chamadas

Gatekeeper Servidor proxy/redirect

Endpoints Gateways terminal Agente do usuário

Transporte de sinalização

TCP/UDP TCP/UDP

Capacidades multimídia

Sim Sim

DMTF – Relay Transport

H.245 (sinaling) ou RFC 2833 (media)

RFC 2833 (media) ou INFO (sinaling)

Fax – Relay Transport

T.38 T.38

Serviços suplementares

Fornecidos pelo endpoint ou pelo controle de chamadas

Fornecidos pelo endpoint ou pelo controle de chamadas

Tabela 1 – Comparativo entre SIP e H.323

2.5.4.6 Segurança em SIP

Na sua especificação, o SIP é descrito como um protocolo bastante difícil de se efetivar segurança (Tutorial Segurança Teleco, 2006). Essa dificuldade é caracterizada pelo próprio modo de operação do protocolo, que engloba o uso de intermediários e relações de confiança das mais variadas entre os elementos envolvidos. A grande variedade de ambientes e formas de utilização também dificulta a efetivação da segurança. Assim, mecanismos distintos devem ser aplicados aos diferentes aspectos do SIP.

O primeiro aspecto evidenciado é que a segurança do processo de sinalização do SIP não tem relação com a maneira como a segurança é efetivada nos protocolos que trabalham em conjunto com o SIP, como o RTP, ou com as implicações de segurança do corpo da mensagem carregada, que é resolvida com a segurança MIME. Como qualquer mídia de uma sessão pode ser encriptada fim-a-fim independente da sinalização SIP, a especificação faz considerações apenas com respeito à segurança da sinalização.

Vários mecanismos de segurança são propostos pela especificação, a partir do exame de modelos de ameaça clássicos que identificam as necessidades de segurança do SIP. Os modelos examinados se referem aos seguintes itens (Colcher, 2005):

Roubo de registro: o atacante faz um registro malicioso fingindo ser um usuário válido no sistema, alterando as informações de contato. Exige a autenticação do originador das mensagens de registro;

Personificação do servidor: o atacante finge ser o servidor de um serviço, intermediando a comunicação com o verdadeiro servidor (atua como man-in-the-middle). Exige a autenticação dos servidores antes do envio das solicitações;

Adulteração do corpo da mensagem: o atacante modifica o corpo da mensagem, interferindo nos parâmetros negociados para uma sessão. Exige confidencialidade, integridade e autenticação do corpo da mensagem, e muitas vezes, do cabeçalho;

Rompimento de sessão: o atacante forja uma mensagem em nome de um dos participantes, mudando o estado de uma sessão. Exige a autenticação do participante que envia a mensagem BYE;

Negação de serviço e intensificação: o atacante gera uma quantidade excessiva de tráfego de rede com endereços forjados, sobrecarregando os elementos que participam de uma sessão. Exige a definição de arquiteturas que minimizem os riscos de uma negação de serviço.

Os mecanismos de segurança recomendados pela especificação são derivados dos mecanismos clássicos utilizados pelo HTTP e SMTP (Powl, 1999). Cada um desses mecanismos é brevemente descrito, a seguir:

Segurança na camada inferior: encripta completamente as requisições e respostas SIP nó-a-nó, e permite que os pontos terminais verifiquem a identidade dos servidores proxies para os quais as requisições são enviadas. As recomendações são IPSEC e TLS;

Esquema URI SIPS: esquema de identificação dos recursos que devem ser acessados de forma segura, exigindo que todo caminho percorrido pela requisição seja seguro. Determina que o processo de autenticação dos participantes seja baseado em certificados digitais;

Autenticação HTTP: oferece uma capacidade de desafio, baseada na autenticação do HTTP, que utiliza as mensagens de resposta 401 e 407, assim como campos no cabeçalho para carregar desafios e credenciais. A utilização do esquema HTTP Digest Authentication no SIP, sem modificação significativa, permite proteção contra reenvio de mensagem e autenticação de mão única;

S/MIME: permite a encriptação apenas do corpo MIME da mensagem SIP, garantindo a segurança fim-a-fim do corpo, sem afetar os campos de cabeçalho da mensagem.

Mais informações sobre os requisitos para a implementação dos mecanismos de segurança apresentados podem ser encontradas na especificação do SIP (RFC 3261). E mais informações sobre segurança, podem ser consultadas em (Redes UnB, 2006).

2.6 Qualidade de Serviço

2.6.1 Conceito

O IP foi inicialmente desenvolvido e implementado como um protocolo de comunicação utilizando a regra do melhor esforço (best-effort service), que não previa nenhum mecanismo de qualidade de serviços (Silva, 2000).

Com o desenvolvimento da Internet, surge a tendência de integrar o transporte de dados, inicialmente previsto no projeto do protocolo IP, com outras formas de tráfego como voz ou vídeo em uma única infra-estrutura de redes de pacotes. Surge então a necessidade de aplicar qualidade de serviço (QoS) às potencialidades do IP.

Fundamentalmente, QoS habilita ao sistema, o fornecimento de um melhor serviço a certos fluxos. Isto é feito por estabelecimento de prioridades em um fluxo ou limitação da prioridade em algum outro fluxo (QoS Networking, 2006). Também caracteriza QoS, segundo (Silva, 2000), sua capacitação fim-a-fim, na qual o tráfego é tratado inicialmente na LAN de origem, depois no próprio roteador, posteriormente nas WANs e roteadores intermediários, no roteador destino, e finalmente na rede local destino.

Entretanto, QoS deve ser compreendida e implementada como um meio de amenizar as questões relacionadas à má distribuição da informação. Isto significa que interpretar sua existência como uma solução que possa vir a resolver todos os eventuais problemas na transmissão dessa informação, é equivocado.

2.6.2 Classes de Serviços

Para adicionar recursos de qualidade de serviços à pilha TCP/IP Internet, dois modelos de classes de serviços para tráfego Internet foram desenvolvidos pela IETF: Differentiated Services (DIFFSERV) ou Soft QoS refere-se aos serviços diferenciados, que provêm um tratamento com prioridades, dando preferência a determinados tipos de fluxo; o segundo modelo é denominado Integrated Services (INTSERV), também chamado de Hard QoS, e se refere ao fornecimento de uma garantia absoluta na alocação dos recursos da rede.

2.6.2.1 DIFFSERV

O DIFFSERV classifica pacotes assim que entram na LAN. Esta classificação ou marcação de pacotes é feita por precedência IP e DiffServ Code Point (DSCP). (RhysRadenQoS, 2006)

Para o caso de precedência por IP, foram utilizados 3 bits do campo tipos de serviços (ToS) presentes no cabeçalho IP, conforme demonstrado na Figura 14.

Figura 14 – Byte ToS do cabeçalho IP (Netcraftsmen, 2003)

A partir do campo ToS foi gerada a seguinte denominação, segundo (Netcraftsmen, 2003), para a eventual classificação: 000 – rotine; 001 – priority; 010 – immediate; 011 – flash; 100 – flash-override; 101 – critical; 110 – internet; 111 – network. Só são consideradas 6 classes para configuração. Quanto maior o nível de classificação do pacote, maior será a prioridade no tratamento e alocação de recursos da rede. Os dois últimos níveis, 6 e 7, são reservados para as aplicações de controle e gerência da rede, e não há como configurá-los. (QoS Networking, 2006).

A Figura 15 lista o comportamento dos bits de precedência nos diferentes tipos de serviços. Um maior detalhamento sobre a especificação é encontrada na própria RFC 795.

Figura 15 – Bits de Precedência (Service Mappings, 1981)

Para classificação DSCP, foi estabelecido o uso dos 6 bits mais significativos do campo ToS. Esta classificação proporciona a chance de 26 = 64 valores diferenciados. Na RFC 2474 (DiffServ,1998), há uma descrição mais detalhada de DIFFSERV e DSCP.

Após marcação, os pacotes são separados em filas, e tratados seguindo a lógica de algoritmos de congestionamento (RhysRadenQoS, 2006). A Figura 16 mostra um exemplo de funcionamento desta lógica.

Figura 16 – Lógica de um algoritmo de congestionamento (Tanenbaum, 1996)

Na Figura 16, segundo a análise de (Cansian, 2002), pode-se notar que a janela de congestionamento tem em princípio 64 KB, portanto foi atribuído ao limite um valor de 32 KB, sendo que a janela de congestionamento da transmissão 0 recebe 1 KB. A janela de congestionamento cresce exponencialmente até alcançar 32 KB, quando a partir de então, passa a apresentar crescimento unicamente linear. Na transmissão 13, ocorre um timeout, e ao limite é atribuído um valor que é a metade do valor da janela atual – janela atual de 40 KB, limite passa a ser 20 KB. O crescimento volta a ser exponencial, até que o limite de 20 KB seja atingido, e torne o crescimento linear. Se não houver outro timeout, a janela de congestionamento continuará crescendo até atingir o tamanho da janela do receptor. Neste caso, o crescimento será interrompido, e permanecerá constante, se a janela do receptor não tiver seu tamanho alterado ou não ocorrer qualquer timeout.

2.6.2.2 INTSERV

A diferença entre INTSERV em relação a DIFFSERV é que os serviços integrados especificam seus requisitos de tráfego, e a rede configura tais requisitos, tudo de forma anterior ao envio da informação. Se a rede não conseguir a configuração do caminho da transmissão, então a chamada não é efetivada, o que caracteriza CAC (RhysRadenQoS, 2006). Maiores informações sobre CAC podem ser vistas em (VoIPCallAdmission, 2003).

De acordo com (Braden, 1994), a idéia de INTSERV é que qualquer roteador no sistema suporte seu padrão, e que qualquer aplicação que exija um determinado nível de garantias seja responsável por fazer reservas individuais. Existe ainda, dentro do contexto de INTSERV, a explicitação de conceitos como especificação do fluxo (flow specs) e RSVP.

A especificação do fluxo trabalha com duas componentes: especificação de tráfego (Traffic SPECification ou TSPEC) e especificação da requisição (Request SPECification ou RSPEC). TSPEC estabelece um controle no qual pacotes só podem ser enviados, se estiverem associados a algum token. A velocidade na qual os tokens são associados regula a taxa média do fluxo de tráfego, enquanto o volume do token bucket filter, responsável pela

recepção dos pacotes com tokens, dita as taxas permitidas no fluxo do tráfego. Por sua vez, RSPEC trata dos parâmetros de fluxo normal, controlled load e guaranteed. Mais detalhes são encontrados na RFC 1633 (Braden, 1994).

RSVP é de um protocolo de sinalização que têm a capacidade de requisitar um determinado nível de QoS em redes heterogêneas. Ele carrega o pedido pela rede, visitando cada nó que carregará o fluxo. Este protocolo trabalha em conjunção com os protocolos de roteamento, utilizando sua robustez, além de pressupor algum tipo de política de escalonamento implementada nos nós intermediários para implementar a reserva de recursos (GTA-UFRJ, 1999). Seu grande problema, segundo (Brito & Sousa, 2005) é a necessidade de um “estado do fluxo” para cada fluxo criado, gerando assim, um problema de escalabilidade nos grandes backbones, pois centenas de fluxos estariam disputando pelos recursos disponíveis na rede e não haveria processamento suficiente nos roteadores que conseguiriam atualizar esses “estados” de uma maneira eficaz. Por tal motivo, houve o desenvolvimento do DIFFSERV. Um informativo mais técnico é demonstrado na RFC 2205 (RSVP, 1997).

2.6.3 Controle de Congestionamento

Há vários mecanismos para prevenção de congestionamento, aplicados tanto em LAN como em WAN, os principais serão explicitados a seguir.

2.6.3.1 FIFO

Uma fila FIFO é um mecanismo de armazenamento e repasse (store and forward) que não implementa nenhum tipo de classificação. A ordem de chegada dos pacotes é que determina a alocação da banda, e o que chega primeiro é logo atendido. É o tratamento default da fila nos roteadores, já que não requer nenhuma configuração. O problema ocorre no tráfego em rajadas, que pode causar longos atrasos em aplicações sensíveis ao tempo. Por isso, filas FIFO não servem para aplicações que requerem QoS. (Silva, 2000). A Figura 17 demonstra como se comporta o FIFO.

Figura 17 – Demonstração do FIFO

2.6.3.2 Enfileiramento PQ

O escalonamento por prioridades permite ao administrador configurar prioridades de tráfego. O tráfego que chega é associado a uma das filas de uma dada prioridade. Desta maneira, o tráfego na fila de maior prioridade é servido até que esta se esvazie; posteriormente, pacotes na próxima fila de prioridades são transmitidos. Este arranjo das filas dos roteadores permite que se dê o máximo de banda para tráfegos críticos, causando prejuízos aos outros (starvation). É importante que este esquema seja utilizado dando prioridades aos tráfegos de uma forma mais adequada, já que só se evita este tipo de

problema quando o tráfego de mais alta prioridade ocupa um mínimo de banda. (GTA-UFRJ, 1999)

2.6.3.3 Enfileiramento CQ

Este permite especificar uma porcentagem da banda para uma determinada aplicação (alocação absoluta da banda). A banda reservada é compartilhada proporcionalmente, no percentual pré-definido, entre as aplicações e os usuários. O restante da banda é compartilhado entre os outros tipos de tráfego.

O algoritmo CQ controla o tráfego alocando uma determinada parte da fila para cada fluxo classificado. As filas são ordenadas ciclicamente num esquema round-robin, onde, para cada fila, é enviada a quantidade de pacotes referente à parte da banda alocada antes de passar para a fila seguinte. Associado a cada fila, há um contador configurável que estabelece quantos bytes devem ser enviados antes da passar para a próxima fila.

Até 17 filas podem ser definidas, mas a fila zero é reservada para mensagens do sistema como sinalização, keep-alive, etc. A classificação CQ pode ser feita por endereço fonte ou destino, por protocolo (IP, IPX, Appletalk, SNA, DecNet, etc), por precedência IP, por interface de entrada e ainda por listas de acesso. (QoS Networking, 2006)

2.6.3.4 Enfileiramento WFQ

O WFQ evita que as filas cheguem a uma situação de starvation, dando ao tráfego um serviço previsível. Tráfegos de baixo volume recebem o serviço preferencial, garantindo sua banda, e tráfegos de volume mais alto recebem a capacidade restante. Este mecanismo garante pouco jitter e a divisão da banda entre as diversas aplicações. O enfileiramento justo é conseguido através do uso do endereço fonte e destino do fluxo, tipo de protocolo, ou número de porta. O peso no WFQ vem de diversas fontes. O campo de precedência do cabeçalho IP afeta o peso de uma dada conversação, bem como o montante de vazão que um determinado fluxo possui. O peso de um fluxo é inversamente proporcional à quantidade de banda por ele consumida. Assim, quanto mais alta a precedência, menor é o peso (GTA-UFRJ, 1999). Outros mecanismos, e uma especificação detalhada daqueles citados anteriormente podem ser encontrados em (QoS Networking, 2006). A Tabela 2 apresenta um resumo comparativo entre métodos de enfileiramento.

Tabela 2 – Comparativo entre FWQ, PQ, CQ (adaptação de Silva, 2000)

2.6.4 Inibição de Congestionamento

No momento em que uma fila estoura, pacotes são perdidos. Como o roteador não pode prever esta perda, mesmo sendo um pacote de alta prioridade, é necessário um mecanismo de controle. Para o problema em questão, é utilizada Random Early Detect (RED). Este é um algoritmo prevenção contra congestionamento que leva em conta que alguns tipos de tráfego são sensíveis a perdas, e injetam mais tráfego na rede, assim que elas são detectadas. O RED mantém uma média distribuída exponencialmente da profundidade da fila. Ele também mantém uma tabela de limiares para estas médias móveis, distribuídos em pontos entre a metade da profundidade da fila de armazenamento e limite da fila de transmissão, e o comprimento total da fila. Quando o tamanho médio da fila excede o limiar, é computada uma função de probabilidade que gera um número aleatório. Com esta probabilidade, o pacote é descartado; caso contrário, é enfileirado. Não há prioridades, utilizando-se assim, filas FIFO. Porém, os tráfegos de baixa precedência, em condições normais, são descartados em detrimento dos de alta. (GTA-UFRJ, 1999)

Existe ainda o Weighted Random Early Detect (WRED), uma implementação da Cisco que combina as funcionalidades do Random Early Detect (RED) com a classificação de pacotes por precedência IP, que basicamente evita que as filas encham, deixando espaço para pacotes de prioridade alta, e estabelece critérios para um descarte controlado dos pacotes de mais baixa prioridade. Entretanto, o uso de WRED não exclui as chances de pacotes de voz serem descartados. Portanto, não é uma tecnologia recomendada para redes de voz. (RhysRadenQoS, 2006)

2.6.5 Eficiência do Link

2.6.5.1 RTP e RTCP

O RTP é o protocolo padrão para o transporte de fluxos de tempo-real, como áudio e vídeo. Ele é constituído de uma parte de dados e uma parte de controle (RTCP). A parte de dados do RTP é um protocolo que garante suporte a aplicações com propriedades de tempo-real, realizando a reconstrução de temporizações, a detecção de perdas e identificação de conteúdo. O RTCP provê suporte à conferência de grupos de qualquer tamanho na Internet. Este suporte inclui a identificação de fontes e suporte a roteadores de nível 2 (bridges) para áudio e vídeo, bem como tradutores de multicast para unicast. É oferecida uma realimentação de QoS dos receptores para o grupo multicast, além do suporte à sincronização de fluxos de mídias diferentes. Como forma de diminuir a sobrecarga de processamento gerada pelos cabeçalhos IP-UDP-RTP, que pode chegar a 40 octetos, é adotada versão CRTP com compressão do cabeçalho para um valor de 2 a 4 octetos. (GTA-UFRJ, 1999)

2.6.5.2 LFI

É um mecanismo onde pacotes grandes são fragmentados, e pacotes menores intercalados junto a esses fragmentos. Maiores detalhes em (RhysRadenQoS, 2006).

2.6.5.3 FRF

Tratando especificamente do padrão FRF.12, este provê funcionalidades para fragmentação fim-a-fim e intercalação de frames num mesmo PVC. Sua utilização é recomendada, não nos PVCs que trafegam voz, e sim nos PVCs de dados que compartilham a mesma conexão física dos de voz.

Em voz sobre IP, os pacotes não devem ser fragmentados, mas podem ser intercalados entre os fragmentos. É importante também que o tráfego de voz sobre IP não exceda a CIR do PVC Frame Relay, o que pode degradar a qualidade do sinal. Para isso, pode-se utilizar o FRTS (Silva, 2000).

Um maior detalhamento técnico pode ser visto em (RhysRadenFrame, 2006).

2.6.5.4 Redes ATM

Segundo (Dastis, 1998) ATM é uma tecnologia de rede para suporte eficiente de voz, dados e vídeo tanto em ambientes LAN como WAN, e que pode suportar taxas de transmissão superiores a gigabits por segundo. Conforme (Rochol, 1998), ATM é uma tecnologia comutada, orientada à conexão, que permite a um número virtualmente ilimitado de usuários terem conexões dedicadas, de alta velocidade, com outros usuários e com servidores de rede de alto desempenho.

(Dastis, 1998) relata que devido às altas taxas de transmissão envolvidas, as redes ATM têm dificuldades no controle de congestionamento, o que não acontece de modo tão ríspido em outros tipos de redes, como o X.25 e o Frame Relay. A complexidade do problema é acentuada pelo número limitado de bits do cabeçalho da célula ATM responsáveis por exercer controle sobre as células de usuário.

Em ATM, a QoS está diretamente relacionada à banda em uso. Quando existem limitados recursos físicos, o uso de mais banda aumenta a perda de células e o atraso ocorre, ou seja, cai a QoS para as células de todas as conexões que compartilham estes recursos. (Jain, 1996)

(Dastis, 1998) afirma que apesar do nível ATM apresentar diversas semelhanças com o nível de rede de redes de pacotes tradicionais, como o IP, os problemas e as soluções são distintos. Isto se deve, primeiro, ao fato das taxas dos enlaces ATM serem consideravelmente altas, variando na faixas de alguns kbit/s a centenas de Mbit/s; e também pela grande variedade de serviços que pode ser utilizada sobre esta banda disponível, sendo que muitos destes serviços têm características de QoS muito restritivas.

Dentre as razões pelas quais os esquemas tradicionais não são ideais em ATM, cita-se altos tráfegos: voz e vídeo não permitem controle de fluxo porque não podem parar de gerar células, mesmo que a rede esteja congestionada; a grande variabilidade de taxas de transmissão disponíveis às aplicações faz com que um controle de tráfego específico acabe penalizando as aplicações de um dos extremos da escala.

A essência do controle de tráfego é determinar quando um nova conexão ATM pode ser aceita ou não. Para isto, a rede deve poder avaliar se uma determinada conexão, com um determinado perfil de QoS, pode ser suportada pela rede com os recursos disponíveis, sem prejuízo para as conexões atualmente ativas. Uma vez aceita tal conexão, rede e usuário

estabelecem um contrato de tráfego, onde a rede concorda em suportar esta conexão em função de um conjunto de parâmetros de QoS negociados e o usuário se compromete em não exceder os limites dos parâmetros de tráfego. Ainda segundo (Dastis, 1998), as funções do controle de tráfego estão diretamente relacionadas com esta negociação e o policiamento de QoS pela rede; seu principal objetivo é evitar o congestionamento, mas se isso ocorrer também poderão atuar para recuperar a rede desta situação.

2.6.6 Moldagem e Policiamento de tráfego

2.6.6.1 GTS

O GTS provê mecanismos para o controle de tráfego utilizando filtros conhecidos como token buckets, limitando o tráfego de saída de uma interface a uma determinada taxa. O tráfego classificado vai para um buffer limitador, sendo liberado sob regras pré-definidas de acordo uma política de controle de tráfego, que pode ser configurada pelo administrador ou derivada da interface. Esta se aplica apenas a interfaces de saída, com o uso de listas de acesso para classificar e selecionar o tráfego. Funciona com qualquer tecnologia de enlace (nível 2) como Frame Relay, ATM, SMDS e Ethernet (Silva, 2000).

2.6.6.2 CAR

Método para policiamento e controle de tráfego IP que realiza, basicamente, duas funções para qualidade de serviço: gerenciamento de banda com limitação de taxa de acesso (policing) – permite controlar a taxa máxima de transmissão ou recepção de dados de uma determinada interface. Os pacotes que excedem os limites pré-definidos, ou são descartados, ou são reclassificados com outra prioridade para retransmissão; classificação de pacotes através de precedência IP ou de grupos de QoS (um rótulo interno do roteador utilizado para definição de classes - permite particionar a rede em múltiplas classes de serviços ou níveis de priorização (Silva, 2000).

2.6.6.3 FRTS

Método de moldagem para tráfego em redes Frame Relay. FRTS oferece parâmetros úteis, como o CIR, EIR, FECN, BECN e DE (Silva, 2000). Com FRTS pode-se, por exemplo, limitar no CIR ou no EIR à taxa de pico do tráfego de saída em cada VC, procedimento denominado rate enforcement. Pode-se obter uma maior granularidade no controle de tráfego, aplicando-se técnicas de enfileiramento como PQ ou CQ (QoS Networking, 2006) em cada VC ou no nível de subinterface. Um maior detalhamento técnico pode ser visto em (RhysRadenFrame, 2006).

2.6.7 QoS em LANs

2.6.7.1 Protocolo IEEE 802.1p

Segundo (QoS MAC, 2002), Ethernet é a tecnologia aplicada a LAN mais utilizada hoje em dia, e não se pode deixar de dar importância para o desenvolvimento de mecanismos de garantia de QoS para tal tecnologia de redes locais. Neste intuito, foi desenvolvida a

expansão do padrão IEEE 802.1, que é o IEEE 802.1p, onde o "p" provém de priorização em inglês.

De acordo com o padrão IEEE 802.1p, os seguintes parâmetros são importantes para prover/garantir QoS: disponibilidade do serviço; perda de quadro; desordenamento dos quadros; duplicação de quadros; atraso de transmissão; tempo de vida do quadro; taxa de erros não detectados; tamanho máximo de SDU; prioridade; vazão.

É importante enfatizar que a qualidade de serviço provida pelo nivel de enlace, tem o objetivo de complementar um mecanismo de QoS mais complexo em um nivel acima, tais como INTSERV e DIFFSERV, sendo considerado o seu uso isolado como um solução incompleta, inadequada e errônea.

Em (QoS MAC, 2002), há detalhes das especificações das propostas do protocolo IEEE 802.1p.

2.6.8 Atraso e Latência

Segundo (Cliconnect, 2006), a latência e o atraso são parâmetros indispensáveis para a QoS das aplicações. Latência é usualmente utilizada para se referir a equipamentos, enquanto atraso está relacionado com as transmissões de dados. A latência da rede pode ser entendida como o somatório dos atrasos impostos pela rede e equipamentos utilizados na comunicação. Ainda conforme (Cliconnect, 2006), atraso de propagação, velocidade de transmissão e processamento nos equipamentos são os principais fatores que influenciam na latência de uma rede. O primeiro corresponde ao tempo necessário para a propagação do sinal elétrico, sendo um parâmetro que não permite ao gerente de rede qualquer alteração. A velocidade de transmissão é controlada objetivando a adequação da rede à qualidade de serviço requisitada. Por último, quanto ao fator referente ao processamento realizado nos equipamentos, a latência pode ser influenciada por roteadores, RAS, firewalls. E, considerando a latência como um parâmetro fim-a-fim, os hosts também influenciariam no atraso, que em seu caso, vai estar relacionado com a capacidade de processamento, disponibilidade de memória, mecanismos de cache, processamento nas camadas de nível superior da rede.

Outros dois problemas que são conseqüência do atraso de pacotes são o eco e a superposição de vozes. O eco se torna um problema quando ocorre um atraso de mais de 50ms (GTA-UFRJ, 2001). Quando o eco é percebido como um problema de qualidade, o sistema VoIP deve arrumar uma maneira de cancelar este efeito. A superposição de vozes começa a ficar significativo se o atraso em um dos sentidos de propagação da informação torna-se maior que 250ms. (GTA-UFRJ, 2001)

Para ilustrar, a Figura 18 mostra o nível de satisfação dos usuários em comparação ao atraso da voz.

Figura 18 – Influência do Atraso na Qualidade da Voz (Lustosa, 2005)

2.6.8.1 Eco

Eco ocorre geralmente na parte analógica de uma conexão telefônica. Uma outra origem pode ser identificada em uma reverberação acústica do speaker para com um microfone, por exemplo.

Quando combinado a um baixo atraso, o fenômeno pode não ser percebido, mas se mesclado a uma quantidade significativa de atraso, os efeitos se tornam críticos para o desenvolvimento da conversa entre os dois lados.

Dentre os principais tipos de eco, existe o eco de quem fala, que se caracteriza quando parte da voz da pessoa que fala retorna ao próprio emissor da mensagem. Também existe o eco do ouvinte, no qual aquele que está escutando, ouve a mensagem original, e instantes depois, a escuta novamente. Ainda existe o eco de convergência que ocorre no início de uma conversa.

Normalmente, gateways VoIP apresentam um controlador de eco. No caso deste não estar resolvendo a situação, deve-se identificar a origem do eco, verificar seu balanceamento e configuração, e então, haverá a identificação do porquê o controlador não está sendo eficaz. (Echo, 2006)

2.6.9 Jitter

Jitter é uma variação estatística do atraso na entrega de pacotes sucessivos de dados. Uma variação elevada produz uma recepção não regular dos pacotes. Uma das formas de minimizar esta variação de atraso é a utilização de buffer, o qual vai armazenando os dados à medida que chegam e os encaminham para a aplicação a uma mesma cadência. (UnderstandJitter, 2006)

Mark Santkuyl (WhatisJitter, 2005) define jitter como algum distúrbio periódico nos pulsos de onda, quando esta é submetida a um sinal digital de alta freqüência. Esse deslocamento de sua localização ideal pode ser caracterizado em termos de amplitude, faseamento, ou

largura do pulso do sinal. Dentre suas causas conhecidas estão a interferência eletromagnética e o conseqüente crosstalk de outros sinais. Ao falar sobre um contexto específico do VoIP, Santkuyl afirma que jitter é a variação entre as chegadas dos pacotes no destino, causado pelo tráfego da rede, mudanças na rota e timing drift. Uma solução que atenua seu efeito é o uso de bufferização. Segundo (Lustosa, 2005), para uma variação de atraso na rede de delta, é necessário um tamanho de buffer igual 2 deltas.

Um estudo mais detalhado sobre o fenômeno de jitter pode ser encontrado em (Jitter and Timing, 2005).

2.6.9.1 Crosstalk

Também conhecido como diafonia. Crosstalk é uma medida da interferência elétrica gerada em um fio (par) pelo sinal que está trafegando em um fio adjacente dentro do mesmo cabo. Sua ocorrência se dá porque quando um dado está sendo transmitido em um fio, ele gera um campo eletromagnético, e no caso haja a presença de algum outro fio dentro deste campo eletromagnético, este fio adjacente capturará o sinal e, modificará seu próprio sinal que estava sendo transmitido (Torres, 2005). Este fenômeno resulta em efeitos como determinada pessoa falando ao telefone, ouvir conversações de terceiros (Pinheiro, 2004).

2.6.9.2 Timing Drift

Timing drift é um fenômeno que ocorre quando o clock do sistema que envia os dados está em uma velocidade diferenciada em relação ao clock do sistema que recebe os dados. Baixas taxas de drift, considerando que o fenômeno pode atingir picos de 60 microssegundos por segundo, podem causar um leve desgaste no áudio, que normalmente é corrigido automaticamente pelo sistema em períodos de não-envio de dados (períodos de silêncio). Altas taxas de drift podem caracterizar mau-funcionamento do hardware, como por exemplo, conseqüência de uma alta temperatura no sistema.

Uma solução proposta envolvendo Linux é que este apresenta um método para configurar o clock interno do sistema, o que junto com as especificações da rede e dos equipamentos utilizados, pode representar uma atenuação do efeito de timing drift. (Timing Drift, 2006)

2.6.10 Perda de Pacotes

Redes IP não podem garantir que todos os pacotes serão entregues corretamente, muito menos que eles irão chegar na ordem. Pacotes poderão ser perdidos devido a períodos de pico e congestionamento da rede. Devido à particularidade na transmissão e à natureza da voz, o sistema de retransmissão normal do TCP não é satisfatório. Procedimentos para compensar a perda de pacotes incluem interpolação de discurso, com retransmissão do último pacote e o envio de informação redundante. Segundo (VOIP-CTI, 2005), a condição de rede para VoIP implica que a perda de pacotes não deve exceder 1%, normalmente resultantes de eco. Da mesma forma, (Lustosa, 2005) diz que perdas na rede e descartes no buffer de compensação de jitter não devem ultrapassar 1% para chamadas de alta qualidade.

2.7 Soluções para a Implementação de VoIP

Dos mais variados problemas existentes para a telefonia e comunicação de dados, quase todos são sanáveis com soluções proprietárias. Já faz algum tempo que empresas e até mesmo usuários finais desses serviços buscam soluções que visam melhor custo/benefício, ou seja, uma integração entre hardware de baixo custo e alta eficiência integrado a um software que apresente baixo preço de licenciamento e funcionalidade ampla.

No caso da telefonia IP, a CISCO1 lançou no mercado há quase três anos, seu PABX IP — chamado Call Manager. O mercado mundial já adotou esta tecnologia e a CISCO está vendendo cerca de 3000 telefones IP por dia, enquanto o mercado de PABX tradicional já caiu mais de 20%. A CISCO possui clientes com mais de 50.000 telefones IP instalados, segundo (CISCO, 2006).

Segundo (Korelc, 2006), em relação a VoIP, uma solução que faz muito a um custo baixo, de forma eficiente é o Asterisk. Isto porque o Asterisk usa o Linux, que é conhecido por funcionar facilmente junto ao hardware x86/AMD legado (entre outros), o que pode significar que uma commodity como de um servidor Asterisk pode ser montado a partir de componentes catados no mercado ou mesmo existentes dentro de casa.

Ele não é a solução única, mas é uma das que melhor viabiliza a construção de projetos de qualquer porte para telefonia convencional, e que suporta voz sobre IP.

2.7.1 Asterisk

“O Asterisk é uma plataforma híbrida TDM de código aberto e uma plataforma PBX de voz por pacotes com funcionalidades ACD” (Mark Spencer, criador do Asterisk)

O nome Asterisk foi escolhido porque tanto era uma tecla do telefone comum como também um símbolo com sobrecarga, multiuso, no Linux, ou seja, a intenção era que o Asterisk fizesse de “tudo” em relação à telefonia. Suas funcionalidades serão descritas posteriormente, mas aplicações de telefonia incluem call bridging, conferências, correio de voz, auto-atendimento, scripts de IVR customizados, call parking, intercom e outros.

O Asterisk é uma plataforma de telefonia convergida, de código-fonte aberto, projetado para rodar em ambiente Linux. A força do Asterisk está em sua estrutura personalizável, complementada por padrões de conformidade sem comparação. Nenhum outro PBX pode se desdobrar em tantas e tão criativas formas como correio de voz, conferência, ordenamento de chamadas, música em espera e chamadas em espera, que são montados diretamente no software (Meggelen & Smith & Madsen, 2005).

O Asterisk pode parecer desanimador e complexo para um usuário principiante, sendo essa a razão pela qual a documentação é tão importante para o seu desenvolvimento.

O Asterisk é desenvolvido para permitir que novas interfaces e tecnologias sejam adicionadas/agregadas facilmente. Essa sublime meta é para suportar qualquer tipo de

1 Cisco Systems, Inc. é uma companhia sediada na Califórnia, fornecedora de equipamentos de telecomunicações, destacando-se fortemente no mercado de equipamentos de interconexão.

tecnologias telefônicas possíveis. A lista dos últimos protocolos e hardware compatíveis pode ser encontrada em http://www.digium.com ou http://www.asterisk.org.

2.7.1.1 Arquitetura do Asterisk – Visão Geral

A arquitetura do Asterisk é fundamentalmente simples, mas diferente de alguns produtos de telefonia existentes. Essencialmente, o Asterisk atua como um middleware2, conectando tecnologias de telefonia no nível mais baixo até softwares de telefonia no nível mais alto, criando um ambiente consistente para construir um ambiente misto de telefonia (AsteriskBrasil.org, 2006).

Tecnologias de telefonia podem incluir serviços VoIP como SIP, H.323, IAX ou MGCP (gateways e fones), assim como as tradicionais tecnologias TDM como T1, ISDN, PRI e serviços PSTN, BRI, entre outros.

2.7.2 Open SER

Segundo (VOIP USER OSER, 2005), OpenSER é um projetado derivado do SER. A inspiração para o seu desenvolvimento surgiu da escassez de progresso e contribuições para o projeto SER. Há o interesse de se acelerar a integração das contribuições do público para o projeto SER. Como se trata de código livre, OpenSER propõe uma nova política de gerenciamento, com a intenção de gerar mais dinamismo para o desenvolvimento SIP no mundo.

2.7.2.1 Arquitetura

Alguns dos módulos que compõe o projeto OpenSER são:

ACC – Módulo accounting

ALIAS_DB – Módulo de aliases do banco de dados

AUTH – Módulo da interface de autenticação

DISPATCHER – Módulo dispatcher (balanceador de cargas)

DOMAIN – Módulo de suporte multi-domínio

GROUP – Módulo de grupos de usuário (com backend de banco de dados)

LCR – Módulo de roteamento de custo mínimo

MEDIAPROXY – Módulo de NAT traversal

MSILO – Módulo que provê armazenamento de mensagens offline

PDT – Módulo tradutor prefixo para domínio

PERMISSIONS – Módulo de controle de permissões2 Middleware é um neologismo criado para designar camadas de software que não constituem diretamente aplicações, mas que facilitam o uso de ambientes de tecnologia da informação. A camada de middleware concentra serviços como identificação, autenticação, autorização, diretórios, certificados digitais e outras ferramentas para segurança, além do armazenamento persistente, naming (nomeação), dentre outros.

PIKE – Módulo detector de flood

REGISTRAR SIP – Módulo de implementação registrar

SMS SIP-to-SMS IM gateway – Módulo SIP para SMS IM gateway

SPEEDDIAL – Módulo de controle de velocidade de discagem por usuário

TEXTOPS – Módulo de operações de texto

TM – Módulo transacional (stateful)

USRLOC – Módulo de implementação de localização do usuário

XLOG – Módulo de logger avançado

Demais módulos podem ser vistos em (Doku OpenSER, 2007) ou (OpenSER 1 Modules, 2006).

2.7.2.2 Características Gerais

Dentre as principais características gerais, podem ser citadas:

SIP robusto e ativo – servidores registrar, location, proxy e de redirecionamento;

Footprint pequeno – o arquivo binário é pequeno, pode ser alterado através dos módulos;

Processamento stateless e transactional statefull SIP proxy;

Linguagem de script – para o arquivo de configuração. Apresenta uma sintaxe similar às linguagens de script, essa configuração oferece formas flexíveis para deploy de serviços SIP customizados;

Pseudo-variáveis – para acessar e gerenciar partes das mensagens SIP e atributos específicos para usuários e servidor;

Capacidades de logging – pode registrar mensagens customizadas, incluindo cabeçalhos ou pseudo-variáveis, e partes da estrutura da mensagem SIP.

Demais características gerais podem ser vistas em (OpenSER Features, 2007).

2.7.2.3 Características de Configuração

2.7.2.3.1 Arquiteturas

OpenSER é suportado nas arquiteturas Linux/i386; Linux/armv4l; FreeBSD/i386; OpenBSD/i386; Solaris/sparc64; NetBSD/sparc64. Para outras arquiteturas, o arquivo de configuração deve ser editado.

2.7.2.3.2 Requisitos

A Figura 19 cita os principais requisitos que um sistema deve apresentar para suportar o OpenSER sob determinados aspectos.

Para FreeBSD/OpenBSD/NetBSD: certifique-se de que gmake, bison ou yacc & flex estão instalados.

Para Solaris: assim como o anterior, pode ser usado o Solaris's yacc ao invés do bison. Necessita-se precisar também do gtar e ginstall.

Outros detalhes sobre a configuração necessária e procedimentos para instalação podem ser encontrados em (OpenSER Installation, 2007).

Figura 19 – Requisitos de ambientes variados do OpenSER (OpenSER Installation, 2007)

2.7.2.4 Serviços Providos

Dentre os principais, podem ser citados:

Suporte para camadas de transporte UDP/TCP/TLS;

Suporte a IPv4 e IPv6;

Suporte multi-homed e multi-domain;

Interface de gerenciamento – via arquivo FIFO e sockets Unix;

Autenticação, autorização e accounting (AAA) – via database (MySQL, Postgress, outros), RADIUS e DIAMETER;

Autenticação por IP;

Suporte ao NAT traversal – para tráfegos de SIP e RTP;

Suporte para replicação – REGISTER oferece novas funções para replicar informações do cliente (fonte real e socket recebido);

Gateway para SMS ou XMPP;

Multiple database backends – MySQL, PostgreSQL, e outros tipos de banco de dados com drivers unixodbc.

Demais serviços podem ser vistos em (OpenSER Features, 2007).

2.7.2.5 Benefícios

Dentre os principais benefícios, podem ser citados:

Roteamento de custo mínimo;

Repositório de grande extensão – mais de 50 módulos podem ser incluídos no repositório do OpenSER;

Arquitetura modular – interface plug-and-play para estender a funcionalidade do servidor;

Balanceamento de carga com failover;

Módulo de interface plug&play – possibilidade de serem adicionadas novas extensões sem necessitar acesso ao núcleo (core), garantindo grande estabilidade para os componentes do núcleo;

O sistema pode ser altamente escalável adicionando mais servidores OpenSER;

OpenSER pode ser usado em plataformas VoIP distribuídas geograficamente.

Demais vantagens podem ser vistas em (OpenSER Features, 2007).

2.7.3 sipX

O sipX é um PBX IP, que segundo (SipX Overview, 2007), além de suportar voz e vídeo, apresenta a premissa de que a comunicação em tempo real deve ser como email, ou seja, um sistema global interoperável que permite troca de informações em tempo real, seja esta de qualquer tipo (voz, vídeo, IM).

2.7.3.1 Arquitetura

Segundo (SipX Architecture, 2007), o sipX foi construído em arquitetura modular com diferentes componentes que se comunicam sobre TCP/IP em sua maior parte.

Seu design foi planejado para suportar uma arquitetura completamente distribuída, na qual diferentes características são providas por servidores que se comunicam através do

protocolo SIP. Existe separação entre mídia e sinalização, o que permite a construção de um sistema escalável globalmente junto com a redundância necessária e a tolerância a falhas. Streams de mídia, uma vez configurados, caminham diretamente entre os end-points (phones e gateways) sem qual requisito extra para a mídia atravessar um servidor de sinalização central.

Na Figura 20, é demonstrado um diagrama representativo da arquitetura do sipX.

Figura 20 – Diagrama da Arquitetura do sipX (SipX Architecture, 2007)

Na respectiva arquitetura, destacam-se as camadas Configuration Server e Media Server. O primeiro é um sistema de gerenciamento de configurações baseado em Web Services, que oferece plug & play para os componentes do núcleo, todos servidores, assim como periféricos (phones e gateways). Também se comunica com outros componentes do servidor sipX através do arquivo de sistema ou da interface XML RPC. Por sua vez, o Media Server provê voicemail e serviço auto-attendant; é baseado em VXML através do uso da biblioteca do OpenVXI, que é um interpretador VXML de código aberto.

Para maior detalhamento deste servidor e da arquitetura geral, as informações estão disponíveis em (SipX Architecture, 2007).

Para uma especificação técnica das bibliotecas dos servidores de aplicação, comunicação e configuração, o conteúdo está apresentado em (sipX Architecture & Library Dependencies, 2007).

2.7.3.2 Características gerais

A seguinte especificação técnica é encontrada em (sipX Features Complete List, 2007). O sipX como o próprio nome já demonstra, apresenta uma implementação baseada em SIP. Sua especificação é relatada nas seguintes RFCs:

RFC 3261 – SIP utilizando transporte UDP e TCP;

Controle de chamadas avançado:

RFC 3515 – Método de referência;

RFC 3891 – Substituição de cabeçalho;

RFC 3892 – Mecanismo referred-by;

RFC 3263 – Localização de servidores SIP – uso dos registros de servidores DNS para controle de roteamento de chamadas e redundância de servidor;

RFC 3581 – Symmetric Response Routing (rport);

RFC 3265 – SIP Event Notification - for phone configuration;

RFC 3842 – Voice mail message waiting indication (MWI);

RFC 3262 – Reliable Provisional Responses;

RFC 2833 – Out-of-band DTMF tones;

RFC 3264 – Offer/Answer model for SDP for Codec Negotiation;

Early media (SDP em 180/183);

SDP atrasado (SDP em ACK);

Re-INVITE: Codec change, hold, off-hold;

Campos de cabeçalho roteamento/registro(record)-roteamento;

Portas RTP/RTCP configuráveis;

Portas SIP configuráveis.

2.7.3.3 Características de configuração

2.7.3.3.1 Requisitos de Hardware

Entre os requisitos de hardware destacam-se o servidor com compatibilidade Intel (VIA C3/C7, Pentium III, Pentium 4, Core 2 Duo, AMD, Xeon); Min RAM 256MB, 1GB preferencialmente; sistema operacional Linux (RHEL ou Fedora preferencialmente); Não há necessidade de outro hardware específico.

O sipX pode ser utilizado com qualquer dispositivo compatível com SIP. A lista, a seguir, apresenta dispositivos com propriedade plug & play:

Polycom SoundPoint IP 301, 430, 501, 601, 650;

Polycom SoundStation IP 4000 SIP;

Snom 300, 320, 360;

Grandstream BudgeTone, HandyTone;

Grandstream GXP2000;

Hitachi IP3000 and IP5000 WiFi phones;

Cisco ATA 186/188, 7960, 7940, 7912, 7905.

2.7.3.3.2 Requisitos de Software

Dentre as plataformas que o sipX suporta podem ser encontradas:

Fedora Core 5– suportado a partir do sipX 3.6. Instalação e atualização são feitas em RPM e yum. Não precisa de instalações adicionais ou scripts de atualização;

CentOS 4 – grande parte da documentação para Fedora se aplica ao CentOS;

Debian Sarge – a aplicação sipX é completamente integrada ao sistema de gerenciamento de pacotes do Debian. Usando os arquivos providos (.deb archives), o sipX pode ser instalado com apt-get install sipxpbx;

OpenSuSE 10.0 – por causa de uma incompatibilidade entre a biblioteca pcre interna do servidor Apache 2.0 usado no SuSE e a biblioteca pcre externa indispensável pela sipX, a autenticação do usuário no portal voicemail não funciona;

OpenSuSE 10.1 – apresenta o Apache 2.2 que resolveu a questão da biblioteca pcre do SuSE 10.0;

Gentoo 2005.1 / 2006.0 – mesmo problema apresentado no SuSE 10.0. Entretanto, o Apache 2.2 está disponível em ~x86;

Ubuntu / Kubuntu Dapper Drake – sipX é completamente integrado ao sistema de gerenciamento de pacotes do Ubuntu;

openSolaris/ Sun Solaris 10/ Apple Mac OS X/ Windows Server 2003 – ainda não estão disponíveis, mas vêm sendo implementados.

O complemento de informações pode ser visto em (sipX Different Platforms, 2007). Informações sobre configurações do servidor sipX estão disponíveis em (sipX Configuration Server, 2007).

2.7.3.4 Serviços Providos

Para uma lista completa de serviços do sipX, consulte (sipX Features Complete List, 2007). Dentre os quais, destacam-se:

Número ilimitado de gateways PSTN e trunk lines;

Suporte a qualquer gateway adaptável ao SIP (ex.: Cisco, Audiocodes, Mediatrix, Vegastream, Patton, etc.);

Roteamento de mínimo custo;

Integração com LDAP;

Interface SOAP Web Services;

Suporte para DNS SRV;

Logging customizável;

Reboot automático após queda de energia;

HTTPS para acesso à Web.

2.7.3.5 Benefícios e Limitações

Segundo (sipX Features, 2007), algumas das características que tornam o sipX atrativo como solução VoIP são:

IP PBX robusto, estável e fácil de usar;

Sistema oferece gerenciamento plug & play de todos os componentes;

É um sistema de missão-crítica, portanto apresenta propriedade de alta disponibilidade;

Roteamento da mídia é peer-to-peer e não através do PBX, o que fornece mais garantias de qualidade;

Ampla escalabilidade – sipX suporta deployments de até 5.000 usuários conectados a um servidor redundante;

Número ilimitado de chamadas simultâneas e número ilimitado de trunks usando gateways distribuídos.

2.7.4 Freeswitch

De acordo com (FreeSWITCH, 2007), FreeSWITCH é uma aplicação de telefonia de código aberto escrita em linguagem C, construída para aproveitar um número máximo possível de bibliotecas de software. Ele torna possível construir um sistema PBX de código aberto, e até possibilita a agregação de várias tecnologias como SIP, H.323, IAX2, LDAP, Zeroconf, XMPP/Jingle, dentre outras. Por fim, FreeSWITCH também pode ser usado com outros sistemas PBX livres, dentre os quais OpenPBX, Bayonne, YATE ou Asterisk. Ressalta-se que o projeto FreeSWITCH ainda não foi oficialmente lançado, espera-se que o seja ainda no primeiro semestre de 2007.

2.7.4.1 Arquitetura

Para ilustrar a arquitetura do projeto FreeSWITCH, foi adaptada uma imagem com as principais bibliotecas tidas como padrões para o projeto, apresentadas na Tabela 3.

Nome da BibliotecaMóduloFunçãoapr/apr-utilfreeswitchIntegração com o APACHECurlmod_php, mod_spidermonkey, mod_xml_rpcIntegração com PHP, RPCDingalingmod_dingalingPara conversas no GoogleTalk, parte do projeto FreeSwitchEtpanmod_spidermonkeyEmailJsmod_spidermonkeyJavascriptHowlmod_zero_confImplementação para ZeroConfIaxmod_iaxIntegração com IAXiksemelmod_dingaling, mod_xmpp_eventXML parser com suporte Jabberopenldapmod_ldapCliente ldapportaudiomod_portaudioDispositivo que dispõe API para escrita / leitura de arquivos de áudiopcrefreeswitchExpressões Regularessndfilemod_sndfileBiblioteca para leitura / escrita de arquivos de áudiosofia-sipmod_sofiaAgente do usuário SIP da NokiaspeakupfreeswitchBuffer de Jitterspeexmod_speexCodec de Áudio de Xiph.orgg726mod_g726Codecg7xxmod_g722Codecgsmmod_gsmCodecilbcmod_ilbcCodec para baixo bit ratelpc10mod_lpc10CodecsrtpfreeswitchSecure RTPteletonefreeswitchDetecção de tom DTMFxmlrpcmod_xml_rpcIntegração XML, RPCTabela 3 – Adaptação da biblioteca padrão do projeto (FreeSWITCH Dependencies, 2007)

A Figura 21 está presente na documentação oficial do FreeSWITCH, que mostra uma adaptação do diagrama de colaboração da Core Library, principal módulo do projeto, também essencial para o entendimento da arquitetura.

Figura 21 – Principais Bibliotecas do FreeSWITCH (FreeSWITCH Docs, 2007)

Para maiores informações sobre a arquitetura do FreeSWITCH, as especificações podem ser encontradas em (FreeSWITCH Docs, 2007) e (FreeSWITCH Dependencies, 2007).

2.7.4.2 Características Gerais

Foi desenvolvimento em linguagem C;

Roteamento para SIP, IAX2, Jingle/Jabber, Woomera/H.323;

Compila e executa em vários sistemas operacionais, tais como Windows; OSX; Linux; Solaris, Windows Mobile/CE;

Suporte a várias linguagens e scripts, por exemplo C; C++; Perl; JavaScript; Python e Ruby.

2.7.4.3 Características de Configuração

2.7.4.3.1 Requisitos de Software

FreeSWITCH foi desenvolvido nas seguintes plataformas:

Linux (x86 & x86_64)

Windows (MSVC 2005)

Mac OS X (intel & ppc)

OpenBSD, FreeBSD 6

2.7.4.3.2 Dependências

FreeSWITCH faz grande uso de bibliotecas externas, dentre as quais, destacam-se:

APR/APR-Util (http://apr.apache.org);

SQLite (http://www.sqlite.org);

Pcre (http://www.pcre.org/);

SRTP (http://srtp.sourceforge.net/srtp.html).

De forma adicional, os módulos externos experimentais utilizam alguns outros módulos externos. Para tal verificação, as informações e links estão disponíveis em (FreeSWITCH Docs, 2007).

2.7.4.4 Serviços Providos

Dentre os serviços providos podem ser destacados:

Suporte para TDM cards;

Suporte para soundcard, no caso de tornar o FreeSWITCH em um softphone;

Compatibilidade tanto com 8kHz, como valores acima de 32kHz;

Suporte a aplicações extensíveis através de Javascript Perl, Python, C, Ruby;

Interface de evento network enabled (TCP socket para FreeSWITCH ou multicast);

Suporte CDR em vários formatos;

Suporte TTS;

Suporte SS7 via http://www.ss7box.com;

Gerenciamento Multi-lingual Speech Phrase integrado;

Vários formatos de dialplan (ldap, directory and xml);

Suporte para Zeroconf e XML RPC.

Demais serviços podem ser encontrados em (FreeSWITCH Wiki, 2007).

2.7.4.5 Benefícios e Limitações

Foi desenvolvido para suportar um número máximo possível de bibliotecas (FreeSWITCH, 2007);

Atinge 16 kiloHertz em switching de chamadas – tradicionalmente chamadas VoIP operam em 8kHz (Minessale II, 2006).

3. Mobilidade

3.1 Dispositivos Móveis

Os dispositivos móveis objetivam a comunicação entre pessoas e a obtenção de informações, seja qual for o lugar, seja qual for o momento. Dentre os tipos mais comuns, citam-se pagers; telefones celulares; webphones; pagers bidirecionais; PDAs; aparelhos móveis para acessar a Internet. Uma lista de dispositivos cuja estimativa não pode ser outra além de um crescimento ainda mais intenso através de um esforço conjunto rumo a uma maior inclusão digital da sociedade.

É fato que a tecnologia da informação se tornou indispensável no cotidiano das pessoas e das empresas. Um dos maiores escopos de dedicação dos tecnólogos, atualmente, é tornar o acesso a determinadas aplicações, algo menos associado e dependente da utilização de dispositivos fixos. A mobilidade que o celular vem propiciando ainda não atingiu seu ápice. Entretanto, o desenvolvimento das tecnologias wireless como a 2,5/3ª geração do celular que oferece conectividade de dados por pacotes e o WiFi/Wimax abriram novas alternativas para implantação de aplicações móveis.

Um ponto importante sobre mobilidade é saber que aplicativos móveis e aplicativos wireless não representam sinônimos. Segundo (Tude Arquitetura, 2005), o conceito de mobilidade é amplo e pode ser interpretado de várias formas, dentre elas em um contexto passado, as aplicações iniciais de sistemas celulares visavam, por exemplo, prover telefones para automóveis, e sua interpretação estava associada a dispositivos em movimento durante a comunicação; em um contexto atual, a idéia de mobilidade em sistemas celulares está associada à possibilidade de se comunicar de qualquer lugar a qualquer instante. Por sua vez, wireless se refere à transmissão multimídia através de ondas de rádio, explicitando uma idéia de comunicação sem fio. Os PDAs convencionais são um exemplo de dispositivos móveis que não são wireless.

A Figura 22 exemplifica alguns dispositivos que retratam a diferença entre aplicativos móveis e wireless.

Figura 22 – Dispositivos Móveis e Wireless (Tude Arquitetura, 2005)

Nas próximas seções, o foco estará voltado para a telefonia celular. Será explorado o contexto em que atuam os aparelhos portáteis celulares, de forma a explicitar suas principais características em relação à transmissão. Neste caso, será explorada a base da arquitetura celular, com detalhamento sobre seus componentes, requisitos para a comunicação móvel, bem como as singularidades dos diferentes padrões que a caracterizaram durante sua evolução.

3.1.1 Arquitetura PCS

Em se tratando especificamente de telefonia celular digital, uma importante arquitetura em questão é a PCS. Ela abrange os padrões CDMA, GSM e D-AMPS, tratados nas próximas seções. Segundo (Chlamtac & Lin, 2001), esta arquitetura é dividida em duas partes: Radio Network e Wireline Transport Network, cujo modelo é apresentado na Figura 23.

Na Radio Network, os usuários possuem um aparelho móvel (MS). Cada MS está associado a uma estação-base (BTS) com a qual as estações se comunicam por enlaces sem fio. Um setor de BTSs é gerenciado por controlador de estações-base (BSC), sendo que este gerenciamento é feito executando handoffs e alocando canais.

O Wireline Transport Network, por sua vez, apresenta o MSC, que vai estar conectado ao BSC e à rede de telefonia pública, e é o coordenador de registros de localização e direcionamento das chamadas. Anexado ao MSC está o VLR, que é o banco de dados local. O VLR apresenta as informações sobre os MS que estão de passagem pelo setor de atuação da MSC. Por fim, associado diretamente à rede de telefonia pública está o HLR, que é o banco de dados global sobre todas estações da rede.

Figura 23 – Arquitetura PCS

Para um melhor entendimento sobre mobilidade também é necessário o esclarecimento de dois outros aspectos presentes na arquitetura PCS: Handoff e Roaming.

De acordo com (Chlamtac & Lin, 2001), handoff acontece no momento em que um usuário se movimenta da área de cobertura de sua BTS para um setor de outra BTS. Neste momento, o radio link para a BTS original é desconectado, e uma nova conexão para a nova BTS deve ser estabelecido para que seja mantida a possibilidade de comunicação. O aspecto também pode ser conhecido como automatic link transfer ou handover.

Roaming é definido também por (Chlamtac & Lin, 2001) como sendo a movimentação do MS de um sistema PCS para outro sistema PCS. No caso, um exemplo seria um usuário de Brasília estar de passagem por São Paulo. O sistema de origem deve ser informado sobre o sistema atual do usuário, caso contrário não será possível a comunicação.

Uma especificação detalhada sobre os tipos de handoff e o tratamento de roaming é encontrada em (Chlamtac & Lin, 2001).

3.1.2 CDMA

A tecnologia CDMA apresenta o padrão de celulares da segunda geração, tendo sido desenvolvido principalmente pela Qualcomm, sendo muito difundido nos Estados Unidos. Sua arquitetura apresenta as características PCS apresentadas na subseção anterior. Nota-se também que o padrão CDMA é conhecido fora do Brasil como IS-95 ou cdmaOne. Atualmente, é apresentado como CDMA2000, um padrão de geração híbrida (2,5/3G).

Segundo (Tude CDMA, 2003), esta tecnologia utiliza espalhamento espectral (Spread Spectrum) como meio de acesso para permitir que vários usuários possam compartilhar uma mesma banda de freqüências. Nesta técnica, o sinal de informação é codificado utilizando-se uma chave de código que provoca o seu espalhamento espectral em uma banda, transformando-o aparentemente em ruído. Os códigos utilizados podem ser ortogonais (Walsh) ou pseudo-noise. Maiores detalhes sobre as características da codificação podem ser pesquisados em (Tude CDMA, 2003). O CDMA permite, desta forma, uma utilização otimizada do espectro, possibilitando um aumento de capacidade dos sistemas celulares. No CDMA, cada MS possui uma identificação própria (MIN) e um número de série eletrônico (ESN).

As bandas do CDMA são divididas em canais de rádio-freqüência (radio link), sendo que cada canal apresentará um par de freqüências – transmissão e recepção (Tx/Rx) – com 1,25 MHz de banda cada. (Tude CDMA, 2003) afirma que se teoricamente poderiam existir até 10 canais de radio link em uma banda de 12,5 MHz, na prática o número é menor pois esta banda é dividida com o AMPS e é necessário estabelecer uma guarda banda. A Figura 24 demonstra o carregamento de um canal no CDMA.

Figura 24 – Carregamento no CDMA (Tude CDMA, 2003)

No padrão CDMA, quanto mais usuários utilizam o canal, maior o ruído, aumentando a interferência para os canais que utilizam a mesma banda até um limiar quando não é mais possível decodificar os canais. De acordo com (Tude CDMA, 2003), esta interferência também é tanto maior, quanto maior for a potência individual de cada canal transmitido naquela banda. Tal comportamento motivou o desenvolvimento de um sofisticado mecanismo de controle de potência nos MSs e BTSs de um sistema CDMA. Este controle de potência leva também à expansão e à contração do raio de uma célula CDMA de acordo com seu carregamento com tráfego.

A divisão das células em setores é usada para reduzir a interferência, uma vez que cada setor utiliza antenas direcionais e não interfere nos demais setores da célula. Um dos fatores que contribui para a capacidade satisfatória alcançada por sistemas CDMA é a possibilidade de utilização uma mesma freqüência de portadora em todas as células.

Atualmente, o padrão cdmaOne vem sendo completamente substituído para serviços de terceira geração com taxas de dados de até 2 Mbps, mas foi mantida compatibilidade com sua estrutura de canais de radio link de 1,25 MHz que apresenta taxa de dados de aproximadamente 14Kb/s (Tude CDMA, 2003).

3.1.3 GSM

Assim como o CDMA, o padrão GSM também é de segunda geração, mas foi desenvolvimento na Europa e adotado na maior parte do mundo. Foi proposto inicialmente para a faixa de 900 MHz, mas também apresentou versões para as faixas de 1800 e 1900 MHz. Neste padrão, a MS apresenta como identificador um SIM CARD, que também servirá para armazenar os dados do usuário.

GSM apresenta seus canais de radio link com cerca 200 KHz de banda cada. Nota-se que há cerca de 124 canais no GSM 900 e 373 canais no DCS 1800. Tais canais receberam uma numeração determinada ARFCN. O sinal digital gerado após modulação, cuja explicação pode ser vista em (Tude GSM, 2003), é de cerca de 270 Kbps. Enquanto o CDMA utiliza somente a técnica de divisão por freqüência, o GSM adiciona a esta, a técnica de divisão por tempo. No caso, o sinal digital é dividido em 8 intervalos de tempo.

De acordo com (Agilent, 2002), as células podem ter um raio de até 35 km no GSM900 e 2 km no DCS1800 (devido a menor potência das unidades móveis do DCS1800). As BTSs são conectadas aos seus BSC pela interface Abis, por cabo ou fibras ópticas. Esta é a interface característica do padrão GSM, que estabelece a conexão entre BTS e BSC (Mobiledia, 2007). As redes DCS1800 muitas vezes usam um link de microondas para a interface Abis. Cada BTS possuirá um certo número de pares Tx/Rx ou módulos transceptores.

Este número determinará o número de canais de freqüência que poderão ser usados na célula, o que dependerá do número esperado de usuários. Todas as BTSs produzem um canal de broadcast (BCH). O BCH está ligado todo o tempo e permite que as unidades móveis encontrem a rede GSM. A intensidade do sinal BCH é também usada pela rede em diversas funções relacionadas ao usuário, sendo um meio útil para dizer qual é a BTS mais próxima da unidade móvel. Ainda segundo (Agilent, 2002), este sinal também carrega informações codificadas, como a identidade da rede, mensagens de paging3 para as unidades móveis que devam aceitar uma chamada telefônica, e diversas outras informações. O BCH é recebido por todas as unidades móveis que estão de passagem na célula, estando ou não, no meio de uma chamada.

O canal de freqüência usado pelo BCH é diferente em cada célula. Os canais podem ser reutilizados por células distantes, nas quais o risco de interferência é baixo. As unidades móveis em chamada usam um canal de tráfego (TCH). Este é um canal bidirecional usado para a troca de informações de conversação entre a MS e a BTS. As informações são divididas em uplink e downlink, dependendo da direção do fluxo, e que são separadas em bandas de freqüências distintas. Segue na Figura 25, um esboço sobre downlink e uplink. Dentro de cada banda, o esquema de numeração de canais usado é o mesmo. Na verdade, um canal do GSM é formado por um uplink e um downlink. É interessante observar que, enquanto o TCH usa um canal de freqüência no uplink e no downlink, o BCH somente ocupa um canal no downlink. O canal correspondente no uplink é, na verdade, deixado desocupado. Este canal pode ser usado pela unidade móvel para canais não programados ou canais de acesso aleatório (RACH). Quando o MS quiser chamar a atenção de BTS para fazer uma chamada, ela poderá fazê-lo usando este canal de freqüência desocupado para enviar um RACH. Como mais de uma unidade móvel pode querer chamar a atenção da estação ao mesmo tempo, é possível que haja uma colisão de canais RACH, e talvez seja necessário que as unidades móveis façam diversas tentativas para serem ouvidas. Mais detalhes técnicos sobre o padrão podem ser encontrados em (Agilent, 2002).

A evolução do GSM para serviços de terceira geração com taxas de dados de até 2 Mbps exigiu a definição de um novo padrão para a interface entre MS e BTS com canais de rádio-freqüência de 5 MHz. Este novo padrão (WCDMA) implicará em mudanças na estrutura de canalização do GSM exigindo uma banda adicional de freqüências para implementação do serviço por parte das operadoras, mantendo no entanto, a compatibilidade e demais interfaces da arquitetura GSM.

3 Paging é um conceito que permite à unidade móvel entrar em estado de dormência, não sendo

obrigada a constantemente enviar informações sobre a sua localização. Uma mensagem de paging é enviada

para a devida unidade no caso de necessidade de se comunicar com a mesma, para que esta possa informar

sua localização na rede (Gomes & Sénica & Coelho, 2003).

Figura 25 – Downlink e Uplink (Agilent, 2002)

3.1.4 AMPS/ TDMA

Padrão também conhecido como D-AMPS. Segundo (Tude AMPS/TDMA, 2003), a primeira geração de sistemas celulares formada por sistemas analógicos, no qual o AMPS foi seu maior expoente, estabeleceu aspectos, como roaming e handoff entre células (esclarecidos na subseção 3.1.1).

O crescimento da utilização de sistemas celulares levou a necessidade do aumento da capacidade dos sistemas analógicos com a motivação para o surgimento dos sistemas digitais de segunda geração. A solução TDMA surgiu como uma opção que mantinha compatibilidade com a arquitetura e a canalização utilizada pelos sistemas AMPS tendo sido inicialmente chamada de D-AMPS.

O AMPS utiliza o múltiplo acesso por divisão de freqüência (FDMA). A Banda do AMPS é dividida em canais de rádio freqüência, onde cada canal (Tx/Rx) apresenta 30 kHz de banda. Cada banda (A ou B) ocupa 12,5 MHz e é composta por 416 canais, sendo 21 canais de controle e os demais de voz. No AMPS, um canal de voz é alocado e permanece dedicado a uma chamada durante toda a sua duração.

(Tude AMPS/TDMA, 2003) afirma que o padrão TDMA manteve toda a estrutura de canalização do AMPS, mas permitiu que um canal fosse compartilhado no tempo, por vários usuários através da técnica de TDMA. A estrutura de transmissão de dados é implementada através de um quadro de 40 ms com 6 intervalos de tempo com 6,66 ms cada. Cada chamada telefônica utiliza dois intervalos de tempo sendo, portanto, possíveis até 3 conversações utilizando a mesma banda de 30 kHz de um canal de voz do AMPS. Cada conversação tem uma taxa bruta de 16,2 Kbps.

O canal de controle no padrão TDMA (IS-36) é digital e permitia a implantação de serviços de mensagens curtas (SMS). Uma versão anterior do TDMA, o IS-54, apresentava canal de controle analógico. Os sistemas AMPS e TDMA (IS-136) utilizam geralmente um plano de freqüência no qual cada célula é dividida em três setores formando 21 grupos de freqüências (canais de voz do AMPS) reutilizados em cada grupo de 7 células.

O AMPS foi o padrão dominante para os sistemas celulares no Brasil sendo hoje utilizado basicamente para roaming. A migração das operadoras para sistemas 3G da família GSM ou CDMA implicou em uma diminuição gradual do número de terminais celulares TDMA no Brasil.

3.1.5 Padrões 3G e 4G

3.1.5.1 3G

Segundo (Teleco WCDMA, 2004), os requisitos de um sistema celular 3G são:

Altas taxas de dados: 144 Kbps em todos os ambientes e 2 Mbps em ambientes "indoor" e de baixa mobilidade;

Transmissão de dados simétrica e assimétrica;

Serviços baseados em comutação de circuitos e comutação de pacotes;

Qualidade de voz comparável a da telefonia fixa;

Melhor eficiência espectral;

Vários serviços simultâneos para usuários finais, para serviços multimídia;

Incorporação suave dos sistemas celulares de segunda geração;

Roaming global;

Arquitetura aberta para a rápida introdução de novos serviços e tecnologias.

Em (3G Frame, 2007) poderão ser visualizados alguns modelos atuais de dispositivos móveis pertencentes a 3G.

Para a tecnologia 3G, os dois principais padrões representativos são: UMTS e CDMA 2000, retratados na Tabela 4.

Tabela 4 – Padrões 3G (Teleco 3G , 2006)

3.1.5.1.1 UMTS

UMTS designa o padrão de 3ª geração estabelecido para a rede das operadoras de celular como evolução para operadoras de GSM e que utiliza como interface rádio WCDMA e suas evoluções. A seguir, a Figura 26 que explicita a arquitetura do UMTS.

Figura 26 – Arquitetura UMTS (Teleco WCDMA, 2004)

UE – é o terminal móvel e seu módulo de identidade de serviços do usuário (USIM) equivalente ao SIM card dos terminais GSM;

UTRAN – rede terrestre de acesso rádio do UMTS baseada no WCDMA;

CN – núcleo da rede que suporta serviços baseados em comutação de circuitos e comutação de pacotes;

RNS – Radio Network Subsystem – controla a alocação dos recursos de transmissão/recepção à fim de estabelecer a conexão entre a UE e a UTRAN;

RNC – Radio Network Controller – responsável pelo gerenciamento da mobilidade, processamento de chamadas e controle de handover;

Iur – é a interface entre dois RNS;

Uu e Iu são as interfaces entre estas entidades.

(Teleco WCDMA, 2004) ainda afirma que os protocolos utilizados na comunicação entre entidades nesta arquitetura procuram manter compatibilidade com os definidos atualmente para o GSM, principalmente no que se refere à parte do usuário. A maior alteração foi na sinalização SS7 utilizada de modo a suportar um o transporte de dados com taxas mais altas.

Sobre a comunicação realizada através da interface rádio do UTRAN, esta utiliza 3 tipos de canais: lógicos, que são mapeados nos canais de transporte; transporte – os quais o RNC utiliza para transportar diferentes fluxos de informação; físicos que compõem a existência física da interface Uu, conforme é demonstrado na Figura 27.

Figura 27 – Comunicação da Interface UTRAN (Teleco WCDMA, 2004)

A interface rádio Uu entre terminal do usuário e sua rede terrestre de acesso rádio (UTRAN) é baseada no WCDMA. O WCDMA é um padrão de interface rádio, entre o MS e a BTSs terminal celular e a Estação Rádio Base, desenvolvido para o UMTS.

O WCDMA tem dois modos de operação:

FDD – no qual os enlaces de subida e descida utilizam canais de 5 MHz diferentes e separados por uma freqüência de 190 MHz;

TDD – no qual o link de subida e descida compartilham a mesma banda de 5 MHz.

Por fim, o WCDMA utiliza como método de múltiplo acesso, o CDMA de seqüência direta (DS-CDMA), com os vários terminais compartilhando uma mesma banda de freqüências, mas utilizando códigos diferentes de espalhamento espectral.

Para maiores referências à modulação do sinal e integração da arquitetura com outros aspectos, as especificações estão referenciadas em (Teleco WCDMA, 2004).

3.1.5.1.2 EV-DO

De acordo com (Swart & Esteves, 2004), 1xEV-DO é um sistema de dados wireless com alta velocidade e alta capacidade que combina a conveniência da mobilidade com o desempenho de uma rede de dados fixa. 1xEV-DO representa uma solução com custo competitivo já que apenas uma BTS é capaz de entregar mais que 4Mbps de capacidade usando um canal de 1.25MHz. Essa eficiência no uso do espectro significa para as operadoras CDMA, poder transmitir muito mais dados para seus usuários com um upgrade mínimo em sua rede. A combinação de variados serviços de valor agregado com conteúdos multimídia e baixo custo por MB é a chave para aumentar a demanda e o sucesso dos serviços de dados wireless.

Um dos segmentos que pode se beneficiar com este padrão é o mercado de banda larga residencial e de pequenas empresas já que uma rede 1xEV-DO pode ser facilmente

instalada, se comparada a uma rede com fio, e pode prover uma performance similar a um serviço a cabo/DSL de 128 a 256kpbs. 1xEV-DO foi desenvolvido para operar em uma portadora de 1,25MHz, ocupando a mesma quantidade de espectro utilizado nos sistemas CDMA anteriores (cdmaOne, cdma2000 1x).

Devido às características similares de radio link, é bastante natural a integração do 1xEV-DO com as redes CDMA existentes reutilizando infra-estrutura das BTSs, antenas e equipamentos de transmissão e recepção. Essas similaridades também permitem aos fabricantes de terminais 1xEV-DO aproveitar o significativo mercado CDMA.

Outra vantagem do 1xEV-DO é que alocando um canal de freqüência para transportar apenas pacotes IP, tem-se como resultado o uso eficiente dos recursos da rede permitindo a transmissão de dados de até 2.4Mbps no downlink.

1xEV-DO está preparado para operar nas faixas de freqüência de 450MHz, 850MHz e 1,9GHz. Quanto a sua taxa de transmissão, um exemplo fornecido por (Swart & Esteves, 2004) foi o download de um arquivo MP3 de 4MBytes que levaria, em média, 25 minutos em GPRS, 8 minutos em 1xRTT e somente 50 segundos com o 1xEV-DO.

A taxa de transmissão máxima de dados na rede 1xEV-DO é de 2,45 Mbps (real, não apenas teórico). Entretanto, como em outros sistemas celulares, enquanto o usuário se move na área de cobertura de uma BTS, ele experimentará boas e más condições de sinal, reduzindo a taxa média efetiva para cerca de 700 Kbps. No upload, o usuário tem taxas de dados de até 153Kbps, enquanto que a média de capacidade do setor da BTS fica em torno de 350 Kbps. Toda explicação sobre sua arquitetura, algumas outras características e uso de protocolos é especificada em (Swart & Esteves, 2004).

3.1.5.1.3 Tabela complementar

Apenas para fim complementar, segue a Tabela 5 que ilustra a situação recente da telefonia celular no mundo.

Tabela 5 – Assinantes no Mundo (GSM World, 2006)

3.1.5.2 4G

Há consenso quanto aos seus principais aspectos, mas ainda não existe uma definição mundialmente aceita dessa futura rede. Os especialistas concordam em que a 4G deverá unificar as diferentes redes wireless, incluindo (LANs) wireless nas diversas tecnologias existentes (IEEE 802.11, HiperLAN/2, bem como as redes de área pessoal, como Bluetooth). Também é esperada integração não apenas das redes públicas fixas e celulares, mas especialmente da ampla rede de outros equipamentos móveis (laptops, PDAs, supercâmeras digitais etc.) que por seu intermédio farão o roaming, nas diversas áreas geográficas e de concessão de operadoras. Essa rede 4G deve também interligar WANs, permitindo que se conecte laptops e outros dispositivos móveis a uma infinidade de novos provedores de novos serviços wireless, praticamente em diversos pontos do país (Wireless Brasil 4G, 2006). Alguns padrões que estão sendo estabelecidos para 4G são o WiMax e o WiBro, que podem ser entendidos respectivamente em (WiMax.com, 2007) e (WiBro, 2007).

Um importante diferencial entre 4G e 3G é o aumento da taxa de transmissão. Segundo NTT-DoCoMo (Whatis 4G, 2006), companhia de wireless japonesa, enquanto a velocidade para i-mode (mobile internet service) é teoricamente de 9.6 Kbps, o que na prática tende a ser menor, a taxa de transmissão do 3G atinge cerca de 200 vezes isto, enquanto 4G poderia atingir cerca de 20-40 Mbps (cerca de 10-20 vezes a velocidade padrão do serviço ADSL).

3.2 Aspectos do Desenvolvimento para Dispositivos Móveis

O desenvolvimento para dispositivos móveis pressupõe a existência de uma infra-estrutura apropriada ao seu projeto e execução, ou seja, requer a existência de uma plataforma de suporte a serviços móveis, e que esteja conceitualmente preparada para trabalhar com um ambiente altamente dinâmico, com certa limitação física, seja de espaço, seja em memória, com constantes mudanças nos recursos disponíveis e nos requisitos do usuário. Para tal, questões centrais, acerca do desenvolvimento da interface e das plataformas de desenvolvimento, foram propostas.

3.2.1 Questões para Desenvolvimento da Interface

Segundo (Mosimann Netto, 2005), a questão central no desenvolvimento de interface para dispositivos móveis está no equilíbrio entre design e diagrama de navegação dos sistemas. O primeiro irá consistir em menus, logomarcas e torna o sistema como algo maior que um simples formulário. O diagrama de navegação consistirá no caminho que o usuário do sistema deverá fazer para chegar a um determinado ponto.

Os sistemas móveis devem ser projetados levando em consideração os limites impostos pelos paradigmas dos dispositivos, como resolução de tela, teclado pequeno, one-hand acess. (Shadish, 2004) afirma que a implementação do programa deve atender à necessidade de se utilizá-lo somente com os dedos. Logo, uma tela muito carregada de opções, as apresentará em pequena resolução, e isto, além de dificultar a visualização e entendimento, também prejudica a navegabilidade.

A seguinte questão sobre o modelo de navegação adequado foi proposta por (Shadish, 2004). Dentre as opções comuns mais válidas, existem o scrolling e a navegação paginada.

Com o scrolling, o conteúdo será exibido como uma longa página, onde a barra de rolagem é usada para navegação vertical. Método que pode ser bem adaptável, por exemplo, para a Web, ou documentos como Microsoft Word e do tipo Adobe Acrobat. Sua limitação se dá no sentido de que pode ser incômoda a movimentação da tela em certos momentos, além de existir a possibilidade de que campos de entrada posicionados fora da área visível da tela, possam ser deixados de lado, a menos que a página imponha ao usuário, o preenchimento dos campos obrigatórios.

Para resolver estes problemas, existe a opção de navegação paginada, que se dá de modo que as informações de uma tela nunca serão maiores que a área exibida pelo equipamento. Neste caso, o conteúdo é dividido em páginas separadas, e o acesso a novas páginas é efetivado ao se clicar nas abas. Se houver muitas páginas, estas abas poderão apresentar a opção anterior/posterior. A navegação paginada resolve a situação dos campos de preenchimento obrigatório, uma vez que necessariamente não irá ocultá-los, o que poderia ocorrer na opção de scrolling. A complicação da implementação por navegação paginada está na implementação das abas, devido à variação de tamanho das telas de dispositivo para dispositivo. A Figura 28 exemplifica a navegação paginada e por scrollling.

A experiência adquirida por um usuário ao longo do uso dos layouts desenvolvidos não pode ser ignorada. Segundo (Mosimann Netto, 2005), deve-se criar formas de acesso direto a módulos existentes. Não seria uma boa opção de usabilidade, forçar o usuário a navegar por cinco ou seis módulos diferentes a fim de chegar ao 7º, por exemplo.

Uma nova questão é referente ao uso das fontes de texto. Shadish afirma que é preferível optar pelo uso de apenas um tamanho de fonte em sua aplicação, se um tamanho somente não for possível, que seja o mínimo possível. O uso de negrito é uma opção interessante para a diferenciação entre campos de título ou texto.

Figura 28 – Navegação paginada e scrolling (Shadish, 2004)

Outro ponto que deve ser padronizado é o uso de cores. Ainda segundo (Shadish, 2004), quanto mais cores, mais perda de absorção da informação vai acontecer por confusão. Duas ou três cores são o recomendável para utilização em todo aplicativo. Além disso, deve-se tomar cuidado para não gerar uma dependência muito forte das cores em termos da diferenciação das seções, uma vez que existem pessoas com dificuldades visuais que ficariam impedidas de utilizar a aplicação. De acordo com (Mosimann Netto, 2005), a padronização é indispensável. Se há a criação de um menu laranja ao lado direito com os ítens do sistema em azul, o mesmo padrão deve ser seguido para todos os módulos do sistema. Não se deve criar o menu cada hora em um lugar.

Deve-se evitar esconder menus, controles ou telas inteiras da área de visão do usuário. Este procedimento frustra o usuário, principalmente quando ele usou um desses itens no passado e, agora, não consegue mais encontrá-lo na interface. O ideal seria desabilitar as funcionalidades que estão fora do contexto. Deste modo, o usuário saberá onde a funcionalidade está, sem perder tempo em procurá-la; e também saberá que a funcionalidade em questão não é apropriada ao contexto.

Outro quesito de implementação refere-se à seleção de dados pelo usuário. O implementador deve saber optar qual controle de seleção, será adequado para a situação. Deve-se saber usar radio buttons, list boxes ou combo boxes. A regra proposta é usar radio buttons, quando o usuário tiver de escolher entre três ou dois itens. Quando houver um número de escolhas suficiente para ocupar boa parte da tela, é recomendável combo box. Mas, quando o número de escolhas for grande de modo que não cabe na tela, deve-se usar list box. Ao usar um list box, é importante o recurso de localizar o registro mais próximo com a entrada do primeiro caractere, no caso de existir um número muito grande de escolhas.

Seguindo as questões de interface, é indispensável que a aplicação sempre requisite ao usuário, a confirmação de que alguma informação será apagada. Um aviso do tipo "você deseja realmente excluir [nome do que será excluído]", permitindo escolher entre sim e não, dará ao usuário uma nova chance. Uma dica de Shadish estabelece a criação de alguns níveis de undo em telas que aceitam entradas de texto em blocos. (Mosimann Netto, 2005) por sua vez, cita a importância de se alertar o usuário quanto aos erros. Deve-se evitar mensagens técnicas para leigos em programação, como por exemplo: "Não foi possível encontrar uma instância para o objeto". As mensagens devem ser simples, diretas e sempre seguindo um padrão, evitando ao máximo intimidar o usuário. Um exemplo disto seria "Seu celular poderá não mais funcionar corretamente se você fizer isso! Tem certeza do que você esta fazendo?".

Quanto aos ícones da aplicação, estes devem necessariamente representar a funcionalidade proposta através de sua imagem. Não se deve reinventar formatos e figuras, quanto mais padronizado, maior a praticidade no uso do programa.

Outro ponto é que a aplicação deve mostrar claramente os campos obrigatórios, para evitar que o usuário preencha campos que considere desnecessários, e fique sempre retornando à tela de preenchimento, no caso de alguma omissão no fornecimento dos dados. A Figura 29 demonstra uma forma de se alertar sobre os campos obrigatórios.

Figura 29 – Visualização clara dos campos obrigatórios (Shadish, 2004)

Naturalmente, a variedade de dispositivos móveis aumenta (Pocket PCs, Smartphones, dentre outros) e os padrões de tamanho de tela ou método de entrada, por exemplo, variam de plataforma para plataforma. Deve-se prever como a aplicação aparecerá e será exibida nessas diferentes plataformas, e como ela vai se comportar, para que no mínimo, os usuários que tentarem rodar sua aplicação em dispositivos incompatíveis, possam obter alguma explicação para o não-funcionamento.

Observa-se que apesar das fontes bibliográficas utilizadas no estudo específico de interfaces, serem datadas de 2004 e 2005, ainda estão válidas, uma vez que independente da evolução dos padrões móveis até o momento atual, tais questões estão presentes visando a conservação da qualidade da usabilidade e navegabilidade, propriedades centrais no desenvolvimento da interface.

3.2.2 Plataformas de Desenvolvimento

A seguir, serão expostos os aspectos relativos às principais e mais populares plataformas de desenvolvimentos para dispositivos móveis.

3.2.2.1 JavaME

O JavaME é uma plataforma para pequenos dispositivos móveis. Segundo (Teixeira & Carniel, 2006), a plataforma suporta aplicações Java comumente usadas em outras arquiteturas distinguindo-se apenas por ter uma API específica, enquanto que as demais arquiteturas fazem uso de outras APIs nativas da micro arquitetura. Como o JavaME não é composto somente de APIs, a seguir serão exibidas as suas características de configuração, segurança, restrições e perfis.

3.2.2.1.1 Configuração

(Teixeira & Carniel, 2006) afirma que a configuração mais básica e também a mais importante do JME é o CLDC – uma configuração para dispositivos móveis que utilizam baterias como fonte de energia e possuem limitações de memória e processamento. A máquina virtual utilizada pelo CLDC é a K Virtual Machine, que é adequada para dispositivos com processadores/controladores RISC/CISC de 16/32 bits e com um total de memória de 160K, dos quais 128K são utilizados para armazenamento da máquina virtual e de bibliotecas. Ela fornece base para uma outra configuração: a CDC. Esta, por sua vez, provê algumas funcionalidades adicionais e requer capacidades adicionais de hardware, pois é um framework para construção de aplicações em dispositivos integrados como pagers e decodificadores que possuem uma maior capacidade de processamento (32 bits) e de memória (2MB de RAM e 2.5MB de ROM).

3.2.2.1.2 Perfil

Um perfil é uma série de APIs padrões que, combinadas com alguma configuração, (no caso o CLDC) provê um serviço completo para a execução de aplicações específicas. Por exemplo, o MIPD é um perfil totalmente especificado para o CLDC e é destinado a aplicações para celulares como jogos, aplicativos que acessam agendas e aplicativos de envio de mensagem.

O MIDP é o perfil mais comumente utilizado. De acordo com o site “Le Club-Java” mais de 80% dos aparelhos celulares de hoje em dia suportam MIDP 2.0 e CLDC 1.1. Em (Sou Java 1, 2007) pode ser encontrada uma lista bem completa de fabricantes e modelos de celulares compatíveis com MIDP 1.0 e 2.0.

Celulares, em sua quase totalidade hoje no mercado, trabalham com o MIDP1.0/2.0 e CLDC1.0/1.1. A versão 2.0 do perfil MIDP, em relação ao MIDP1.0, possui algumas bibliotecas a mais de geração e reprodução de áudio e reprodução vídeo (no MIDP 1.0 não era possível gerar ou reproduzir som ou vídeo), a API de interface gráfica foi expandida com mais funções de jogos e a segurança é maior, pois o acesso a funções pastas, rede, portas de comunicação é protegido por meio de permissões definidas por domínios de

proteção (o MIDP1.0 não endereçava os pedidos de acesso aos recursos). Em (Teixeira & Carniel, 2006), entende-se que os perfis são mais específicos que configurações; por exemplo, a respeito de um carro, pode-se considerar como ele é fabricado (configuração) e como um modelo específico é fabricado (perfil); tecnicamente falando, perfil é baseado em configuração enquanto as APIs definem o modelo específico da marca usada.

Dos perfis de maior uso para estudos e finalidades comerciais estão o MIDP e também o PDAP - ambos estão acima do CLDC.

Para o CLDC, no mínimo, 16MHz são requeridos, e se tratando de aparelhos 'topo de linha' podem chegar até 300MHz ou um pouco mais (até o momento atual), porém é muito difícil dizer ao certo, pois o acesso a informações desse tipo nas especificações dos fabricantes é bem restrito. A conexão é lenta, tipicamente de 9.600bps para aparelhos TDMA/CDMA e de 128Kbps para GPRS/CDMA 1xRTT.

MIDP tem as seguintes características:

Mínimo de 160kB de memória não-volátil para JAVA;

Um processador de 16/32 bits com um clock de no mínimo 16MHz;

32KB de memória volátil para tempo de execução;

Pelo menos 192KB livres para Java;

8KB de memória não-volátil de para armazenamento de dados;

Uma tela de pelo menos 96x54 pixels;

Capacidade de entrada de dados seja por teclado (do celular), teclado externo ou mesmo touch-screen;

Possibilidade de enviar e receber dados em conexão possivelmente intermitente e banda reduzida.

Seguem dois comparativos, de acordo com (Borges, 2005).

Comparativo entre CLDC 1.0 e CLDC 1.1:

Inclusão de suporte a ponto flutuante (classes Float e Double);

Exigência de memória total mínima aumentada de 160Kb para 192Kb;

Melhora no modelo de threads;

Inclusão de algumas funções no pacote java.lang (Random.nextInt(int num), String.intern(), etc.).

Comparativo entre MIDP1.0 e MIDP2.0:

Incluídas componentes de GUI, além de mais recursos para gerenciamento de eventos;

Novas classes para jogos: GameCanvas, Sprite, TiledLayer, etc;

Multimedia API;

Redes (ServerSocket) e segurança (HttpsConnection);

Assinatura de MIDlets (certificados digitais) e Push Registry.

3.2.2.1.3 Segurança

Por meio do JavaME, dificilmente haveria problemas (devido à segurança fornecida pelo MIDP através da garantia de confidencialidade dos dados, via criptografia) de falha na segurança, porém já foram vistos celulares sendo atacados por vírus que exploram falhas no sistema operacional e não de uma aplicação JavaME.

A máquina virtual tem um espaço independente de memória (sand-box), e não pode acessar a memória correspondente às aplicações nativas do celular, assim como é feito com as applets, um pouco diferente do JavaSE.

3.2.2.1.4 Restrições

A CLDC 1.0 não possui suporte a ponto flutuante, ou seja, aplicações que trabalhem com contas, e valores reais terão que manuseá-los em código. A versão 1.1 do CLDC já possui suporte a ponto flutuante.

Há outras pendências como:

Sem user classLoading;

Sem finalização de objetos (finallize() de java.lang.Object);

Garbage collector existe, porém não executa método automático;

Sem RMI e JINI;

Sem métodos nativos, a não ser os fornecidos pela JVM nativa;

Multithreading (sem interrupt(), pause(), resume() e stop());

Sem thread groups e thread daemons.

3.2.2.2 .Net Compact Framework

A Microsoft .NET CF (Microsoft .NET Compact Framework) se trata de um produto da Microsoft .NET Framework. Por tal motivo, a .NET CF herdou muitas de suas características e formas de execução. Segundo (Mosimann Netto, 2006), todos os códigos desenvolvidos para serem executados sob a .NET CF são executados por um compilador de alta performance, denominado JIT. Este compilador é responsável por otimizar o código para o dispositivo onde o software será executado. Em outras palavras, o mesmo software é otimizado para ser executado em dispositivos que possuem recursos de hardware ou software diferentes. Ainda no contexto do .NET CF, há a CLR juntamente com uma coleção de classes permite uma gerência de processos otimizada para ser executada em equipamentos com limitações de processamento, memória ou display, como é o caso dos dispositivos móveis.

A vantagem trazida pela .NET CF é a possibilidade do desenvolvimento multi-linguagem. Em um mesmo projeto, pode-se construir cada módulo em uma linguagem diferente. Por exemplo, construir as classes de acesso a dados em C# (C-Sharp) e os módulos de interface em Visual Basic.NET. Isso possibilita a programadores íntimos de uma determinada linguagem a continuar trabalhando da mesma forma, através de um novo conceito.

A plataforma .NET CF permite o desenvolvimento de softwares com muito valor agregado, como por exemplo o bancos de dados SQL Server CE Edition, que manipula arquivos XML, acessa Web Services e manipula dados de retorno, tendo um amplo acesso a biblioteca gráfica GDI, possuindo recursos para infravermelho, possuindo recursos para Bluetooth entre outros, conforme (Mosimann Netto, 2006).

Uma curiosidade é que juntamente com o lançamento do .NET CF, a Microsoft lançou o Visual Studio.net, uma IDE muito utilizada inclusive por plataformas concorrentes, conforme será exposto na subseção sobre BREW.

3.2.2.3 BREW

O BREW foi desenvolvido pela Qualcomm, a mesma empresa que difundiu a tecnologia CDMA. Em conjunto com o Visual Studio da Microsoft, apresenta segundo (Franco, 2006), boas vantagens em relação a alto desempenho e produtividade. Uma vantagem é que o BREW se trata de um ambiente com ampla capacidade de portabilidade, uma vez que a Qualcomm teve o objetivo de construir as APIs de modo que elas pudessem estar disponíveis em todas as plataformas. Neste caso, o BREW pode ser adaptado tanto em dispositivos que apresentam sistema operacional quanto naqueles que não possuem recursos suficientes para tanto. Outra vantagem é que o desenvolvedor que já conhece C/C++ precisará apenas aprender as funcionalidades das APIs. Para o desenvolvimento em BREW é possível utilizar as linguagens de programação C/C++ e Java, embora a linguagem mais utilizada seja C++.

Como obrigatório para o desenvolvimento em BREW, cita-se o BREW SDK. Sua programação é feita utilizando-se de módulos, sendo um módulo composto por uma ou mais classes. Essas classes podem ser classificadas como sendo applets ou não. Um tipo importante de módulo é o MIF, que contém a extensão “.mif” e guarda os IDs de todas as classes (através do uso dos arquivos “.bid”), além de guardar nomes e ícones dos applets que podem ser vistos pelo usuário através de um menu antes de serem executados.

No BREW, toda classe, seja applet ou não, precisa de um identificador de classe único, o BID (BREW ID). Um BID corresponde a um arquivo com a extensão “.bid” contendo um número inteiro de 32 bits, fornecido pela Qualcomm para desenvolvedores registrados. Esse número precisa ser diferente e único para cada classe utilizada. Em termos de aprendizado e testes, pode-se utilizar um BID fictício, sem que haja a necessidade de se registrar no site da Qualcomm.

Dentre os componentes complementares da plataforma estão os Resource Files, com os quais é possível adicionar strings, imagens ou caixas de diálogo, através do uso do aplicativo Resource Editor. E, assim como em qualquer plataforma de desenvolvimento, o BREW SDK também oferece um simulador, o BREW Simulator. Este contém diversos

tipos de dispositivos para que testes possam ser feitos antes de enviar o aplicativo ao dispositivo móvel real.

Ainda de acordo com (Franco, 2006), BREW apresenta uma documentação concisa e bem elaborada, agregada ao BREW SDK. O arquivo de documentação mais usado e de extrema importância é o API Reference, que inclui a documentação de todas a APIs suportadas pelo BREW.

3.3 Soluções para VoIP em Dispositivos Móveis

Diz-se solução VoIP toda tecnologia capaz, não apenas, de suportar voz sobre IP, mas fazê-lo da forma mais eficiente possível. Isso porque há uma QoS mínima que classifica em usável ou não uma solução.

3.3.1 Soluções em Software

Uma das soluções de maior uso via Web em relação a voz sobre IP é o Skype (SKYPE #1, 2006), que é um programa de comunicação baseada em voz. Ele utiliza um protocolo não padronizado proprietário da própria Skype, o IP Skype (GEEK, 2006), e que possui melhor performance do que o SIP (BR-Linux, 2006). O seu grande problema é que por ser proprietário, não permite a comunicação com outros programas preexistentes ou Telefones via IP, como os do padrão SIP e H.323 (Morais e Silva, 2006).

Além deste, o mercado vem presenciando o crescimento do Gizmo (GIZMO, 2006). A Figura 30 apresenta um exemplo de execução deste software, que possui uma lista de contatos e um quadro de diálogo, seguindo os padrões de aplicações multimídia como verificação de status dos membros da lista, mensagem instantânea para os contatos, transferência de arquivos, janelas para conversas real-time, dentre outros.

Figura 30 – Exemplo de Visualização no Gizmo (GIZMO, 2006)

O Gizmo possui tarifas semelhantes ao Skype, além de recursos também similares através do uso do padrão aberto de telefonia SIP. O projeto tem adotando estratégias de marketing eficientes, fazendo com que o Gizmo alcance um número expressivo de usuários.

Segundo (Stevenson, 2006) algumas das inovações mais interessantes do Gizmo são a capacidade de gravar a chamada, voicemail para email e a configuração que permite que uma chamada possa ser alertada tanto no PC quanto em um número de celular à sua escolha.

Quanto à qualidade do som, tanto o Skype como o Gizmo utilizam a tecnologia Global IP Sound's VoiceEngine, (Stevenson, 2006) afirma não ter encontrado problemas relacionados a atraso e jitter durante o teste de qualidade sonora do Gizmo. Através do uso de um headset de qualidade, o som do Gizmo pode ser espaçoso e tridimensional com muito mais capacidade que teria um telefone convencional.

O Gizmo não utiliza técnicas peer-to-peer para conferências; utilizando a técnica novel server-based – (Jackson, 2002) apresenta maiores detalhes sobre a mesma.

O Gizmo apresenta dois servidores para conferência: o seu próprio servidor, e um servidor em parceria com a FreeConferenceCall.com, ambos livres.

De acordo com (GIZMO, 2006), o projeto suporta 10 participantes na conferência sem perder qualidade. Entretanto, no caso de todos deixarem seu Gizmo phone mudo quando não estiver conversando, a capacidade sobe para cerca de 30 participantes.

Ainda segundo (Stevenson, 2006), um softphone irá ter dependência financeira em relação à venda de conectividade junto a PSTN, e neste caso, o Gizmo o faz, nos Estados Unidos da América, por 1centavo/min. Por fim, (Stevenson, 2006) conclui que um dos fatores mais

importante do Gizmo é que o mesmo faz uso do SIP, o que propicia interoperabilidade e ampla capacidade de utilização do software ao redor do mundo.

Uma outra alternativa, talvez uma das mais recentes, chama-se SkypeOUT (SKYPE #2, 2006), que pode ser usado em um PDA próximo ao HotSpot e ligado como no Skype convencional, contando com uma taxa mínima de uso, com valores bem próximos de uma ligação local. Na Figura 31, há um protótipo do produto que já está disponível para uso comercial (SKYPE #2, 2006).

Figura 31 – SkypeOUT (SKYPE #2, 2006)

Têm-se, atualmente, tecnologias como ADSL, DSL, CDMA, TDMA, entre outros que fornecem suporte a redes IP. Os softwares não só têm foco em aproveitar a estrutura existente, mas disponibilizar novas áreas de atuação no mercado das telecomunicações e TI.

Hoje em dia, já existem APIs que trabalham com a camada de aplicação SIP funcionando como middlewares e que fornecem todo um aparato para o desenvolvimento não só de softwares para comunicação de voz como aplicações para dispositivos móveis. Este é o caso da API Java: “SIP API for J2ME” (SUN #2, 2006). Uma idéia do que as diferentes ferramentas case podem oferecer pode ser obtido no próprio portal da Sun Microsystems (SUN #1, 2006).

3.3.2 Soluções em Hardware

Os telefones IP são os dispositivos mais revolucionários da indústria das telecomunicações. As grandes possibilidades inerentes a esses dispositivos vão provocar uma explosão de interessantes aplicações, de vídeo-fones a dispositivos de rádio-emissão de alta fidelidade. Uma revolução sobre o poder de se comunicar da maneira que quiser (TELECO #1, 2006).

Os aparelhos móveis, em especial os celulares, tornaram-se acessíveis a todos não só pelo uso do recurso de comunicação, mas sim pela mobilidade. Os principais fabricantes de telefonia celular vêm colocando seu foco em aparelhos que sejam híbridos (GSM e Wi-Fi) (MOBILELIFE, 2006). Segundo (TELECO #2, 2006), estes ainda não apresentam nomes comerciais específicos e implementariam a conhecida GAN que permitem roaming transparente entre chamadas de voz e dados de uma rede GSM para uma rede Wi-Fi, baseada em HotSpots.

Retrocedendo ao Skype no que diz respeito à solução VoIP para dispositivos móveis no quesito hardware, pode-se ressaltar que o Skype começou lançando a versão para pocket PC. A chamada pode ser feita por infrared ou bluetooth (usando um celular como conexão), Wi-Fi e 3G (SKYPE #3, 2006). Esta é uma solução que envolve otimização tanto por parte de software quanto hardware (MOBILELIFE, 2006).

A definição da arquitetura e deslocamento da comunicação do Skype Pocket é mostrada na Figura 32. Nela, são mostradas as duas formas de utilização do Skype. A solução em software é exemplificada pela rede envolvendo o PC, que fará uso de uma conexão ADSL ou a cabo, por exemplo, para o desenvolvimento da comunicação. Por sua vez, a solução em hardware é exemplificada pelo pocket pc, que necessitará apenas de um roteador WiFi, por exemplo, para que possa fazer uso do HotSpot representando algum ponto de acesso público.

Figura 32 – Skype Pocket Pc traduzido de (Boulogne, 2004)

Somente o tempo e o empenho no desenvolvimento técnico podem estabelecer datas para a transição completa do sistema tradicional de telefonia para VoIP. Ainda há muito a ser avaliado, seja em conceitos fundamentais como qualidade de voz, seja em questões tributárias sobre a cobrança dos novos serviços. As vantagens vêm se tornando cada vez mais claras e diversificadas. Desde a possibilidade de suporte a sistemas unificados de

mensagens, podendo integrar correio eletrônico, de voz e fax; mobilidade, a possibilidade de acesso ao sistema de qualquer lugar ou facilidade de integração com outras aplicações de dados e vídeo, como por exemplo, sistemas de vídeo-conferência. Entretanto, tudo ainda ocorre apenas no clima de expectativa.

4. Proposta de Arquitetura e Aplicação

Neste capítulo, é apresentada a proposta de arquitetura para comunicação VoIP entre dispositivos móveis (celulares, em especial) e os requisitos mínimos para a sua implementação.

4.1 Arquitetura Fundamental

Destacam-se, sob uma visão macro da arquitetura, os seguintes elementos:

Dispositivo celular – para o qual será desenvolvida uma aplicação que permita comunicação VoIP;

Central Asterisk – responsável pela alocação de IPs temporários e autenticação de usuários;

Base de dados – um componente do GW de gerência presente no Asterisk.

A Figura 33 exibe os componentes da arquitetura e exemplifica o fluxo de uma chamada telefônica – salienta-se que há dois possíveis tipos de terminais: um proveniente da rede de telefonia GPRS e outro de uma fonte A que se comunica, via IP.

O Sistema Autônomo VoIP, composto pela Rede IP, Central e Base de Dados, está ligado à rede IP, de onde recebe pedidos de autenticação, faz conexão entre terminais, gerenciamento de requisições de chamadas e o registro das mesmas.

Figura 33 – Sistema Autônomo VoIP e dois possíveis terminais (Fonte A e Fonte GPRS)

A idéia deste trabalho é utilizar uma aplicação implementada sobre a camada de rede existente nos celulares, que servirá de interface para utilização da estrutura de comunicação VoIP provida pela arquitetura. Desta forma, havendo a necessidade de comunicação, a aplicação será iniciada no dispositivo móvel, disparando um pedido de autenticação, na qual o requisitante irá informar login e senha, para a Central, que é representada pelo sistema Asterisk. A Central efetuará a autenticação, e sendo esta efetivada com sucesso,

arquivam-se endereços IP temporários que, por sua vez, são atribuídos pelo Asterisk e enviados para cada um dos lados da chamada. A partir de então, a aplicação passa a ser utilizada somente entre os dispositivos móveis envolvidos, sendo que a digitalização da voz é feita nos próprios aparelhos e compactada pelo codec G.711.

Para este trabalho, desenvolve-se uma solução para o cenário de Sinalização IP – Sinalização IP.

Também é importante lembrar a necessidade de haver largura de banda suficiente para a transmissão contínua da voz – largura esta que depende da escolha do codec e do protocolo VoIP.

A seguir, são cobertos os detalhes a respeito da estrutura de comunicação em rede que integra a Central do Sistema Autônomo aos demais envolvidos na arquitetura, apresentada na Figura 33; além das justificativas quanto às escolhas de protocolos e recursos de hardware/software utilizados, assim como detalhes acerca da aplicação desenvolvida.

4.1.1 Rede da Central do Sistema Autônomo

A estrutura de rede é baseada em Sistemas Autônomos (ou SAs), como no modelo de estrutura de rede considerada pelo protocolo de roteamento dinâmico BGP (Meggelen & Smith & Madsen, 2005). O conjunto de SAs forma uma rede de comunicação VoIP. A cobertura de um SA-VoIP não depende necessariamente da distância física entre a Central e os elementos que se comunicam com ela (telefones IP, celulares, softphones e outras fontes de comunicação multimídia, por exemplo).

Cada SA é capaz de atender a n usuários, onde n é o número de conexões possíveis de serem atendidas pela Central (sistema Asterisk) de forma a assegurar o melhor tempo de resposta possível, para o usuário, ou seja, é possível que um usuário que esteja a poucos metros fisicamente da Central, seja atendido por outra Central, e um segundo usuário, com um enlace de melhor qualidade, por exemplo, que esteja a vários metros dessa Central possa ter sua requisição atendida.

A Figura 34 representa o fato da Central do SA-VoIP poder possuir interface tanto com qualquer dispositivo multimídia com sinalização IP como com a rede PSTN. Na Figura 34 são exemplificadas interfaces de telefones convencionais, celulares e computadores.

Figura 34 – Macro-arquitetura

Na Central, estão encapsulados todos os servidores que compõem a arquitetura, inclusive as interfaces de rede IP e PSTN. A base de dados por sua vez, conterá todo o endereçamento SIP necessário para que uma estação que seja componente de uma rede IP possa ser reconhecida e tenha seu serviço autenticado.

A Figura 35 se refere à disposição dos gateways que compõem a Central do SA-VoIP. Nela, pode-se perceber a hierarquia disposta no Asterisk (os três componentes GW da figura representam módulos de funcionalidades distintas do Asterisk). O GW de voz será o responsável pelo repasse do fluxo de áudio entre a RTCC e a rede IP, no caso de um cenário de comunicação sinalização IP – PSTN. O GW de sinalização tratará de funcionalidades, tal como converter uma sinalização SS7 (RTCC) para VoIP. Já o GW de gerência permite controlar o estabelecimento de novas chamadas e apresenta uma base de dados contendo os IPs temporários.

Figura 35 – Gateways de interface e serviço (Módulos do Asterisk)

4.1.2 Protocolos

A arquitetura foi proposta para ser aplicada sobre o protocolo SIP. A dúvida inicial seria em relação à sua escolha perante o protocolo H.323. Por fim, optou-se pelo SIP por este representar, em comparação ao H.323, uma tecnologia mais recente, padrão IETF e com apoio de grande parte das empresas que investem em pesquisa (em especial, aquelas que atuam no mercado de aparelhos celulares) e um conseqüente maior desenvolvimento de pesquisas – isto foi priorizado em relação ao H.323 que apenas apresenta maior popularidade devido ao fato de ter sido o primeiro com um conjunto de padrões estabelecidos (ITU) (SIP Center, 2007).

Para complementar, o fato é que como não havia experiência de trabalho com ambos os protocolos, por parte da equipe de projeto final, e as informações encontradas sobre a comparação entre eles serem apresentadas com antagonismo, com autores privilegiando um ou outro de acordo com uma visão pessoal, optou-se por aquele que se julgou, como um protocolo com maior disponibilidade de APIs disponíveis e empresas interessadas em seu investimento. Em (SUN #2, 2006) podem ser encontradas referências neste sentido.

4.1.3 Hardware/Software

No tocante a softwares, para o desenvolvimento da aplicação, foi escolhida a plataforma JavaME. O fator decisivo para tal escolha foi a maior experiência de uso e maior disponibilidade de componentes adicionais em relação à plataforma BREW (também pesquisada). Usou-se o Asterisk PBX 1.4.4 sobre o sistema operacional Ubuntu 6.0.6 pelo fato de que esta ferramenta atende às necessidades tais como gateway VoIP, sinalização IP, gateway de voz, PBX, gerenciamento de autenticações e registros. Outras ferramentas como o SUN Proxy & Registrar apenas registra e autentica os usuários.

Sobre o contexto de hardware utilizado, destacam-se os aparelhos celulares. Neste caso, relata-se a dificuldade, durante a realização deste trabalho, para inserir versões-testes da aplicação em diversos modelos de aparelhos. Pela falta de experiência em relação ao escopo de desenvolvimento, a equipe previu, inicialmente, que modelos que apresentassem suporte a JVM, CLDC 1.1 e MIDP 2.0 teriam capacidade de executar a aplicação. Posteriormente, foi comprovada a necessidade de que eles apresentassem o adicional de ter suporte à API JSR 180, denominada SIP API for J2ME. A dificuldade neste caso, está em encontrar modelos que apresentam tal API e os altos custos para obtenção, uma vez que se tratam de séries recentes (a partir de fim de 2006), com a grande maioria ainda não tendo sido disponibilizada no Brasil. Os modelos de aparelhos das séries N e E da empresa Nokia são exemplos de dispositivos (uma vez que estas séries também incluem smartphones) com suporte para a API JSR 180.

Para a Central, roteamento e Gateways (gerência, sinalização e voz) utilizou-se uma máquina Athlon XP 2200, 512 MB RAM, com duas placas 10/100M Fast Ethernet Network Adapter, Sistema Operacional Ubuntu 6.0.6 Dapper e Servidor Asterisk PBX 1.4.4. Para os terminais, foram utilizados dois Notebooks Toshiba M115-S3154, Intel Centrino T2250 1,66Ghz Duo Core, 2Gb Ram DDR 533Mhz, HD 100Gb, 2Mb Cache L2, Windows XP – Professional, Java Wireless Toolkit 2.5.1 e a aplicação SoftPhone.

4.1.4 Aplicação

A aplicação desenvolvida corresponde a um protótipo funcional de um software, que é instalado nos terminais (dispositivos móveis – celulares). Para melhor identificação do mesmo, foi convencionado que se chamaria SoftPhone. A aplicação é de uso contínuo, pois mesmo sem haver uma comunicação entre os terminais ela permanece em execução e aguardando possíveis chamadas, mas tem maior aplicabilidade após feita a requisição de uma conexão, na qual é efetuada a autenticação na Central, atribuído um endereço IP temporário, e se autorizada, dispara-se a execução ao aparelho celular envolvido. Além da autenticação no sistema, a aplicação oferece suporte a uma agenda de contatos e ainda implementa seu principal objetivo: a comunicação entre terminais SIP remotos.

Para o desenvolvimento da aplicação foi montada uma plataforma diferenciada para desenvolvimento JavaME que pode ser executada em qualquer dispositivo que tenha suporte à SIP API, ou seja, o pacote JSR 180. Usou-se a IDE NetBeans 6.0 para desenvolver a aplicação e a plataforma Sun Java(TM) Wireless Toolkit 2.5.1 foi utilizada por suportar as APIs necessárias e o emulador.

Tal aplicação baseia-se no modelo cliente-servidor, executável considerando as camadas, a saber:

Aplicação;

JVM;

KVM;

Hardware do dispositivo;

Rede (engloba mais de uma camada, mas pode ser considerada como uma só para a aplicação).

Neste trabalho, desenvolve-se a camada de aplicação. As demais citadas, por sua vez, garantem suporte à implementação. A camada JVM corresponde à plataforma operacional do SoftPhone servindo como interface entre a aplicação e o equivalente ao SO do dispositivo, no caso o KVM. As camadas de hardware do dispositivo e a de rede dependem da arquitetura e da tecnologia, respectivamente, do celular. O que independe para a aplicação, por isso, não é detalhado neste trabalho.

A camada de aplicação, em particular, apresenta as seguintes subcamadas:

Interface – codec e formulários;

Controle – lógica da comunicação e manutenção do dispositivo;

Modelo: API SIP (versão 1.0.1) que funcionará como middleware e modelo de persistência.

A Tabela 6 exibe as subcamadas e seus componentes que, por sua vez, são divididos em duas colunas, sendo a primeira relacionada à voz e a segunda relacionada à agenda/manutenção do dispositivo.

Subc

amad

as

ComponentesInterfaceCamada de MídiaMIDlet (formulários, painéis e outros

componentes)Codec (G.711)ControleConexão, troca de mensagens e outros controles relacionados à comunicaçãoManutenção do celular: agenda, configurações e outrosModeloFramework de comunicação do protocolo SIP (API Sip)Persistência em arquivo de configuraçãoTabela 6 – Subcamadas da aplicação

A aplicação foi implementada seguindo o modelo de camadas supracitado. Conforme visto, há duas colunas de componentes, sendo que para a comunicação e a manutenção do dispositivo móvel foram consideradas duas linhas diferentes da aplicação, ou seja, uma ação de realizar chamadas com outro dispositivo (comunicação) é diferente de uma ação de cadastro de contatos no dispositivo (manutenção).

Nas próximas subseções, são apresentadas as subcamadas da aplicação, destacando suas peculiaridades.

4.1.4.1 Interface

Em se tratando de voz a subcamada é dividida em mídia e codec. A camada de mídia faz a captura da voz que é passada para o codec, que por sua vez faz a compactação adequada e repassa para a camada subseqüente. O processo do outro lado do diálogo é análogo: o mesmo codec decodifica a seqüência binária transformando dados em voz digitalizada e repassa para a subcamada de mídia que reproduz o áudio.

Em termos do dispositivo em si, a camada de interface representa os formulários de transição de forms, ou seja, as telas da aplicação e as ações que levam de uma tela a outra,

além do componente de requisição de dados de autenticação, registro de contatos e interface para requisição/aceitação de chamadas. A partir desta interface gráfica, as ações do usuário são feitas.

4.1.4.2 Controle

Com respeito à voz, a subcamada de controle trata as mensagens SIP que chegam e saem. Esta subcamada conhece as primitivas do protocolo SIP, tais como INVITE, REGISTER, MESSAGE, ACK e as demais não citadas.

Já no contexto do dispositivo, esta subcamada faz o controle lógico de montagem dos formulários, controle de mensagens de sucesso e erro, além do controle da agenda e configurações do dispositivo.

4.1.4.3 Modelo

Quanto à voz, a subcamada modelo não possui inteligência associada, apenas possui duas funcionalidades: manter uma porta de saída de mensagens, independente do tipo de mensagem, destinatário e conteúdo; e manter um listener permanente para a recepção de mensagens destinadas ao dispositivo.

Em termos do dispositivo, o comportamento da subcamada de modelo é tão simples quanto para voz, sendo responsável pela persistência e leitura de dados da agenda e configuração do dispositivo/sistema.

4.1.5 Configuração AsteriskO Servidor Asterisk é executado no Sistema Operacional Ubuntu 6.0.6 Dapper pelo terminal de execução através do comando “asterisk –cvvv”, ou seja “c” para se conectar ao console do Asterisk e “v” para definir o nível de verbosidade, ou seja, a quantidade de saídas da eliminação de falhas da linha de comando, que neste caso é de nível 3. Assim que o Asterisk é iniciado são carregadas todas as configurações contidas nos arquivos “sip.conf” e “extensions.conf”, onde estão contidas as informações dos usuários como tipo de acesso, identificador, senha de cada um, tipo de contexto em que estará executando (local e interno) e se a estação será dinâmica ou estática. As estações com a aplicação cliente são executadas no Sistema Operacional Windows XP Professional e se utilizam do Java Wireless Toolkit 2.5.1 para emular um dispositivo que contem as APIs necessárias. Desta forma, uma aplicação faz uma requisição, que por sua vez é encaminhada ao Asterisk que busca o destinatário e sinaliza a este que há uma requisição e a aplicação do terminal destinatário aceita a chamada, enviando assim uma confirmação para o remetente, estabelecendo um canal de comunicação através do Asterisk.

4.1.6 Diagramas e Código

No Anexo A está disposto o diagrama de classes representando as classes participantes da aplicação. O Anexo B é relativo a uma visão macro do fluxo da aplicação. O Anexo C

representa a visão da comunicação de usuários. O Anexo D apresenta o diagrama de atividades para autenticação enquanto o Anexo E representa a conexão de dispositivos.

O código da aplicação está disponível no CD que acompanha este documento.

4.2 Requisitos

Hardware:

Servidor (VoIP gateway) – 1 GHz x86, 512 MB RAM, e interface de rede 10/100M Fast Ethernet Network Adapter;

Duas estações de desenvolvimento – 1 GHz x86, 512 MB RAM, 1GB de espaço em disco disponível, e interface de rede 10/100M Fast Ethernet Network Adapter;

Dispositivo móvel – aparelho celular com JVM, CLDC 1.1 e MIDP 2.0;

Roteador para acesso à Internet.

Software:

Asterisk PBX 1.4.4 + Add-ons;

Linux Ubuntu 6.0.6 (Kernel 2.6);

JDK 1.5;

Aplicando o codec G.711 (64kpbs descomprimido), 20 milissegundos de duração de pacotes, aproximadamente 160 bytes de payload, 1 quadro por pacote, a largura de banda IP/UDP/RTP requerida é 80kbps e a largura de banda Ethernet requerida é de aproximadamente 95 Kbps – dados relativos ao uso de uma chamada simultânea (Bandwidth Calculator, 2007);

API SIP JSR 180.

Ferramentas para desenvolvimento:

NetBeans IDE 6.0 + JavaME Wireless tool kit 2.5.1 1 for CLDC, EA.

5. Conclusão

O primeiro objetivo deste trabalho refere-se ao levantamento do estado-da-arte em comunicação VoIP, das características de ferramentas baseadas em software livre para tal comunicação e do desenvolvimento para a telefonia convencional e móvel. Esta etapa foi concluída com êxito. Acredita-se que houve uma exposição completa, tendo sido detalhadas todas as temáticas consideradas fundamentais para o contexto. Nesta etapa, objetivou-se tornar o conteúdo gerado, compreensível àqueles, leigos no assunto. Deste modo, alguns assuntos abordados ao longo dos capítulos 2 e 3 serviram para ilustrar a capacidade de uso das tecnologias, não tendo necessariamente sido explorados para a solução proposta. Fundamentadas as tecnologias, as escolhas feitas para a definição da arquitetura e implementação da aplicação puderam ser justificadas com clareza.

Um segundo objetivo deste projeto final compreende o entendimento de particularidades de soluções para a comunicação VoIP, no âmbito de software livre. Não somente em relação às soluções para VoIP, mas em um sentido geral, principalmente por meio das etapas de montagem do laboratório de testes, o grupo adquiriu uma compreensão e experiência quanto ao uso de software livre. Atividades como instalar um sistema operacional, procurar bibliotecas específicas para a proposta e configurar o Asterisk foram fundamentais para tal. O fato de ter sido conseguida a utilização do Asterisk (fato este que será exposto adiante), no que lhe foi proposto na arquitetura, representa um meio de demonstrar êxito neste objetivo.

A próxima etapa indicou a necessidade de se propor uma arquitetura para a comunicação VoIP entre dispositivos móveis. A teoria que sustenta a viabilidade da arquitetura é fundamentada ao longo do levantamento bibliográfico apresentado nos capítulos 2 e 3, e justificada no capítulo 4. A arquitetura, que contemplava em seus esboços iniciais, a possibilidade de comunicação VoIP para a telefonia convencional, foi adaptada a fim de se tornar exclusiva para dispositivos móveis, em especial celulares. Houve esta necessidade devido à ausência de disponibilidade de placas PABX e placas alternativas, uma vez que a aquisição das mesmas deveria ser feita pelo grupo, o que se tornou uma situação inviável financeiramente. O fato do grupo não ter experiência em desenvolvimento para telefonia também foi decisivo neste ponto. Isto porque não havia meios de testar previamente a placa antes de sua adquiri-la, e por tal, não poderia ser previsto exatamente qual modelo poderia ser adaptado com funcionalidade máxima à proposta de desenvolvimento. Portanto, optou-se por remodelar a proposta de aplicação e arquitetura visando uma comunicação que fosse direcionada para o escopo dos celulares. Foi proposta uma arquitetura que não apresentasse um alto grau de complexidade, seja para facilidade na implementação ou complementaridade de novas funcionalidades por novos grupos de projeto que por ela se interessem. Acredita-se que houve clareza nas justificativas relativas à funcionalidade de cada componente da arquitetura. Desta forma, o grupo também conclui com êxito esta etapa.

A solução para comunicação VoIP utilizada define uma aplicação cliente denominada SoftPhone, desenvolvida ao longo deste projeto e o PABX Asterisk 1.4.4 instalado e configurado com os dados dos usuários que se comunicam e serão autenticados pelo servidor. De fato, esta aplicação foi implementada e esteve de acordo com a proposta. A aplicação conseguiu estabelecer o objetivo de comunicar dois dispositivos móveis de forma full-duplex, e também realizou a troca de argumentos junto ao Asterisk, o que permite a

efetiva autenticação do usuário requisitante da chamada. Houve captura de voz, compactação através da técnica PCM, e envio de pacotes para o outro lado da conversa. Devido à complexidade da solução, de sua baixa portabilidade e da baixa disponibilidade de fontes referenciais, não foi possível configurar a transmissão de modo ideal. A transmissão dos pacotes de voz se deu por protocolo TCP e apresentou problemas de eco, jitter e atraso. A voz era de fato recebida, mas sempre com alguma dessas restrições associadas. O uso do protocolo TCP, no lugar do protocolo UDP (que seria o mais recomendável), foi uma opção devido à ausência do protocolo RTP. Este último garantiria que os pacotes fossem entregues na ordem, mas na sua ausência, esta garantia só poderia ser dada pelo TCP. De fato, a tecnologia VoIP ainda é recente o suficiente para não apresentar, nos aspectos de disponibilidade de códigos livres e APIs, as bases de pesquisas e implementações necessárias para aqueles que desejem iniciar o desenvolvimento de um cliente VoIP, a partir do zero. Nem mesmo através da consulta a clientes VoIP já estabelecidos no mercado como o X-Lite, foi possível criar uma lógica de transmissão adequada para o modelo previsto. Em adição, não se esperava encontrar tantas incompatibilidades na relação entre plataforma de desenvolvimento e software livre (seja no sistema operacional Ubuntu 6.0.6 ou no próprio Asterisk).

De qualquer forma, o grupo conclui como importante sua contribuição no âmbito científico. Isto porque atingir a plena troca de pacotes de forma full-duplex associado a uma autenticação feita a partir de um software livre, além de se propor uma arquitetura com justificativas coesas, é um caminho indispensável para que soluções VoIP baseadas em Asterisk possam ser desenvolvidas.

6. Trabalhos Futuros

Ao final deste trabalho e após uma extensa fase de pesquisa seguida de uma fase de implementação, considera-se importante que haja uma continuidade de pesquisas e avanços neste trabalho, visto que se trata de tecnologias atuais e que envolve um grupo considerável de potenciais usuários.

Portanto, consideram-se válidas as seguintes idéias para futuras implementações:

Implementação de segurança do fluxo de dados (voz): Implementar criptografia para que se possa garantir confiabilidade e integridade dos dados que serão trafegados entre cliente(s) e servidor(es). Com estes serviços de segurança implementados os riscos de qualquer pessoa autorizada ou não poder interceptar uma ligação serão minimizados;

Construção e melhoria das configurações e funcionalidades da aplicação: A aplicação SoftPhone pode ser melhorada no sentido de implementar novas funcionalidades tais como integração com a Agenda de Contatos para que se possa manter vários contatos gravados e que estejam à disposição, envio de mensagens de texto e manutenção de histórico de chamadas na própria aplicação. Isto tornaria aplicação mais completa e, como tem potencial de mercado, se constituiria em um produto mais atrativo;

Otimização das configurações do Asterisk: Esta ferramenta é a mais completa das ferramentas PBX por possuir funcionalidades que outras não possuem. Então, seria interessante configurar as funcionalidades como correio de voz, chamadas em espera e conferência de chamadas para que possam ser utilizadas com a aplicação SoftPhone;

Inclusão do contexto de telefonia convencional através de interface PSTN no Asterisk: Incluir na arquitetura do projeto uma interface de telefonia fixa convencional, para que haja uma maior abrangência do contexto de VoIP e a arquitetura não permaneça limitada apenas à telefonia móvel;

Junção de mais de um Sistema Autônomo baseado Asterisk: Permitindo que usuários possam ter o serviço com mais eficiência e principalmente disponibilidade.

Implementação de políticas de QoS (DiffService): Caso haja a possibilidade da concepção de uma rede de servidores Asterisk em pontos remotos distintos, deverá se pensar no tratamento que os links deverão dar aos dados e à voz. Desta forma, seria possível garantir que o tráfego de voz, caso ocorra no Sistema autônomo, fosse priorizado;

Tornar a aplicação mais flexível quanto ao tipo de tecnologia (GPRS, WiFi, WiMax): A aplicação atual não considera o meio pelo qual seus dados trafegam. Caso haja um tratamento mais específico no sentido de tratar cada cenário de tráfego de dados, a aplicação se tornaria mais flexível e se aproveitaria melhor o que cada uma destas tecnologias tem a oferecer;

Então, com o que foi proposto acima, conclui-se que este trabalho tem um potencial de contribuição enorme para futuros pesquisadores que queiram levar esta idéia adiante. Além disso, a aplicação desenvolvida no projeto também tem um potencial considerável de mercado, visto que o que foi implementado constitui um campo ainda pouco explorado e pouco documentado, uma vez que ainda existem algumas limitações como custos de implantação e tecnologias pouco suportadas.

7. Referências Bibliográficas

(3G Frame, 2007) 3g.com.br, Celular 3G, disponível em

http://www.3g.com.br/site3g/celular_frame.htm, consulta em 02/07

(Agilent, 2002) Agilent Technologies Brasil, GSM – Conceitos Básicos, disponível em

http://www.wirelessbrasil.org/wirelessbr/colaboradores/agilent_gsm/gsm_03.html, consulta em 02/2007

(Alecrim, 2005) Alecrim, E., Tecnologia VoIP, 2005, disponível em

www.infowester.com/voip.php, consulta em 10/2006

(AsteriskBrasil.org, 2006) Asterisk Brasil, disponível em http://www.asteriskbrasil.org/, consulta em 11/2006

(Araújo Orrico, 2006) Orrico, Ângelo Carneiro Araújo, Configurando um Ambiente de Desenvolvimento para J2ME, disponível em

http://www.devmedia.com.br/articles/viewcomp.asp?comp=1689, consulta em 11/2006

(Bandwidth Calculator, 2007) Newport Networks, VoIP Bandwidth Calculator, disponível em http://www.newport-networks.com/pages/voip-bandwidth-calculator.html, consulta em 06/2007

(Borges, 2005) Borges, R.L., J2ME na Prática, disponível em

http://www.ucb.br/java/JavaDays/J2ME_RosfranBorges.pdf, consulta em 05/2007

(Boulogne, 2004) Boulogne, Exemples d’utilisation d’um réseau Wifi, disponível em

http://fama.boulogne.free.fr/wifi/videoconference.htm, consulta em 10/2006

(Braden, 1994) Braden, Bob, Clark, David, Shenker, Scott. Integrated Services in the Internet Architecture: an Overview, disponível em

http://www.ietf.org/rfc/rfc1633.txt, consulta em 09/2006

(Brito & Sousa, 2005) Brito, I.A.,Sousa, V.M., Uma Ferramenta Para Análise de desempenho de redes convergentes, disponível em

www.redes.unb.br/PFG.222004.pdf, consulta em 09/2006

(BR-Linux, 2006) BR-Linux, Skype Linux, disponível em

http://br-linux.org/linux/nova_versao_do_skype_para_linux, consulta em 10/2006

(BrTelecom Voipzone, 2007) Voipzone, disponível em

http://www.brasiltelecom.com.br/voipzone/, consulta em 06/2007

(Cansian, 2002) Cansian, Adriano Mauro, Controle de Congestionamento no TCP

www.acme.ibilce.unesp.br/~adriano/redes/adr-redes-2002-controle-congestionamento.pdf, consulta em 11/2006

(Castaldelli, 2003) Castaldelli, M., Aplicações de Internet Móvel, disponível em

www.teleco.com.br, consulta em 02/2007

(Chlamtac & Lin, 2001) Lin, Yi-Bing, Chlamtac, Imrich. Wireless and Mobile Network Architectures, ed. Wiley, 2001

(Cliconnect, 2006) Qualidade de Serviço em VoIP, disponível em

http://www.cliconnect.com/br/Artigos/QOS/QOS29.html, consulta em 10/2006

(Dastis, 1998) Dastis, R. S., Um Estudo dos Mecanismos de Controle de Tráfego e Congestionamento nas Diferentes Categorias de Serviço do ATM, 1998, disponível em

http://www.inf.ufrgs.br/pos/SemanaAcademica/Semana98/dastis.html, consulta em 11/2006

(DiffServ, 1998) Blake, S., Baker, F., Black, D. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, disponível em

http://www.ietf.org/rfc/rfc2474.txt, consulta em 09/2006

(Digit-Life, 2006) IP Telephony Problems disponível em

http://www.digit-life.com/articles/iptelephonyproblems/ip-tel-2.gif, consulta em 10/2006

(Doku OpenSER, 2007) OpenSER Documentation Factory, disponível em http://openser.org/dokuwiki/doku.php, consulta em 01/2007

(Echo, 2006) VoIP TroubleShooter – Problem: Echo, disponível em

http://www.voiptroubleshooter.com/problems/echo.html, consulta 10/2006

(Ejnisman, 2006) Ejnisman, Marcela, Telefonia na Internet - A Voz Sobre IP e os Novos Desafios Regulatórios, disponível em

http://www.cliconnect.com/br/Artigos/VOIPDesafiosRegulatorios01.html, consulta em 09/2006

(Franco, 2006) Franco, Márcio, Introdução ao BREW, 2006, disponível em

http://www.linhadecodigo.com.br/artigos.asp?id_ac=1098, consulta em 11/2006

(FreeSWITCH, 2007) Welcome To FreeSWITCH, disponível em

http://www.freeswitch.org/, consulta em 01/2007

(FreeSWITCH Dependencies, 2007) FreeSWITCH Dependencies, disponível em

http://www.voip-info.org/wiki/view/FreeSwitch+Dependencies, consulta em 01/2007

(FreeSWITCH Docs, 2007) FreeSWITCH Docs, disponível em

http://www.freeswitch.org/docs/, consulta em 01/2007

(FreeSWITCH Wiki, 2007) FreeSWITCH Wiki, disponível em

http://wiki.freeswitch.org/wiki/Main_Page, consulta em 01/2007

(GEEK, 2006) Geek, Skype, disponível em http://www.geek.com.br/modules/noticias/lista.php?id=3&pg=2, consulta em 10/2006

(GIZMO, 2006) Gizmo is a Free Phone for Your Computer, disponível em

www.gizmoproject.com/, consulta em 10/2006

(Gomes & Sénica & Coelho, 2003) Gomes, D.N.P., Sénica, N.J.S.L.H, Duarte, N.P.P.C.

Demonstrador Mobilidade Heterogênea, disponível em http://mobydick.av.it.pt/Relatorio.pdf, consulta em 03/2007

(GSM World, 2006) GSM Stats, disponível em

http://www.gsmworld.com/news/statistics/index.shtml

(GTA-UFRJ, 1999) Mecanismos que possibilitam QoS na Internet, disponível em

http://www.gta.ufrj.br/~gardel/redes/mecanis.htm, consulta em 09/2006

(GTA-UFRJ,2001) GTA-UFRJ, Voip, disponível em

http://www.gta.ufrj.br/grad/01_2/VOIP.htm, consulta em 09/2006

(GT VoIP, 2002) Rodrigues, P., Marcondes, C., David, F., Costa, J. GT VoIP – Relatório de Avaliação do Serviço Experimental, disponível em

http://www.rnp.br/newsgen/0307/gt-voip-2002.html, consulta 09/2006

(Hersent, Guide, Petit, 2002) Hersent Oliver, Guide, David, Petit, Jean-Pierre. Telefonia IP. Comunicação multimídia baseada em pacotes. São Paulo: Prentice Hall, 2002

(H323, 2002) Leopoldino, G., Medeiros, R., H.323: Um Padrão para Sistemas de Comunicação Multimídia Baseado em Pacotes, disponível em

http://www.rnp.br/newsgen/0111/h323.html, consulta em 09/2006

(Jain, 1996) Jain, R. Congestion Control and Traffic Management in ATM Networks: Recent Advances and A Survey. Departament of Computer and Information Science. The Ohio State University, 1996.

(Jitter and Timing, 2005) Jitter and Timing Analysis, disponível em

www.tektronix.com/jitter, consulta em 09/2006

(Jackson, 2002) Jackson, Joab, Sound bytes: Novel phonetic techniques advance audio searches, disponível em

http://www.washingtontechnology.com/print/17_7/18499-1.html, consulta em 03/2007

(Korelc, 2006) Korelc, J. Asterisk no Mercado Corporativo: Benefícios e Melhores Práticas para Estratégia de Adoção por parte do Negócio, disponível em http://www.asteriskbrasil.org/tiki/tiki-read_article.php?articleId=36, consulta em 03/2007

(Linux Magazine n3) Linux Magazine nº 3, Telefonia IP, Softphones - Me liga a qualquer hora. Editora: Linux New Media do Brasil, 2004

(Lustosa, 2005) Lustosa, L.C.G, Avaliação de Qualidade de Voz em Sistemas Baseados em VoIP, disponível em

www.voip.nce.ufrj.br/leandro/download/slides-Mestrado2005.pdf, consulta em 10/2006

(Magro, 2006) Magro, Julio César, Unicamp, Estudo da Qualidade de Voz em Redes IP, disponível em http://libdigi.unicamp.br/document/?code=vtls000365297, consulta em 09/2006

(Meggelen & Smith & Madsen, 2005) Meggelen, J.V., Smith,J. e Madsen, L. Asterisk: O Futuro da Telefonia, disponível em http://www.altabooks.com.br/pdf/asterisk.pdf, consulta em 03/2007

(Minessale II, 2006) Minessale, A. VoIP Hat Trick. GoogleTalk, 16K and NextGen IVR, disponível em http://www.linuxpr.com/releases/8983.html, consulta em 01/2007

(MGCP, 1999) Arango, M., Duga,, A. Elliot, I., Huitema, C. Pickett, S. Media Gateway Control Protocol, disponível em http://www.ietf.org/rfc/rfc2705.txt, consulta em 10/2006

(MobileIP,2005) Santos, L. da S., Tolerância à Falha dos Agentes de Mobilidade do Protocolo Mobile IP, PUC-RJ, disponível em http://www.maxwell.lambda.ele.puc-rio.br/cgi-bin/PRG_0599.EXE/7583_1.PDF?NrOcoSis=21748, consulta em 09/2006

(MOBILELIFE, 2006) IEEE Aprova padrão Wi-Max Móvel, disponível em

www.mobilelife.com.br/2006/03/, consulta em 10/2006

(Mobiledia, 2007) Cell Phone Glossary, disponível em

http://www.mobiledia.com/glossary/37.html, consulta em 03/2007

(MonoVoIP, 2005) Souza, Igor Luiz Oliveira, Voip: Voice Over IP, Salvador, DCC/UFBA, Julho 2005. Monografia de Tópicos de Redes, Graduação em Ciência da Computação

(Morais e Silva, 2006) Morais e Silva, R., GIZMO: Ligações gratuitas para telefones fixos no Brasil, disponível em http://www.dicas-l.com.br/dicas-l/20061009.php, consulta em 03/2007

(Mosimann Netto, 2006) Netto, Max Mosimann, Microsoft .NET Compact Framework – Conheça a plataforma para dispositivos móveis criada pela Microsoft, 2006, disponível em

http://www.linhadecodigo.com.br/artigos.asp?id_ac=646&pag=1, consulta em 11/2006

(Mosimann Netto, 2005) Netto, Max Mosimann, Design para Dispositivos Moveis - O primeiro passo para um sistema bem sucedido é a interação com o usuário, disponível em http://www.linhadecodigo.com.br/artigos.asp?id_ac=648&pag=1, consulta em 03/2007

(Netcraftsmen, 2003) Quality of Service for Voice Over IP, disponível em

www.netcraftsmen.net/welcher/seminars/qos-voip.pdf, consulta em 09/2006

(Network Dictionary, 2007) Network Dictionary, disponível em http://www.networkdictionary.com/protocols/voip.php?PHPSESSID=cda97853dbb5931438ca2e4a0174b662, consulta em 02/2007

(OpenSER Features, 2007) OpenSER Features, disponível em

http://www.openser.org/index.php?option=com_content&task=view&id=33&Itemid=50, consulta em 02/2007

(OpenSER Installation, 2007) OpenSER Installation Notes, disponível em

http://www.openser.org/index.php?option=com_content&task=view&id=26&Itemid=56, consulta em 01/2007

(OpenSER 1 Modules, 2006) OpenSER Modules 1.0.x, disponível em

http://openser.org/docs/modules/1.0.x/, consulta em 01/2007

(Pietrosemoli, 2006) Pietrosemoli, E., VoIP, Slide 4, 2006, disponível em

www.ute.edu.ec/walc2006/track1/8%5B1%5D.Voz%20sobre%20IP.ppt, consulta em 10/2006

(Pinheiro, 2003) Pinheiro, Christiano, J2ME:Java para os portáteis, 2003, disponível em

http://www.imasters.com.br/artigo/1539, consulta em 11/2006

(Pinheiro, 2004) Pinheiro, J.M.S., Projeto e Gestão de Redes de Computadores, disponível em http://www.projetoderedes.com.br/artigos/artigo_desempenho_sistemas_estruturados.php,

consulta em 10/2006

(Pinheiro, 2005) Pinheiro, J. M. S., Telefonia pela Internet, 2005, disponível em

http://www.projetoderedes.com.br/artigos/artigo_telefonia_pela_internet.php, consulta em 10/2006

(Promon3, 2005) Promon, Voz sobre IP: A Revolução na Telefonia, Ano 3, disponível em http://www.promon.com.br/portugues/a_promon/download/PBTR5.pdf, consulta: 09/2006

(Promon5, 2005) Promon, Voz sobre IP: A Revolução na Telefonia, Ano 5, disponível em http://www.promon.com.br/portugues/noticias/download/VoIP_4Web.pdf, consulta: 09/2006

(PUC-RIO, 2004) PUC-RIO, Certificação Digital nº 0220932/CC, 2004, disponível em http://www2.dbd.puc-rio.br/pergamum/tesesabertas/0220932_05_cap_02.pdf, consulta em 09/2006

(QoS MAC, 2002) Bicudo, M.D.D, Duarte, O.C.M.B. IEEE 802.1p - Qos na Camada MAC, disponível em

http://www.gta.ufrj.br/grad/02_2/802.1p/, consulta em 09/2006

(QoS Networking, 2006) Quality of Service Networking, disponível em

http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/qos.htm, consulta em 09/2006

(RhysRadenFrame, 2006) Frame Relay, disponível em

http://www.rhyshaden.com/frame.htm#frts, consulta em 09/2006

(RhysRadenQoS, 2006) Quality of Service, disponível em

http://www.rhyshaden.com/qos.htm, consulta em 09/2006

(Rochol, 1998) Rochol, J. Otimização de Fluxos de Tráfego no Ambiente do Usuário. Proposta de Tese de Doutorado. Porto Alegre, CPGCC/UFRGS, Março 1998.

(RSVP, 1997) Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S. Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification

http://www.ietf.org/rfc/rfc2205.txt, consulta em 09/2006

(Service Mappings, 1981) Postel, J, Service Mappings, 1981, disponível em

www.faqs.org/ftp/rfc/pdf/rfc795.txt.pdf, consulta em 11/2006

(Shadish, 2004) Shadish, Bill, Ten Commandments for Pocket PC User Interfaces (Do’s & Don’ts), 2004, disponível em

http://www.pocketpcmag.com/_archives/nov04/Commandements.aspx, consulta em 11/2006

(Silva, 2000) Silva, A., Qualidade de Serviço em VoIP – Parte I, Vol. 3, Nº. 3, RNP NewsGeneration, maio de 2000, disponível em

http://www.rnp.br/newsgen/0005/qos_voip1.html, consulta 09/2006

(SIP Center, 2007) SIP Center, SIP and H.323 Comparison, disponível em

http://www.sipcenter.com/sip.nsf/html/SIP+and+H.323, consulta em 06/2007

(sipX Architecture, 2007) sipX Architecture, disponível em

http://sipx-wiki.calivia.com/index.php/Architecture_Diagram, consulta em 01/2007

(sipX Architecture & Library Dependencies, 2007) SipX SW Architecture & Library Dependencies, disponível em

http://sipx-wiki.calivia.com/index.php/SipX_SW_Architecture_%26_Library_Dependencies, consulta em 01/2007

(sipX Configuration Server, 2007) sipX Configuration Server, disponível em

http://sipx-wiki.calivia.com/index.php/SipX_Configuration_Server, consulta em 01/2007

(sipX Different Platforms, 2007) sipX Different Platforms, disponível em

http://sipx-wiki.calivia.com/index.php/SipX_on_Different_Platforms, consulta em 01/2007

(sipX Features, 2007) sipX Features, disponível em

http://www.sipfoundry.org/sipxpbx/index.html, consulta em 01/2007

(sipX Features Complete List, 2007) sipX Features Complete List, disponível em

http://sipx-wiki.calivia.com/index.php/SipX_Features, consulta em 01/2007

(sipX Overview, 2007) sipX Overview, disponível em

http://sipx-wiki.calivia.com/index.php/SipX_Overview%2C_Deployment_%26_Architecture, consulta em 01/2007

(SKYPE #1, 2006) Skype, Skype Inicial, disponível em

www.skype.com/intl/pt/, consulta em 10/2006

(SKYPE #2, 2006) Call phones with SkypeOut, disponível em

http://www.skype.com/products/skypeout/, consulta em 10/2006

(SKYPE #3, 2006) Skype, Download o Skype para Pocket PC 2.1, disponível em

http://www.skype.com/intl/pt/download/skype/mobile/, consulta em 10/2006

(Sou Java 1, 2007) Sou Java, Telefones Móveis Java MIDP, disponível em

http://www.club-java.com/TastePhone/J2ME/MIDP_mobile.jsp; jsessionid=7F2F7A12DE7AD34C2F025905BBB04D2E?l=pt , consulta em 05/2007

(Souza & Tude, 2007) Tude, E., de Souza, J.L.Telefonia Celular no Brasil, disponível em http://www.teleco.com.br, consulta em 02/2007

(Spencer, 2004) Spencer, Mark, Miller, Frank W. IAX Protocol Description, 2004, disponível em http://www.cse.iitd.ernet.in/~csd01426/minorp/iax.pdf, consulta em 01/2007

(Spencer, 2006) Spencer, Mark. IAX2, disponível em

http://www.ietf.org/internet-drafts/draft-guy-iax-02.txt, consulta em 01/2007

(Stevenson, 2006) Stevenson, T., Softphones Reviewed: Gizmo Project, disponível em

http://www.voipplanet.com/reviews/article.php/3607481, consulta em 03/2007

(SUN #1, 2006) Sun, Sun Developers Initial, disponível em

http://developers.sun.com/, consulta em 11/2006

(SUN #2, 2006) Skype, Getting Started with SIP API for J2ME, disponível em

http://developers.sun.com/techtopics/mobility/apis/articles/sip/index.html, consulta em 10/2006

(Swart & Esteves, 2004) Swart, H., Esteves, E. cdma2000 1xEV-DO: Tecnologia, Serviços e Mercado, disponível em http://www.teleco.com.br/tutoriais/tutorialcdma2000/default.asp

consulta 02/2007

(Symmetric NAT Traversal, 2006) NAT Traversal for Multimedia over IP Services

http://www.newport-networks.com/whitepapers/nat-traversal1.html

consulta em 02/2007

(Tanenbaum, 1996) Tanenbaum, Andrew S. Computer Networks. 3th Ed. – Prentice Hall, 1996

(Teixeira & Carniel, 2006) Teixeira, C., Carniel, J. Portal Java, Tutorial J2ME versão 1.1, disponível em https://portaljava.dev.java.net/files/documents/353/13024/Tutorial_J2ME.pdf

consulta em 03/2007

(Teleco #1, 2006) TELECO, WLAN/Wi-Fi, disponível em

http://www.teleco.com.br/wifi.asp, consulta em 10/2006

(Teleco #2, 2006) Teleco, Quem tem medo do WiMAX?, disponível em http://www.teleco.com.br/emdebate/eprado25a.asp, consulta em 10/2006

(Teleco 3G, 2006) TELECO, 3G: Tecnologias de 3ª Geração de Celular, disponível em http://www.teleco.com.br/3g_tecnologia.asp, consulta em 02/2007

(Teleco WCDMA, 2004) Tude, E., UMTS, disponível em

http://www.teleco.com.br/tutoriais/tutorialwcdma/default.asp, consulta em 02/2007

(Terra VOIP, 2006) Terra VOIP, disponível em http://voip.terra.com.br/vcp.cgi?+_stt=2020, consulta em 10/2006

(Timing Drift, 2006) Problem: Timing Drift, disponível em

http://www.voiptroubleshooter.com/problems/drift.html, consulta 10/2006

(Torres, 2005) Torres, G., Discos Rígidos CE-ATA, disponível em

http://www.clubedohardware.com.br/artigos/1062/2, consulta em 10/2006

(Tude AMPS/TDMA, 2003) Tude, E. AMPS/TDMA (IS-136), disponível em

www.teleco.com.br, consulta em 01/2007

(Tude Arquitetura, 2005) Tude, E. Arquiteturas para implantação de aplicações móveis wireless, disponível em http://www.teleco.com.br, consulta em 01/2007

(Tude CDMA, 2003) Tude, E. CDMA (IS-95), disponível em http://www.teleco.com.br, consulta em 01/2007

(Tude GSM, 2003) Tude, E. GSM, disponível em http://www.teleco.com.br, consulta em 01/2007

(Tutorial Teleco IP, 2006) Tutorial Telefonia IP, disponível em http://www.teleco.com.br/tutoriais/tutorialtelip/, consulta em 09/2006

(UnderstandJitter, 2006) Understanding Jitter in Packet Voice Networks (Cisco IOS Platforms), disponível em www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a00800945df.shtml,

consulta em 09/2006

(VoIPCallAdmission, 2003) VoIP Call Admission Control, disponível em

http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/voipsol/cac.htm, consulta em 09/2006

(VOIP-CTI, 2005) VOIP-CTI, slide 13 disponível em

www.usp.br/cci/downloads/VoIP-CTI-20-05-2005.ppt, consulta em 10/2006

(VoIP Center #1, 2007) VoIP Center, VoIP:Brasileiro usa cada vez mais telefone via Internet, disponível em

http://www.voipcenter.com.br/modules/news/article.php?storyid=2177, consulta em 06/2007

(VoIP Center #2, 2007) VoIP Center, VoIP: Única franquia de VoIP do Brasil vai à feira de franquias, disponível em

http://www.voipcenter.com.br/modules/news/article.php?storyid=2175, consulta em 06/2007

(VoiP Info, 2006) What is VOIP – Voip Info, disponível em

http://www.voip-info.org/wiki/view/What+is+VOIP, consulta em 02/2007

(VoIP MGCP, 2004) Trabalhos de Disciplina de Redes II da UFRJ, VoIP – Voice Over IP, disponível em

http://www.gta.ufrj.br/~rezende/cursos/ee1879/trabalhos/voip1/index.html, consulta em 10/2006

(VOIP Overview, 2006) VOIP Overview – Tutorial Reports.com, disponível em

http://www.tutorial-reports.com/internet/telephony/voip/overview.php, consulta em 09/2006

(VoIP UFRJ) Fone@RNP¸ disponível em http://www.voip.ufrj.br/, consulta em 06/2007

(VoIP UFSC) VoIP@UFSC, disponível em

http://www.voip.ufsc.br/, consulta em 07/2007

(VOIP USER OSER, 2005) About OpenSER

http://www.voipuser.org/forum_topic_1811.html, consulta em 01/2007

(Webinsider, 2004) Voip. Um dia você vai ter um telefone assim

http://webinsider.uol.com.br/index.php/2004/12/06/voip-um-dia-voce-vai-ter-um-telefone-assim/, consulta em 10/2006

(Whatis 4G, 2006) Whatis 4G, disponível em

http://whatis.techtarget.com/definition/0,,sid9_gci749934,00.html, consulta em 02/2007

(WhatisJitter, 2005) What is Jitter? A Definition from Whatis.com, disponível em

http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci213534,00.html, consulta em 09/2006

(WiBro, 2007) Wireless Broadband Overview, disponível em

www.wibro.or.kr/index.htm, consulta em 03/2007

(WiMax.com, 2007) WIMAX technology, news, jobs, training , disponível em

http://www.wimax.com/, consulta em 03/2007

(Wireless Brasil 4G, 2006) Wireless Brasil, Perspectivas 4G, disponível emhttp://www.wirelessbrasil.org/wirelessbr/index.php?option=com_content&task=view&id=41&Itemid=55, consulta em 01/2007

Anexo A – Diagrama de Classes

Anexo B – Diagrama de Fluxo

Anexo C – Diagrama de Seqüência: Comunicação de Usuários

Anexo D – Diagrama de Atividades: Autenticação

Anexo E – Diagrama de Atividades: Conexão de Dispositivos