Transmissão multimídia em redes de computadores

Transcrição

1 Transmissão multimídia em redes de computadores Autor: Universidade: UNISINOS Data: Julho de 2001

2 Multimídia em redes de computadores pg. 2 SUMÁRIO 1 Transmissão multimídia em redes Latência Jitter Skew Tabela comparativa Protocolos de tempo real para transmissões multimídia RTP Entidades RTP Cabeçalho RTP Exemplo: conferência de áudio Exemplo: videoconferência RTCP SR (Sender Report) RR (Receiver Report) SDES (Source Description) BYE APP Restrições de tempo nos pacotes RTCP Padrões de multimídia em redes de computadores H Terminais Gatekeepers Gateways MCUs Sinalização no H Exemplo de conferência H Exemplos de Terminais H Exemplos de Gatekeepers Exemplos de Gateways Exemplos de MCUs SIP Comparação entre SIP e H Atraso de conexão Escalabilidade Tamanho da conferência Uso de novos CODECS Formato de endereço Complexidade Compressão de áudio e vídeo Padrões de áudio e vídeo Codificação de áudio Testes de áudio com Netmeeting Testes de áudio com o RAT (Robust Audio Tool) Teste de tamanho de arquivo de áudio com o Goldwave Codificação de vídeo Codificação de vídeo no M-JPEG Codificação de vídeo no MPEG Resumo de padrões para codificação de vídeo Estudo de caso 1: Transmissão multicast ao vivo durante a VI Semana da Qualidade na Unisinos...31

3 Multimídia em redes de computadores pg. 3 7 Estudo de caso2: Videoconferência multicast no Metropoa Bibliografia Transmissão multimídia em redes As etapas de uma transmissão multimídia são mostradas na figura a seguir: Sinal de entrada Digitalização Compressão Transmissão Perda / atraso Sinal de saída Recuperação Descompressão Reordenação 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 Conferências (interatividade) Transmissão Unidirecional Áudio Texto Vídeo 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.

4 Multimídia em redes de computadores pg 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.

5 Multimídia em redes de computadores pg. 5 N. de Pacotes latência jitter 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. t N. de Pacotes chegando skew 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 velocidade (largura de banda) baixa alta alta t

6 Multimídia em redes de computadores pg. 6 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.

7 Multimídia em redes de computadores pg. 7 Aplicação Encapsulamento de mídia RTP RTCP dados controle UDP IPv4 / IPv6 Unicast ou multicast Ethernet 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= SSRC = 87 PCM Troca de codificação Múltiplos fluxos Fluxo único Sistema origem / destino IP= SSRC = 35 Tradutor ADPCM IP MP3 MP3 Multiplexador IP SSRC = 46 SSRC = 46 CSRC = 87, 35 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).

8 Multimídia em redes de computadores pg Cabeçalho RTP O cabeçalho do RTP é visto na figura a seguir V=2 P X CC M PT Número de seqüência Timestamp 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; Marcador (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ê 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

9 Multimídia em redes de computadores pg. 9 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 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 1 o de janeiro de /**/ /* sniffar videoconferência identificar pacotes RTCP e forma de sincronização intermí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;

10 Multimídia em redes de computadores pg. 10 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 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] 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 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 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;

11 Multimídia em redes de computadores pg. 11 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 /**/ sniffar a rede e capturar pacotes RTCP de uma videoconferência, identificando os campos */ 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) 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: do transmissor, por exemplo jsilva@x.com.br; Tipo = 4: PHONE: telefone do transmissor, identificado com o sinal de + para o código internacional. Por exemplo ; 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 ;

12 Multimídia em redes de computadores pg. 12 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 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 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 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 momento. 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.

13 Multimídia em redes de computadores pg. 13 Padrão Data Descrição H Broadband audiovisual communication systems and terminals: videoconferência MPEG-2 sobre ATM com alta qualidade H Narrow-band visual telephone systems and terminal equipment: videoconferência sobre RDSI H Adaptation of H.320 visual telephone terminals to B-ISDN environments: videoconferência sobre ATM com boa qualidade H Visual telephone systems and terminal equipment for local area networks which provide a guaranteed quality of service: /**/ H Packet based multimedia communications systems: videoconferência sobre redes de pacotes, como IP e Ethernet H 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;

14 Multimídia em redes de computadores pg. 14 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.323 MCU H.323 HUB Rede baseada em pacotes Gatekeeper H.323 Gateway H.323 Terminal H.323 Terminal H.323 GSTN LAN com QoS RDSI-FE RDSI-FL Terminal H.310 operando no modo H.321 Terminal V.70 Terminal H.324 Terminal de voz Terminal H.322 Terminal de voz Terminal H.320 Terminal H.321 Terminal H 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].

15 Multimídia em redes de computadores pg. 15 Escopo da norma H.323 Eqto de entrada de áudio (microfone, vídeo cassete) Eqto de entrada de vídeo Câmera de vídeo, vídeo cassete) CODEC de áudio G.711, G.722, G.723, G.728, G.729 CODEC de vídeo H.261, H.263 Receive Path Delay Aplicações de dados (T.120, etc) Controle do sistema Controle do sistema Controle H.245 Controle de chamada H Controle RAS H Sinalização Q.931 Camada H Interface LAN 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

16 Multimídia em redes de computadores pg. 16 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 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 [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 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 Terminal Gatekeeper Gateway Terminal Terminal HUB HUB Terminal Terminal Roteador Roteador MCU 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.

17 Multimídia em redes de computadores pg. 17 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 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

18 Multimídia em redes de computadores pg 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 (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 (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.

19 Multimídia em redes de computadores pg. 19 RTT Origem Destino Descrição 1 T1 G H.225 RAS: Admission Request (ARQ) para T1 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 2 G T2 H.225 RAS: Admission Confirm (ACF) para T2 T2 T1 TCP SYN ACK para confirmação canal Q.931 T1 T2 TCP ACK estabelece conexão 3 T1 T2 H.225: Q.931: setup T2 T1 H.225: Q.931: connect T1 T2 TCP SYN para abertura de canal de controle H T2 T1 TCP SYN+ACK para confirmação do canal H.245 T1 T2 TCP ACK estabelece conexão H T1 T2 Capabilities Exchange Mestre/Escravo T2 T1 Capabilities Exchange Mestre/Escravo 6 T1 T2 H.245: abre canal de áudio (open) T2 T1 H.245: abre canal de áudio (ack+open) 7 T1 T2 H.245: abre canal de áudio (ack) Exemplo de conferência H Exemplos de Terminais H.323 /**/ /* falar do Netmeeting, VIC??, CU-Seeme */ Exemplos de Gatekeepers /**/ /* procurar gatekeepers H.323 comerciais */ Exemplos de Gateways /**/ /* procurar gateways H.323 comerciais */ 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 para estabelecer a chamada; Capacidades do usuário: determinação da mídia e seus parâmetros;

20 Multimídia em redes de computadores pg. 20 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 (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 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 CONNECTED 200 OK 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 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.