# 1.6. a 1.11 Multimídia

## 1.6. APLICAÇÕES DE VOZ SOBRE IP

Há sempre muita confusão quando se fala em VoIP e telefonia IP. Os dois conceitos são muito semelhantes já que usam o protocolo IP para transmissão de dados. Porém há diferenças importantes entre eles.

Na telefonia IP, um aparelho telefônico é conectado a um comutador que prepara a integração da voz, transformando o sinal em um pacote IP;

O VoIP utiliza um Router para comunicação entre o analógico e o digital e utiliza alguns softwares para complementar o serviço. (IP Contact Center, Web Attendant, entre outros).

Voz sobre IP é um serviço que basicamente converge um sinal de voz analógico para digital. Já a Telefonia IP é um conceito mais amplo, que utiliza telefones especiais que se conectam a rede e transmitem não somente um sinal de voz, mas também vídeos, dados, imagens.

O paradigma do melhor esforço (*best effort*) oferecido pelas redes IP não é suficiente para uma aplicação de voz, já que esta aplicação é sensível a variação de atraso. Assim dois foram os protocolos principais criados para atender a demanda de transmissão de Voz sobre IP seus serviços, requisitos e restrições de funcionamento. O H.323 do ITU e o *Session Initiaton Protocol* (SIP) do IETF.

### 1.6.1 Telefonia IP

O VoIP, é uma tecnologia que permite a digitalização e codificação da voz e o
empacotamento destes dados em pacotes IP para transmissão em uma rede que utilize o protocolo TCP/IP. O transporte de dados VoIP, utilizando-se como suporte a rede Internet, tem sido um forte atrativo para os usuários

A experiência, no entanto, demonstrou que os pacotes IP contendo os dados de voz, ao passarem por diversos domínios e roteadores. Assim, na prática raramente o destino tem condições de oferecer uma qualidade de voz aceitável. Um dos motivos é que os parâmetros de QoS (Quality of Service) exigidos para este serviço.

Comecemos pelos obstáculos a transmissão de voz através de uma rede de dados sob a arquitetura IP.

<span style="font-size:1.3em;"><ins>**Perda de pacotes**:</ins></span>

O segmento UDP é encapsulado num datagrama IP um datagrama pode ser descartado por falta de espaço num roteador. O TCP poderia eliminar as perdas, mas seu método de retransmissões aumentam o atraso e o controle de congestionamento do TCP limita a taxa de transmissão

  Taxas de perda entre 1 e 20% podem ser toleradas e lançar mão de mecanismo de correção de erros como FEC (forward error control) podem ajudar a ocultar as perdas.

<span style="font-size:1.3em;"><ins>**Retardo fim-a-fim**:</ins></span>

O acúmulo dos retardos de transmissão, propagação, atrasos nas filas dos roteadores e retardos de processamento nos sistemas finais podem ser proibitivos para inteligibilidade da voz. Mais que 400 ms de retardo fim-a-fim compromete a interatividade;

Manter o retardo menor melhor. E Normalmente o receptor descarta pacotes com retardo maior que um patamar

<span style="font-size:1.3em;"><ins>**Variação de atraso (*jitter*)**:</ins></span>

* Retardo nas filas dos roteadores é aleatório
* considere dois pacotes consecutivos num intervalo de atividade
* Os retardos fim-a-fim desses dois pacotes podem ser diferentes
* espaçamento inicial é de 20 ms, mas o espaçamento no receptor pode ser maior ou menor que 20 ms
* O jitter pode ser removido:
* Precedendo cada bloco com um número de seqüência
* O Transmissor incrementa esse número para cada novo pacote
* Precedendo cada bloco com uma marca de tempo
* transmissor marca cada bloco com o tempo em que foi gerado
* Atrasando a reprodução
* atraso na reprodução deve ser suficiente para que a maioria dos pacotes seja recebida antes do seu tempo de reprodução programado
* atraso de reprodução fixo ou adaptativo

#### 1.6.1.2 H.323

Com a multiplicação das redes locais e o elevado crescimento da internet, o protocolo IP foi se tornando gradativamente um padrão “de facto” de convergência de serviços. Desta forma, entre 1993 a 1996, foi preparada pelo Grupo de Estudo 15 da ITU-T, e aprovada pela resolução Nº 1 em 8 de Novembro de 1996, a recomendação H.323.

A recomendação H.323 define um arcabouço (guarda-chuva) para a estruturação dos diversos padrões e protocolos para transmissão de vídeo, áudio e dados para aplicações em videoconferência.

O padrão H.323 compreende um conjunto de especificações que define várias entidades, protocolos e procedimentos para comunicação multimídia sobre rede de pacotes.
<center>

</center>

**Endpoints (Terminais)**

Os endpoints constituem uma entidade H.323 que provêm comunicação em tempo real para serviços de multimídia.

**Gatekeepers**

O padrão H.323 define o *gatekeeper*, em um serviço multimídia, como um servidor de nível de administração, o qual provê serviços para os endpoints (um endpoint pode ser um terminal, um gateway ou mesmo uma Unidade de Controle multiponto MCU). Os serviços providos pelos gatekeepers compreendem:
• Resolução de endereços;
• Controle de admissão;
• Gerenciamento de banda;
• Gerenciamento de zona.

Um Gatekeeper é o componente mais importante de uma rede H.323. Ele age como o ponto central para todas as chamadas dentro de sua zona e provê serviços de controle de chamada para estações registradas.

*Gatekeepers* executam duas funções de controle de chamada importantes. A primeira é tradução de endereço dos apelidos de terminais de rede e gateways para endereços IP.

A segunda função é administração de largura de banda, que também é designada dentro da RAS (Registration, Admission and Status). Por exemplo, se um gerente de rede especificou um limite para o número de conferências simultâneas na rede, o Gatekeeper pode recusar fazer mais algumas conexões uma vez que o limite é alcançado. O efeito é limitar a largura de banda total da conferência, para alguma fração do total disponível; a capacidade restante permanece para e-mail, transferência de arquivo, e outras atividades da rede.

***Gateways***

O Gateway é um elemento opcional em uma conferência H.323. Gateways provêem muitos serviços, onde o mais comum provê uma função de tradução entre os terminais de conferência H.323 e outros tipos terminais que falam outros protocolos e arquiteturas.

Os serviços providos pelos gateways compreendem basicamente:
• Interoperabilidade entre padrões de audio/vídeo e redes (H.320/H.323);
• Conversão de protocolos (procedimentos de comunicação e formatos de transmissão);
• Conversão de formatos de áudio e vídeo.

MCU – Multipoint Control Unit (Unidade de Controle Multiponto)

**MCU (*Multipoint Control Unit*) ou Unidade de Controle Multiponto**

É um *endpoint* da rede local que provê recursos para que 3 ou mais *endpoints* participem de uma conexão multiponto. Uma Unidade de Controle Multiponto é formada por duas entidades H.323:
• MC: Multipoint Controller ou Controladora Multiponto é um componente mandatório na MCU e realiza todo o controle de conexões em uma sessão multiponto;
• MP: Multipoint Processor ou Processador Multiponto, de caráter opcional. O MC tem a finalidade de prover controle para a realização de conferências multiponto em uma rede, enquanto que o MP (Multipoint Processor) tem a finalidade de prover recursos para uma conferência multiponto através do processamento dos fluxos de áudio e vídeo para distribuição aos endpoints.


A recomendação H.323 compreende, portanto, um padrão **“de jure”** definido pelo ITU-T e que por ser normalizada, agrega alguns importantes benefícios:

* Habilidade para integrar comunicações multimídia com outras aplicações IP: O padrão H.323 permite a integração de dados através do padrão T.120*, criando novos caminhos paraa colaboração com o mundo corporativo;
* Proteção do investimento das aplicações anteriores: O H.323 permite, através de um gateway, a conversão de protocolos de outros sistemas, tais como H.320 (ISDN) e H.324 - Plain and Old Telephony System (POTS), garantindo a integração destes sistemas com as aplicações H.323;
* Escalabilidade: O H.323 não limita o crescimento de uma rede. O padrão permite o crescimento do sistema de videoconferência dentro de regras e recomendações seguras para interoperabilidade entre os equipamentos;
* Interoperabilidade de equipamentos: O H.323 possibilita a interoperabilidade entre equipamentos de vários fabricantes;
* “Cross Plataform”: O padrão H.323 pode ser utilizado em um ambiente operacional de qualquer plataforma;
* Gerenciamento de largura de banda: No H.323, a largura de banda ocupada pelos tráfegos de áudio e vídeo é gerenciável, de forma que as conferências podem ser ou não ativadas dependendo da largura de banda disponível na rede ou no segmento de rede dos equipamentos envolvidos.

-------
*T120 - O padrão T.120 é um padrão guarda-chuva que contém um conjunto de protocolos de comunicação e aplicativos. Programas baseados em T.120 permitem que vários usuários participem de sessões de conferência em diferentes tipos de redes e conexões.

