Estudo experimental de videoconferência pessoal em inter-redes IP com QoS

José Luiz A. da Fonseca <joseluiz@petrobras.com.br>
Michael A. Stanton <michael@ic.uff.br>

Tecnologia da Informação
Instituto de Computação
PETROBRAS
Universidade Federal Fluminense

Resumo
1. Introdução
2. Requisitos das aplicações de videoconferência pessoal
3. Parâmetros de QoS
4. Descrição do experimento
5. Resultados e interpretação
5.1 A relação entre a demanda e a banda nominal disponível
5.2 Qualidade de Serviço
5.3 Interpretação dos resultados
6. Conclusões
Referências bibliográficas

Resumo

Uma videoconferência em ambiente de rede de dados envolve a transmissão entre os participantes de diferentes fluxos de tráfego, incluindo alguns de tempo real como áudio e vídeo. Numa inter-rede IP sem suporte de Quality of Service (QoS), o desempenho de aplicações de tempo real pode ser muito prejudicado por congestionamento, inviabilizando-as. Avanços recentes na tecnologia de roteadores (IntServ, DiffServ) possibilitam a proteção de aplicações de tempo real das conseqüências maléficas do congestionamento, possibilitando a convivência pacífica na mesma inter-rede de aplicações de tempo real com tráfego de melhor esforço. Neste trabalho, descreve-se um estudo experimental do uso da tecnologia DiffServ para proteger o tráfego de videoconferências do congestionamento causado por tráfego de melhor esforço. Os resultados demonstram que o modelo DiffServ viabiliza a utilização de aplicações de mídia contínua em redes de dados, através do atendimento de seus requisitos.

^

1. Introdução

Dentre as aplicações novas que começam a ser usadas nas redes IP estão as aplicações de videoconferência pessoal, que permitem aos usuários utilizarem computadores para participar de uma conferência, normalmente também permitindo o compartilhamento de documentos e aplicações. O trabalho aqui descrito originou-se de uma demanda da área de comercialização de combustíveis da Petróleo Brasileiro S/A (PETROBRAS), que tenciona utilizar os recursos de videoconferência pessoal para agilizar o processo de negociação de preços e agendamento de embarque de produtos com os escritórios da companhia no exterior.

Entretanto, como explicitaremos mais adiante, a instalação pura e simples do aplicativo de videoconferência pessoal na estação do usuário ligado a uma Intranet não garante a obtenção de recursos suficientes para um desempenho mínimo aceitável em uma sessão de videoconferência. Além disso, a tentativa de estabelecer uma conexão remota através desta aplicação pode comprometer o funcionamento da rede como um todo, degradando o desempenho das outras aplicações de dados que dela já se utilizam.

Portanto, o objetivo deste trabalho é estudar experimentalmente os requisitos necessários para tornar viável a criação de sessões de videoconferência pessoal com desempenho aceitável entre duas estações de trabalho remotas, sem degradar o desempenho das outras aplicações cujos dados já transitam pela rede corporativa.

Na seção 2 serão apresentadas as principais características das aplicações de videoconferência pessoal. Na seção 3 serão apresentados os principais requisitos de QoS que servem para possibilitar o bom desempenho das aplicações de mídia contínua de tempo real. Na seção 4 será descrito o experimento realizado para fazer as medições de sessões reais de videoconferência. Na seção 5 serão mostrados os resultados destes experimentos e sua interpretação. Na seção 6 serão apresentadas as conclusões.

^

2. Requisitos das aplicações de videoconferência pessoal

A aplicação de videoconferência pessoal é a mais crítica sob o aspecto de requisitos de rede, pois além de ser uma aplicação bidirecional, ela transporta simultaneamente mídias de áudio e vídeo, além de dados. Estas aplicações devem utilizar um padrão a fim de permitir a interoperação entre aquelas de fabricantes diferentes como o H.323 [ITU 99]. Por exemplo, a aplicação NetMeeting codifica a mídia de voz com padrões H.323 como o G.711 [ITU 88] ou G.723.1 [ITU 96] e a envia através do protocolo RTP (Real-time Transport Protocol) [SCH96] encapsulado no UDP. Para a mídia de vídeo são utilizados padrões de codificação como o H.263 [RIJ 96], sendo também enviada por RTP sobre UDP. O TCP é o protocolo de transporte para a troca de dados.

