Antes de 1950 a fala humana era convertida em sinais analógicos para que ocorresse a transmissão de voz, que realizava toda a viagem entre esses dois pontos em formato analógico. Então alguns problemas estavam presentes como o ruído e a economia.

A partir de então foi introduzida a tecnologia que convertia a fala em sinais digitais. Logo, a invenção e implantação das linhas T1 permitiram a transmissão de voz a uma taxa de 1.544 megabits por segundo. Como estes sinais digitais eram formados por 0s e 1s, logo eles podiam ser decodificados com qualidade próxima ao original, com isso o impacto da distância na qualidade da fala foi virtualmente eliminado.

A questão da economia foi aliviada, pois as linhas T1 eram capazes de transportar canais de 64-Kbps. O mecanismo que coloca múltiplos canais na linha T1 é conhecido como TDM (time division multiplexing).

Uma das grandes desvantagens desse modelo era a reserva de banda mesmo nas situações onde nenhuma informação útil precisava ser enviada, caracterizada pelos períodos de silêncio.

A partir dos anos 70 houve um aumento no uso de redes baseadas em pacotes para a transmissão de dados. Logo surgiram esses dois paradigmas, as redes comutadas por circuitos e as por pacotes. Onde neste novo modelo os pacotes de voz poderiam ser transmitidos através de rotas diferentes, a largura de banda necessária seria aquela que realmente seria usada [4].

Foi também em 1970 que a idéia de VoIP começou a ser discutida [9]. Mas apesar disto o VoIP não se estabeleceu comercialmente até meados dos anos 90.

Este desenvolvimento gradual pode ser atribuído à falta de uma infra-estrutura e ao fato que o sistema convencional de telefonia (Public Switched Telephone Network) ainda era uma alternativa muito confiável para a transmissão de voz, especialmente comparado com a pouca qualidade das chamadas VoIP iniciais.

Em 1995 a Vocaltec (www.vocaltec.com) produziu o primeiro produto VoIP comercial que requeria que ambos os participantes da chamada tivessem o software instalado no PC assim como uma conexão de Internet. Mas ainda não era possível realizar chamadas através dos PSTN.

Com o rápido crescimento da Internet nos anos 90 acompanhado dos investimentos na infra-estrutura da rede IP. O VoIP finalmente tornou-se uma alternativa viável para a transmissão de voz sobre o PSTN, e um dos grandes fatores que influenciaram a adoção do VoIP foi o custo das ligações, principalmente as de longas distâncias [8].

Qualidade de Voz

O paradigma do melhor esforço (best effort) por parte da rede Internet em relação aos pacotes de dados não é suficiente para uma aplicação de voz, já que esta aplicação é sensível ao atraso. Em uma rede IP não é possível garantir um atraso constante ou, no mínimo, com uma variação dentro de limites definidos, o que torna uma aplicação de voz em tempo real (como por exemplo uma ligação telefônica), inviável ou, como costuma ser, um serviço de baixa qualidade com voz entrecortada e pouco legível [10].

As redes IP não oferecem nenhum tipo de QoS as suas aplicações, o que é considerado atualmente o principal empecilho para as aplicações multimídia. Vários fatores determinam a qualidade de voz, dentre eles temos a escolha do codificador de voz, a perda de pacotes, o delay e o jitter.

Codificadores de Voz (Codecs)

O objetivo dos codecs (coding/decoding) é transformar os sinais analógicos produzidos pela fala humana em dados digitais de uma maneira compacta.

Um grande número de diferentes codificadores de voz são usados nas redes VoIP. Entre eles existem os padronizados da série G recomendados pelo ITU (International Telecommunication Union), sendo o mais comuns o G.711, que encodifica a uma taxa de 64 Kbps, e G729, que encodifica a 8Kbps. Cada um dos codecs tem atributos diferentes, incluindo nível de compressão, qualidade etc [11].

Devemos notar que codecs complexos que necessitam de pouca largura de banda tendem a gerar um atraso no processo de empacotamento.

Uma outra técnica para aumentar a eficiência da largura de banda seria a detecção de voz ativa e supressão do silêncio.

Característica dos vários codificadores de Voz