-----------

#### 1.6.1.3 SIP

O SIP constitui um protocolo alternativo ao H.323, tendo sido desenvolvido na Universidade de Columbia e posteriormente submetido à aprovação do IETF (*Internet Engineering Task Force*). Foi aprovado e emitido como RFC 2543 em março de 1999.

O protocolo SIP é baseado em texto, com características muito similares ao HTTP. Utiliza algumas características do HTTP, tais como regras de codificação e cabeçalhos.

O objetivo do SIP é de estabelecer uma sessão entre usuários, oferecendo recursos para localização de usuários, controle de chamada e gerência de participantes em uma conferência.

O SIP é um protocolo do tipo cliente-servidor, com sintaxe e semântica similar ao HTTP. As
requisições geradas por uma entidade cliente são enviadas para uma entidade do tipo servidor. O servidor processa a mensagem e devolve ao cliente uma resposta.

Componentes SIP

Tendo como base uma estrutura alicerçada na topologia cliente-servidor, o SIP possui dois
componentes:

***User Agent Client* (UAC)**

O UAC que, como o próprio nome indica, está residente no cliente e tem a finalidade de dar início às chamadas e enviar as requisições. O User Agent pode originar ou terminar uma sessão SIP. O UAC pode ser um telefone SIP, um cliente PC (softphone) ou até mesmo um gateway SIP.

**User Agent Server (UAS)**
O UAS, residente no servidor, é responsável pela resposta das requisições feitas pelo UAC.

A arqitetura SIP prevê basicamente três tipos de servidores distribuídos pela rede:

**Servidores de Registro:**

Compreende uma entidade que armazena a localização lógica dos UAS dentro dos domínios e dos subdomínios. Os servidores de registro recebem as atualizações sobre a localização corrente de cada usuário e efetuam a resolução dos nomes. Funcionam da mesma forma que os servidores DNS para uma rede web. Utilizam mensagens de registro (Register Messages) para este fim.

**Servidores *Proxy***

Cabe aos servidores Proxy a tarefa de receber as requisições e enviá-las aos outros servidores. Os outros servidores são denominados next-hop Servers. O servidor next-hop pode ser outro servidor Proxy , um UAS (User Agent Server) ou ainda um servidor de redirecionamento.

**Servidor de Redirecionamento**

Compreende uma entidade de controle de chamada que provê informação de roteamento ao UAS,
concedendo uma URI (Uniform Resource Identifier) alternativa, quando necessário. Basicamente, um servidor de redirecionamento recebe as requisições e determina um servidor next-hop.

**As principais diferenças entre os protocolos H.323 e SIP são apresentadas a seguir.**

<table>
<tr>
<center>

<td colspan="2">Filosofia</td>
</center>
</tr>
<tr>
<td><b>H.323:</b> A filosofia foi baseada em padrões bem definidos para comunicação em rede IP com recursos de multimídia.
</td>
<td><b>SIP:</b> O protocolo SIP foi desenvolvido para estabelecer uma sessão entre dois pontos. Não estabelece um padrão rígido para o estabelecimento da chamada, não possui suporte para conferência multimídia e a integração com os diversos outros padrões normalmente é deixada à cargo de cada fornecedor.</td>
</tr>
</table>

<table>
<tr>
<center>

<td colspan="2">Confiabilidade</td>
</center>
</tr>
<tr>
<td> <b>H.323:</b> Define um número de características para gerenciar falhas de entidades intermediárias da
rede. Como exemplo, se um gatekeeper falha, o protocolo está preparado para utilizar um
gatekeeper alternativo. Os endpoints H.323 podem se registrar a outro gatekeeper.</td>
<td> <b>SIP:</b> O SIP não dispõe de procedimentos para gerenciamento de falhas nos dispositivos. Se um
agente SIP falha, não existe meios para que o Proxy venha detectar a falha, exceto se o Proxy enviar
mensagens Invite para o dispositivo e aguardar o retorno dentro de um time-out determinado. Além
disto, caso o Proxy falhe, o Agente SIP não possui mecanismos para detectar a falha.</td>
</tr>
</table>

<table>
<tr>
<center>

<td colspan="2">Definição de Mensagem</td>
</center>
</tr>
<tr>
<td> <b>H.323:</b> Utiliza o padrão ASN.1 (Abstract Syntax Notation 1), extremamente preciso e de fácil entendimento e utilizado por vários sistemas </td>
<td> <b>SIP:</b> Utiliza o padrão ABNF (Augmented Backus-Naur Form) como notação sintática. </td>
</tr>
</table>

<table>
<tr>
<center>

<td colspan="2"> Codificação das Mensagens</td>
</center>
</tr>
<tr>
<td> <b>H.323:</b> codifica as mensagens em um formato compacto binário, adequado para conexões
de banda estreita ou de banda larga. </td>
<td> <b>SIP:</b> As mensagens SIP são codificadas no formato texto ASCII, adequadas para a leitura. Como
conseqüência, as mensagens são maiores e menos adequadas à redes que envolvem requisitos piores
para processamento e largura de banda.
</td>
</tr>
</table>

<table>
<tr>
<center>

<td colspan="2"> Protocolos de Transporte Utilizados
</td>
</center>
</tr>
<tr>
<td> <b>H.323:</b> RTP/RTCP.</td>
<td> <b>SIP:</b> RTP/RTCP.</td>
</tr>
</table>

<table>
<tr>
<center>

<td colspan="2">Load Balance </td>
</center>
</tr>
<tr>
<td> <b>H.323:</b> Possui habilidade para efetuar load balance entre endpoints ao longo de um número de gatekeepers alternativos. Em adição, os endpoints reportam sua disponibilidade e capacidade total,
de forma que chamadas endereçadas para um conjunto de gateways poderão por exemplo ser
melhor distribuídas através dos mesmos.</td>
<td> <b>SIP:</b> Não possui </td>
</tr>
</table>

<table>
<tr>
<center>

<td colspan="2"> Codecs</td>
</center>
</tr>
<tr>
<td> <b>H.323:</b> O H.323 suporta qualquer CODEC, seja ele padronizado ou proprietário</td>
<td> <b>SIP:</b> Suporta qualquer CODEC registrado na IANA ou outro CODEC cujo nome faz parte de um acordo de atualização.
</td>
</tr>
</table>

<table>
<tr>
<center>

<td colspan="2"> Endereçamento </td>
</center>
</tr>
<tr>
<td> <b>H.323:</b> Possui mecanismos de endereçamento flexíveis que incluem URL e padrão de
numeração E.164.</td>
<td> <b>SIP:</b> Somente permite o endereçamento através de URL. </td>
</tr>
</table>
O SIP possui a vantagem de ter, como fundamento, os protocolos internet, facilitando a integração de serviços com os serviços web, como o Instant Message. Com as raízes fundadas na tecnologia internet, e grande simplicidade, o protocolo SIP facilita a interoperabilidade para as redes de telefonia tradicionais e as aplicações web. Observa-se um crescimento crescente de aplicações SIP voltadas para telefonia VoIP.

Por outro lado, o H.323, apesar de compreender um padrão mais pesado, e de implementação mais detalhada, carrega uma pilha de especificações que, além de garantir a interoperabilidade entre os sistemas, agrega uma gama de serviços adicionais, voltados para aplicações de voz, vídeo e dados.

O receptor é que tem que lidar com as perdas e atrasos Note que Se usar o TCP como protocolo de transporte ao invés do UDP o que iria acontecer é que em caso de perda por colisão, enfileiramento, congestionamento etc, um pacote perdido iria sofrer um pedido de retransmissão, mas a fonte não parou de falar nem de transmitir, tornando assim a retransmissão de um pacote irrelevante para o receptor. Fora qie o *slow start* derruba a vazão.

## 1.7. TÉCNICAS DE ELIMINAÇÃO DA VARIAÇÃO DO ATRASO

O protocolo de camada de rede da Internet, IP, provê um serviço de melhor esforço. Em outras palavras, a Internet faz seu melhor esforço para transportar cada datagrama do remetente ao receptor o mais rapidamente possível, mas não faz nenhuma promessa sequer sobre o atraso fim a fim para um pacote individual, ou sobre o limite de perdas de pacotes.

Se cada pacote chegasse ao receptor com um atraso fim a fim constante a, digamos, cada 20 ms. Nessas condições ideais, o receptor pode simplesmente reproduzir cada parte assim que ele chega. Infelizmente alguns pacotes talvez se percam e a maioria dos que sobraram não possuirão o mesmo atraso fim a fim, ainda que a Internet esteja apenas ligeiramente congestionada. Por este motivo, o receptor deve se empenhar em determinar (1) quando reproduzir uma parte e (2) o que fazer com uma parte perdida.