Das três mídias transportadas, a de áudio é a que requer mais atenção à qualidade de serviço, para preservar a inteligibilidade da conferência e, portanto deve ter a preferência na alocação de recursos da rede na transmissão. Os requisitos de banda de rede para a mídia de áudio são pequenos, tipicamente não excedendo 75 kbps, e podem ser utilizadas codificacões de baixa taxa de bits, como o padrão G.723.1, para diminuir ainda esta necessidade de banda.

O retardo fim-a-fim para o áudio não deve ultrapassar o valor de 250 ms, a fim de impedir uma comunicação de áudio sem sincronismo entre os participantes. A rede também deverá garantir um jitter pequeno, a fim de não aumentar ainda mais o retardo, ao atrasar o ponto de reprodução dos pacotes para eliminar o jitter através de um buffer de recepção.

A mídia de vídeo deve ser a de menor prioridade, mesmo em relação à dos dados, e também precisa ser comprimida a fim de utilizar uma banda de rede menor. O H.323 especifica os padrões H.261 e H.263 para a mídia de vídeo.

Uma vez que a reprodução da mídia de vídeo deve estar sincronizada com a de áudio, ela acaba herdando os mesmos requisitos de retardo e jitter da de áudio, apesar desta por si só possuir requisitos menos restritivos.

Em suma, muitas das novas aplicações na Internet são de mídia contínua e necessitam de uma quantidade razoável de recursos de rede para funcionarem adequadamente. Muitas destas têm requisitos rígidos de temporização, o que requer serviços de rede mais sofisticados que os oferecidos pelo modelo IP tradicional de "melhor esforço", encontrado na Internet de hoje. Na realidade, elas necessitam que as atuais redes IP sejam capacitadas para dar tratamento diferente a fluxos de tráfego com requisitos distintos.

A solução para que as redes IP recebam tráfego de aplicações de mídia contínua de tempo real, e atendam aos seus requisitos, está em adicionar suporte para qualidade de serviço (QoS) a estas redes, permitindo que estas passem a contar com mecanismos que assegurem, dentro de certos níveis de certeza, que os requisitos de tráfego destas aplicações serão satisfeitos. Este assunto será tratado na próxima seção.

^

3. Parâmetros de QoS

A tecnologia de comutação de pacotes, na qual se baseiam as redes IP, possui algumas características que são decorrentes de sua arquitetura, e que não são encontradas no modelo de comutação de circuitos utilizado pelas redes telefônicas. É necessário identificar as características das redes IP que influenciam diretamente no desempenho das aplicações de mídia contínua de tempo real e, em especial, nas de videoconferência pessoal.

As redes IP atuais oferecem um serviço de entrega de pacotes chamado de "melhor esforço", que não oferece garantias de desempenho para seus usuários, e pacotes podem ser perdidos em trânsito. As aplicações tradicionais (WWW, correio eletrônico, transferência de arquivos) requerem confiabilidade, garantida através do uso do protocolo de transporte TCP. Estas aplicações são chamadas de "elásticas", pois não requerem um capacidade mínima de transmissão ou retardo máximo para funcionarem corretamente.

O retardo, a perda de pacotes e a capacidade de transmissão da rede são muito importantes para as aplicações de mídia contínua pois, embora elas possam tolerar pequenas perdas de pacotes, em contrapartida impõem restrições severas de temporização ou de capacidade mínima de transmissão para garantir sua própria viabilidade.

Caracterizamos a qualidade do serviço (QoS) recebido pela aplicação através dos chamados parâmetros de QoS, os quais incluem (1) o retardo fim-a-fim, (2) a taxa de perda de pacotes, (3) o jitter, e (4) a vazão.

Ao atraso total que um pacote experimenta durante o seu trajeto pela rede dá-se o nome de retardo fim-a-fim. Este é a soma dos retardos associados aos comutadores ou roteadores e aos enlaces intermediários, os quais são devidos ao processamento de comutação, à espera em filas aguardando retransmissão, ao tempo de transmissão pela interface ao enlace e ao tempo de propagação pelo enlace. A ocorrência de congestionamento causa aumento no tamanho das filas e conseqüentemente no retardo. Além disto, pode haver uma variação no retardo fim-a-fim, chamada jitter . Uma aplicação de reprodução poderá eliminar o jitter através do uso de um buffer de recepção, adiando com ele o "ponto de reprodução" do fluxo recebido. A conseqüência deste tratamento do jitter é o aumento do retardo fim-a-fim.