A qualidade das chamadas telefônicas proporcionadas pelos codecs é geralmente medida por critérios subjetivos, onde são realizados testes em condições controlados usando um grande numero de usuários para determinar este parâmetro chamado MOS (Mean Opinion Score), onde esta é uma medida de qualidade de voz amplamente aceita em telefonia que varia entre 1(ruim) a 5(excelente).

Perda de Pacotes

Como transmissão de voz é sensível ao atraso logo torna-se inviável a utilização do protocolo TCP devido a sua característica de retransmissão, devemos então utilizar o protocolo UDP que é o mais indicado para sua implementação, porém este protocolo não apresenta nenhuma garantia quanto a entrega dos pacotes. Perdas maiores que 10 % geralmente são intoleráveis. Então algumas abordagens são utilizadas para que este efeito seja compensado, que são os mecanismos de correção.

Jitter

O jitter é a variação do atraso, ou seja é a variação da taxa de chegada dos pacotes que é introduzido pelo atraso na rede. Uma das alternativas para atacar este problema seria a utilização de um buffer no lado receptor ou nos Media Gateways, porém como se trata de uma aplicação iterativa a utilização de buffer não seria muito apropriada [2].

Esta figura demonstra um caso em que o atraso esperado é de 20 ms, porém a real chegada dos pacotes de da em intervalos distintos.

Delay / Latência

Em termos de telefonia, latência é a medida de tempo entre o momento em que o emissor pronuncia a sua voz até esta ser percebida pelo receptor. Grandes valores de latência não necessariamente degrada a qualidade do som, mas o resultado pode resultar em uma falta de sincronização entre os usuários [11].

O ITU (International Telecommunication Union) recomenda os seguintes tempos limites de transmissão :

¡ 0 até 150 ms: aceitável para a maior parte das aplicações

¡ 150 até 400 ms: aceitável para ligações internacionais

¡ > 400 ms: inaceitável para a maioria das aplicações

A figura anterior descreve quais são os atrasos que um pacote pode sofrer.

Protocolos de Transporte

Aplicações típicas de Internet usam TCP/IP, enquanto VoIP usa RTP/UDP/IP. O TCP é um protocolo confiável que utiliza confirmações e retransmissões para assegurar se os pacotes foram recebidos. O TCP tem a característica de ajustar a taxa de transmissão, que aumenta quando a rede está descongestionada, mas diminui rapidamente quando o host originador não recebe uma confirmação positiva do host destino. Logo o TCP não é um protocolo adaptável a aplicações em tempo real como a transmissão de voz, porque as características de confirmação e retransmissão levam a um atraso excessivo [1].

O UDP prove um serviço de entrega não confiável utilizando o IP para transportar suas mensagens entre dois pontos na Internet, quando utilizado juntamente com o RTP, prove uma função de transporte fim-a-fim para aplicações que transmitem dados real-time, como áudio e vídeo.

RTP

O Real-time Transport Protocol (RTP) é um protocolo da camada de aplicação que tem como objetivo carregar informações multimídias que ficam contidas em seus cabeçalhos. Informações como número de seqüência, timestamp, codificação entre outros, podem ser passados para o receptor [1].

RTP roda sobre o UDP. Onde o lado emissor encapsula a informação de mídia em pacotes RTP, então estes serão encapsulados em segmentos UDP e em seguida são enviados para a camada IP.

Este protocolo está sendo altamente utilizado, o que permite uma maior inter-operabilidade entre as aplicações multimídias.

É importante enfatizar que o RTP não prove um mecanismo para assegurar o tempo de entrega ou qualquer tipo de qualidade de serviço, a entrega pode se dar de maneira desordenada e sem nenhuma garantia.

RTCP

Real-time Control Protocol (RTCP) é baseado na transmissão periódica de pacotes de controle para todos os participantes de uma sessão. O RTCP pode ser usado em conjunto com o RTP, onde os pacotes RTCP são transmitidos por cada participante em uma sessão RTP para todos os outros participantes na sessão usando IP multicast. Os pacotes RTCP são enviados periodicamente e contém informações que representam estatísticas que podem ser úteis para a aplicação. Estas estatísticas incluem o número de pacotes perdidos e o jitter [2].

