TrabalhosGratuitos.com - Trabalhos, Monografias, Artigos, Exames, Resumos de livros, Dissertações
Pesquisar

Protocolos para aplicações interativas em tempo real

Por:   •  24/10/2018  •  Artigo  •  11.982 Palavras (48 Páginas)  •  366 Visualizações

Página 1 de 48
  1. 7.4  Protocolos para aplicações interativas em tempo real

Aplicações interativas em tempo real, incluindo VoIP e videoconferência, são atraentes e muito populares.

Portanto, não é surpresa que órgãos de padrões, tais como IETF e ITU, tenham se ocupado durante tantos anos (e ainda se ocupem!) com a produção de padrões para essa classe de aplicações. Tendo à mão padrões apropriados para aplicações interativas em tempo real, empresas independentes poderão criar novos produtos atraentes que interagem uns com os outros. Nesta seção estudamos RTP e SIP para aplicações interativas em tempo real. Todos

os três conjuntos de padrões estão sendo implementados amplamente em produtos do setor.

  1. 7.4.1 Protocolo de tempo real (RTP)

Na seção anterior, aprendemos que o lado remetente de uma aplicação de VoIP anexa campos de cabeçalho aos trechos de áudio/vídeo antes de passá-los à camada de transporte. Esses campos contêm números de sequência e marcas de tempo. Já que a maioria das aplicações de rede multimídia pode usar números de sequência e marcas de tempo, é conveniente ter uma estrutura de pacote padronizada que inclua campos para dados de áudio/vídeo, números de sequência e marcas de tempo, bem como outros campos potencialmente úteis. O RTP, definido no RFC

3550, é um padrão desse tipo. Ele pode ser usado para transportar formatos comuns como PCM, ACC e MP3 para som e MPEG e H.263 para vídeo. O protocolo também pode ser usado para transportar formatos proprietários de som e de vídeo. Hoje, o RTP é amplamente implementado em muitos produtos e protótipos de pesquisa. Também é complementar a outros importantes protocolos interativos de tempo real, entre eles SIP.

Nesta seção, faremos uma introdução ao RTP. Também aconselhamos o leitor a visitar o site de Henning Schulzrinne [Schulzrinne-RTP, 2012], que trata do RTP e traz uma profusão de informações sobre o assunto. O leitor também poderá visitar o site da RAT [RAT, 2012], que documenta uma aplicação de VoIP que usa RTP.

Fundamentos de RTP

O RTP comumente roda sobre UDP. O lado remetente encapsula uma parte de mídia dentro de um pacote RTP, em seguida  encapsula o pacote em um segmento UDP, e então passa o segmento para o IP. O lado receptor extrai o pacote RTP do segmento UDP, em seguida extrai a parte de mídia do pacote RTP e então passa a parte para o transdutor para decodificação e apresentação.

Como exemplo, considere a utilização do RTP para transportar voz. Suponha que a origem de voz esteja codificada (isto é, amostrada, quantizada e digitalizada) em PCM a 64 kbits/s. Suponha também que a aplicação colete os dados codificados em trechos de 20 milissegundos, isto é, 160 bytes por trecho. O lado remetente precede cada parte dos dados de áudio com um cabeçalho RTP que contém o tipo de codificação de áudio, um número de sequência e uma marca de tempo. O tamanho do cabeçalho RTP é normalmente 12 bytes.

A parte de áudio, junto com o cabeçalho RTP, forma o pacote RTP. O pacote RTP é, então, enviado para dentro da interface de socket UDP. No lado receptor, a aplicação recebe o pacote RTP da interface do seu socket. A aplicação extrai a parte de áudio do pacote RTP e usa os campos de cabeçalho do pacote RTP para decodificar e reproduzir adequadamente a parte de áudio.

Se uma aplicação incorporar o RTP — em vez de um esquema proprietário para fornecer tipo de carga útil, número de sequência ou marcas de tempo —, ela interagirá mais facilmente com as outras aplicações de rede multimídia. Por exemplo, se duas empresas diferentes desenvolvem um software de VoIP e ambas incorporam o RTP a seu produto, pode haver alguma chance de um usuário que estiver usando um desses produtos conseguir se comunicar com alguém que estiver usando o outro produto de VoIP.

Na Seção 7.4.2, veremos que o RTP é muito utilizado em conjunto com os padrões de telefonia por Internet.

Devemos enfatizar que o RTP não fornece nenhum mecanismo que assegure a entrega de dados a tempo nem fornece outras garantias de qualidade de serviço (QoS); ele não garante nem mesmo a entrega dos pacotes nem impede a entrega de pacotes fora de ordem. Na verdade, o encapsulamento realizado pelo RTP é visto somente nos sistemas finais. Os roteadores não distinguem datagramas IP que carregam pacotes RTP de datagramas IP que não o fazem.

O RTP permite que seja atribuído a cada origem (por exemplo, uma câmera ou um microfone) seu próprio fluxo independente de pacotes RTP. Por exemplo, para uma videoconferência entre dois participantes, quatro fluxos RTP podem ser abertos — dois para transmitir o áudio (um em cada direção) e dois para transmitir o vídeo (um em cada direção). Contudo, muitas técnicas de codificação populares — incluindo MPEG1 e o MPEG2— conjugam áudio e vídeo em um único fluxo durante o processo de codificação.

Quando áudio e vídeo são conjugados pelo codificador, somente um fluxo RTP é gerado em cada direção.

Pacotes RTP não são limitados às aplicações individuais. Eles podem também ser enviados por árvores para um grupo um-para-muitos e muitos-para-muitos. Para uma sessão para um grupo muitos-para-muitos, todos os remetentes e origens da sessão em geral usam o mesmo grupo para enviar seus fluxos RTP. Fluxos para um grupo RTP que formam um conjunto, como fluxos de áudio e vídeo que emanam de vários remetentes em uma aplicação de videoconferência, pertencem a uma sessão RTP.

Campos do cabeçalho do pacote RTP

Como mostra a Figura 7.11, os quatro principais campos de cabeçalho do pacote RTP são os campos de tipo da carga útil, número de sequência, marca de tempo e os campos identificadores da origem.

O campo de tipo de carga útil do pacote RTP tem 7 bits de comprimento. Para um fluxo de áudio, o campo de tipo de carga útil serve para indicar o tipo de codificação de áudio (por exemplo, PCM, modulação delta adaptativa, codificação por previsão linear) que está sendo usado. Se um remetente decidir mudar a codificação no meio de uma sessão, ele poderá informar a mudança ao receptor por meio desse campo de tipo de carga útil.

O remetente pode querer mudar o código para aumentar a qualidade do áudio ou para reduzir a taxa de bits do fluxo RTP. A Tabela 7.2 apresenta alguns dos tipos de carga útil de áudio suportados pelo RTP.

Para um fluxo de vídeo, o tipo de carga útil é usado para indicar o tipo de codificação de vídeo (por exemplo, Motion JPEG, MPEG1, MPEG2, H.261). Novamente, o remetente pode mudar a codificação de vídeo durante a sessão.

A Tabela 7.3 apresenta alguns tipos de carga útil de vídeo suportados pelo RTP. Os outros campos importantes são:

...

Baixar como (para membros premium)  txt (73.7 Kb)   pdf (659 Kb)   docx (609 Kb)  
Continuar por mais 47 páginas »
Disponível apenas no TrabalhosGratuitos.com