A taxa de perda de pacotes é calculada no lado do receptor como a razão entre as quantidades de pacotes perdidos e a quantidade de pacotes transmitidos, em cada intervalo de tempo considerado. As perdas de pacotes em aplicações de mídia contínua geralmente são devidas ao descompasso entre a taxa de transmissão (ou demanda) dos pacotes e a capacidade de transmissão do canal, o que leva ao congestionamento em um ou mais roteadores da rede, com ocrescimento das filas de pacotes, o aumento de retardo e eventual descarte dos pacotes.

Um dos principais atributos de um enlace de transmissão de dados é sua capacidade nominal de transportar bits, ou banda nominal. A vazão, ou a banda de rede ocupada pela mídia, corresponde à taxa de bits que são efetivamente transportados, tendo como valor máximo a banda nominal.

^

4. Descrição do experimento

Figura 1 - Rede para testes de QoS

Decidiu-se realizar um estudo experimental da transmissão de uma videoconferência em uma rede IP, com o objetivo de medir os parâmetros de QoS associados à transmissão, em diferentes condições ambientais. Em particular, um dos objetivos era avaliar a eficácia da implementação de suporte para QoS em equipamentos de roteamento, para possível posterior aproveitamento no atendimento das necessidades da PETROBRAS mencionadas na introdução. Do ponto de vista do estudo, a rede IP usada para interligar as duas pontas da videoconferência poderia ser reduzida a um único enlace serial entre dois roteadores.

Uma bancada de testes montada em laboratório (v. Figura 1) permitiu examinar, no enlace serial entre os dois roteadores, o efeito da concorrência entre dois tipos de tráfego: o tráfego de videoconferência da estação Videocon1 à estação Videocon2, e o tráfego cruzado (sintético) da estação Tráfego1 à estação Tráfego3. Os roteadores Rot1 e Rot2 usados no experimento eram da marca Cisco, modelo 2610 com IOS 12.1.5(T). Os dois tipos de tráfego foram gerados com os softwares NetMeeting 3.01 da Microsoft [MIC 99], e NetSpec 3.0 [JON 94], respectivamente.

O conteúdo da videoconferência foi gerado captando o som e imagem de um clipe de vídeo, reproduzido em um computador portátil.

Os parâmetros ajustáveis incluíam:

• a banda do enlace disponível entre os roteadores;
• a disciplina de QoS implementada para acesso a este enlace;
• as características da transmissão da videoconferência;
• as características do tráfego cruzado.

Os primeiros dois itens foram especificados através de configuração dos roteadores Rot1 e Rot2. No caso dos equipamentos usados, o modelo principal de QoS que pôde ser usado foi o DiffServ (Serviços Diferenciados) [BLA98], e puderam ser especificados PHBs (Per Hop Behaviours) que utilizavam diversas disciplinas de fila, incluindo WFQ (Weighted Fair Queueing) e uso de prioridades. O controle das características da transmissão da videoconferência foi feito através da escolha da codificação usada para o áudio e pelo tamanho e "qualidade" do vídeo (havia três opções de qualidade: alta, média, baixa). A taxa de transmissão do vídeo ficava sob controle da aplicação, não podendo ser ajustada diretamente pelo experimentador. O software NetSpec permitiu gerar uma ampla variedade de tráfegos cruzados, usando TCP ou UDP, com especificação de tamanho dos pacotes e as características temporais (transmissão contínua ou em rajadas).

As estações Videocon1 e Videocon2 foram instrumentadas para realizar coleta de dados que pudessem ser utilizados para calcular os parâmetros de QoS de interesse. Estes dados foram obtidos das mensagens SR (Sender Report) e RR (Receiver Report) do protocolo RTCP (RTP Control Protocol) [SCH 96], que carregam informações acerca da qualidade da transmissão em curso. Para a coleta de dados foram utilizadas o software TCPDump [TCPD] e sua versão para o ambiente Windows, WinDump 2.1 [DEO 00], que permitem acesso transparente aos pacotes RTCP gerados e recebidos por aplicações na mesma estação. O cálculo dos parâmetros de QoS envolveu a correlação entre os dados coletados nas duas estações, e foi realizado assincronamente.

Havia uma dificuldade prática em estimar o retardo fim-a-fim de um enlace, decorrente de pequenas defasagens de freqüência e fase que havia entre os relógios internos das máquinas. Portanto, o cálculo possível era do retardo de ida-e-volta no lado do transmissor, através dos pacotes SR e RR do RTCP, que carregam informações de temporização. Com a indisponibilidade da referência de tempo usada pelo RTP, acessível apenas pela aplicação de videoconferência, foi usada a referência de tempo do próprio WinDump associada à referência de tempo do RTP.