O RTCP executa as seguintes funções:

¡ Prove o feedback da qualidade da distribuição de dados;

¡ Controla a taxa para que o RTP seja escalável para um grande número de participantes

¡ Transporta o mínimo de informações de controle de sessão

A figura anterior demonstra a encapsulação dos pacotes UDP pelo cabeçalho RTP, ao ser transmitidos pela rede estes pacotes chegam até seu destino, a partir de então algumas informações de controle podem ser enviadas para o receptor através do protocolo RTCP.

Cenários

Agora serão mostrados os diferentes cenários de VOIP segundo David Clark, MIT.

Cenário 1: Uso da Internet como acesso à Rede Telefônica

Através de um telefone o usuário disca para a central telefônica local que se conecta a Internet através de um gateway. O gateway reconhece, valida o número do chamador e solicita o número do destino. Então o gateway de saída mais próximo do usuário de destino chama o telefone desejado, e após a chamada ser atendida, inicia a conversação através de datagramas IP entre os gateways e circuitos na rede telefônica.

Este cenário apresenta as seguintes características:

¡ É necessário interconectar Rede Telefônica à Internet

¡ Não requer acesso de nós baseados em computadores

¡ Podem operar através de regiões dedicadas da Internet

¡ Muito utilizado hoje para baratear custos de telefonia de longa distância

Cenário 2: Inter-operação entre a Internet e a Rede Telefônica

Nessa modalidade a chamada feita do computador de um usuário é roteada pelo provedor de telefonia IP pela Internet até o ponto mais próximo possível de seu destino. Nesse ponto ela é transformada em voz e transferida para a rede de telefonia convencional, que completa a chamada para o aparelho fixo ou celular da pessoa desejada. Alguns serviços de telefonia IP também permitem receber no PC ligações originadas em telefones fixos ou celulares.

Este cenário apresenta as seguintes características:

¡ É necessário interconectar Rede Telefônica à Internet

¡ Requer acesso de nós baseados em computadores

¡ Provê comunicação entre usuários de computadores e de terminais telefônicos tradicionais

¡ Aplicação típica: acrescentar telefonia aos serviços disponíveis através de WWW

Cenário 3: Substituição da Rede Telefônica pela Internet

Nessa modalidade todo o tratamento de voz é realizado nos PCs (softphone) , sendo a chamada estabelecida com base no endereço IP do receptor, podendo o PC ser substituído por um telefone com capacidade de codificação de voz e implementação do protocolo IP (Hardwarephone).

Este cenário apresenta as seguintes características:

¡ Não existe mais a Rede Telefônica de comutação de circuitos

¡ Requer acesso de nós baseados em computadores

¡ Provê comunicação apenas entre usuários de computadores (ou telefones IP)

Componentes do VoIP

As tecnologias envolvidas no processo de telefonia IP podem ser dividas em quatro categorias: sinalização, codificação, transporte e o controle de gateway.

O propósito dos protocolos de sinalização é o de criar e gerenciar conexões entre endpoints. Então quando a conversação começa o sinal analógico produzido pela voz humana precisa ser codificado em formato digital para ser transmitido através da rede IP. A rede IP deve assegurar que a conversação em tempo real é transportada de maneira a produzir uma qualidade de voz aceitável. Finalmente é necessário para o sistema de telefonia IP que seja realizada a conversão através de gateway para outro formato possibilitando a inter-operação entre a rede IP e a rede de telefonia convencional (PSTN) [4].

O Public Switched Telephone Network (PSTN) é a coleção de equipamentos que são responsáveis por prover o serviço de telefonia convencional das redes públicas.

Uma vez que o usuário disca o número de telefone, a sinalização é requerida para determinar o status disponível ou ocupado e para estabelecer a chamada. Signaling System 7 (SS7) é o conjunto de protocolos usados para estabelecer, finalizar e manter a chamada no ambiente PSTN.

A próxima figura descreve um tipo de rede VoIP utilizando um SS7-to-IP gateways. SS7 provê o controle de chamada dos dois lados do tradicional PSTN, enquanto o H.323/Session Initiation Protocol (SIP) prove o controle de chamada na rede IP. O media gateway provê a conversão circuito para voz. [2]