Considere um dos segmentos UDPs, gerado por nossa aplicação VoIP. O segmento UDP é encapsulado por um datagrama IP. Enquanto o datagrama vagueia pela rede, ele passa por *buffers* (isto é, por filas) nos roteadores, aguardando para ser transmitido em enlaces de saída. É possível que um ou mais destes *buffers* na rota entre o remetente e o destinatário estejam lotados e não possam aceitar o datagrama IP. Nesse caso, o datagrama IP será descartado e nunca chegará à aplicação receptora.

A perda pode ser eliminada enviando os pacotes por TCP (que proporciona transferência de dados confiáveis), em vez de por UDP. Contudo, os mecanismos de retransmissão frequentemente são considerados inaceitáveis para aplicações interativas de áudio em tempo real, como o VoIP, porque aumentam o atraso fim a fim. Além disso, por causa do controle de congestionamento do TCP, após a perda de pacote a taxa de transmissão no remetente pode ser reduzida a uma taxa mais baixa do que a de reprodução no receptor, possivelmente ocasionando inanição no *buffer*.

Mas perder pacotes talvez não seja tão desastroso quanto se possa imaginar. Na verdade, taxas de perda de pacotes entre 1% e 20% podem ser toleradas, dependendo de como a voz é codificada e transmitida e de como a perda é ocultada no receptor. Por exemplo, o mecanismo de correção de erros de repasse (*forward error correction* — FEC) pode ajudar a ocultar a perda de pacotes.

### 1.7.1 Atraso fim-a-fim.

Atraso de fim a fim é o acúmulo de atrasos de processamento, de transmissão e de formação de filas nos roteadores; atrasos de propagação nos enlaces e atrasos de processamento em sistemas finais. Para as aplicações de áudio altamente interativas em tempo real, como oVoIP, atrasos fim a fim menores do que 150 ms não são percebidos pelo ouvido humano; entre 150 e 400 ms podem ser aceitáveis, mas não são o ideal e os que excedem 400 ms podem atrapalhar seriamente a interatividade em conversações por voz. O lado receptor de uma aplicação de telefone por
Internet em geral desconsiderará quaisquer pacotes cujos atrasos ultrapassarem determinado patamar, por exemplo, mais do que 400 ms. Assim, os pacotes cujos atrasos ultrapassem o patamar são efetivamente perdidos.

### 1.7.2 Variação de atraso do pacote

Um componente crucial do atraso fim a fim são os atrasos variáveis de fila que os pacotes sofrem nos roteadores. Por causa de tais atrasos, o tempo decorrido entre o momento em que um pacote é gerado na fonte e o momento em que é recebido no destinatário pode variar de pacote para pacote
Esse fenômeno é denominado variação de atraso.

Se o receptor ignorar a presença de variação de atraso e reproduzir as porções assim que elas chegam, então a qualidade de áudio resultante poderá facilmente se tornar ininteligível no receptor. Felizmente, a variação de atraso quase sempre pode ser eliminada com a utilização de números de sequência, marcas de tempo e atraso de reprodução, como discutido a seguir.
### 1.7.3 Eliminação da variação de atraso no receptor para áudio

Para uma aplicação de VoIP, em que pacotes vão sendo gerados periodicamente, o receptor deve tentar prover reprodução sincronizada de porções de voz na presença de variação de atraso aleatório. Isto normalmente é feito combinando os dois mecanismos seguintes:

1. Preceder cada parte com uma marca de tempo. O remetente marca cada parte com o instante em que ela foi gerada.
2. Atrasar a reprodução de porções no receptor. O atraso da reprodução das porções de áudio recebidas deve ser longo o suficiente para que a maioria dos pacotes seja recebida antes de seus tempos de reprodução programados. O atraso da reprodução pode ser fixado para todo o período de duração da sessão de áudio ou pode variar adaptativamente durante o período útil da sessão.

#### 1.7.3.1 Atraso por reprodução fixa

Com a estratégia do atraso fixo, o receptor tenta reproduzir cada parte exatamente q milissegundos após a parte ter sido gerada. Assim, se a marca de tempo de uma parte for $t$, o receptor reproduz a parte no tempo $t + q$, admitindo-se que a parte já tenha chegado naquele instante. Os pacotes que chegam após seus tempos de reprodução programados são descartados e considerados perdidos.

Mas qual é uma boa escolha para $q$? VoIP pode suportar atrasos de até cerca de 400 ms, embora com valores menores que q a experiência interativa resultante seja mais satisfatória. Por outro lado, caso se escolha um q muito menor do que 400 ms, muitos pacotes podem perder seus tempos de reprodução programados por causa da variação de atraso induzida pela rede. Em termos gerais, se grandes variações no atraso fim a fim forem características, será preferível usar um $q$ grande; por outro lado, se o atraso for pequeno e as variações também forem pequenas, será preferível usar um q pequeno, talvez menor do que 150 ms.

O compromisso entre o atraso de reprodução e a perda de pacotes é ilustrado na Figura abaixo. A figura mostra os tempos em que os pacotes são gerados e reproduzidos para uma única rajada de voz. Dois atrasos de reprodução iniciais distintos são considerados. Como mostram os degraus mais à esquerda do gráfico, o remetente gera pacotes a intervalos regulares — digamos, a cada 20 ms. O primeiro pacote dessa rajada de voz é recebido no tempo r. Como mostra a figura, as chegadas dos pacotes subsequentes não são espaçadas regularmente por causa da variação de atraso da rede.

Para o primeiro esquema de reprodução, o atraso inicial está estabelecido em $p – r$. Com esse esquema, o quarto pacote não chega dentro de seu atraso de reprodução programado e o receptor o considera perdido.

<center>

</center>

Pelo segundo esquema, o atraso inicial de reprodução fixo está estabelecido em $p’ – r$. Aqui, todos os pacotes chegam antes de seu tempo de reprodução e, portanto, não há perda.

#### 1.7.3.1 Atraso por reprodução adaptativo

O exemplo anterior demonstra um importante compromisso entre atraso e perda que surge ao se projetarem esquemas de reprodução com atrasos por reprodução fixa. Ao se decidir por um atraso inicial de reprodução grande, a maioria dos pacotes cumprirá suas programações e, portanto, a perda será insignificante; contudo, para serviços interativos como VoIP, atrasos longos podem se tornar incômodos, se não intoleráveis. Idealmente, gostaríamos que o atraso de reprodução fosse minimizado mas que mantivesse a limitação de perda abaixo de uns poucos por cento.

A maneira natural de tratar esse compromisso é estimar o atraso de rede e sua variância e ajustar o atraso de reprodução de acordo com o resultado, no início de cada rajada de voz. Esse ajuste adaptativo de atrasos de reprodução no início das rajadas de voz fará que os períodos de silêncio no receptor sejam comprimidos e alongados; contudo, compressão e alongamento de silêncio em pequenas quantidades não são percebidos durante a fala.

Tomando Ramjee [1994] como base, escrevemos agora um algoritmo genérico que o receptor pode usar para ajustar seus atrasos de reprodução adaptativamente. Para tal, consideremos:

$t_i=$ marca de tempo do i-ésimo pacote = o instante em que o pacote foi gerado pelo remetente
$r_i =$ o instante em que o pacote i é recebido pelo receptor
$p_i =$ o instante em que o pacote i é reproduzido no receptor

O atraso de rede fim a fim do i-ésimo pacote é $r_i–t_i$

Por causa da variação de atraso da rede, esse atraso variará de pacote a pacote. Seja $d_i$ a estimativa do atraso de rede médio para a recepção do i-ésimo pacote. Essa estimativa é obtida das marcas de tempo como segue:

$d_i = (1 – u) d_{i–1} + u (r_i – t_i )$

Seja $v_i$ uma estimativa do desvio médio do atraso em relação ao atraso médio estimado. A estimativa também é obtida com base nas marcas de tempo:

$v i = (1 – u) v_{i–1} + u | r_i – t_i – d_i |$

Uma vez calculadas essas estimativas, o receptor emprega o seguinte algoritmo para a reprodução de pacotes. Se o pacote i for o primeiro de uma rajada de voz, seu tempo de reprodução $p_i$ será computado como:

$p_i = t_i + d_i + Kv_i$

sendo K uma constante positiva (por exemplo, K = 4). A finalidade do termo $Kv_i$ é estabelecer o tempo de reprodução em um futuro longínquo o suficiente, de modo que apenas uma pequena fração dos pacotes que estão chegando na rajada de voz seja perdida devido às chegadas das atrasadas. O ponto de reprodução para qualquer pacote subsequente em uma rajada de voz é computado como um deslocamento em relação ao ponto no tempo em que o primeiro pacote foi reproduzido. Em particular, seja

$q_i = p_i – t_i$

a duração do tempo decorrido desde a geração do primeiro pacote da rajada de voz até sua reprodução. Se o pacote j também pertencer a essa rajada de voz, ele será reproduzido no tempo