O jitter foi obtido diretamente a partir dos pacotes RR do RTCP enviados por Videocon2. Como o valor do jitter está expresso em unidades de amostragem, este valor precisava ser dividido pelo valor da taxa de amostragem do CODEC da mídia, para se obter um valor expresso em unidades de tempo.

A taxa de perda de pacotes foi calculada a partir de dois pacotes RR consecutivos do RTCP, pois estes informam a quantidade acumulada de pacotes perdidos e o maior número de seqüência do pacote RTP recebido até o instante de emissão do pacote RR.

A vazão mediu a taxa de bits recebida pelo roteador Rot2 sobre o enlace Frame-Relay, referentes aos fluxos de mídia enviados a Videocon2. Neste procedimento foi utilizado o pacote SR do RTCP para calcular o tamanho médio do pacote RTP de mídia, que junto com dois pacotes RR consecutivos do RTCP, permitiu calcular a taxa de bits recebida durante este intervalo de tempo. A este valor foram acrescentados os bytes referentes aos cabeçalhos do RTP (12 bytes), UDP (8 bytes), IP (20 bytes) e Frame-Relay (6 bytes).

^

5. Resultados e interpretação

Um primeiro resultado importante é a comprovação de que as técnicas de compressão podem ser um fator essencial para viabilizar uma sessão de videoconferência pessoal, na medida em que reduzem os requisitos de banda de rede necessários para a transmissão de mídia em tempo real. Em seguida, é mostrado que a utilização de mecanismos de QoS permite a convivência pacífica entre aplicações tradicionais de dados e as de mídia contínua.

^

5.1 A relação entre a demanda e a banda nominal disponível

A Tabela 1 demonstra os resultados dos testes (000)¹ e (002). No teste (000), cujo enlace Frame-Relay tem banda nominal de 64 kbps, foi transmitida a mídia de vídeo com resolução QCIF (176 x 144 pixels) com o CODEC H.263 gerando vídeo de máxima qualidade possível, e a mídia de áudio através do CODEC G.711 (64 kbps). Os valores para taxa de perdas e retardo de ambas as mídias mostram que uma banda de 64 kbps não é suficiente para uma sessão de videoconferência sem compressão das mídias. Já no teste (002) foi utilizado o mesmo enlace, entretanto com o CODEC G.723.1 de 5,3 kbps para o áudio e vídeo com baixa qualidade. Fica fácil perceber que agora já é possível estabelecer uma sessão de videoconferência, pois os parâmetros de QoS apresentam valores aceitáveis, como a ocupação de apenas 37 kbps da banda nominal do enlace de 64 kbps.

Tabela 1 - Testes (000) e (002): Eficácia como função da disponibilidade de banda nominal adequada

¹Esta numeração faz parte de uma bateria de cerca de 40 testes contemplando diferentes configurações, onde se utilizou um código de três dígitos.

Os resultados apresentados na Tabela 1, como nas demais tabelas abaixo, são as médias das séries temporais de cada um dos parâmetros de QoS.

Devemos observar que quando a demanda excede a banda nominal, os retardos grandes na Tabela 1 correspondem ao tempo médio na fila de pacotes de saída para o enlace serial, e são diretamente proporcionais à memória alocada no roteador Rot1 para esta fila. Não houve configuração explícita da quantidade desta memória nos experimentos realizados.

^

5.2 Qualidade de Serviço

O objetivo deste teste é reproduzir o cenário existente entre os escritórios do Rio de Janeiro e Buenos Aires, cujo enlace Frame-Relay possui uma capacidade de 384 kbps, onde no mínimo 256 kbps devem ser utilizados para o tráfego de dados tradicional, e no máximo 128 kbps devem ser utilizados para uma sessão de videoconferência. Para a transmissão da mídia de áudio foi utilizado o CODEC G.711 a 64 kbps, enquanto que o vídeo foi transmitido como de baixa qualidade para evitar ocupação desnecessária de banda de rede. Nestes testes, a aplicação de videoconferência sofria concorrência de um tráfego de carga de rajada baseado em UDP com taxa de 3,84 Mbps, após 4 minutos do início da sessão. Este tráfego cruzado era gerado na estação Tráfego1 tendo como destino a estação Trafego3.

Tabela 2 - Teste (035): Videoconferência não protegida do tráfego cruzado (melhor esforço)