Media Gateway

As funções de telefonia foram transferidas para um novo elemento de rede denominado Media Gateway (MG). Este é responsável pela interface de mídia entre o PSTN e a rede IP. O MG é um endpoint simples, ele faz somente o que lhe é mandado, ele não compreende a sinalizações tanto do PSTN quanto da rede IP, ele também não compreende os serviços e nem as chamadas. O MG cria, modifica e destrói conexões entre o PSTN e a rede IP.

Media Gateway Controller

O Media Gateway Controller (MGC) é um endpoint inteligente, ele interage com os pontos para estabelecer, modificar e destruir conexões entre os pontos de uma rede. A manipulação dessas conexões resulta em vários serviços: estabelecimento de chamadas, características como transferência, espera e encaminhamento. O MGC é o componente que supervisiona as chamadas e serviços de fim a fim. Freqüentemente ele é implementado em um componente de sistema de alta confiabilidade.

MGCs e MGs interagem um com o outro através de interfaces proprietárias, ou por protocolos padrões que estão sendo desenvolvidos tanto pelo ITU quanto pelo IETF, que são o H.323 e o SIP respectivamente.

H.323

O H.323 é derivado dos protocolos PSTN usados para acessar os serviços PSTN Q.931. Conexões VoIP em H.323 seguem o modelo ISDN: a mesma seqüência de mensagem é usada para estabelecer e terminar chamadas. H.323 foi entendido para suportar um número de serviços, novamente este segue o modelo da arquitetura de redes TDM.

O H.323 é um conjunto de protocolos para voz, vídeo, e conferência de dados sobre uma rede baseada em pacotes como a Internet. A pilha de protocolo H.323 é projetada para operar sobre a camada de transporte. Logo o H.323 pode ser usado sobre qualquer rede baseada em pacotes, como por exemplo TCP/IP com o objetivo de prover uma comunicação multimídia em tempo real.

SIP

Session Initiation Protocol definido pelo IETF, é um protocolo de sinalização para chamadas telefônicas sobre a rede IP. Diferente do H.323, porém o SIP foi projetado especificamente para a Internet. Ele explora a maneabilidade da rede IP e faz o desenvolvimento em aplicações telefônicas de maneira simples. SIP é um protocolo de sinalização da camada de aplicação, utilizado para criar, modificar e terminar sessões com um ou mais participantes [12].

SIP pode ser empregado para iniciar sessão e convidar membros para sessão. O protocolo de sinalização suporta de maneira transparente serviços de re-direcionamento e mapeamento de nomes. Este permite a implementação inteligente de serviços para rede telefônica [2].

SIP suporta cinco facetas para estabelecer e terminar comunicações multimídias:

¡ User location: determinação dos hosts para serem usados pela comunicação;

¡ User capabilities: determinação da mídia e paramentros de mídia para ser usado;

¡ User availability: determinação da vontade da parte chamada para realizar a comunicação;

¡ Call Setup: ringing, estabelecer os parâmetros da chamada em ambos os lados da ligação;

¡ Call handing: realizar transferência e terminar chamadas.

Estes são alguns métodos que o SIP implementa:

¡ INVITE Inicia a chamada

¡ CONNECTED Confirma a resposta Final

¡ BYE Termina e transfere a ligação

¡ CANCEL Cancela o search e o ring

¡ REGISTER Registra no servidor local

¡ UNREGISTER leave servidor

¡ OPTION Consulta o servidor sobre a capacidade

A figura acima descreve como funciona a comunicação SIP, onde um usuário (user@nortel.com) quer iniciar uma sessão com o usuário (pulver@von1). Ao enviar a mensagem de requisição (INVITE) o Proxy intermediar a conexão com o intuito de controlar e possivelmente (no caso de telefonia) tarifar esta comunicação.

Podemos Concluir que algumas das mais importantes diferenças entre H.323 e o

SIP são:

¡ H.323 é completo, ou seja, é um protocolo integrado e adaptado para conferências multimídias, possuindo as seguintes funcionalidades: sinalização, registro, controle de admissão, transporte e codecs

