Voz Sobre IP - Um estudo Experimental

RESUMO Serviços de voz sobre uma rede de dados baseada na arquitetura TCP/IP pode trazer sérios problemas de performance na rede, pois o TCP/IP não foi projetado para suportar aplicações de tempo real, não tendo como oferecer QoS. Para realizar um projeto de VoIP (Voz sobre IP),é necessário conhecer todo o tráfego existente na rede e verificar o quanto isto representa em relação a banda total da rede. Também deve conhecer o tipo de aplicação que se deseja implantar, verificando a banda de rede a ser utilizada por esta, e então projetar como a rede deverá ser estruturada. Para auxiliar no projeto de VoIP, pretendemos mostrar o que está sendo desenvolvido para que o protocolo TCP/IP ofereça QoS e também uma ferramenta para analise do tráfego de voz sobre redes TCP/IP.

1. INTRODUÇÃO Voz sobre IP é uma tecnologia que permite a digitalização e codificação da voz e o empacotamento em pacotes de dados IP para a transmissão em uma rede que utilize TCP/IP. Devido ao volume de dados gerado por uma aplicação VoIP, esta tecnologia se encontra em funcionamento em redes corporativas privadas, mas se a rede base para o transporte desta aplicação for a Internet, certamente não deve ser utilizada para fins profissionais, pois o TCP/IP não oferece padrões de QoS comprometendo desta forma a qualidade da voz [1]. A qualidade da voz fica dependente do tráfego de dados existente no momento da conversa. Uma grande diferença entre uma aplicação de dados e um aplicação de voz é que uma aplicação de voz é sensível ao atraso. Em uma rede IP não é possível garantir um atraso constante o que pode tornar uma aplicação de voz em tempo real, como por exemplo uma ligação telefônica, um serviço de baixa qualidade com a voz entrecortada e muitas vezes inteligível. Para resolver o problema de falta de QoS em redes IP, estão sendo desenvolvidos vários protocolos, entre eles o Protocolo de Reserva de Recursos (Resource ReSerVation Protocol – RSVP) que consiste em determinar um caminho fixo a ser percorrido por todos os pacotes IP e reservar banda de rede suficiente para atender a necessidade da aplicação e o Protocolo de Transporte em Tempo-Real (Real-time Transport Protocol – RTP) que atua como uma interface melhorada entre as aplicações de tempo real e os protocolos das camadas já existente. Mas de uma maneira geral, o RTP não garante o fornecimento de pacotes ou previne que os pacotes sejam entregues fora de ordem, e também não assume que a rede na qual ele está rodando é confiável, que fornece a entrega de pacotes em sequência ou garantia de tempo entre pacotes fixa. As próximas seções deste artigo dividem-se em duas abordagens: primeiramente vamos abordar o serviço de voz sobre o protocolo TCP/IP, onde voltaremos a falar sobre o problema de falta de QoS e depois vamos apresentar resultados do estudo experimental.

2. SERVIÇO DE VOZ SOBRE O PROTOCOLO TCP/IP TCP/IP é uma tecnologia de rede simples popularizada entre computadores com o sistema operacional Unix e a Internet. Atualmente o TCP/IP está presente na maioria dos sistemas operacionais de rede e é utilizado por muitas empresas em uma variedade de aplicações. TCP/IP é, especificamente, um protocolo de comunicação de dados projetado para aplicações não sensíveis ao atraso tais como: e-mail, web, ftp, etc. Devido a imprevisibilidade do atraso, os protocolos da camada de transporte do TCP/IP, o TCP e o UDP não são adequados para aplicações de voz em tempo teal. O Protocolo de Controle de Transporte (Transport Control Protocol – TCP) não suporta transmissão de voz em tempo real porque ele recupera os dados perdidos por retransmissão, assim o fornecimento dos dados, deve esperar por todas as retransmissões, gerando grandes atrasos. O Protocolo de Datagrama do Usuário (User Datagrama Protocol – UDP) evita este problema, fornecendo um serviço orientado a datagrama, com a desvantagem que este protocolo não é confiável [2]. Voz sobre IP é um conceito relativamente simples, basta transformar a voz em sinal digital e então empacotar os dados em uma aplicação IP dentro de uma rede de dados que utilize o IP como protocolo de nível de rede. Aliás, esta simplicidade é que permite transmitir dados e voz dentro de uma mesma rede. Aplicações de voz em tempo real sobre o protocolo IP já é uma realidade em rede privadas onde é possível exercer um controle sobre a rede, o que não é possível quando se fala de Internet [1]. A escolha de um codificador de voz é fundamental para o sucesso de uma aplicação VoIP, e também as técnicas de supressão de silêncio e cancelamento de eco. O codificador G.729 especificado pelo ITU-T tem uma qualidade de voz boa para comunicação, pontuação MOS 3.92 e uma taxa de bit pequena, sendo 8 kbits/s. Depois de codificada, a voz deve ser encapsulada no protocolo IP e transmitida. Antes do empacotamento é realizada a codificação da voz, gerando um fluxo de bits contínuo e então este fluxo deve ser separado em pequenos pedaços de bits e encapsulado em pacotes UDP que por sua vez, será encapsulado em pacotes IP para a transmissão pela rede