$p_j = t_j + q_i$

## 1.8. TÉCNICAS DE RECUPERAÇÃO DE PERDA DE PACOTES (do Kurose)

<!--- https://www.midiacom.uff.br/debora/index.php/disciplinas/disciplinas-concluidas/30-redes-multimidia-fundamentos-de-sistemas-multimidia parte 10b 2020 2--->

slide 26 possibilidade de descarte de pacotes

### 1.8.1 FEC - Operação Xor

Pacotes redundante e Forward Error Correction (correção de erros de encaminhamento FEC)

As vezes a detecção de erros (checksum, etc) somente não é
suficiente, nesses casos algumas vezes a retransmissão
é necessária, mas quando os erros são comuns e retransmissão é
impossível como é caso do UDP, um esquema mais eficiente é
empregado - Forward Error Correction (FEC).
FEC envolve transmitir dados extras que permite a correção sem
retransmissão. E Correção de erros exige um código de correção
de erro (erro correction code - ECC)

Slide 34 vem depois do 26

Para cada $n$ pacotes ele faz um xor entre os pacotes e envia n+1 pacotes ou seja se precisar enviar dois pacotes ($p_1$ e $p_2$), na realidade ele enviará 3 pacotes e o 3° será $p_1\oplus p_2$.

### 1.8.2 FEC - Piggyback

Ao envio do pacote $n+1$ é adicionado o pacote $n$ codificado a uma menor qualidade (taxa menor)

<center>

</center>
### 1.8.3 FEC - Entrelaçamento (*interleaving*)

Não recupera, oculta a perda Ao reduzir o tamanho do pacote a probabilidade de erro cai e a perda de um frame de tamanho reduzido causa menos impacto na recepção.
<center>

</center>

## 1.9. REDES DE DISTRIBUIÇÃO DE CONTEÚDOS (CDN)

Muitas companhias de vídeo na Internet têm distribuído sob demanda fluxos contínuos multi-Mbits/s para milhões de usuários diariamente. YouTube, por exemplo, distribui centenas de milhões de vídeos de fluxo contínuo para usuários ao redor do mundo inteiro, todos os dias. Controlar o fluxo contínuo de todo esse tráfego para locais ao redor do mundo inteiro, enquanto provê reprodução contínua e grande interatividade constitui-se claramente uma tarefa desafiadora.

Talvez a mais franca abordagem para prover serviços de vídeo de fluxo contínuo seja construir um único datacenter, armazenar todos os vídeos e realizar o fluxo contínuo dos vídeos diretamente do datacenter para os clientes ao redor do mundo.

Três grandes problemas surgem com essa abordagem.

* se o cliente estiver muito longe do datacenter, os pacotes atravessarão muitos ISPs com alguns destes ISPs talvez localizados em diferentes continentes. a taxa de transferência fim a fim será também abaixo da de consumo, resultando para o usuário em atrasos incômodos e congelamentos.
* Uma segunda desvantagem é que um vídeo popular será possivelmente enviado muitas vezes pelos mesmos enlaces de comunicação.
* *Single point of failure*

Para enfrentar o desafio de distribuição de uma quantidade maciça de dados de vídeo para usuários espalhados ao redor do mundo, quase todas as maiores companhias de vídeo de fluxo contínuo fazem uso de Redes de Distribuição de Conteúdo (CDNs).

Uma CDN gerencia servidores em múltiplas localidades distribuídas geograficamente, armazena cópias dos vídeos (e outros tipos de conteúdos da rede, incluindo documentos,
imagens e áudio) em seus servidores, e tenta direcionar cada requisição do usuário para uma localidade CDN que proporcionará a melhor experiência para o usuário.

As CDNs podem ser privadas, isto é, que pertence ao próprio provedor de conteúdo; por exemplo, a CDN da Google distribui vídeos do YouTube e outros tipos de conteúdo. As CDNs também podes ser de terceiros, que distribuem conteúdo em nome de múltiplos provedores de conteúdo; a da Akamai, por exemplo, é uma CDN de terceiros que distribui conteúdos do Netflix e da Hulu, dentre outros.

As CDNs adotam em geral uma entre as duas filosofias de instalação de servidores:

* *Enter deep.* é entrar profundamente dentro das redes de acesso dos Provedores de Serviço de Internet pela implantação de clusters de servidores no acesso de ISPs por todo o mundo. O objetivo é conseguir proximidade com os usuários finais, melhorando assim o atraso percebido pelo usuário e a taxa de transferência pela diminuição do número de enlaces e roteadores entre o usuário final e o agrupamento da CDN da qual ele recebe conteúdo.
* Por causa desse projeto altamente distribuído, a tarefa de manter e gerenciar os agrupamentos se torna desafiadora.

* *Bring home*. Uma segunda filosofia de projeto, é trazer para dentro de casa os ISPs, construindo clusters enormes, mas em um número menor (por exemplo, dezenas) de lugares-chave e conectando-os em uma rede privada de alta velocidade. Em vez de entrar nos ISPs de acesso, estas CDNs normalmente colocam cada cluster em uma localidade que seja ao mesmo tempo próxima aos PoPs de muitos ISPs da camada 1, por exemplo, a algumas milhas tanto da AT&T quanto aos PoPs da Verizon em uma cidade maior. Comparado com a filosofia de projeto *enter deep*, o projeto bring home em geral resulta em menos desperdício com gerenciamento e manutenção, mas um maior atraso e menores taxas de transferência para os usuários finais.

O google opera uma solução híbrida que
faz uso em maior ou menor grau das
soluções enter deep e bring home

**Uso complementar do Cache:**

Uma vez que os seus clusters estejam operando, a CDN replica conteúdo através dos seus clusters. A CDN pode não querer pôr uma cópia de todos os vídeos em cada cluster, já que alguns vídeos são vistos raramente ou são populares só em alguns países. De fato, muitas CDNs não empurram vídeos para seus clusters, mas, em vez disso, usam uma estratégia simples de puxar o conteúdo: Se um cliente requisita um vídeo de um cluster que não o está armazenando, o cluster recupera o vídeo (de um repositório central ou de outro cluster) e armazena uma cópia localmente enquanto envia o fluxo contínuo para o cliente ao mesmo tempo. Similar aos caches de Internet, quando a memória do cluster fica cheia, ele remove vídeos que não são frequentemente requisitados.

**DNS redirection:**

Uma característica chave da CDN é a escolha correta do servidor de mídia que esteja o mais próximo possível usuário requisitante. Duas restrições surgem imediatamente uma é o software do cliente que não deve ser modificado e outra é que o redirecionamento precisa ser eficiente. **Uma resposta prática é o DNS.**

<center>

DNS redireciona uma requisição do usuário para um servidor de CDN.
</center>

1. O usuário visita a página da Internet no www.NetCinema.com
2. Quando o usuário clica no link <http://video.netcinema.com/6Y7B23V>, note que o servidor mudou) o host do usuário envia uma consulta de DNS para **video.netcinema.com.**
3. O Servidor de DNS local (LDNS) do usuário retransmite a consulta de DNS a um servidor DNS autoritativo pelo NetCinema, o qual encontra a palavra “video” no nome do novo host video.netcinema.com. Então “entregar” a consulta de DNS à KingCDN, em vez de um endereço IP. O servidor de DNS autoritativo do NetCinema retorna ao LDNS um nome de host no domínio da KingCDN, por exemplo, a1105.kingcdn.com.
4. Deste ponto em diante, a consulta de DNS entra na infraestrutura da DNS privada da KingCDN. O LDNS do usuário, então, envia uma segunda consulta, agora para a1105.kingcdn.com, e o sistema de DNS da KingCDN por fim retorna os endereços IP de um servidor de conteúdo da KingCDN para o LDNS. Assim, é aqui, dentro do sistema de DNS da KingCDN, que é especificado o servidor de CDN de onde o cliente receberá o seu conteúdo.
5. O LDNS encaminha o endereço IP do nó de conteúdo/serviço da CDN para o host do usuário.
6. Uma vez que o cliente obtém o endereço IP de um servidor de conteúdo da KingCDN, ele estabelece uma conexão TCP direta com o servidor que se encontra nesse endereço IP e executa uma requisição HTTP GET para obter o vídeo. Se utilizar DASH(Dynamic Adaptive Streaming over HTTP), o servidor primeiro enviará ao cliente um arquivo de manifesto com uma lista de URLs, uma para cada versão do vídeo, e o cliente irá dinamicamente selecionar trechos das diferentes versões codificadas com qualidades diferentes.

No centro de qualquer distribuição de uma CDN está a estratégia de seleção de cluster, isto é, um mecanismo para direcionamento dinâmico de clientes para um cluster de servidor ou uma central de dados dentro da CDN. Como acabamos de ver, a CDN descobre qual o endereço IP do servidor LDNS do cliente consultando o DNS do cliente. Após descobrir esse endereço IP, a CDN precisa selecionar um cluster apropriado baseado nesse endereço IP. As CDNs geralmente empregam estratégias próprias de seleção de cluster. Examinaremos agora algumas abordagens naturais, cada uma com suas vantagens e desvantagens.

