Aula 08 – Redes de Computadores

Redes Convergentes

Objetivos

• Conhecer os serviços que os sistemas computacionais podem compartilhar.
• Compreender a integração entre dados, voz e imagem transmitidos pelas redes de computadores.

Introdução

O que você sabe sobre comunicação multimídia? E redes convergentes? Nunca ouviu falar? Você usa o MSN? Já usou com webcam e microfone? Se sim, então você já utilizou uma comunicação multimídia.

A internet comporta uma grande variedade de aplicações de multimídia interessantes como dados, voz, vídeo, imagens, músicas, e tudo que possa ser transformado em bits utilizando o mesmo meio físico. São os chamados serviços integrados (KUROSE, 2010). Esses serviços integrados compõem as redes multimídias ou convergentes.

Para Roesler (2001), pode-se dividir transmissão multimídia em redes de computadores em parte de conferência (que requer interatividade) e parte de transmissão de vídeo (que envolve apenas um lado transmitindo e vários clientes recebendo). Ambas possuem necessidades diferentes para funcionar a contento; por exemplo, as aplicações de conferência normalmente possuem necessidades mais rígidas em relação ao atraso da rede, enquanto a transmissão unidirecional pode trabalhar com um atraso maior.

As aplicações multimídia têm características e necessidades bem diferentes umas das outras, como, por exemplo, voz, que exige atrasos, ou latências, baixos. Dados, ao contrário, não têm tanta preocupação com latência e jitter. Já videoconferência, além de exigir latência e jitter baixos, ainda necessita de skew baixo, de modo a manter sincronizados voz e vídeo. A compreensão dessas necessidades é primordial para a construção de uma rede multimídia (ROESLER, 2001).

Latência

Latência é o tempo que um pacote leva da origem ao destino. Caso haja um atraso muito grande, isso pode prejudicar, por exemplo, uma conversação através da rede, tornando difícil o diálogo e a interatividade necessária para certas aplicações (ROESLER, 2001).

Os principais responsáveis pela latência são (ROESLER, 2001):

• Atraso de transmissão: tempo após o pacote sair do transmissor até sua chegado no receptor. Esse tempo envolve uma série de fatores, como o atraso no meio físico, processamento em cada nodo intermediário, fila de espera em nodo, etc.
• Atraso de codificação e decodificação: sinais como voz e vídeo são normalmente codificados em um padrão, tipo PCM (G.711 a 64Kbps) para voz, ou H.261 para vídeo. Essa codificação gasta um tempo de processamento na máquina.
• Atraso de empacotamento e desempacotamento: após codificado, o dado deve ser empacotado na pilha OSI a fim de ser transmitido na rede, e isso gera um atraso.

Jitter

Uma informação digitalizada é quebrada em pacotes, e os pacotes são numerados em sequência e enviados pelo meio físico. O jitter, de acordo com Roesler (2001), é a variação estatística do retardo, que altera o fluxo de chegada dos pacotes, ou seja, os pacotes chegam fora de ordem. O conceito de jitter e latência é ilustrado na Figura a seguir.

A consequência dessa variação é que o destino deve possuir um buffer cujo tamanho vai depender do jitter, gerando mais atraso na conversação (aplicação de voz, por exemplo).

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. 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 (ROESLER, 2001).

Protocolos de tempo real para transmissões multimídia

Segundo Kurose (2010), as aplicações interativas em tempo real pela internet prometem liderar o seu crescimento. Por isso se fez necessário criar padrões para essa classe de aplicações que permitam a interatividade entre os diversos desenvolvedores dessa categoria de produto. A seguir serão mostrados alguns protocolos que estão sendo mais usados.

RTP

O protocolo RTP (Real-time Transport Protocol), segundo Kurose (2010), roda sobre o protocolo UDP. O lado remetente encapsula uma porção de mídia dentro de um pacote RTP que o encapsula em um segmento UDP. No destinatário, o processo inverso é feito até ter-se a porção de mídia enviada.

Alguns benefícios obtidos por esse protocolo são (ROESLER, 2001):

• Detecção de perda de pacotes: observando o número de sequência, é possível saber se houve perda de pacotes ou não.
• Sincronização intramídia: o campo de timestamp do cabeçalho informa ao receptor o momento exato de passar os dados ao usuário.
• Sincronização intermí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.

Kurose (2010) afirma que o RTP não fornece nenhum mecanismo que garanta a entrega dos pacotes, a sua ordem de entrega ou a qualidade de serviço da rede. O encapsulamento realizado pelo RTP é visto somente nos sistemas finais.

Assim, de acordo Roesler (2001), a garantia de entrega do pacote ou a qualidade de serviço da rede devem ser obtidas através de outro mecanismo de entrega, como o RSVP , diffserv ou outro protocolo.

RTCP