O QoS é definido pelo ITU-T na recomendação I.350 [3] como: "Qualidade de Serviço (QoS) é efeito coletivo de performance que determina o grau de satisfação do usuário deste serviço específico". As redes IP não oferecem nenhum tipo de QoS que é o principal problema para as aplicações VoIP. O IETF (Internet Engineering Task Force) desenvolveu vários tipos de protocolos destinados a oferecer QoS, de forma que esses protocolos possam contornar as limitações impostas por redes baseadas no protocolo IP. Neste artigo daremos ênfase a dois desses protocolos: o Protocolo de Transporte em Tempo-Real (Real-time Transfer Protocol – RTP) e o Protocolo de Reserva de Recursos (Resource ReSerVation Protocol – RSVP). O protocolo RTP foi definido pela RFC 1889, sua função principal é agir como uma interface melhorada entre as aplicações de tempo real e os protocolos das camadas já existentes. De uma maneira geral, o RTP não garante o fornecimento de pacotes no tempo desejado ou de qualidade de serviço, não previne que os pacotes sejam entregues fora de ordem, e também não assume que a rede na qual ele está rodando é confiável ou que fornece a entrega de pacotes em sequência [2]. O protocolo RSVP funciona no topo do protocolo IP, na camada de transporte. É um protocolo de controle comparável com o ICMP (Internet Control Message Protocol) ou IGMP (Internet Gateway Message Protocol). O RSVP foi projetado para funcionar com os protocolos de roteamento considerando um único receptor ou um grupo de receptores. Algumas aplicações são direcionadas para apenas um receptor enquanto que outras aplicações possam enviar dados a mais de um receptor sem ter que enviar para a rede inteira [5]. Os componentes do RSVP são: o transmissor, receptor e os roteadores entre a origem e o destino. O transmissor é quem conhece o receptor e tem dados a ser transmitido e que necessita de QoS. O receptor envia notificações para os roteadores se preparar para a chegada dos dados. Estes roteadores é quem reserva os recursos. Uma vez que estes passos são completados, o transmissor pode enviar os dados com sucesso. Com o RSVP, a aplicação é capaz de notificar antecipadamente qual o recurso da rede que será necessário. Para garantir a reserva, os roteadores envolvidos se comprometem a oferecer estes recursos. Se o roteador não é capaz de oferecer estes recursos, ou se os recursos não estão disponíveis, ele pode recusar a reserva. A aplicação é imediatamente notificada que a rede não suporta os recursos necessários, evitando assim tempo e custo de uma tentativa e erro.

3. ESTUDO EXPERIMENTAL O estudo experimental consistem em um ambiente de teste para avaliar o trafego de voz sobre uma rede IP. O ambiente de teste é composto por uma rede ethernet 10 Mbits/s e três estações conforme Figura 2 abaixo. Duas estações estão configuradas com o sistema operacional Windows 95 e com uma ferramenta que possibilita o uso de voz sobre IP, o Microsoft NetMeeting. A outra estação está configurada com o sistema operacional Linux e com um programa desenvolvido em C que possibilita a captura dos pacotes que estão trafegando na rede, adicionando aos mesmos o segundo e o microssegundo em que foram capturados e gravando os pacotes em um arquivo texto. Para que não haja atraso na gravação dos pacotes, estão sendo armazenados somente o cabeçalho IP e o tempo, tudo em memória. Após o número de pacotes desejado serem capturados, é gerado o arquivo texto com os pacotes que estão na memória da estação C. Um outro componente deste ambiente de teste é uma ferramenta desenvolvida em Delphi que analisa os pacotes gravados no arquivo texto e gera um gráfico onde é possível visualizar o tempo entre os pacotes. Esta ferramenta foi desenvolvida e está instalada na estação A. Os testes acontecem em duas etapas, primeiro é estabelecida uma conexão com o NetMeeting entre a estações A e estação B simulado uma conversa entre os usuários dessas estações, capturado-se os pacotes da rede através da estação C, e depois o arquivo texto é transferido da estação C para a estação A onde é executada a ferramenta de analise. A ferramenta de analise calcula o tempo médio entre os pacotes de cada instante (segundo) somente da aplicação de voz, pois é feito um filtro dos pacotes entre as duas estações, gerando um gráfico onde é possível analisar o desempenho da aplicação de voz. A Figura 3 mostra um exemplo onde foram capturados 1.000 pacotes de trafego geral em 22 segundos, sendo que 776 pacotes eram de voz. Durante os primeiros 8 segundos o tempo médio entre os pacotes se manteve estável, no instante 9 foi realizado uma transferencia de arquivo na rede e podemos observar no gráfico que o tempo médio entre os pacotes aumentou. No instante 10 estabilizou novamente e no instante 16 foi realizado outra transferencia de um arquivo maior e então observamos que o tempo médio aumentou novamente.

Com estes testes podemos observar que o protocolo TCP\IP não consegue manter um tempo entre pacotes fixo, pois o tempo entre pacotes de uma determinada aplicação varia de acordo com o trafego geral da rede ficando evidente a falta de requisitos de QoS para este protocolo. Quando aumenta o tempo entre pacotes compromete a qualidade do serviço de voz. 4. CONCLUSÕES Através deste estudo preliminar, conclui-se que ainda são necessários muitos avanços na tecnologia de voz em tempo real sobre redes IP. No estudo experimental apresentado foi definido apenas um ambiente de teste e apenas uma situação de trafego.

REFERÊNCIAS [1] S. Calvo. A Linguagem dos Negócios. Revista Network Computing, junho/99. [2] C. Lui. Multimedia Over IP: RSVP, RTP, RTCP, RTSP. [3] J. Rochol. Apostila de Redes de Computadores. CPGCC/UFRGS. Porto Alegre.

Mais Informação Sobre VOIP