¡ SIP, por outro lado, se encarrega somente da iniciação da sessão e gerenciamento em um simples componente. SIP trabalha junto com o RTP, G.711 e QCIF H.261, porém estes não são de uso obrigatório. O SIP pode ser combinado com outros protocolos e serviços.

¡ H.323 vem do ITU, enquanto o SIP vem do IETF.

Podemos observar que o SIP provê um conjunto de serviço similar ao H.323, porém com baixa complexidade, alta extensibilidade e melhor escalabilidade [3].

Localização dos Gateways

Apesar da Internet ter sido projetada para manipular dados com característica elástica, nós podemos perceber o grande aumento das aplicações em tempo real, e um dos fatores que contribui para isto é o crescente aumento do uso da telefonia IP. Um dos fatores críticos para a difusão desta tecnologia é a implementação da interoperabilidade com as redes telefônicas existente. Esta interoperabilidade é possível através da utilização do Internet Telephony Gateway´s (ITG´s) que executa a tradução entre a rede IP e o PSTN. Então para que um IP host estabeleça a chamada com o usuário da rede PSTN, este host deve conhecer o endereço IP do gateway apropiado.

Prover conectividade entre usuários de telefonia IP e PSTN é a função do Internet Telephony Gateway (ITG). O ITG pode trabalhar tanto na camada de rede quanto na camada de aplicação. Na camada de rede o ITG traduz as informações de endereçamento do PSTN em IP e vice-versa. Como isto requereria significante mudanças nos roteadores e equipamentos telefônicos existentes, logo o ITGs comumente operam em nível de aplicação. Isto implica que eles agem como sistemas finais em ambos os lados da rede IP e do PSTN. Quando um IP hosts quer contatar um usuário PSTN, este deve primeiro contatar o ITG, o qual terminaria a porção IP da chamada e iniciaria uma nova chamada no PSTN para o destino final.

Com aplicações gateways, é necessário que os sistemas finais contatem primeiramente os gateways antes de atingir o destino final. Note que os usuários podem não ter conhecimento desta operação, apenas o software subjacente e hardware que têm que contatar o ITG. O problema existe em ambos os lados do ITG. Por causa das diferenças entre as interfaces e arquiteturas de rede, estes problemas são resolvidos em diferentes modelos.

No artigo [7] foi realizada uma análise de várias arquiteturas de protocolo, incluindo base de dados hierárquica, multicast advertisement, routing protocols,e base de dados centralizadas. Foi proposta uma nova arquitetura chamada Brokered Multicast Advertisements (BMA) que fornece um mecanismo escalável para a localização dos ITGs. Neste artigo foi concluído que o BMA é a solução mais efetiva para solucionar o problema de localização de gateways.

Firewall e NAT

Network Address Translation (NAT) está sendo usado por vários provedores de serviços como uma alternativa para o problema de não possuir endereços IP suficientes. É possível termos uma situação onde existe apenas uma conexão DSL com um único endereço IP, mas queremos que múltiplos computadores compartilhem essa conexão e tenham acesso a Internet.

O NAT resolve este problema através do mapeamento interno dos endereços para um endereço público. Um par interno IP:porta é mapeado externamente para outro IP:porta, e quando o NAT recebe o pacote com o IP:porta externo ele sabe como re-encaminhar o pacote de volta ao terminal interno [6].

A figura anterior mostra como um NAT pode fazer o mapeamento para dois computadores que estão em uma rede privada utilizando o mesmo número de porta em suas aplicações.

O problema do Firewall

O objetivo do firewall é proteger a rede de ser acessada por fontes não autorizadas. Isto é feito através do bloqueio de tráfego baseado em três parâmetros: a fonte, o destino, e o tipo de tráfego. Firewalls também tomam decisões baseados na direção do fluxo de tráfego. Tipicamente, tráfegos de chegada (de domínios públicos não conhecidos) é somente permitido se auela sessão foi iniciada por um dispositivo do domínio privado.

A figura anterior mostra o funcionamento de um firewall.

O problema do NAT