Quando uma requisição DNS é recebida de um determinado LDNS, a CDN escolhe o cluster mais próximo geograficamente, isto é, o cluster que está a uma distância menor, em quilômetros, do LDNS. Esta solução pode funcionar razoavelmente bem para uma boa parte dos clientes. No entanto, para alguns clientes, esta solução pode ter um desempenho ruim, uma vez que o cluster geograficamente mais próximo pode não ser o mais próximo se considerarmos o caminho percorrido pela rede. Mais ainda, existe um problema inerente a todas as abordagens baseadas em DNS, que consiste no fato de que alguns usuários finais são configurados para utilizar LDNSs remotas.
Uma alternativa Por exemplo, o atraso entre um cliente e um cluster pode ser estimado examinando o intervalo entre um SYNACK do servidor para o cliente e o ACK do cliente para o servidor, durante a apresentação de três vias do TCP. Tais soluções, porém, requerem, de tempos em tempos, o redirecionamento de clientes para (possivelmente) clusters que não são os melhores, a fim de medir as propriedades dos caminhos para esses clusters. Embora seja necessário apenas um pequeno número de requisições para servir de mensagens de verificação, os clientes selecionados podem sofrer uma degradação de desempenho significativo quando receberem conteúdo.

## 1.10. REDES PAR A PAR

A tecnologia *peer-to-peer* (P2P) surge para mudar o paradigma existente, à medida que não depende de uma organização central ou hierárquica, além de dispor aos seus integrantes as mesmas capacidades e responsabilidades. Através dessa tecnologia qualquer dispositivo pode acessar diretamente os recursos de outro, sem nenhum controle centralizado.
A inexistência de um servidor central significa que é possível cooperar para a formação de uma rede P2P sem qualquer investimento adicional em hardware de alto desempenho para coordená-la. Outra vantagem é a possibilidade de agregar e utilizar a capacidade de processamento e armazenamento que fica subutilizada em máquinas ociosas. Além disso, a natureza descentralizada e distribuída dos sistemas P2P torna-os inerentemente robustos a certos tipos de falhas muito comuns em sistemas centralizados. Finalmente, o modelo P2P apresenta o benefício da escalabilidade, para tratar de crescimentos incontroláveis no número de usuários e equipamentos conectados, capacidade de rede, aplicações e gargalos de processamento.

**Definição:** Uma arquitetura de rede distribuída pode ser chamada de rede Peer-to-Peer (P-to-P, P2P,...), se os participantes compartilham uma parte de seus próprios recursos (hardware) (processamento) potência, capacidade de armazenamento, capacidade de *link* de rede, impressoras,...). Esses recursos compartilhados são necessários para fornecer o serviço e o conteúdo oferecido pela rede (por exemplo, compartilhamento de arquivos ou espaços de trabalho compartilhados para colaboração). Eles são acessíveis por outros pares diretamente, sem passar por entidades intermediárias. Os participantes de tal rede são, portanto, recursos provedores (de serviços e conteúdo) bem como solicitantes de recursos (serviços e conteúdo). E em geral devem suportar os seguintes requisitos:

* Nós podem estar localizados nas bordas da rede;
* Nós com conectividade variável ou temporária e endereços também variáveis;
* A capacidade de lidar com diferentes taxas de transmissão entre nós;
* Nós com autonomia parcial ou total em relação a um servidor centralizado;
* Assegurar que os nós possuem capacidades iguais de fornecer e consumir recursos de seus peers;
* A rede deve ser escalável;
* A capacidade dos nós se comunicarem diretamente uns com os outros.

Tendo todas estas características, uma rede pode ser dita *peer-to-peer*, mesmo que algumas das funções de controle da rede estejam localizadas em um servidor central (ponto de falha).

### 1.10.1 Redes P2P e Redes Overlay

Uma rede overlay é uma rede “virtual” criada sobre uma rede existente, por exemplo: a Internet, com infra-estrutura IP. A rede overlay cria uma arquitetura com nível mais alto de abstração, de modo a poder solucionar vários problemas que, em geral, são difíceis de serem tratados ao nível dos roteadores da rede subjacente. A própria Internet pratica o paradigma overlay quando usa o protocolo IP como solução de interworking sobre tecnologias de redes diversas como ATM, Frame Relay, PSTN, LANs, etc.

Numa perspectiva de alto nível, uma rede P2P pode ser considerada uma rede overlay, uma vez que funciona como uma rede virtual, formada pela interconexão dos nós (peers), executando sobre a infra-estrutura de uma rede física (Figura 1).

### 1.10.2. Modelos de Arquitetura P2P

Existem diferentes categorizações dos modelos de arquitetura P2P indicados na literatura, das
quais três são apresentadas nesta seção. Na primeira categorização, quanto a centralização, são considerados dois modelos de rede P2P:

**Descentralizado –** uma rede onde não há um ponto central e cada nó tem o mesmo nível. Neste modelo todos os nós são autônomos e todos os nós são responsáveis por troca de recursos e por controle (gerenciamento) de recursos. Os nós podem se comunicar de maneira direta ou através de vizinhos comuns (melhor escala de informações de controle, pior escala de tráfego de rede);
<center>

</center>

**Híbrida:**

Diferente de um conceito "puro" peer-to-peer, onde apenas os próprios pares eram permitidos na rede, uma rede "híbrida" sempre incluirá algum tipo de entidade central.

<center>


</center>
**Semicentralizado –** uma rede onde há diferença de relevância entre os nós, havendo um nó central para informações de controle (e, possivelmente, para tráfego de dados) ou um conjunto de supernós que assume tais funções (onde a queda de um supernó afeta apenas os nós inferiores ligados a ele). Os nós inferiores podem ter maior ou menor nível de autonomia, mas são equivalentes entre si.

Na segunda categorização, quanto ao tipo de busca, existem três tipos de arquitetura de rede P2P:

**Busca centralizada –** rede com um ponto central (possivelmente espelhado para outros pontos, dando a impressão de serem vários) de busca e nós que consultam o ponto central para trocar informações diretamente entre os peers;

**Busca por inundação –** rede com nós totalmente independentes, onde normalmente a busca é limitada à vizinhança mais próxima do nó que fez a busca (assim, a busca é escalável, mas não é completa);

**Busca por tabela hash distribuída (DHT) –** rede onde os nós têm autonomia e usam uma tabela hash para separar o espaço de busca entre eles.

Abaixo exemplos das principais classes de aplicações P2P:
* mensagem instantânea, (aim)
* compartilhamento de arquivo, (utorrent)
* computação distribuída (seti@home)
* e trabalhos colaborativos (*groupware*).

### 1.10.3 Questões de projeto das redes P2P

Essa seção apresenta as principais questões que devem ser consideras no projeto de sistemas P2P

#### 1.10.3.1 Endereçamento.

Aplicações inerentemente P2P necessitam de conexões diretas entre os peers. Entretanto um problema preponderante a ser tratado no projeto desses sistemas são as barreiras de proteção dispostas nas redes, que impedem a comunicação direta entre os peers. Os tipos de proteção mais utilizados são os firewalls, servidores proxy e NAT – *Network Address Translator*.

Uma solução para transpor essas barreiras pode ser implementada utilizando o protocolo HTTP: HTTP *tunneling*. Esse protocolo permite que um web browser inicie um pedido em um servidor WEB através da porta de comunicação 80. Isso efetivamente não se traduz em ameaça, uma vez que aplicações externas não podem iniciar ações danosas nas máquinas da rede interna, pois em nenhum momento o servidor WEB inicia uma conexão com
o web browser. Por isso, engenheiros de segurança normalmente permitem que essa porta não seja barrada pelos firewalls. Essa solução também é aplicada para redes que utilizam servidores proxy e NAT.

Um problema com a estratégia HTTP tunneling é que a comunicação não mantém estado. As respostas podem ser associadas aos pedidos, mas o contexto entre cada ciclo pedido/resposta anterior é perdido. Outro problema com HTTP *tunneling* está relacionado com a necessidade de iniciar uma mensagem ou passar dados para um cliente “protegido” por firewall. Como foi dito, o mundo exterior não pode iniciar uma comunicação para fornecer uma mensagem, a única alternativa é esperar para que o cliente entre em contato com o servidor e retire a mensagem. Isso pode aumentar o número de mensagens e conseqüentemente a latência. Portanto, clientes em redes cobertas por firewalls têm a desvantagem de não poderem atuar como peers servidores.

A utilização de peers para retransmissão agindo como servidores http, com razoável capacidade de enlace e posicionados em lugares estratégicos na rede, pode isolar o fluxo de mensagens provenientes dos peers “protegidos”, melhorando o desempenho do HTTP tunneling.