O protocolo RTCP (RTP Control Protocol) pode ser usado juntamente com o RTP para, segundo Kurose (2010), fornecer informações sobre a qualidade de serviço obtida na distribuição de dados RTP.

Para Roesler (2001), essas informações são obtidas 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. Suas funções são (Roesler, 2001):

• fornecer feedback sobre a qualidade de serviço obtida na distribuição de dados RTP;
• 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 de um nome canônico para identificar a origem e poder sincronizar as sessões;
• controlar a periodicidade de envio dos pacotes RTCP, a fim de permitir a escalabilidade do sistema;
• permitir (função opcional) o transporte de informações mínimas de controle, possibilitando, por exemplo, que a identificação de cada participante seja apresentada na interface com o usuário.

Padrões de multimídia em redes de computadores

Como já foi dito, quando as redes convergentes, também chamadas de multimídias, começaram a crescer, fez-se necessário a criação de padrões para permitir que sistemas de desenvolvedores diferentes pudessem conversar entre si. Muitos padrões foram criados, mas os mais importantes são os desenvolvidos pelo ITU-T e pelo IETF. A seguir eles serão mostrados.

Os padrões de multimídia do ITU-T

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 Figura 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 (ROESLER, 2001).

Cada um dos protocolos da série H aponta 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.

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 (ROESLER, 2001):

• 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).
• 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.

SIP

De acordo com Kurose (2010), o SIP (Session Initiation Protocol) é um protocolo da camada de aplicação que tem por objetivo:

• Prover mecanismos para estabelecer chamadas entre dois interlocutores por uma rede IP. Permite que quem chama avise ao que é chamado que quer iniciar uma chamada. Permite que os participantes concordem com a codificação da mídia. E também permite que encerrem as chamadas.
• Prover mecanismos que permitam a quem chama determinar o endereço IP corrente de quem é chamado. Os usuários não têm um endereço IP único, fixo, porque podem receber endereços dinamicamente, através do serviço de DHCP, e porque podem ter vários equipamentos IP, cada um com um endereço IP diferente.
• Prover mecanismos para gerenciamento de chamadas, tais como adicionar novas correntes de mídia, mudar a codificação, convidar outros participantes, tudo durante a chamada, e ainda   transferir e segurar chamadas.

No SIP são definidas cinco funções para iniciar e terminar comunicações multimídia (ROESLER, 2001):

• 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, o 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.
• Capacidades do usuário: determinação da mídia e seus parâmetros.
• 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.

Padrão H.323

Segundo Kurose (2010), como uma alternativa ao SIP, o padrão H.323 é muito popular para audioconferência e videoconferência entre sistemas finais na internet. As principais características do H.323 são (ROESLER, 2001):

• 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.

O padrão H.323 inclui as seguintes especificações (KUROSE, 2010):

• Uma especificação para o modo como os terminais negociam codificações comuns de áudio/vídeo. Como o H.323 suporta uma variedade de padrões de codificação de áudio e vídeo, é preciso um protocolo para permitir que os terminais comunicantes cheguem a um acordo quanto a uma codificação comum.
• Uma especificação para o modo como porções de áudio e vídeo são encapsuladas e enviadas à rede. Em particular, para essa finalidade o H.323 impõe o RTP.
• Uma especificação para o modo como terminais se comunicam com seus respectivos gatekeepers (tem a função de registrar os usuários na rede H.323).
• Uma especificação para o modo como telefones por internet se comunicam por meio do gateway com os telefones comuns da rede pública de telefonia por comutação de circuitos.

SIP X H.323

A seguir são destacadas algumas diferenças importantes entre o protocolo SIP e o H.323 (KUROSE, 2010): o H.323 é um conjunto de protocolos completo, integrados verticalmente para conferência multimídia. Ele possibilita a sinalização, o registro, o controle de admissão dos usuários, o transporte e os CODECs em uma conexão. Já o SIP aborda apenas a inicialização e gerenciamento da sessão, e é um componente separado. Ele precisa ser combinado com outros protocolos e serviços para poder executar uma conferência multimídia. O H.323 vem do ITU, enquanto o SIP vem da IETF e toma emprestados muitos conceitos da web, do DNS e do e-mail.

Resumo

Nesta aula conhecemos redes convergentes, que são a unificação de vários serviços de comunicação distintas, que antes utilizavam várias redes, numa única rede capaz de prover esses serviços. Um dos primeiros exemplos é a convergência entre redes de voz e dados. E, ultimamente, aos serviços de voz e dados têm sido incluídos serviços de vídeo e/ou multimídia. Vimos que a transmissão multimídia é muito sensível a atrasos e ruídos, que, se não forem considerados, podem comprometer seu uso. Vimos também os vários protocolos que podem ser usados em redes convergentes, bem como sua constituição básica.

Fim da Aula 08