Cada dispositivo em uma rede privada tem o seu próprio endereço IP. O tráfego (mídia streaming por exemplo) enviado para um dispositivo na rede pública vai ser dinamicamente associado a um número de porta específico no endereço público pelo NAT. O NAT mantém a tabela que relaciona os endereços privados e número de portas para a porta e endereço IP públicos. É importante notar que esta ligação somente pode ser iniciada por um fluxo de saída, e chamadas entrantes que não são solicitadas não podem ser suportadas por esse modelo.

As mensagens fim-afim do SIP entre clientes contêm detalhes sobre endereço e porta privada do cliente, que serão usados pelos fluxos de mídia. Quando os clientes tentarem usar o endereço privado para enviar ou receber mídia, a conexão falha e eles não serão roteados. Note que esta questão também se aplica a outros protocolos de sinalização como o H.323 e MGCP.

Qualquer abordagem para solucionar este problema deve permitir uma comunicação segura nos dois caminhos incluindo as chamadas entrante não solicitadas e minimizar dependências na atualização dos NATs [5].

A figura anterior ilustra o Problema do NAT.

Métodos para resolver o Problema do NAT

A necessidade fundamental das aplicações VoIP é descobrir e usar o endereço de IP externo e porta que o NAT seleciona para a sinalização e os fluxos de mídia, Uma vez que estas informações são conhecidas, o cliente VoIP (um SoftPhone por exemplo) pode colocar estas informações dentro da sinalização do VoIP para estabelecer a chamada . Isto assegura que a chamada é estabelecida usando endereços e portas públicos e assegura a conectividade fim-a-fim.

Em seguida serão descritos alguns mecanismos para resolver o problema do NAT.

Universal Plug and Play

UPnP é uma tecnologia que é predominantemente usada por usuários domésticos, uma das grandes forças por trás do UPnP é a Microsoft.

A arquitetura UPnP foi projetada para tratar de várias questões gerais não somente VoIP e foi projetado para permitir a configuração de redes pequenas por pessoas tipicamente não qualificadas. UPnP permite que aplicações cliente descubram e configurem os componentes da rede, incluindo NATs e Firewalls, que estão equipados com o software UPnP.

Nesta arquitetura um cliente pode perguntar para o NAT como ele mapeou um endereço particular IP:porta através do protocolo chamado UPnP. O cliente consulta o NAT via UPnP perguntando qual mapeamento deveria ser usado se ele quisesse receber na porta x. O NAT responde com o par IP:porta que alguém na Internet pública deveria usar para alcançar o cliente naquela porta.

A principal desvantagem desta abordagem está relacionada com a segurança, ela não resolve este problema de forma satisfatória, e atualmente existem um pequeno número de fabricantes de NAT e Firewall comprometidos em suportar o UPnP.

Simple Traversal of UDP Through Network Address Translators (STUN)

O protocolo STUN habilita um cliente SIP para descobrir se este está atrás de um NAT e para determinar o tipo de NAT.

O STUN identifica o lado público do NAT, detalhado por uma inspeção exploratória das mensagens STUN que chegam no servidor STUN. O cliente STUN-enabled envia uma mensagem exploratória para o servidor STUN externo para determinar a porta de recepção que será usada. O servidor STUN examina a mensagem que chegou e informa ao cliente qual é o endereço público IP:porta que foi usado pelo NAT, onde esta resposta será usada na mensagem de estabelecimento da chamada.

A figura anterior ilustra o funcionamento do STUN.

O STUN confia no fato que uma vez que a porta de saída foi mapeada pelo servidor STUN, qualquer tráfego vindo de qualquer lado da rede com qualquer endereço IP fonte, será capaz de usar o mapeamento na direção reversa e então atingir a porta de recepção do cliente.

O NAT não trabalha dessa forma, logo ele fica susceptível a ataques e geralmente cria problemas de segurança. Logo, este método falha na resolução do problema de Firewall, porque ele introduz riscos adicionais para a segurança que são inaceitáveis para o gerenciamento das comunicações.

O STUN apresenta outras duas desvantagens ele não trabalha com o tipo mais comum de NAT o NAT simétrico. Ele também não trata a necessidade de suportar dispositivos SIP baseados em TCP.

Application Layer Gateway (ALG)

Esta técnica relacionada com a instalação de um Firewall/NAT modificado chamado Application Layer Gateway, que compreende a mensagem de sinalização e o seu relacionamento com o fluxo de mídia.