#### 1.10.3.2 heterogeneidade dos enlaces.

As conexões da maioria dos peers trabalham com baixas taxas de conexão (e muitas vezes assimétricas em relação ao *downlink* e ao *uplink*), e ao mesmo tempo existe uma variedade muito grande de tipos de conexões – *dial-up*, banda larga (cable modem, isdn, etc.), redes acadêmicas e corporativas. Outra importante característica dos enlaces é a assimetria no provisionamento das bandas para upload e download. . Em geral, existe uma tendencia que
peers bem estabelecidos, isto é, com alta capacidade de processamento e armazenamento, e
conectados a enlaces dedicados de alta capacidade sejam mais requisitados.

#### 1.10.3.3 Escalabilidade

Um dos benefícios imediatos da descentralização das redes P2P é a melhor escalabilidade dos sistemas. A escalabilidade é limitada por fatores relacionados à quantidade de operações centralizadas, como coordenação e sincronização, os estados que precisam ser mantidos, o paralelismo inerente das aplicações e o modelo de programação utilizado na construção do sistema.

Em geral, sistemas P2P tendem a ter maior escalabilidade que sistemas que utilizam o modelo cliente-servidor. Em um sistema cliente-servidor, os servidores são os únicos responsáveis por toda a carga do sistema. O que ocorre muitas vezes é que em horários de pico os servidores ficam sobrecarregados e o sistema como um todo tende a oferecer um serviço com baixa qualidade. Em um sistema P2P, quando o número de clientes na rede aumenta, cresce também o número de servidores, uma vez que todos podem atuar como clientes e servidores, aumentando na mesma proporção a quantidade de recursos compartilhados. Dessa forma, o sistema aumenta de tamanho sem perder escalabilidade.

Algoritmos mais recentes, dentre eles, CAN, Chord, Oceanstore e Pastry implementam mapeamento consistente entre a chave do objeto e o peer hospedeiro, conseqüentemente um objeto pode ser recuperado tão logo os peers hospedeiros possam ser alcançados. Peers nesses sistemas compõem uma rede overlay. Cada peer mantém somente informações acerca de um pequeno número de outros nós no sistema. Essa característica limita a quantidade de estados do sistema que precisam ser mantidos, melhorando dessa forma a escalabilidade e proporcionando também balanceamento de carga. Por exemplo, Oceanstore foi projetado para permitir bilhões de usuários, milhões de peers servidores e mais de $10^{10}$ arquivos disponíveis na rede.

#### 1.10.3.4 Roteamento (**aqui não é IP**)

Localizar informação numa rede volátil, de grande escala e altamente distribuída não é tarefa simples. Nessa seção serão descritos os principais mecanismos de roteamento existentes, ressaltando suas vantagens e desvantagens.
Algoritmos de busca e roteamento geralmente tentam otimizar o encaminhamento de uma mensagem de um peer para outro.

Os três modelos mais comuns são : centralizado, inundação e tabela de *hash* distribuída (DHT). O modelo de inundação é também classificado como modelo “descentralizado não-estruturado”, enquanto que o modelo DHT é chamado de modelo “descentralizado estruturado”. Isso se deve ao mecanismo (estruturado ou não) de entrada de um nó na rede e de busca de informações.

**Modelo Centralizado**
Popularizado pelo Napster, esse modelo caracteriza-se pela conexão dos peers a um diretório central onde eles publicam informações sobre o conteúdo que oferecem para compartilhamento. Como ilustra a Figura 6, ao receber uma requisição, o índice (diretório) central escolhe o peer no diretório que for mais adequado. Esse peer pode ser o mais rápido e disponível, dependendo das necessidades do usuário. Então, a troca de arquivos será realizada diretamente entre os dois peers. Esse modelo requer uma infra-estrutura de gerenciamento (o servidor de diretórios), que armazena informações sobre todos os participantes da comunidade. Tal aspecto pode gerar limites de escalabilidade ao modelo, uma vez que requer servidores maiores quando o número de requisições aumenta, e mais espaço para armazenamento à medida que a quantidade de usuários cresce. Contudo, a experiência do Napster mostrou que, exceto por questões legais, esse modelo era bastante robusto e eficiente.

**Modelo de Inundação:**

O modelo de inundação de requisições é diferente do modelo de índice central, pois não se baseia na publicação dos recursos compartilhados. Ao invés disso, cada requisição de um peer é enviada para todos os peers diretamente conectados, os quais enviam para os peers diretamente conectados a eles, e assim sucessivamente até que a requisição seja respondida ou que ocorra o número máximo de encaminhamentos (tipicamente 5 a 9). Esse modelo (Figura 7) é utilizado pelo Gnutella e requer alta capacidade dos enlaces de comunicação para proporcionar desempenho razoável, apresentando problemas de escalabilidade quando o objetivo é alcançar todos os peers em uma rede. Contudo, o modelo é eficiente em comunidades limitadas e em redes corporativas.

**Modelo DHT**
O modelo de tabelas de hash distribuídas (DHT) é o mais recente. Nesse modelo, um ID randômico é associado a cada peer da rede que conhecem um determinado número de peers Quando um documento é publicado (compartilhado) em tal sistema, um ID é associado ao documento baseado em uma hash de conteúdo dos documentos e no seu nome. Cada peer então encaminha o documento ao peer cujo ID é mais próximo do ID do documento. Esse processo é repetido até que o ID do peer atual seja o mais próximo do ID do documento.

Cada operação de roteamento também garante que uma cópia local do documento seja mantida. Quando um peer solicita o documento de um sistema P2P, a requisição irá até o peer com ID mais semelhante ao ID do documento. Esse processo continua até que uma cópia do documento seja encontrada. Então o documento é transferido ao peer que originou a requisição, enquanto cada peer que participou do roteamento permanecerá com uma cópia local do documento.

Apesar do modelo DHT ser eficiente para comunidades grandes e globais, ele apresenta um problema relacionado ao ID do documento. Este precisa ser conhecido antes que uma requisição do documento seja realizada. Assim, é mais difícil implementar uma pesquisa nesse modelo que no modelo de inundação. Além disso, pode ocorrer a formação de “ilhas”, onde a comunidade se divide em sub-comunidades que não possuem nenhuma ligação (links) entre si.

Existem quatro algoritmos principais que implementam esse modelo: Chord, CAN, Tapestry e Pastry,

### 1.10.X Bit torrent
BitTorrent é uma tecnologia\/protocolo que faz a distribuição de arquivos, especialmente grandes arquivos de modo mais fácil e usando menos largura de banda para o seeder. Isso é feito utilizando a capacidade de upload dos pares que estão baixando um arquivo. Um aumento considerável nos ownloaders só resultará em um aumento modesto na carga no editor que hospeda o arquivo.

<center>

O fluxo básico do protocolo BitTorrent
</center>

A ilustração na Figura acima mostra o fluxo básico do BitTorrent. A figura à esquerda mostra um abordagem cliente-servidor para download. Os pares baixam do servidor simultaneamente. Se nós assumir a capacidade de upload do servidor é o mesmo que a capacidade de download de um peer, o tempo para o download para terminar será duas vezes o tempo se apenas um par onde baixar do servidor. A figura à direita mostra uma abordagem semelhante ao BitTorrent. Dividindo o arquivo e enviando uma parte para cada par, e deixando os pares baixar a parte que está faltando para um e para outro, tanto o tempo de download quanto a carga no servidor são reduzidos. Claro, o O protocolo BitTorrent é muito mais sofisticado do que este simples exemplo, mas isso mostra a ideia básica.

O BitTorrent é de longe o programa peer-to-peer mais popular de todos os tempos. A análise mostra que representa cerca de 35% de todo o tráfego da Internet . Como se tornou tão popular, e o que torna isso tão especial? No final dos anos 90, Bram Cohen cansou de saltar entre dotcoms que nunca lançou qualquer produto antes que eles foram falido. Ele decidiu desenvolver algo por conta própria, e tem inspiração de seu último trabalho. A ideia desta empresa era manter um arquivo seguro e seguro, quebrando-o em pequenos pedaços, criptografar os pedaços e armazená-los em diferentes locais. Bram percebeu que o conceito de quebrar um arquivo em pedaços menores também poderia ser usado em arquivo compartilhamento. No verão de 2001, Cohen lançou sua primeira versão beta de BitTorrent. Em 2002, ele apresentou-o em uma conferência. Seu objetivo com este software era dar pessoas uma maneira rápida e simples de distribuir e trocar software Linux on-line. Mas, como todos nós sabemos, os nerds de cinema logo viram o potencial na tecnologia BitTorrent. Em 2004, cópias piratas de filmes e programas de TV começou a dominar o tráfego BitTorrent, e depois disso o crescimento tem sido explosivo. Projeta-se que até o final deste ano cerca de 40 milhões de pessoas baixaram o aplicativo BitTorrent.

