!
!
"!
% #$" ! & ! " '
&( ) "
!" !
!
'
!
Universidade Federal de Pernambuco
[email protected]
www.cin.ufpe.br/~posgraduacao
RECIFE, ABRIL/2004
#$"
'
! *
UNIVERSIDADE FEDERAL DE PERNAMBUCO
CENTRO DE INFORMÁTICA
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
FÁBIO PEREIRA BOTELHO
“INFRA-ESTRUTURA DE TRANSCODIFICAÇÃO PARA
DISTRIBUIÇÃO DE ÁUDIO EM UMA INTRANET ADAPTÁVEL AO
ESTADO DA REDE”
ESTE TRABALHO FOI APRESENTADO À PÓS-GRADUAÇÃO EM
CIÊNCIA DA COMPUTAÇÃO DO CENTRO DE INFORMÁTICA DA
UNIVERSIDADE FEDERAL DE PERNAMBUCO COMO REQUISITO
PARCIAL PARA OBTENÇÃO DO GRAU DE MESTRE EM CIÊNCIA DA
COMPUTAÇÃO.
ORIENTADOR: DR. DJAMEL FAWZI HADJ SADOK
RECIFE, ABRIL/2004
ii
Botelho, Fábio Pereira
de
transcodificação
para
Infra-estrutura
distribuição de áudio em uma Intranet adaptável ao
estado da rede / Fábio Pereira Botelho. – Recife : O
Autor, 2004.
xv, 122 folhas : il., fig., gráf., quadros.
Dissertação (mestrado) – Universidade Federal
de Pernambuco. CIn. Ciência da Computação, 2004.
Inclui bibliografia , apêndices e anexo.
1. Redes de computadores – Sistemas
distribuídos.
2.
Convergência
digital
–
Transcodificação. 3. RTP (Real Time Transport
Protocol) – Aplicação para distribuição de áudio. 4.
Intranet – Adaptabilidade ao estado da rede. I. Título.
004.75
004.68
CDU (2.ed.)
CDD (20.ed.)
UFPE
BC2004-470
A meu filho Emanuel e
a minha esposa Iraci Botelho
iii
Agradecimentos
Gostaria de agradecer a Deus e a Nossa Senhora Aparecida pela condução nesta importante fase
de minha vida; a minha esposa Iraci Botelho pela paciência, carinho e amizade; a meu filho
Emanuel Botelho pela sua presença em minha vida e na vida de Iraci, no oitavo mês gestacional;
a minha cunhada Iolanda Fontenele pelos conselhos e orações sempre oportunas; a minha mãe
pelo apoio e amizade incondicionais; a meu pai por ter lançado o barco à água não sem os
cuidados de minha mãe; a meus caros amigos e irmãos; enfim, a todas as pessoas que
dispensaram atenção no auxílio a escrita dessa dissertação, em especial aos Professores Dr.
Djamel Sadok e Dra. Judith Kelner pelos direcionamentos pontuais e precisos.
iv
Sumário
Abreviações e Acrônimos
Resumo
Abstract
xi
xiv
xv
1. Introdução
01
1.1. Motivação ............................................................................................................
1.2. Problemática ........................................................................................................
1.3. Organização da Dissertação ................................................................................
2. Projetos Relacionados
2.1. Transcodificação Baseada em Proxy ..................................................................
2.2. Projeto KISS .........................................................................................................
2.3. Projeto ICEBERG ...............................................................................................
2.4. Projeto COMCAR ...............................................................................................
3. Real-Time Transport Protocol (RTP)
3.1. Apresentação .......................................................................................................
3.2. Objetivos do RTP ................................................................................................
3.3. Transporte de Dados Multimídia e de Controle ..................................................
3.4. Funções RTP .......................................................................................................
3.5. Misturador e Tradutor RTP .................................................................................
3.6. Pacote RTP ..........................................................................................................
3.7. Protocolo RTCP ..................................................................................................
3.8. Representação Digital dos Dados de Áudio ........................................................
3.8.1. Codificação de Áudio ....................................................................................
3.8.2. Intervalo de criação dos Pacotes ...................................................................
3.9. Formatos de Codificação de Áudio RTP Disponíveis na API JMF 2.1.1e .........
3.9.1. DVI ................................................................................................................
3.9.2. Compressão de Áudio -LAW ......................................................................
3.9.3. G.723 .............................................................................................................
3.9.4. GSM ..............................................................................................................
3.9.5. MPEG-1 / MPEG-2 ......................................................................................
4. IP Multicast
4.1. Apresentação .......................................................................................................
4.2. Outros Tipos de Transmissão comparados à Multicast ......................................
4.3. Multicast em Diferentes Camadas ......................................................................
4.4. Filtro Multicast nos Switchs .........................................................................
4.5. O Processo Multicast ....................................................................................
4.6. Conceitos de Roteamento Multicast .............................................................
01
02
03
05
05
08
10
12
17
17
19
19
20
20
21
24
30
31
32
32
33
35
35
36
36
41
41
41
43
43
45
46
v
5. Infra-Estrutura de Transcodificação e Aplicação para Distribuição de Áudio
5.1. Transcodificador .................................................................................................
5.2. Serviços da Infra-Estrutura de Transcodificação ................................................
5.3. Arquitetura e Implementação ..............................................................................
5.3.1. Classes Identificadas .....................................................................................
5.3.2. Papéis Exercidos pelo Cliente .......................................................................
5.3.3. Casos de Uso Identificados e Situação de Implementação ...........................
6. Protocolo para Controle de Sessão no Transcodificador e Troca de Sessão
nos Receptores
6.1. Entendendo o Problema ......................................................................................
6.2. Associação da Sessão Multicast mais Adequada dada a Informação da
Capacidade do Enlace ..........................................................................................
6.3. Eleição do Responsável pelo Controle de Troca de Sessão para uma dada
Sub-rede ...............................................................................................................
6.4. Troca de Sessão em caso de Congestionamento .................................................
6.5. Troca de Sessão na Ausência de Congestionamento .........................................
6.6. Algoritmo de Adaptabilidade do Receptor Gerente ............................................
7. Análise dos Formatos de Áudio RTP para a Infra-estrutura de
Transcodificação
7.1. Cenário Utilizado ................................................................................................
7.2. Análise dos Formatos de Áudio RTP para as Sessões Multicast da Infraestrutura de Transcodificação Proposta ...............................................................
7.3. Análise dos Formatos de Áudio RTP Candidatos às Sessões Disponibilizadas
pelo Transcodificador ..........................................................................................
49
49
52
54
56
59
60
70
70
72
72
74
75
76
78
78
80
86
8. Conclusão e Trabalhos Futuros
91
Referências
93
Apêndice A. Jitter em Redes de Pacotes de Voz
97
A.1. Definição ............................................................................................................
A.2. O que pode causar o Jitter ? ...............................................................................
Apêndice B. Qualidade de Serviço (QoS)
B.1. Mecanismos usados para se implementar Qualidade de Serviço (QoS) ............
B.2. Type of Service (ToS) ........................................................................................
B.3. Serviços Diferenciados .......................................................................................
B.4. IEEE 802.1P .......................................................................................................
B.5. Infra-Estrutura de Rede Necessária a Distribuição de Áudio com QoS .............
97
99
100
100
101
101
104
108
vi
Anexo A. Java Media Framework (JMF)
An.1. Modelo de tempo ..............................................................................................
An.2. Objetos Manager ..............................................................................................
An.3. Modelo de Evento ............................................................................................
An.4. Modelo de Dados .............................................................................................
An.4.1. PushDataSources e PullDataSources .........................................................
An.5. Objetos DataSource Especiais ..........................................................................
An.6. Formatos de Dados ...........................................................................................
An.7. Controls ............................................................................................................
An.8. Componentes da Interface com o Usuário .......................................................
An.9. Apresentação de Áudio e Vídeo .......................................................................
An.10. Player .............................................................................................................
An.11. Estados do Player ...........................................................................................
An.12. Processor ........................................................................................................
An.13. ControllerEvent ..............................................................................................
An.14. Processamento ................................................................................................
110
111
111
112
112
113
114
114
115
117
117
118
118
119
119
121
vii
Lista de Figuras
Figura 2.1. Arquitetura Básica do Transcodificador Baseado em Proxy ..................................
Figura 2.2. Visão Simplificada dos Componentes da Infra-Estrutura de Rede do Projeto
KISS ..........................................................................................................................................
Figura 2.3. Um Cenário Ilustrativo do APC no Projeto ICEBERG .........................................
Figura 2.4. Área de Interesse do Projeto COMCAR ................................................................
Figura 2.5. Arquitetura do Sistema COMCAR ........................................................................
Figura 2.6. Infra-estrutura de Transcodificação Implementada como parte do
Projeto COMCAR ....................................................................................................................
Figura 3.1. Posicionamento e Interações dos Protocolos RTP/RTCP e RTSP no Modelo
TCP/IP ......................................................................................................................................
Figura 3.2. Atuação de um Misturador nos Streams Multimídia de Entrada ...........................
Figura 3.3. Atuação de um Tradutor nos Streams Multimídia de Entrada ...............................
Figura 3.4. Pacote RTP .............................................................................................................
Figura 3.5. Extensão do Cabeçalho do Pacote RTP ..................................................................
Figura 3.6. Pacote RTCP SR .....................................................................................................
Figura 3.7. Pacote RTCP RR ....................................................................................................
Figura 3.8. Processamento de Áudio Digital ............................................................................
Figura 3.9. Compressão e Descompressão ADPCM ................................................................
Figura 3.10. Compressão e Descompressão de Áudio MPEG ..................................................
Figura 3.11. Limites de Bandas Críticas X Filtros de Banda para Áudio MPEG .....................
Figura 4.1. Comparação entre Multicast e Unicast ...................................................................
Figura 4.2. Filtro Multicast nos Switchs ...................................................................................
Figura 4.3. Processo Multicast ..................................................................................................
Figura 4.4. Efeito da Aplicação do Spanning Tree a uma Rede IP ..........................................
Figura 5.1. Infra-Estrutura de Transcodificação Utilizada nesta Dissertação ...........................
Figura 5.2. Arquitetura de Infra-Estrutura de Serviços de Rede para Transcodificação de
Streams Multimídia ...................................................................................................................
Figura 5.3. Diagrama de Classes da Infra-Estrutura de Transcodificação para Distribuição
de Áudio ....................................................................................................................................
Figura 5.4. Múltiplas Funcionalidades Assumidas pelo Cliente em Uma Dada Sub-Rede ......
Figura 5.5. Diagrama de Seqüência do Caso de Uso Transmitir Áudio ao Transcodificador ..
Figura 5.6. Inicialização do Serviço Transmissor .....................................................................
Figura 5.7. Diagrama de Seqüência do Caso de Uso Iniciar as Três Sessões Multicast de
Áudio RTP ................................................................................................................................
Figura 5.8. Inicialização do Serviço Transcodificador e Criação das Três Sessões de Áudio
RTP Após Recepção do Stream de Áudio Oriundo do Transmissor ........................................
Figura 5.9. Diagrama de Seqüência do Caso de Uso Receber Stream de Áudio no Receptor
....................................................................................................................................................
Figura 5.10. Recepção e Apresentação do Stream de Áudio RTP de Uma das Sessões de
Áudio Multicast Iniciadas pelo Transcodificador .....................................................................
Figura 6.1. Cenário Ilustrativo da Adaptabilidade dos Receptores e Controle do
Transcodificador .......................................................................................................................
Figura 6.2. Cenário Ilustrativo do Problema da Adaptabilidade dos Receptores e Controle
do Transcodificador em Situação de Congestionamento ..........................................................
06
09
11
13
15
15
18
20
21
21
23
25
28
30
34
38
39
42
44
46
47
50
53
55
60
62
63
64
65
67
68
71
71
viii
Figura 6.3. Receptores Gerente e Agente para Troca de Sessão em Uma Dada Sub-Rede ......
Figura 6.4. Troca de Sessão em Caso de Congestionamento ...................................................
Figura 6.5. Diagrama de Seqüência para Troca de Sessão pelo Receptor Gerente em
Situação de Congestionamento .................................................................................................
Figura 6.6. Algoritmo de Adaptabilidade do Receptor – Gerente ............................................
Figura 7.1. Cenário Utilizado na Análise ..................................................................................
Figura 7.2. Vazões Observadas para as Sessões Multicast Mantidas pelo Transcodificador ...
Figura 7.3. Jitter Observado para as Sessões Multicast Mantidas pelo Transcodificador ........
Figura 7.4. Quantidade de Bytes Recebidos das Sessões Multicast Mantidas pelo
Transcodificador .......................................................................................................................
Figura 7.5. Pacotes RTP Recebidos das Sessões Multicast Mantidas pelo Transcodificador ..
Figura 7.6. Pacotes RTCP Recebidos das Sessões Multicast Mantidas pelo Transcodificador
Figura 7.7. Vazões Observadas para os Formatos de Áudio RTP Candidatos .........................
Figura 7.8. Maiores Valores de Jitter Observados para os Formatos de Áudio RTP
Candidatos .................................................................................................................................
Figura 7.9. Menores Valores de Jitter Observados para os Formatos de Áudio RTP
Candidatos .................................................................................................................................
Figura 7.10. Quantidade de Bytes Recebidos para os Formatos de Áudio RTP Candidatos ...
Figura A.1. Efeito do Jitter em um Stream de Pacotes de Voz ................................................
Figura A.2. Buffer para Compensação do Jitter .......................................................................
Figura A.3. Pacote Perdido Devido a Jitter Excessivo .............................................................
Figura B.1. Formato do Byte TOS no Cabeçalho Ipv4 .............................................................
Figura B.2. Visão Lógica do Classificador de Pacotes e Condicionador de Tráfego ...............
Figura B.3. Formato do Byte Diffserv ......................................................................................
Figura B.4. Cabeçalho da Camada 2 Ethernet sem a Informação 802.1 P/Q ...........................
Figura B.5. Cabeçalho da Camada 2 Ethernet 802.1 com a Informação 802.1 P/Q..................
Figura B.6. Configuração de uma Placa Ethernet com Suporte a 802.1P Vista no S.O
Windows 2000 ..........................................................................................................................
Figura B.7. Software de Configuração da Marcação de Pacotes 802.1P Disponibilizado pelo
Sistema Operacional Windows 2000/XP ..................................................................................
Figura B.8. Infra-Estrutura de Rede Necessária a Distribuição de Áudio com QoS ................
Figura An.1. JMF é Baseado no Modelo de Captura e Apresentação de Vídeo Tradicionais ..
Figura An.2. API JMF ..............................................................................................................
Figura An.3. Modelo de Tempo JMF .......................................................................................
Figura An.4. Modelo de Eventos ..............................................................................................
Figura An.5. Modelo de Dados .................................................................................................
Figura An.6. Formato de Mídias JMF ......................................................................................
Figura An.7. JMF Controls ......................................................................................................
Figura An.8. Objetos JMF Controller ......................................................................................
Figura An.9. Modelo JMF Player ............................................................................................
Figura An.10. Estados do Player ..............................................................................................
Figura An.11. Modelo JMF Processor .....................................................................................
Figura An.12. Eventos JMF ......................................................................................................
Figura An.13. JMF Processors .................................................................................................
Figura An.14. Estágios do Processor .......................................................................................
73
74
75
76
79
81
83
84
85
85
87
88
89
90
97
98
98
101
102
102
104
105
107
108
109
110
111
111
112
113
114
116
117
118
118
119
120
121
121
ix
Lista de Tabelas
Tabela 3.1. Codificadores de Áudio RTP Disponíveis na API JMF 2.1.1e .............................
Tabela 3.2. Diferentes Tamanhos de Quadros Especificados no Algoritmo G.723 .................
Tabela 3.3. Limite Aproximado de Bandas Críticas ................................................................
Tabela 5.1. Diferentes Configurações de Alguns Dispositivos Computacionais .....................
Tabela 5.2. Algoritmos de Compressão de Áudio ....................................................................
Tabela 5.3. Algoritmos de Compressão de Vídeo ....................................................................
Tabela 6.1. Formatos de Áudio RTP Disponíveis na API JMF2.1.1e ......................................
Tabela 6.2. Formatos de Codificação mais Adequados as Capacidades de Enlace .................
Tabela 6.3. Quadro de Mensagens Oriundas do Gerente para os Agentes em uma Sub-rede
Tabela 7.1. Quadro de Mensagens Oriundas do Gerente para os Agentes em uma Sub-Rede
qualquer ....................................................................................................................................
Tabela 7.2. Formatos de Codificação mais Adequados dada a Capacidade do Enlace ............
33
36
37
50
51
51
69
72
73
80
87
x
Abreviações e Acrônimos
ADPCM
A-LAW
APC
API
CBT
CCITT
CIF
CNAME
COMCAR
CRC
CSRC
DiffServ
DLSR
DM
DAB
DVB-T
DVI
DVMRP
Ethernet
FDDI
FTP
G.711
G.721
G.723
GPRS
GSM
GSTN
H.324
HTML
HTTP
ICEBERG
IEEE
IETF
IGMP
IMA
Internet2
IP
IPv4
IPv6
ISDN
ISO/IEC
Adaptative Delta Pulse Code Modulation
Padrão ITU-T para conversão de áudio analógico para digital usando
codificação PCM usado na Europa
Automatic Path Creation
Application Program Interface
Core Based Trees
Comité Consultatif Internationale de Télégraphique et Téléphonique
Common Intermediate Format (Video)
Canonical Name
Communication and Mobility by Cellular Advanced Radio
Cyclic Redundancy Code
Contributing Source
Differentiated Services
Delay Since Last SR
Dense Mode
Digital Audio Broadcast
Digital Video Broadcast
Digital Video Interactive
Distance Vector Multicast Routing Protocol
Um tipo de rede para interconexão de dispositivos computacionais (IEEE
802.3)
Fibre-Distributed Data Interface
File Transfer Protocol
Recomendação do CCITT para freqüência de voz PCM
Recomendação do CCITT para compressão de áudio
Definição do ITU-T H.324 GSTN para terminais de vídeo-fone
General Packet Radio Service
Group Special Mobile
Global Switched Telephone Network
Um grupo de padrões aprovados pelo ITU que define video conferência sobre
a rede telefônica
Hipertext mark-up language
Hipertext Transport Protocol
An Internet-core Network Architecture for Integrated Communications
Institute for Eletrical and Eletronics Engineers
Internet Engeneering Task Force
Internet Group Management Protocol
Interactive Multimedia Association
Projeto para rede norte americana de alta velocidade
Internet Protocol
Internet Protocol Version 4
Internet Protocol Version 6
Integrated Services Digital Network
Internacional Organization for Standardization/International
xi
ITU-T
JMF
KISS
LAN
LSR
MAC
MDCT
MIB
MMUSIC
MOSPF
MPEG
MPE-LPC
NAP
NCM
NTP
OSI
PCM
PDA
PIM-DM
PIM-SM
PT
QCIF
RAM
RC
RFC
RMI
RNP2
RPC
RPE/LTP
RR
RTCP
RTP
RTSP
SA
SDES
SID
SM
SNMP
SR
SSRC
TCP
Electrotechnical Commission
International Telecommunication Union
Java Media Framework
Communication Infrastructure for Streaming Services in a Heterogeneous
Environment
Local Area Network
Last SR (timestamp)
Media Accesss Control (IEEE 802)
Modified Discrete Cosine Transform
Management Information Base
Multiparty Multimedia Session Control
Multicast Open Shortest Path First
Motion Picture Experts Group
Multipulse-Excitation Linear Predictive Coding
Network Access Points
Network Connector Monitor
Network Time Protocol
Open System Interconnection
Pulse Code Modulation
Personal Digital Assistant
Protocol Independent Multicast-Dense Mode
Protocol Independent Multicast-Sparse Mode
Payload Type
Quarter Common Intermediate Format, um formato para videoconferência
apresentando ¼ da resolução do CIF
Random Access Memory
Reception Report Count
Request for Comments
Remote Method Invocation
Projeto brasileiro para redes de alta velocidade de iniciativa da Rede
Nacional de Pacotes
Remote Procedure Call
Regular Pulse Excitation / Long Term Prediction
Receiver Report
Real-Time Transport Control Protocol
Real-Time Transport Protocol
Real-Time Streaming Protocol
Service Applications
Source description itens
Silence Insertion Descriptor
Sparse Mode
Simple Network Management Protocol
Sender Report
Synchronization Source
Transmission Control Protocol
xii
Token Ring
UDP
UML
UTC
VLAN
WAN
-LAW
Um tipo de rede em que os computadores são arranjados esquematicamente
em um círculo
User Datram Protocol
Unified Modeling Language
Coordinated Universal Time
Virtual Local Area Network
Wide Area Network
Padrão ITU-T para conversão de áudio analógico para digital usando
codificação PCM usado na América do Norte
xiii
Resumo
Com o advento das Redes de Computadores e a sua popularização, principalmente nas
décadas de 80 e 90, a tradicional, segura e robusta arquitetura centralizada personificada
nos mainframes, deu lugar rapidamente a uma arquitetura descentralizada que além “correr
atrás do prejuízo” quando se analisa os benefícios já consolidados da arquitetura
centralizada, ainda se volta a partir da década de 90 para a disponibilização de serviços
ditos de nova geração, caracterizados por tratar além da mídia textual, ainda áudio e vídeo.
Comparativamente ao ambiente complexo, amplo e heterogêneo observado na
Internet, o ambiente de uma Intranet é “bem comportado” para se disponibilizar os serviços
de nova geração uma vez que o universo de equipamentos e tecnologias envolvidos, para se
garantir os requisitos necessários aos novos serviços, é previsível.
A presente dissertação possui como principal contribuição o desenvolvimento de uma
infra-estrutura de transcodificação e a implementação de uma aplicação para distribuição de
áudio em uma rede corporativa (Intranet) adaptável ao estado da rede que se utiliza da
infra-estrura elaborada. Embora focada na distribuição apenas da mídia de áudio, a infraestrutura proposta pode evoluir para permitir a criação de aplicações de distribuição de
áudio e vídeo e ainda áudio e vídeo conferências. Usa-se o protocolo de
Aplicação/Transporte RTP - Real Time Transport Protocol, disponível em vários formatos
de áudio existentes na API JMF - Java Media Framework, além de se abordar as
necessidades a nível de rede, tais como Multicast e mecanismos de priorização de quadros e
pacotes nas camadas 2 e 3 do modelo de referência OSI (i.e. IEEE 802.1P e DiffServ).
São identificados quatro Casos de Uso básicos na infra-estrutura proposta: Transmitir
ao Transcodificador; Iniciar Sessões de Áudio no Transcodificador; Receber Stream de
Áudio RTP no Receptor; e, Trocar a Sessão Multicast de Recepção. Os três primeiros são
especificados, implementados e validados; o quarto, é apenas especificado, sendo a sua
implementação e validação em cenário com filas diferenciadas de priorização de pacotes na
camada de rede, um trabalho futuro.
O trabalho explora o conceito de transcodificação como ideal para lidar com a
heterogeneidade de recursos de rede existentes em uma Intranet.
Palavras-chave: RTP, Distribuição de Áudio, Adaptabilidade, Intranet, Multicast, JMF
xiv
Abstract
With the advent of Computer Networks and their popularization, principally in 80 and 90’s
decades, the traditional, secure and reliable centralized architecture, represented by
mainframes, was rapidily substituted by a descentralized architecture characterized by tring
to resolve old problems already resolved by the old architeture and facing new problems,
demanded after 90’s decade, to offer Next Generation services, i.e. services which treat
audio, video and text medias.
Comparatively to the wide, complex and heterogeneous Internet environment, an
Intranet is a better place to offer Next Generation Services because of the previsible
variables like equipments and technologies involved to guarantee necessary requirements of
newer services.
The principal contribution of this thesis is the project and implementation of a
transcoding infrastructure and an aplication prototype to distribute audio in an Intranet with
adaptability to network computer’s state. Only audio media is treated but in future works,
other medias can be treated, like video, to develop not only media distribution but
audio/video conferences applications too. The application and Transport RTP - Real Time
Transport Protocol, implemented in various audio formats in JMF - Java Media Framework
is used to improve adaptable mechanism. Network necessities, like Multicast and
priorization queues in layers 2 and 3 of OSI reference model (e.g, IEEE 802.1P and
DiffServ), are explained.
Four basics Use Cases are identifieds: Transmit to the Transcodifier; Start up of audio
sessions in the Transcodifier; Receive Audio Streams in the Receptor; and Change
Reception Multicast Session. First three of then are specified, implemented and validated.
The other, is only specified and its implementation and validation in scenery with various
queues of packet priority in the net layer are a future work.
This Master thesis exploits the concept of transcodification to treat in a good way the
problem of heterogeneous network resources in an Intranet.
Keywords: RTP, Audio Distribution, Adaptability, Intranet, Multicast, JMF
xv
1
Introdução
Neste capítulo é apresentada a motivação para o uso de infra-estruturas de transcodificação em
rede, a problemática envolvida e a organização dos capítulos, apêndices e anexo.
1.1. Motivação
Com o advento das Redes de Computadores e a sua popularização, principalmente nas décadas de
80 e 90, a tradicional, segura e robusta arquitetura centralizada representada pelos mainframes,
deu lugar rapidamente a uma arquitetura descentralizada, interligada por uma infra-estrutura de
comunicação e representada pelas redes de computadores, caracterizada por uma série de
questões em aberto a serem resolvidas para que se pudesse usufruir os ganhos financeiros
decorrentes dessa mudança, sem abrir mão da simplicidade, segurança e robustez da antiga
arquitetura.
Além da premente necessidade de “correr atrás do prejuízo” quando são analisados os
benefícios já consolidados da arquitetura centralizada, surge fortemente a partir da década de 90 a
preocupação em se tratar mídias que até então não tinham sido objeto de atenção dos serviços
disponibilizados nas redes de computadores. Estas, tradicionalmente voltadas a tratar a mídia
textual, tendo como principal protocolo o TCP (parte integrante da pilha de protocolos TCP/IP
que se tornou o padrão de fato nas redes), deparam-se agora com a crescente demanda para tratar
também as mídias de voz e vídeo – mudança esta que é estruturalmente influenciada pelo
crescimento exponencial dos recursos de largura de banda e confiabilidade dos meios de
transmissão disponíveis.
Movido por esta preocupação, surgiu a iniciativa do governo americano para a criação de
um projeto denominado Internet2 em 1997, que além de disponibilizar alta largura de banda,
ainda incentiva o estudo de mecanismos, protocolos e aplicações que até então não estavam
disponíveis na Internet convencional: reserva de recursos; filas variadas de priorização de pacotes
nas camadas 2 e 3 do modelo de referência OSI que possibilitariam a oferta de diferenciação de
serviços; aplicações e protocolos para tratar as mídias textual, voz e vídeo de forma eficiente,
disponibilizando serviços tais como conferências de áudio e vídeo, áudio e vídeo sob demanda. A
1. Introdução
2
criação desta nova geração de redes refletiu em vários países do mundo com o surgimento de
backbones de alta velocidade que se interligariam formando uma rede internacional de alta
velocidade voltada a atender prioritariamente a comunidade científica, representada no Brasil
pelo projeto RNP2.
A última milha sempre será um problema para que os serviços ditos de nova geração se
tornem corriqueiros e usuais. O ambiente de uma Intranet é “bem mais comportado” para se usar
os serviços de nova geração uma vez que se diminui o universo de equipamentos e tecnologias
envolvidas para se garantir os requisitos necessários.
A transcodificação é o processo pelo qual um stream multimídia de origem é convertido em
um ou vários streams de destino, alterando sua qualidade e propriedades, tais como vazão e jitter.
Este processo é útil para atender à heterogeneidade de recursos tanto da rede onde o stream irá
trafegar quanto de dispositivos receptores que irão recuperar e reproduzir o stream.
Esta dissertação desenvolve uma infra-estrutura de transcodificação para atender ao
problema da heterogeneidade dos recursos de rede existentes em uma Intranet com várias subredes, cada uma com capacidade de enlace diferente. Para tanto, é concebido uma infra-estrutura
de transcodificação e um protótipo de aplicação para distribuição de áudio que se utiliza da infraestrutura concebida.
Na infra-estrutura de transcodificação proposta é especificado um mecanismo de adaptação
ao estado da rede, retirando da aplicação e do usuário esta responsabilidade. Este mecanismo de
adaptação, usa o protocolo RTP - Real Time Transport Protocol implementado em diversos
formatos de áudio e vídeo disponíveis na API JMF - Java Media Framework. A distribuição de
áudio, implementada e validada, subentende que a rede implemente multicast tanto em roteadores
quanto em switchs.
1.2. Problemática
A distribuição de áudio e vídeo em uma Intranet, além de aplicações de áudio e vídeo
conferências, podem envolver diversos participantes em várias sub-redes membros. O uso de
multicast, conforme visto no capítulo 4 se torna imprescindível para a otimização do uso dos
recursos de rede quando há um grande número de receptores.
Esta dissertação propõe uma infra-estrutura de transcodificação que usa multicast para
atender apenas à distribuição de áudio em uma Intranet, definindo no entanto um modelo
1. Introdução
3
genérico para atender também às aplicações de distribuição de áudio/vídeo e áudio e vídeoconferências, conforme visto no capítulo 5.
O diferencial do presente trabalho é o controle por parte do transcodificador acerca de qual
formato de codificação de áudio é mais adequado às sub-redes por ele atendidas, não se levando
em conta as características computacionais dos dispositivos clientes mas sim o impacto da
transmissão na rede.
A transcodificação, conforme visto no capítulo 5, se utiliza do fato de que os formatos de
codificação de áudio, possuem qualidades e requisitos de largura de banda diferentes. A infraestrutura proposta especifica como seria a implementação da auto-adaptação coletiva dos
receptores, ao definir qual codificação utilizar para a transmissão de áudio a todos os receptores
em cada sub-rede diante de uma situação de congestionamento.
A troca de sessão de recepção de áudio de todos os participantes de uma dada sub-rede
enfrentando problemas de congestionamento, pode complicar ainda mais a situação de
congestionamento que disparou o mecanismo de adaptação dos receptores caso não haja um
protocolo que realiza esta troca de forma eficiente. No capítulo 6 este protocolo é definido.
1.3 Organização da Dissertação
O capítulo 2 apresenta os trabalhos que tal qual esta dissertação apresentam infra-estrutura de
transcodificação em rede, realizando breve comparativo com a apresentada.
O capítulo 3 aborda o protocolo de aplicação / transporte RTP explicitando o mecanismo de
envio de relatórios usado para manter informado tanto o transmissor quanto o receptor a respeito
da qualidade dos dados multimídia (dentre outras informações) que é capaz de transportar com o
auxílio do Protocolo de Transporte UDP da pilha TCP/IP. Cada um dos formatos de áudio RTP
disponíveis na API JMF 2.1.1e, usados para implementar o mecanismo de transcodificação dessa
dissertação, é introduzido brevemente.
O conceito de multicast é abordado no capítulo 4. O mecanismo de distribuição de áudio
dessa dissertação subentende a disponibilidade de multicast ao menos nos roteadores e
idealmente também nos switchs em uma Intranet.
O capítulo 5 apresenta a infra-estrutura de transcodificação usada, contribuição desta
dissertação, explicitando as responsabilidades básicas de transmissão, transcodificação e recepção
implementadas. Descreve-se o diagrama de classes e suas responsabilidades, além do protótipo
1. Introdução
4
de implementação. Usa-se Java e a API JMF 2.1.1e para a implementação da transmissão,
transcodificação e recepção de áudio RTP. O mecanismo de adaptabilidade é apenas
especificado.
O capítulo 6 apresenta o mecanismo de adaptação ao estado da rede usado na dissertação
através da definição de um protocolo para o controle de sessão no transcodificador e troca de
sessão nos receptores. Ressalte-se que não foi encontrado na literatura mecanismo similar uma
vez que o transcodificador guarda informações a respeito do formato de áudio RTP mais
adequado a cada sub-rede onde se encontram os receptores que solicitam sincronizadamente a
todos os pares de suas sub-redes a sessão multicast mais adequada à sub-rede em dado instante.
Os formatos de áudio RTP, disponíveis na API JMF 2.1.1e, são analisados no capítulo 7 no
ambiente de uma rede corporativa com suporte a multicast nas camadas 2 e 3, sem tráfego de
background, usando-se a implementação realizada. São coletadas principalmente as estatísticas a
respeito da vazão, jitter e perda de pacotes. Em um primeiro momento, são analisados os
formatos de áudio RTP disponibilizados em cada uma das 3 sessões multicast do mecanismo de
transcodificação e adaptação ao estado da rede projetados. Os demais formatos são analisados em
seguida no mesmo capítulo.
Finaliza-se no capítulo 8 com a conclusão e sugestão de trabalhos futuros.
Segue o Apêndice A, explicando o processo de formação do jitter; o Apêndice B,
descrevendo qualidade de serviço implementada basicamente nas camadas 2 e 3 do modelo de
referência OSI através dos mecanismos de filas de priorização de quadros (IEEE 802.1P) e
pacotes (DiffServ). Em anexo encontra-se ainda descrição da API JMF.
2
Projetos Relacionados
Este capítulo apresenta os projetos relacionados ao conceito de transcodificação, explorado nesta
dissertação, melhor detalhados a seguir: Transcodificação Baseada em Proxy [2-1]; Projeto KISS
[2-2,2-3]; Projeto ICEBERG [2-4,2-5]; e, Projeto COMCAR [2-6,2-7].
2.1. Transcodificação Baseada em Proxy
Em [2-1] é proposta uma infra-estrutura de transcodificação baseada em proxy que usa um
princípio denominado pelo autor de “destilação sob demanda”, cujo propósito é melhorar a
qualidade de serviço e reduzir o atraso percebido pelos receptores resultando em uma melhor
performance fim-a-fim e melhor qualidade dos dados de saída. O mecanismo altera os parâmetros
das mídias, por exemplo no caso do vídeo, reduz as informações de cores, freqüência, resolução
de pixels e taxa de quadros (frames), além de usar compressão com perda dos dados multimídia
para atender às restrições impostas por diferentes clientes, tais como estações de trabalho,
computadores de bolso, notebooks, cujas características de hardware, software e qualidade da
conectividade variam bastante.
Os autores fazem distinção entre o conceito de destilação e o de refinamento. Entende-se o
primeiro como a compressão com perda de determinados tipos de dados, preservando contudo
seu conteúdo semântico enquanto adaptados às restrições de largura de banda ou características
computacionais dos dispositivos clientes. O segundo, refere-se à separação de partes de um
objeto para serem tratados em determinado instante de forma separada do contexto total do objeto
como por exemplo a realização de zoom em partes de um objeto gráfico ou a apresentação de
uma
determinada
página
ao
invés
de
todo
um
documento.
É definida uma arquitetura conforme ilustra a figura 2.1, abaixo, cujos principais
componentes são: proxy; um ou mais destiladores de dados; monitor de conexão de rede,
conhecido como NCM - Network Connector Monitor, opcional; e, a biblioteca de aplicação.
2. Projetos Relacionados
6
Figura 2.1. Arquitetura Básica do Transcodificador Baseado em Proxy [2-1]
Proxy
O proxy é um componente que se comunica diretamente com os clientes e os servidores,
localizado estrategicamente entre eles. A tarefa dele é recuperar o conteúdo do servidor e de
acordo com as características do cliente definir qual mecanismo de destilação ou tratamento dos
dados multimídia será usado.
A infra-estrutura de rede - através do mecanismo de destilação - é implementada no proxy,
aliviando a complexidade dos componentes cliente e servidor, possibilitando o gerenciamento
inteligente dos formatos de texto, áudio e vídeo mais adequados ao cliente levando-se em conta a
variabilidade dos recursos da rede, do hardware e software suportados, de forma transparente à
aplicação.
Destiladores
Os destiladores de dados são processos controlados pelo proxy que realizam adaptação tanto
dos dados textuais quanto de imagens e vídeos, observando as variações nos parâmetros de rede,
hardware e software que o cliente pode suportar (formatos de áudio e vídeo).
NCM
O monitor de conexão de rede, NCM, realiza o monitoramento fim-a-fim da largura de
banda e a conectividade entre os clientes e o proxy, de forma que o proxy possa dinamicamente
reagir às mudanças nas condições da rede.
2. Projetos Relacionados
7
Biblioteca de Aplicação
A arquitetura do lado cliente suporta tanto aplicações modificadas quanto não modificadas.
Estas últimas são auxiliadas por um agente do lado cliente.
Ao invés de se preocupar com questões de formato e transporte de dados, a aplicação
cliente lida com tipos de dados a nível de camada de aplicação em quaisquer formatos de
codificação. Os processos de destilação e refinamento ocorrem de forma transparente à aplicação.
As aplicações modificadas dispõem de uma API para interagir com o proxy e manipular
dados influenciando as decisões tomadas no proxy.
Sistemas legados devem ser modificados caso queiram usar as vantagens da biblioteca de
suporte para interação com o proxy. Contudo, podem permanecer inalterados com o auxílio de
agentes do lado cliente. O agente é um processo que funciona no dispositivo cliente e se
comunica diretamente com o proxy usando a biblioteca de suporte à aplicação.
A transcodificação baseada em proxy possui as seguintes desvantagens:
Ausência de escalabilidade: o cliente depende de um único proxy para transcodificar o
stream. Caso o número de clientes aumente muito, o proxy pode ficar sobrecarregado;
Único ponto de falha: o proxy representa o único ponto de falha. Caso apresente algum
problema, todos os clientes dele dependentes não receberão os streams transcodificados.
Como vantagens, pode-se identificar:
Cada servidor tem como papel oferecer um único conteúdo de alta qualidade ao invés de
múltiplas versões do mesmo conteúdo;
A complexidade do mecanismo de transcodificação é posto no proxy, aliando os componentes
servidor e cliente;
Servidores legados não precisam ser alterados;
Os clientes confiam no proxy para a definição do conteúdo mais adequado a eles;
Os clientes precisam conhecer unicamente o proxy, sem se preocupar em manter múltiplas
sessões com diversos servidores.
A arquitetura de transcodificação proposta nesta dissertação nos capítulos 5 e 6 possui os
mesmos problemas apresentados. Caso um transcodificador falhe, o receptor precisará esperar
2. Projetos Relacionados
8
pelo retorno do serviço ou obter o serviço de um outro transcodificador, necessitando neste caso
saber a sua localização através do endereço IP.
O mecanismo de adaptação é separado da detecção de mudanças na rede, tal qual a
implementação realizada nesta dissertação.
Diferentemente da Transcodificação baseada em Proxy, a implementação realizada
apresenta no cliente maior complexidade, uma vez que o mecanismo de adaptação coletiva, tendo
como escopo a sub-rede IP é de sua responsabilidade.
2.2. Projeto KISS
O Projeto KISS [2-2,2-3] propõe uma estrutura de comunicação para serviços de transmissão de
stream em uma rede heterogênea, movendo a complexidade da aplicação para a rede como forma
de enfrentar o problema da grande quantidade de formatos de codificação e compressão para
aplicações que lidam com streaming e visando aliviar os componentes cliente e servidor.
Esta nova abordagem para ambientes de multimídia streaming tem como conseqüência que
o formato de apresentação no lado receptor não é completamente dependente do formato que é
distribuído pelo transmissor, pois ao passo que o transmissor escolhe o formato mais adequado a
ele, o receptor também toma a decisão de qual formato lhe é mais apropriado, levando em conta a
rede, a sua capacidade de processamento e as características de hardware.
Para melhorar a qualidade de recepção, o projeto KISS propõe adaptação e transcodificação
na infra-estrutura de rede que são demandadas por requisitos de cada receptor.
Para resolver o problema da heterogeneidade entre equipamentos de redes, servidores e
clientes, vários serviços de rede transparentes à aplicação são elaborados. Assim, uma aplicação
receptora ou transmissora pode usar uma conexão ponto-a-ponto entre si e uma outra aplicação
conhecida como NAP – Network Access Point. O NAP geralmente se encontra na mesma LAN
onde se encontra o transmissor e o receptor ou na borda entre a LAN e a WAN para enviar e
receber dados. O NAP é a única aplicação a se comunicar com a aplicação do usuário através de
uma interface denominada CNI – Client Network Interface.
O CNI oferece métodos para encontrar um NAP, estabelecer e controlar conexões e
oferecer ou obter informações da rede.
Uma aplicação pode funcionar como transmissora ou receptora ao mesmo tempo.
2. Projetos Relacionados
9
Entre os NAPs há uma interface denominada NNI – Network to Network Interface que
oferece métodos para propagar e requisitar informações a respeito de serviços disponíveis e são
úteis para que o receptor encontre o transmissor do stream desejado.
Um outro componente desta arquitetura é a aplicação provedora do serviço, conhecida
como SA – Service Providing Application. Um SA oferece através do NNI um serviço bem
definido para outras aplicações na rede. Este serviço pode ser um transcodificador, detecção e
correção de erro, sincronização de stream ou multicast.
Ressalte-se que nenhuma das aplicações finais está diretamente envolvida em qualquer dos
aspectos de rede, multicast ou transcodificação. Ao invés disso, uma aplicação transmissora
informa à rede através do NAP acerca do serviço oferecido. A aplicação receptora pode requisitar
uma lista de serviços disponíveis, ou seja, requisitando diferentes formatos de codificação. Toda
esta complexidade é deixada a cargo da infra-estrutura de rede elaborada.
A figura 2.2 ilustra, simplificadamente, os componentes presentes na infra-estrutura de rede
do Projeto KISS.
Figura 2.2. Visão Simplificada dos Componentes da Infra-Estrutura de Rede do Projeto
KISS [2-3]
O NAP, como vimos, é o mediador entre as aplicações-fim e o SA. O SA oferece ao NAP
seus serviços. As aplicações cliente se conectam ao NAP e requisitam os serviços. Caso o serviço
solicitado não coincida com os serviços anunciados ao NAP, este tenta encontrar um serviço na
rede que se adapte à solicitação.
Em um cenário real, um servidor pode anunciar ao NAP mais próximo (NAP 1), por
exemplo, “Audio / Vídeo ao vivo 4 Mbps, MPEG-2”. Um cliente requisita a outro NAP (NAP 2),
“Áudio / Vídeo 64 kbps H.263”. NAP 2 envia mensagens multicast na rede perguntando por um
2. Projetos Relacionados
10
transcodificador que possa converter os streams de 4 Mbps para 64 kbps, ao obter a resposta de
NAP1, repassa a informação a respeito da localização do serviço.
A vantagem da infra-estrutura proposta no projeto KISS é que as aplicações cliente obtêm os
serviços de transcodificação de uma forma transparente em relação aos SAs que podem estar
instalados em qualquer lugar da rede. Novos serviços de transcodificação podem ser adicionados
sem que as aplicações cliente sejam notificadas.
Nesta dissertação, novos transcodificadores podem ser adicionados, no entanto, os clientes
precisam saber as suas localizações através do endereço IP para poderem usar seus serviços, ou
seja, este procedimento não é transparente. O mecanismo de adaptação está implementado do
lado cliente, uma vez que o objetivo é otimizar o uso dos recursos da rede quando o link está
saturado. O mecanismo de transcodificação é implementado no componente denominado
transcodificador que também mantém informações acerca de formatos de streams mais
adequados às sub-redes participantes.
2.3. Projeto ICEBERG
O Projeto ICEBERG visa o desenvolvimento de uma infra-estrutura para integrar a variedade de
serviços de dados e telefonia disponíveis em diversas redes de acesso e acessados por diferentes
dispositivos. Implementa o conceito de portabilidade de serviço, ou seja, a possibilidade de
acessar serviços usando quaisquer dispositivos, em qualquer lugar, sem interrupção, com suporte
a mobilidade e adaptação dinâmica à variação dos recursos.
Um componente chave proposto no Projeto ICEBERG é a infra-estrutura de serviço
denominada APC - Automatic Path Creation que automaticamente adapta os dados de saída para
o dispositivo do usuário, levando em consideração as atuais condições da rede. O APC permite
que os serviços sejam acessados transparentemente de qualquer dispositivo em qualquer rede.
Além do APC, um outro componente encontrado na arquitetura é conhecido como
Operator, entendido como todo serviço baseado na Internet responsável pela transformação e
adaptação dos dados. Assim, existe um Operator que realiza a conversão do formato PCM para o
formato GSM dos usuários de telefonia celular; outro que implementa a correção de erro
necessária ao serviço de transmissão de dados para usuários de rede sem fio; etc.
2. Projetos Relacionados
11
As propriedades de transporte, tais como confiabilidade, ordem de entrega, mecanismo de
buffering e política de perdas de pacotes são encapsuladas em um componente da arquitetura
conhecido como Connector.
Além da conversão de formato, APC oferece ainda suporte ao conceito de mobilidade
pessoal necessário aos usuários móveis, permitindo que um usuário mude de uma rede sem fio
para uma rede com fio por exemplo, com mudança de endereço IP, sem que ocorra interrupção
no serviço ou troca de sessão.
Devido aos usuários poderem experimentar degradação da performance do serviço,
ocasionado por mudanças nas condições da rede em situação de congestionamento, ou por
problemas relacionados à memória e capacidade de processamento, o APC é responsável pela
devida adaptação à nova condição detectada.
O APC permite que os serviços sejam acessados transparentemente a partir de quaisquer
dispositivos e redes, conforme pode ser observado na figura 2.3.
Figura 2.3. Um Cenário Ilustrativo do APC no Projeto ICEBERG [2-4]
Neste cenário, um usuário tenta recuperar informações de um serviço de mapas disponível
na Internet usando um celular GSM. O APC realiza a conversão do formato HTML para o
formato GSM através da extração de conteúdo, sintetização de voz e operação de codificação
GSM.
2. Projetos Relacionados
12
Como desvantagem, podemos identificar que a manutenção da sessão em caso de handoff
necessita da existência de um proxy, único ponto de falha. Caso ocorram problemas, o serviço
fica indisponível.
Como vantagens, a arquitetura bem definida; a complexidade dos serviços de adaptação e
controle de sessão serem postos no APC, aliviando os componentes que ofertam os serviços
daqueles que os recebem; e a disponibilização de serviços variados de transcodificação de áudio,
vídeo e texto para diversos formatos.
Esta dissertação implementa o mesmo conceito do APC realizando a transcodificação do
stream de áudio de origem em três streams diferentes de áudio mais adequados às restrições de
enlace com as diferentes sub-redes onde se encontram os receptores.
O conceito de mobilidade pessoal não é aqui implementado. Caso um dispositivo mude de
uma sub-rede para outra, tal mudança não mantém a sessão já iniciada que precisaria ser
novamente criada.
2.4. Projeto COMCAR
Foi patrocinado até 2002 pelo ministério de educação e pesquisa do governo alemão com o
objetivo de conceber e implementar protótipos de rede de comunicação móvel que satisfaçam à
demanda por multimídia baseada em IP e serviços de telecomunicações para trens e carros. Um
aspecto importante enfocado é a qualidade de serviço, tratada através da concepção de aplicações
móveis adaptativas.
É parte do Projeto UMTSplus, um novo conceito de sistemas que tenta resolver o problema
da universalidade e mobilidade de redes e sistemas de telecomunicação.
A figura 2.4 ilustra a área de abrangência do Projeto COMCAR.
2. Projetos Relacionados
13
Figura 2.4. Área de Interesse do Projeto COMCAR [2-7]
O foco está nos serviços assimétricos e interativos baseados em IP. As tecnologias de rádio
e infra-estruturas tais como GSM, GPRS e UMTS são usadas e otimizadas para a oferta de
serviços de alta qualidade tendo por base o IP. Também são usados sistemas de broadcast digital
tais como DAB ou DVB-T.
Oferece um ambiente de comunicação flexível aos parâmetros de QoS propondo para isto o
desenvolvimento de um middleware para oferecer adaptação às aplicações multimídia móveis.
As funcionalidades do COMCAR estão divididas em três camadas:
Uma API de baixo nível para acessar as informações de rede, mapeamento de IP QoS e
suporte a módulos para descoberta de serviço;
Um modelo de componente para a oferta de serviços multimídia de rede. O modelo separa os
componentes de manuseio das mídias daqueles de controle da aplicação.
Uma API de alto nível permitindo à aplicação requisitar os serviços de comunicação
multimídia. A aplicação pode definir as restrições de QoS e comportamentos alternativos para
os serviços de comunicação. Uma parte da API define a interface de controle que permite à
aplicação checar o status dos serviços multimídia; outra parte permite ao middleware sinalizar
mudança nos serviços de comunicação para a aplicação; e, por fim, uma opcional que permite
a negociação entre a aplicação e o middleware no caso do QoS requisitado não poder ser
oferecido.
2. Projetos Relacionados
14
A figura 2.5 mostra a arquitetura do sistema COMCAR, onde podemos identificar os
seguintes componentes:
CM - Communication Manager, é a entidade central da plataforma de comunicação.
Seleciona e regula a comunicação configurando parâmetros de QoS para atender às
necessidades dos usuários baseado em informações dadas pelo Commom Coordination
Channel e pelo Gerenciador de Profile do Usuário. Possui um componente denominado
QoS-M - QoS Manager para gerenciamento do QoS;
CCC-M - Commom Coordination Channel Manager é responsável por oferecer informações
sobre a disponibilidade dos sistemas de comunicação e suas capacidades;
SM - Session Manager oferece suporte a mudança do serviço de forma transparente ao
usuário, realizando o vertical handoff, ou seja, a mudança de provedor de serviço, do sistema
de comunicação ou do dispositivo de apresentação ao usuário, sem perda da sessão
estabelecida;
PM - Presentation Manager é responsável por gerenciar diferentes componentes de hardware
e software, tais como, monitores sensíveis ao toque, dispositivos de conversão de texto para
voz e vice-versa e dispositivos de áudio, etc;
AH - Application Handling realiza o planejamento do serviço de entrega, o controle da
aplicação e as conexões de comunicação/streams multimídia associados, além de tarefas
como download de componentes necessários à aplicação. Interage com o SM, o CCC-M e o
CM;
MM - Media Manager são componentes usados para enviar, receber, controlar, monitorar,
processar e apresentar streams multimídia, tentando manter ao máximo os requisitos de QoS.
2. Projetos Relacionados
15
Figura 2.5. Arquitetura do Sistema COMCAR [2-7]
Em [5-1] é definido como parte do Projeto COMCAR [2-6] uma infra-estrutura de
transcodificação especialmente para atender as limitações de recursos disponíveis em clientes
móveis como celulares, palms e notebooks, conforme ilustra a figura 2.6.
Figura 2.6. Infra-estrutura de Transcodificação Implementada como parte do
Projeto COMCAR [5-1]
Na figura, podemos observar que o stream MP3 44Khz é convertido em diferentes
transcodificadores para formatos diversos mais adequados às restrições computacionais dos
dispositivos clientes. Cada formato de codificação de áudio possui diferentes características
quanto à qualidade e largura de banda ocupada.
Como desvantagem, observe-se mais uma vez que para a implementação do serviço de
vertical handoff, há a necessidade da existência de um proxy que representa um único ponto de
2. Projetos Relacionados
16
falha. As vantagens são uma API e arquitetura bem definidas; um ambiente de comunicação
flexível aos parâmetros de QoS; a existência de um middleware no qual se concentra toda a
complexidade, aliviando os componentes que demandam serviços e os que os ofertam.
A infra-estrutura de transcodifcação do Projeto COMCAR é semelhante à implementada
nesta dissertação, atendendo mais à problemática das características computacionais dos
diferentes dispositivos receptores e os formatos de codificação e decodificação que estes
dispositivos podem processar. O diferencial do presente trabalho é o controle por parte do
transcodificador acerca de qual formato de codificação de áudio é mais adequado às sub-redes
por ele atendidas não sendo levado em conta as características computacionais dos dispositivos
receptores, embora o modelo apresentado no capítulo 5 esteja aberto para isto através do
componente ClientConditions.
3
Real-Time Transport
Protocol (RTP)
Neste capítulo é abordado o protocolo de aplicação / transporte RTP explicitando o mecanismo
de envio de relatórios usado para manter informado tanto o transmissor quanto o receptor a
respeito da qualidade dos dados multimídia (dentre outras informações) que é capaz de
transportar com o auxílio do protocolo de transporte UDP. Introduz-se ainda, brevemente, cada
um dos formatos de áudio RTP disponíveis na API JMF 2.1.1e usados para implementar o
mecanismo de transcodificação desta dissertação.
3.1. Apresentação
RTP - Real-Time Transport Protocol é definido pelo Grupo de Trabalho Audio/Video Transport
do IETF - Internet Engeneering Task Force [3-4] nas RFC 1889 [3-1] e RFC 3550 [3-2]. Esta
última torna obsoleta a primeira não realizando modificações no formato dos pacotes mas
somente modificações nas regras e algoritmos que regulam como o protocolo é usado. Oferece
serviços de entrega fim-a-fim de dados com características de tempo real, tais como áudio e vídeo
interativo. Estes serviços incluem identificação do tipo da carga útil, números de seqüência,
marcas de tempo e monitoramento de entrega. Aplicações usam o RTP no topo do protocolo de
transporte UDP (figura 3.1) para fazer uso de suas características de multiplexação e checksum.
RTP suporta transferência de dados para múltiplos destinos usando distribuição multicast
disponibilizada pela camada de rede.
RTP não oferece nenhum mecanismo para garantir o tempo de entrega ou outras garantias
de qualidade de serviço, confiando nas camadas inferiores para isso. Não garante entrega ou
previne entrega fora da ordem, nem assume que a camada de rede abaixo seja confiável e
entregue pacotes em seqüência. O número de seqüência incluso no pacote RTP permite ao
receptor reconstruir a seqüência de pacotes do transmissor, além de permitir que os pacotes sejam
3. Real-Time Transport Protocol (RTP)
18
decodificados fora da seqüência para depois serem seqüenciados antes da apresentação do áudio
no receptor.
A figura 3.1, a seguir, ilustra o posicionamento dos protocolos RTP e RTSP - Real-Time
Streaming Protocol no modelo TCP/IP. O protocolo RTSP é um protocolo de aplicação mantido
pelo grupo de trabalho MMUSIC do IETF [3-6] e definido na RFC 2326 [3-7]. É referenciado
por ser ideal e exclusivo para a negociação da distribuição de áudio e vídeo sob demanda funcionando como um controle remoto para a recepção dos streams distribuídos na rede. O RTSP
geralmente se utiliza do protocolo RTP embora não seja dele dependente. Em aplicações de áudio
e vídeo conferências, o uso do RTSP pode contribuir através de requisições semelhantes às do
protocolo HTTP a servidores multimídia que então iniciam o processo de transmissão de streams
que podem ser distribuídos para os participantes da conferência.
Figura 3.1. Posicionamento e Interações dos Protocolos RTP/RTCP e RTSP no Modelo
TCP/IP [3-3]
A RFC 2508 [3-8], trata da compressão dos cabeçalhos dos datagramas IP/UDP/RTP a fim
de melhorar a performance em enlaces de baixa velocidade. Tanto o cabeçalho do RTP, formado
3. Real-Time Transport Protocol (RTP)
19
por no mínimo 12 bytes, quanto o cabeçalho composto, formado por um mínimo de 40 bytes, são
comprimidos para tamanhos que variam de 2 a 4 bytes.
3.2. Objetivos do RTP
Inicialmente projetado para satisfazer as necessidades de conferências multimídia com vários
participantes, não é limitado apenas a esta funcionalidade podendo ser também usado para
armazenamento de dados contínuos, simulações interativas distribuídas entre outras.
O RTP é desenvolvido para ser flexível a fim de oferecer a informação necessária para as
aplicações, sendo geralmente integrado ao processamento da aplicação ao invés de ser
implementado como uma camada em separado.
Pode ser usado com outros protocolos das camadas de transporte, não limitado ao UDP, e
de rede, não limitado ao IP, embora seja esta a combinação mais comum.
É escalar, podendo ser usado tanto em aplicações unicast quanto multicast, com número de
participantes variando de 2 a O(107).
Conforme visto no tópico 3.3 a seguir, possibilita o transporte de dados multimídia e de
controle e ainda o uso de criptografia e autenticação [3-2].
3.3. Transporte de Dados Multimídia e de Controle
O protocolo RTP é formado por duas partes intimamente ligadas:
RTP - Real-Time Transport Protocol, responsável pelo transporte de dados com propriedades
de tempo real, dentre os quais se encontram dados multimídia. Cada pacote RTP possui uma
marcação de tempo usada para sincronização de diferentes streams de áudio e vídeo, número
de seqüência usado para detecção de perda de pacotes, indicação do tipo de dado encapsulado
pelo RTP, entre outros;
RTCP - RTP Control Protocol, usado para transportar dados de controle com a finalidade de
monitorar a qualidade de serviço e oferecer informações a respeito dos participantes em uma
dada sessão RTP.
participantes.
O envio de pacotes RTCP é periódico e depende do número de
3. Real-Time Transport Protocol (RTP)
20
3.4. Funções RTP
As funções disponibilizadas pelo protocolo RTP são:
Fragmentação e remontagem de pacotes realizada pelo protocolo da camada de transporte,
UDP ou similar;
Reseqüenciamento, caso haja necessidade;
Detecção de perda de pacotes para verificação da qualidade ou recuperação de pacotes;
Sincronização intra-mídia para a remoção do jitter através do uso de buffer no receptor;
Sincronização entre mídias para apresentação de streams de áudio e vídeo relacionados;
Disponibilização de informações que sirvam de base para mecanismos de adaptação a fim de
garantir qualidade de serviço e adaptação da taxa de transferência de áudio e vídeo;
Identificação da origem de streams multimídia.
3.5. Misturador e Tradutor RTP
Um misturador resincroniza os pacotes de áudio que estão chegando a fim de reconstruir o
espaçamento constante de 20 ms gerado pelo transmissor, podendo mudar ou não o formato de
codificação dos streams multimídia de entrada, misturando-os em um simples stream de saída.
Observe na figura 3.2 que o campo SSRC - Synchronization Source, responsável por identificar a
origem do stream de pacotes RTP é mudado no Misturador recebendo um novo valor para o novo
stream gerado a partir dele, SSRC=52, preservando-se contudo a identificação de quais fontes de
streams RTP contribuíram, CSRC - Contributing source = {6,23}. O misturador realiza ajustes
de tempo entre os streams e gera seu próprio tempo para o stream combinado. Pode ser usado
para atender a exigência de transmitir áudio e vídeo oriundos de várias fontes para enlaces com
restrições de largura de banda.
Figura 3.2. Atuação de um Misturador nos Streams Multimídia de Entrada. [3-2]
3. Real-Time Transport Protocol (RTP)
21
Um tradutor pode ser entendido como um sistema intermediário que retransmite pacotes
RTP deixando intactos os campos SSRC dos streams multimídia de origem, conforme se verifica
na figura 3.3 abaixo. É usado para atravessar filtros de firewall e quando não há possibilidade de
retransmissão de pacotes destinado a grupos multicast localizados além do firewall. Pode ainda
mudar ou não o formato de codificação do dado multimídia que chega ao tradutor, sem no
entanto alterar o campo SSRC que identifica a origem do stream.
Figura 3.3. Atuação de um Tradutor nos Streams Multimídia de Entrada. [3-3]
3.6. Pacote RTP
O pacote RTP tem o formato observado na figura 3.4, cujos campos possuem o seguinte
significado:
Figura 3.4. Pacote RTP [3-2]
Versão (V): Representado por 2 bits, é o identificador da versão do RTP que neste caso é a
versão 2;
3. Real-Time Transport Protocol (RTP)
22
Enchimento (P): Possui apenas 1 bit que em apresentando valor 1, significa que o pacote
possui um ou mais octetos adicionais no final que não fazem parte da carga útil. O último
octeto do enchimento possui um contador de quantos octetos de enchimento precisam ser
ignorados, incluindo ele próprio. Este campo é necessário para alguns algoritmos de
criptografia ou para carregar vários pacotes RTP em uma unidade de protocolo de camada
mais baixa;
Extensão (X): Tem apenas um bit que se possuir valor 1 significará que o cabeçalho fixo será
seguido de apenas uma extensão ao cabeçalho;
Contador CSRC (CC): Possui 4 bits e representa o número de identificadores CSRC que
seguem o cabeçalho fixo;
Marcação (M): É representado por 1 bit cuja interpretação é definida por um profile, podendo
significar, dentre outras coisas, os limites do quadro a ser marcado no stream de pacotes;
Tipo da carga útil (PT): Definido por 7 bits, este campo identifica o formato da carga útil do
RTP, determinando a sua interpretação pela aplicação. Um conjunto de mapeamentos padrão
entre códigos de tipos de carga útil e os formatos de áudio e vídeo podem ser encontrados na
RFC 3551 [3-9]. Uma fonte RTP pode mudar o tipo de carga útil durante uma sessão;
sequence number: Representado por 16 bits, este número incrementa em um a cada pacote
RTP enviado, sendo usado pelo receptor para detectar perda de pacotes e restaurar o seu
seqüenciamento;
timestamp: Definida por 32 bits, a marca de tempo reflete o instante do primeiro octeto no
pacote de dados RTP. A marca de tempo é derivada do relógio do computador e é usada para
a sincronização de streams multimídia e para permitir o cálculo do jitter;
SSRC: Representado por 32 bits, este campo identifica a origem do stream transmitido. É
escolhido aleatoriamente com a intenção de que não haja duas fontes na mesma sessão RTP
que tenham o mesmo identificador. As implementações RTP estão preparadas para detectar e
resolver os casos de repetições;
Lista CSRC: Varia de 0 a 15 itens, cada um com 32 bits. Identifica as fontes contribuintes
para a carga útil contida no pacote. O número de identificadores é dado pelo campo CC. Caso
haja mais que 15 fontes contribuintes, apenas as 15 primeiras são representadas;
Header extension: É um mecanismo que permite a certas implementações com novos
formatos de carga útil (áudio, vídeo, etc) que necessitem de informações adicionais de
3. Real-Time Transport Protocol (RTP)
23
comprimento variável serem carregadas no cabeçalho do pacote RTP. Este mecanismo é
projetado de tal forma que a extensão possa ser ignorada por outras implementações que não
necessitem dela. Caso o bit X possua valor 0 é ignorado. Veja figura 3.5, adiante;
payload: É o dado transportado pelo pacote RTP, tais como amostras de áudio e dados
comprimidos de vídeo.
Os doze primeiros octetos (figura 3.4 acima) estão presentes em cada pacote RTP, enquanto
que a lista de identificadores CSRC está presente somente quando inserida por um misturador.
O referencial de tempo é representado usando a marca de tempo definida para o NTP Network Time Protocol, que é apresentado em segundos relativo a 0h UTC de 1 de janeiro de
1900 [3-5]. A marca de tempo NTP é representada por um número de ponto fixo não sinalizado
de 64-bit com a parte inteira representada pelos primeiros 32 bits e a fracional representada pelos
últimos 32 bits. Uma implementação não necessita usar o NTP para usar RTP, a não ser quando
sincronizar streams transmitidos de diferentes computadores.
Os primeiros 16 bits da extensão do cabeçalho (figura 3.5 abaixo) são deixados em aberto
para a definição de parâmetros, cujo formato é definido pela especificação do profile em que a
implementação está operando. O campo comprimento possui 16 bits que contam o número de
palavras de 32 bits, excluindo os 4 octetos da extensão do cabeçalho.
Figura 3.5. Extensão do Cabeçalho do Pacote RTP [3-2]
3. Real-Time Transport Protocol (RTP)
24
3.7. Protocolo RTCP
O protocolo RTCP é baseado em transmissões periódicas de pacotes de controle para todos os
participantes em uma sessão usando o mesmo mecanismo de distribuição de pacotes de dados. O
protocolo de transporte utilizado (geralmente UDP) abaixo deve realizar a multiplexação dos
pacotes de dado e controle, como por exemplo através do uso de números de portas UDP
diferentes. Suas quatro funções básicas são:
Oferece à fonte de streams RTP informações dadas pelos receptores a respeito da qualidade
de distribuição dos dados. Os receptores também podem usar estas informações para
implementar mecanismos de adaptação ou simplesmente para apresentar informações sobre a
recepção;
O RTCP carrega um identificador da fonte RTP chamado de CNAME - Canonical Name.
Uma vez que o identificador SSRC dos participantes pode ser modificado devido a conflitos,
os receptores necessitam do CNAME para identificar o stream de cada participante. Os
receptores também utilizam o CNAME para associar sessões RTP relacionadas
(sincronização entre mídias), por exemplo áudio e vídeo. A sincronização entre mídias
também necessita das marcas de tempo NTP e RTP;
As duas funções acima requerem que todos os participantes enviem pacotes RTCP, contudo a
periodicidade de transmissão dos pacotes RTCP é controlada a fim de que o RTP seja escalar
a um grande número de participantes. Para isso, cada participante observa o número de
participantes e usa esta informação para calcular a taxa de transmissão;
RTP permite o transporte de informações mínimas de controle de sessão, por exemplo
informações de identificação dos participantes que são mostradas na interface do usuário.
As funções acima podem ser usadas tanto em ambiente unicast quanto multicast. Para
grande número de participantes o uso de multicast torna-se imprescindível.
Formato do Pacote RTCP
Há vários tipos de pacotes RTCP para carregar as informações de controle:
Relatório SR - Sender Report, para transmissão e recepção de estatísticas a respeito dos
participantes que são transmissores ativos;
Relatório RR - Receiver Report, para recepção de estatísticas dos participantes que não são
transmissores;
3. Real-Time Transport Protocol (RTP)
25
Informações SDES – Source Description Itens, referentes à fonte dos streams, incluindo o
CNAME;
Indicação de fim de participação, BYE;
Funções de Aplicações específicas, APP.
Receptores RTP retornam informações a respeito da qualidade de recepção usando pacotes
RTCP que podem assumir uma de duas formas dependendo do receptor ser também transmissor.
A única diferença entre os relatórios de transmissão (SR) e os de recepção (RR) além do tipo de
código do pacote é que o SR inclui 20 bytes de informação do transmissor, usados pelos
transmissores ativos.
Tanto o SR quanto o RR incluem 0 ou mais blocos de relatórios de recepção, um para cada
fonte de stream do qual dado receptor recebeu pacotes de dados RTP desde o último relatório
enviado. Cada bloco de relatório de recepção provê estatísticas a respeito dos dados recebidos de
uma fonte indicada no bloco. Uma vez que no máximo 31 blocos de relatórios de recepção
caberão em um pacote SR ou RR, pacotes RR podem ser empilhados após o pacote SR ou RR
inicial a fim de conter os relatórios de recepção de todas as fontes escutadas durante o intervalo
desde o último relatório enviado.
A figura 3.6 abaixo ilustra o formato do pacote RTCP SR:
Figura 3.6. Pacote RTCP SR [3-2]
3. Real-Time Transport Protocol (RTP)
26
O pacote SR é formado por três sessões que podem ser seguidas de uma quarta dependente
do profile. A primeira, o cabeçalho, é formado por 8 bytes cujos campos possuem o seguinte
significado:
Versão (V): Formado por 2 bits, identifica a versão do RTP que neste caso é a versão 2;
Enchimento (P): Composto por 1 bit, caso possua valor 1 significará que este pacote RTCP
possui alguns octetos de enchimento adicionais no final que não fazem parte das informações
de controle mas que são incluídos no campo comprimento. O enchimento é necessário para
alguns algoritmos de criptografia;
Contador RC - Reception Report Count: Formado por 5 bits, informa o número de blocos de
relatórios de recepção contidos no pacote;
PT - Packet type: Seus 8 bits contêm a constante 200 para identificar que este é um pacote
RTCP SR;
Comprimento: Composto por 16 bits, informa o comprimento do pacote RTCP incluindo o
cabeçalho e o eventual enchimento;
SSRC: Identificado por 32 bits, representa a origem do pacote SR.
A segunda sessão, contém informações do transmissor e é representada por 20 octetos que
estão presentes em cada pacote SR. Apresenta um resumo das transmissões realizadas por
determinado transmissor. Os campos possuem o seguinte significado:
Marca de tempo NTP: Composta de 64 bits, indica o tempo em que um dado relatório foi
enviado de tal forma que ele possa ser comparado à marca de tempo retornada pelos RR de
outros receptores a fim de medir o tempo médio de propagação até os receptores;
Marca de tempo RTP: Formada por 32 bits, corresponde ao mesmo tempo indicado na marca
de tempo NTP, na mesma unidade e em compatibilidade com as marcas de tempo RTP dos
pacotes de dados. É usada para sincronização intra-mídia e entre mídias;
Contador de pacotes do transmissor: Composto de 32 bits, corresponde ao número total de
pacotes de dados transmitidos por uma fonte qualquer desde o início da transmissão até o
momento em que o pacote SR foi gerado;
Contador de octetos do transmissor: Possui 32 bits e representa o número total de octetos de
carga útil, isto é, não incluindo cabeçalho e enchimento transmitidos em pacotes de dados
3. Real-Time Transport Protocol (RTP)
27
RTP pela fonte de streams desde o início da transmissão até o momento em que o pacote SR
foi gerado.
A terceira sessão contém zero ou mais blocos de relatórios de recepção dependendo do
número de receptores escutados pelo transmissor desde o último relatório enviado. Cada bloco de
relatório de recepção carrega informações estatísticas a respeito da recepção dos pacotes RTP de
uma única fonte de transmissão. As estatísticas são:
SSRC_n (identificação da fonte): Formado por 32 bits, representa o identificador SSRC da
fonte a que a informação no bloco de recepção pertence;
Percentual de perda: Representado por 8 bits, significa o percentual de pacotes de dados RTP
originados a partir de uma fonte identificada pelo SSRC_n perdidos desde o último pacote SR
ou RR enviado;
Somatório do número de pacotes perdidos: Composto de 24 bits, representa o número total de
pacotes de dados RTP oriundos da fonte SSRC_n que foram perdidos desde o início da
recepção;
Mais alto número de seqüência extendido recebido: Formado por 32 bits, os 16 bits menos
significativos contêm o número de seqüência com valor mais alto recebido em um pacote de
dados RTP vindo de uma fonte SSRC_n. Os 16 bits mais significativos são usados pelo
receptor;
Jitter: Formado por 32 bits, é uma estimativa da variação estatística do tempo de chegada
entre pacotes, medido em unidades de marca de tempo e expressado como um inteiro sem
sinal;
Marca de tempo do último SR (LSR): Seus 32 bits são retirados da marca de tempo NTP do
mais recente pacote RTCP SR recebido de uma dada fonte SSRC_n. Caso nenhum pacote
RTCP SR tenha sido recebido, este campo assume valor 0;
Atraso desde o último SR (DLSR): Representado por 32 bits que significam o atraso,
expresso em unidades de 1/65536 segundos, entre a recepção do último pacote SR vindo da
fonte SSRC_n e o momento de envio do bloco de relatório de recepção atual. Caso nenhum
pacote SR tenha sido recebido, DLSR assume valor 0. Permite à fonte calcular o atraso médio
do tempo de propagação até o receptor.
3. Real-Time Transport Protocol (RTP)
28
O pacote RTCP RR, figura 3.7 abaixo, é o mesmo que o SR, exceto que o campo tipo do
pacote contem a constante 201 e os 20 bytes de informação do transmissor são omitidos. O
restante dos campos possuem o mesmo significado.
Figura 3.7. Pacote RTCP RR [3-2]
Cálculo do Jitter
Denomina-se tempo relativo de trânsito, à diferença entre a marca de tempo RTP e o relógio do
receptor no instante de chegada do pacote, medido nas mesmas unidades.
Considere Si a marca de tempo RTP para o pacote i, e Ri o tempo de chegada em unidades
de tempo RTP para o mesmo pacote i, então para dois pacotes i e j, o atraso D pode ser expresso
da seguinte forma:
D(i,j) = (Rj – Ri) – (Sj – Si) = (Rj – Sj) – (Ri – Si)
O jitter deve ser calculado continuamente, cada vez que um pacote de dados i é recebido de
uma fonte SSRC_n, usando a diferença D para este pacote e o anterior, i-1, na ordem de chegada
de acordo com a fórmula:
J(i) = J(i-1) + ( | D(i-1,i) | - J(i-1))/16
Sempre que um pacote RR é enviado o valor J é calculado.
3. Real-Time Transport Protocol (RTP)
29
Intervalo de Transmissão RTCP
RTP é projetado para permitir a aplicações se adaptarem automaticamente ao tamanho da
sessão que pode variar desde poucos participantes até milhares. A quantidade de pacotes de dados
multimídia é relativamente mais previsível que a quantidade de pacotes de controle. Com efeito,
em uma aplicação de áudio conferência com distribuição multicast para vários participantes, é
previsível que haja no máximo dois participantes falando ao mesmo tempo enquanto que os
outros apenas escutam. Assim, a sessão de dados RTP possui apenas no máximo 2 participantes
enquanto que os pacotes RTCP trocados crescerá linearmente com o número de participantes. O
intervalo de transmissão de pacotes RTCP é então ajustado a fim de controlar a taxa de
transferência quando há um número muito grande de participantes.
Um conceito chave para o cálculo do intervalo de transmissão é a largura de banda da
sessão. Esta, pode ser estabelecida com base no conhecimento prévio da largura de banda da rede
disponível. Geralmente é representada pelo somatório das larguras de banda nominais dos
transmissores esperados para serem concorrentemente ativos.
A largura de banda utilizada pelo tráfego de controle (largura de banda RTCP) é fixa em
5% da largura de banda da sessão. Da largura de banda RTCP, 25% é reservada para os
participantes que são transmissores de dados, enquanto que os 75% restante são reservados para
os receptores caso o número de transmissores seja menor que 1/4 do número total de membros.
Caso o número de transmissores seja maior que este valor, então há uma separação igual entre
todos os participantes.
Caso o participante não tenha enviado ainda um pacote RTCP, o intervalo mínimo para a
transmissão assume valor de 2,5 segundos. A partir do instante em que o participante envia um
pacote RTCP, o intervalo mínimo de transmissão assume valor de 5 segundos. O intervalo
assume valor aleatório para cada participante e na média distribui o uso da largura de banda
RTCP conforme explicitado no parágrafo anterior.
A maior parte das modificações realizada pela RFC 3550 [3-2] frente a RFC 1889 [3-1]
ocorreu no algoritmo para o cálculo do intervalo de transmissão de pacotes RTCP visando
melhorar a performance para grupos muito grandes de participantes. Dentre outras alterações,
podemos citar:
Foi incluída uma “reconsideração” para minimizar o excesso de transmissão quando muitos
participantes entram em uma sessão simultaneamente, e “reconsideração reversa” para reduzir
3. Real-Time Transport Protocol (RTP)
30
a incidência e duração do tempo de expiração de falsos participantes quando o número de
participantes cai drasticamente. Esta última também pode ser usada para diminuir o atraso no
envio de pacotes RTCP SR quando um participante muda de receptor para transmissor;
Novas regras são definidas a fim de controlar quando um pacote RTCP BYE deve ser enviado
quando um número muito grande de participantes deixa a sessão simultaneamente;
Apenas os identificadores SSRC dos participantes devem ser armazenados permitindo atender
a sessões com um número muito grande de participantes.
3.8. Representação Digital dos Dados de Áudio
A representação digital dos dados de áudio tem a vantagem de ter alta imunidade a ruído, ser
estável e reprodutível. Áudio na forma digital permite ainda a implementação de muitas funções
de processamento, tais como a junção de várias fontes de áudio em uma única fonte; filtragem de
determinadas freqüências de um sinal original; e, equalização, entendida como o aumento da
intensidade de determinados sinais e a diminuição da intensidade de outros recuperando o sinal
original perdido devido a distorções.
A conversão do sinal analógico para o digital tem início separando-se o áudio de entrada em
intervalos de tempo regulares e criteriosos e associando-se os valores do sinal amostrado a uma
seqüência de valores binários. O método para representar cada amostra a uma palavra de código
independente é chamado PCM - Pulse Code Modulation. Veja a figura 3.8.
Figura 3.8. Processamento de Áudio Digital [3-12]
As taxas de amostra variam entre 8 kilohertz (kHz) e 48 kHz. A taxa de 8 kHz cobre uma
faixa de freqüência acima de 4 kHz, o que significa a maioria das freqüências produzidas pela
voz humana. A taxa de 48 kHz cobre uma faixa de freqüência acima de 24 kHz, ou seja,
adequadamente a faixa de freqüência audível que para os humanos não ultrapassa os 20 kHz.
3. Real-Time Transport Protocol (RTP)
31
Dados de áudio em um compact disk com dois canais amostrados a 44,1 kHz e 16 bits por
amostra produzem uma taxa de dados de aproximadamente 1,4 megabits por segundo. Este
exemplo ilustra claramente a necessidade de compressão dos dados de áudio para uma
transmissão e armazenamento eficientes.
Existem várias técnicas de compressão de dados de áudio com diferentes níveis de
complexidade, qualidade e quantidade dos dados comprimidos.
A RFC 3551 [3-9] que torna obsoleta a RFC 1890 tece algumas considerações sobre os
formatos de áudio RTP [3-1] abordados nesta dissertação, presentes na API JMF 2.1.1e [An-1],
conforme passamos a explicitar nos tópicos a seguir.
3.8.1. Codificação de Áudio
A codificação de áudio RTP pode ser baseada em amostras ou em quadros.
Codificação de Áudio Baseada em Amostra
Na codificação baseada em amostra, cada amostra de áudio é representada por um número
fixo de bits. Um pacote de áudio RTP pode conter qualquer número de amostras de áudio,
observando que o número de bits por amostra multiplicado pelo número de amostras por pacote
resulta em um número de octetos inteiro. Codificações fracionais produzem menos de um octeto
por amostra.
A duração de um pacote de áudio é determinada pelo número de amostras no pacote.
Para codificação baseada em amostra produzindo um ou mais octetos por amostra, amostras
de diferentes canais em um mesmo instante são empacotadas em octetos consecutivos.
A marca de tempo RTP reflete o instante em que a primeira amostra do pacote foi
amostrada, que é a informação mais antiga no pacote.
Codificação de Áudio Baseada em Quadro
Codifica um bloco de áudio de comprimento fixo dentro de outro bloco de dados
comprimido, geralmente também de comprimento fixo. Na codificação baseada em quadro, o
transmissor pode escolher combinar vários quadros em um pacote RTP único. O receptor pode
saber quantos quadros estão contidos em um pacote RTP caso todos os quadros possuam o
mesmo tamanho, simplesmente dividindo o tamanho da carga útil (payload) do pacote RTP pelo
3. Real-Time Transport Protocol (RTP)
32
comprimento do quadro que é definido como parte do codificador. Isto não funciona quando o
tamanho do quadro é variável.
Para codificadores baseados em quadro, a ordem do canal é definida para um bloco inteiro.
Assim, para dois canais de áudio, amostras esquerda e direita podem ser codificadas
independentemente, com o quadro codificado para o canal esquerdo precedendo o do canal
direito.
Todos os codificadores de áudio orientados a quadros devem estar aptos a codificar e
decodificar vários quadros consecutivos dentro de um único pacote.
Pacotes RTP podem conter vários quadros que são inseridos no pacote à medida que são
criados, de tal forma que o quadro mais antigo e que deverá ser reproduzido primeiro no receptor
ocorre imediatamente após o cabeçalho do pacote RTP. A marca de tempo RTP reflete o instante
em que a primeira amostra do primeiro quadro foi amostrada, que é a informação mais velha no
pacote.
3.8.2. Intervalo de Criação dos Pacotes
Para pacotes de áudio, o intervalo de empacotamento padrão tem duração de 20 ms ou o tempo
de criação de um quadro. O intervalo de empacotamento determina o mínimo atraso fim-a-fim.
Pacotes muito longos possuem menos overhead de cabeçalho, no entanto possuem um atraso
maior e sofrem mais com a perda de pacotes.
Para aplicações não tempo-real ou para enlaces com restrições de largura de banda pode ser
usado um intervalo de empacotamento alto.
Um receptor pode aceitar pacotes contendo entre 0 e 200 ms de dados de áudio. Para
codificadores de áudio baseados em quadro, um receptor deve aceitar pacotes com um número de
quadros igual a 200 ms dividido pela duração de cada quadro, com o resultado arredondado para
cima.
Estas restrições permitem um tamanho de buffer de recepção razoável.
3.9. Formatos de Codificação de Áudio RTP Disponíveis na API JMF 2.1.1e
A tabela 3.1, abaixo, apresenta os codificadores de áudio RTP disponíveis na API JMF 2.1.1e que
em seguida são descritos.
3. Real-Time Transport Protocol (RTP)
33
Tabela 3.1. Codificadores de Áudio RTP Disponíveis na API JMF 2.1.1e
* possuem boa qualidade para fala humana
** 16 bits por amostra na implementação disponível na API JMF 2.1.1e
ND – Informação não disponível
3.9.1. DVI
Usa o esquema de codificação ADPCM - Adaptative Delta Pulse Code Modulation que foi
especificado pelo IMA - Interactive Multimedia Association. O IMA desenvolveu uma série de
algoritmos incluindo codificadores de áudio conhecidos como ADPCM DVI ou simplesmente
DVI no início dos anos 90 [3-11]. A RFC 3551 [3-9] recomenda algumas alterações do formato
original ADPCM DVI.
A figura 3.9 mostra um diagrama de blocos simplificado para a codificação ADPCM. O
codificador ADPCM aproveita-se do fato das amostras de áudio vizinhas serem geralmente
parecidas umas com as outras. Ao invés de representar cada amostra de áudio de modo
independente como no PCM, um codificador ADPCM verifica a diferença entre cada amostra de
áudio e a anterior de forma a gerar como saída apenas a diferença. Pela observação da figura
3.9(a) em relação à figura 3.9(b) podemos verificar que a codificação é mais complexa que a
decodificação.
3. Real-Time Transport Protocol (RTP)
34
(a) Codificador ADPCM
(b) Decodificador ADPCM
Figura 3.9. Compressão e Descompressão ADPCM [3-11]
Note-se que o codificador (figura 3.9a) usa a maioria dos componentes do decodificador
(figura 3.9b), blocos Adaptative Dequantizer e Adaptative Predictor, para obter os valores
previstos.
A saída do bloco Quantizer é geralmente apenas uma representação do número de níveis de
quantificação do sinal. O bloco Dequantizer reconstrói o valor da amostra quantificada.
Alguns sistemas ADPCM requerem que o codificador forneça informações adicionais à
diferença dos valores PCM. Esta informação pode servir para dois propósitos. Primeiro, em
alguns esquemas ADPCM, o decodificador necessita de informações adicionais tanto para o
PREDICTOR quanto para o QUANTIZER. Segundo, os dados podem oferecer informação
redundante para o decodificador poder recuperar os erros em streams de bits.
Um dos objetivos do algoritmo IMA ADPCM é ser simples o suficiente para permitir
descompressão por software de áudio estéreo 44,1 kHz em tempo real com um mínimo de
recursos computacionais.
A simplicidade do IMA ADPCM reside em seu PREDICTOR. O valor previsto da amostra
de áudio é o valor decodificado da amostra de áudio imediatamente anterior.
3. Real-Time Transport Protocol (RTP)
35
3.9.2. Compressão de Áudio -LAW
A transformação -LAW é uma técnica básica de compressão de áudio especificado pelo CCITT
- Comité Consultatif Internationale de Télégraphique et Téléphonique, recomendação G.711 [313]. É uma transformação essencialmente logarítmica por natureza com amostras de 8 bits que
equivalem a 14 bits de dados de áudio linear.
O espaçamento logarítmico, ao contrário da quantização linear, representa amostras de
baixa amplitude de áudio com maior precisão que os valores de amplitudes mais altas.
A transformação -LAW é representada pela seguinte equação:
Onde x é o valor do sinal de entrada normalizado para ter um valor máximo de 1. A
recomendação CCITT G.711 também especifica uma transformação A-LAW semelhante.
A transformação -LAW é comumente usada para serviços de telefonia digital de 8 kHz
ISDN - Integrated Services Digital Network na América do Norte e Japão enquanto que a
transformação A-LAW é usada na telefonia ISDN no restante do mundo.
Cada octeto G.711 é alinhado em um pacote RTP. O bit de sinal de cada octeto G.711
corresponde ao bit mais significativo do octeto em um pacote RTP (assumindo que as amostras
G.711 são manuseadas como octetos nas diversas arquiteturas de computadores existentes, o bit
de sinal deve ser o bit mais significativo do octeto na forma como é definido em cada arquitetura
de computador).
Uma descrição detalhada pode ser vista em [3-14].
3.9.3. G.723
É especificado na recomendação ITU G. 723.1. Foi definido pelo ITU-T H.324 GSTN para
aplicações de terminal de vídeo-fone. O algoritmo possui em seus anexos uma especificação de
ponto flutuante, supressão de silêncio e um esquema de codificação escalar a aplicações wireless.
O áudio é codificado em quadros de 30 ms com um atraso adicional de 7,5 ms (introduzidos
para uso futuro). Um quadro G.723.1 pode ter três tamanhos diferentes: 24 octetos, 20 octetos, ou
3. Real-Time Transport Protocol (RTP)
36
4 octetos. Os quadros de 4 octetos são chamados SID - Silence Insertion Descriptor, usados para
indicar quadros de silêncio (aplicações podem considerar a perda de pacotes contendo este tipo
de quadro como irrelevante). Os últimos dois bits menos significativos do primeiro octeto no
quadro determinam o tamanho do quadro e o tipo de codificador, conforme mostra a tabela 3.2.
Tabela 3.2. Diferentes Tamanhos de Quadros Especificados no Algoritmo G.723 [3-9]
Bits de identificação
Octetos / quadro
00
24
01
20
10
4
11
Este codificador foi otimizado para representar a fala com boa qualidade e pouca
complexidade.
A recomendação para áudio comprimido CCITT G.721 e a G.723 são ainda esquemas de
ADPCM para compressão interativa padrão de áudio compact disk [3-15, 3-16].
3.9.4. GSM
GSM - Group Special Mobile é o padrão Europeu GSM 06.10 ETS 300 961 para codificação de
voz. É baseado na RPE/LTP - Regular Pulse Excitation / Long Term Prediction, onde blocos de
160 amostras de áudio de 13 bits (260 octetos) são comprimidos em 33 octetos.
O RPE/LTP é um caso especial do sistema MPE-LPC - Multipulse-Excitation Linear
Predictive Coding. O MPE-LPC oferece uma boa qualidade de fala a taxas de 8 a 16 kbps. A
performance dos sistemas RPE é semelhante à obtida pelos codificadores MPE.
No empacotamento RTP, os bits são empacotados a partir do mais significativo.
3.9.5. MPEG-1 / MPEG-2
O algoritmo de compressão de áudio MPEG - Motion Picture Experts Group, tem a codificação
definida nos padrões ISO/IEC 11172-3 e 13818-3 e o encapsulamento especificado na RFC 2250
[2-17]. Permite a compressão de áudio com alta fidelidade.
Assim como
-Law e ADPCM, a compressão de áudio MPEG é uma compressão com
perda. Testes realizados mostraram que mesmo com uma taxa de compressão de 6 para 1 (áudio
estéreo de 16 bits por amostra a 48 kHz comprimidos) consegue-se alta fidelidade de reprodução
de clipes de áudio especialmente escolhidos pela dificuldade de compressão [3-18].
3. Real-Time Transport Protocol (RTP)
37
A alta performance deste algoritmo de compressão se deve à exploração de camuflagens
auditivas. Esta camuflagem explora a fraqueza do ouvido humano exposto a sinais fortes de áudio
que tornam os sinais fracos imperceptíveis. Este fenômeno de camuflagem do barulho foi
observado e comprovado através de experimentos psico-acústicos [3-19].
O espectro audível pode ser quebrado em bandas críticas, como mostra a tabela 3.3 abaixo,
que reflete a perspicácia do ouvido humano a determinadas freqüências. Sabe-se que o ouvido
humano percebe freqüências que variam entre 100 Hz e 20.000 Hz.
Tabela 3.3. Limite Aproximado de Bandas Críticas [3-12]
Número da Banda
Freqüência (Hz) *
Número da Banda
Freqüência (Hz)
00
50
14
1.970
01
95
15
2.340
02
140
16
2.720
03
235
17
3.280
04
330
18
3.840
05
420
19
4.690
06
560
20
5.440
07
660
21
6.375
08
800
22
7.690
09
940
23
9.375
10
1.125
24
11.625
11
1.265
25
15.375
12
1.500
26
20.250
13
1.735
* Limite superior da faixa de freqüência
A figura 3.10 mostra o diagrama de blocos para o codificador e decodificador de áudio
MPEG [3-20,3-21]. O stream de áudio de entrada passa filter bank, que representa um conjunto
de filtros cuja função é dividir a entrada em várias sub-bandas. Simultaneamente, o áudio de
entrada é submetido ao psychoacoustic model, um modelo psico-acústico [3-23,3-25,3-26,3-27],
que faz a associação do sinal a uma máscara para cada sub-banda. O bloco bit or noise allocation
determina quais sub-bandas são mais importantes que as outras de forma a minimizar a
audibilidade de determinadas freqüências. Por fim, o último bloco - bit stream formatting,
formata os dados em um stream de bits decodificável. Opcionalmente, ancillary data, ou seja,
dados auxiliares de áudio não necessariamente relacionados aos dados de áudio, podem ser
inseridos no stream de bits codificado.
3. Real-Time Transport Protocol (RTP)
38
O decodificador faz o inverso, reconstrói os valores quantificados para cada sub-banda para
em seguida transformar o conjunto de valores de sub-banda em um sinal de áudio. Dados
auxiliares são extraídos caso existam.
(a) Codificação de áudio MPEG
(b) Decodificação de áudio MPEG
Figura 3.10. Compressão e Descompressão de Áudio MPEG [3-12]
A codificação pode possuir três níveis de complexidade, denominados camada 1, 2 e 3. A
camada selecionada assim como a taxa de amostragem e a indicação do canal são encontradas no
payload. Áudio MPEG-1 suporta taxas de amostragem de 32; 44,1 e 48 kHz enquanto MPEG-2
suporta taxas de amostragem de 16; 22,05 e 24 kHz. O número de amostras por quadro é fixo,
mas o tamanho do quadro varia com a taxa de amostragem e a quantidade de bits por amostra.
Podemos ver pela tabela 3.1 que a API JMF 2.1.1e implementa MPEG-1 com taxa de
amostragem de 44.100 e 48.000 Hz e MPEG-2 com taxas de amostragem de 22.050 Hz.
Camada 1
Para a camada 1, o algoritmo usa um banco de filtros básicos encontrados em todas as
outras camadas. O banco de filtros divide o sinal de áudio em 32 bandas de freqüência constante.
Os filtros são relativamente simples e oferecem uma boa resolução de tempo com resolução de
freqüência razoável em relação à percepção do ouvido humano.
Possui três características principais:
Primeiro, as 32 bandas de comprimento de onda constante não refletem com precisão as
bandas críticas ao ouvido humano (tabela 3.3, acima). A figura 3.11 ilustra esta discrepância.
3. Real-Time Transport Protocol (RTP)
39
Podemos observar pela figura que o banco de filtros reflete com maior fidelidade as bandas
críticas ao ouvido humano de freqüências mais baixas;
Banco de Filtros de Banda para Áudio MPEG
Limites de Bandas Críticas
Figura 3.11. Limites de Bandas Críticas X Filtros de Banda para Áudio MPEG [3-12]
Segundo, o banco de filtros e seu inverso não são transformações sem perda. Contudo o erro
introduzido pelo banco de filtros é pequeno e inaudível;
Por fim, filtros de bandas adjacentes possuem uma sobreposição de freqüência significativa,
ou seja, um sinal em uma dada freqüência pode afetar dois bancos de filtros adjacentes.
O codificador formata os 32 grupos de 12 amostras em um quadro com 384 amostras. Além
dos dados de áudio, cada quadro contém um cabeçalho, um CRC - Cyclic Redundancy Code para
checagem de palavra, opcional, e possivelmente ancillary data com dados auxiliares.
Camada 2
Este algoritmo é uma melhora do definido na camada 1. Ele codifica dados em grupos mais
largos de forma a melhorar a performance da compressão, formando quadros de 3 grupos de 12
amostras de áudio para cada sub-banda (32 no total), em um total de 1.152 amostras por canal de
áudio.
Camada 3
É um algoritmo muito mais refinado que nas outras abordagens [3-22,3-23], embora
também seja baseado no mesmo banco de filtros encontrados nas duas outras camadas, a camada
3 compensa algumas deficiências do banco de filtros processando a saída dos filtros através de
uma transformação discreta conhecida como MDCT. A API JMF 2.1.1e não disponibiliza áudio
3. Real-Time Transport Protocol (RTP)
40
MPEG-3 devido a problemas legais embora já o tenha feito em versões anteriores. Mais
informações em [3-12].
4
IP Multicast
Neste capítulo é discutido o conceito de Multicast, necessário à distribuição de áudio
implementada nesta dissertação.
4.1. Apresentação
IP Multicast é uma extensão ao protocolo IP definida na RFC 1112 [4-1] cuja principal
funcionalidade é permitir a transmissão de datagramas IP de uma fonte para vários destinos em
uma LAN ou WAN. Com o uso do IP Multicast, aplicações enviam uma cópia da informação
para o endereço do grupo permitindo que todos os receptores que tenham interesse na informação
possam recebê-la. Cabe à rede fazer com que os pacotes endereçados ao grupo possam chegar às
sub-redes destinatárias e aos computadores específicos.
O padrão IP Multicast suporta milhares de usuários simultaneamente sem afetar
substancialmente a largura de banda disponível. Os protocolos de roteamento IP Multicast
oferecem entrega eficiente de datagramas IP destinados a qualquer número de participantes em
uma rede heterogênea e com uma quantidade muito grande de nós. Caso o hardware de rede
ofereça suporte multicast, então um único pacote destinado a vários participantes pode ser
entregue sem que haja necessidade várias cópias destinadas a cada participante.
4.2. Outros Tipos de Transmissão comparados à Multicast
Além do Multicast, há outros dois tipos fundamentais de endereços IPv4 associados a diferentes
mecanismos de transmissão:
Unicast, usado para transmitir um pacote a um único destino. Caso um nó queira enviar a
mesma informação para muitos destinatários, precisará enviar uma cópia do mesmo dado a
todos os destinatários. A mesma informação trafegará várias vezes pela rede e será gerada
repetidas vezes pelo transmissor consumindo além dos recursos de rede, capacidade de
processamento e a memória do transmissor;
4. IP Multicast
42
Broadcast, permite o envio de datagramas IP para toda uma sub-rede. Neste caso há apenas
um stream de dados que é entregue a cada estação membro da sub-rede;
Na trasmissão multicast, um computador não envia um tráfego a outro computador e sim a
um grupo. Isto é feito através do envio de tráfego a um endereço cuja localização física é dentro
de um roteador. Um cliente que deseje receber o stream multicast deverá informar ao roteador
que por sua vez replicará o dado a todos os participantes.
Enviar a informação apenas uma vez a um grupo de usuários gera uma economia muito
grande de largura de banda. Cópias da mensagem são feitas apenas onde os caminhos divergem
em outros roteadores que também precisam retransmiti-las para que cheguem até os clientes que
desejam recebê-las. Veja a figura 4.1 abaixo onde as transmissões Unicast e Multicast são
comparadas.
Figura 4.1. Comparação entre Multicast e Unicast
Membros de um grupo multicast podem estar presentes em qualquer ponto de uma rede que
tenha suporte a multicast. Computadores usam o IGMP - Internet Group Management Protocol
[4-1] para informar a roteadores, com suporte a multicast, quaisquer sessões multicast em que
desejem participar ou sair. Se todos os membros de uma sessão multicast em uma dada sub-rede
saírem do grupo, o roteador deixa de retransmitir os dados multicast para aquele segmento.
4. IP Multicast
43
4.3. Multicast em Diferentes Camadas
Multicast pode ser implementado tanto na camada de enlace de dados quanto na camada de rede
do modelo de referência OSI.
Na camada de enlace de dados além do Ethernet, possuem também suporte a multicast
outras tecnologias tais como FDDI e Token Ring. Caso a implementação de multicast seja restrita
a uma LAN, basta o suporte a multicast na camada 2.
Para que uma implementação multicast possa ultrapassar os limites de uma LAN, é
necessário que haja suporte a multicast na camada 3. Para tanto há a necessidade de se atentar
para o seguinte:
Tradução de endereços da camada 3 para a camada 2;
Registro dinâmico realizado pelo computador junto a um roteador para indicar que o
computador é membro de um dado grupo. Para tanto a RFC 1112 [4-1] define o protocolo
IGMP que especifica como um computador deve informar à rede que é membro de um dado
grupo;
Roteamento Multicast definido em vários padrões:
o A RFC 1075 [4-2] define o DVMRP - Distance Vector Multicast Routing Protocol;
o A RFC 1584 [4-3] define o Protocolo MOSPF - Multicast Open Shortest Path First que é
uma extensão ao OSPF com suporte a multicast;
o A RFC 2362 [4-4] define o Protocolo PIM-SM - Protocol Independent Multicast-Sparse
Mode;
o A Internet Draft [4-5] define o Protocolo PIM-DM - Protocol Independent Multicast-Dense
Mode.
4.4. Filtro Multicast nos Switchs
O comportamento padrão de um switch nível 2 seria retransmitir todo o tráfego multicast para
cada porta, porém isto fere o princípio de uso do switch que é retransmitir o tráfego apenas às
portas que de fato necessitam recebê-lo.
IP Multicast pode ser otimizado em uma LAN pelo uso de switchs com filtro multicast. Um
switch com suporte a multicast possui os mesmos benefícios que um roteador com suporte a
multicast só que dentro de uma LAN. O switch pode automaticamente configurar filtros multicast
4. IP Multicast
44
de tal forma que o tráfego multicast é retransmitido apenas às portas que possuem computadores
conectados que requisitaram participar da sessão, como mostra a figura 4.2 abaixo.
Figura 4.2. Filtro Multicast nos Switchs
IGMP Snooping é o método utilizado para tratar multicast de uma forma eficiente na
camada 2. Ele requer que os switchs em uma LAN examinem algumas informações da camada 3
nos pacotes IGMP enviados entre os computadores e o roteador. Quando o switch escuta o
relatório IGMP de um computador para um grupo multicast em particular, o switch adiciona o
número da porta em que o computador está associado à tabela multicast mantida por ele.
As mensagens de controle IGMP são transmitidas como pacotes multicast. Para os switchs
implementando IGMP Snooping não há maneira de distinguir na camada 2 quais pacotes são
mensagens IGMP dos que são dados multicast de tal forma que todos os pacotes de dados são
examinados para saber se há informações IGMP neles.
Esta análise pode provocar sérios
problemas de desempenho em alguns switchs com baixa capacidade de processamento quando a
4. IP Multicast
45
taxa de transmissão dos dados é alta. A solução é implementar IGMP Snooping em switchs com
hardware especial para checar os pacotes IGMP.
4.5. O Processo Multicast
O processo pelo qual um cliente recebe dados multicast oriundos de um servidor através de uma
rede com suporte a multicast é representado pelos seguintes passos esboçados na figura 4.3
adiante:
1.
O cliente envia uma mensagem IGMP join ao roteador. O endereço MAC de destino é
mapeado para o endereço classe D do grupo ao qual se deseja associar ao invés do endereço
MAC do roteador. O corpo do pacote IGMP também inclui o endereço classe D do grupo;
2.
O roteador registra a mensagem join e usa o protocolo PIM ou outro protocolo de
roteamento multicast para adicionar o segmento à árvore de distribuição multicast;
3.
O tráfego multicast transmitido a partir do servidor é agora distribuído pelo roteador para
a sub-rede cliente. O endereço MAC de destino corresponde ao endereço classe D do grupo;
4.
O switch recebe o pacote multicast e examina a sua tabela de retransmisão. Caso não
exista nenhuma entrada para o endereço MAC, o pacote será retransmitido para todas as
portas dentro do domínio broadcast. No caso de existir uma entrada na tabela do switch, o
pacote será retransmitido apenas para as portas necessárias;
5.
Com IGMP versão 2, o cliente pode sair do grupo multicast através do envio de uma
mensagem IGMP leave ao roteador. Na versão 1 do IGMP, o cliente permanece participando
do grupo até que ele falhe em retornar uma mensagem em resposta a uma consulta feita a ele
pelo roteador. Roteadores multicast enviam periodicamente consultas IGMP a todos os
computadores participantes do grupo multicast para determinar quais grupos ainda
permanecem ativos. Cada computador atrasa a resposta à consulta por um período pequeno e
aleatório. Este mecanismo previne congestionar a rede e a inundação do roteador com
respostas simultâneas
4. IP Multicast
46
Figura 4.3. Processo Multicast
4.6. Conceitos de Roteamento Multicast
O protocolo IP é o responsável por permitir que uma mensagem enviada a partir de uma sub-rede
chegue a um destino em outra sub-rede. Cada computador possui ao menos um endereço IP que o
identifica univocamente.
Os roteadores enviam periodicamente mensagens de atualização aos roteadores adjacentes
transportando o estado da rede conforme percebido por eles. Esta informação é armazenada em
tabelas de roteamento IP que são então utilizadas para determinar os caminhos mais adequados
para a retransmissão de mensagens através da rede.
Em unicast, o processo de direcionamento dos datagramas ao destino não é tão complexo
devido à localização física do destino ser identificada por um endereço simples.
Um endereço multicast identifica uma sessão de transmissão em particular ao invés de um
endereço físico específico. No roteamento multicast, os roteadores interagem uns com os outros
para trocar a informação a respeito dos roteadores vizinhos. Para evitar duplicação de esforços,
um único roteador é selecionado via IGMP como o roteador designado para cada sub-rede.
Para transmitir a informação multicast de forma eficiente os roteadores designados
constroem uma estrutura Spanning Tree que conecta todos os membros de um grupo IP multicast
de tal forma que há apenas um caminho, livre de loop, entre cada par de roteadores, conforme
4. IP Multicast
47
visto na figura 4.4 adiante. A construção da árvore de distribuição é para garantir que uma cópia
de cada pacote seja retransmitida para cada ponto terminal da árvore. Caso cada roteador conheça
qual de suas portas pertença à árvore, ele pode copiar um datagrama multicast de entrada para
cada ponto de saída gerando uma quantidade mínima de cópias, replicando os dados apenas onde
há bifurcação. Isto minimiza o número de mensagens que são transmitidas através da rede.
Uma vez que os grupos multicast são dinâmicos, onde os membros se associam ou
desassociam a qualquer momento, é também necessário para a árvore ser atualizada
dinamicamente. Galhos onde não há mais membros são cortados.
O algoritmo spanning tree usado e como os roteadores multicast interagem dependem de
cada protocolo de roteamento.
Figura 4.4. Efeito da Aplicação do Spanning Tree a uma Rede IP
Os algoritmos de roteamento multicast seguem uma de duas abordagens básicas:
Modo Denso (DM): assumem que os membros de grupos multicast estão densamente
distribuídos através da rede e que há alta largura de banda disponível. As árvores de
4. IP Multicast
48
distribuição DM são construídas pela inundação inicial da rede por inteiro para então cortar o
pequeno número de caminhos sem receptores. Entre os protocolos dessa categoria estão
incluídos: DVMRP - Distance Vector Multicast Routing Protocol [4-2], MOSPF - Multicast
Open Shortest Path First [4-3], e PIM-DM - Protocol Independent Mutlicast - Dense Mode
[4-5].
Modo Esparso (SM): Assume que há relativamente poucos roteadores na rede que estarão
envolvidos em cada sessão multicast e que a largura de banda é pequena. Os participantes do
grupo estão vastamente dispersos em WANs. Protocolos nessa categoria começam com uma
árvore de distribuição vazia e adicionam galhos apenas como resultado a requisições
explícitas de associação dos membros. É o caso do CBT - Core Based Trees [4-6] e PIM-SM
- Protocol Independent Multicast - Sparse Mode [4-4].
5
Infra-Estrutura de Transcodificação e
Aplicação para Distribuição de Áudio
Neste capítulo é apresentada a Infra-Estrutura de Transcodificação usada, explicitando as
responsabilidades básicas de transmissão, transcodificação e recepção implementadas,
descrevendo-se a Arquitetura de Classes e o Protótipo de Implementação, contribuições dessa
dissertação.
5.1. Transcodificador
Um transcodificador realiza a tarefa de mudar a codificação de um stream multimídia de origem
em um dado formato para um stream de destino em um formato mais adequado a trafegar na rede
ou a ser processado no receptor. A figura 5.1 abaixo ilustra a Infra-Estrutura de Transcodificação
implementada nesta dissertação.
A transcodificação é útil para que o stream de distribuição de dados multimídia possa
chegar até o receptor em um formato mais adequado seja para trafegar na rede ou para ser
processado em uma dada estação. As estações-fim podem ter diversas características
computacionais as mais variadas possíveis como clock do Processador (Hz), capacidade de
memória RAM (byte), dentre outras, conforme ilustra a tabela 5.1; a infra-estrutura de rede
também pode ser caracterizada por fatores diferentes como capacidade do enlace (bits/s), atraso
de propagação na rede (ms), variação estatística do atraso – jitter (ms), quantidade de pacotes
perdidos. Esta dissertação, focará apenas na adaptabilidade em relação aos estados da rede não
observando a adaptabilidade com relação à capacidade de processamento dos dispositivos
receptores (tabelas 5.1, 5.2 e 5.3).
A Infra-estrutura de transcodificação é definida em três partes como mostra a figura 5.1:
transmissor, transcodificador e receptor. É concebida de uma forma genérica para os diversos
tipos de aplicações multimídia, isto é, distribuição de áudio e vídeo ou aplicações de áudio e
vídeo conferências. Para as aplicações de distribuição de áudio e vídeo não haveria necessidade
de se ter o transmissor separado do transcodificador. Nas aplicações de áudio e vídeo
conferências, esta separação se faz necessária uma vez que dois participantes podem estar
5. Infra-Estrutura de Transcodificação e Aplicação para Distribuição de Áudio
50
transmitindo ao mesmo tempo enquanto vários outros apenas estão recebendo os streams
originados da conversação. A sincronização dos streams oriundos do transmissor em uma
conferência poderia ser feita no transcodificador que então distribuiria o stream sincronizado a
todos os participantes.
Transmissor
...
Não
Concorrente
...
Fonte do Stream RTP
Fonte do Stream RTP
Fonte do Stream RTP
MPEG/RTP 44.100 Hz
Transcodificador
...
...
MPEG/RTP 44.100 Hz
MPEG/RTP 22.050 Hz
GSM/RTP 8.000 Hz
Receptor
Cliente A
Sub-rede A
Cliente B
Sub-rede B
Cliente C
Sub-rede C
Figura 5.1. Infra-Estrutura de Transcodificação Utilizada nesta Dissertação
Tabela 5.1. Diferentes Configurações de Alguns Dispositivos Computacionais [5-1]
Dispositivos Velocidade do
Memória
Tamanho da Color Depth Caixas de
Cliente
Processador
RAM (MB)
tela (pixels)
(bit)
som
Estação de
2 GHz
512
1.600 x 1.024
32
Stereo
trabalho PC
1 GHz
256
1.024 x 768
24
Notebook
Stereo
PC
PDA
200 MHz
32
240 x 320
12
Mono
O tempo para codificar ou decodificar um stream multimídia é influenciado pela velocidade
do processador e pela disponibilidade de memória RAM. Os formatos de codificação possuem
diferentes características com relação ao poder computacional exigido pelos dispositivos
5. Infra-Estrutura de Transcodificação e Aplicação para Distribuição de Áudio
51
computacionais uma vez que são baseados em algoritmos de compressão diferentes, como
mostram as tabelas 5.2 e 5.3:
Tabela 5.2. Algoritmos de Compressão de Áudio [5-1]
Formato de
Taxa de
Bits por
Poder
Compressão de
Amostra
Amostra (bits) Computacional
Áudio
(kHz)
Exigido
G.711 (u-Law)
8
8
Baixo
G.721
8
8
Baixo
G.723
8
8
Baixo
DVI
8
4
Baixo
GSM 06.10
Baixo
MPEG-1 Layer 1
32, 44 e 48
16
Alto
MPEG-1 Layer 2
32, 44 e 48
16
Alto
MPEG-1 Layer 3
32, 44 e 48
16
Alto
Tabela 5.3. Algoritmos de Compressão de Vídeo [5-1]
Compressão de
Formato de Resolução
Poder Computacional
Vídeo
Exigido
H.261
CIF,QCIF
Baixo
H.263
CIF,QCIF,SQCIF,4CIF,16CIF Baixo
MPEG-1
352 x 240 pixels, 30 fps
Alto
MPEG-1
352 x 288 pixels, 25 fps
Alto
MPEG-2
720 x 480 pixels, 30 fps
Muito Alto
MPEG-2
1920 x 1080 pixels, 30 fps
Muito Alto
MPEG-4
Alto
Em [5-2] há maiores informações a respeito de algoritmos de compressão de áudio e vídeo.
Esta dissertação aborda apenas a distribuição de áudio, no entanto, trabalhos futuros podem
também envolver áudio e vídeo. O capítulo 7 aborda os formatos de codificação de áudio RTP
disponíveis na API JMF e usados nesta dissertação.
Heterogeneidade e Mobilidade dos Receptores
A heterogeneidade tanto de dispositivos quanto de suas conexões é um sério problema para
as comunicações multimídia.
Uma estação de trabalho PC conectada a uma LAN de 100 Mbps pode receber um vídeo no
formato MPEG sem maiores problemas; um notebook PC conectado a uma LAN sem fio pode
ter problemas para reproduzir este formato de vídeo pois esta não é uma conexão adequada. Um
5. Infra-Estrutura de Transcodificação e Aplicação para Distribuição de Áudio
52
PDA por sua vez não conseguirá reproduzir o vídeo pois o display é muito pequeno e a conexão
também pode não ser adequada.
A mobilidade dos clientes também é um outro problema. Os clientes podem mudar suas
conexões para outras redes congestionadas ou com largura de banda não apropriada [5-4].
Em [5-1] são descritos dois tipos de abordagens para o problema da heterogeneidade e
mobilidade: foco no servidor e foco na rede. A primeira, tem a vantagem da facilidade de
implementação e a desvantagem de que para cada novo formato multimídia disponibilizado, há
necessidade de espaço em disco para armazená-lo; diversos serviços de distribuição multimídia
na Internet implementam este tipo, permitindo ao próprio usuário selecionar o formato e o tipo de
conexão mais adequado. A segunda, usa o conceito de transcodificação, ideal para o problema da
heterogeneidade e mobilidade, onde há apenas um formato multimídia em disco que é convertido
para outros formatos de streams multimídia; a abordagem com foco na rede é mais flexível pois o
servidor armazena o dado multimídia em um único formato, no entanto tem a desvantagem de
uma maior complexidade.
Esta dissertação implementa o conceito de transcodificação, onde os receptores são
responsáveis pela adaptabilidade, selecionando o formato mais adequado às sub-redes em que
participam dentre as disponibilizadas pelo Transcodificador em diferentes sessões multicast.
5.2. Serviços da Infra-Estrutura de Transcodificação
Os três serviços básicos da infra-estrutura de transcodificação são: servidor, cliente e
transcodificador. Para aprimorar a infra-estrutura básica, realizando ainda a transparência de
localização em uma rede, [5-1] implementou os serviços de broker e lookup. Esta dissertação
implementa apenas a infra-estrutura básica. A figura 5.2, a seguir, ilustra a infra-estrutura de
transcodificação.
5. Infra-Estrutura de Transcodificação e Aplicação para Distribuição de Áudio
53
Servidor
Lookup
2
1
Transcodificador
4
5
7
8
3
Cliente
Broker
6
1. Transcodificador registra-se no lookup
Servidor Oferece streams multimídia ao transcodificador
Cliente Solicita serviço de transcodificação ao Broker
4. Broker busca localização do transcodificador no serviço de diretório
5. Lookup informa localização ao Broker
6. Broker informa localização do serviço ao cliente
7. Cliente acessa o transcodificador
8. Transcodificador oferece stream com formato de codificação mudado
2.
3.
Figura 5.2. Arquitetura de Serviços de Rede para Transcodificação de Streams Multimídia [5-1]
Servidor
Oferece streams multimídia seja para aplicações conversacionais ou de distribuição de
dados multimídia. Há vários protocolos que podem ser usados para distribuir o stream, por
exemplo: HTTP, FTP, RTP.
Transcodificador
Muda a codificação do stream multimídia de um formato para outro que seja mais
apropriado a trafegar na rede ou a ser processado no cliente. O transcodificador pode se registrar
no serviço de lookup com alguns atributos, tais como endereço, formatos suportados, localização,
entre outros. Em algumas implementações pode ser controlado pelo cliente que pode executar
qualquer das ações play, pause, stop, rewind ou fast forward no stream, quando disponível. Em
aplicações de distribuição de áudio e vídeo, o cliente apenas pode optar por receber os streams
atualmente transmitidos ou não (este é o caso da implementação realizada nesta dissertação).
5. Infra-Estrutura de Transcodificação e Aplicação para Distribuição de Áudio
54
Cliente
É um usuário final que requisita o stream e o reproduz. O cliente pode enviar informações
para o broker que lhe responde informando a localização do transcodificador após consultar o
serviço de lookup. Nesta dissertação a comunicação se dá diretamente entre o cliente e o
transcodificador (há transparência de distribuição mas não de localização).
Broker
Tem por finalidade encontrar a localização do transcodificador e retornar a informação para
o cliente. Ele encontra o transcodificador após realizar uma busca em um diretório armazenado
no serviço de lookup.
Lookup
É um serviço de diretório que armazena informações sobre transcodificadores. Uma vez que
o serviço de lookup é bastante crítico, é recomendado que uma rede tenha vários. O lookup
também não é implementado nesta dissertação.
5.3. Arquitetura e Implementação
Esta sessão apresenta a arquitetura de classes Java utilizada para a construção da infra-estrutura
de transcodicação usada pela aplicação para distribuição de áudio implementada nesta
dissertação.
A presente dissertação possui como principais contribuições a implementação de um
protótipo de software para entrega de áudio no ambiente de uma rede corporativa plana (com
apenas uma sub-rede) ou com várias sub-redes e a definição de uma infra-estrutura de
transcodificação, baseada em JMF, utilizada para a implementação do protótipo visto adiante.
Embora com modestos objetivos a princípio, tratando apenas a distribuição de áudio, o resultado
deste trabalho deve ser visto como parte de um processo que, se continuado, pode evoluir para
aplicações mais avançadas, uma vez que a arquitetura apresentada é genérica, que lidem também
com a distribuição de vídeo e ainda áudio e vídeo conferências. Uma vez distribuído como
software livre pode ser aproveitado por instituições públicas e privadas que necessitem de
aplicações semelhantes. Mencione-se ainda os custos bastante elevados para aquisição de
licenças de softwares comerciais que muitas vezes inviabilizam iniciativas governamentais,
5. Infra-Estrutura de Transcodificação e Aplicação para Distribuição de Áudio
55
principalmente em países em vias de desenvolvimento, para a popularização de serviços
característicos da Terceira Geração da Internet.
Um conceito chave implementado pela infra-estrutura de transcodificação é conhecido
como reflexão que pode ser entendida como a capacidade que uma determinada aplicação possui
para inspecionar e adaptar o seu comportamento automaticamente em resposta a ocorrência de
algum evento. Oferece o nível necessário de adaptação para as emergentes áreas de aplicações de
sistemas distribuídos, ou seja, multimídia e computação móvel [5-10].
A figura 5.3, apresenta o diagrama de classes UML [5-11,5-12] da infra-estrutura de
transcodificação proposta nesta dissertação, adaptado de [5-15]. Para um melhor entendimento
veja também a figura 5.1.
Figura 5.3. Diagrama de Classes da Infra-Estrutura de Transcodificação para
Distribuição de Áudio
Pela figura, pode-se identificar as camadas da Aplicação e da Infra-Estrutura de
Transcodificação e a existência de dois planos fundamentais:
5. Infra-Estrutura de Transcodificação e Aplicação para Distribuição de Áudio
56
Plano de Controle, implementado usando RMI - Remote Method Invocation [5-13], versão
Java de RPC - Remote Procedure Call, através das classes DelegateClient, CommClient,
CommServer, InterfaceControleCCS, Sessoes e Participantes - melhor explicitadas a seguir.
Utiliza-se ainda do protocolo RTCP/RTP [3-2], para a obtenção de informações a respeito de
perda de pacotes RTP que caracteriza situação de congestionamento.
Plano Multimídia, utiliza-se da API JMF que lida com o protocolo RTP e é implementado
pelas classes CommClient, AVReceiveClient, AVTransmit2, CommServer, AVReceive2,
Clone, AVTransmitClone.
5.3.1. Classes Identificadas
As classes identificadas de acordo com responsabilidades bem definidas associam-se a dois
grupos: as que assumem os papeis de transmissor, receptor ou agente-gerente de troca de sessão
para a sub-rede; e, as que implementam a transcodificação.
Transmissor, Receptor ou Agente-Gerente
de Troca de Sessão para a Sub-rede
Estas classes estão representadas em azul na figura 5.3. Suas responsabilidades são as
seguintes:
PlayerClientGui, permite ao usuário iniciar o serviço cliente, ou seja, transmissor ou
receptor. Faz a interface gráfica com o usuário apresentando as opções transmitir e finalizar
transmissão quando estiver transmitindo áudio ao transcodificador; e, escutar e finalizar
escuta quando se associar a uma das três sessões de áudio iniciadas pelo transcodificador;
CommClient, Possui funcionalidades tanto do transmissor, do receptor de áudio e do par
gerente-agente responsável pela troca de sessão multicast de recepção - em caso de
congestionamento – para toda a sub-rede IP da qual participa. Para a transmissão de áudio ao
Transcodificador, instancia a classe AVTransmit2. Quando recebe áudio de uma das três
sessões multicast iniciadas pelo Transcodificador, usa a classe AVReceiveClient.
CommClient guarda informações a respeito da sessão multicast da qual está recebendo áudio,
quando da recepção de áudio; recebe informações acerca do estado da recepção dos streams
de áudio, informado por DelegateClient, e troca a sessão multicast de recepção de áudio para
toda a sub-rede em caso de troca de estado, caso seja o gerente eleito para isso. Implementa
5. Infra-Estrutura de Transcodificação e Aplicação para Distribuição de Áudio
57
além do plano multimídia, recebendo ou enviando streams de áudio, o plano de controle pela
comunicação com CommServer usando a interface RMI, InterfaceControleCCS;
AVReceiveClient, responsável pela recepção dos streams de áudio RTP oriundos de uma das
três sessões de áudio multicast iniciadas pelo transcodificador;
AVTransmit2, é responsável pela transmissão do stream de áudio RTP ao transcodificador
que ao recebe-lo, inicia três sessões multicast de áudio RTP;
DelegateClient, recebe informações a respeito da quantidade de pacotes RTP perdidos e
jitter, repassadas por NetConditionsGui, realizando a troca de estado e informando a troca
para CommClient a fim de que seja providenciada a troca de sessão multicast de recepção
para toda a sub-rede (realizado apenas pelo receptor eleito como gerente de troca de sessão
para a sub-rede);
NetConditionsGui, repassa para DelegateClient as informações sobre as condições da rede
entre o receptor e o transcodificador, a saber: quantidade de pacotes perdidos e jitter.
Apresenta uma interface gráfica para o usuário com as estatísticas RTP coletadas por
RtpStats;
ClientConditions, é responsável por coletar informações Management Information Base –
MIBs através do protocolo Simple Network Management Protocol - SNMP a respeito do
estado do computador cliente, uso de memória RAM disponível e paginação, a fim de que
seja escolhida uma sessão de áudio mais apropriada às condições de processamento do
computador cliente. Esta funcionalidade não será implementada nesta dissertação uma vez
que a escolha da sessão de áudio se dará para todos os computadores existentes em uma subrede IP.
Transcodificador
As classes que assumem os papéis do transcodificador podem ser vistas em vermelho na
figura 5.3. Suas responsabilidades são as seguintes:
AudioDistributor, permite a inicialização do serviço transcodificador,
instancia
CommServer e uma interface gráfica para a indicação da inicialização do serviço;
CommServer, implementa todas as funcionalidades Multimídia do transcodificador, tanto
para o plano multimídia quanto para o plano de controle. Com relação ao primeiro, usa
AVReceive2 para receber os streams de áudio oriundos do Transmissor. Com relação ao
5. Infra-Estrutura de Transcodificação e Aplicação para Distribuição de Áudio
58
segundo, usa a classse Sessoes como repositório de informações acerca das sessões multicast
iniciadas, tais como endereço IP multicast, porta RTP, codificador de áudio RTP (disponível
na API JMF) usado na sessão multicast; usa a classe Participantes como repositório de subredes participantes, guardando informações tais como endereço IP da sub-rede, máscara de
sub-rede, endereço IP do gerente responsável pela troca de sessão RTP multicast de recepção
para toda a sub-rede e sessão multicast mais adequada. Por fim, registra o serviço RMI
acessado por CommClient no RMIRegistry, realizando a interface InterfaceControleCCS;
Participantes, é um repositório com informações a respeito de todas as sub-redes que estão
recebendo streams de áudio;
Participante, representa cada sub-rede recebendo áudio RTP multicast oriundo do
transcodificador. Guarda informações acerca do endereço IP da sub-rede, máscara de subrede, formato de áudio RTP (disponível na API JMF) associado à sub-rede dentre os três
disponíveis no repositório Sessoes, endereço IP do gerente responsável pela troca de sessão
RTP multicast de recepção para toda a sub-rede em caso de congestionamento;
Sessoes, repositório responsável por guardar informações a respeito de todas as três sessões
de áudio multicast iniciadas pelo transcodificador;
Sessao, guarda informação sobre cada sessão multicast RTP iniciada pelo transcodificador, a
saber: endereço IP multicast da sessão RTP, porta RTP, formato de áudio RTP disponível na
API JMF e usado na sessão multicast;
AVReceive2, é responsável pela recepção dos streams de áudio oriundos do transmissor e
pela criação de três objetos clone, cada um realizando a transcodificação do formato de áudio
recebido do transmissor para cada um dos três formatos de áudio RTP registrados para as
sessões encontradas no repositório Sessoes;
Clone, é o responsável de fato pela transcodificação do formato de áudio RTP recebido pelo
transcodificador, oriundo do transmissor, para as três sessões de áudio multicast (cada uma
com diferentes formatos de áudio) iniciadas pelo transcodificador e que deverão ser recebidas
pelos clientes ao longo da rede. Cada objeto Clone realiza a transcodificação para cada um
dos formatos de áudio RTP registrados no repositório Sessoes;
AVTransmitClone, é quem de fato transmite o stream de áudio já transcodificado para um
endereço multicast da rede. Cada objeto Clone possui o seu próprio objeto AVTransmitClone
para a efetivação da transmissão na rede IP.
5. Infra-Estrutura de Transcodificação e Aplicação para Distribuição de Áudio
59
5.3.2. Papéis Exercidos pelo Cliente
Conforme já citado nos tópicos anteriores, o lado cliente do modelo definido pode exercer três
papéis distintos: Transmissor; Receptor; e, Gerente - Agente para troca de sessão multicast da
sub-rede.
O Transmissor é qualquer dos clientes que inicia a transmissão de áudio ao
Transcodificador para que este o distribua a outros clientes nos formatos mais convenientes a
cada sub-rede IP. Pode haver apenas um transmissor por vez para este cenário de distribuição de
áudio. No entanto, cenários mais complexos como o de uma conferência de áudio podem se
utilizar do modelo definido.
O papel de Receptor é exercido por todos os outros clientes, à exceção do Transmissor (em
uma conferência, o Transmissor também seria um receptor dos membros que estivessem
transmitindo). Os clientes que estão em determinada sub-rede IP recebem áudio RTP em um
único formato mais adequado a toda a sub-rede IP. O Transcodificador é quem define qual
formato é mais adequado dentre os três registrados no repositório Sessoes, baseado nas
informações fornecidas pelo cliente - quando solicita recepção de áudio - a respeito da
capacidade do enlace entre o cliente e o Transcodificador. Todos os receptores recebem
estatíticas RTP e as apresentam ao usuário, no entanto cabe ao Gerente o papel de responder à
situações de congestionamento e controlar a troca de formato de recepção de áudio dos outros
receptores em sua sub-rede, através de broadcast detectado pelo agente presente nos outros
receptores, conforme especificado no capítulo 6.
Com relação ao par Gerente - Agente para a troca de sessão multicast para a sub-rede, o
papel de Gerente é assumido pelo primeiro cliente de uma dada sub-rede IP a solicitar do
Transcodificador os dados da sessão multicast para recepção de áudio. Ele tem por
responsabilidade estar atento às mudanças de estado informadas por DelegateClient e realizar a
troca de sessão de recepção de áudio para si próprio e controlar a troca de sessão, de uma forma
eficiente, de todos os outros receptores da sub-rede da qual é responsável – para isto é definido
um protocolo visto no Capítulo 6. Enquanto em uma dada sub-rede há apenas um Gerente, todos
os outros receptores têm um Agente ativo que escuta as mensagens broadcast enviadas para toda
a sub-rede pelo Gerente a fim de realizarem em conjunto a troca de sessão de recepção de áudio.
Toda esta negociação é explicitada no Capítulo 6.
5. Infra-Estrutura de Transcodificação e Aplicação para Distribuição de Áudio
60
A figura 5.4, ilustra as múltiplas funcionalidades do cliente, considerando apenas uma única
sub-rede onde os receptores esboçados se encontram. Em azul, são apresentados os papéis
exercidos pelo cliente; em vermelho, o Transcodificador. Observe ainda que os receptores
podem ter ativos o Gerente, em amarelo, ou o Agente, em verde. Os endereços IP mostrados são
apenas para indicar que o Transmissor, o Transcodificador e os Receptores podem estar em subredes IP diferentes.
Sub-rede 10.107.0.0/16
Transmissor
10.107.0.15
Streams de áudio
unicast RTP no
formato A
Sub-rede 10.109.0.0/16
Transcodificador
10.109.0.25
Streams de áudio
multicast RTP no
formato B
Sub-rede 192.168.0.0/24
Receptor
Gerente
192.168.0.10
Receptor
Agente
192.168.0.20
Receptor
Agente
192.168.0.30
Figura 5.4. Múltiplas Funcionalidades Assumidas pelo Cliente em uma dada Sub-rede
5.3.3. Casos de Uso Identificados e Situação de Implementação
Foram identificados basicamente quatro casos de uso [5-11,5-12]:
Transmitir ao Transcodificador;
Iniciar Sessões de Áudio no Transcodificador;
Receber Stream de Áudio RTP no Receptor;
Trocar a Sessão Multicast de Recepção.
Os diagramas de seqüência dos três primeiros são vistos adiante, estando especificados e
implementados. O quarto, envolve a definição de um protocolo para o controle da troca de sessão
5. Infra-Estrutura de Transcodificação e Aplicação para Distribuição de Áudio
61
multicast de recepção pelos clientes, encontra-se apenas especificado no capítulo 6 sendo a sua
implementação um trabalho futuro.
Transmitir ao Transcodificador
Representa a transmissão do stream de áudio RTP pelo Transmissor ao Transcodificador.
Uma vez iniciado o serviço Transcodificador (veja o diagrama de seqüencia na figura 5.5),
é iniciado o serviço Transmissor informando o endereço IP do Transcodificador, o endereço IP
do Transmissor e a porta UDP usada para a transmissão de pacotes RTP ao transcodificador – a
porta UDP usada para a transmissão e recepção de pacotes RTCP é dado pelo número da porta
RTP + 1.
PlayerClienGui cria um objeto denominado commClient, instância da classe CommClient,
passando como parâmetros o endereço IP do Transcodificador, o endereço IP do Transmissor e a
porta UDP usada para a transmissão de pacotes RTP.
O objeto commClient cria um objeto denominado at, instância da classe AVTransmit2,
passando como parâmetros a fonte do stream a ser transmitido, endereço IP do Transcodificador,
porta UDP usada para a transmissão de pacotes RTP e o formato de áudio a ser transmitido.
O usuário usa a interface Gui, clicando no botão transmite. O objeto instância da classe
PlayerClientGui invoca o método solicitaTransmissao() disponível em commClient que o faz
invocar o método transmite() disponível nele mesmo.
O objeto commClient invoca o método start() disponível em at, recebendo em seguida a
indicação de início de transmissão, Mensagem inicio transmissao.
O objeto commClient realiza a invocação RMI passando como parâmetros o endereço IP do
Transcodificador onde se encontra registrado o serviço RMI por nome ControleCommServer,
usando
o
método
informaTransmissao
disponível
no
objeto
commServer
no
lado
Transcodificador, passando como parâmetros o endereço IP do transmissor, a porta RTP usada
pelo transmissor e o formato de áudio transmitido para informar a commServer a transmissão de
áudio ao Transcodificador.
5. Infra-Estrutura de Transcodificação e Aplicação para Distribuição de Áudio
62
Figura 5.5. Diagrama de Seqüência do Caso de Uso Transmitir ao Transcodificador
Este caso de uso encontra-se implementado conforme ilustra a figura 5.6 a seguir, onde se
pode ver que uma sessão unicast para a transmissão de áudio RTP MPEG 48.000 Hz ao
Transcodificador é iniciada.
5. Infra-Estrutura de Transcodificação e Aplicação para Distribuição de Áudio
63
Figura 5.6. Inicialização do Serviço Transmissor
Iniciar Sessões de Áudio no Transcodificador
Este caso de uso representa o início das três sessões multicast de áudio RTP pelo
Transcodificador.
Após receber a invocação remota (RMI) de commClient, através do seu método
recebeTransmissao, passando como parâmetros Endereço IP e Porta UDP utilizada pelo
Transmissor, commServer - instância da classe CommServer, cria um objeto avReceive instância da classe AVReceive2, passando os mesmos parâmetros IP e Porta UDP. Veja o
diagrama de seqüência na figura 5.7.
A classe DataSource, melhor explanada no anexo A, é usada como premissa tanto para a
apresentação quanto para o processamento dos dados de áudio.
Uma vez avReceive inicializado, é invocado o método startClone(), disponível nele próprio
para iniciar o processo de criação dos três objetos clone necessários à transcodificação do stream
de áudio recebido do Transmissor. Para tanto, é necessário que o objeto dataSource, instância da
5. Infra-Estrutura de Transcodificação e Aplicação para Distribuição de Áudio
64
classe JMF DataSource, criado para a recepção do stream de áudio oriundo do transmissor seja
transformado em um objeto dataSource clonável com o auxílio da instancia de Manager.
Então, são criadas três instancias da classe Clone, clone1, clone2 e clone3 passando como
parâmetros para cada uma no ato da criação: o endereço IP multicast, a porta UDP, o formato de
áudio a ser utilizado na sessão e o dataSource clonável criado anteriormente e recriado para cada
objeto clone.
Cada objeto clone cria um objeto avt, instância de AVTransmitClone para a transmissão do
stream de áudio transcodificado na sessão multicast respectiva. Para isso os parâmetros endereço
IP multicast, porta UDP, formato de áudio e dataSource clonado são passados no ato da criação
do objeto. Após a invocação do método start() disponível em cada objeto avt, a transmissão do
stream de dados transcodificado na rede é iniciada para cada sessão multicast.
Figura 5.7. Diagrama de Seqüência do Caso de Uso Iniciar Sessões de Áudio no
Transcodificador
5. Infra-Estrutura de Transcodificação e Aplicação para Distribuição de Áudio
65
A figura 5.8, a seguir, mostra a inicialização do serviço Transcodificador e a inicialização
das três sessões de áudio multicast após recepção do stream de áudio RTP oriundo do
Transmissor.
Figura 5.8. Inicialização do Serviço Transcodificador e Criação das Três Sessões de Áudio RTP após
Recepção do Stream de Áudio Oriundo do Transmissor
5. Infra-Estrutura de Transcodificação e Aplicação para Distribuição de Áudio
66
Receber Stream de Áudio RTP no Receptor
Representa a recepção do stream de áudio RTP no Receptor, oriundo de uma das três
sessões multicast de áudio iniciadas pelo Transcodificador.
O diagrama de seqüência é esboçado na figura 5.9.
A recepção do stream de áudio RTP de uma das sessões de áudio iniciadas pelo
transcodificador é realizada pela instância da classe AVReceiveClient.
Um objeto dataSource é recuperado de stream, instancia da classe ReceiveStream, através
da invocação do método getDataSource, disponível neste.
O objeto dataSource recuperado é então utilizado para a criação de um objeto p, instância
de Player. Isto é realizado com o auxílio de uma instância de Manager, através da invocação de
seu método createPlayer, passando como parâmetro o objeto dataSource recuperado
anteriormente.
A seguir é instanciado um objeto pw, instancia de PlayerWindow, passando como
parâmetros os objetos p e stream. O objeto pw é utilizado para apresentar ao usuário uma
interface gráfica que lhe permita pausar e iniciar a recepção de áudio e ver detalhes da recepção,
como mostra a figura 5.10.
5. Infra-Estrutura de Transcodificação e Aplicação para Distribuição de Áudio
67
Figura 5.9. Diagrama de Seqüência do Caso de Uso Receber Stream de Áudio RTP no
Receptor
A figura 5.10, apresenta o Receptor recebendo stream de áudio RTP de uma das sessões
multicast iniciadas pelo Transcodificador após solicitar ao Transcodificador informações da
sessão mais adequada. Note a janela que apresenta as estatísticas de recepção.
5. Infra-Estrutura de Transcodificação e Aplicação para Distribuição de Áudio
68
Figura 5.10. Recepção e Apresentação do Stream de Áudio RTP de uma das Sessões de Áudio
Multicast Iniciadas pelo Transcodificador
6
Protocolo para Controle de Sessão no
Transcodificador e Troca de Sessão nos Receptores
O controle de sessão no transcodificador e a ocorrência da troca de sessão nos receptores, como
uma resposta de adaptação a condições da rede, não é uma operação trivial. O objetivo deste
capítulo é especificar um protocolo que implemente esta adaptação de forma menos onerosa à
rede. A validação deste protocolo através de sua implementação na infra-estrutura de
transcodificação será um trabalho futuro.
6.1. Entendendo o Problema
Nesta dissertação, o transcodificador implementa 3 sessões multicast, conforme visto no capítulo
5. Cada uma tem a responsabilidade de atender a determinado perfil de usuário levando em conta
o estado da rede (perda de pacotes, jitter, capacidade do enlace, vazão da sessão). Desta forma,
temos implementado, os seguintes formatos de codificação de áudio distribuídos nas sessões
multicast respectivas, conforme visto no capítulo 5 e analisado no capítulo 7, como mostra a
tabela 6.1
Tabela 6.1. Formatos de Áudio RTP por Sessão Multicast e suas Vazões Médias
Descrição
Formato de Áudio
Sessão 3
mpegaudio/rtp, 48000.0 Hz,
16-bit, Mono
Sessão 2
Sessão 1
Sessão Multicast
Vazão Média
(bps) das sessões
RTP *
65.686,53
IP: 239.224.222.222
Porta: 22224
mpegaudio/rtp, 22050.0 Hz,
32.926,9
IP: 239.222.222.222
16-bit, Mono
Porta: 22222
gsm/rtp, 8000.0 Hz, Mono,
15.093,26
IP: 239.220.222.222
FrameSize=264 bits
Porta: 22220
* Coletadas na análise realizada no capítulo 7
Nas figuras 6.1 e 6.2 a seguir, temos um cenário ilustrativo da complexidade do problema.
Observe na figura 6.1 que os clientes 10.107.0.1/16, 10.107.0.2/16 estão associados à sessão
multicast 2 e os outros clientes nas sub-redes 10.108.0.0/16 e 10.109.0.0/16 associados à sessão
multicast 3. O Transcodificador tem o controle de qual sessão multicast é a mais apropriada para
determinada sub-rede em um dado instante, conforme critérios definidos adiante. O problema a
6. Protocolo para Controle de Sessão no Transcodificador e Troca de Sessão nos Receptores
70
ser solucionado refere-se a como ocorrerá a troca de sessão em todos os receptores de uma dada
sub-rede em resposta a um estado de congestionamento ou em sua ausência. A idéia é que diante
de uma situação de congestionamento todos os receptores de uma dada sub-rede passem a receber
áudio de uma sessão que consuma menos os recursos da rede. Da mesma forma, na ausência de
congestionamento, ocorre a troca para um formato de codificação que tenha uma maior qualidade
de recepção embora consumindo mais recursos da rede.
A figura 6.2 ilustra uma situação de congestionamento detectado pelo Receptor
10.107.0.1/16 que imediatamente solicitou ao Transcodificador mudança na sessão de áudio de 2
para 1, ou seja de mpegaudio/rtp, 22050.0 Hz para gsm/rtp, 8000.0 Hz – menos oneroso a rede.
Ocorre que em dado instante, poderá acontecer que 2 receptores na sub-rede 10.107.0.0/16
recebem áudio em formatos diferentes complicando ainda mais a situação de congestionamento.
É preciso que todos os receptores em uma dada sub-rede passem a receber o áudio no formato
mais econômico para a rede e que esta convergência ocorra no menor tempo possível. Os tópicos
a seguir tentam resolver este problema.
Neste capítulo estamos abstraindo a existência de multicast, disponível nas camadas
inferiores dois e três, e seus mecanismos de join group e leaving group. Este tópico é abordado
no capítulo 4. Por hora o receptor ao enviar uma solicitação de troca de sessão ao
transcodificador, também envia uma solicitação IGMP leave group ao roteador. Todos os outros
receptores de uma dada sub-rede também enviam solicitações IGMP leave group após receberem
a mensagem do receptor que controla a sub-rede.
6. Protocolo para Controle de Sessão no Transcodificador e Troca de Sessão nos Receptores
71
Figura 6.1. Cenário Ilustrativo da Adaptabilidade dos Receptores e Controle do Transcodificador
Figura 6.2. Cenário Ilustrativo do Problema da Adaptabilidade dos Receptores e Controle do
Transcodificador em Situação de Congestionamento
6. Protocolo para Controle de Sessão no Transcodificador e Troca de Sessão nos Receptores
72
6.2. Associação da Sessão Multicast mais Adequada dada a Informação da Capacidade do
Enlace
A vazão de um dado formato de codificação não pode ser maior que 50% da capacidade do
enlace. O Receptor ao solicitar a distribuição de uma sessão multicast informa o valor do enlace
mais adequado ao Transcodificador que então guarda esta informação para toda a sub-rede onde
o Receptor se encontra. Novos receptores ao solicitarem a distribuição de áudio ao
Transcodificador irão receber da sessão já definida para a sub-rede em questão.
A tabela 6.2 abaixo associa os formatos de codificação de áudio mais adequados às
capacidades de enlace. A escolha dos formatos de áudio na tabela abaixo, é apenas uma entre
outras possibilidades resultantes da análise realizada no capítulo 7.
Tabela 6.2. Formatos de Codificação mais Adequados às Capacidades de Enlace
Formato de Codificação de Áudio
Capacidade do
mpegaudio/rtp,
mpegaudio/rtp,
gsm/rtp, 8000.0 Hz, Mono,
Enlace Kbps
48.000 Hz, 16-bit,
22.050 Hz, 16-bit,
FrameSize=264 bits
Mono
Mono
< 64
64 < 128
> 128
Como mostra a tabela 6.2, podemos observar que para enlaces menores que 64 Kbps o
Transcodificador apenas associará o formato gsm/rtp 8.000 Hz. Para enlaces entre 64 e 128 Kbps,
poderão ser associados os formatos mpegaudio/rtp, 22050.0 Hz e gsm/rtp 8.000 Hz. Por fim, para
os enlaces maiores que 128 Kbps os três formatos de áudio poderão ser associados.
A
adaptabilidade obedece então ao definido nesta tabela.
6.3. Eleição do Responsável pelo Controle de Troca de Sessão para uma dada Sub-rede
Para evitar o problema esboçado na figura 6.2, onde vemos que a sub-rede pode ficar ainda mais
congestionada caso apenas um receptor se adapte e os outros não, situação em que a sub-rede em
questão recebe streams de duas sessões de áudio RTP - piorando a situação de congestionamento,
é necessário que se defina um receptor em cada sub-rede que será o responsável pelo controle de
troca de sessões como passamos a explicitar.
A forma adotada nesta dissertação, é bem simples. O primeiro receptor de uma sub-rede
será o responsável pelo controle da troca de sessão em caso de congestionamento ou em sua
ausência. Antes de qualquer troca de sessão, o receptor responsável, dito Gerente, emite um
6. Protocolo para Controle de Sessão no Transcodificador e Troca de Sessão nos Receptores
73
broadcast em sua sub-rede durante um período de 1 segundo solicitando aos seus pares, ditos
Agentes, finalizarem a recepção de áudio, conforme esboçado na figura 6.3. Após os seus pares
terem finalizado a recepção, o Gerente realiza a solicitação de troca de sessão conforme descrito
nos itens 6.4 e 6.5 adiante. Feito isto, o próximo passo realizado pelo Gerente é emitir um
broadcast para todos os Agentes, informando a nova sessão de recepção. Para evitar eventuais
perdas de pacotes UDP, este broadcast é repetido pelo intervalo de 1 segundo. A partir deste
ponto, todos os receptores de uma dada sub-rede estarão recebendo streams de áudio em um
formato mais adequado às condições da rede para um dado instante.
Figura 6.3. Receptores Gerente e Agente para Troca de Sessão em uma dada Sub-rede
Tabela 6.3. Quadro de Mensagens Oriundas do Gerente para os Agentes em uma Sub-rede
Mensagem
Finaliza Recepção
Informa Sessão Escuta
Inicializa Recepção
Parâmetros
Nova Sessão Multicast, porta RTP
-
As mensagens explicitadas na tabela 6.3 têm por origem o Gerente e por destino os Agentes
em uma dada sub-rede. A repetição no envio destas mensagens por um período de um segundo,
6. Protocolo para Controle de Sessão no Transcodificador e Troca de Sessão nos Receptores
74
conforme citado anteriormente, tem por objetivo evitar eventuais perdas de pacotes que não são
corrigidas pelo protocolo de transporte UDP usado.
6.4. Troca de Sessão em caso de Congestionamento
Em situações de congestionamento, a troca de sessão para uma dada sub-rede ocorrerá
observando o disposto na figura 6.4 abaixo. Estas sessões já foram definidas na tabela 6.1. A
troca de sessão, conforme explicitado no item 6.3 anterior é de responsabilidade de apenas um
receptor encarregado de trocar a sessão para toda a sua sub-rede, denominado Gerente.
Sessão 3
Sessão 2
Sessão 1
Figura 6.4. Troca de Sessão em Caso de Congestionamento
Assim, caso o Receptor responsável pela sua sub-rede esteja na sessão 3 passará para a
sessão 2; caso esteja na sessão 2 passará para a sessão 1. O Transcodificador, por sua vez
registrará a nova sessão para toda a sub-rede do Receptor em questão, de tal forma que novos
receptores dessa sub-rede que venham a solicitar do Transcodificador uma sessão para recepção
passarão a receber streams em um formato mais adequado para determinado instante.
A troca de sessão em caso de congestionamento, melhor discutida no item 6.3 acima, é
especificado pelo diagrama de seqüência UML [5-11,5-12] da figura 6.5 e pelo algoritmo do item
6.6.
6. Protocolo para Controle de Sessão no Transcodificador e Troca de Sessão nos Receptores
75
Figura 6.5. Diagrama de Seqüência para Troca de Sessão pelo Receptor Gerente em
Situação de Congestionamento
6.5. Troca de Sessão na Ausência de Congestionamento
Na ausência de congestionamento, sem informações a respeito da utilização da largura de banda,
o Receptor Gerente tentará melhorar a qualidade da recepção nos próximos 10 minutos. Caso
detecte congestionamento mais uma vez diminuirá a qualidade da recepção e esperará o dobro
para a próxima tentativa. Isto se repetirá até o limite de 1 hora. A partir da quarta tentativa de
adaptação, o receptor esperará 1 hora para realizar nova tentativa.
Neste caso vale o mesmo diagrama já definido na figura 6.5, mudando apenas a mensagem
enviada por DelegateClient que informaria ausência de congestionamento.
6. Protocolo para Controle de Sessão no Transcodificador e Troca de Sessão nos Receptores
76
6.6. Algoritmo de Adaptabilidade do Receptor Gerente
Em [6-1] é definido um algoritmo adaptativo para redes wireless que também é baseado em
coleta de estatísticas de sessões RTP. O algoritmo que hora apresentamos é uma adaptação
daquele, conforme ilustra a figura 6.6.
Figura 6.6. Algoritmo de Adaptabilidade do Receptor Gerente
O Transcodificador (figura 5.3 do Capítulo 5), através das sessões RTP iniciadas pelos 3
objetos instanciados da classe AVTransmitClone, envia periodicamente relatórios RTCP SR para
6. Protocolo para Controle de Sessão no Transcodificador e Troca de Sessão nos Receptores
77
todos os receptores de cada uma das sessões multicast por ele mantidas. Cada Receptor recebe o
stream de áudio RTP através da instância da classe AVReceiveClient enquanto que a instância de
NetConditionsGui (através de RtpStats) é a responsável por coletar e mostrar as estatísticas
RTCP que então são informadas a DelegateClient. Caso o percentual de pacotes perdidos tenha
sido maior que 3% desde o último relatório SR recebido, então DelegateClient solicita a
CommClient no Receptor Gerente a diminuição da qualidade de recepção. Caso este percentual
de perda não tenha sido maior que 3%, então é verificado se a qualidade da recepção poderia ser
melhor (de acordo com a capacidade do enlace informada, conforme tabela 6.2) e se o tempo
desde a última tentativa de melhora de qualidade não expirou (conforme visto no item 6.5),
situação em que será realizada uma nova tentativa de melhora da qualidade de recepção. Se esta
nova tentativa apresentar insucesso, então o tempo para a nova tentativa será incrementado até o
limite de 1 hora (item 6.5). Podemos notar ainda pelo algoritmo que pacotes RTCP perdidos
também indicam situação de congestionamento de tal forma que após 3 pacotes SR terem sido
perdidos consecutivamente, a qualidade de recepção é diminuída.
7
Análise dos Formatos de Áudio RTP para a Infra-estrutura
de Transcodificação
Neste capítulo, são analisados os formatos de áudio RTP, disponíveis na API JMF 2.1.1e no
ambiente de uma rede corporativa com suporte a multicast nas camadas 2 e 3, sem tráfego de
background, usando-se a implementação realizada.
Apresenta-se inicialmente os formatos de áudio RTP disponibilizados em cada uma das
sessões pelo Transcodificador. Os formatos de áudio são escolhidos, dentre outras possibilidades
analisadas ainda no capítulo, de acordo com os requisitos da aplicação de distribuição de áudio e
vazão dos streams.
Deixa-se a validação da adaptabilidade especificada para a Infra-Estrutura de
Transcodificação com a implementação desta funcionalidade e realização de testes com
diferentes filas de priorização de pacotes no Linux, conforme discutido no Apêndice B, como um
trabalho futuro.
7.1. Cenário Utilizado
A análise levou em conta o ambiente de uma Rede local comutada, sem tráfego de background,
conforme ilustra a figura 7.1, adiante.
Como podemos observar, os computadores que hospedam o Receptor e o Transcodificador
encontram-se respectivamente conectados aos switchs de borda IBM 8271 e Cisco 1924. Estes,
por sua vez, possuem uplinks de 100 Mpbs para o switch de distribuição IBM 8277 onde é
implementada a VLAN 107 e onde ocorre o roteamento de pacotes entre VLANs diferentes.
Tanto o Transcodificador quanto o Receptor possuem um Processador Pentium IV 1,2 GHz e 256
Mbytes de memória RAM. O sistema operacional usado é Windows XP.
O Transcodificador inicia uma sessão de 20 minutos de áudio com o Receptor. O buffer do
receptor é configurado em 350ms, suficiente para evitar sensação de retardo em aplicações de
áudio-conferências e evitar sensação de perda de segmentos de áudio na aplicação de distribuição
devido ao jitter. As estatísticas são coletadas fim-a-fim, aproveitando-se da implementação do
RTP disponível na API JMF. O RTP, conforme visto no Capítulo 3, além do transporte dos dados
7. Análise dos Formatos de Áudio RTP para a Infra-estrutura de Transcoficação
79
de áudio, possui um outro protocolo denominado RTCP, responsável pelo transporte de
informações de controle, tais como perda de pacotes, quantidade de pacotes recebidos,
quantidade de bytes recebidos, jitter (variação estatística do atraso de pacotes), dentre outras
informações.
VLAN 107
Switch de Distribuição
Switch IBM 8277
(10.107.100.1
255.255.0.0)
100 Mbps
100 Mbps
Switchs de Borda
...
Switch IBM 8271
(10.107.200.8
255.255.0.0)
...
Switch Cisco 1924
(10.107.200.7
255.255.0.0)
10 Mbps
...
10 Mbps
Receptor
(10.107.2.125
255.255.0.0)
Transcodificador
(10.107.2.156
255.255.0.0)
Figura 7.1. Cenário Utilizado na Análise
No Receptor foram coletadas informações, através dos relatórios RTCP, a respeito da
quantidade de pacotes RTP e RTCP recebidos, percentual de pacotes RTP perdidos, quantidade
de pacotes RTP perdidos, quantidade de bytes recebidos, jitter e calculada a vazão; é deixado
como trabalho futuro o cálculo do atraso. Estas informações são úteis para a mudança de estado
do Receptor que desencadeará a mudança do formato de recepção de áudio, através da mudança
sincronizada de sessão para todos os receptores de uma dada sub-rede IP, a fim de promover a
adaptabilidade necessária a todo um segmento da rede quando as condições não forem as mais
adequadas.
Nas análises realizadas, não houve repetições do experimento, cálculo do intervalo de
confiança, uma vez que os dados são reais.
7. Análise dos Formatos de Áudio RTP para a Infra-estrutura de Transcoficação
80
Os formatos de áudio RTP analisados, disponíveis na API JMF em sua versão 2.1.1.e são
explicitados na tabela 7.1, onde está indicado aqueles que estão associados a quais sessões de
distribuição de áudio mantidas no Transcodificador e quais são possíveis candidatos.
Tabela 7.1. Formatos de Áudio RTP e as Sessões Mantidas pelo Transcodificador
Descrição dos Formatos de Áudio
dvi/rtp, 8000.0 Hz, 4-bit, Mono
dvi/rtp, 11025.0 Hz, 4-bit, Mono
dvi/rtp, 22050.0 Hz, 4-bit, Mono
uLAW/rtp, 8000.0 Hz, 8-bit, Mono, FrameSize=8 bits
g723/rtp, 8000.0 Hz, Mono, FrameSize=192 bits
Gsm/rtp, 8000.0 Hz, Mono, FrameSize=264 bits
mpegaudio/rtp, 48000.0 Hz, 16-bit, Mono
mpegaudio/rtp, 44100.0 Hz, 16-bit, Mono
mpegaudio/rtp, 22050.0 Hz, 16-bit, Mono
Implementado
Candidato
Candidato
Candidato
Candidato
Candidato
Sessão 1
Sessão 3
Candidato
Sessão 2
7.2. Análise dos Formatos de Áudio RTP para as Sessões Multicast da Infra-estrutura de
Transcodificação Proposta
Nesta sessão são analisados os formatos de áudio RTP para as 3 sessões multicast de distribuição
de áudio implementadas no Transcodificador, parte da Infra-estrutura de Transcodificação
proposta.
As análises levam em conta a vazão, o jitter, a quantidade de bytes, e a quantidade de
pacotes RTP e RTCP recebidos no receptor, conforme visto nos tópicos a seguir.
Vazão
A figura 7.2 abaixo ilustra as vazões em bits/s coletadas para os formatos RTP GSM
8.000Hz, sessão 1 do Transcodificador e representado pela cor vermelha; RTP MPEG 22.050Hz,
sessão 2 do Transcodificador, ilustrado na cor azul; e, RTP MPEG 48.000Hz, sessão 3 do
Transcodificador, mostrado na cor verde. A associação de quais sessões poderiam estar
associadas dada a informação de restrição de capacidade do enlace é vista no item 6.2 do
capítulo 6.
As vazões máxima média e mínima coletadas para RTP GSM 8.000Hz foram
respectivamente 18.648 bits/s; 15.093,26 bits/s; e, 9.768 bits/s. Para o formato RTP MPEG
22.050Hz, a máxima apresentou 41.440 bits/s; média de 32.926,9 bits/s; e, mínima de 20.320
7. Análise dos Formatos de Áudio RTP para a Infra-estrutura de Transcoficação
81
bits/s. Por fim, RTP MPEG 48.000Hz apresentou máxima de 87.040 bits/s; média de 65.686,53
bits/s e mínima de 54.400 bits/s.
Legenda
+++ GSM 8.000Hz
xxx MPEG 22.050Hz
... MPEG 48.000Hz
Figura 7.2. Vazões Observadas para as Sessões Multicast Mantidas pelo Transcodificador
Jitter
A variação do tempo médio entre a chegada de pacotes se chama jitter (item 3.7.2 e
Apêndice A). O tempo médio entre a chegada de pacotes RTP deve variar de maneira suave a fim
de que a reprodução do áudio no receptor possa ocorrer sem distorções. Para poder eliminar o
jitter o tamanho do buffer que alimenta a aplicação destino deve variar de maneira diretamente
proporcional ao tempo médio entre a chegada de pacotes. Neste experimento, conforme já
mencionado, o buffer do receptor possui um tamanho de 350 ms.
Da mesma forma que para a vazão, também foram coletadas informações a respeito do jitter
(valores máximo e médio) para os formatos de áudio das sessões multicast mantidos pelo
Transcodificador, vistos neste item, e para os demais, vistos no item seguinte, mostrados na
tabela 7.1.
O comportamento do jitter é ilustrado na figura 7.3. Em vermelho pode-se observar o
formato RTP GSM 8.000Hz que apresentou valores máximo de 7,980347 ms e médio de
7. Análise dos Formatos de Áudio RTP para a Infra-estrutura de Transcoficação
82
7,531637 ms. Em azul, tem-se o formato RTP MPEG 22.050Hz que apresentou valores máximo
de 95,7489 ms e médio de 84,65772 ms. O formato RTP MPEG 48.000Hz pode ser visto em
verde e apresentou valores máximo de 81,25305 ms e médio de 74,54516 ms.
Os altos valores do jitter observados para os formatos de áudio RTP MPEG podem ser
explicados pela complexidade do algoritmo de codificação e decodificação, conforme visto no
item 3.9.5; pelo comportamento do sistema de coleta de lixo, usado em Java; pelo tamanho e
quantidade dos pacotes RTP que não seguem o intervalo de criação padrão de 20 ms observado
nos outros formatos, conforme visto na tabela 3.1 do Capítulo 3 e observado nas análises
realizadas sobre a quantidade de Bytes e pacotes RTP recebidos, adiante. JVMs geralmente
gastam de 15 a 20 por cento de seu tempo com o sistema de coleta de lixo [7-1]. Em [7-2] são
realizados experimentos com áudio e vídeo em aplicações desenvolvidas em Java interpretado
pela JVM, Java compilado através de compiladores JIT - Just in Time e C++ observando-se
valores de jitter mais baixos para aplicações C++.
Para aplicações de áudio-conferência, seria mais indicado os formatos de áudio que
apresentaram valores de jitter mais baixos uma vez que o tamanho do buffer do receptor precisa
ser abaixo de 500 ms para que não seja experimentada a sensação incômoda de atraso na
propagação do áudio. Para aplicações de distribuição e reprodução de áudio o alto valor do jitter
pode ser compensado por um tamanho de buffer do receptor grande, i.e. maior que 500 ms, sem
problema para a qualidade da reprodução do áudio.
7. Análise dos Formatos de Áudio RTP para a Infra-estrutura de Transcoficação
83
Legenda
+++ GSM 8.000Hz
xxx MPEG 22.050Hz
... MPEG 48.000Hz
Figura 7.3. Jitter Observado para as Sessões Multicast Mantidas pelo Transcodificador
Quantidade de Bytes, Pacotes RTP e RTCP
A quantidade de bytes, pacotes RTP e RTCP recebidos no destino após os 20 minutos de
análise podem ser vistas respectivamente nas figuras 7.4, 7.5 e 7.6 a seguir. Em vermelho,
observa-se o formato RTP GSM 8.000Hz; em azul, vê-se o formato RTP MPEG 22.050Hz; e, em
verde tem-se o formato RTP MPEG 48.000Hz.
O formato RTP GSM 8.000Hz acusou 2.263.989 bytes recebidos, 20.470 pacotes RTP e
243 pacotes RTCP. O formato RTP MPEG 22.050Hz registrou 4.939.035 bytes, 4.124 pacotes
RTP e 249 pacotes RTCP. Já o formato RTP MPEG 48.000Hz apresentou 9.852.980 bytes, 7.488
pacotes RTP e 257 pacotes RTCP.
A quantidade de pacotes de controle, RTCP, é praticamente a mesma para os três formatos.
O formato RTP GSM 8.000Hz apresentou uma quantidade maior de pacotes RTP
comparativamente aos outros dois formatos MPEG, valor explicado pelo tamanho aproximado de
110 bytes do pacote RTP; o formato RTP MPEG 48.000Hz apresentou uma quantidade maior de
pacotes RTP, com aproximadamente 1.315 bytes por pacote, em relação ao formato RTP MPEG
22.050Hz, com aproximadamente 1.197 bytes por pacote.
7. Análise dos Formatos de Áudio RTP para a Infra-estrutura de Transcoficação
84
Os valores observados para a quantidade de bytes por pacote RTP, aliado a complexidade
do algoritmo de codificação e decodificação MPEG, explicam os altos valores de jitter
registrados. Da mesma forma, a quantidade pequena de bytes por pacote e a simplicidade do
algoritmo de codificação e decodificação GSM explicam o baixo valor do jitter mensurado.
Legenda
+++ GSM 8.000Hz
xxx MPEG 22.050Hz
... MPEG 48.000Hz
Figura 7.4. Quantidade de Bytes Recebidos das Sessões Multicast Mantidas pelo
Transcodificador
7. Análise dos Formatos de Áudio RTP para a Infra-estrutura de Transcoficação
85
Legenda
+++ GSM 8.000Hz
xxx MPEG 22.050Hz
... MPEG 48.000Hz
Figura 7.5. Pacotes RTP Recebidos das Sessões Multicast Mantidas pelo Transcodificador
Legenda
+++ GSM 8.000Hz
xxx MPEG 22.050Hz
... MPEG 48.000Hz
Figura 7.6. Pacotes RTCP Recebidos das Sessões Multicast Mantidas pelo Transcodificador
7. Análise dos Formatos de Áudio RTP para a Infra-estrutura de Transcoficação
86
7.3. Análise dos Formatos de Áudio RTP Candidatos às Sessões Disponibilizadas pelo
Transcodificador
Nesta sessão são analisados os formatos de áudio RTP candidatos às sessões multicast
disponibilizadas pela Infra-Estrutura de Transcodificação proposta.
Da mesma forma que na sessão anterior, as análises levam em conta a vazão, o jitter, a
quantidade de bytes, a quantidade de pacotes RTP e RTCP recebidos no receptor, conforme visto
a seguir.
Vazão
A figura 7.7 ilustra as vazões observadas para os formatos candidatos às sessões multicast
mantidas pelo Transcodificador, a saber: RTP DVI 22.050Hz, em amarelo; RTP MPEG
44.100Hz, cor azul claro; RTP ULAW 8.000Hz, cor laranja; RTP DVI 11.025Hz, cor azul
escuro; RTP DVI 8.000Hz, cor vermelha; e, RTP g723 8.000Hz, cor verde.
O formato de áudio RTP DVI 22.050Hz apresentou maiores valores de vazão entre os
formatos candidatos, com vazões máxima, media e mínima respectivamente de 124.864 bits/s,
91.733,36 bits/s e 75.712 bits/s. Em seguida, tem-se o formato RTP MPEG 44.100Hz que
apresentou vazões máxima, média e mínima de 82.072 bits/s, 65.729,53 bits/s e 50.792 bits/s,
nesta ordem. O formato RTP ULAW 8.000Hz, aparece em terceiro com vazões máxima de
82.656 bits/s, média de 66.552,53 bits/s e mínima de 44.128 bits/s. Em quarto, tem-se o formato
RTP DVI 11.025Hz com vazões máxima, média e mínima respectivamente de 58.128 bits/s,
46.920,96 bits/s e 30.448 bits/s. O formato RTP DVI 8.000Hz aparece em quinto com vazões
máxima de 43.840 bits/s, média de 34.655,84 bits/s e mínima de 22.528 bits/s. Por fim, aparece o
formato RTP g723 8.000Hz com vazões máxima, média e mínima respectivamente de 11.040
bits/s, 8.228,8 bits/s e 5.280 bits/s.
A tabela 7.2 mostra os formatos de áudio RTP mais adequados dada a informação da
capacidade do enlace. Esta informação, conforme critério adotado no item 6.2 do capítulo 6, pode
ser útil para definição de quais formatos de áudio RTP estão associados a quais sessões multicast
mantidas pelo Transcodificador. Desta forma, estaria associado à sessão 1 apenas o formato g723
8.000Hz; à sessão 2, os formatos DVI 8.000Hz e DVI 11.025Hz; à sessão 3, os formatos ULAW
8.000Hz, MPEG 44.100Hz, DVI 22.050Hz.
7. Análise dos Formatos de Áudio RTP para a Infra-estrutura de Transcoficação
87
Tabela 7.2. Formatos de Codificação mais Adequados dada a Capacidade do Enlace
Capacidade
do Enlace
(Kbps)
64
Formatos de Áudio RTP Candidatos
DVI
22.050Hz
MPEG
44.100Hz
ULAW
8.000Hz
DVI
11.025Hz
DVI
8.000Hz
g723
8.000Hz
64 < 128
128
Legenda
´´´´´ ULAW 8.000Hz
g723 8.000Hz
xxx
DVI 8.000Hz
....... DVI 11.025Hz
++++ DVI 22.050Hz
MPEG 44.100Hz
Figura 7.7. Vazões Observadas para os Formatos de Áudio RTP Candidatos
Jitter
As figuras 7.8 e 7.9 ilustram o comportamento do jitter para os formatos analisados nesta
sessão.
Os mais altos valores de jitter observados são vistos na figura 7.8 que apresenta o formato
RTP MPEG 44.100Hz em azul claro com valores de jitter máximo e médio respectivamente de
73,15063 ms e 62,27804 ms; o formato RTP DVI 22.050Hz, em amarelo, com jitter máximo de
21,8811 ms e médio de 20,70246 ms; e, o formato RTP DVI 11.025Hz, em azul escuro, com
valores de jitter máximo e médio, respectivamente de 10,81848 ms e 10,34304 ms.
7. Análise dos Formatos de Áudio RTP para a Infra-estrutura de Transcoficação
88
A figura 7.9 ilustra os mais baixos valores de jitter observados que estão em média na casa
de 7 ms. São eles: RTP ULAW 8.000Hz, visto em laranja, com valores de jitter máximo e médio
respectivamente de 7,919312 ms e 7,513819 ms; RTP DVI 8.000Hz, em vermelho, registrando
valores máximo e médio respectivamente de 8,651733 ms e 7,52646 ms; e, RTP g723 8.000Hz,
representado em verde e apresentando valor máximo de 8,285522 ms e médio de 7,566713 ms.
A análise da quantidade de bytes, pacotes RTP e RTCP ajuda a explicar os valores de jitter
observados, conforme visto adiante.
Legenda
....... DVI 11.025Hz
++++ DVI 22.050Hz
MPEG 44.100Hz
Figura 7.8. Maiores Valores de Jitter Observados para os Formatos de Áudio RTP Candidatos
7. Análise dos Formatos de Áudio RTP para a Infra-estrutura de Transcoficação
89
Legenda
´´´´´ ULAW 8.000Hz
g723 8.000Hz
xxx
DVI 8.000Hz
Figura 7.9. Menores Valores de Jitter Observados para os Formatos de Áudio RTP Candidatos
Quantidade de Bytes, Pacotes RTP e RTCP
A figura 7.10 ilustra a quantidade de bytes recebidos para os formatos de áudio RTP
candidatos às sessões multicast disponibilizadas pelo Transcodificador durante o intervalo
analisado, apresentando em amarelo o formato RTP DVI 22.050Hz; em laranja o formato RTP
ULAW 8.000Hz; em azul claro o formato RTP MPEG 44.100Hz; em azul escuro o formato DVI
11.025Hz; em vermelho o formato RTP DVI 8.000Hz; em verde o formato g723 8.000Hz.
O formato RTP DVI 22.050Hz registrou 13.760.004 bytes, 20.569 pacotes RTP e 240
pacotes RTCP, aproximadamente 669 bytes por pacote RTP. O formato RTP ULAW 8.000Hz
apresentou 9.982.880 bytes, 20.496 pacotes RTP e 244 pacotes RTCP, aproximadamente 487
bytes por pacote RTP. O formato RTP MPEG 44.100Hz registrou 9.859.430 bytes, 7.994 pacotes
RTP e 244 pacotes RTCP, aproximadamente 1233 bytes por pacote RTP. O formato RTP DVI
11.025Hz acusou 7.038.144 bytes, 20.527 pacotes RTP e 239 pacotes RTCP, aproximadamente
343 bytes por pacote RTP. O formato RTP DVI 8.000Hz registrou 5.198.376 bytes, 20.475
pacotes RTP e 242 pacotes RTCP, aproximadamente 254 bytes por pacote RTP. Por fim, o
7. Análise dos Formatos de Áudio RTP para a Infra-estrutura de Transcoficação
90
formato g723 8.000Hz apresentou 1.234.320 bytes, 20.500 pacotes RTP e 250 pacotes RTCP,
aproximadamente 60 bytes por pacote RTP.
A quantidade de pacotes RTP registrados para todos os formatos analisados permaneceu
aproximadamente na faixa de 20.500, exceto para o formato RTP MEG 44.100Hz que registrou
7.994. Com relação à quantidade de pacotes RTCP observada, todos os formatos analisados
apresentaram quantidade próxima a 240.
O alto valor observado para o jitter no formato RTP MPEG 44.100Hz, da mesma forma que
na sessão 7.2, pode ser explicado pela quantidade de bytes por pacote RTP, aproximadamente
1233; pela complexidade do algoritmo de codificação e decodificação MPEG; pelo uso de Java,
não otimizado para aplicações com características de tempo real. A baixa complexidade dos
algoritmos de codificação e decodificação dos demais formatos de áudio RTP, explica os valores
de jitter mais baixos.
Legenda
´´´´´ ULAW 8.000Hz
g723 8.000Hz
xxx
DVI 8.000Hz
....... DVI 11.025Hz
++++ DVI 22.050Hz
MPEG 44.100Hz
Figura 7.10. Quantidade de Bytes Recebidos para os Formatos de Áudio RTP Candidatos
8
Conclusão e Trabalhos Futuros
A demanda crescente por aplicações que tratem mídias até então não presentes nas redes
convencionais encontra problemas na falta de mecanismos, a nível das camadas de enlace de
dados, redes e aplicação do modelo de referência OSI, que por um lado garantam os requisitos de
largura de banda e controle do jitter e por outro permitam a adaptação à heterogeneidade dos
recursos de rede e variabilidade de seus estados. Esta dissertação, realiza um levantamento dos
mecanismos para garantia de recursos de rede no apêndice B e propõe uma infra-estrutura de
transcodificação adaptável ao estado da rede tendo por base a monitoração da perda de pacotes
RTP.
Foram definidos quatro casos de uso principais para a infra-estrutura de transcodificação
proposta no capítulo 5, a saber: Transmitir ao Transcodificador; Iniciar Sessões de Áudio no
Transcodificador; Receber Stream de Áudio RTP no Receptor; e, Trocar a Sessão Multicast de
Recepção. Destes, os três primeiros foram implementados, conforme visto no capítulo 5, e
validados, conforme visto nas análises do capítulo 7; o quarto, foi apenas especificado, conforme
visto no capítulo 6, sendo a sua implementação e validação em cenário com filas diferenciadas de
priorização de pacotes na camada de rede, visto no apêndice B, um trabalho futuro.
O uso da linguagem Java e JMF possui a vantagem de facilitar a implementação, mas peca
pelo desempenho desejável (e.g. áudio MPEG RTP, capítulo 7) principalmente quando o foco são
aplicações com características de tempo real onde há fortes restrições para se manter a qualidade
a todos os participantes envolvidos, como é o caso de conferências de áudio e vídeo.
O mecanismo de distribuição de áudio visto no capítulo 5, extensível a distribuição de vídeo
em uma Intranet, contribuição dessa dissertação, não encontra similar na literatura uma vez que o
Transcodificador guarda informações a respeito das sub-redes participantes - o formato de áudio
RTP mais adequado a cada sub-rede em um dado instante – ofertando aos receptores três sessões
multicast de áudio RTP às quais devem se associar de acordo com o estado da rede e não o
fazendo de forma individual mas coletiva envolvendo os pares das sub-redes onde se encontram.
8. Conclusão e Trabalhos Futuros
92
Com relação aos trabalhos futuros, pode-se identificar:
A implementação do mecanismo de adaptação especificado nessa dissertação uma vez que se
encontra implementado apenas a distribuição, recepção e transcodificação de áudio RTP;
A evolução da infra-estrutura de transcodificação proposta e da aplicação para a distribuição
das mídias de áudio e vídeo;
A evolução da infra-estrutura de transcodificação e da aplicação para disponibilizar
conferências de áudio e vídeo entre os participantes. Esse mecanismo, aliado à distribuição de
áudio e vídeo cujo princípio de funcionamento já se encontra explicitado nessa dissertação, é
ideal para aplicações de ensino a distância;
O protocolo de aplicação RTSP, citado no capítulo 3, cujo princípio de funcionamento é
semelhante ao de um controle remoto para servidores multimídia, pela sua semelhança de
funcionamento ao protocolo de aplicação HTTP surge como ótima opção a espraiar o uso de
aplicações avançadas tanto no ambiente de uma Intranet quanto na Internet. Implementações
exclusivas para a distribuição de mídia sob demanda podem “pegar carona” no sucesso da
Web através da implementação desse protocolo;
Validação do mecanismo de adaptação à rede fazendo-se uso dos mecanismos de garantias da
qualidade de serviço: reserva de recursos, mecanismos de priorização de quadros (IEEE
802.1P) e pacotes (DiffServ). O Sistema Operacional Linux já possui a funcionalidade de
priorização de pacotes a nível da camada de rede, conforme citado no apêndice B.
Referências
[2-1] FOX, A.; GRIBBLE, S. D.; BREWER, E. A.; AMIR, E. Adapting to Network and Client
Variatiability via On-Demand Dynamic Distillation. In: INTERNATIONAL CONFERENCE, 17.
Asplos, 1996.
[2-2] JONAS, K. Forget the Net! Architecture, Specification and Implementation of a
Communication System for Real-time Streaming in Heterogeneous Environments. In:
Pacific Workshop on Distributed Multimedia Systems. Vancouver, 1997.
[2-3] JONAS, K.; KRETSCHMER, M.; MÖDEKER, J. J. Get a KISS – Communication
Infrastructure for Streaming Services in a Heterogeneous Environment. In: ACM
MULTIMEDIA 98. Bristol, 1998.
[2-4] MAO, Z. M.; KATZ, R. Achieving Service Portability in ICEBERG. California:
University of California at Berkeley, 2000.
[2-5] WANG, H. J. et al. ICEBERG: An Internet-core Network Architecture for Integrated
Communications. In: IEEE Personal Communications (2000): Special Issue on IP-Based Mobile
Telecommunication Networks, 2000.
[2-6] COMCAR – COMMUNICATION AND MOBILITY BY CELLULAR ADVANCED RADIO.
Disponível na Internet em http://www.comcar.de, 2003.
[2-7] KOVACS, E. et al. Adaptative Mobile Application over Cellular Advanced Radio. In:
IEEE PIRMC2000. London: 2000.
[3-1] SCHULZRINNE, H. et al. RTP: A Transport Protocol for Real-Time Applications. RFC
1889. 1996.
[3-2] SCHULZRINNE, H. et al. RTP: A Transport Protocol for Real-Time Applications. RFC
3550. 2003.
[3-3] ROCA, V. RTP/RTCP and RTSP – Multimedia Protocols for the Internet. Projet
Planèt. Inria Rhône-Alpes. 2001.
[3-4] GRUPO DE TRABALHO AUDIO/VIDEO TRANSPORT. Internet Engineering Task Force – IETF.
Página da Internet em http://www.ietf.org/html.charters/avt-charter.html, 2003.
[3-5] MILLS, Da. Network Time Protocol (Version 3) Specification, Implementation and
Analyses. RFC 1305. 1992.
[3-6] GRUPO DE TRABALHO MMUSIC - MULTIPARTY MULTIMEDIA SESSION CONTROL. Internet
Engineering Task Force – IETF. Página da Internet em http://www.ietf.org, 2003.
[3-7] SCHULZRINE, D.; RAO, A.; LANPHIER, R. Real Time Streaming Protocol – RTSP. RFC
2326. 1998.
[3-8] CASNER, S.; JACOBSON, V. Compressing IP/UDP/RTP Headers for Low-Speed Serial
Links. RFC 2508. 1999.
[3-9] SCHULZRINNE, H.; CASNER, S. RTP Profile for Audio and Video Conferences with
Minimal Control. RFC 3551. 2003.
[3-10] HOFFMAN, D.; FERNANDO, G.; GOYAL, V. RTP Payload Format for MPEG1/MPEG2
Video. RFC 2038. 1996.
[3-11] IMA DIGITAL AUDIO FOCUS AND TECHNICAL WORKING GROUPS. Recommended
practices for enhancing digital audio compatibility in multimedia systems. Maryland:
Interactive Multimedia Association, 1992.
[3-12] YEN PAN, D. Digital Audio Compression. Digital Technical Journal. Vol. 5, n. 2, 1993.
Referências
94
[3-13] CCITT - COMITÉ CONSULTATIF INTERNATIONAL TÉLÉPHONIQUE ET TÉLÉGRAPHIQUE.
Recommendation G.711: Pulse Code Modulation (PCM) of Voice Frequencies. 1972.
[3-14] JAYANT, N. S.; NOLL, P. Digital Coding of Waveforms – Principles and Applications
to Speech and Video Englewood Cliffs. Prentice-Hall, 1984.
[3-15] NISHIGUCHI, M.; AKAGIRI, K.; SUZUKI, T. A New Audio Bit Rate Reduction System for
the CD-I Format. In: Audio Engineering Society Convention, 81. Los Angeles: 1986.
[3-16] TAKAHASHI, Y. et al. Study and Evaluation of a New Method of ADPCM Encoding.
In: Audio Engineering Society Convention,86. Hamburg: 1989.
[3-17] HOFFMAN, D. et al. RTP Payload Format for MPEG1/MPEG2 Video. RFC 2250.
1998.
[3-18] GREWIN, C.; RYDEN, T. Subjective Asseseements on Low-Bit rate Audio Codecs. In:
International Audio Engineering Society Conference, 10. Londres: 1991.
[3-19] TOBIAS, J. Foundations of Modern Auditory Theory. Academic Press. New York &
London: 1970.
[3-20] BRANDENBURG, K.; STOLL, G. The ISO/MPEGAudio Codec: A Generic Standard for
Coding of High Quality Digital Audio. In: Audio Engineering Society Convention,92. Vienna:
1992.
[3-21] BRANDENBURG, K.; HERRE, J. Digital Audio Compression for Professional
Applications. In: Audio Engineering Society Convention, 92. Vienna: 1992.
[3-22] BRANDENBURG, K.; JOHNSTON, J. D. Second Generation Perceptual Audio Coding:
The Hybrid Coder. In: Audio Engineering Society Convention,88. Montreaux: 1990.
[3-23] BRANDENBURG, K et al. ASPEC: Adaptive Spectral Perceptual Entropy Coding of
High Quality Music Signals. In: Audio Engineering Society Convention, 90. Paris: 1991.
[3-25] Huffman, D. A. A Method for the Construction of Minimum Redundancy Codes. In:
IRE. 1962.
[3-26] JOHNSTON, J. D. Estimation of Perceptual Entropy Using Noise Masking Criteria. In:
IEEE International Conference on Acoustics, Speech, and Signal Processing. 1988.
[3-27] JOHNSTON, J. D. Transform Coding of Audio Signals Using Perceptual Noise Criteria.
IEEE Journal on Selected Areas in Communications, fev. 1988.
[4-1] DEERING, S. Host Extensions for IP Multicasting. RFC 1112. 1989.
[4-2] WAITZMAN, D.; PARTRIDGE, C.; DEERING, S. Distance Vector Multicast Routing
Protocol. RFC 1075. 1988.
[4-3] MOY, J. Multicast Extensions to OSPF. RFC 1584. 1994.
[4-4] ESTRIN, D. et al. Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
Specification. RFC 2362. 1998.
[4-5] ADAMS, A.; NICHOLAS, J.; SIADAK, W. Protocol Independent Multicast Dense Mode.
Internet Draft. 2003.
[4-6] BALLARDIE, A. Core Based Trees (CBT) Multicast Routing Architecture. RFC 2201.
1997.
[5-1] PRANATA, A. Development of Network Service Infrastructure for Transcoding
Multimedia Streams. University of Stuttgart. Faculty of Computer Science, 2002.
[5-2] GUOJUN, L. Communication and Computing for Distributed Multimedia Systems.
Norwood: Artech House Inc. 1996.
[5-3] STEINMETZ, R.; NAHRSTEDT, K. Multimedia: Computing, Communications and
Applications. Prentice Hall Inc. 1995.
[5-4] CHALMERS, D.; SLOMAN, M. Survery of Quality of Service in Mobile Computing
Environments. London: Imperial College. Department of Computing. 1999.
Referências
95
[5-5] SCHIMIDT, D. C. Applying Design Patterns and Frameworks to Develop ObjectOriented Communication Software. St. Louis: Washington University. 1997.
[5-6] JOHNSON, R.; FOOTE, B. Designing Reusable Classes. Journal of Object-Oriented
Programming: Junho, 1988.
[5-7] GAMMA, E. et al. Design Paterns: Elements of Reusable Object-Oriented Software.
Addison-Wesley. 1995.
[5-8] JOHNSON, R. Frameworks = Patterns + Componentes. Communications of the ACM.
1997.
[5-9] STEPANOV, A.; LEE, M. The Standard Template Library. Hewlett-Packard Laboratories.
1994.
[5-10] Blair, G. S. et al. Supporting Dynamic QoS Management Functions in a Reflexive
Middleware Platform. IEEE. 2000.
[5-11] BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. The Unified Modeling Language User Guide.
Ed. Addison-Wesley. 1999.
[5-12] BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. The Unified Software Development Process
Ed. Addison-Wesley. 1999.
[5-13] SUN MICROSYSTEMS INC. Java Remote Method Invocation Specification. Página da
Internet acessível em http://www.sun.com , 2003.
[5-14] SCHIMIDT, D. et al. Integration of QoS-Enabled Distributed Object Computing
Middleware for Developing Next-Generation Distributed Applications. Irvine: University of
California. Electrical & Computer Engineering Department. 2000.
[5-15] ZINKY, J. A.; BAKKEN, D. E.; SCHANTZ, R. Architetural Support for Quality of Service
for Corba Objects. Theory and Pratice of Object Systems. Vol. 3, n. 1, 1997.
[6-1] RUIZ, P. M., GARCÍA, E. Adaptative Multimedia Applications to Improve UserPerceived QoS in Multihop Wireless Ad-Hoc Networks. Atlanta: IEEE Conference on Local
Networks. 2002.
[7-1] HALLFILL, T.; GALLANT, A. How to Soup Up Java. Byte Magazine v. 23, n. 5, 1998.
[7-2] CLAYPOOL, M.; TANNER, J. Java Jitters – The Effects of Java on Jitter in a
Continuous Media Server. Worcester Polytechnic Institute, Computer Science Department,
1998.
[An-1] SUN MICROSYSTEMS INC. Java Media Framework API Guide. 1999.
[A-1] CISCO SYSTEMS. Understanding Jitter in Packet Voice Networks. Disponível em
http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a00800945df.shtml.
Acesso em 20/10/2003.
[B-1] CISCO SYSTEMS. Página da Internet em http://www.cisco.com, 2003.
[B-2] ANSI/IEEE. IEEE 802.1D Standard for Information technology. 1998.
[B-3] NETIQ CORPORATION. Testing 802.1P QoS with Chariot. 2001.
[B-4] NICHOLS, K. Et al. Definition of the Differentiated Services Field (DS Field) in the
IPv4 and IPv6 Headers. RFC 2474. 1998.
[B-5] BLAKE, S.; BLACK, D.; CARLSON, M.; DAVIES, E.; WANG, Z.; WEISS, W. An
Architecture for Differentiated Services. RFC 2475. 1998.
[B-6] EXTREME NETWORKS. Página da Internet em http://www.extremenetworks.com, 2003.
[B-7] ALMQUIST, P. Type of Service in the Internet Protocol Suite. RFC 1349. 1992.
[B-8] GRUPO DE TRABALHO DIFFSERV DO IETF. Página da Internet em
http://www.ietf.org/html.charters/diffserv-charter.html, 2003.
[B-9] JACOBSON, V.; NICHOLS, K.; PODURI, K. An Expedited Forwarding PHB. RFC
2598. 1999.
Referências
[B-10] HEINANEN, J. et al. Assured Forwarding PHB Group. RFC 2597. 1999.
[B-11] SOURCEFORGE. Differtiated Services on Linux. Página da Internet em
http://diffserv.sourceforge.net, 2003.
[B-12] SIMON, E.; GRESSIER-SOUDAN, E.; BERTHELIN, J. Avoid LAN Switches, IP
Routers provide a better alternative for a Real-Time Communication System. CNAMCEDRIC. 2003.
[B-13] LARTC. Linux Advanced Routing & Traffic Control HOWTO. Página da Internet
disponível em http://lartc.org/lartc.pdf, 2003.
96
Apêndice A
Jitter em Redes de Pacotes de Voz
O jitter geralmente é causado devido a congestionamento em uma rede de pacotes IP. O
congestionamento pode ocorrer na interface de um roteador caso não tenha sido feito o
aprovisionamento correto de um circuito.
A.1. Definição
Jitter é definido como a variação no atraso do recebimento de pacotes. Do lado transmissor,
pacotes são enviados na forma de streams contínuos com os pacotes sendo espaçados
regularmente. Devido ao congestionamento ou à má configuração na rede, ocorre a perda de
uniformidade no espaçamento dos pacotes no stream, ou seja, o atraso entre cada pacote começa
a variar ao invés de permanecer constante.
Stream de pacotes bem organizado
tempo
O mesmo stream de pacotes após congestionamento
Figura A.1. Efeito do jitter em um stream de pacotes de voz [A-1]
Quando o receptor recebe um stream de áudio RTP para voz sobre IP (VoIP), ele deve
compensar o jitter que foi encontrado. O mecanismo para realizar esta compensação é a criação
de um buffer de recepção. Este mecanismo também pode estar implementado em roteadores que
mantenham um buffer de compensação do jitter e entreguem os streams de pacotes de áudio de
uma forma mais suavizada para os dispositivos de processamento do sinal digital, a fim de que
haja a reprodução do stream de áudio analógico.
A figura A.2 ilustra como o jitter é tratado.
Apêndice A. Jitter em Redes de Pacotes de Voz
98
Stream RTP com jitter
Buffer para
compensação
do jitter
Stream após compensação realizada pelo Buffer
Figura A.2. Buffer para compensação do jitter [A-1]
Caso o jitter seja tão grande que leve aos pacotes serem recebidos fora dos limites do
buffer, os pacotes serão descartados e falhas serão ouvidas no áudio processado e reproduzido no
receptor. O dispositivo receptor pode tentar minimizar o problema da perda de pacotes, no
entanto, quando a perda de pacotes for muito grande, problemas serão ouvidos no áudio.
Stream RTP com jitter excessivo
Buffer para
compensação
do jitter
Pacote é perdido devido a buffer excessivo
Figura A.3. Pacote perdido devido a jitter excessivo. [A-1]
Apêndice A. Jitter em Redes de Pacotes de Voz
99
A.2. O que pode causar o Jitter ?
O mais fácil e melhor lugar para se começar a procurar solucionar problemas com jitter é nas
interfaces dos roteadores [A-1]. O modo de se tratar este problema depende do tipo de enlace
onde o jitter está ocorrendo. Em um circuito ATM, caso esteja bem configurado, o jitter não
deverá ocorrer devido a taxa constante no envio de células que faz com que o atraso seja
controlável. Quando houver um encapsulamento ponto-a-ponto, através do protocolo PPP Point-to-Point Protocol, o jitter ocorre devido ao atraso de serialização. Isto pode ser facilmente
corrigido usando a fragmentação e o intervalo de transmissão em um enlace PPP. A natureza do
PPP significa que os pontos-finais estão conectados diretamente um ao outro, sem uma rede de
switchs ou roteadores entre elas.
Em um ambiente frame-relay, três fatores podem influenciar o jitter:
Modelagem do tráfego
Fragmentação
Enfileiramento
É necessário verificar se a modelagem do tráfego que deixa o roteador está de acordo com a
vazão garantida, definida através do CIR - Committed Information Rate, que o provedor está
oferecendo.
A fragmentação é mais associada ao atraso de serialização que ao jitter, no entanto, certas
condições podem causar o jitter. Em um circuito frame-relay, a configuração deste parâmetro
pode causar que todos os pacotes maiores que o tamanho especificado sejam fragmentados.
O enfileiramento geralmente não é causa de jitter, uma vez que as variações criadas por ele
no atraso de pacotes são relativamente baixas. No entanto, caso haja dados trafegando junto com
pacotes de voz em um mesmo circuito, isto pode levar a ocorrência de jitter.
Apêndice B
Qualidade de Serviço (QoS)
Mecanismos para garantir QoS são essenciais aos serviços de nova geração. Para o cenário
focado nesta dissertação, entrega de áudio dentro de uma rede corporativa, pode-se usar
mecanismos de qualidade de serviço que atuam nas camadas 2, 3, 4 e 7 do modelo de referência
OSI. Para a camada 2 é abordado o uso do protocolo IEEE 802.1P, disponível nos switchs. Para a
camada 3 sugere-se o uso de serviços diferenciados (DiffServ) apontando-se para a
implementação no Linux através do pacote IPROUTE2 e mecanismos disponível a partir do
Kernel 2.3. Para as camada 4 e 7, ocorre que os Sistemas Operacionais disponibilizam aplicações
de configuração (camada 7) que permitem a definição de políticas de priorização de pacotes para
aplicações que utilizam determinadas portas
UDP ou TCP – camada 4 (isto é feito em
consonância com os mecanismos de marcação de prioridade de pacotes disponíveis na camada 2,
protocolo IEEE 802.1P) e dispositivos de hardware existentes nas estações de trabalho, placas de
interface de rede com suporte ao protocolo IEEE 802.1P.
B.1. Mecanismos usados para se implementar Qualidade de Serviço (QoS)
Type of Service (ToS), DiffServ, e 802.1P são três diferentes mecanismos usados para obter QoS,
através da marcação de cada pacote da camada da camada 3 ou quadro da camada 2, a fim de
indicar sua prioridade aos dispositivos de rede.
É fácil confundir a diferença entre Type of Service (ToS) e DiffServ pois ambos usam o
mesmo byte do cabeçalho do protocolo IP. Isto é esclarecido nos tópicos adiante.
802.1P relaciona-se ao Ethernet enquanto que o campo Precedence do byte ToS e DiffServ
(vistos nos tópicos B.2 e B.3) estão relacionados ao IP. A carga útil do frame Ethernet pode não
ser sempre o IP o que é considerado como uma vantagem do 802.1P sobre o DiffServ e ToS uma
vez que qualquer protocolo da camada 3 pode estar sendo usado.
Apêndice B. Qualidade de Serviço (QoS)
101
B.2. Type of Service (ToS)
É definido na RFC 1349 [B-7]. O formato do byte do cabeçalho do protocolo IPv4 é:
0
1
2
Precedence
3
4
5
6
ToS
7
MBZ
Figura B.1. Formato do byte TOS do Cabeçalho do Ipv4 [B-7]
O byte é dividido nos campos Precedence, ToS e MBZ.
O campo Precedence é o mais usado dos três. Definido por 3 bits, há oito valores de
precedência possíveis que vão de 000 (decimal 0) a 111 (decimal 7). O valor 000 representa o
tráfego de prioridade mais baixa enquanto que o valor 111 o de prioridade mais alta.
O campo ToS define classes de serviço com enfoque em atraso (delay), vazão (throughput),
confiabilidade, valores monetários e serviços ditos normais. É pouco usado na prática.
O campo MBZ “Must be Zero”, nunca foi usado.
B.3. Serviços Diferenciados
Serviços Diferenciados (DiffServ) é uma arquitetura definida na RFC 2474 [B-4] e na 2475 [B-5]
que oferece diferentes tipos ou níveis de serviço para o tráfego da rede.
Uma característica chave do Diffserv é a agregação dos fluxos na rede, de tal forma que os
roteadores necessitam distinguir um pequeno número de fluxos agregados, mesmo que estes
fluxos contenham milhares de fluxos individuais.
Esta arquitetura é composta de um número de elementos funcionais implementado nos
roteadores de borda da rede, incluindo um pequeno conjunto de comportamentos bem definidos
para a retransmissão de pacotes a cada salto, funções de classificação de pacotes e funções de
condicionamento de tráfego que incluem medição, marcação, modelagem e definição de políticas,
conforme ilustra a figura B.2 abaixo.
Apêndice B. Qualidade de Serviço (QoS)
102
Figura B.2. Visão Lógica do Classificador de Pacotes e Condicionador de Tráfego [B-5]
Quando um pacote sai de um condicionador de tráfego em um roteador de borda com
DiffServ, a marcação DSCP - DiffServ codepoint é configurada para um valor apropriado
conforme a política de tráfego adotada.
O Medidor contabiliza as propriedades temporais do stream de pacotes selecionados pelo
Classificador comparando ao perfil de tráfego especificado pelo contrato. Ele informa o estado
para outras funções de condicionamento de tráfego a fim de disparar ações automáticas a serem
tomadas para cada pacote.
Por sua vez o Marcador é responsável por definir o DSCP, adicionando o pacote marcado à
mesma fila que definirá o comportamento do tráfego para a agregação de pacotes com o mesmo
DSCP.
Enquanto o Modelador atrasa alguns ou todos os pacotes em um stream de tráfego o
Descartador os descarta, de tal forma a deixar o stream em conformidade com o padrão de
tráfego adequado.
Devido ao byte TOS do cabeçalho do Protocolo IPv4 ser raramente usado, o grupo de
trabalho do DiffServ [B-8] foi formado para redefinir o byte a fim de torná-lo mais útil. Seu
formato é mostrado na figura B.3. No Ipv6 é usado o octeto denominado Classe de Tráfego.
0
1
2
3
DSCP
4
5
6
7
Current
Unused
Figura B.3. Formato do byte DiffServ [B-4]
O DSCP tem agora comprimento de 6 bits e não 3 bits reservados ao campo Precedence do
byte ToS. Os bits 6 e 7 não são usados. Desta forma o DSCP pode assumir valores que vão de
000000 (decimal 0) a 111111 (decimal 63) que dão um total de 64 marcações diferentes de tipos
de tráfego. O que geralmente é feito nos switchs e roteadores para manter a compatibibilidade
Apêndice B. Qualidade de Serviço (QoS)
103
com o campo Precedence do byte ToS do cabeçalho do IPv4 é associar os 64 diferentes valores
do DSCP a apenas 8 possíveis valores do campo Precedence e que também estão associados aos
8 possíveis valores de marcações do quadro IEEE 802.1P.
Em adição às definições básicas do DSCP, o grupo de trabalho DiffServ [B-8] definiu
classes de tráfego adicionais. Em particular a classe Expedited Forward definida na RFC 2598
[B-9] e Assured Forward definida na RFC 2597 [B-10].
Serviços Difereciados no Linux
O suporte a Serviços Diferenciados no Linux, parte da arquitetura de Controle de Tráfego
mais geral, é nativo no Kernel 2.3 e 2.4 [B-11].
O Controle de Tráfego no Linux é configurado com o utilitário denominado tc que é parte
integrante do pacote iproute2 [B-12]. Ambos formam um framework [B-13] que unifica
ferramentas relacionadas a rede tais como arp, ifconfig, route e novas ferramentas para a criação
de túneis. A ferramenta para controle de tráfego no Linux (tc) permite a configuração da pilha IP
através de características do iproute2 a fim de habilitar o gerenciamento de QoS dentro do kernel,
lidando especialmente com disciplinas de tráfego. Estas facilidades levam o Linux a ser uma
opção fácil e barata para a construção de uma arquitetura de roteamento com classes de serviço.
Este framework permite o gerenciamento de diferentes disciplinas de filas, classes e filtros.
Algumas das características implementadas são: CBQ - Class Based Queuing, HTB Hierarchical Token Bucket, SFQ - Stochastic Fairness Queuing, TBF - Token Bucket Filter.
São definidas 256 filas, manuseadas de acordo com a prioridade. Cada fila suporta uma
vazão de 100kbps. O filtro denominado u32 é usado para classificar os datagramas
retransmitidos, associando-os à fila correta. O parâmetro "pfifo" define uma disciplina FIFO,
estatísticas são geradas a partir de cada datagrama. iproute2 é muito flexível apesar de sua sintaxe
não tão amigável.
Apêndice B. Qualidade de Serviço (QoS)
104
B.4. IEEE 802.1P
Em 1990 foi desenvolvido o padrão IEEE 802.1D, posteriormente publicado em 1993, como
ISO/IEC 10038, e revisado em 1998 especifica uma arquitetura e protocolo para a interconexão
de LANs IEEE 802 abaixo dos limites de serviço da subcamada MAC. O padrão IEEE 802.1P, o
qual passamos a explicitar adiante, faz parte do IEEE 802.1D [B-2].
A técnica de sinalização IEEE 802.1P é uma especificação IEEE para priorização de tráfego
na rede a nível da camada de enlace de dados / MAC (Camada 2 do modelo de referência OSI). O
IEEE 802.1P também possibilita filtrar o tráfego multicast de tal forma que ele não se propague
através das redes comultadas a nível da camada 2, a não ser para as portas do switch que
realmente têm interesse no tráfego. O cabeçalho 802.1P inclui um campo de três bits para
priorização que permite aos pacotes serem agrupados em várias classes de tráfego (até oito).
Também pode ser definido como best-effort QoS a nível da camada 2 e é implementado em
switchs e adaptadores de rede sem envolver nenhuma configuração de reserva de recursos. Em
outras palavras, o tráfego 802.1P é classificado e enviado ao destino sem que haja mecanismos de
reserva de recursos.
IEEE 802.1P é um avanço da marcação de VLANs 802.1Q (uma marca acrescentada ao
quadro MAC). Veja figuras B.4 e B.5 adiante. A marcação da VLAN carrega informações da
VLAN e é dividida em duas partes: o identificador da VLAN (12-bit) e a priorização (3-bit). O
campo priorização não foi definido no padrão VLAN. A implementação 802.1P define este
campo de priorização.
Endereço de Destino
Endereço de Origem
Tipo / Comprimento
(6 bytes)
(6 bytes)
(2 bytes)
Figura B.4. Cabeçalho da Camada 2 Ethernet sem a informação 802.1 P/Q [B-2]
Apêndice B. Qualidade de Serviço (QoS)
Endereço de Destino
(6 bytes)
...
105
Endereço de Origem
(6 bytes)
Campo de
prioridade
802.1P
(3 bits)
1
bit
Marca de Controle
(4 bytes)
Tipo / Comprimento
(2 bytes)
Identificação da VLAN 802.1Q
(12 bits)
Figura B.5. Cabeçalho da Camada 2 Ethernet 802.1 com a informação 802.1 P/Q [B-2]
A maioria dos fabricantes concorda que IEEE 802.1P é um mecanismo para marcação de
quadros com priorização. No entanto, não há abordagem uniforme acerca dos mecanismos de
fila que implementam a priorização dos fluxos. IEEE 802.1P define oito níveis de prioridade
semelhante ao campo IP Precedence, subconjunto do campo Type of Service, do cabeçalho IP.
Adaptadores de rede e switches roteam o tráfego baseado no nível de prioridade. O uso de
switchs nível 3 possibilita mapear a priorização 802.1P ao IP Precedence antes da retransmissão
pelos roteadores. Atuar a nível da camada 2 permite ao 802.1P suportar IPX, SNA, AppleTalk e
outros protocolos nível 3 além do IP conforme já dito anteriormente.
Apesar dos padrões IEEE suportarem até oito níveis de prioridade, muitos vendedores
suportam apenas dois ou três filas de prioridade em seus switchs na prática e não oito. Switchs
CISCO [B-1] nos modelos 2900 XL e 3500 XL implementam apenas duas filas e não 8. Switchs
Extreme Networks [B-6] possuem as oito filas de prioridade definidas e associadas por padrão a
marcadores DSCP do Diffserv. Quando se trata de switchs de fabricantes diferentes, pode-se ter
dois valores de níveis de prioridade iguais, por exemplo 3, que na prática estão associados
internamente a filas de prioridades diferentes.
Baseado em regras, cada quadro recebe uma marcação de prioridade. Esta marca é
observada e entendida pelos dispositivos antes de qualquer broadcast ou retransmissões para
outros switchs, roteadores ou estações de trabalho. Quando o frame atinge o último switch ou
roteador, a marca é removida antes de seu encaminhamento para o destino final. Quando chega a
um roteador, a marca do frame é removida e é acrescido uma marcação Diffserv (camada 3,
Apêndice B. Qualidade de Serviço (QoS)
106
cabeçalho do protocolo IP) antes do encaminhamento a outro roteador. Cada porta da switch tem
um buffer de recepção, conhecido como ingress port, para o tráfego de chegada. Quando um
quadro chega sem marcação de prioridade, a ele é atribuído uma marcação padrão. Um quadro
continua a usar sua marcação de classe de serviço quando ele passa pelo buffer de chegada.
Quadros nas filas de prioridade mais baixas são retransmitidos apenas após os quadros de
prioridade mais alta terem sido retransmitidos.
Componentes de Hardware e Software necessários ao QoS 802.1P
Vários componentes de hardware e software são necessários para oferecer qualidade de
serviço 802.1P, a saber:
Switch;
Placa de Interface de Rede;
Software de Configuração e Marcação de Pacotes.
Switch
Por ser uma evolução, o protocolo 802.1P sofre do problema de incompatibilidade com
switchs legados. Alguns dispositivos usados em LANs, tais como Hubs conseguem repassar
pacotes marcados com a informação 802.1P mas ignoram a prioridade. Dispositivos que não
suportem mais que os tradicionais 1.518 bytes do frame Ethernet, descartarão simplesmente os
pacotes com 1.522 bytes máximo devido ao acréscimo de 4 bytes da marcação do protocolo
802.1 P/Q.
Placa de Interface de Rede
Muitas das placas de rede possuem suporte a 802.1P conforme ilustra a configuração da
interface no Sistema Operacional Windows 2000 na figura B.6 adiante.
Apêndice B. Qualidade de Serviço (QoS)
107
Figura B.6. Configuração de uma placa Ethernet com suporte a 802.1P vista no S.O Windows
2000
Software de Configuração e Marcação de Pacotes
Os Sistemas Operacionais podem disponibilizar aplicações para configurar a marcação de
pacotes 802.1P, conforme é ilustrado na figura B.7.
Para a implementação objeto desta
dissertação é necessário que os pacotes com portas UDP de origem e destino iguais às usadas
pela aplicação recebam marcação de priorização mais alta.
Apêndice B. Qualidade de Serviço (QoS)
108
Figura B.7. Software de Configuração da marcação de pacotes 802.1P disponibilizado pelo
Sistema Operacional Windows 2000/XP
B.5. Infra-Estrutura de Rede Necessária a Distribuição de Áudio com QoS
A figura B.8 abaixo ilustra a infra-estrutura de rede necessária a distribuição de áudio com QoS.
Os seguintes itens devem ser observados:
Estações de trabalho PC com placa de interface de rede suportando IEEE 802.1P e política de
priorização de pacotes definida pelo S.O;
Switchs de borda com suporte a IEEE 802.1P e multicast habilitado;
Switchs de distribuição com suporte a IEEE 802.1P realizando mapeamento automático das
marcações de priorização do quadro IEEE 802.1P para a marca de prioridade DSCP no
cabeçalho do protocolo IP e multicast habilitado;
PCs com sistema operacional Linux, Kernel 2.3 ou superior, pacote iproute2, multicast
habilitado e duas interfaces (uma Ethernet 10/100 Mbps e outra Serial Síncrona), fazendo as
vezes de roteador.
Apêndice B. Qualidade de Serviço (QoS)
109
Figura B.8. Infra-estrutura de rede necessária a distribuição de áudio com QoS.
Observe-se que ocorre uma tradução entre a marcação de prioridade IEEE 802.1P do frame
Ethernet para o DSCP no cabeçalho do protocolo IP automaticamente na switch de Distribuição
conforme é relatado em [B-6]. O computador realizando o papel de roteador com suporte a
DiffServ reconhece a marcação DSCP inserida pelo switch de distribuição e toma as providências
necessárias para associar cada pacote à fila de prioridade respectiva.
Anexo A
Java Media Framework (JMF)
Java Media Framework (JMF) é uma arquitetura para aquisição, processamento e apresentação de
dados multimídia sensíveis ao tempo. JMF é projetado para suportar muitos tipos de mídia
padrão, tais como AIFF, AU, AVI, GSM, MIDI, MPEG, QuickTime, RMF e WAV.
Baseado no tradicional modelo de captura e apresentação de áudio e vídeo, como mostra a
figura An.1, adiante. Desta forma, um objeto DataSource encapsula o stream multimídia de
maneira similar a uma fita de vídeo ou DVD; um objeto Player oferece mecanismos de controle e
processamento similar a um VCR ou DVD. Tocar e capturar áudio e vídeo usando JMF requer
dispositivos de entrada e saída adequados tais como microfones, câmeras, caixas de som e
monitores.
Figura An.1. JMF é baseado no modelo de captura e apresentação de vídeo tradicionais [An-1]
Objetos DataSource e Player são partes integrantes da API JMF de alto nível para gerenciar
a captura, apresentação e processamento de dados multimídia sensíveis ao tempo. JMF também
oferece uma API de baixo nível que a torna extensível, conforme a figura An.2.
Anexo A. Java Media Framework (JMF)
111
Figura An.2. API JMF [An-1]
An.1. Modelo de tempo
A precisão de tempo de JMF está na casa de nanosegundos.
Classes que suportam o modelo de tempo JMF implementam a interface Clock (figura
An.3) o que garante as operações básicas de tempo e sincronização dos streams multimídia.
Figura An.3. Modelo de tempo JMF [An-1]
An.2. Objetos Manager
A API JMF usa quatro tipos de objetos manager:
Manager - lida com a construção de objetos Player, Processor, DataSource e DateSink;
PackageManager - mantém um registro de pacotes que contém classes JMF, tais como Player,
Processor, DataSource e DataSink;
CaptureDeviceManager - mantém um registro da disponibilidade de dispositivos de captura;
Anexo A. Java Media Framework (JMF)
112
PlugInManager - mantém um registro da disponibilidade de componentes de processamento
JMF
(plug-ins),
tais
como
Multiplexadores
(Multiplexers),
Demultiplexadores
(Demultiplexers), Codificadores (Codecs), Aplicador de efeitos (Effects) e Apresentadores
(Renders).
A classe Manager é essencial na escrita de programas baseados em JMF. Seus métodos
create são usados para criar objetos Player, Processor, DataSource e DataSink, conforme já
citado. O controle de qual processamento é feito sobre o dado multimídia é feito pela classe
PlugInManager.
An.3. Modelo de Evento
Usa um modelo de eventos estruturado que possibilita aos programas baseados em JMF estarem
informados a respeito do estado corrente de sistemas multimídia, bem como a responder a
eventuais erros em tempo de execução. MediaEvent é uma subclasse para identificar vários tipos
particulares de eventos. Estes objetos seguem o padrão Java Beans para eventos.
Objetos Controller, tais como Player e Processor, e certos objetos Control, tais como
GainControl, submetem eventos multimídia. Veja figura An.4.
Figura An.4. Modelo de eventos [An-1]
An.4. Modelo de Dados
Objetos JMF media player geralmente utilizam objetos DataSource (figura An.5) para gerenciar a
transferência de arquivos de áudio e vídeo.
Um DataSource é identificado tanto por um JMF MediaLocator ou uma URL (universal
resource locator). Um MediaLocator é similar a uma URL e pode ser construído a partir de uma
URL, mesmo que o protocolo correspondente não esteja instalado no sistema. Em JAVA, ocorre
o contrário, ou seja, uma URL só pode ser construída se o protocolo estiver instalado.
Anexo A. Java Media Framework (JMF)
113
Figura An.5. Modelo de Dados [An-1]
Um objeto DataSource gerencia um conjunto de objetos SourceStream. Um DataSource
padrão usa um array de byte como uma unidade de transferência. Um objeto BufferDataSource
usa um objeto Buffer como uma unidade de transferência. JMF define vários tipos de objetos
DataSource, como visto no tópico An.4.1.
An.4.1. PushDataSources e PullDataSources
Dados multimídia podem ser obtidos de várias fontes diferentes, tais como arquivos locais,
remotos, broadcast ao vivo. JMF DataSources podem ser caracterizados de acordo com o formato
de transferência iniciado:
Pull - o cliente inicia a transferência de dados e controla o fluxo de dados a partir de objetos
PullDataSource. Protocolos para transferência incluem http e file. JMF define os seguintes
tipos: PullDataSource e PullBufferDataSource (ambos usam objetos Buffer como suas
unidades de transferência);
Push - o servidor inicia a transferência de dados e controla o fluxo de dados a partir de um
objeto PushDataSource. Objetos PushDataSource incluem mídias broadcast e vídeo sob
demanda. Para a realização de broadcast, um protocolo que pode ser usado é o Real-time
Transport Protocol - RTP, de responsabilidade do Internet Engineering Task Force (IETF) [22]. JMF define os tipos: PushDataSource e PushBufferDataSource, que usam objetos Buffer
como sua unidade de transferência.
O grau de controle que um programa cliente pode oferecer aos seus usuários depende do
tipo de DataSource sendo apresentado. Por exemplo, um arquivo MPEG pode ser reposicionado e
Anexo A. Java Media Framework (JMF)
114
um programa cliente poderia permitir ao usuário reposicionar o vídeo ou passar a uma
determinada posição do vídeo. Ao contrário, mídias broadcast estão sob o controle do servidor e
não podem ser reposicionados. Alguns protocolos de vídeo sob demanda suportam um controle
limitado do usuário - por exemplo, um programa cliente pode permitir ao usuário ir para uma
determinada posição, mas não avançar rapidamente ou retornar rapidamente.
An.5. Objetos DataSource Especiais
JMF define dois tipos de objetos DataSource especiais, são eles: CloneableDataSource e
MergingDataSource.
Um CloneableDataSource pode ser usado para criar clones tanto de um objeto
PushDataSource quanto de um PullDataSource.
Um MergingData pode ser usado para combinar os streams (SourceStream) de vários
objetos DataSource em um DataSource único. Isto possibilita que um conjunto de DataSource
seja controlado a partir de um único ponto - quando connect, disconnect, start ou stop é chamado
em um MergingDataSource, a chamada de método é propagada para todos os objetos
DataSource.
An.6. Formatos de Dados
O formato exato de um objeto multimídia é representado por um objeto Format. JMF extende
Format para definir os formatos de áudio e vídeo. Veja a figura An.6.
Figura An.6. Formato de mídias JMF [An-1]
Anexo A. Java Media Framework (JMF)
115
Um objeto AudioFormat descreve os atributos específicos para um dado formato de áudio,
tais como taxa de cada amostra (Hz), quantidade de bits por amostra e número de canais. Um
objeto VideoFormat encapsula informações que são importantes para dados de vídeo. Vários
formatos são derivados de VideoFormat para descrever os atributos de formatos de vídeo
comuns, incluindo:
IndexColorFormat
RGBFormat
YUVFormat
JPEGFormat
H261Format
H263Format
Para receber notificações de mudanças de formatos vindos de um objeto Controller,
implementa-se a interface ControllerListener e escuta-se por FormatChangeEvents.
An.7. Controls
JMF Control (figura An.7), oferece um mecanismo para configurar e recuperar atributos de um
objeto. Muitos objetos JMF oferecem Controls, incluindo objetos Controller, objetos DataSource,
objetos DataSink e JMF plug-ins. DataSource e PlugIn usam as interfaces Control para oferecer
acesso aos seus objetos Control.
Anexo A. Java Media Framework (JMF)
Standard Controls
116
Figura An.7. JMF Controls [An-1]
Objetos DataSink ou Multiplexer lêem a mídia de um DataSource, escrevendo para um
destino (e.g. um arquivo ou a rede).
FramePositioningControl e FrameGrabbingControl oferecem facilidades para objetos
Player e Processor. Possibilita posicionamento preciso dentro de um Player ou de um Processor.
FormatControl oferece métodos para recuperar e configurar um determinado formato.
Um TrackControl é um tipo de FormatControl que oferece um mecanismo para controlar
qual processamento um objeto Processor realiza em um track particular de dados multimídia.
Com os métodos do TrackControl, pode-se especificar quais conversões de formatos são
realizadas em tracks individuais e selecionar os plug-ins Effect, Codec, ou Renderer que são
usados pelo Processor.
Anexo A. Java Media Framework (JMF)
117
BufferControl possibilita controle a nível de usuário sobre o mecanismo de buffer realizado
por um determinado objeto.
An.8. Componentes da Interface com o Usuário
Um Control pode oferecer acesso a um componente de interface com o usuário. Para obter um
componente de interface com o usuário padrão para um Control particular, faz-se uma chamada
ao método getControlComponent. Este método retorna um Component AWT que pode ser
adicionado a um espaço de apresentação de um applet ou de uma janela de aplicação.
Um Controller pode também oferecer acesso à interface Components (interface com o
usuário). Por exemplo, um Player oferece acesso tanto a um componente visual quanto a um
painel de controle - para se recuperar estes componentes, pode-se usar os métodos de Player,
getVisualComponent e getControlComponent.
An.9. Apresentação de Áudio e Vídeo
Em JMF, o processo de apresentação (figura An.8) é modelado por uma interface Controller
que define o estado básico e o mecanismo de controle para um objeto que além de controlar,
apresenta ou captura mídia baseado em um mecanismo de tempo.
Um Controller informa uma variedade de eventos específicos, denominados MediaEvent,
para oferecer notificação de mudanças em seus estados. Para receber eventos de um Controller tal
como um Player, implementa-se a interface ControllerListener.
JMF API define dois tipos de objetos Controller: Player e Processor. Um Player ou
Processor é construído a partir de um objeto DataSource particular e normalmente não reusado.
Figura An.8. Objetos JMF Controller [An-1]
Anexo A. Java Media Framework (JMF)
118
An.10. Player
Um Player processa um stream de entrada e o apresenta (realizando o que se costuma chamar de
“render”) em um tempo preciso. Um DataSource é usado para entregar o stream de entrada para
um Player. O dispositivo apresentador de destino depende do tipo de mídia que está sendo
apresentada, como mostra a figura An.9 abaixo.
Figura An.9. Modelo JMFPlayer [An-1]
Um Player não oferece nenhum controle sobre o processamento que está sendo feito ou
como ele apresenta os dados da mídia.
An.11. Estados do Player
Um Player pode estar em um dos seis estados mostrados na figura An.10, a seguir. A interface
Clock define os dois primeiros estados: Stopped e Started. Para facilitar o gerenciamento de
recursos, o Controller quebra o estado em cinco estados standby: Unrealized, Realizing, Realized,
Prefetching e Prefetched.
Figura An.10. Estados do Player. [An-1]
Anexo A. Java Media Framework (JMF)
119
Em uma operação normal, um Player passa pelos estados até atingir o estado de Started.
An.12. Processor
Objetos Processor podem também ser usados para apresentar dados multimídia, como visto na
figura An.11. Um Processor é justamente um tipo de Player especializado que oferece controle
sobre qual processamento é realizado no stream de entrada. Um Processor suporta todos os tipos
de controles de um Player.
Figura An.11. Modelo JMF Processor [An-1]
Adicionalmente à apresentação de dados multimídia para dispositivos de apresentação, um
Processor pode oferecer saída de dados multimídia para um DataSource de tal forma que estes
dados possam ser apresentados por outro Player ou Processor, manipulados posteriormente por
outro Processor ou entregues para algum destino, como um arquivo.
An.13. ControllerEvent
ControllerEvent (figura An.12) é um evento lançado por um objeto Controller, como um Player
ou Processor e pode estar em três categorias: notificação de mudanças, eventos de finalização e
eventos de transição.
Anexo A. Java Media Framework (JMF)
Figura An.12. Eventos JMF [An-1]
120
Anexo A. Java Media Framework (JMF)
121
An.14. Processamento
Um Processor (figura An.13) pode enviar os dados de saída para um dispositivo de apresentação
ou para um DataSource. Se o dado é enviado para um DataSource, este DataSource pode ser
usado como entrada para um outro Player ou Processor ou como entrada para um DataSink.
Um Processor permite a um desenvolvedor de aplicação definir o tipo de processamento
que é aplicado aos dados multimídia.
O Processamento dos dados multimídia é separado em vários estágios, como mostra a
figura An.14 abaixo.
Figura An.13. JMF Processors [An-1]
Figura An.14. Estágios do Processor [An-1]
Anexo A. Java Media Framework (JMF)
122
Transcodificação (transcoding) é o ato de converter cada track de mídia de um formato de
entrada para outro formato de saída. Ao processo de converter um tipo comprimido para
descomprimido, chama-se Decodificação (Decoding). Ao inverso, Codificação (Encoding).
Denomina-se ainda Apresentação (Rendering), ao processo de mostrar a mídia ao usuário.