A figura anterior ilustra o funcionamento do ALG.

O ALG processa a sinalização e o stream de mídia, assim ele pode modificar a sinalização para refletir o endereço IP público e a porta que será usada.

Como sugerido esta técnica requer substituições dos NAT/Firewall existentes. Alternativamente alguns fabricantes provem atualização de software para suportar as funcionalidades do ALG.

O ALG requer habilidade para configuração e gerenciamento, o que significa que atualizações ou novas instalações não serão empreendidas de forma rápida.

Manual Configuration

Neste método, o cliente é manualmente configurado com detalhes do endereço público e porta, que o NAT vai usar para sinalização e mídia. O NAT é também manualmente configurado com o mapeamento estático para cada cliente.

Este método requer que o cliente deve ter fixado o par IP:porta para a recepção da sinalização e da mídia.

A figura anterior ilustra o funcionamento da configuração manual.

Devido ao caráter manual e a necessidade do prévio conhecimento da rede, assim como o perfil fixo das configurações, logo esta abordagem torna-se pouco adaptável em ambientes de rede amplo [5].

Conclusão

O objetivo do survey foi discutir alguns conceitos sobre a questão da tecnologia de transmissão de voz sobre o protocolo de Internet que são: qualidade de serviço, protocolos de transporte, protocolos de sinalização, diferentes cenários de comunicação, localização dos gateways, e diferentes abordagens para resolução do problema de NAT.

Chegamos a conclusão que prover um serviço de voz confiável e de alta qualidade é uma tarefa complexa e desafiadora, vários são os fatores envolvidos neste projeto. Enquanto isso o VoIP continua como uma área de intensas pesquisas e desenvolvimento, onde nós podemos esperar várias soluções para um futuro próximo, bem como a crescente aumento do uso desta tecnologia.

Dada a relativa imaturidade dos produtos Voip e a relutância de descartar bilhões de dólares investidos no modelo de redes de comutação por circuito, logo será preciso muitos anos para que a transmissão pura através de redes baseadas em pacotes seja realidade [13].

Referências

[1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, RTP: A transport protocol for real-time applications, IETF RFC 1889,1996.

[2] Udani, S.,"Voice over IP.pdf", Potentials, IEEE , Oct.-Nov. 2001

[3] H. Schulzrinne and J. Rosenberg, "A Comparison of SIP and H.323 for Internet Telephony", Network and Operating System Support for Digit Audio and Video (NOSSDAV), Cambridge, England, Jul. 1998.

[4] Upkar Varshney and Snow Andy, Communications of the ACM, January 2002/Vol. 45, No. 1

[5] Newport networks, Solving the Firewall and NAT Traversal Issues for Multimedia Services over IP, Disponível em: http://www.newport-networks.com/cust-docs/910033-nat-wp.pdf [referred to 04.7.2005].

[6] B. Sterman and D. Schwartz. NAT Traversal in SIP, 2001. Disponível em:

http://corp.deltathree.com/technology/nattraversalinsip.pdf [referred to 04.7.2005].

[7] J. Rosenberg, H. Schulzrinne, Internet Telephony Gateway Location

[8] Weiss, M. and Hwang, J. Internet Telephony or Circuit-Switched Telephony: Which is Cheaper? School of Information Science, University of Pittsburgh, Pittsburgh, PA, Sept. 1999

[9] Schulzrinne, H. Service for telecom, Version II. IEEE Internet Comput. 3, 3 (May/June 1999), 4043.

[10] Voz sobre IP: Um estudo experimental, C. L., Sitolino, UNOESTE

[11] Voice Over Internet Protocol (VoIP), BUR GOODE, PROCEEDINGS OF THE IEEE, VOL. 90, NO. 9, SEPTEMBER 2002

[12] J. Rosenberg, H. Schulzrinne, Camarillo, Johnston, Peterson, Sparks, Handley, and Schooler, SIP: Session initiation protocol v.2.0, IETF RFC 3261, 2002.

[13] A Commentary on the Evolution to Internet Telephony, Henning Schulzrinne, IEEE Internet Computing 1999 IEEE.