O problema com muitos protocolos de ompartilhamento de arquivos "tradicionais", aos olhos de Bram Cohen, é que a maioria dos usuários tem velocidades diferentes downlink e uplink. Isso significa que mesmo embora um usuário tenha muita largura de banda downlink, a velocidade de uma transferência de arquivo para ele será restrito por um uplink de largura de banda muito menor do usuário que ele baixa.

Isso implica que o compartilhamento de arquivos um para um não é a solução ideal. É, no entanto, a maneira protocolos tradicionais de compartilhamento de arquivos (como KaZaa) funcionam. Bram Cohen gerenciou este problema dividindo arquivos em pedaços menores. Ao solicitar um arquivo, o computador do usuário fareja a internet por usuários que têm uma ou mais peças do arquivo procurado. Ele então baixa diferentes partes do arquivo de diferentes usuários ao mesmo tempo através de seu downlink com largura de banda melhor. O efeito é, naturalmente, que o arquivo chega muitas vezes mais rápido em comparação com
download de apenas um usuário. Parece simples, não é? Capítulo 4 explicará em detalhes como o BitTorrent torna isso possível.

#### 1.10.X.1 Arquitetura BitTorrent

A arquitetura BitTorrent normalmente consiste nas seguintes entidades:
- um arquivo metainfo estático (um "arquivo torrent")
- um 'tracker'
- usuário baixador original ("seed")
- o usuário baixador final ("leecher")

<center>

O BitTorrent em sua forma original corresponde ao conceito "híbrido" peer-to-peer. É tudo sobre o arquivo torrent, o rastreador centralizado e o enxame de pares. O rastreador centralizado fornece às diferentes entidades uma lista de endereços sobre os pares disponíveis. Esses pares, então, entrarão em contato uns com os outros para baixar pedaços do arquivo do outro.

</center>

O primeiro passo para publicar um arquivo usando o BitTorrent é criar um arquivo metainfo a partir do arquivo que você deseja publicar. O arquivo metainfo é chamado de "torrent". o o arquivo torrent contém o nome do arquivo, o tamanho, as informações de hashing e a URL do "tracker" (figura azul). O "torrent" é necessário para quem quiser baixar o arquivo do que o torrent é criado. O arquivo torrent pode ser distribuído por e-mail, IRC, http etc.

O rastreador mantém um registro de pares que estão atualmente baixar um arquivo, e ajuda-os a encontrar um ao outro. o rastreador não está diretamente envolvido na transferência de dados e não tem uma cópia do arquivo. O rastreador e os usuários que baixam trocam informações usando um protocolo simples em cima de HTTP. Primeiro, o usuário dá informações ao rastreador sobre qual arquivo está baixando, portas que está ouvindo etc. A resposta do rastreador é uma lista de outros usuários que estão baixando o mesmo arquivo e informações sobre como contatá-los. Este grupo de pares que compartilham a mesma torrente representa um "enxame".

No entanto, fazer um arquivo torrent não é suficiente para disponibilizar o arquivo que você deseja distribuir. Um downloader original conhecido como "semente" tem que ser iniciado. Uma "semente" é um usuário que tem o arquivo inteiro. Um usuário de download que não tem nada ou apenas partes de um arquivo é chamado de "leecher". A "semente" deve carregar pelo menos uma cópia completa do arquivo. Uma vez que uma cópia inteira é distribuído entre os outros downloaders, a 'semente' pode parar de carregar e o download ainda vai continuar para todos os downloaders, desde que haja pessoas suficientes baixando o arquivo, e todas as peças do arquivo estão disponíveis. Sempre que uma peça é baixada e verificada, o download de relatórios pares para o outros pares no enxame sobre sua nova peça. Esta peça já está disponível para outros pares.

#### 1.10.X.2 Políticas do BitTorrent

* A principal política no BitTorrent é a de "primeiro o pedaço mais raro". Isso significa que quando um peer seleciona o próxima peça para baixar, ele seleciona a peça que menos de seus pares tem. Há várias razões para isso ser uma boa política

* Espalhando a semente: O mais raro primeiro garante que apenas peças "novas" sejam baixadas da semente. No início, a semente será um gargalo, já que é a única com qualquer pedaço do arquivo. Um downloader pode ver que peças seus pares têm, e os "a política mais rara primeiro" resultará em que as peças retiradas da semente são peças que ainda não foram carregados por outros.
* Maior velocidade de download: Quanto mais pares tiverem a peça, mais rápido será o download pode acontecer, pois é possível baixar sub-peças de diferentes lugares. Queremos replicar peças raras para que possam ser baixadas mais rapidamente.
* Habilitação do upload: Uma peça rara é mais desejada por outros pares, e por obter um raro peça outros estarão interessados em carregar de você.
* Último mais comum: É sensato deixar as peças mais comuns até o fim do baixar. Uma vez que muitos pares têm isso, a probabilidade de ser capaz de baixá-los mais tarde é muito maior do que o das peças raras.
* Evite a falta de peça mais rara: Quando a semente é retirada, é importante que todas as diferentes peças do arquivo são distribuídas em algum lugar entre os pares restantes. Ao replicar as peças mais raras primeiro, reduzimos o risco de perder uma ou mais peças de um arquivo quando o seeder sai.
* End game mode: Quando todas as sub-peças que um peer não tem são ativamente sendo solicitado, estes são solicitados de todos os pares.

## 1.11 APLICAÇÕES MULTIMÍDIA DISTRIBUÍDAS (VIDEOCONFERÊNCIA, IP TV)

**PARA VIDEO CONFERÊNCIA VER SEÇÃO 1.6**
<!--- https://www.midiacom.uff.br/debora/index.php/disciplinas/disciplinas-concluidas/30-redes-multimidia-fundamentos-de-sistemas-multimidia parte 11a e b 2020 2--->

O IPTV representa a transmissão de sinais multimídia, tais como: áudio, vídeo, gráficos, textos e TV, sempre transportando em rede IP com garantias de qualidade, segurança, integridade e confiabilidade.

Os serviços de vídeo englobam duas grandes categorias – *broadcast* e vídeo armazenado.
O serviço de *broadcast* é o tradicional existente na TV aberta ou TV paga, baseado em
canais e grades de programação.Também para os usuários há a possibilidade de controlar o conteúdo armazenado incluindo funções como *play, stop, rewind, fast forward*. Exemplos de modalidades de serviços nesta categoria incluem:

Video on Demand (VOD): usuário pode selecionar o conteúdo que deseja assistir de uma lista que inclui filmes, documentários, entre outros programas. Existem diversas variações de modalidades do serviço como, por exemplo: near VOD (NVOD) em que existem horários pré-definidos (ex.: meia em meia hora) para início da exibição de um determinado conteúdo; subscription VOD (SVOD) em que o usuário paga uma assinatura que lhe dá direito a consumir uma quantidade de títulos determinada; free VOD (FVOD) em que o usuário possui acesso gratuito a conteúdo sob demanda; e o VOD propriamente dito em que, tradicionalmente, o usuário paga por transação.

Virtual Channels: é uma variação dos serviços NVOD em que a operadora cria canais
virtuais para exibir conteúdos selecionados. Por exemplo, é possível criar canais virtuais
temáticos onde são exibidos filmes de um determinado gênero sequencialmente.

**Os serviços de áudio incluem:**

<ins>Broadcast* de música</ins>: serviços de transmissão de estações de rádio tradicionais ou de canais de música criados pela operadora, e que podem ser personalizados e já são oferecidos pelas operadoras de TV a cabo e satélite.
<ins>Música sob demanda</ins>: serviço análogo ao VOD aplicado no contexto de música,
permitindo ao usuário selecionar as músicas que deseja ouvir e até criar coleções
personalizadas.

A infraestrutura de rede é constituída pelas diversas redes que suportam o serviço IPTV.
Em essência, essa camada oferece o serviço IP de maneira fim-a-fim valendo-se de uma
rede conhecida como multisserviços.

<center>

</center>

Núcleo da rede IP

É responsável por transportar o elevado volume de tráfego das diversas redes de
agregação, utiliza tecnologia das redes IP e a sua função, na essência, é o transporte e
roteamento combinando tecnologias em duas camadas principais. IP e MPLS

Rede de Acesso

Acesso
Redes de acesso atendem às necessidades de largura de banda exigidas pelos serviços
de vídeo, pode-se utilizar para o IPTV várias implementações de rede de acesso, tais como : xDSL, PON e GPON. A rede de acesso interliga o ambiente do prestador de serviço até o usuário.

A tecnologia xDSLque são redes adaptadas para prestação de serviços de Internet Banda Larga valendo-se da Digital tecnologia Digital Subscrider Line (DSL). O padrão mais difundido é o Asymetric DSL (ADSL2plus).

### 1.11.1 Protocolos utilizados no tráfego de IPTV