No teste (035), apresentado na Tabela 2, não foi utilizado nenhum mecanismo de QoS para proteger a videoconferência do tráfego cruzado. Já nos testes (135) da Tabela 3 e (235) da Tabela 4 havia uso de suporte para QoS baseado no modelo DiffServ. Foram criadas duas classes de serviço: premium, para o tráfego de videoconferência e gold para o tráfego cruzado.

Tabela 3 - Teste (135): Videoconferência protegida por DiffServ com filas de prioridade (LLQ)

No teste (135) o PHB foi implementado através de WFQ (Weighted Fair Queueing) [DEM 90]. Entretanto, o tráfego da classe premium era direcionado para uma fila de prioridade (LLQ - Low Latency Queueing) [CIS 99] com garantia de banda máxima em 128 kbps, enquanto que o tráfego gold era direcionado para outra fila simples com garantia de banda mínima de 160 kbps. O uso de 160 kbps era devido a restrições de configuração do roteador.

Tabela 4 - Teste (235): Videoconferência protegida por DiffServ com WFQ

No teste (235) o PHB usou WFQ [CIS 00], mas sem filas de prioridade, onde 33% da banda disponível eram alocados à classe premium e 66% à classe gold.

Os resultados do teste (035) indicam que existe um grande impacto nos parâmetros de QoS quando entra em transmissão o tráfego cruzado, tornando inviável a sessão de videoconferência. Entretanto, a utilização de mecanismos de QoS dos testes (135) e (235) permite a continuação da sessão, com redução irrelevante no desempenho, mantendo os parâmetros de QoS dentro de valores aceitáveis.

O mecanismo usado no teste (135) parece ter sido mais eficiente em manter o retardo em níveis baixos, provavelmente devido à prioridade dada ao tráfego de videoconferência. Os dois mecanismos de QoS foram capazes de evitar perdas de pacotes e de manter constante a vazão das mídias de áudio e vídeo mesmo na presença de congestionamento. É curioso observar que o mecanismo de QoS utilizado no teste (235) foi capaz de reduzir os níveis do jitter para a mídia de áudio em razão de concorrência, talvez devido à divisão mais eqüitativa da banda de rede que esta realiza, enquanto que em (135) os níveis do jitter foram mantidos.

^

5.3 Interpretação dos resultados

Embora simples, o experimento realizado permitiu examinar o comportamento da videoconferência pessoal em situações importantes. Em primeiro lugar confirmou a intuição de que o mais importante para o sucesso da transmissão é providenciar banda nominal suficiente no canal para acomodar a taxa de transmissão utilizada. Quando foi gerado tráfego a taxas superiores à banda nominal, os parâmetros de QoS (perdas, retardo e jitter) registraram a deterioração da qualidade. Na prática, então, a taxa de transmissão da videoconferência deveria ser configurada para se manter dentro da banda efetivamente disponível. Felizmente, há muitas opções de compressão das mídias de áudio e vídeo, que permitem esta acomodação.

A segunda parte do estudo tratava da viabilidade da videoconferência na presença de tráfego cruzado intenso. Numa inter-rede TCP, esta situação seria normal, pois a tendência destas redes é de consumo da banda disponível pelo conjunto de aplicações, devido às características conhecidas do TCP. Este protocolo de transporte, usado pela maioria das aplicações "convencionais" (especialmente FTP e WWW), tenta manter a taxa de transmissão ligeiramente abaixo do nível que provocaria congestionamento [JAC 88]. Estas aplicações são menos sensíveis a retardo e jitter que as aplicações de mídia contínua. A coexistência destas aplicações com aplicações de mídia contínua poderia levar ao comprometimento dos objetivos destas últimas, se os parâmetros de QoS fossem determinados pelas primeiras.

Nos experimentos, levamos esta situação ao limite de esgotamento dos recursos de transmissão pela geração de um tráfego cruzado muito superior à capacidade do enlace compartilhado, através de fontes de tráfego UDP. Foi confirmada a expectativa intuitiva de que, sem a proteção especial do tráfego cruzado, a videoconferência seria inviável. Porém, quando esta proteção foi dada pela separação de tráfego implementada pelo modelo DiffServ, então foi possível preservar quase incólume a viabilidade da videoconferência, com pequenas conseqüências para o jitter e retardo, mas sem ocasionar perda de pacotes.

^

6. Conclusões

