Transmissão multimídia em redes de
computadores
Autor: Valter Roesler
Universidade: UNISINOS
SUMÁRIO
1 Transmissão multimídia em redes... 3
1.1 Latência ... 4
1.2 Jitter ... 4
1.3 Skew ... 5
1.4 Tabela comparativa ... 5
2 Protocolos de tempo real para transmissões multimídia ... 6
2.1 RTP... 6
2.1.1 Entidades RTP ... 7
2.1.2 Cabeçalho RTP ... 8
2.1.3 Exemplo: conferência de áudio ... 8
2.1.4 Exemplo: videoconferência ... 9
2.2 RTCP ... 9
2.2.1 SR (Sender Report) ... 10
2.2.2 RR (Receiver Report) ... 11
2.2.3 SDES (Source Description) ... 11
2.2.4 BYE... 12
2.2.5 APP... 12
2.2.6 Restrições de tempo nos pacotes RTCP... 12
3 Padrões de multimídia em redes de computadores ... 12
3.1 H.323 ... 13 3.1.1 Terminais... 14 3.1.2 Gatekeepers ... 16 3.1.3 Gateways ... 16 3.1.4 MCUs ... 17 3.1.5 Sinalização no H.323... 18 3.1.6 Exemplo de conferência H.323 ... 19 3.1.6.1 Exemplos de Terminais H.323 ... 19 3.1.6.2 Exemplos de Gatekeepers ... 19 3.1.6.3 Exemplos de Gateways ... 19 3.1.6.4 Exemplos de MCUs... 19 3.2 SIP ... 19
3.3 Comparação entre SIP e H.323 ... 20
3.3.1 Atraso de conexão ... 20
3.3.2 Escalabilidade... 20
3.3.3 Tamanho da conferência ... 20
3.3.4 Uso de novos CODECS ... 21
3.3.5 Formato de endereço ... 21
3.3.6 Complexidade... 21
4 Compressão de áudio e vídeo ... 21
5 Padrões de áudio e vídeo ... 22
5.1 Codificação de áudio ... 23
5.1.1 Testes de áudio com Netmeeting ... 24
5.1.2 Testes de áudio com o RAT (Robust Audio Tool) ... 25
5.1.3 Teste de tamanho de arquivo de áudio com o Goldwave ... 26
5.2 Codificação de vídeo ... 26
5.2.1 Codificação de vídeo no M-JPEG... 28
5.2.2 Codificação de vídeo no MPEG ... 28
5.2.3 Resumo de padrões para codificação de vídeo... 30
6 Estudo de caso 1: Transmissão multicast ao vivo durante a VI Semana da Qualidade na Unisinos... 31
7 Estudo de caso2: Videoconferência multicast no Metropoa ... 33 8 Bibliografia... 34
1 Transmissão multimídia em redes
As etapas de uma transmissão multimídia são mostradas na figura a seguir: Digitalização
Sinal de
entrada Compressão Transmissão
Perda / atraso Reordenação Descompressão Recuperação Sinal de saída
O sinal gerado é inicialmente digitalizado, para então passar por um processo de compressão, que diminui seu tamanho, tornando-o viável para ser transmitido na rede. A rede insere alguns atrasos no sistema. No receptor, os pacotes são reordenados, descomprimidos e reconvertidos ao estado original, normalmente com perdas inseridas no processo de compressão. Esses aspectos serão analisados no decorrer desta apostila.
As aplicações que necessitam transmissão multimídia em redes de computadores se encontram subdivididas em duas partes, como a figura a seguir ilustra: teleconferência (que requer interatividade) e transmissão unidirecional (que envolve apenas um lado transmitindo e vários clientes recebendo). Na figura, pode-se ver uma divisão dos dados em áudio, vídeo e texto. Aplicações multimídia Vídeo Conferências (interatividade) Transmissão Unidirecional Áudio Texto
Apesar das aplicações possuírem necessidades diferentes, existe uma tendência atualmente para sua convergência em um único meio físico. Assim, se unificaria o meio físico, que compartilharia a transmissão de voz, vídeo, dados, imagens, músicas, e tudo que possa ser transformado em bits.
Entretanto, as aplicações têm características e requisitos bem diferentes umas das outras. Aplicações de teleconferência possuem necessidades mais rígidas em relação à latência e jitter do que aplicações de transmissão unidirecional. Da mesma forma, transmissões de vídeo necessitam uma largura de banda muito maior que transmissões de áudio ou texto.
A seguir serão definidos três conceitos fundamentais para o entendimento da transmissão multimídia nas redes de computadores: latência, jitter e skew. Em seguida esses conceitos serão comparados entre si dentro das necessidades das aplicações.
1.1 Latência
Latência é o tempo que um pacote leva da origem ao destino. Caso esse atraso seja muito grande, prejudica uma conversação através da rede, tornando difícil o diálogo e a interatividade necessária para certas aplicações. Segundo [PAS 97a] e [PAU 98, pg 9], um atraso confortável para o ser humano fica na ordem de 100ms.
Suponha duas pessoas conversando através da Internet. À medida que o atraso aumenta, as conversas tendem a se entrelaçar, ou seja, uma pessoa não sabe se o outro a ouviu e continua falando. Após alguns milisegundos, vem a resposta do interlocutor sobre a primeira pergunta efetuada, misturando as vozes. Num atraso muito grande, as pessoas devem começar a conversar utilizando códigos, tipo “câmbio”, quando terminam de falar e passam a palavra ao outro.
Os principais responsáveis pela latência são o atraso de transmissão, de codificação e de empacotamento, que podem ser definidos da seguinte forma:
• Atraso de transmissão: tempo que leva para o pacote sair da placa de rede do computador origem e chegar na placa de rede do computador destino. Esse tempo envolve uma série de fatores, como por exemplo:
1. Atraso no meio físico: é o atraso de propagação da mensagem no meio de transmissão, e varia bastante. Por exemplo, num enlace de satélite o tempo típico é de 250ms, e numa fibra ótica ou UTP o atraso é na ordem de 5µs/Km [TAN 97, pg 107] e [SPU 00, pg /**/].
2. Atrasos de processamento nos equipamentos intermediários, como roteadores e switches;
3. Atraso devido ao tempo de espera nas filas de transmissão dos equipamentos intermediários: esse valor depende do congestionamento da rede no momento, e varia bastante, dependendo do tamanho da fila. Quanto menor a fila, menor o atraso, mas aumenta a probabilidade de descarte do pacote no caso de congestionamento;
• Atraso de codificação e decodificação: tempo de processamento na máquina origem na máquina destino para codificação e decodificação de sinais, respectivamente. Voz e vídeo normalmente são codificados em um padrão, tal como PCM (G.711 a 64Kbps) para voz, ou H.261 para vídeo. O atraso varia com o padrão adotado; por exemplo, o G.711 ocupa menos de 1ms de codificação ([PAS 97a]), porém requer 64Kbps de banda. Um protocolo de voz como o G.729 requer 25ms de codificação, mas ocupa apenas 8Kbps de banda ([PAS 97a]);
• Atraso de empacotamento e desempacotamento: depois de codificado, o dado deve ser empacotado através dos níveis na pilha de protocolos a fim de ser transmitido na rede. Por exemplo, numa transmissão de voz a 64Kbps, ou 8000 bytes por segundo, o preenchimento de um pacote de dados com apenas 100 bytes toma 12,5ms. Mais 12,5ms serão necessários no destino a fim de desempacotar os dados.
Além disso, dependendo do jitter da transmissão, a aplicação de tempo real deverá criar um buffer para homogeneizar a entrega de pacotes ao usuário, criando um novo atraso no sistema.
1.2 Jitter
Apenas latência não é suficiente para definir a qualidade de uma transmissão, pois as redes não conseguem garantir uma entrega constante de pacotes ao destino. O jitter é a variação estatística do retardo, que altera o fluxo de chegada dos pacotes. O conceito de jitter e latência é ilustrado na figura a seguir.
t latência
jitter N. de
Pacotes
A conseqüência do jitter é que a aplicação no destino deve criar um buffer cujo tamanho vai depender do jitter, gerando mais atraso na conversação (aplicação de voz, por exemplo). Esse buffer vai servir como uma reserva para manter a taxa de entrega constante no interlocutor. Daí a importância de latência e jitter baixos em determinadas aplicações sensíveis a esses fatores, como teleconferência.
1.3 Skew
O skew é um parâmetro utilizado para medir a diferença entre os tempos de chegada de diferentes mídias que deveriam estar sincronizadas, como mostra a figura a seguir. Em diversas aplicações existe uma dependência entre duas mídias, como áudio e vídeo, ou vídeo e dados. Assim, numa transmissão de vídeo, o áudio deve estar sincronizado com o movimento dos lábios (ou levemente atrasado, visto que a luz viaja mais rápido que o som, e o ser humano percebe o som levemente atrasado em relação à visão). Outro exemplo em que sincronização é necessária é na transmissão de áudio (manual explicativo, por exemplo) acompanhada de uma seta percorrendo a imagem associada.
skew N. de Pacotes chegando t vídeo áudio
1.4 Tabela comparativa
A tabela a seguir apresenta algumas aplicações típicas de multimídia em rede, bem como seus fatores críticos. Aplicações de telefonia (voz) são sensíveis à latência e ao jitter. Em termos de velocidade, sua necessidade é baixa, variando de 5 Kbps (compressão no padrão G.723) a 64Kbps (padrão G.711, o mais comum em telefonia atualmente).
Telefone TV Videoconferência
latência sensível insensível sensível
jitter sensível sensível sensível
skew - sensível sensível
Já em transmissões unilaterais de áudio e vídeo (por exemplo, TV), há uma flexibilidade maior quanto à latência. Isso se deve ao fato que, na maioria dos casos, para o usuário não seria relevante a inclusão de um pequeno atraso entre o momento em que um evento se dá e sua exibição. Entretanto, esse atraso deve se manter fixo até o final e com sincronismo entre áudio e vídeo, daí a necessidade de jitter e skew baixos.
Aplicações de videoconferência são muito parecidas com aplicações de telefonia em termos de latência e jitter, entretanto, possuem alta largura de banda e devem manter um baixo skew, pois necessitam sincronização entre áudio e vídeo.
2 Protocolos de tempo real para transmissões multimídia
Para transportar dados em tempo real, são necessários protocolos que levem consigo informações de sincronismo e de tempo, como o RTP (Real-time Transport Protocol). Para fornecer feedbacks aos participantes da transmissão efetuada pelo RTP, existe o protocolo RTCP (RTP Control Protocol). Ambos são analisados a seguir.
2.1 RTP
O protocolo RTP (Real-time Transport Protocol), descrito na RFC 1889, especifica um formato para transmissão de dados em tempo real, tais como áudio, vídeo ou dados de simulação. Alguns benefícios obtidos por esse protocolo (que serão detalhados no decorrer deste item) são [PAU 98, pg 197]:
• Detecção de perda de pacotes: observando o número de seqüência é possível saber se houve perda de pacotes ou não. Isso é útil para estimar a qualidade da recepção, adaptação da aplicação às características da rede, recuperação de dados, e assim por diante;
• Sincronização intra -mídia: o campo de timestamp do cabeçalho informa ao receptor o momento exato de passar os dados ao usuário. Essa informação é usada pelo receptor absorver o jitter da rede através de um buffer auxiliar;
• Sincronização inter-mídia: o campo de timestamp do cabeçalho de diferentes sessões RTP (como áudio e vídeo) pode ser usado em conjunto com o protocolo NTP (Network Time Protocol) a fim de sincronizar as diferentes mídias, permitindo ao receptor a adaptação ao skew. Um exemplo típico é o sincronismo voz-lábio. Outro é o sincronismo de uma seta na tela apontando objetos de acordo com um texto falado.
A garantia de entrega do pacote ou a qualidade de serviço da rede não são especificadas no RTP, e devem ser obtidas através de outro mecanismo de entrega, como o RSVP, Diffserv ou outro.
O RTP é utilizado para transportar dados em tempo real, e utiliza o RTCP para
monitorar a qualidade de serviço (da sessão e não da rede) e levar informações sobre os
participantes de uma sessão em andamento, como, por exemplo, uma conferência de áudio entre diversos participantes.
Em termos do modelo OSI, o RTP se situa acima do nível 4, no subnível inferior do nível de aplicação, como mostra a figura a seguir [PAU 98, pg 194]. O IP pode ser tanto unicast como multicast, e o protocolo de nível 2 (Ethernet) é apenas um exemplo.
Aplicação Encapsulamento de mídia RTP RTCP UDP IPv4 / IPv6 Unicast ou multicast Ethernet dados controle 2.1.1 Entidades RTP
Às vezes surgem necessidades na transmissão de sinais em tempo real, como, por exemplo, várias pessoas participando duma conferência de áudio, sendo que algumas estão em enlaces congestionados ou com máquinas lentas. Para evitar que todos participantes utilizem um algoritmo de compactação de áudio de baixa qualidade, pode-se utilizar um tradutor (translator). Outras vezes, pode ser necessário combinar múltiplos fluxos em um só, a fim de distribuir a um conjunto de receptores, e aí se utiliza o multiplexador (mixer). Essas duas entidades são importantes para entender o RTP, e são mostradas na figura [PAU 98, pg 195].
Sistema origem / destino IP=10.16.169.53 SSRC = 87
Sistema origem / destino IP=10.16.165.29 SSRC = 35 Tradutor Multiplexador PCM ADPCM IP 10.13.45.6 MP3 MP3 IP 10.18.32.14 SSRC = 46 SSRC = 46 CSRC = 87, 35 Fluxo único Múltiplos fluxos Troca de codificação
O tradutor é um sistema intermediário que encaminha os pacotes RTP com o SSRC e timestamp intactos, porém, modifica serviços de tradução, como, por exemplo, a conversão do formato de codificação (ADPCM para MP3), ou converter um pacote multicast em vários pacotes unicast, ou efetuar uma conexão segura com máquinas atrás de firewalls.
O multiplexador é um sistema intermediário que recebe pacotes RTP de uma ou mais origens, gerando uma única saída com a combinação das diversas origens (e também a tradução de formato de codificação, se necessário). Como o timestamp das diversas origens pode ser diferente, o multiplexador efetua os ajustes de tempo (buffers) e gera sua própria seqüência de tempo para o fluxo concatenado. Assim, todas os pacotes de dados originados no multiplexador terão o multiplexador como sua origem de sincronização (SSRC).
2.1.2 Cabeçalho RTP
O cabeçalho do RTP é visto na figura a seguir.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
M
V=2 P X CC PT Número de seqüência
Timestamp
1 2 3
Synchronization Source (SSRC) identifier Contributing Source (CSRC) identifiers
Os primeiros doze bytes existem em todo pacote RTP, enquanto que a lista dos identificadores CSRC está presente somente quando inserido por um multiplexador. Os campos têm o seguinte significado [RFC 1889, pg 10]:
• Versão (V): 2 bits : identifica a versão do protocolo RTP;
• Padding (P): 1 bit: se esse bit estiver ligado, o pacote contém um ou mais bytes de enchimento no final que não fazem parte dos dados úteis, devendo ser ignorados. Esses bytes podem ser necessários por alguns algoritmos de criptografia com tamanhos fixos de blocos, ou para enviar muitos pacotes RTP em um protocolo de nível inferior;
• Extensão (X): 1 bit: se esse bit estiver ligado, o cabeçalho terá uma extensão com o mesmo número de bytes, em formato definido na RFC 1889;
• Contador de CSRC (CC): 4 bits : número de identificadores CSRC que seguem o tamanho fixo do cabeçalho;
• Marcado r (M): 1 bit: tem o objetivo de permitir eventos significativos, tal como limites de quadro, serem marcados no fluxo de pacotes;
• Payload Type (PT): 7 bits : identifica o formato da carga útil do pacote, de forma que possa ser interpretado pela aplicação. Um exemplo é áudio codificado em PCM ou ADPCM, ou vídeo codificado em MPEG ou H.263, e assim por diante;
• Número de seqüência: 16 bits : incrementa de um a cada pacote RTP transmitido, e pode ser usado pelo receptor para detectar perda de pacotes, bem como para restaurar a seqüência correta do fluxo;
• Timestamp: 32 bits : reflete o instante de amostragem do primeiro byte no pacote de dados do RTP. O instante de amostragem deve derivar de um relógio que incrementa linearmente no tempo a fim de permitir sincronização e cálculo de jitter. A resolução do relógio deve ser suficiente para a precisão de sincronização desejada e medição de jitter;
• SSRC: 32 bits: identifica a origem da sincronização. Esse número é escolhido randomicamente, procurando fazer com que todas as fontes de sincronização tenham
identificadores diferentes. Caso haja colisões, o SSRC é modificado de acordo com um
algoritmo determinado na RFC 1889;
• CSRC: 32 bits cada identificador: máximo de 15 itens : identifica as fontes que contribuíram para a carga de dados existente no pacote RTP. Esses campos são inseridos por multiplexadores, usando os SSRCs das fontes contribuintes. Assim, por exemplo, para pacotes de áudio de várias fontes que foram multiplexados em pacotes únicos RTP, o receptor utiliza esse campo para colocar de forma correta quem falou o quê.
2.1.3 Exemplo: conferência de áudio
Um exemplo de uso do RTP é visto na RFC 1889 (pg 5), onde ele é utilizado para efetivação de uma conferência de áudio em multicast. No início são alocados duas portas UDP (uma para dados RTP e outra para controle RTCP) e um endereço IP multicast. Essa informação é transmitida para todos os participantes. A aplicação utilizada pelos participantes envia áudio
em pequenos pedaços de 20ms de duração, cada um deles com um cabeçalho RTP, que é transmitido via UDP na porta especificada anteriormente.
O cabeçalho RTP indica o tipo de codificação de áudio (PCM, ADPCM, MP3) que está contida no pacote, a fim de que os participantes possam trocar a codificação para permitir a entrada de um novo participante que está conectado através de uma linha lenta.
Para pacotes que chegam em ordem trocada, o número de seqüência ajuda na reorganização da informação. Já para atrasos variáveis na rede, a informação de timestamp vai ajudar o receptor a dimensionar o buffer de recepção, a fim de evitar truncamentos na conversa. Além disso, o receptor sabe que cada número de seqüência corresponde a 20ms nesse exemplo, permitindo a ele reconstruir o tempo produzido pela fonte.
Para saber quem está participando da conferência e quão bem está recebendo áudio, a aplicação de cada pessoa envia uma mensagem multicast periodicamente para a porta RTCP do grupo, indicando seu nome e a qualidade com que está recebendo a informação.
Para deixar a conferência, a aplicação envia um pacote RTCP BYE, indicando que está saindo.
/**/ sniffar uma conferência de áudio com RTP e colocar figura aqui.
2.1.4 Exemplo: videoconferência
Numa videoconferência, os pacotes de áudio e vídeo são transmitidos em sessões RTP separadas, portanto, existem dois pares diferentes de portas UDP e números IP (unicast ou multicast). A identificação do acoplamento entre as mídias no receptor é obtida através do nome canônico utilizado pelo protocolo RTCP.
Uma das motivações para esta separação é permitir a alguns participantes na conferência receber somente um meio (áudio ou vídeo). A sincronização entre áudio e vídeo pode ser obtida através do timestamp de ambas sessões, juntamente com a utilização do protocolo NTP (Network Time Protocol), enviado pelo RTCP (pacote SR – Sender Report).
O NTP utiliza um valor de tempo absoluto, que é o número de segundos relativo à 0h de 1o de janeiro de 1900.
/**/ /* sniffar videoconferência – identificar pacotes RTCP e forma de sincronização inter-mídia. */
2.2 RTCP
O protocolo RTCP (RTP Control Protocol) tem por objetivo fornecer feedback sobre a qualidade de serviço obtida na distribuição de dados RTP, e consegue isso através de transmissões periódicas de pacotes de controle a todos participantes da sessão RTP, utilizando o mesmo mecanismo de distribuição do RTP (unicast ou multicast), e possuindo uma porta específica de controle na sessão, conforme descrito anteriormente. Suas funções são [RFC 1889, pg 15]:
• Fornecer feedback sobre a qualidade de serviço obtida na distribuição de dados RTP. Exemplos de utilização são: controle de codificadores adaptativos (muda algoritmo de compactação dependendo da qualidade), diagnóstico de problemas na rede, e outros;
• Enviar o nome canônico (CNAME) do transmissor dos dados, utilizado para que todos saibam quem originou a transmissão. O uso do SSRC para identificar a origem não é eficaz, visto que pode haver mudança nesse número em caso de conflitos. Além disso, um transmissor com múltiplas sessões RTP (áudio e vídeo) utiliza um SSRC para cada sessão, e o receptor precisa um nome canônico para identificar a origem e poder sincronizar as sessões;
• Controle da periodicidade de envio dos pacotes RTCP, a fim de permitir a escalabilidade do sistema;
• Função opcional para permitir o transporte de informações mínimas de controle, permitindo, por exemplo, que a identificação de cada participante seja apresentada na interface com o usuário.
Os principais tipos de pacotes utilizados pelo RTCP são o SR (Sender Report), o RR (Receiver Report), o SDES (Source Description), o BYE e o APP (funções específicas da aplicação). Os itens a seguir analisam cada um deles com mais detalhes.
2.2.1 SR (Sender Report)
Os pacotes SR (Sender Report) são enviados pelos transmissores, e contém informações de timestamp NTP, timestamp RTP, número de pacotes enviados, número de bytes enviados, bem como informações da qualidade dos outros transmissores que chegam a eles. Com os timestamps (NTP e RTP), o receptor consegue sincronizar mais de uma sessão relacionada (como áudio e vídeo). A figura a seguir ilustra o formato do pacote SR [RFC 1889, pg 23].
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| RC | PT=SR=200 | length | header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | NTP timestamp, most significant word | sender +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ info | NTP timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's packet count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender's octet count | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_1 (SSRC of first source) | report +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block | fraction lost | cumulative number of packets lost | 1 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extended highest sequence number received | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | last SR (LSR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last SR (DLSR) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC_2 (SSRC of second source) | report +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block : ... : 2 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | profile-specific extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Os pacotes SR consistem de 3 seções: um cabeçalho de 8 bytes, uma seção de informações do transmissor, e uma seção de informações de outros transmissores. No final, é possível ainda a existência de uma quarta seção contendo extensões específicas de perfil. Esta seção não será explicada neste documento. Os principais campos são explicados a seguir. Para maiores informações, uma referência é a RFC 1889.
• Versão (V): 2 bits: Identifica a versão do RTP, que é a mesma do RTCP, que é 2;
• Padding (P): 1 bit: ver RFC 1889;
• Reception Report Count (RC): 5 bits: número de blocos de informações de outros transmissores;
• Packet Type (PT): 8 bits: valor “200”, identifica pacote RTCP SR;
• Length: 16 bits: tamanho deste pacote em palavras de 32 bits menos uma. Este tamanho inclui o cabeçalho;
• SSRC: 32 bits: identificador SSRC do transmissor deste pacote;
• NTP timestamp: 64 bits: indica o tempo NTP do momento que este pacote foi enviado;
• RTP timestamp: 32 bits: corresponde ao mesmo momento do campo NTP, mas nas mesmas unidades e offset dos pacotes de dados RTP. Com a correspondência do tempo entre NTP e RTP, é possível efetuar sincronização intermídia;
• Sender’s packet count: 32 bits: o número total de pacotes de dados transmitidos desde o início da transmissão;
• Sender’s octet count: 32 bits: número total de bytes de dados úteis (i.e., sem incluir cabeçalho) transmitidos desde o início da transmissão. Este campo pode ser usado para estimar a taxa de transmissão média dos dados úteis;
• SSRC_n (source identifier): 32 bits: indica o SSRC do transmissor para o qual este report está sendo gerado. O transmissor envia um bloco com estatísticas de cada
transmissor que ele ouviu desde o último report.
• Fraction lost: 8 bits: fração de pacotes de dados perdidos desde o último report. Esta fração é igual a “número de pacotes perdidos” dividido pelo “número de pacotes esperado”;
• Cumulative number of packets lost: 24 bits: o número total de pacotes de dados RTP perdidos desde o início da recepção;
• Extended highest sequence number received: 32 bits: ver RFC 1889;
• Interarrival jitter: 32 bits: estimativa da variação do tempo de chegada dos pacotes RTP, medido em unidades do timestamp e expresso em um valor inteiro.
• Last SR timestamp (LSR) e outros campos: ver RFC 1889.
/**/ sniffar a rede e capturar pacotes RTCP de uma videoconferência, identificando os campos */
2.2.2 RR (Receiver Report)
Os pacotes RR (Receiver Report) são enviados pelos receptores das sessões RTP existentes. O formato do pacote RR é o mesmo do SR, exceto que o tipo de pacote é “201” em vez de “200” e a seção “sender info” é eliminada (cinco palavras contendo os timestamps NTP e RTP, bem como a contagem de pacotes e bytes enviados pelo transmissor).
2.2.3 SDES (Source Description)
Pacotes SDES (Source Description) contêm informações específicas do transmissor, identificadas por seu tipo. Estão definidos os seguintes tipos [RFC 1889, pg 34]:
• Tipo = 1: CNAME: nome canônico, que identifica univocamente o transmissor, como, por exemplo, user@domínio;
• Tipo = 2: NAME: nome do transmissor, por exemplo “João da Silva, empresa X”;
• Tipo = 3: EMAIL: e- mail do transmissor, por exemplo [email protected];
• Tipo = 4: PHONE: telefone do transmissor, identificado com o sinal de “+” para o código internacional. Por exemplo +55 51 991 56118;
• Tipo = 5: LOC: localização geográfica, por exemplo “Porto Alegre, RS”;
• Tipo = 6: TOOL: nome e versão da ferramenta utilizada para transmitir, por exemplo “videotool”;
• Tipo = 7: NOTE: informação a ser transmitida no momento, como por exemplo, para enviar o título da palestra sendo efetuada. Essa informação é dependente de perfil, e pode ser mudada dependendo da aplicação;
• Tipo = 8: PRIV: extensões privativas para testes.
2.2.4 BYE
O pacote de BYE indica que um transmissor está deixando a sessão. Existe um campo opcional de comprimento variável para indicar o motivo da saída.
2.2.5 APP
Pacote destinado a uso experimental à medida que novas aplicações surgem, possuindo um tipo=“204” e um subtipo descrevendo o tipo de aplicação experimental.
2.2.6 Restrições de tempo nos pacotes RTCP
O protocolo RTCP gera pacotes de controle, e, caso não houvesse restrições, poderia sobrecarregar a rede numa sessão com um grande número de participantes. Procurando se adaptar a isso, o tráfego de controle RTCP deve se manter em torno de 5% do tráfego total de determinada sessão RTP. 25% deste tráfego (1,25% do total) é destinado aos transmissores (pacotes SR+RR+SDES) e os 75% restantes (3,75% do total) aos receptores (pacotes RR).
Como o tráfego de controle é uma fração constante do tráfego total, à medida que o número de receptores aumenta, o número de pacotes RTCP por participante diminui [PAU 98, pg 200].
O intervalo mínimo sugerido entre pacotes RTCP é de 5 segundos (para evitar excesso de pacotes RTCP), mas numa sessão, o intervalo pode ir de 2 a 5 minutos. Um receptor deve desconsiderar um participante da estatística caso ele não se manifeste em 30 minutos.
Um pacote RTCP é transmitido após o tempo calculado vezes um tempo randômico entre 0,5s e 1,5s. Isso é para evitar sincronização de pacotes entre várias entidades (transmissores e receptores), o que ocasionaria uma rajada de tráfego RTCP naquele mo mento.
3 Padrões de multimídia em redes de computadores
Existem muitos padrões atualmente para multimídia em redes de computadores, e os mais enfatizados neste documento são os do ITU-T e do IETF.
Os padrões de multimídia do ITU-T são os da série H (“Sistemas audiovisuais e de
multimídia”) e estão citados na tabela a seguir. Cada um deles tem uma finalidade específica, como o H.323, por exemplo, que trata somente da comunicação multimídia em redes de pacotes.
Padrão Data Descrição
H.310 1996 Broadband audiovisual communication systems and terminals: videoconferência MPEG-2 sobre ATM com alta qualidade
H.320 1997 Narrow-band visual telephone systems and terminal equipment: videoconferência sobre RDSI
H.321 1996 Adaptation of H.320 visual telephone terminals to B-ISDN
environments: videoconferência sobre ATM com boa qualidade
H.322 1996 Visual telephone systems and terminal equipment for local area
networks which provide a guaranteed quality of service: /**/ H.323 1998 Packet based multimedia communications systems:
videoconferência sobre redes de pacotes, como IP e Ethernet H.324 1996 Terminal for low bit rate multimedia communication:
videoconferência sobre sistema telefônico
Cada um dos protocolos da série H especifica um conjunto de outros protocolos para resolver funções específicas na rede, como, por exemplo, sinalização, codificação de áudio, codificação de vídeo, e assim por diante. É como se fosse um guarda-chuva, ou seja, um protocolo que aponta para diversos outros. Quando o H.323 for analisado isso vai ficar mais claro.
Os padrões multimídia do IETF são definidos nas RFCs. A arquitetura global de
multimídia do IETF atualmente possui protocolos como os seguintes [RFC 2543, pg 8]:
• SIP (Session Initiation Protocol – RFC 2543): estabelece, mantém e encerra chamadas ou sessões multimídia;
• RSVP (Resource Reservation Protocol – RFC 2205): reserva recursos da rede;
• RTP (Real-time Transport Protocol – RFC 1889): transporta dados em tempo real, proporcionando feedback de QoS através do RTCP (RTP Control Protocol), conforme descrito anteriormente;
• RTSP (Real Time Streaming Protocol – RFC 2326): controla entrega de mídia através de streaming;
• SDP (Session Description Protocol – RFC 2327): descreve sessões multimídia.
Os padrões do ITU-T e do IETF conseguem conversar entre si através de gateways. A seguir será analisado com maiores detalhes o protocolo do ITU para comunicação multimídia sobre redes de pacotes (o H.323). No item seguinte, o SIP será analisado, e depois será feita uma comparação entre SIP e H.323 em relação a sinalização e controle, pois ambos são equivalentes nesse assunto.
3.1 H.323
A recomendação H.323 especifica um conjunto de protocolos de áudio, vídeo e dados a serem utilizados sobre redes baseadas em pacotes, sejam elas LANs, MANs ou WANs. Exemplos podem ser redes TCP/IP, tipo a Internet, ATM, ou redes locais Ethernet, Fast- Ethernet e Token Ring. Essas redes não precisam necessariamente prover garantia de qualidade de serviço (QoS) [ITU 98]. Essa recomendação teve sua segunda versão aprovada em fevereiro de 1998, pelo grupo de estudos 16 do ITU-T.
As principais características do H.323 são as seguintes [PRI 99]:
• Interoperabilidade : definindo normas de CODECs de áudio e vídeo, é possível integrar sistemas de diferentes fabricantes sem problemas;
• Gerência de banda : é possível limitar o número de conexões H.323 simultâneas, bem como a largura de banda utilizada pelas aplicações;
• Suporte a multiponto: embora H.323 possa suportar conferências com três ou mais pontos, é especificado um componente chamado MCU (Multipoint Control Unit) a fim de tornar mais poderosas e flexíveis tais conferências;
• Suporte a multicast: extremamente importante para economizar banda em conferências e transmissões multiponto;
• Flexibilidade : Uma conferência H.323 pode incluir equipamentos e redes com diferentes características. Por exemplo, um participante pode entrar na conferência somente com áudio, e outro somente com dados, via um terminal que fale a recomendação T.120 do ITU-T (Data protocols for multimedia conferencing).
A figura a seguir mostra uma visão geral da arquitetura H.323, sua interoperabilidade com outros terminais e seus principais componentes, que são os Terminais, Gateways, Gatekeepers e
MCUs (Multipoint Control Units) [PRI 99].
O conjunto de terminais H.323, gateways e MCUs controlados por um Gatekeeper é conhecido como zona H.323, e é mostrado na figura. O Gateway serve para tradução de padrões, ligando a zona H.323 com outros serviços, tais como o GSTN (General Switched Telephone Network ), o RDSI (Rede Digital de Serviços Integrados faixa estreita ou faixa larga), e redes locais com QoS (Quality of Service).
A seguir cada um desses componentes será explicado com maiores detalhes.
Terminal H.310 operando no modo H.321 Terminal H.323 Terminal H.323 Gateway H.323 Gatekeeper H.323 MCU H.323 Terminal H.323 HUB Rede baseada em pacotes
Terminal H.321 Terminal V.70 Terminal H.324 Terminal de voz Terminal H.322 Terminal de voz Terminal H.320 Terminal H.321
GSTN LAN comQoS RDSI-FE RDSI-FL
3.1.1 Terminais
Terminais são os componentes responsáveis pela comunicação bidirecional em tempo real com outro terminal, gateway ou MCU. Um terminal pode oferecer somente voz, voz e vídeo, voz e dados ou voz, dados e vídeo. A norma definiu que voz é obrigatório, mas dados e vídeo são opcionais. A figura a seguir mostra a recomendação H.323 para terminais [ITU 98, pg 13].
Escopo da norma H.323
Eqto de entrada de vídeo Câmera de vídeo, vídeo
cassete)
Aplicações de dados (T.120, etc) Eqto de entrada de áudio (microfone, vídeo cassete)
Controle do sistema CODEC de áudio G.711, G.722, G.723, G.728, G.729 CODEC de vídeo H.261, H.263 Receive Path Delay Camada H.225.0 Interface LAN Controle do sistema Controle H.245 Controle de chamada H.225.0 Controle RAS H.225.0 Sinalização Q.931
Todos terminais H.323 devem ter uma camada H.225.0, uma unidade de controle do
sistema (H245, RAS), uma interface LAN e CODEC de áudio. O CODEC de vídeo e as
aplicações de dados são opcionais [ITU 98, pg 13]. O canal de controle H.245, os canais de dados e o canal de sinalização da chamada precisam obrigatoriamente de um protocolo confiável (por exemplo, TCP ou SPX). Já os protocolos de áudio, vídeo e RAS (Registration, Admission and Status) precisam de um protocolo não confiável (por exemplo, UDP ou IPX). A seguir uma definição dos elementos da figura anterior (posteriormente os principais protocolos serão detalhados):
• CODEC de vídeo (H.261, H.263): codifica o vídeo vindo da fonte (por exemplo, placa de captura de vídeo) para transmissão. O receptor joga o sinal decodificado para a tela de vídeo do usuário. A transmissão de vídeo e, conseqüentemente, esse CODEC, é opcional, mas caso exista, o terminal deve prover, no mínimo, H.261 QCIF (Quarter Common Intermediate Format);
• CODEC de áudio (G.711, G.722, G.723, G.728, G.729): codifica o áudio vindo da fonte (por exemplo, microfone) para transmissão. No receptor joga o sinal decodificado para o alto- falante do sistema. Todo terminal H.323 deve ter, no mínimo, o CODEC para a recomendação G.711, entretanto, em linhas de baixa velocidade (<56Kbps), o G.711 não funciona, portanto, tais terminais devem suportar ou o G.723 ou o G.729 [ITU 98, pg 16];
• Canal de dados: suporta aplicações tipo whiteboard, transferência de imagens estáticas, transferência de arquivos, acesso a banco de dados, e outros;
• Unidade de controle do sistema (H.245, H.225.0): fornece sinalização para operação do terminal H.323. Fornece controle de chamada, sinalização de comandos e indicações, e assim por diante. Através da negociação do protocolo H.245, é possível usar outros CODECs de vídeo e outros formatos de imagem. Além disso, mais de um canal de vídeo pode ser transmitido ou recebido (para enviar o palestrante e a platéia simultaneamente, ou para receber todos os participantes de uma conferência). Durante o estabelecimento da
conexão, são trocadas mensagens de sinalização H.245 “capability exchange”, para descobrir a capacidade dos terminais, o que permite a escolha da taxa de transmissão em bits/s, o formato da imagem, algoritmo de compactação, e assim por diante [ITU 98, pg 15];
• Controle de RAS (Registration, Admission and Status): utiliza mensagens H.225.0 para fazer funções de registro, admissão, mudança de largura de banda, status e desligamento entre Gatekeepers e terminais. Em ambientes que não tem Gatekeeper, o RAS não é utilizado;
• Camada H.225.0: formata as informações (vídeo, áudio, dados) a serem transmitidas ou recebidas da interface de rede. Além disso, faz controle de erros e numeração de seqüência, dependendo do meio. A norma H.225.0 [ITU 98a] utiliza os protocolos
RTP e RTCP [RFC 1889] para sincronização e montagem dos pacotes;
• Receive Path Delay: é um atraso incluído no fluxo de entrada de dados a fim de manter a sincronização e controlar o jitter, conseguindo assim, por exemplo, sincronização labial.
3.1.2 Gatekeepers
O gatekeeper é opcional em um sistema H.323, provendo, quando utilizado, os seguintes serviços de controle de chamada para componentes H.323:
• Tradução de endereço: é necessário traduzir o endereço LAN dos terminais e gateways (aliases mais fáceis de decorar) para endereços IP ou IPX, conforme a especificação do RAS;
• Controle de admissão: Autorização de acesso à LAN usando mensagens de “admission request, confirm e reject” (ARQ, ARC, ARJ);
• Gerência de zona : o gatekeeper provê as funções acima para sua zona. O conjunto de todos terminais, gateways e MCUs controlados por um gatekeeper é conhecido como zona H.323, como mostra a figura a seguir [PRI 99].
• Controle e Gerência de banda : se um gerente especificou um número máximo de conferências na rede, o gatekeeper pode deixar de aceitar conexões após esse máximo ter sido atingido, limitando a largura de banda utilizada pelo H.323 como um todo;
Zona H.323
HUB HUB
Terminal Gatekeeper Gateway
Terminal Terminal Roteador Roteador
Terminal Terminal
MCU
3.1.3 Gateways
O Gateway também é opcional em um sistema H.323, sendo utilizado quando é necessário efetuar conversão entre formatos para permitir a comunicação entre terminais H.323 e outros tipos. Essa função inclui conversão de formatos de transmissão (por exemplo, H.225 para/de H.221), e formatos de comunicação (por exemplo, H.245 para/de H.242). A figura a seguir mostra um exemplo de uso do gateway interligando um terminal H.323 e a telefonia pública.
As principais aplicações do gateway são as seguintes [PRI 99]:
• Estabelecer links com terminais analógicos da telefonia pública;
• Estabelecer links através de redes RDSI com terminais compatíveis H.320;
• Estabelecer links através de redes públicas de telefonia com terminais compatíveis H.324.
3.1.4 MCUs
O Multipoint Control Unit também é um elemento opcional, seu objetivo é permitir conferências entre três ou mais usuários. No H.323, um MCU consiste de um Multipoint Controller (MC) e zero ou mais Multipoint Processors (MPs). Isso é importante principalmente para conferências multicast, que são controladas por ele. O fluxo de áudio e vídeo é processado pelo MP.
MC e MP podem existir como componentes separados ou serem implementados junto com outros componentes H.323. Pode haver conferências de dois tipos: centralizada e
descentralizada [ITU 98, pg 5].
Uma conferência multiponto descentralizada utiliza multicast para enviar dados entre os participantes, não necessitando MP para isso, entretanto, a parte de controle é feita utilizando o protocolo H.245 para um MC, que gerencia a conferência.
Uma conferência multiponto centralizada é aquela onde cada um dos terminais participantes envia sinalização de controle, áudio, vídeo e dados para o MCU. O MC do MCU gerencia a conferência, e o MP processa o áudio, vídeo e dados, retornando os fluxos processados a cada terminal.
Na figura a seguir tem uma ilustração de conferência centralizada e descentralizada.
Áudio e Vídeo multicast Descentralizado
Áudio e Vídeo unicast Centralizado
3.1.5 Sinalização no H.323
O H.323 utiliza uma série de protocolos de sinalização, conforme mostrado na figura a seguir. A explicação a seguir assume a existência do gatekeeper, mas caso ele não exista, as mensagens de sinalização são trocadas diretamente entre origem e destino [SCH 99], [ITU 98].
Inicialmente, são trocadas mensagens H.225 ARQ (Admission Request) e ACF (Admission Confirm) para registro no gatekeeper (mensagens utilizando o canal RAS - Registration, Admission and Status - do gatekeeper). Na figura não mostra, mas o destino também deve se registrar no seu gatekeeper (visto na tabela após a figura).
Logo em seguida, deve ser estabelecido o canal confiável (TCP) de sinalização (call signalling channel) para trocar mensagens de controle H.225.0 (que, por sua vez, utiliza mensagens Q.931 para sinalização).
Da mesma forma que foi estabelecido um canal confiável de sinalização H.225.0 (via Q.931), deve ser estabelecido um canal confiável (TCP) de controle para o H.245. A sinalização do H.245 efetua a troca de capacidades entre origem e destino, determinando mestre e escravo (para controle MCU), formato do fluxo de áudio, formato do fluxo de vídeo, e assim por diante.
A tabela a seguir mostra com maiores detalhes o fluxo de mensagens para efetuar uma conferência de áudio no H.323 [SCH 99]. T1=Terminal1, T2=Terminal2, G=gatekeeper, RTT=Round Trip Time.
RTT Origem Destino Descrição T1 G H.225 RAS: Admission Request (ARQ) para T1 1
G T1 H.225 RAS: Admission Confirm (ACF) para T1 T1 T2 TCP SYN para abertura de canal de sinalização Q.931 T2 G H.225 RAS: Admission Request (ARQ) para T2
G T2 H.225 RAS: Admission Confirm (ACF) para T2 T2 T1 TCP SYN ACK para confirmação canal Q.931 2
T1 T2 TCP ACK – estabelece conexão T1 T2 H.225: Q.931: setup
3
T2 T1 H.225: Q.931: connect
T1 T2 TCP SYN para abertura de canal de controle H.245 T2 T1 TCP SYN+ACK para confirmação do canal H.245 4
T1 T2 TCP ACK – estabelece conexão H.245 T1 T2 Capabilities Exchange – Mestre/Escravo
5
T2 T1 Capabilities Exchange – Mestre/Escravo
T1 T2 H.245: abre canal de áudio (open) 6
T2 T1 H.245: abre canal de áudio (ack+open) 7 T1 T2 H.245: abre canal de áudio (ack ) 3.1.6 Exemplo de conferência H.323
3.1.6.1 Exemplos de Terminais H.323
/**/ /* falar do Netmeeting, VIC??, CU-Seeme */
3.1.6.2 Exemplos de Gatekeepers
/**/ /* procurar gatekeepers H.323 comerciais */
3.1.6.3 Exemplos de Gateways
/**/ /* procurar gateways H.323 comerciais */
3.1.6.4 Exemplos de MCUs
/**/ /* procurar MCUs H.323 comerciais */
3.2 SIP
O protocolo SIP (Session Initiation Protocol), definido na RFC 2543, é um protocolo da camada de aplicação que tem por objetivo prover a sinalização necessária para estabelecer, modificar e terminar chamadas ou sessões multimídia. Tais sessões multimídia incluem conferências, ensino a distância, voz sobre IP, distribuição de vídeo e outras aplicações similares. Os participantes podem se comunicar via multicast, unicast ou de ambas formas, e também via TCP ou UDP.
No protocolo, são definidas cinco funções para iniciar e terminar comunicações multimídia:
• Localização de usuário: determinação do endereço a ser usado para comunicação. O endereço SIP é da forma user@host. A parte User é um nome de usuário ou número de telefone, e a parte host é um nome de domínio ou número de rede. Em redes heterogêneas, SIP pode ser usado para determinar que o interlocutor pode ser encontrado via H.323, obter o endereço do usuário e endereço do gateway via H.245 e usar o H.225.0 para estabelecer a chamada;
• Disponibilidade do usuário: determinação da vontade do interlocutor de entrar na comunicação;
• Estabelecimento da chamada (call setup): estabelecimento dos parâmetros de chamada entre participantes. Utiliza para isso os métodos INVITE e ACK. O método INVITE contém, normalmente, uma descrição da sessão, sendo utilizado um formato específico, como o SDP, descrito na RFC 2327;
• Tratamento da chamada (call handling): inclui transferência e término de chamadas. O término de chamadas é com o método BYE.
3.3 Comparação entre SIP e H.323
O H.323 está sendo padronizado pelo ITU-T, e o SIP faz parte da trilha do IETF. Em termos de sinalização de dados, é possível fazer uma comparação entre ambos, como pode ser visto em [SCH 99] e [SCH 99a].
H.323 compreende uma série de protocolos, como RTP para transporte de dados, H.225.0 (com sinalização RAS e Q.931) para configuração, H.245 para negociação de formato, H.450 para serviços suplementares e H.332 para conferências tipo “painel” [SCH 99].
O SIP oferece uma funcionalidade similar ao H.225.0, Q.931, RAS, H.245 e H.450.
3.3.1 Atraso de conexão
Dependendo do uso ou não de um gatekeeper, o estabelecimento de conexão no H.323 pode levar de 6 a 7 RTTs (Round Trip Times), que significa todas as vezes que o origem tem que ficar esperando pelo interlocutor para continuar o estabelecimento de conexão (isso foi visto anteriormente). No H.323 v2 com “fast connect ”, o atraso é reduzido para 2,5 RTTs. A adição do anexo E (UDP -based signalling), pode reduzir para 1,5 RTTs [SCH 99].
O estabelecimento de conexão com o SIP via UDP necessita de 1,5 RTTs. Um pacote INVITE do terminal origem, seguido de um 200 OK do destino e um CONNECTED do origem, como mostra a figura a seguir.
INVITE
200 OK CONNECTED
3.3.2 Escalabilidade
O H.323 necessita de um nível de transporte confiável para o H.245 e Q.931, levando a problemas de escalabilidade. O SIP pode usar tanto UDP como TCP. Se desejado, pode também utilizar ATM AAL5, IPX ou X.25, sem mudanças no protocolo.
3.3.3 Tamanho da conferência
O H.323 permite conferências através do MCU (Multipoint Control Unit), até mesmo para conferências pequenas. Caso o usuário de uma pequena conferência esteja sendo o MC (Multipoint Controller), e desligue sua máquina, a conferência inteira termina. O uso obrigatório de MCs provoca problemas de escalabilidade.
O SIP não necessita do MC, suportando conferências através de multicast diretamente pelos terminais, permitindo uma escalabilidade de 2 a milhões de membros [SCH 99a].
3.3.4 Uso de novos CODECS
SIP funciona com qualquer tipo de CODEC, utilizando SDP (Session Description Protocol) para informar os CODECS suportados por uma entidade. Os CODECS são identificados por strings, e podem ser registrados por qualquer pessoa ou grupo no IANA.
No H.323, cada CODEC deve ser registrado centralmente e normalizado. Atualmente, somente os CODECS desenvolvidos pelo ITU possuem códigos. Como a maioria deles possuem direitos de propriedade intelectual, não existem CODECS free abaixo de 28,8 Kbit/s que possam ser usados num sistema H.323 [SCH 99a, pg 2].
3.3.5 Formato de endereço
O destinatário de uma conexão SIP pode ser qualquer URL, incluindo mailto, phone, H.323 e http. H.323 v1 permite endereçar qualquer host diretamente (mas sem nome de usuário), ou usar um alias. Todos aliases devem ser resolvidos pelo gatekeeper.
3.3.6 Complexidade
A especificação do SIP é bem menor que a das sinalizações Q.931 e H.245, tornando mais simples o sistema. Para se ter uma idéia, a especificação do SIP tem um total de 128 páginas, enquanto a soma das especificações base de sinalização do H.323 dá um total de 736 páginas [SCH 99a]. H.323 define centenas de elementos, enquanto o SIP define somente 37 cabeçalhos. Uma implementação básica do SIP funciona com quatro cabeçalhos (To, From, Call-ID e Cseq) e três tipos (INVITE, ACK e BYE).
Existem outras diferenças entre SIP e H.323 que não serão analisadas neste documento, mas podem ser encontradas nas referências passadas no início deste item.
4 Compressão de áudio e vídeo
Os itens a seguir resumem algumas técnicas de compressão de áudio e vídeo. Os itens em azul se referem a vídeo, os em vermelho a áudio e vídeo, e em verde se refere a somente áudio.
• Redundância Espacial: valores dos pixels próximos são bastante correlacionados
• Redundância em escala: bordas retas e regiões constantes são invariáveis quando
reescalando
• Redundância em freqüência: um sinal mais forte pode mascarar sinais de mesma
freqüência mais fracos
• Redundância temporal: quadros adjacentes de vídeo normalmente possuem pouca
mudança
• Redundância estéreo: existem correlações entre canais de áudio estéreo que podem ser
comprimidas
A compressão tem algumas características, citadas a seguir:
• Sem perdas: dados originais podem ser recuperados precisamente
• Com perdas: ocorrem perdas na compressão
• Intraframe: quadros são codificados independentemente
• Interframe: leva em conta quadros anteriores e futuros
• Simétrica: tempos de codificação e decodificação iguais
• Tempo real: atraso de codificação não deve exceder 50ms
• Escalável: quadros codificados em níveis de resolução diferentes
A compressão sem perdas gera arquivos maiores (não comprime tanto), entretanto, consegue uma qualidade maior, pois o receptor consegue obter uma imagem idêntica à que foi transmitida. A figura a seguir mostra a relação entre qualidade e largura de banda para compressão com e sem perdas.
Largura de banda Compressão sem perdas Compressão com perdas baixa alta baixa alta Qualidade
Dependendo do tipo de compressão desejada, deve-se utilizar o algoritmo correspondente, como mostram os itens a seguir:
• Entropy coding (sem perdas): Aritmética, huffman, run- length
• Source coding (com perdas): Differencial Pulse Code Modulation, Discrete Cosine Transform, Discrete Wavelet Transform, Fourier Transform, Motion-compensated prediction
• Hybrid coding (combinação dos dois): Fractal, H.261, H.263, JPEG, MPEG vídeo, MPEG áudio, Perceptual audio coder, wavelet image compression.
A codificação híbrida consegue as melhores taxas de compressão, pois efetua inicialmente uma compressão com perdas (a fim de aproveitar bem as redundâncias do sinal), e em seguida aplica uma compressão sem perdas, a fim de explorar outras características que podem ainda ser comprimidas. A figura a seguir ilustra o processo.
Preparação Source Coding Entropy Coding Dados não comprimidos Dados comprimidos
Um exemplo de compressão pode ser o DPCM (PCM diferencial). Para a seqüência de amostras 10,12,14,16,18 e 20, o DPCM forma 10,2,2,2,2,2. Aplicando posteriormente o método run- length encoding, fica 10!52.
5 Padrões de áudio e vídeo
A seguir serão analisados alguns padrões e aspectos relevantes para a transmissão de áudio e vídeo, base para as comunicações multimídia em rede. O conhecimento de tais padrões é importante para adaptar as condições da rede à aplicação.
5.1 Codificação de áudio
Os sinais de voz que partem do ser humano e de instrumentos musicais são analógicos e sonoros, ou seja, o ar é empurrado com mais ou menos intensidade, um determinado número de vezes por segundo, gerando uma onda que se propaga. Quando atinge o ouvido, este decodifica as ondas sonoras e as transforma em percepções ao cérebro, que identifica um padrão e monta uma mensagem.
A freqüência da voz humana, ou seja, o número de vezes por segundo que o ar é empurrado, é dada pelas cordas vocais, gerando um som mais agudo (de maior freqüência), ou mais grave (de menor freqüência). Normalmente, o ser humano consegue emitir sinais sonoros entre 100 Hz e 8.000 Hz (8KHz), aproximadamente. Um ouvido humano perfeito consegue captar de 16 Hz a 18.000 Hz, aproximadamente.
Entretanto, numa conversação normal, as freqüências estão entre 300Hz e 3400Hz. Assim, visando utilizar melhor o canal, criou-se uma largura de banda de 4KHz para canais de telefonia, que é o que se utiliza atualmente nas ligações. Isso foi feito para conseguir mais ligações entre centrais públicas utilizando o mesmo meio físico, que é o princípio da multiplexação1, visto através da figura a seguir. Já instrumentos musicais atingem freqüências bem mais altas. O piano, por exemplo, vai normalmente de 20Hz a 7KHz (chegando a 18KHz), e o violino vai de 200Hz a 10KHz (chegando a 20KHz).
Vários canais de 4KHz multiplexados na mesma linha CENTRAL
PÚBLICA
CENTRAL PÚBLICA Limita em 4KHz
Para transmissão de áudio em redes de computadores, vale ressaltar os seguintes itens:
• Digitalização: é necessário digitalizar o sinal para transformar os sinais analógicos em bits, necessário para transmissão em redes de computadores;
• Compressão: a compressão é usada para minimizar o uso de largura de banda. O padrão PCM (G.711 do ITU-T) necessita 64Kbps para transmissão, enquanto o G.729 utiliza apenas 8Kbps. Uma transmissão com duração de 30 segundos no padrão G.711 demandaria 240.000 bytes, enquanto que a mesma transmissão com o G729 iria necessitar de 30.000 bytes, ou 1/8 da anterior. A tabela a seguir mostra algumas taxas de transmissão sem compressão;
Formato Amostragem Bit rate
Telefonia 8000/8bits/mono 64 Kbit/s Teleconferência 16000/16bits/mono 256 Kbit/s CD rom 44100/16bits/stereo 1.410 Kbit/s Digital Audio Tape 48000/16bits/stereo 1.536 Kbit/s
• Qualidade do sinal: a qualidade do sinal está relacionada com a freqüência de amostragem e número de bits gerados por amostra. Para sinais de voz até 4KHz, é suficiente utilizar 8000 amostras por segundo a 8 bits por amostra (resultando em 64Kbps), pois, segundo Nyquist, é necessário o dobro da freqüência para poder recuperar
1
completamente o sinal. Entretanto, o mesmo número de amostras não é suficiente para uma qualidade de CD, e na prática utiliza-se 44,1KHz com 16 bits por amostra estéreo, gerando a necessidade de mais de 1,4Mbps (44100x16x2). Na prática, utiliza-se algum algoritmo de compressão do sinal, como o MP3, que consegue qualidade de CD com 128Kbps, ou qualidade de FM com 56Kbps;
• Latência de codificação: em aplicações que exigem interatividade, como, por exe mplo, uma conversa telefônica, manter a latência baixa é muito importante. O G.711 possui uma latência de codificação desprezível, enquanto que o MP3 precisa de mais de 50ms para codificar o áudio.
A tabela a seguir mostra um resumo de alguns padrões utilizados atualmente para codificação e transmissão de áudio.
Padrão Data Descrição
G.711 1988, 1993
Pulse Code Modulation (PCM) of voice frequencies: utiliza 8000 amostras por segundo, onde
cada amostra tem 13 bits que, comprimindo de acordo com a lei A ou µ, fica 8 bits, gerando taxa de transmissão de 64Kbps. Feito para freqüências de voz, ou seja, até 4KHz [ITU 93]. A latência do algoritmo é menor que 1ms.
G.722 1988, 1993
7 kHz audio-coding within 64 kbit/s: utiliza 16000 amostras por segundo, onde cada amostra
tem 14 bits que, comprimindo na técnica sub-band ADPCM, gera taxa de transmissão de 64Kbps. Pode operar a 56Kbps com um canal de dados auxiliar de 8Kbps, ou 48Kbps com canal de dados auxiliar de 16Kbps [ITU 93a].
G.723 1996 Speech coders: dual rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s: utilizado para transmissão de voz (4KHz). O CODEC para a taxa de 6,3Kbps é MLQ
multipulso, e para a de 5,3Kbps é o ACELP. Ambos utilizam a técnica de previsão linear (linear
predictive analysis by synthesis coding). Esse tipo de algoritmo utiliza muito cálculo em ponto
flutuante, requerendo um poder computacional bem maior do que os baseados em PCM puro. A latência do algoritmo é de 37,5ms [ITU 96] ou 100ms, no caso do Internet Phone da Intel, que utiliza G.723 para codificar áudio [PAS 97a].
G.728 1992, 1997
Coding of speech at 16 kbit/s using low-delay code excited linear prediction: utilizado para voz
(4KHz), esse algoritmo mantém a essência do CELP, entretanto, utiliza uma análise de ganho e previsão linear para reduzir a latência do algoritmo, que fica em 0,625ms [ITU 92]. O anexo H da norma [ITU 97] mostra uma técnica para usar CELP de baixo atraso com uma largura de banda ainda menor, provocando uma taxa de bits variável de até 12,8Kbps ou 9,6Kbps, dependendo da técnica usada.
G.729 1996 Coding of speech at 8 kbit/s using Conjugate Structure Algebraic-Code-Excited Linear-Prediction (CS-ACELP): utilizado para voz (4KHz), recebe um sinal digital codificado segundo
a norma G.712 e o codifica em 8Kbps segundo o algoritmo CS-ACELP [ITU 96a]. A latência gerada fica em torno de 25ms [PAS 97a].
MP3 1992 O MP3 (ou MPEG áudio layer 3) é um algoritmo de compressão de voz utilizado no MPEG-1 ou no MPEG-2 BC (Backward Compatible ), e layer representa uma família de algoritmos de codificação que provê sons de alta qualidade necessitando de uma baixa largura de banda, com taxa de bits variável [THO 98]. A largura de banda e a qualidade do sistema podem ser especificados na codificação do arquivo de áudio. As taxas de bit variam de 8Kbps a 320Kbps [FAQ 98], gerando qualidade de CD estéreo em taxas de 128Kbps. Devido à complexidade do algoritmo, a latência teórica é de 59ms, mas na prática é superior a 150ms [FAQ 98].
AAC 1998 A codificação MPEG-2 AAC (Advanced Audio Coding) permite uma alta qualidade de som com taxas menores que MP3. Para tanto, utiliza alguns algoritmos modernos para filtragem,
eliminação de redundâncias, diminuição de ruído, previsão linear, codificação de Huffmann e codificação estéreo [THO 98]. O resultado é uma taxa de bits 30% menos do que para uma qualidade equivalente de MP3. Esse tipo de codificação não é compatível com versões anteriores de áudio, ou seja, um decodificador MPEG-1 não vai conseguir decodificar um áudio AAC. As taxas de bit variam de 8Kbps a 160Kbps [MPE 99].
5.1.1 Testes de áudio com Netmeeting
Em 10/7/00 foram efetuados alguns testes de transmissão de áudio com o netmeeting. O ambiente consistia de 2 computadores (PIII 450MHz e K6-2 350MHz) ligados via cabo cross,
com o Netmeeting configurado para rede local. O K6II transmite áudio e mais nada passa na rede. Foi utilizado um sniffer de redes para analisar os pacotes. Um resumo dos resultados foi:
• A transmissão utilizou pacotes UDP + IP + Ethernet, com tamanho total de 126 bytes (sem contar preâmbulo nem CRC). Ethernet = 14 bytes, IP=20 bytes, UDP=8 bytes, áudio e níveis superiores=84 bytes;
• Atraso de um segundo;
• Não mudou a taxa de transmissão, independente do CODEC, provavelmente devido a alguma característica do aplicativo.
A seguir uma descrição dos testes. Evidentemente existe alguma condição no software que decide utilizar o que bem entende, e não aceita a configuração da interface.
• CODEC Microsoft ADPCM, 8000Hz, 4bit, mono : Taxa de 11,54 quadros Ethe rnet por segundo; Taxa de transmissão: 11,54*84 = 8Kbps.
• CODEC Microsoft G.723.1, 8000Hz, mono, 6400 bps : Taxa de 11,54 quadros Ethernet por segundo; Taxa de transmissão: 11,54*84 = 8Kbps.
• CODEC Microsoft G.723.1, 8000Hz, mono, 5333 bps : Taxa de 11,54 quadros Ethernet por segundo; Taxa de transmissão: 11,54*84 = 8Kbps.
• CODEC Lernout&Hauspie SBC 16Kbps, 8000Hz, 16 bits, mono : Taxa de 11,54 quadros Ethernet por segundo; Taxa de transmissão: 11,54*84 = 8Kbps.
5.1.2 Testes de áudio com o RAT (Robust Audio Tool)
Em 10/7/00 foram efetuados alguns testes de transmissão de áudio com o RAT (Robust Audio Tool). O ambiente consistia de 2 computadores (PIII 450MHz e K6-2 350MHz) ligados via cabo cross, com o RAT configurado para rede local. O K6II transmite áudio e mais nada passa na rede. Foi utilizado um sniffer de redes para analisar os pacotes. Um resumo dos resultados foi:
• Pacotes UDP + IP + Ethernet. Tamanho total sem contar preâmbulo nem CRC. Ethernet = 14 bytes, IP=20 bytes, UDP=8 bytes, áudio e níveis superiores=resto do pacote.
• A qualidade foi muito parecida com todos CODECS, exceto o LPC.
A seguir uma descrição dos testes. Pode-se ver que neste caso a taxa de transmissão respeitou a configuração da interface com o usuário, entretanto, a taxa em bit/s foi muito superior à do Netmeeting, e a única equivalente (LPC) ficou muito ruim.
• CODEC – Lei A: Atraso de 0,8s; Pacote com 40ms : Taxa de 25,6 quadros Ethernet por segundo. Áudio e níveis superiores=332 bytes. Taxa de transmissão: 25,6*332 = 65Kbps.
Pacote com 20ms : Taxa de 50 quadros Ethernet por segundo. Áudio e níveis
superiores=172 bytes. Taxa de transmissão: 50*172=65Kbps.
• CODEC DVI – 40ms : Atraso de 0,8s; Taxa de 25,5 quadros Ethernet por segundo. Áudio e níveis superiores=176 bytes; Taxa de transmissão: 25,5*176 = 34Kbps.
• CODEC 16 bit linear – 40ms : Atraso de 0,8s; Taxa de 25,7 quadros Ethernet por segundo. Áudio e níveis superiores=652 bytes. Taxa de transmissão: 25,7*652 = 130Kbps.
• CODEC GSM – 40ms: Atraso de 0,7s; Taxa de 25,5 quadros Ethernet por segundo. Áudio e níveis superiores=88 bytes. Taxa de transmissão: 25,5*88 = 16Kbps.
• CODEC LPC – 40ms : Atraso de 0,9s; Não dava para entender as palavras... Muito ruim. Taxa de 25 quadros Ethernet por segundo. Áudio e níveis superiores=40 bytes. Taxa de transmissão: 25*8 = 8Kbps.
5.1.3 Teste de tamanho de arquivo de áudio com o Goldwave
Em 11/7/00 efetuou-se um teste com o aplicativo goldwave a fim de ver o tamanho dos arquivos de áudio gerados com qualidades diferentes. Todos os testes geraram um arquivo com 5 segundos de áudio. O resultado pode ser visto a seguir, onde se pode ver que a teoria confere com a prática.
• 8bits, 8000am/s, mono, 5s : arquivo = 40.000 bytes. Teórico = 8000x1x5 = 40.000 bytes.
• 8bits, 16000am/s, mono, 5s : arquivo=80.000 bytes. Teórico = 8000x2x5 = 80.000 bytes.
• 16bits, 44100am/s, stereo, 5s: arquivo=882000 bytes. Teórico = 44100x2x2x5 = 882.000 bytes.
5.2 Codificação de vídeo
Vídeo pode ser definido como uma seqüência de imagens paradas que, quando apresentadas em uma taxa suficientemente rápida, dão a impressão de movimento ao ser humano, como, por exemplo, os seguintes sistemas analógicos:
• NTSC (National Television Standards Committee) 525x60: 30 quadros por segundo, sendo apresentados em 525 linhas e, de forma entrelaçada, 60 vezes por segundo (cada quadro é dividido em linhas pares e ímpares) para melhorar a sensação de movimento;
• PAL (Phase Alternation Line) 625x50: 25 quadros por segundo, sendo apresentados em 625 linhas e, de forma entrelaçada, 50 vezes por segundo (cada quadro é dividido em linhas pares e ímpares) para melhorar a sensação de movimento.
Para apresentar a imagem em meios digitais, é necessária a conversão entre os padrões analógicos (25 ou 30 quadros por segundo entrelaçados) e digitais (freqüência de atualização de tela no computador é normalmente entre 60 e 80Hz). O resultado é que no computador o quadro é apresentado mais de uma vez, de acordo com a freqüência do monitor (60Hz, 75Hz, etc).
O PAL (Phase Alternation Line) utiliza 625 linhas e 25 qps. A resolução espacial da TV é 4x3, resultando 833x625 (nem tudo visível). O equivalente digital no PAL é o CIF (Common Intermediate Format), equivalente a um quarto do tamanho da área visível da imagem PAL (352x288)
O NTSC (National Television Standards Committee) utiliza 525 linhas e 30qps. Mantendo o aspecto da TV de 4x3, o resultado é 700x525 (nem tudo visível). O equivalente CIF no NTSC é 320x240.
Da mesma forma que no áudio, os fatores digitalização, compressão, qualidade do sinal e latência são extremamente importantes na transmissão de vídeo. Basicamente, existem três pontos que podem ser ajustados para modificar a qualidade e a taxa de transmissão: a resolução espacial (largura x altura) da imagem, a taxa de quadros e os passos de quantização [MCG 99].
• Resolução espacial: significa o tamanho do quadro, ou seja, a relação entre sua largura e altura. Em meios digitais, para permitir que uma recomendação possa ser utilizada em tanto em regiões do planeta que utilizam NTSC como as que utilizam PAL, normalmente se utiliza o formato CIF (Common Intermediate Format) [ITU 93b] ou SIF (Standard Interchange Format). A tabela a seguir mostra formatos de vídeo e alguns padrões onde esses formatos são utilizados [PRI 99], [SHA 96], [MCG 99];
Formato Número de pixels Padrões Sub-QCIF 128x96 H.263 QCIF 176x144 H.261, H.263 CIF 352x288 Opcional no H.261 e H.263 4CIF 702x576 Opcional no H.263 16CIF 1408x1152 Opcional no H.263 Sub-QSIF 88x60 MPEG QSIF 176x120 MPEG
SIF 352x240 MPEG-1, MPEG-2 CCIR-601 720x480 MPEG-2
1280x720 Grand Alliance High Definition Television Standard
1920x1080 Grand Alliance High Definition Television Standard
• Taxa de quadros : representa o número de quadros sucessivos por segundo. Para uma boa qualidade, o ideal é utilizar acima de 24 quadros por segundo (padrão atual dos cinemas). Em termos de compressão da imagem, quanto mais quadros por segundo melhor a taxa de compressão, pois é possível codificar somente as mudanças entre quadros. Isso permite a padrões que exploram essa característica, como o MPEG, comprimir 50 a 70 vezes uma transmissão 352x240 30 quadros por segundo, enquanto padrões que não exploram, como o M-JPEG, comprimem apenas 15 a 30 vezes [MCG 99]. Entretanto, quando a taxa de quadros é baixa, como, por exemplo, 1 quadro por segundo, a diferença na compressão entre MPEG e M-JPEG não é significativa;
• Passo de quantização: quanto maior o número de amostras de um vídeo por segundo, maior a sua qualidade, da mesma forma que foi visto na parte de áudio.
A largura de banda necessária para transmissão de vídeo é maior que para o áudio, como pode ser visto no exemplo a seguir.
A figura a seguir possui um formato de 352x288 pixels com 256 cores (cada pixel precisa de um byte). Para efetuar sua transmissão pela rede, são necessários aproximadamente 100Kbytes (352x288x1). Para enviar o peixinho se movendo a 30 quadros por segundo sem compressão alguma, seria necessário 30 vezes esse tamanho, ou 3Mbytes (24Mbit/s).
Uma figura vale mais que mil palavras, mas uma figura não comprimida vale muitos megabytes. A tabela a seguir mostra algumas taxas de vídeo não comprimido.