Em uma rede IPTV, os pacotes de vídeo são carregados em geral utilizando-se protocolos
de tempo real, de maneira a privilegiar a característica do tráfego multimídia de fluxo contínuo. Um exemplo de protocolo utilizado em IPTV é o *Internet Group Management Protocol* (IGMP) que será analisado em seus tipos de endereçamento mais a frente.

**Protocolos de tempo real:**

Após a codificação do vídeo utilizando, por exemplo, o padrão MPEG-2, os pacotes
resultantes da codificação são transportados em geral utilizando *User Datagram Protocol*
(UDP) sobre IP.

A razão para a utilização do UDP em detrimento do Transmission Control Protocol (TCP) é
que ele não prevê retransmissão de pacotes perdidos, o que poderia prejudicar o sincronismo que é de fundamental importância no tráfego de vídeo.

O encapsulamento dos pacotes UDP é realizado utilizando Real Time Protocol (RTP) que
suporta transmissão de conteúdo em tempo real, valendo-se de mecanismos de controle,
para sincronizar diversos streams
com características de sincronização temporais.

O protocolo RTP pode vir associado de seu protocolo de controle Real Time Control Protocol (RTCP), que oferece funções de *feedback* e sinalização de Qualidade de Serviço (QoS), sincronização, identificação
de participantes e informações de controle de sessão.

Adicionalmente, no caso de serviços de Video on Demand (VOD), pode-se utilizar o
protocolo de controle de sessão Real Time Streaming Protocol (RTSP) que associado ao
RTP pode oferecer funcionalidades análogas ao DVD – funções como: *play, pause, rewind*
para serviços baseados em streaming.

### 1.11.2 Tipos de endereçamento

Dependendo do tipo de tráfego, existem três tipos de endereçamento capazes de levar pacotes IP ou frames Ethernet de sua origem ao destino.

**Unicast:**

O endereçamento unicast é utilizado para a comunicação entre dois hosts e apenas uma cópia do conteúdo é envio da origem ao seu destino.
Quando o conteúdo transmitido no serviço IPTV é de natureza VOD, utiliza-se o
endereçamento unicast para sua transmissão, pois o stream de vídeo está sendo enviado do servidor para apenas um usuário.

**Broadcast:**

O endereçamento broadcast é utilizado quando um host deseja enviar a mesma
informação simultaneamente para os outros hosts.

**Multicast:**

O endereçamento *multicast* é um caso específico do broadcast onde um host deseja enviar a mesma informação simultaneamente para um subconjunto de hosts conectados à rede. A transmissão dos canais de programação utiliza o endereçamento multicast, dessa forma, um *stream* é enviado simultaneamente para um grupo limitado de usuários que estejam assistindo o conteúdo naquele momento.

O mecanismo de multicast evita que exista tráfego de vídeo redundante na rede,
otimizando a utilização destes recursos e baseia-se no conceito da criação grupos nos quais um usuário precisa se integrar a um determinado grupo para poder receber seu conteúdo. Quando o usuário não deseja mais receber aquele conteúdo ele deixa um grupo
e se autentica a outro, passando a receber outro tipo de conteúdo como, por exemplo, outro canal de programação.

O protocolo IGMP controla desde o anúncio e manutenção dos grupos multicast até o
registro (join/leave) dos receptores aos grupos até a sinalização do mecanismo multicast
entre hosts e a rede.

Quando assinantes selecionam um mesmo canal para exibição, para evitar a duplicação
desnecessária de pacotes na rede, são empregados os conceitos de árvore de distribuição multicast, especificando um caminho único entre a origem e o grupo de usuários que requisitaram esse conteúdo. O objetivo principal das árvores de distribuição é garantir que apenas uma cópia de cada pacote seja encaminhada em cada ramificação da árvore, sendo que as folhas são representadas pelos assinantes e a origem pela fonte de conteúdo.

### 1.11.2 Infraestrutura de conteúdo

**O Servidor Middleware:**

Pode ser considerado como o sistema operacional da solução. Dito de outra forma,o servidor middleware é o componente responsável pela inteligência do serviço, além de interpor-se no âmbito da entrega do serviço fim-a-fim, sendo, por isso, responsável pela interligação das diversas partes do sistema: servidores de vídeo, set top box, head-end, DRM, elementos de rede.

Nesta mesma linha de raciocínio, pode-se dizer que o middleware é o viabilizador da solução de IPTV. Portanto é ele o responsável por: experiência do serviço do usuário; definições de serviços, pacotes e preços; interface com outros blocos da solução; gerenciamento de transações, conteúdo de ativos de mídia, dispositivos e assinantes.

O middleware é, portanto, um conjunto de aplicações que suportam as quatro áreas
mencionadas.

**Funções do middleware**

Dentre as funções sustentadas pelo middleware, podemos destacar duas:

**Funções para o assinante:**

Eletronic Program Guide (EPG), apresentação e interatividade dos serviços (VOD, PVR, etc.); apresentação e interatividade de serviços integrados (vídeo, telefonia, identificador de chamadas, etc.); informação de programação; parental controle e informações da conta do assinante.

**Funções para a operadora:**

Representada por atividades como: Application Programing Interface (API); kit de desenvolvimento de software (SDK); gestão do serviço; gestão de clientes; gestão de transações; gestão de conteúdo e estratégia de distribuição; controle remoto dos dispositivos de usuário – set top box; interface com billing; interface com aprovisionamento/ativação; integração com sistemas de segurança e elaboração de relatórios.

**O Digital Rights Management (DRM):**

A segurança do conteúdo é um requisito fundamental para viabilizar a oferta de IPTV.
Os tradicionais sistemas de acesso condicional ou Conditional Access Systems (CAS), são
projetados essencialmente para os serviços de broadcast/pay-per-view.

Tais sistemas egados focalizam principalmente o conteúdo em trânsito, e não o conteúdo armazenado. Esses sistemas legados criptografam o conteúdo no head-end e depois decriptografam na residência do assinante, utilizando autenticação baseada geralmente em smart cards localizados no set top box (VILLEGAS, 2007).

A segurança no contexto de IPTV abrange também a proteção do conteúdo de vídeo
armazenado ao longo da infraestrutura, seja nos servidores da operadora ou nas
dependências do assinante. A necessidade de soluções mais abrangentes nos levam a
uma nova categoria de soluções denominadas como *Digital Rights Management* (DRM).

O DRM tem como propósito, gerenciar o conteúdo digital. Ele é utilizado baseado em condições específicas definidas pelos direitos de utilização do usuário e visa garantir controle de acesso (autenticação e autorização), contabilização de utilização (gestão dos direitos de uso), controle de replicação (cópia), autenticidade da fonte, confidencialidade, integridade e disponibilidade do conteúdo protegido.
Vale registrar que são os sistemas de DRM que oferecem a infraestrutura de segurança,
necessária, para prevenir a pirataria do conteúdo de vídeo independente de ele estar armazenado ou sendo transmitido.
O funcionamento do DRM é baseado na criptografia do conteúdo no head-end e a sua decriptografia é baseada no set top box utilizando certificados digitais. Nessa perspectiva, o conteúdo fica criptografado onde quer que esteja e só é decriptografado na sua exibição.

O DRM possui, ainda, inúmeros pontos de contato ao longo do sistema e, portanto, necessita de integração fim-a-fim com os diversos componentes da solução para garantir a proteção do conteúdo.

**Os Servidores de Vídeo:**

Os servidores de vídeo são responsáveis por armazenar e disponibilizar conteúdos que são oferecidos sob demanda para os assinantes. Assim, eles armazenam, o conteúdo destinado a VOD e também o conteúdo broadcast selecionado para habilitar funcionalidades de PVR ao usuário final. Essa modalidade de PVR é conhecida como Network PVR (NPVR) em que o conteúdo não está armazenado nas dependências do usuário, mas sim nos sistemas da operadora (WEBER,2006).
Os servidores possuem, portanto, uma alta capacidade de armazenamento, bem como uma alta disponibilidade, permitindo suportar um elevado número de streams de vídeo simultâneos. Nessa conjuntura, quando se necessita de soluções mais complexas e de maior escalabilidade, os servidores possuem inteligência para formar Content Delivery Networks (CDNs), capazes de gerenciar a distribuição de conteúdo entre diversos servidores colocados na rede mais próximos do assinante (por exemplo, nos VHOs e VSOs).
Vale lembrar que, as arquiteturas distribuídas de armazenamento de vídeo mantêm cópias do conteúdo mais acessado mais próximas do usuário final.

**O Set top box:**

Componente da camada de serviço que realiza a interface entre o sistema de IPTV com o usuário e os aparelhos de exibição de conteúdo televisores, telas de plasma, etc.).

Hospedam os componentes do middleware, DRM, browser de navegação, decodificador, possuindo, assim, capacidade de armazenamento de conteúdo local e realizando a função de um PVR.