Foi demonstrado que, com o uso do modelo DiffServ, os requisitos da aplicações de mídia contínua são atendidos, pois ele permite a coexistência na mesma inter-rede IP de tráfego de tempo real e tráfego de melhor esforço, mesmo em condições de congestionamento extremo. Isto contribui para a integração de serviços numa única rede. No caso específico da PETROBRAS, o suporte para o transporte de videoconferência pessoal antes era feito pelo aluguel de um canal internacional dedicado, distinto daquele usado para o transporte de outras aplicações de rede, o que resulta num custeio maior do que o uso de um canal compartilhado. Neste caso, a separação do tráfego por software (uso de DiffServ) sai mais barato do que por hardware (canais de telecomunicações separados). Futuros trabalhos darão atenção ao gerenciamento de QoS, para possibilitar o uso em larga escala da integração de serviços em inter-redes IP.

O trabalho experimental foi realizado em laboratório da Petróleo Brasileiro S/A, e fez parte do desenvolvimento da dissertação de mestrado do primeiro autor no IC/UFF [FON 01]. Os roteadores utilizados foram cedidos gentilmente pela Cisco Systems, Inc., que também prestou assessoria técnica para a configuração dos equipamentos.

^

Referências bibliográficas

[BLA 98] BLAKE, S. et al. RFC 2475: An Architecture for Differentiated Services, IETF, December 1998. Documento disponível em http://www2.ietf.org/rfc/rfc2475.txt .

[CIS 00] Cisco Systems Inc., Class-Based Weighted Fair Queueing, 2000. Documento disponível em http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/cbwfq.pdf .

[CIS 99] Cisco Systems Inc., Low Latency Queueing, 1999. Documento disponível em http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t7/pqcbwfq.pdf .

[DEM 90] DEMERS A., et al., Analysis and Simulation of a Fair Queueing Algorithm, Internetworking: Research and Experience, Vol. 1, No. 1, pp. 3-26, 1990.

[DEO 00] DEOGIOANNI, L. et al., WinDump: TCPdump for Windows, Politecnico di Torino, Italia, March, 2000. Documento disponível em http://netgroup-serv.polito.it/windump/ .

[FON 01] FONSECA, J.L.A., Arquitetura de Redes para Aplicações Multimídia de Tempo Real, Dissertação de Mestrado, Instituto de Computação, Universidade Federal Fluminense, Niterói, RJ, 2001.

[ITU 88] International Telecommunication Union, ITU-T Recommendation G.711: Pulse Code Modulation of Voice Frequencies, Geneva, 1988.
Documento disponível em http://www.itu.int/itudocs/itu-t/rec/g/g700-799/g711.pdf .

[ITU 96] International Telecommunication Union, ITU-T Recommendation G.723.1: Dual Rate Speech Coder for Multimedia Communications Transmitting at 5.3 and 6.3 kbps, Geneva, 1996.
Documento disponível em http://www.itu.int/itudocs/itu-t/rec/g/g700-799/g723-1.pdf .

[ITU 99] International Telecommunication Union, ITU-T Recommendation H.323: Packet-based Multimedia Communications Systems, Sep 1999.
Documento disponível em http://www.itu.int/itudocs/itu-t/rec/h/h323.pdf .

[JAC 88] JACOBSON, V., Congestion Avoidance and Control, Computer Communication Review, Vol. 18, nº 4, pp. 314-329, August 1988. Documento disponível em ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z .

[JON 94] JONKMAN, R., NetSpec: Philosophy, Design and Implementation, University of Kansas, Holanda, 1994. Documento disponível em http://www.ittc.ukans.edu/netspec/docs/roel.ps .

[MIC 99] Microsoft Corporation, Microsoft NetMeeting 3 Resource Kit, December 1999.
Documento disponível em http://www.microsoft.com/windows/NetMeeting/Corp/reskit/About/default.asp .

[RIJ 96] RIJKSE, K., H.263: Video Coding for Low-Bit-Rate Communication, IEEE Communications Magazine, December 1996. .

[SCH 96] SCHULZRINNE, H. et al., RFC 1889: RTP - A Transport Protocol for Real-Time Applications, IETF, 1996, 75pp. Documento disponível em http://www.ietf.org/rfc/rfc1889.txt .

[TCPD] TCPDUMP/LIBPCAP homepage, http://www.tcpdump.org .

^

NewsGeneration, um serviço oferecido pela RNP – Rede Nacional de Ensino e Pesquisa
Copyright © RNP, 1997 – 2004