A versão imprimível não é mais suportada e pode ter erros de renderização. Atualize os favoritos do seu navegador e use a função de impressão padrão do navegador.

Redes Multimidia: Diário de Aula 2015-1

Professor: Marcelo Maia Sobral
Grupo (Facebook): RMU - IFSC
Encontros: 3a feira/7:30, 4a feira/9:40
Atendimento paralelo: 4a feira 13:30-14:30

Ementa

Bibliografia

Livros sobre Redes de Computadores (por ordem de preferência):
- KUROSE, James F. e ROSS, Keith W. Redes de computadores e a Internet, Uma abordagem Top-Down. 5a edição. Editora Addison Wesley SP, 2010.
- Sérgio Colcher, Antônio Tadeu Azevedo Gomes, e Anderson Oliveira da Silva. VoIP: Voz sobre IP. Campus, 1a edição, 2005.
- STALLINGS, W. Redes e sistemas de comunicação de dados. Editora Elsevier RJ, 2005.
- TANENBAUM, Andrew S. Redes de Computadores, tradução da quarta edição. Editora Campus RJ, 2003
- FOROUZAN, Behrouz. Comunicação de Dados e Redes de Computadores, 3a/4a edicão. Editora Bookman, 2004.

Curiosidades

Listas de exercícios

Avaliações

Nome	Projeto 1	Projeto 2	Prova1	Prova2	Faltas até 24/06 (máximo no semestre: 20)
Anderson	D*	A	C	B	18
~~Diogo~~	D*		D*		48
Mariana	D*		D	D*	36
Nathan	D*		D	D	17
Raphael	D*		D	D*	6
Vinicius Hames	D*		D	D*	32
Vinicius Kachniacz	D*		D	D*	32

Obs: D* = não fez a avaliação.

Softwares

04/02: Apresentação

Slides

Apresentação da disciplina: conteúdo, bibliografia e avaliação, laboratório.

Redes multimidia

Uso de redes de dados para transmitir conteúdo de diferentes midias:

Video streaming (ex: Netflix, Youtube)
Internet radio (ex: Icecast)
VoIP e telefonia IP (SIP com Asterisk, Freeswitch ou FreePBX; Skype)
Video e áudio conferência
Telemedicina
Jogos
... outros ? Ver este exemplo interessante ...

Algumas questões sobre essas aplicações:

Como funcionam esses serviços ? Como os conteúdos são acessados ?
Como os dados são representados ?
Como os dados são transportados através da rede ? Quais os protocolos envolvidos e como os dados são encapsulados em suas PDUs ?
Que requisitos quanto à transmissão pela rede possuem para um bom funcionamento ?

Atividade: compartilhando video pela rede

A turma deve conceber uma forma de distribuir video usando a rede, que possibilite a reprodução de video tanto por computadores quanto dispositivos móveis (smartphones e tablets). Esse serviço precisa ter sua arquitetura devidamente descrita, para que fique claro:

como os videos são armazenados
como os videos são acessados e transmitidos
que requisitos os usuário do serviço devem cumprir para utilizá-lo
qual a infraestrutura física necessária

Exemplo 1: video streaming

Video streaming é a transmissão de video por uma rede de dados, com sua visualização ocorrendo à medida que for sendo recebido pelo cliente. Um exemplo muito conhecido de serviço de video streaming é fornecido pelo YouTube. Outros exemplos de video streaming são Netflix, que possibilita assistir filmes via Internet mediante o pagamento de uma assinatura, e a transmissão de jogos de futebol via Internet por algumas emissoras de TV aberta. Apesar de a experiência dos usuários parecer a mesma (ou quase ...) para esses serviços, existem diferenças na forma como são implementados.

Experimente visualizar os videos abaixo. Em todos eles observe quanto tempo demora para iniciar a tocar o video e sua continuidade (se ele interrompe ou degrada a imagem). Experimente também avançar o video, como por exemplo para perto de seu final.

Video 1: usando um tocador Flash.
Video 2: usando HTML5
Video 3: execute vlc http://tele.sj.ifsc.edu.br/~msobral/rmu/videos/Paul-Kuthe.m4v
Video 4: execute vlc http://tele.sj.ifsc.edu.br/~msobral/rmu/videos/wsm-bonus4.avi
Video 5: execute vlc http://tele.sj.ifsc.edu.br/~msobral/rmu/videos/teste.mp4

Como é feito o acesso a esses videos, e como eles são transportados pela rede ?

Execute o wireshark e repita o acesso aos videos. Enquanto a captura acontece, faça um reposicionamento do video - i.e. avance-o para perto de seu final. Observe as mensagens trocadas entre sua aplicação cliente e o servidor do video.
Você conseguiria descrever como funcionam seus acessos e transmissões ?
Você pode notar alguma diferença entre as diferentes formas de transmissão do video ?

Exemplo 2: Internet radio

Atualmente muitas estações de rádio transmitem suas programações também pela Internet. Existem inclusive muitas estações cujas transmissões são feitas somente pela rede - i.e. a rigor, não fazem transmissão por rádio. Com isso, pessoas conseguem escutar a programação de uma estação de rádio de outro país. Um atrativo dessas estações via Internet é informarem o gênero de música transmitida, além de apresentarem uma boa qualidade sonora. Esse tipo de serviço se popularizou tanto que existem diretórios de estações, que podem ser acessados por aplicativos e assim possibilitar que os usuários escolham que tipo de música desejam escutar.

Um aplicativo do Linux que oferece fácil acesso a Internet radio é o Rhytmbox. Ele pode ser executado no menu Aplicativos->Som e video. Execute o Rhytmbox em seu computador, e escolha uma estação de radio. Observe quanto tempo demora para que a música comece a tocar, a qualidade do som, e sua continuidade.

Como é feito o acesso às estações de rádio, e como as músicas são transportadas pela rede ?

Execute o wireshark e repita o acesso à estação. Enquanto a captura acontece, observe os protocolos envolvidos e as mensagens que fluem entre seu computador e o servidor da estação. Observe também onde a estação se localiza (país/cidade).
Você conseguiria descrever como funcionam seus acessos e transmissões ?

TAREFA: leitura da semana

Leiam os seguintes artigos:

... sintetizem suas ideias e comparem-nas com a situação da Internet brasileira. Preparem-se para apresentar suas conclusões na próxima aula (09/02). A apresentação deverá durar de 5 a 10 minutos e deve ser composta de:

Um resumo sobre os conceitos-chaves contidos no texto
Alguns slides (não mais que 5) para auxiliar a explicação desses conceitos chaves.
- Não carregue os slides de texto ! Priorize o uso de figuras, diagramas e frases curtas para enunciar cada ideia apresentada.

Durante a apresentação qualquer aluno ou o professor poderão fazer apartes. Em particular, o professor pode pedir a outro aluno para explicar o que entendeu sobre determinada informação apresentada.

Um aluno será sorteado para fazer sua apresentação. Caso não a tenha preparado, receberá um conceito negativo que influenciará seu conceito final (isso vale também para alunos sorteados que tiverem faltado). O sorteio será realizado até que um aluno faça a apresentação.

10/02: Apresentação do Projeto 1

Uma comparação entre serviços de distribuição de video da Internet

O projeto 1 trata da implantação e demonstração de um sistema de compartilhamento de video semelhante ao Youtube (conhecido como CMS - Content Management System). Tal serviço deve possibilitar:

A visualização de videos via web
- Os videos podem estar armazenados ou serem ao vivo (ex: fornecidos por uma câmera IP)
A publicação de videos por usuários cadastrados
A reprodução de músicas via web (opcional)
A publicação de músicas por usuários cadastrados (opcional)

A implantação do serviço deve ser feita em um servidor do câmpus. Há um servidor disponibilizado para cada equipe. Pode ser usado qualquer software para CMS, ficando ao gosto de cada equipe. Algumas opções são:

phpmotion
- Cópia no servidor de Tele
Plumi: experiências anteriores indicam que este software pode ser muito árduo de por pra funcionar ... tente por sua conta e risco ;-)
Clip-bucket
Cumulus
MediaDrop

Estes outros não são CMS baseados em web, porém demonstram outras formas (e tecnologias) para compartilhamento e streaming:

Cada equipe (até dois alunos) devem usar um servidor dedicado na rede do Ifsc-SJ para desenvolver seu projeto, conforme a tabela a seguir:

Equipe	Alunos	Servidor	URL
Equipe 1	Diogo,Anderson	equipe1.rmu.sj.ifsc.edu.br	http://equipe1.rmu.sj.ifsc.edu.br/
Equipe 2	Nathan, Raphael	equipe2.rmu.sj.ifsc.edu.br	http://equipe2.rmu.sj.ifsc.edu.br/
Equipe 3	Vinicius K. e Vinicius H.	equipe3.rmu.sj.ifsc.edu.br	http://equipe3.rmu.sj.ifsc.edu.br/

Produto a entregar: até 10/03

Cada equipe deve demonstrar o funcionamento do seu servidor de video. Isso inclui fornecer uma conta ao professor para ele publicar videos de teste.
Deve ser entregue um relatório descrevendo:
- Como instalar o serviço de video.
- Os requisitos (outros softwares) para que o serviço seja instalado.
- Os formatos de video suportados (codecs e containers) tanto para importação quanto reprodução
- Uma breve descrição de como funciona a transmissão do video: protocolos usados, tipo de reprodutor de video, funcionalidades suportadas (avançar, retroceder, pausa, seleção de qualidade de video, videos online ou armazenados, ...).

Atividade

Usando a máquina virtual de RMU, investigue os softwares sugeridos e escolha um deles para sua implantação.

11/02: Início do projeto 1; transmissão de video

Existem diversos mecanismos de transmissão de video por uma rede de computadores. Para conhecer alguns deles, pesquise como videos são transmitidos por estes sistemas:

O resultado dessa pesquisa deve ser usado para construir a seguinte tabela:

Mecanismo	Protocolos de aplicação	Protocolos de transporte	Multicast	Qualidade adaptativa	Formatos de video	Reprodutor de video	Software/sistema servidor
Flash video	HTTP	TCP	Não	??	??	Flash player	servidor web
HTML5	HTTP	TCP	Não	??	??	Navegador (Chrome, Firefox, ...)	servidor web
P2P (torrent)	BitTorrent*	TCP/UDP	Não	Não	??	Popocorn Time (Javascript/NodeJS)	Popocorn Time (Javascript/NodeJS)
DASH	HTTP	TCP	Não	Sim	??	Reprodutores específicos (ex: dash.js, VLC)	??
HTLS	HTTP	TCP	Não	Sim	??	??	Quicktime server
RTSP/RTP	RTSP/RTP	TCP/UDP	Sim	Sim	??	VLC e outros	live555mediaServer, DarwinStreaming Server, ...

Formatos de video

Videos digitais podem ser representados em diferentes formatos. Isso é uma combinação da codificação de video (codec) e a forma com que o video é armazenado (container). Basicamente um codec define como a sequência de quadros de um video é representada digitalmente, e o container define como os bits de um video codificado são encapsulados de forma conveniente, seja em um arquivo ou mesmo on-the-fly. Para investigar alguns tipos de container e codecs existentes, analise os seguintes videos:

Video	Container	Codec	Características de codificação
Video 1	m4v	H.264	480x272, 24bpp, 25fps,648.8 kbps
Video 2	mpg	mpeg2	720x480,29.97fps, 4509.7 kbps
Video 3	avi	mjpg	720x480 24bpp 29.970 4509.7 kbps
Video 4	avi	xvid	384x288 12bpp 25.000 fps 587.5 kbps
Video 5	mkv	H.264	320x240,25.000 fps
Video 6	mkv	mpeg2	384x286 0bpp 25.000 fps 104857.2 kbps
Video 7	asf	wmv3	320x240 24bpp 1000.000 fps 372.7 kbps
Video 8	mov(quicktime)	mp4v	640x480 32bpp 10.000 fps 261.8 kbps

Estes textos explicam o que contém cada container, e quais suas estruturas de armazenamento:

Já a codificação de video é muito mais complexa ...

24/02: Compressão de video

Fomos assistir as apresentações de TCC.

25/02: Compressão de video

Técnicas usadas para compressão de video:

Remoção de redundância espacial - codificação intraquadros (ex: MJPEG)
Remoção de redundância espacial e temporal - codificação intraquadros e interquadros (H.264, MPEG)

Remoção de redundância temporal: iniciando com um intraquadro (quadro I), quadros sucessivos contém atualizações relativas a quadros anteriores (quadros P) ou a quadros anteriores e posteriores (quadros B). O conjunto de quadros entre quadros I se chama GOP (Group of Pictures):

Exemplos de codecs de video

MPEG-2
H-264
XVID
Theora

Exemplos de formatos de video usados em MPEG2 (i.e. em DVD):

Atividade

1) Copie esta imagem para seu computador, e recorte uma parte com dimensões 128x128 pixels (use o gimp).

1.1) Qual o tamanho dessa imagem no formato BMP com 24 bpp ?

1.2) Qual o tamanho dessa imagem no formato PNG ? E no formato JPG ?

1.3) Crie uma nova imagem com dimensões 128x128 pixels e que seja toda preta, e determina seu tamanho nos formatos BMP com 24 bpp, PNG e JPG.

1.4) O que se pode concluir quanto à representação digital das imagens ?

2) Copie este arquivo compactado para seu computador, e em seguida descompacte-o. Note que ele contém um certo número de arquivos de imagem em formato JPG (experimente visualizar alguns deles).

2.1) Crie um video a partir dessas imagens. Esse video estará no formato MPJG (Motion JPG), que nada mais é que as imagens sequencializadas.

cd figs
mencoder mf://\*.jpg -fps 10 -ovc copy -o video.avi

2.2) Veja o tamanho do arquivo de video, e compare-o com o tamanho total das imagens. Em seguida, reproduza-o com vlc ou mplayer.

2.3) Recodifique o seu arquivo de video usando o codec XVID:

mencoder -o video2.avi -ovc xvid -xvidencopts bitrate=1024 -oac copy video.avi

... e observe o tamanho do arquivo de video resultante. Em seguida reproduza-o com vlc ou mplayer. Como você o compara com o video gerado no item 2.2 ?

3) Copie este video para seu computador. Visualize-o com mplayer ou vlc, observando sua qualidade de imagem. Veja também o tamanho desse arquivo de video, que está codificado com MJPG.

3.1) Codifique-o para outros formatos de compressão:

MPEG-2: mencoder -o turning-mpg2.mpg -of mpeg -ovc lavc -lavcopts vcodec=mpeg2video:vbitrate=250 -nosound tunrning_pages.avi
XVID: mencoder -o turning-xvid.avi -ovc xvid -xvidencopts bitrate=250 -nosound tunrning_pages.avi
H-264:
mencoder -o turning1.mp4 -ovc x264 -x264encopts pass=1:turbo -nosound tunrning_pages.avi
mencoder -o turning-h264.mp4 -ovc x264 -x264encopts bitrate=250:pass=2 -nosound tunrning_pages.avi

4) Codifique este video para outros formatos de compressão:

MPEG-2: mencoder -o wsm-bonus4_mpg2.mpg -of mpeg -ovc lavc -lavcopts vcodec=mpeg2video:vbitrate=250 -oac copy wsm-bonus4.avi
XVID: mencoder -o wsm-bonus4_xvid.avi -ovc xvid -xvidencopts bitrate=250 -oac copy wsm-bonus4.avi
H-264:
mencoder -o wsm-bonus4.mp4 -ovc x264 -x264encopts pass=1:turbo -oac mp3lame wsm-bonus4.avi
mencoder -o wsm-bonus4_h264.mp4 -ovc x264 -x264encopts bitrate=250:pass=2 -oac mp3lame wsm-bonus4.avi

5) Compare os tamanhos dos arquivos de video resultantes das codificações. Toque-os e veja se há diferença de qualidade de imagem entre eles.

6) Um software de processamento de video disponível para Linux se chama gopchop. Abaixo segue um texto explicativo sobre esse programa:

Interprete as informações contidas no texto acima, e experimente usar o gopchop.

03/03: Caracterização de midias

Slides

Compressão de audio

Técnicas usadas:

Remoção de silêncio
Uso de psicoacústica
Remoção de redundância

Exemplo de codificação:

Atividade

1) Copie este arquivo de audio para seu computador. Escute-o e confira sua qualidade sonora. Veja também o tamanho do arquivo.

2) Codifique esse arquivo com os seguintes codecs:

PCM: time mplayer -vc dummy -vo null -af format=s8,resample=8000:0:0,channels=1,volume=0 -ao pcm:waveheader:file="musica2.wav" musica.wav
MP3: time lame musica.wav musica.mp3
Ogg: time oggenc -o musica.ogg musica.wav
Flac: time flac musica.wav -o musica.flac
Speex: time speexenc --bitrate 8 musica.wav musica.spx

3) Toque os arquivos de audio codificados, comparando suas qualidades sonoras. Compare também os tamanhos dos arquivos.

Transmissão de dados multimidia

Slides

A transmissão de dados multimidia está sujeita a alguns fatores, destacando-se:

Banda disponível: cada tipo de transmissão demanda uma certa banda mínima (ver o exemplo dos videos gerados na aula anterior, que demandam em torno de 250 kbps). A banda requerida depende do codec, podendo mesmo ser variável (ver figura abaixo). Se a banda disponível na rede não for suficiente, a reprodução dos dados transmitidos não será possível (quer dizer, a reprodução contínua simultânea ao recebimento dos dados).
Atrasos fim-a-fim: alguns tipos de transmissão são mais sensíveis a atrasos fim-a-fim, como por exemplo conversações VoIP, porém todas transmissões de dados multimidia apresentam pouca tolerância a variações de atraso. A variação de atraso excessiva causa a perda de sincronismo entre a transmissão e a recepção, impedindo a reprodução contínua dos dados recebidos.

Componentes do atraso fim-a-fim

O atraso fim-a-fim, contado portanto desde a origem de um pacote até seu destino, se compõe de um conjunto de tempos despendidos ao longo de sua transmissão. Alguns desses tempos são constantes, porém outros são variáveis.

Atraso	Descrição	Tipo	Expressão (F: tamanho de um pacote em bytes, B: taxa de bits do link)
Transmissão	Tempo entre o início da saída do 1o bit até a saída do último bit de um pacote pela interface de rede. Depende basicamente da taxa de bits do link onde se dá a transmissão.	Variável (depende do tamanho do pacote)	$A_{t}={\frac {F}{B}}$
Propagação	Tempo entre a saída do 1o bit de um pacote da interface de rede do equipamento transmissor, e sua chegada na interface de rede do equipamento receptor. Depende basicamente da latência do meio de transmissão.	Constante	$A_{p}$
Processamento	Tempo entre a recepção de um pacote e a ação a ser feita sobre ele dentro de um equipamento de rede (seja encaminhá-lo por outro link, ou entregá-lo a uma aplicação que o consumirá)	Usualmente desprezível	$A_{x}$
Enfileiramento	Tempo de espera de um pacote na fila de saída de uma interface de rede por onde deve ser transmitido. Depende de quantos pacotes (e quantos bytes) estão na sua frente nessa fila.	Variável	$A_{q}=\sum _{F\in Fila}{\frac {F}{B}}$

No exemplo abaixo, os links LAN (link1, link2, link7 e link8) possuem taxa de 1 Gbps, e os links WAN (demais links) possuem taxa de 10 Mbps. As filas dos roteadores podem conter até 100 pacotes de 1500 bytes (tamanho máximo de pacote). Os links WAN possuem latência de 2 ms (a dos links LAN é desprezível). Sendo assim, calcular o atraso mínimo e máximo que cada pacote pode sofrer entre sua saída do servidor de video e sua chegada no reprodutor. Os pacotes de vídeo têm tamanho de 1500 bytes:

Atrasos de transmissão nos links WAN:	$A_{wan}={\frac {1500\cdot 8}{10\cdot 10^{6}}}=1,2\cdot 10^{-3}s$
Atrasos de transmissão nos links LAN:	$A_{lan}={\frac {1500\cdot 8}{1\cdot 10^{9}}}=12\cdot 10^{-6}s$
Atraso de enfileiramento em roteador: melhor caso (fila vazia)	$A_{q}=0~s$
Atraso de enfileiramento em roteador: pior caso (fila cheia):	$A_{q}=100\cdot {\frac {1500\cdot 8}{10\cdot 10^{6}}}=120\cdot 10^{-3}s$

O menor atraso pode ser calculado assim:

$A_{min}=4\cdot A_{lan}+4\cdot A_{wan}+4\cdot A_{p}=12,848\cdot 10^{-3}s$

... e o maior atraso possível é:

$A_{max}=4\cdot A_{lan}+4\cdot A_{wan}+4\cdot A_{p}+4\cdot A_{q}=492,848\cdot 10^{-3}s$

Com isso, uma transmissão de video nessa rede está sujeita a atrasos máximo de cerca de 492 ms por pacote, e variação de atraso de até $A_{max}-A_{min}=480ms$ . Note-se que, nessa rede, a variação de atraso se deve essencialmente a atrasos de enfileiramento nos roteadores. Em outras redes pode haver fatores adicionais para variações de atraso: perdas de pacotes por erros de transmissão ou congestionamento, priorização de pacotes, e até o controle de congestionamento TCP (se esse protocolo for usado para a transmissão).

O exemplo acima diz respeito a uma pequena rede com bons links WAN e pequeno número de saltos (roteadores intermediários) entre origem e destino. Em um cenário mais realista, como um usuário doméstico acessando videos no Youtube, a situação pode ser bem pior. Para fins de comparação, da rede da escola até o Youtube foram contados 9 saltos, e de casa se contaram 8 saltos (o caso do Youtube é um pouco mais complicado, pois sua infraestrutura é baseada em um tipo de CDN).

Se cada pacote está sujeito a um atraso variável, o reprodutor de video no receptor precisa de algum mecanismo para compensar essas variações e apresentar o video de forma contínua. O mesmo raciocínio vale para transmissões de audio.

04/03: Estratégias para tratar a variação de atraso

Mecanismos para compensar atraso e variação de atraso da rede:

Numerar cada mensagem com um número de sequência.
Registrar o instante em que cada mensagem foi gerada (i.e. registrar seu timestamp).
Atrasar a reprodução do conteúdo no receptor, para compensar variações de atraso.

Atrasos devido a transmissão

Esses mecanismos são combinados nas seguintes estratégias para compensar variação de atraso:

Atraso de reprodução fixo

Compensa atrasos de mensagens com a imposição de um atraso fixo q no reprodutor de midia. Mensagens recebidas após seu instante de reprodução (i.e. chegam após timestamp + q) são descartados.

Atraso de reprodução: midia será tocada somente no instante $p^{'}$ , sendo que $p^{'}=r+q$ . O atraso q corresponde ao atraso de reprodução imposto do lado do cliente, para compensar variações de atraso das mensagens.

Por exemplo, uma sequência de mensagens pode ser reproduzida da seguinte forma se for imposto um atraso fixo:

Atraso de reprodução adaptativo

Procura minimizar o atraso de reprodução, estimando o atraso da rede e sua variação. O atraso de reprodução assim calculado é imposto no receptor antes de cada rajada de mensagens (isso faz mais sentido em transmissão de voz).

Por exemplo, uma sequência de mensagens pode ser reproduzida da seguinte forma se for imposto um atraso adaptativo:

Se uma determinada mensagem se atrasar além do tolerável, será descartada (não reproduzida):

Exercícios

Resolva estes dois problemas:
- Problema 1
- Problema 2
Resolver os exercícios contidos no final das transparências.

Atividade: atraso de reprodução

Podemos experimentar o efeito do buffer de reprodução modificando seu tamanho em um reprodutor de video:

Visualize um video usando o mplayer:

mplayer -cache 200 -framedrop http://tele.sj.ifsc.edu.br/~msobral/rmu/videos/video.avi

Experimente variar o tamanho do buffer por meio da opção -cache. Experimento inclusive remover o buffer (use a opção -nocache).

Quais devem ser o atraso e variação de atraso do streaming de video que fizemos na aula de 04/02 ? Poderíamos estimar essas características de transmissão para o video que estava em um servidor dentro do IF-SC São José, e para aquele outro que estava em um computador fora do câmpus.

Qual deveria ser o atraso de reprodução mínimo, em cada caso, para que o video pudesse ser reproduzido sem perdas ?
Qual seria o valor desse atraso mínimo, se fosse calculado segundo o procedimento para determinar o atraso de reprodução adaptativo ?

Obs: a medição dos atrasos de pacotes pode ser feita com wireshark ou tcpdump. Este pequeno programa auxilia esta tarefa.

Estratégias para abrandar a perda de mensagens

Reprodução de mensagens perdidas inadequada para aplicações interativas

Mensagens que realmente não chegaram
Mensagens que chegaram após instante de reprodução

Técnicas para abrandar a perda de mensagens e preservar uma boa (?!) qualidade de áudio

Correção antecipada de erros (FEC - Forward Error Correction)
Intercalação

Correção antecipada de erros

Emissor envia dados redundantes em suas mensagens, também conhecidos como um código de correção de erro.

Exemplo 1: envio de uma mensagem redundante para cada grupo de n mensagens. A mensagem redundante é calculada fazendo XOR das demais mensagens do grupo.

Tolera a perda de 1 mensagem
Aumento de banda de 1/n

Uso de mensagem redundante com XOR

Exemplo 2: envio de fluxos redundantes de diferentes qualidades.

Pode-se enviar um fluxo de qualidade inferior junto com o fluxo principal.

Intercalação

Consiste no resequenciamento das unidades de áudio antes de transmiti-las, de forma que unidades que estavam originalmente próximas sejam separadas por uma certa distância no fluxo a ser transmitido.

No exemplo abaixo, cada unidade de áudio tem 5 ms, e cada mensagem contém quatro unidades (totalizando 20 ms).

Atividade

Pesquise sobre o uso de técnicas de abrandamento de perdas de mensagens em diferentes tipos de transmissão de midia: VoIP, video, radio on-line, ...

TAREFA: pesquisa sobre modelos e mecanismos de distribuição de midia

Faça uma breve pesquisa sobre sistemas de distribuição de conteúdo multimidia na Internet (ex: CDN, P2P, ...), apresentando suas características e exemplos de sistemas que os implementem. Em seguida, pesquise também sobre ao menos dois mecanismos de distribuição de midia, que pode estar armazenada ou ser ao vivo. Explique como os dados são codificados, que protocolos são usados e que mensagens são trocadas para que o acesso a midia se realize. Inclua diagramas para ajudar a explicar seu funcionamento, e forneça exemplos de sua aplicação.

Algumas sugestões de mecanismos:

HTTP Live streaming
HTTP Pseudo-streaming
HTTP Dynamic-streaming
RTSP streaming
P2P streaming
... outros ?

Prazo de entrega da pesquisa por email: 09/03.
Na aula de 10/03 os resultados das pesquisas serão discutidos em aula.

Lista de exercícios

Os exercícios do capítulo 7 do livro "Redes de Computadores e a Internet, 5a edição", do Kurose, devem ser resolvidos:

Exercicios de fixação: 1, 2, 4, 5, 6, 7, 9, 10, 11, 12
Problemas: 1, 3, 4, 5, 7, 8, 9, 10, 12, 13, 14, 16, 17, 18, 19

10/03: Projeto 1: conclusão

Aula utilizada para que as equipes trabalhassem no projeto 1.

11/03: Projeto 2: um serviço de videophone usando a rede de computadores

Um serviço de videophone possibilita realizar chamadas com audio e video sincronizados. Tal serviço pode ser implantado para utilizar uma rede computadores (ver figura abaixo), se apresentando como uma aplicação para redes multimidia. Existem vários aparelhos telefônicos e softphones capazes de realizar chamadas desse tipo. A infraestrutura necessária para implantar tal serviço também já existe, bastando integrar alguns componentes da rede. No entanto, tal integração ainda demanda um certo esforço e conhecimento.

O projeto 2 propõe a implantação de um serviço de videophone, o qual deve atender estes requisitos:

Possibilitar a realização de chamadas com video e audio sincronizados.
Possibilitar a realização de múltiplas chamadas simultâneas.
Realizar chamadas independente da localização dos usuários (ex: dentro ou fora do IFSC, em casa com link ADSL, usuário móvel com link 3G ou 4G, ...)
Realizar alguma forma de autenticação forte dos usuários do serviço.
Encriptar as comunicações realizadas (sinalização, audio e video).
Atender necessidades de qualidade de serviço das chamadas.

O desenvolvimento deste projeto envolve o conhecimento de muitas tecnologias, técnicas e softwares.

A realização do projeto deve ser em equipes de até três alunos.

Tarefa 1: definição da arquitetura do sistema

No início de um projeto, devem-se esclarecer seus objetivos, seus requisitos funcionais e não-funcionais, e suas restrições. Essa especificação não precisa ser completa, pois nem sempre há um total domínio dos conhecimentos e necessidades envolvidos no projeto. Alguns requisitos mais gerais foram apresentados na introdução, os quais podem ser refinados. De forma geral, os requisitos e restrições podem ser entendidos desta forma:

Funcionais: o que o sistema deve ser capaz de fazer ?
Não-funcionais: o que o sistema deve ser ? Que propriedades ele deve possuir ?
Restrições: sob quais condições o sistema deve funcionar ? o que obrigatoriamente deve ser usado, ou não pode ser utilizado ?

Havendo uma visão razoavelmente clara sobre essas questões, pode-se conceber uma arquitetura do sistema. Essa arquitetura apresenta o sistema compostos por um certo número de blocos funcionais, os quais se relacionam de alguma maneira. A arquitetura do sistema é assim apresentada como um diagrama de blocos.

Sendo assim, faça o seguinte:

Refine os requisitos e restrições do sistema
Esboce uma arquitetura do sistema, identificando seus blocos funcionais

Introdução a Voz sobre IP (VoIP)

VoIP: transmissão de voz usando protocolos da arquitetura TCP/IP, com o objetivo de estabelecer chamadas semelhantes a chamadas telefônicas. Alguns exemplos de tecnologias VoIP são:

Skype (mais material aqui)
Viber
SIP (padrão)
H.323 (padrão)

Uma chamada VoIP entre dois telefones IP é feita através da rede de dados.

A realização de chamadas VoIP implica a necessidade de alguns mecanismos:

Sinalização: deve haver alguma forma de um usuário iniciar uma chamada para outro usuário, de forma parecida com uma chamada telefônica convencional. A sinalização é responsável por possibilitar que um usuário convide outro para o estabelecimento de uma chamada, e para notificar sobre sua aceitação ou não. Além disso, a sinalização deve participar da definição sobre as características da chamada, tais como o codec de áudio.
Transmissão de midia: a voz precisa ser digitalizada com algum codec então transmitida entre os participantes da chamada. O transporte da voz digitalizada implica o uso protocolos capazes de encapsulá-la e de atender ou dar subsídios ao atendimento de seus requisitos de qualidade de serviço (atrasos fim-a-fim e variação de atraso, taxa de perdas).

Em RMU será estudado o modelo SIP para VoIP, o qual se compõe de um conjunto de padrões abertos para tratar dos vários aspectos envolvidos na realização de chamadas. Esse modelo, como diz seu nome, tem como principal elemento o protocolo de sinalização SIP (Session Initiation Protocol).

O protocolo SIP

O protocolo SIP segue um modelo P2P (peer-to-peer), em que dois ou mais participantes, chamados de agentes, trocam mensagens com a finalidade de estabelecerem algum tipo de sessão (de voz no nosso caso, mas pode ser de video, mensagem instantânea, ou algum outro tipo de serviço). Assim, cada agente em uma sessão SIP se comporta tanto como cliente (quando envia requisições SIP) quanto servidor (quando responde a requisições SIP). A parte que inicia requisições se chama UAC (User Agent Client), e a que responde requisições é denominada UAS (User Agent Server), estando ambas implementadas nos telefones IP e similares.

Uma sessão SIP envolve a interação entre duas entidades lógicas, que no caso de chamadas VoIP são por vezes chamadas simplesmente de usuários. A diferença entre entidade lógica e agente é que a primeira é o usuário (recurso) que inicia ou recebe chamadas, e o segundo é a aplicação que contém os mecanismos para efetuar e receber chamadas - pense que a entidade seria uma pessoa, e o agente o aparelho telefônico em uma chamada telefônica convencional. Cada entidade é identificada por uma URI (Uniform Resource Indicator) SIP, semelhante a um número de telefone. Além de identificar uma entidade lógica, a informação em uma URI SIP indica a forma com que essa entidade deve ser contatada via SIP. Exemplos de URI SIP seguem abaixo:

# Uma URI simples, tipicamente usada em mensagens INVITE (que iniciam sessões SIP)
sip:1234@biloxi.example.com

# Uma URI mais elaborada, tipicamente usada em alguns cabeçalhos SIP (ex: Contact ou Refer-to)
sip:joseph.fourier@transform.org:5060;transport=udp;user=ip;method=INVITE;ttl=1;
maddr=240.101.102.103?Subject=FFT

As comunicações SIP seguem uma hierarquia, cujos níveis são:

Mensagens: mensagens de texto individuais trocadas entre agentes.
Transação: sequência de mensagens entre dois agentes iniciando com uma requisição e terminando com uma resposta final.
Diálogo: uma relação entre dois agentes que persiste por algum tempo, e identificada por um Call-ID.
Chamada: composta por todos os diálogos originados por um agente.

'Mensagens, transações, diálogos e chamadas

Mensagens SIP

O protocolo SIP tem uma estrutura simplificada com mensagens de pedido e resposta, assemelhando-se ao protocolo HTTP. Essas mensagens possuem a seguinte estrutura:

Linha inicial
Cabeçalho1: valor do cabeçalho 1
Cabeçalho2: valor do cabeçalho 2
...
CabeçalhoN: valor do cabeçalho N
<linha em branco>
corpo da mensagem (opcional)

A diferença básica entre pedidos e respostas SIP está na linha inicial: pedidos contém um método SIP e seus parâmetros, e respostas possuem um código de status junto com um curto texto informativo. Abaixo são mostradas duas mensagens SIP: um pedido e sua respectiva resposta. Nesse exemplo, ambas mensagens não possuem um corpo de mensagem (lembre que isso é opcional):

Pedido:

REGISTER sips:ss2.biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>
Content-Length: 0

Resposta:

SIP/2.0 200 OK
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92
 ;received=192.0.2.201
From: Bob <sips:bob@biloxi.example.com>;tag=ja743ks76zlflH
To: Bob <sips:bob@biloxi.example.com>;tag=37GkEhwl6
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 2 REGISTER
Contact: <sips:bob@client.biloxi.example.com>;expires=3600
Content-Length: 0

O pedido exemplificado foi uma mensagem do tipo REGISTER, que é um tipo de método SIP. Um método pode ser entendido como um comando enviado de um participante a outro. A resposta contém o status 200 OK, que significa que o pedido foi atendido com sucesso. Por fim, ambas mensagens contiveram um conjunto de cabeçalhos necessários para caracterizá-las, dentre eles Via, From, To, Call-Id, CSeq, Contact e Content-Length. As tabelas a seguir descrevem resumidamente os principais métodos e cabeçalhos SIP.

Método SIP	Descrição
REGISTER	Usado por um agente para notificar a rede SIP (outros agentes) sobre sua URI de contato
INVITE	Usado para estabelecer sessões entre dois agentes
ACK	Confirma respostas finais a requisições INVITE
BYE	Termina uma sessão previamente estabelecida
CANCEL	Encerra tentativas de chamadas
OPTIONS	Consulta um agente sobre suas capacidades

Tabela de métodos SIP (não exaustiva ... apenas os principais métodos)

Cabeçalho SIP	Descrição	Obrigatoriedade	Uso
Via	Registra a rota seguida por uma requisição, sendo usado para que respostas sigam o caminho inverso	Requisição e resposta	Requisição e resposta
To	Identifica o destinatário de uma requisição	Requisição e resposta	Requisição e resposta
From	Identifica o originador da requisição	Requisição e resposta	Requisição e resposta
Call-Id	Identifica univocamente uma chamada entre um UAC e um UAS.	Requisição e resposta	Requisição e resposta
CSeq	Numera as requisições de uma mesma chamada de um mesmo UAC	Requisição	Requisição e resposta
Contact	Identifica o originador da requisição ou o recurso requisitado		Requisição e resposta
Max-Forwards	Máximo número de saltos que a requisição pode atravessar	Requisição	Requisição
Content-Length	Informa a quantidade de bytes do corpo da mensagem		Requisição e resposta
Date	Informa a data e horário de uma requisição ou resposta		Requisição e resposta
Supported	Lista uma ou mais opções suportadas por um UAC ou UAS		Requisição e resposta
User-Agent	Informa sobre o agente (o programa) originador de uma requisição
Allow	Informa os métodos SIP aceitos pelo UAS		Resposta
Content-type	Informa o tipo de conteúdo contido no corpo da mensagem
WWW-Authenticate	Informa que o UAC deve se autenticar para o UAS (e como isso deve ser feito)		Resposta
Authorization	Contém as credenciais para autenticar o UAC para o UAS		Requisição

Tabela de cabeçalhos SIP (não exaustiva ... apenas os principais cabeçalhos)

Diagramas de chamadas

Alguns tipos de chamadas VoIP com SIP são recorrentes, estando representadas nas subseções a seguir.

Registro de agente SIP em um proxy SIP

Esta chamada ocorre entre um agente SIP e um servidor de registro SIP (SIP Registar), que está implementado tipicamente em um proxy SIP, um gateway de media, ou um PBX IP (este último incorpora as funções dos dois primeiros com as de um PBX). O registro do agente SIP tem por finalidade fazer com que o servidor de registro SIP conheça a localização do agente (endereço IP e port usado pelo UAS).

Exemplo de sinalização

Fone 1                      Proxy SIP ou PBX IP
     |                             |
     |          REGISTER           |
     |---------------------------->|
     |      401 Unauthorized       |
     |<----------------------------|
     |          REGISTER           |
     |---------------------------->|
     |            200 OK           |
     |<----------------------------|
     |                             |

Chamada direta entre dois agentes SIP

Uma chamada direta entre dois agentes envolve uma transação INVITE, em que um agente convida o outro a estabelecer uma sessão SIP com um determinado tipo de media (ex: audio). A chamada é finalizada quando um dos agentes inicia uma transação BYE.

Exemplo de sinalização

 Fone 1                    Fone 2
     |                        |
     |       INVITE           |
     |----------------------->|
     |    180 Ringing         |
     |<-----------------------|
     |                        |
     |       200 OK           |
     |<-----------------------|
     |         ACK            |
     |----------------------->|
     |      RTP Media         |
     |<======================>|
     |                        |
     |         BYE            |
     |<-----------------------|
     |       200 OK           |
     |----------------------->|
     |                        |

Chamada entre dois agentes SIP com intermediação de um Proxy SIP

A principal diferença entre este tipo de chamada e o anterior é o uso de um (ou mais) proxy SIP entre os dois agentes. O proxy SIP tem por finalidade ajudar na realização das chamadas, uma vez que usualmente incorpora a função de servidor de registro. Um proxy SIP encaminha chamadas para o agente chamado, ou para outro proxy mais próximo do destino, podendo aplicar regras de controle de acesso quanto a quem pode realizar chamadas para quem.

Exemplo de sinalização

Fone 1      Proxy SIP ou PBX IP     Fone 2  
             (directmedia=yes)          
     |                |                |                
     |   INVITE       |                |                
     |--------------->|   INVITE       |                
     |  100 Trying    |--------------->|    
     |<---------------|   100 Trying   |
     |                |<---------------|                
     |                |                |     
     |                |  180 Ringing   |
     |  180 Ringing   |<---------------|                
     |<---------------|                |    
     |                |    200 Ok      |
     |     200 Ok     |<---------------|                
     |<---------------|                |                
     |     ACK        |                |                
     |--------------->|    ACK         |                
     |                |--------------->|    
     |                |                |
     |         RTP Media               |
     |<===============================>|
     |                |                |
     |                |    BYE         |
     |     BYE        |<---------------|                
     |<---------------|                |                
     |     200 Ok     |                |                
     |--------------->|     200 Ok     |                
     |                |--------------->|    
     |                |                |
     |                |                |

Chamada entre dois agentes SIP com intermediação de um gateway de media

Este caso é parecido com o anterior, que usa um proxy SIP. A diferença está na intermediação do fluxo de media, que é feita pelo gateway de media. Isso possibilita que dois agentes estabeleçam uma chamada mesmo usando codecs diferentes, pois o gateway de media fará a tradução entre codecs.

Exemplo de sinalização

Fone 1            PBX IP              Fone 2
              (directmedia=no)        
     |                |                |
     |   INVITE       |                |
     |--------------->|   INVITE       |
     |  100 Trying    |--------------->| 
     |<---------------|  100 Trying    |
     |                |<---------------| 
     |                |   180 Ringing  |
     |   180 Ringing  |<---------------|                
     |<---------------|                |      
     |                |    200 Ok      |
     |     200 Ok     |<---------------|
     |<---------------|                |
     |     ACK        |                |
     |--------------->|    ACK         |
     |                |--------------->|
     |    RTP Media   |   RTP Media    |
     |<==============>|<==============>|
     |     BYE        |                |
     |--------------->|    BYE         |
     |                |--------------->|
     |                |    200 Ok      |
     |     200 Ok     |<---------------|
     |<---------------|                |
     |                |                |

Chamada entre dois agentes SIP com intermediação de um gateway de media e uso de re-INVITE

O uso de re-invite possibilita que o fluxo de media seja estabelecido diretamente entre os agentes SIP, caso usem o mesmo codec. Assim, evita-se a carga de processamento envolvida na intermediação pelo gateway de media. Isso é feito com o envio pelo gateway de media (representado abaixo por um PBX IP) de um novo INVITE para cada agente SIP, após a sessão SIP estar estabelecida. Esse novo INVITE contém uma descrição de media (mensagem SDP embutida no corpo da mensagem INVITE) com a localização do outro agente SIP - isso é, seu endereço IP, port UDP para a stream RTP e codec a ser usado.

Exemplo de sinalização

Fone 1            PBX IP              Fone 2
              (directmedia=yes)        
     |                |                |
     |   INVITE       |                |
     |--------------->|   INVITE       |
     |  100 Trying    |--------------->| 
     |<---------------|  100 Trying    |
     |                |<---------------| 
     |                |  180 Ringing   |
     |  180 Ringing   |<---------------|                
     |<---------------|                |      
     |                |    200 Ok      |
     |     200 Ok     |<---------------|
     |<---------------|                |
     |     ACK        |                |
     |--------------->|    ACK         |
     |    INVITE      |--------------->|
     |<---------------|   INVITE       |
     |    200 OK      |--------------->|
     |--------------->|    200 OK      |
     |    ACK         |<---------------|
     |--------------->|    ACK         |
     |                |<---------------| 
     |                                 |
     |              RTP Media          |
     |<===============================>|
     |     BYE        |                |
     |--------------->|    BYE         |
     |                |--------------->|
     |                |    200 Ok      |
     |     200 Ok     |<---------------|
     |<---------------|                |
     |                |                |

Atividade 1: Ligação SIP ponto a ponto

O primeiro experimento com uma chamada VoIP envolve estabelecer uma chamada diretamente entre dois softphones. Cada par de alunos deve fazer o seguinte:

Executar o Jitsi (ver em Aplicativos->Internet).
Definir uma conta SIP contendo somente um identificador de usuário (sem a localização).
Um dos alunos deve iniciar uma chamada para o outro aluno, que deve atendê-la.
Experimente falar ao microfone e escutar o som no fone de ouvido.
Encerre a chamada.

A sequência de passos acima estabelece uma chamada VoIP do tipo mais simples possível. Para ver os detalhes da comunicação entre os softphones faça o seguinte:

Execute o wireshark e inicie a captura de datagramas UDP pela interface eth0.
Repita a chamada.
Após encerrar a chamada, analise mensagens SIP no wireshark (menu Telephony -> Voip Calls -> Graph)
Disseque a sinalização SIP entre os softphones.
Identifique como foi transportada a voz digitalizada.

Questões:

Quem foram o UAC e UAS nesse experimento ?
Quantas requisições SIP foram realizadas para uma chamada completa ?
Quantas mensagens, transações, diálogos e chamadas foram realizadas ?
Como a voz digitalizada foi transportada ? Foi usado algum protocolo em especial ?
Qual o CODEC selecionado por cada parte? Onde isso foi feito ?
Qual a lista de CODECS suportados?

17/03 e 18/03: Projeto 2: o PBX

IMPORTANTE: leiam os seguintes textos para complementar a base conceitual necessária ao projeto 2. Sempre que necessário vocês podem usá-los para esclarecer dúvidas.
- Introdução a SIP (capítulos 1 e 2 de: SIP: Understanding the Session Initiation Protocol, 3rd ed.)
- SIP Video (obtido de: SIP: Understanding the Session Initiation Protocol, 3rd ed.)
- Redes Multimidia (capítulo 7 de: Computer Networking: A Top-Down Approach, 6th ed.)
- Segurança em Redes (capítulo 8 de: Computer Networking: A Top-Down Approach, 6th ed.)
- Introdução a VoIP e SIP
- RFC 3261: Session Initiation Protocol (SIP)

O projeto 2 demanda como componente central um PBX IP capaz de encaminhar chamadas de voz e video. Sendo assim, a primeira tarefa de hoje é identificar as opções existentes para ser o nosso PBX IP. Para isso, devem estar clarosos requisitos a serem atendidos por esse PBX:

Ser capaz de intermediar chamadas sinalizadas com protocolo SIP
Aceitar sinalização de voz e video
Ser capaz de manter múltiplas chamadas simultâneas
Ser capaz de intermediar chamadas com segurança (tanto sinalização quanto midia)

PBX/Servidor SIP	SIP	Voz	Video	Segurança na sinalização	Segurança na midia	Chamadas simultâneas	Plataforma (SO)	Gratuito
Asterisk	X	X	X	X	X	X	Mac OS X, Linux, BSD, Solaris, Windows?	X
Freeswitch	X	X	X	X	X	X	Windows, Mac OS X, Linux, BSD, Solaris	X
OpenSIPS/Kamailio	X	X	X	X	X	X	Linux/Unix	X

Equipe	Alunos	PBX	Servidor	URL
Equipe 1	Diogo,Anderson	Asterisk	equipe1.rmu.sj.ifsc.edu.br	http://equipe1.rmu.sj.ifsc.edu.br/
Equipe 2	Nathan, Raphael	Asterisk	equipe2.rmu.sj.ifsc.edu.br	http://equipe2.rmu.sj.ifsc.edu.br/
Equipe 3	Vinicius K. e Vinicius H.	Asterisk	equipe3.rmu.sj.ifsc.edu.br	http://equipe3.rmu.sj.ifsc.edu.br/

Asterisk

Transparências
Site oficial do Asterisk
Asterisk Guru
Dicas sobre Asterisk
Livro online gratuito sobre Asterisk
Introdução a VoIP e SIP
Livro Asterisk: Guia de Configuração - 5a geração, de Flávio Gonçalves.

Asterisk: uma solução completa de PABX baseado em software, permitindo ligar o mundo IP ao mundo da rede pública de telefonia comutada.

Características Básicas: faz tudo que um PABX pequeno e simples faz e pouco mais

Transferência, música de espera, siga-me, etc.
Conferência, correio de voz, URA, fila de chamadas, monitoramento de chamadas, integração com o Jabber (Google talk)

Características Avançadas: o que seria interessante para grandes empresas

Uso de banco de dados (MySQL), integração com o LDAP, DUNDi, DNS SRV, geração de bilhetagem

Exemplo de cenário de uso do Asterisk

Arquitetura modular do Asterisk

Plano de discagem

O plano de discagem define como cada chamada deve ser processada. As instruções de processamento residem no arquivo de configuração extensions.conf. O fluxo de processamento de chamadas pode ser visto resumidamente abaixo:

Um exemplo de plano de discagem simples pode ser visto abaixo:

[alunos]; o nome deste contexto

# Chamadas para o número 101 são feitas via SIP para o canal "maria"
exten=>101,1,Dial(SIP/maria)
same=>n,Hangup()

# Chamadas para "teste" serão atendidas com um som de beep, seguido 
# da reprodução do arquivo de som "hello-world", em seguida outro beep e
# enfim se encerra a chamada.
exten=>teste,1,Playback(beep)
same=>n,Wait(1)
same=>n,Playback(hello-world)
same=>n,Wait(1)
same=>n,Playback(beep)
same=>n,Hangup

A estrutura do plano de discagem é composta por extensões (um termo específico do Asterisk). Cada extensão identifica um número (ou usuário) que pode ser chamado, e como essa chamada deve ser processada. A sintaxe pode ser vista abaixo:

exten=>identificador,prioridade,aplicação

identificador: o número ou usuário chamado
prioridade: a prioridade da extensão. Isso determina a ordem de execução das extensões que tratam do mesmo identificador.
aplicação: uma ação a ser realizada quando a extensão for processada. Por exemplo, a aplicação Dial determina que deve ser encaminhada a outro canal.

Como o processamento de uma chamada usualmente envolve uma sequência de extensões, existe uma sintaxe opcional para simplificar a declaração:

exten=>identificador,prioridade,aplicação
same=>prioridade,aplicação

same: declara uma nova extensão com mesmo identificador da extensão imediatamente anterior

Por fim, a prioridade (que define a ordem com que as extensões são processadas) declarada com o valor n equivale à prioridade da extensão imediatamente anterior incrementada em uma unidade:

exten=>101,1,Dial(SIP/101)
same=>n,Hangup; a prioridade aqui terá o valor 2

Canais SIP

Cada telefone SIP deve ter seu identificador cadastrado no Asterisk. O identificador pode tanto ser um número, análogo a um ramal, ou uma string alfanumérica. No terminologia do Asterisk, cada telefone SIP é chamado de canal SIP, e deve estar declarado em /etc/asterisk/sip.conf:

; Canal 2000 (um exemplo)
[2000]
username=2000 ; o nome do usuário para fins de autenticação
secret=kabrum
type=friend ; pode efetuar e receber chamadas
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
insecure=port,invite ; a segurança está associada ao registro do canal (primeiro
 passo),
                     ; assim como acontece em sessões Web
context=alunos ; o contexto padrão do João. O arquivo extensions.conf o definirá
disallow=all
allow=gsm ; habilita este codec para o João. Os vários codecs serão vistos em se
guida,
          ; já que cada um deles tem suas particularidades.
allow=alaw ; outro codec
allow=ulaw ; mais um codec
qualify=yes; mostra a qualidade, em ms, da conexão entre UAC e UAS.

; Canal joao (outro exemplo)
[joao]
username=joao ; o nome do usuário para fins de autenticação
secret=blabla
type=friend ; pode efetuar e receber chamadas
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
insecure=port,invite ; a segurança está associada ao registro do canal (primeiro
 passo),
                     ; assim como acontece em sessões Web
context=alunos ; o contexto padrão do João. O arquivo extensions.conf o definirá
disallow=all
allow=gsm ; habilita este codec para o João. Os vários codecs serão vistos em se
guida,
          ; já que cada um deles tem suas particularidades.
allow=alaw ; outro codec
allow=ulaw ; mais um codec
qualify=yes; mostra a qualidade, em ms, da conexão entre UAC e UAS.

Como se pode notar, a declaração de um canal SIP envolve muitos parâmetros que envolvem autenticação, controle de acesso, localização na rede, codecs e possivelmente outras capacidades. Como os valores de alguns parâmetros podem ser iguais para vários canais, o Asterisk possibilita a declaração de perfis (templates):

; Perfil alunos
[alunos](!);  a sequência "(!)" define isto como um perfil
type=friend ; pode efetuar e receber chamadas
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
insecure=port,invite ; a segurança está associada ao registro do canal (primeiro
 passo),
                     ; assim como acontece em sessões Web
context=alunos ; o contexto padrão do João. O arquivo extensions.conf o definirá
disallow=all
allow=gsm ; habilita este codec para o João. Os vários codecs serão vistos em se
guida,
          ; já que cada um deles tem suas particularidades.
allow=alaw ; outro codec
allow=ulaw ; mais um codec
qualify=yes; mostra a qualidade, em ms, da conexão entre UAC e UAS.

; Canal 2000
[2000](alunos); a sequência "(alunos)" copia as definições do perfil "alunos"
username=2000 ; o nome do usuário para fins de autenticação
secret=kabrum

; Canal joao
[joao](alunos)
username=joao ; o nome do usuário para fins de autenticação
secret=blabla

Atividade: fazendo chamadas por meio do Asterisk

Para realizar esses exercícios você deve usar o Asterisk na máquina virtual rmu-asterisk. Para testar as chamadas, use o softphone jitsy na máquina real.

Criar as seguintes contas SIP e contextos:
- alunos: Contas 100 e 101
- professores: Contas 200 e 201
- coordenacao: Contas 300 e 301

sip.conf

[general]
insecure=port,invite ; a segurança está associada ao registro do canal (primeiro
 passo),
                     ; assim como acontece em sessões Web
disallow=all
allow=gsm ; habilita este codec para o João. Os vários codecs serão vistos em se
guida,
          ; já que cada um deles tem suas particularidades.
allow=alaw ; outro codec
allow=ulaw ; mais um codec
qualify=yes; mostra a qualidade, em ms, da conexão entre UAC e UAS.

[alunos](!)
type=friend ; pode efetuar e receber chamadas
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
context=alunos

[professores](!)
type=friend ; pode efetuar e receber chamadas
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
context=professores

[coordenacao](!)
type=friend ; pode efetuar e receber chamadas
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
context=coordenacao
 
[100](alunos)
username=100
secret=100

[101](alunos)
username=101
secret=101

[200](professores)
username=200
secret=200

[201](professores)
username=201
secret=201

[300](coordenacao)
username=300
secret=300

[301](coordenacao)
username=301
secret=301

extensions.conf

[alunos]; contexto alunos
; extensoes dos alunos
exten=>100,1,Dial(SIP/100)
same=>n,Hangup
exten=>101,1,Dial(SIP/101)
same=>n,Hangup

[professores]; contexto professores
; extensoes dos professores
exten=>200,1,Dial(SIP/200)
same=>n,Hangup
exten=>201,1,Dial(SIP/201)
same=>n,Hangup

[coordenacao]; contexto coordenacao
; extensoes da coordenacao
exten=>300,1,Dial(SIP/300)
same=>n,Hangup
exten=>301,1,Dial(SIP/301)
same=>n,Hangup
include=>alunos
include=>professores

Crie um plano de discagem em que todos podem fazer chamadas para todos. Isso implica haver um único contexto para os canais SIP.
Execute duas instâncias do Jitsy, sendo que uma delas deve ser configurada para usar a porta 5060, e a outra deve usar a porta 5061. Essas portas servirão para efetuar trocas de mensagens SIP, que é o protocolo usado para iniciar e terminar as chamadas VoIP.
- Para executar uma segunda instância do jitsi, use o seguinte comando em um prompt do shell:
```
jitsi -multiple
```
Adicione uma conta a cada softphone. Use as contas criadas no ítem 1.
A partir de um softphone faça uma chamada para a conta do outro softphone. Verifique se o softphone destino acusou o recebimento de chamada. Caso isso não tenha ocorrido, verifique seu plano de discagem.
Execute o wireshark, e ponha-o em modo de captura em todas as interfaces (pseudo-interface any).
Repita a chamada de um softphone a outro. No softphone destino atenda a chamada, e alguns segundos depois encerre-a.
No wireshark interrompa a captura, e em seguida acesse o menu Telephony->VoIP Calls. Selecione uma chamada, e visualize o diagrama de mensagens SIP. Siga cada mensagem SIP (clique no diagrama), e observe a mensagem selecionada no painel de captura do wireshark. Identifique as transações (observe os códigos de resposta) e os diálogos.
Crie um novo plano de discagem de forma que as contas SIP do contexto alunos só possam atingir outras contas SIP deste contexto. Faça o mesmo para o contexto professores. Contas SIP do contexto coordenação poderão atingir, além das contas SIP desse contexto, as contas dos contextos alunos e professores.

Questões:

Que papel desempenhou o Asterisk para os softphones ? UAS, UAC ou algo diferente ?
Entre que agentes ocorreram os diálogos identificados ?
A stream de audio seguiu o mesmo caminho que a sinalização SIP ?
Como o Asterisk conseguiu identificar o telefone chamado (i.e. localizar onde ele estava na rede) ?

Como testar as chamadas

Para testar as chamadas, são necessários dois softphones além do Asterisk.

Em cada softphone crie uma conta SIP, que deve ser identificada por ramal@IP_do_PBX (ex: se o PBX tiver IP 192.168.2.110, as contas de alunos podem ser 100@192.168.2.110 e 101@192.168.2.110).

Após definir as contas, verifique se os softphones indicaram que elas estão disponíveis (online). Você pode fazer essa verificação também no próprio Asterisk. Neste caso execute o seguinte comando para acessar o console do Asterisk:

sudo rasterisk -vvv
host*CLI> sip show peers
host*CLI> sip show peers
Name/username              Host            Dyn Nat ACL Port     Status     
101/101                    192.168.2.10      D          11270    OK (6 ms)
102/102                    192.168.2.10      D          63169    OK (12 ms)
2 sip peers [Monitored: 2 online, 0 offline Unmonitored: 0 online, 0 offline]

Se algum dos softphones não aparecer como OK no console do Asterisk, verifique se o número de ramal e a senha configuradas no softphone são os mesmos declarados em /etc/asterisk/sip.conf. Outro teste que se pode fazer é acessar o console do Asterisk, e depois tentar ativar as contas SIP nos softphones (i.e. colocá-las para indisponível ou offline, e depois reativá-las). O Asterisk irá mostrar algumas linhas informativas sobre os registros dos softphones (lembre que ao ativar uma conta SIP, ela é registrada no Asterisk usando uma mensagem SIP do tipo REGISTER).
Se as contas SIP estão devidamente registradas no Asterisk, mas ainda assim as chamadas não são realizadas, o problema deve estar no plano de discagem. Isso fica evidente se ao tentar fazer uma chamada obtém-se uma mensagem de erro do tipo 404 not found. Neste caso, acesse o console do Asterisk e tente novamente fazer a chamada. Veja se o Asterisk informa na tela o motivo para a chamada não ser realizada. Em seguida, confira se seu plano de discagem (/etc/asterisk/extensions.conf) possui uma extensão que satisfaça a chamada que se deseja realizar. Isso é, se você estiver tentando chamar o ramal SIP 101@192.168.2.110, deve haver uma extensão assim:
```
exten=>101,1,Dial(SIP/101)
same=>n,Hangup
```

24 e 25/03: Investigando os protocolos envolvidos nas chamadas

Sinalização com SIP

As chamadas que realizamos por meio do Asterisk foram iniciadas e terminadas usando protocolo SIP. Elas podem ser enquadradas em dois casos:

Chamada com intermediação de gateway de midia
Chamada com intermediação de gateway de midia, porém usando re-INVITE

Os diagramas a seguir servem para melhor entender como ocorrem as comunicações em cada caso.

Chamada entre dois agentes SIP com intermediação de um gateway de media

Este caso é parecido com o anterior, que usa um proxy SIP. A diferença está na intermediação do fluxo de media, que é feita pelo gateway de media. Isso possibilita que dois agentes estabeleçam uma chamada mesmo usando codecs diferentes, pois o gateway de media fará a tradução entre codecs.

Fone 1            PBX IP              Fone 2
              (directmedia=no)        
     |                |                |
     |   INVITE       |                |
     |--------------->|   INVITE       |
     |  100 Trying    |--------------->| 
     |<---------------|  100 Trying    |
     |                |<---------------| 
     |                |   180 Ringing  |
     |   180 Ringing  |<---------------|                
     |<---------------|                |      
     |                |    200 Ok      |
     |     200 Ok     |<---------------|
     |<---------------|                |
     |     ACK        |                |
     |--------------->|    ACK         |
     |                |--------------->|
     |    RTP Media   |   RTP Media    |
     |<==============>|<==============>|
     |     BYE        |                |
     |--------------->|    BYE         |
     |                |--------------->|
     |                |    200 Ok      |
     |     200 Ok     |<---------------|
     |<---------------|                |
     |                |                |

Chamada entre dois agentes SIP com intermediação de um gateway de media e uso de re-INVITE

O uso de re-invite possibilita que o fluxo de media seja estabelecido diretamente entre os agentes SIP, caso usem o mesmo codec. Assim, evita-se a carga de processamento envolvida na intermediação pelo gateway de media. Isso é feito com o envio pelo gateway de media (representado abaixo por um PBX IP) de um novo INVITE para cada agente SIP, após a sessão SIP estar estabelecida. Esse novo INVITE contém uma descrição de media (mensagem SDP embutida no corpo da mensagem INVITE) com a localização do outro agente SIP - isso é, seu endereço IP, port UDP para a stream RTP e codec a ser usado.

Fone 1            PBX IP              Fone 2
              (directmedia=yes)        
     |                |                |
     |   INVITE       |                |
     |--------------->|   INVITE       |
     |  100 Trying    |--------------->| 
     |<---------------|  100 Trying    |
     |                |<---------------| 
     |                |  180 Ringing   |
     |  180 Ringing   |<---------------|                
     |<---------------|                |      
     |                |    200 Ok      |
     |     200 Ok     |<---------------|
     |<---------------|                |
     |     ACK        |                |
     |--------------->|    ACK         |
     |    INVITE      |--------------->|
     |<---------------|   INVITE       |
     |    200 OK      |--------------->|
     |--------------->|    200 OK      |
     |    ACK         |<---------------|
     |--------------->|    ACK         |
     |                |<---------------| 
     |                                 |
     |              RTP Media          |
     |<===============================>|
     |     BYE        |                |
     |--------------->|    BYE         |
     |                |--------------->|
     |                |    200 Ok      |
     |     200 Ok     |<---------------|
     |<---------------|                |
     |                |                |

Atividade

Identifique toda a sinalização de uma chamada realizada com sucesso entre dois telefones usando o seu PBX.
- Identifique as transações envolvidas
- Interprete o que está sendo realizado em cada transação
- Identifique os atributos da chamada que foram negociados entre os telefones
- Identifique os agentes SIP envolvidos

31/03: Projeto 2: continuação e RTP

O transporte de midia com protocolo RTP

Transparências
Uma FAQ sobre RTP (muito boa)
RFC 3550: RTP: A Transport Protocol for Real-Time Applications
Capítulo 11 do livro SIP: Understanding the Session Initiation Protocol, 3rd ed
Cap. 7 do livro Redes de Computadores e a Internet, 5a edição, de James Kurose.

O protocolo RTP (Real-Time Protocol) foi desenvolvido para possibilitar o transporte de datagramas de tempo-real contendo voz, video, ou outro tipo de dados, sobre IP. Tanto H.323 quanto o modelo SIP usam RTP para o transporte de media, tornando-o o padrão mais comum para comunicações desse tipo na Internet. Apesar desse protocolo não prover qualidade de serviço (i.e. ele não possui mecanismos para atender tais tipos de requisitos), ele torna possível a detecção de alguns dos problemas introduzidos por uma rede IP, tais como:

Perda de pacotes
Atraso fim-a-fim variável
Chegada de pacotes fora de ordem

Esses problemas não são novidade ... nós já os discutimos nas aulas sobre transmissão de dados multimidia. O que há de novo é um protocolo que dá subsídios para as técnicas que buscam atender requisitos de qualidade de serviço. Esses subsídios são informações providas pelo RTP para ajudar a identificar os problemas citados acima, as quais são:

Identificação do tipo do conteúdo que está sendo carregado (codec): isso informa ao receptor como ele deve decodificar o conteúdo transportado (ver esta tabela de identificadores de codec usados pelo RTP)
Numeração de sequência: essa informação possibilita identificar pacotes perdidos ou fora de ordem.
Marcação de tempo (timestamp): com isso é possível efetuar o cálculo de variação de atraso e implementar algum mecanismo de sincronização com a fonte (ex: atraso de reprodução).

Essas informações fazem parte da PDU RTP, como se pode ver a seguir:

Localização do RTP na camada de transporte	Cabeçalho RTP

RTCP

Além do RTP, o protocolo auxiliar RTCP (Real-Time Control Protocol, também definido na RFC 3550) foi definido para o monitoramento da entrega dos pacotes (recepção da stream). Com esse protocolo, os participantes de uma sessão de media podem fazer o intercâmbio de relatórios e estatísticas. Cada tipo de relatório é transportado por um tipo de pacote RTCP. O uso de relatórios possibilita o feedback sobre a qualidade da comunicação, incluindo informações como:

Número de pacotes enviados e recebidos
Número de pacotes perdidos
Jitter (variação de atraso)

Os cinco tipos de relatórios são:

Relatório do transmissor (Sender Report - SR)
Relatório do receptor (Receiver Report - RR)
Descrição da fonte (Source Description - SDES)
Bye
Específico da aplicação (Application Specific - APP)

Como o tráfego RTCP é puramente overhead, o protocolo foi projetado para que seu consumo da capacidade da rede seja constante, não importa quantos participantes da sessão de media existam. A ideia é que quanto mais participantes houver, menos frequentemente os relatórios RTCP são enviados. Por exemplo, se em uma conferência houver somente dois participantes, os relatórios podem ser enviados a cada 5 segundos. Se houver quatro participantes, os relatórios são enviados a cada 10 segundos. Com isso o consumo de banda para relatórios se mantém constante e previsível.

Atividade

Essa atividade busca ilustrar os fluxos RTP com um exemplo:

Estabeleça uma chamada VoIP entre dois softphones usando o Asterisk como intermediário.
Execute o wireshark no computador onde roda o Asterisk, e ative a captura de datagramas UDP.
Observe os pacotes RTP capturados pelo Wireshark. Selecione alguns deles e investigue as informações contidas em seu cabeçalho. Procure identificar o codec usado e as marcações de tempo. Compare as marcações de tempo do RTP com os instantes de recepção desses pacotes.
Estime o jitter durante a recepção de ao menos 15 segundos de audio.
Observe os relatórios RTCP:
- Que tipos de relatórios são enviados ?
- Com que frequência esses relatórios são transmitidos ?
- Que informações esses relatórios contêm ?

Exercício: faça um grampo de uma chamada de voz, e relate as condições necessárias para isso ser possível, além do procedimento para realizá-lo. Obs: suponha que você não tem acesso ao PBX.

VoIP com SIP e NAT

SIP e NAT

As streams de audio não fluiam entre os telefones porque existe um ou mais tradutores NAT entre os agentes SIP (telefones e PBX). A sinalização SIP (INVITE e sua resposta) carregam mensagens SDP que informam o endereço IP e port UDP para recebimento dos pacotes da stream de audio RTP. Como existe NAT, os endereços informados não correspondem aos endereços IP vistos de fato pelos agentes SIP. Para resolver esse problema existe mais de uma solução, porém a mais simples explora o uso de alguns atributos na configuração SIP do Asterisk.

Para que o Asterisk consiga enviar a stream de audio para telefones SIP que estão atrás de NAT, devem-se adicionar estes atributos aos canais SIP em questão (em sip.conf):
```
nat=yes
qualify=yes
directmedia=no
```
Aqui tem uma boa explicação sobre o que fazem essas opções.
Para que os telefones SIP consigam enviar suas streams de audio para um PBX Asterisk que esteja atrás de NAT, os seguintes atributos devem ser inseridos na seção general de sip.conf:
```
[general]
externip=IP_externo_do_Asterisk
localnet=lista_de_subredes_privativas_do_Asterisk
```
Uma explicação sobre esses atributos

Outra forma de resolver o problema é com ICE/STUN ... uma abordagem mais complicada e sem garantia de que funcione sempre !

01/04: Projeto 2: fazendo chamadas entre os PBX das equipes

Transparências

Até o momento, é possível realizar chamadas somente entre os usuários SIP de um mesmo PBX IP. Porém podem ser necessárias chamadas entre usuários de diferentes PBX. Para isso, algumas modificações devem ser feitas:

Deve haver alguma forma de encaminhar chamadas entre PBX
Deve existir uma maneira de indicar que uma chamada se destina a um usuário de outro PBX

Hoje iremos estender o projeto 2 para que esse tipo de chamada seja possível.

Interligando PBX Asterisk por meio de troncos SIP ou IAX2

A interligação entre PBX Asterisk pode ser feita via rede de dados usando os protocolos SIP ou IAX2. No primeiro caso, o encaminhamento de uma chamada entre dois PBX funciona como uma chamada SIP usual, e isso significa que a sinalização é feita com SIP e a media flui em separado com RTP. No segundo caso, o protocolo IAX2 (Inter-Asterisk eXchange) encapsula tanto a sinalização quanto os fluxos de media, o que simplifica o estabelecimento do tronco.

Inicialmente criaremos a infraestrutura para chamadas VoIP, a qual aumentaremos gradualmente para podermos reproduzir o modelo aqui descrito.

Tronco SIP

Em um entroncamento SIP (SIP trunking), um PBX pode encaminhar chamadas através de um tronco SIP. Essas chamadas podem ser originadas de diferentes formas, tais como telefones IP ou convencionais. Entre os PBX do entroncamento, as chamadas são sinalizadas com SIP e transmitidas com RTP e algum codec.

A ativação de um entroncamento SIP entre dois PBX Asterisk pode ser feita seguindo o exemplo abaixo:

PBX

sip.conf

extensions.conf

Norte

[Sul]
type=user
secret=supersecreta
host=IP_PBX_Norte
disallow=all
allow=ulaw
;canreinvite=no
directmedia=no
context=troncoSIP
qualify=yes

[ParaSul]
type=peer
fromuser=Norte
username=Norte
secret=supersecreta
host=IP_PBX_Sul
disallow=all
allow=ulaw
;canreinvite=no
directmedia=no
qualify=yes

 [troncoSIP]
 ; Ligando para a outra central e, na sequência, o "ramal" de destino
 exten => _4XXX.,1,Dial(SIP/ParaSul/${EXTEN})
 same=>n,Hangup

Sul

[Norte]
type=user
secret=supersecreta
host=IP_PBX_Sul
disallow=all
allow=ulaw
;canreinvite=no
directmedia=no
context=troncoSIP
qualify=yes

[ParaNorte]
type=peer
fromuser=Sul
username=Sul
secret=supersecreta
host=IP_PBX_Norte
disallow=all
allow=ulaw
;canreinvite=no
directmedia=yes
qualify=yes

 [troncoSIP]
 ;
 ; Ligando para a outra central e, na sequência, o "ramal" de destino
 exten => _2XXX.,1,Dial(SIP/ParaNorte/${EXTEN})
 same=>n,Hangup

Atividade: estabelecendo chamadas entre diferentes PBX Asterisk

Nesta atividade, vamos realizar chamadas entre softphones registrados em diferentes PBX Asterisk. Para isso, precisaremos estruturar o os PBX das equipes de forma que cada PBX Asterisk possua um tronco SIP com os demais PBX. Também devemos definir um código de área associado a cada equipe. Assim, é possível fazer um plano de discagem para encaminhar corretamente as chamadas.

07, 08 e 14/04: Projeto 2: entrocamentos SIP e segurança

Continuação da interligação dos PBX iniciada na aula anterior. Em seguida, deve-se pensar em como implementar chamadas com segurança (tanto sinalização quanto midia).

Chamadas seguras

SIP/TLS: sinalização
SRTP e ZRTP: transporte de midia

O que é necessário para ativar essas modalidades de chamadas ?
Qual a diferença em relação a chamadas usuais (SIP e RTP) ? Vale investigar o que muda nas informações carregadas pelos protocolos de sinalização, descrição de sessão e transporte de midia.

Criação de certificados

Obs: altere os nomes dos arquivos de certificados usados nestes exemplos
- ca.crt: certificado do CA raiz
- ca.key: chave privada do CA raiz
- cert.csr: requisição de certificado
- cert.key: chave privada associada à chave pública contida no certificado digital
- cert.crt: certificado digital assinado pelo CA raiz
- cert.pem: certificado digital no formato PEM (necessário para alguns softwares) [outros formatos]
- cert.p12: certificado digital + chave privada no formato PKCS12 (útil para instalação em softwares, tais como navegadores)

Criação do certificado CA raiz (auto-assinado):

openssl req -x509 -new -newkey rsa:1024 -keyout ca.key -out ca.crt -extensions v3_ca -config /etc/ssl/openssl.cnf -set_serial 1
echo 02 > ca.srl
rm -f .rnd

Criação de uma requisição de certificado (certificate request):

openssl req -new -newkey rsa:1024 -keyout cert.key -out cert.csr -sha1 -config /etc/ssl/openssl.cnf

Criação de um certificado digital a partir de uma requisição de certificado:

openssl x509 -req -CA ca.crt -CAkey ca.key -in cert.csr -addtrust serverAuth -out cert.crt -days 365

Mostrar o conteúdo de um certificado:
```
openssl x509 -in cert.crt -text
```

Converter certificado para formato PEM:

openssl x509 -in cert.crt -out cert.pem -outform PEM

Converter certificado para formato PKCS12:

openssl pkcs12 -export -in cert.crt -inkey cert.key -out cert.p12

Leitura complementar

A integração entre PSTN e VoIP tem o potencial de estender o serviço de telefonia, com a liberdade que o modelo da Internet confere à criação de novos serviços e aplicações. Uma peça-chave para que essa integração ocorra é o mapeamento entre usuários VoIP e números de telefone da PSTN. O serviço ENUM foi proposto buscando atender essa necessidade, e fazendo uso do DNS. Leiam os textos abaixo para se informarem mais sobre essa proposta:

15/04: Avaliação 1

A avaliação 1 cobrirá os assuntos estudados até dia 08/04.

Os exercícios do capítulo 7 do livro "Redes de Computadores e a Internet, 5a edição", do Kurose, devem ser resolvidos:

Exercicios de fixação: 1, 2, 4, 5, 6, 7, 9, 10, 11, 12
Problemas: 1, 3, 4, 5, 7, 8, 9, 10, 12, 13, 14, 16, 17, 18, 19

É possível que haja questões na avaliação sobre o uso do Asterisk, envolvendo definição de canais SIP e plano de discagem.

Vejam as provas feitas em semestres anteriores:

22/04: Projeto 2: conclusão; correção da avaliação

As tecnologias citadas em aula, com respeito a redes sem-fio para aplicações com prazos estritos entrega de mensagens (entre outros requisitos difíceis de atender):

A apresentação do projeto 2 deve ser feita na próxima aula (28/04). Cada equipe deve demonstrar o funcionamento de sua infraestrutura VoIP, e esclarecer questões colocadas pelo professor. O projeto terá assim dois conceitos:

Conceito do projeto: avalia a equipe quanto ao cumprimento dos requisitos do projeto, e a documentação por meio de um relatório da solução implantada
Conceito individual: avalia cada membro da equipe quanto ao domínio da solução

O relatório deve ter informação suficiente para que o sistema seja reproduzido por outras pessoas, e deve conter:

Uma introdução que apresente o sistema VoIP desejado, incluindo quais seus atrativos e o que ele deve ser capaz de fazer. A introdução deve conter também o objetivo do projeto.
A descrição da solução, que deve apresentar a arquitetura do sistema implantado (evidenciando seus componentes e seus papéis ... usem figuras), e em seguida como cada componente foi integrado e configurado no sistema. Deve-se incluir também um tutorial sobre como adicionar novos usuários ao sistema, e o que cada usuário deve possuir/configurar para poder utilizá-lo.
Uma conclusão (ou considerações finais), em que se resume o que foi realizado, fazendo uma comparação com o objetivo do projeto e o sistema VoIP desejado.

28/04: Apresentação do projeto 2

29/04: Conclusão do projeto 2

...

04/05: Introdução à qualidade de serviço (Qos)

Como medir a qualidade de serviço de uma rede ?

Disponibilidade ?
Largura de banda
Latência (atraso fim-a-fim)
Variação de atraso (jitter)
Perda de pacotes

Um comparativo de requisitos de QoS de algumas aplicações

Como prover QoS ?

Uma pequena experiência

Nessa experiência, todos vão realizar um download simultâneo de um grande arquivo. Enquanto isso, um dos alunos vai visualizar um video via streaming.

Para fazer o download:

wget http://tele.sj.ifsc.edu.br/~msobral/ubuntu.iso

Para ver o video execute:

vlc http://172.18.20.251/~msobral/video.avi

Qual a taxa de download que foi obtida ?
Como se desempenhou a reprodução do video ?

A reprodução do video poderia ser preservada se a rede priorizasse seu tráfego. Assim, uma forma de priorização será definida no gateway do laboratório. Após essa modificação, repitam os downloads do arquivo e reprodução do video.

Qual a nova taxa de download obtida ?
Como se desempenhou a reprodução do video desta vez ?

Uma outra experiência

Desta vez, todos irão usar softphones (ou telefones IP) para escutar uma mensagem gravada em um servidor fora da rede, ao mesmo tempo em que se descarrega um arquivo via HTTP:

Execute o Jitsi ou algum outro sopftphone, registrando-o em 172.18.20.251 com o ramal 20001 a 2010 (com senha=número_do_ramal).

Faça este download:

wget http://172.18.20.251/~msobral/rmu.bin

Execute o wireshark, e deixe-o capturando datagramas UDP na interface eth0.
Chame o ramal 6666, e escute a mensagem gravada.
Ao final da chamada, veja a qualidade da stream RTP no wireshark, acessando o menu Telephony->RTP->Show All Streams.

Novamente, as chamadas poderiam ser preservadas se a rede priorizasse seu tráfego. Para isso, foi reativada a priorização de datagramas UDP no gateway do laboratório. Após essa modificação, repitam os downloads do arquivo e realização das chamadas.

Qual a nova taxa de download obtida ?
Que qualidade se obteve para as streams RTP desta vez ?

Provendo QoS: conceitos básicos

Como PROVER qualidade de serviço em uma rede ?

Como classificar os pacotes, para que sejam tratados de acordo com os requisitos de QoS especificados ?
Como garantir banda para um determinada classe de tráfego ?
Como limitar o uso de banda ?
Como limitar o atraso fim-a-fim de pacotes ?
Como limitar a variação de atraso (jitter) de pacotes ?

Assume-se que a rede considerada seja formada por uma malha de roteadores. Cada interface de um roteador possui uma fila de saída, onde ficam os pacotes à espera de serem transmitidos, como mostrado na figura a seguir. Essas filas possuem tamanho limitado, sendo implementadas por buffers de memória. Para prover QoS, uma primeira necessidade é controlar quando saem pacotes por uma interface (para limitar banda), e a ordem em que pacotes saem (para priorizar pacotes, garantir banda e limitar atrasos). Isso significa atuar principalmente sobre as filas de saída das interfaces de rede.

Algumas técnicas conhecidas podem ser usadas para atender os requisitos acima:

Classificador: classifica os pacotes em classes de serviço, de acordo com contratos de tráfego predefinidos. Atua na entrada de pacotes no roteador.
Disciplinas de filas: trata de definir a ordem de saída de pacotes. Com isso se consegue implementar garantia de banda mínima, priorização de tráfego, redução de atraso fim-a-fim e variação de atraso.
Balde furado (leaky bucket): trata de definir quando pacotes podem sair. Com isso se pode fazer limitação de banda. Esta é uma técnica fundamental para fazer condicionamento de tráfego (traffic shaping);.

A combinação dessas técnicas possibilita atender os requisitos de QoS especificados para diferentes tipos de tráfego. Elas são amplamente usadas em arquiteturas para QoS na Internet, tais como Intserv e Diffserv.

Exercícios

Resolver os exercícios propostos no final das transparências.

OBS: para o problema de enfileiramentos RR e WFQ:

classe 1 (peso 2 no caso do WFQ) = pacotes 2,3,6,8,9,12
classe 2 (peso 4 no caso do WFQ) = pacotes 4,5,7,10,11

No caso do enfileiramento com prioridades: pacotes ímpares são mais prioritários.

06/05: QoS em um roteador Linux

Transparências
Um bom tutorial sobre disciplinas de filas no Linux
Linux Advanced Routing and Traffic Control Howto: quase tudo sobre disciplinas de filas (e mais outras coisas).

Disciplinas de filas (qdisc)

Disciplinas de filas são mecanismos para condicionar a saída de pacotes por uma interface de rede. Com elas se podem priorizar pacotes e limitar taxas de bits de fluxos de saída.

Visão geral do enfileiramento de pacotes em uma interface de saída

As filas contidas nas qdisc podem ser tratadas de diferentes formas. Isso vai determinar a ordem e o ritmo com que os pacotes são desenfileirados para serem transmitidos. Alguns exemplos de qdisc implementadas no Linux:

FIFO: pacotes saem por ordem de chegada.
PRIO: pacotes saem de acordo com prioridades.
SFQ (Stochastic Fair Queueing): pacotes saem de forma que os fluxos a que pertencem recebam aproximadamente a mesma taxa de bits.
TBF (Token Bucket Filter): pacotes saem limitados a uma certa taxa de bits.
... e outras (ver Differentiated Service on Linux HOWTO e Linux Advanced Routing and Traffic Control Howto)

Os diagramas abaixo ilustram algumas dessas qdisc:

Uma disciplina de filas baseada em prioridades. Fonte: Differentiated Service on Linux HOWTO

A qdisc TBF (combinada com PRIO), usada para limitar a taxa de saída. Fonte: Differentiated Service on Linux HOWTO

Atividade

Os exercícios sobre disciplinas de filas serão realizados em um cenário em que dois tipos de fluxo são estabelecidos entre duas redes, que estão interligadas por um link ponto-a-ponto. Esse link tem capacidade limitada a 512 kbps. Os fluxos são representados por:

Uma transferência de um arquivo com HTTP
Uma chamada VoIP com SIP e RTP

A rede a ser usada deve ser criada no Netkit2, a partir da configuração abaixo:

Arquivo de configuração do Netkit (copie-o para dentro de Lab.conf)

server1[type]=generic
server2[type]=generic
pc[type]=generic
r1[type]=gateway
r2[type]=gateway
 
# Rede 1: servidores + roteador r1
server1[eth0]=rede1:ip=192.168.1.1/24
server2[eth0]=rede1:ip=192.168.1.2/24
r1[eth0]=rede1:ip=192.168.1.254/24
 
# Rede 2: pc + roteador r2
r2[eth0]=rede2:ip=192.168.2.254/24
pc[eth0]=rede2:ip=192.168.2.1/24
 
# Link PPP entre Rede 1 e Rede 2 (512 kbps)
r1[eth1]=link:ip=10.0.0.1/30
r2[eth1]=link:ip=10.0.0.2/30
 
# Roteadores default dos servidores e pc
server1[default_gateway]=192.168.1.254
server2[default_gateway]=192.168.1.254
pc[default_gateway]=192.168.2.254
 
# Rotas estáticas nos roteadores
r1[route]=192.168.2.0/24:gateway=10.0.0.2
r2[route]=192.168.1.0/24:gateway=10.0.0.1
 
# Ativando o servidor HTTP em server1
server1[services]=apache2

Roteiro

1) Antes de mais nada, deve-se limitar a banda do enlace ponto-a-ponto (entre r1 e r2) a 256 kbps. Crie o arquivo /root/qdisc.sh em cada um desses roteadores, e grave neles o seguinte:

#!/bin/bash
 
# Limpa as qdisc que porventura existam
tc qdisc del dev eth1 root
 
# Cria uma qdisc HTB (Hierarchical Token Bucket) para limitar a saída a uma taxa comparável 
# a do link ponto-a-ponto
tc qdisc add dev eth1 root handle 1: htb default 1
tc class add dev eth1  parent 1: classid 1:1 htb rate 256kbit ceil 256kbit

Obs: isso implanta uma qdisc do tipo HTB (ser vista com detalhes numa aula posterior) para fazer a limitação de banda. Após criar o arquivo /root/qdisc.sh, execute-o:

bash /root/qdisc.sh

2) As chamadas VoIP serão simuladas usando uma ferramenta de teste chamada siprtp, que faz parte do projeto PJSIP. Seu uso deve ser da seguinte forma:

Em server2 executa-se o siprtp em modo servidor:
```
siprtp --ip-addr=192.168.1.2
```
Em um dos roteadores deve-se executar o wireshark (ver menu Wireshark), escolhendo-se a interface eth0.
Em pc executa-se o siprtp em modo cliente, de forma a efetuar uma chamada para server2:
```
siprtp --ip-addr=192.168.2.1 sip:0@192.168.1.2
```

Em pc pode-se monitorar o andamento da chamada teclando-se l. Um sumário como mostrado abaixo deve ser apresentado:

>>> l
List all calls:
Call #0: CONFIRMED [duration: 00:00:01.643]
   To: sip:0@127.0.1.1;tag=PKcMBzp6yhIZQG-du1TsYkW1MPmX6L5V
   Signaling quality: got 1st response in 0 ms, connected after: 0 ms
   Stream #0: audio PCMU@8000Hz, 20ms/frame, 8.00KB/s (9.06KB/s +IP hdr)
              RX stat last update: never
                 total 77 packets 12.03KB received (14.07KB +IP hdr)
                 pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
                       (msec)    min     avg     max     last
                 loss period:   0.000   0.000   0.000   0.000
                 jitter     :   0.000   0.000   0.000   0.000
              TX stat last update: never
                 total 77 packets 12.03KB sent (14.07KB +IP hdr)
                 pkt loss=0 (0.0%), dup=0 (0.0%), reorder=0 (0.0%)
                       (msec)    min     avg     max     last
                 loss period:   0.000   0.000   0.000   0.000
                 jitter     :   0.000   0.000   0.000   0.000
             RTT delay      :   0.000   0.000   0.000   0.000

A cada vez que se teclar l, um novo sumário pode ser visualizado.
Quando se quiser encerrar a chamada, deve-se teclar h, e em seguida fornecer o número da chamada (0 - zero).
Após o término da chamada, recarregar os pacotes no wireshark (tecle no ícone para forçar a atualização). Em seguida selecione Telephony->VoIP Calls e visualize a chamada realizada. Experimente também selecionar Telephony->RTP->Show All streams e analisar a stream RTP da chamada. Observe particularmente os valores para delta e jitter.

3) O experimento da realização da chamada VoIP deve ser repetido, porém realizando-se também uma transferência de arquivo com HTTP entre server1 e pc:

Crie um arquivo de 16 MB em server1:

dd if=/dev/urandom of=/var/www/teste.img bs=4096 count=4096

Inicie seu download em pc:

wget http://192.168.1.1/teste.img > log 2>&1 &

Repita os passos do ítem 1, prestando especial atenção aos valores de jitter e perda de pacotes mostrados no sumário de chamada do siprtp. Compare aos valores obtidos quando foi realizada somente a chamada VoIP.

4) Chamadas VoIP são consideradas prioritárias em comparação a transferências de arquivos (e fluxos de dados em geral), pois possuem restrições de atrasos e jitter. Assim, devem ser definidas qdisc nos roteadores para priorizar pacotes RTP. Isso pode ser feito assim:

Em r1 e r2 cria-se uma qdisc do tipo prio na interface eth1. Os fluxos UDP com port 4000 (stream RTP criada pelo siprtp) devem ser colocados na fila de maior prioridade. Copie os comandos abaixo para dentro do arquivo /root/qdisc.sh:

#!/bin/bash
 
# Limpa as qdisc que porventura existam
tc qdisc del dev eth1 root
 
# Cria uma qdisc HTB (Hierarchical Token Bucket) para limitar a saída a uma taxa comparável 
# a do link ponto-a-ponto
tc qdisc add dev eth1 root handle 1: htb default 1
tc class add dev eth1  parent 1: classid 1:1 htb rate 256kbit ceil 256kbit
 
# Cria uma qdisc PRIO, porém subordinada a qdisc TBF
tc qdisc add dev eth1 parent 1:1 handle 10:0 prio
 
# Datagramas UDP vão pra fila mais prioritária.
tc filter add dev eth1 parent 10: prio 1 protocol ip u32 match ip protocol 17 0xff flowid 10:1
 
# Segmentos TCP vão pra fila menos prioritária.
tc filter add dev eth1 parent 10: prio 1 protocol ip u32 match ip protocol 6 0xff flowid 10:2

... e em seguida execute-o:

bash /root/qdisc.sh

Repita o ítem 2, e observe as perdas de pacotes e jitter da chamada VoIP. Houve melhora ?

5) Pela capacidade do link é possível haver mais de uma chamada VoIP. Sendo assim:

Calcule quantas chamadas podem ser atendidas através desse link.
Teste se de fato essa quantidade de chamadas pode ser atendida, respeitando-se seus requisitos de QoS. Para iniciar mais de uma chamada simultânea execute o siprtp da seguinte forma:
```
# inicia duas chamadas
siprtp --ip-addr=192.168.2.1 --count=2
```

6) E se for desejável limitar o atendimento com qualidade de até quatro chamadas, deixando o restante da capacidade do link para transferências de dados ? Pense numa forma de fazer isso usando as disciplinas de filas do Linux (dica: veja a qdisc TBF).

Implemente essa limitação nos roteadores.
Teste qual a taxa disponível para transferências de dados.
verifique se até quatro chamadas simultâneas podem ser atendidas a contento.

12/05: QoS em roteador Linux

Transparências
Um bom tutorial sobre disciplinas de filas no Linux
Linux Advanced Routing and Traffic Control Howto: quase tudo sobre disciplinas de filas (e mais outras coisas).
HTB (Hierarchical Token Bucket) queuing discipline

qdisc com estado (stateful)

Com exceção da qdisc PRIO, até o momento foram vistas somente qdisc capazes de conter uma única classe. Regras de priorização e condicionamento de tráfego mais elaboradas precisam, no entanto, combinar qdisc hierarquicamente. Isso pode ser percebido com um primeiro exemplo.

Em um enlace, deseja-se limitar em 100 kbps o tráfego de um conjunto de aplicações. No entanto, cada aplicação também deve ter um limite de uso do enlace, de acordo com o descrito a seguir:

WWW (http e https): 40 kbps
SSH: 40 kbps
Demais aplicações: 20 kbps

O diagrama abaixo mostra como poderia ser modelada a limitação de banda para essas aplicações:

Como isso poderia ser feito usando o tc ? Usando apenas as qdisc que já vimos não parece possível implementar essa regras (na dúvida, você pode tentar). Mas se for usada uma qdisc capaz de conter várias classes, isso poderia ser realizado. Essa qdisc limitaria o uso de banda a 100 kbps, e dentro dela existiriam três classes (uma para cada tipo de aplicação). Cada classe, por sua vez, conteria uma qdisc que poderia impor sua limitação de banda específica. E é exatamente isso que a qdisc HTB (Hierarchical Token Bucket) é capaz de fazer, criando uma hierarquia de classes e qdisc como mostrado na figura abaixo:

# adiciona a qdisc raiz na interface eth0
tc qdisc add dev eth0 root handle 1:0 htb default 23

# cria a classe filha, que impõe o limite de banda global desta HTB
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 100kbps ceil 100kbps

# cria as classes das aplicações
tc class add dev eth0 parent 1:1 classid 1:21 htb rate 40kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:22 htb rate 40kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:23 htb rate 20kbps ceil 100kbps

# cria os filtros para classificar os datagramas
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip sport 80 0xffff flowid 1:21
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip sport 443 0xffff flowid 1:21
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip sport 22 0xffff flowid 1:22

A qdisc HTB funciona da seguinte forma:

Cada classe possui uma taxa garantida e uma taxa máxima.
A banda garantida não utilizada por uma classe reverte para para sua classe mãe (um nível acima na hierarquia). Essa sobra pode assim ser aproveitada pelas outras classes filhas.
Cada classe pode emprestar banda adicional de sua classe mãe até o limite especificado por sua taxa máxima.
Se houver mais de uma classe filha requisitando banda adicional, a classe mãe divide essa banda proporcionalmente à taxa garantida de cada filha.
Classes podem ter prioridades, de forma que classes mais prioritárias se apropriam primeiro da banda de sobra (mas a taxa garantida é preservada).

Os parâmetros da qdisc HTB estão sumarizados abaixo:

Parâmetro	Descrição	Exemplo
rate	taxa garantida	rate 100kbit
ceil	taxa máxima	ceil 200 kbit
prio	prioridade da classe (menores valores = maiores prioridades)	prio 1
burst	quantidade máxima de bytes de uma classe, dentro da taxa garantida, que podem ser enviados antes de servir outra classe	burst 20 kb
cburst	quantidade máxima de bytes de uma classe, acima da taxa garabntida, que podem ser enviados antes de servir outra classe	cburst 20 k

Atividade

A rede abaixo será usada para os experimentos com disciplinas de enfileiramento:

Configuração para o Netkit (salvar em Lab.conf)

# Global attributes: these values are obtained automatically from menu General->Preferences
# 32 MB por VM
global[mem]=32
# Não remove o diretório de trabalho ao final da execução
global[clean]=False
 
server1[type]=generic
server2[type]=generic
pc1[type]=generic
pc2[type]=generic
pc3[type]=generic
r1[type]=gateway
r2[type]=gateway
 
# Rede 1: servidores + roteador r1
server1[eth0]=rede1:ip=192.168.1.1/24
server2[eth0]=rede1:ip=192.168.1.2/24
r1[eth0]=rede1:ip=192.168.1.254/24
 
# Rede 2: pc + roteador r2
r2[eth0]=rede2:ip=192.168.2.254/24
pc1[eth0]=rede2:ip=192.168.2.1/24
pc2[eth0]=rede2:ip=192.168.2.2/24
pc3[eth0]=rede2:ip=192.168.2.3/24
 
# Link PPP entre Rede 1 e Rede 2 (512 kbps)
r1[eth1]=link:ip=10.0.0.1/30
r2[eth1]=link:ip=10.0.0.2/30
 
# Roteadores default dos servidores e pc
server1[default_gateway]=192.168.1.254
server2[default_gateway]=192.168.1.254
pc1[default_gateway]=192.168.2.254
pc2[default_gateway]=192.168.2.254
pc3[default_gateway]=192.168.2.254
 
# Rotas estáticas nos roteadores
r1[route]=192.168.2.0/24:gateway=10.0.0.2
r2[route]=192.168.1.0/24:gateway=10.0.0.1
 
# Ativando o servidor HTTP em server1
server1[services]=apache2,netserver

1) Na rede usada nos exercícios da semana passada, procuravam-se priorizar as chamadas VoIP usando uma qdisc PRIO. Modifique a disciplina de enfileiramento nos roteadores para que até 2 chamadas possam ser realizadas simultaneamente (com seus requisitos de QoS atendidos). Use a qdisc HTB.

Qual a banda disponível para as transferências de dados no melhor e no pior caso ? Descubra isso por meio de um experimento na rede simulada (você pode usar o netperf).

Regras para criar as disciplinas de filas

#!/bin/bash

IFACE=eth1

tc qdisc del dev $IFACE root > /dev/null 2>&1

# adiciona a qdisc raiz na interface eth0
tc qdisc add dev $IFACE root handle 1:0 htb default 22

# cria a classe filha, que impõe o limite de banda global desta HTB
tc class add dev $IFACE parent 1:0 classid 1:1 htb rate 512kbit ceil 512kbit

# cria as classes das aplicações
tc class add dev $IFACE parent 1:1 classid 1:21 htb rate 180kbit ceil 512kbit
tc class add dev $IFACE parent 1:1 classid 1:22 htb rate 332kbit ceil 512kbit

# cria os filtros para classificar os datagramas
tc filter add dev $IFACE protocol ip parent 1:0 prio 1 u32 match ip protocol 17 0xff flowid 1:21

2) Modifique as regras de QoS do exercicio 1 de forma que:

pc1 tenha garantidos 256 kbps, com garantia de QoS para uma chamada VoIP.
pc2 tenha garantidos 256 kbps, com garantia de QoS para duas chamadas VoIP.
pc3 não tenha banda garantida, mas possa usar a banda ociosa.

Exemplo de como criar um classificador baseado em endereços IP:

# classifica de acordo com o endereço IP de destino do datagrama
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 4.3.2.1/32 flowid 1:22


# classifica de acordo com o endereço IP de origem do datagrama
tc filter add dev eth1 protocol ip parent 1:0 prio 2 u32 match ip src 4.3.2.1/32 flowid 1:22

# classifica de acordo com o endereço IP de origem do datagrama E se for UDP
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 4.3.2.1/32 
match ip protocol 17 0xff flowid 1:22

# classifica de acordo com o endereço IP de origem do datagrama E port de origem 80
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 4.3.2.1/32 
match ip sport 80 0xffff flowid 1:22

# classifica de acordo com o endereço IP de origem do datagrama E port de destino 80
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 4.3.2.1/32 
match ip dport 80 0xffff flowid 1:22

3) Incremente as regras de QoS do exercício 2 para que tráfego SSH tenha prioridade em relação aos demais tipos de tráfego de dados.

4) Em relação ao exercício 3, ao invés de priorizar SSH modifique as regras para que se garanta ao menos 64 kbps para esse tipo de tráfego.

5) A disciplina de filas WFQ, existente em roteadores Cisco e usada para garantir banda para classes de serviço, não está implementada no controle de tráfego do Linux. Com as disciplinas existentes no Linux seria possível emular a WFQ ? Caso sim, como isso poderia ser feito ?

Por exemplo, como emular WFQ de forma que chamadas VoIP tenham peso 5, tráfego SSH tenha peso 2, e demais tipos de tráfego tenha peso 3 ?
Como se poderia resolver o exercício 2 caso se usasse WFQ ?
DESAFIO: faça um programa ou script que implante uma disciplina WFQ no Linux.

Exercícios

Sobre disciplinas de filas e QoS.

Lista: exercícios 20 a 28 do cap. 7 do livro Redes de Computadores e a Internet, 5a edição, de James Kurose.

Questões de avaliações anteriores

19/05: continuação dos exercícios

Uma forma alternativa de classificar pacotes para as qdisc:

Usando o iptables: na tabela mangle usa-se o alvo CLASSIFY para associar um datagrama a uma classe. Ex:

# Uma qdisc HTB com taxa de 100 kBps e duas classes .. apenas para exemplificar o uso do iptables mais abaixo
tc qdisc add dev eth0 root handle handle 1:0 htb default 13
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 100kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 80kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:13 htb rate 20kbps ceil 100kbps

# datagramas da classe DSCP AF41 vão para a classe 1:21 do tc
iptables -t mangle -A POSTROUTING -p tcp --sport 80 -j CLASSIFY --set-class 1:12
iptables -t mangle -A POSTROUTING -p tcp --sport 443 -j CLASSIFY --set-class 1:12

OBS: o alvo CLASSIFY é do tipo não-terminal. Isso significa o processamento das regras continua, mesmo que uma determinada regra seja selecionada. Por isso devem-se organizar as regras de classificação da mais genérica para a mais específica. Ex:

# datagramas udp destinados a 192.168.1.1 vão para a qdisc 1:11
# demais pacotes para 192.168.1.1 vão para a qdisc 1:12
iptables -t mangle -A POSTROUTING -d 192.168.1.1 -j CLASSIFY --set-class 1:12
iptables -t mangle -A POSTROUTING -p udp -d 192.168.1.1 -j CLASSIFY --set-class 1:11

Dicas para o iptables

Uma regra com iptables deve especificar basicamente quatro coisas:

Tabela: a tabela indica a finalidade da regra. No caso do classificador, deve ser mangle. Essa tabela contém regras que modificam valores de cabeçalhos de pacotes (no caso, a classe/qdisc).
Chain: em que chain deve ser adicionada.
- No caso do classificador, deve-se usar a chain FORWARD (avalia as regras logo após consultar a tabela de rotas).
Seletor: informações a serem usadas para selecionar os pacotes a que ela deve ser aplicada.
Alvo (target): ação a ser executada sobre o pacote que ativar a regra.
- Dependendo do alvo pode haver opções adicionais .

Por exemplo, a regra abaixo marca com o DSCP AF41 os datagramas vindos da rede 172.18.0.0/16:

Desta forma, a escrita das regras depende de conhecer as opções para definição de seletores, e os possíveis alvos. Algumas opções de uso comum para composição de seletores são listadas abaixo, sendo que o que está entre colchetes ([]) é opcional. Um seletor pode ser composto por uma combinação dessas opções. Para mais detalhes leia o manual.

Opção	Descrição	Exemplo
-s IP[/Mascara]	endereço IP de origem	-s 200.135.37.64/26
-d IP[/Mascara]	endereço IP de destino	-d 8.8.8.8
-p Protocolo	protocolo de transporte (tcp ou udp)	-p tcp
--dport numero	Port de destino	--dport 80
--sport numero	Port de origem	--sport 53
--syn	Se flag SYN está acesa (somente TCP)
--tcp-flags Flags1 Flags2	Se somente as flags listadas em Flags1 estão acesas dentre as Flags2	--tcp-flags SYN,ACK,RST,FIN SYN
-i interface	Se pacote foi recebido pela interface	-i eth0
-o interface	Se pacote vai sair pela interface	-o eth1
-m state --state ESTADO	Identifica o estado do fluxo, o qual pode ser: NEW: início de um fluxo ESTABLISHED: parte de um fluxo estabelecido RELATED: inicia um novo fluxo, porém relacionado com um fluxo existente	-m state --state NEW,RELATED

20/05: Continuação dos exercícios sobre disciplinas de filas

26/05: Diffserv em roteador Linux

Transparências

Diffserv é um modelo para provimento de QoS para Internet, em que fluxos são classificados e então tratados de forma diferenciada dentro da rede. A proposta, contida na RFC 2475, visa definir um modelo flexível e escalável para atendimento de requisitos de QoS.

Flexibilidade: o tratamento de cada classe de tráfego é uma decisão da gerência da rede, e assim não é especificada na proposta.
Escalabilidade: a priorização e condicionamento de tráfego a serem feitos nos roteadores se basearão nas classes de tráfego, e não nos fluxos individuais que passam pela rede (compare com IntServ). Isso proporciona a agregação dos fluxos, que são rotulados com as classes de serviço, facilitando a tarefa dos roteadores no núcleo da rede.

Obs: as figuras abaixo foram obtidas em um artigo da Cisco

Uma visão geral da arquitetura DiffServ pode ser vista na figura abaixo:

Arquitetura DiffServ

Diversos elementos compõem a arquitetura:

Domínios DiffServ: conjuntos de roteadores onde se aplicam uma determinada classificação e diferenciação de tráfego, definidas pela gerência da rede.
Roteadores de borda: roteadores que classificam fluxos que entram num domínio DiffServ. Essa tarefa de classificação e condicionamento de fluxos de entrada pode ser complexa. Por esses roteadores também passam fluxos que saem do domínio, para serem entregues a sistemas finais.
Roteadores de núcleo: roteadores internos de um domínio DiffServ, que encaminham fluxos já classificados. Esses roteadores verificam a conformidade desses fluxos às regras definidas pela gerência da rede para as classes de serviço. Assim, pacotes desses fluxos estão sujeitos a priorizações, enfileiramentos, e mesmo descartes, dependendo das restrições de QoS que foram definidas. Essas regras compõem o que se chama de Comportamento por Salto (PHB - Per-Hop Behaviour), representada no diagrama contido na figura abaixo.

PHB - Per-Hop Behaviour

A classificação feita nos roteadores de borda mapeia características dos fluxos para um número de 6 bits. Assim, podem haver até 64 classes de serviço em um domínio DiffServ. Esse número, chamado de DSCP - DiffServ Code Point, é inscrito no campo ToS dos datagramas IPv4 (ou no campo Traffic Class de datagramas IPv6), como mostrado abaixo:

Os comportamentos por salto podem ser:

Default PHB: pacotes com DSCP de valor 000000 (zero) são tratados com melhor esforço. Isso também deve ser aplicado para pacotes cujos DSCP tenham valores não reconhecidos pelo roteador. Ver maiores detalhes na RFC 2474.
Class-selector PHB: pacotes com DSCP xxx000 são tratados de acordo com uma política tradicional de precedência IP (i.e. classes de tráfego descritas no campo ToS). Também descrito na RFC 2474
Expedited Forwarding PHB (EF): semelhante ao serviço garantido do IntServ. Desenhado para prover um serviço com baixas taxas de perda, baixa latência e jitter, e uma largura de banda garantida. Deve ser usado somente por aplicações críticas. O valor do DSCP deve ser 101110 (ver RFC 2598)
Assured Forwarding PHB (AF): semelhante ao serviço de carga controlada do IntServ. Define quatro classes de serviço, sendo que cada uma tem três níveis de precedência de descarte.

Classes de serviço e precedências de descarte em AF PHB

Uma interpretação sobre Diffserv

Um domínio DiffServ é composto por roteadores com comportamentos predefinidos (PHB - Per Host Behavior), e que policiam e condicionam fluxos de acordo com as classes de tráfego existentes. Dentre os quatro grupos de classes, vale destacar estes dois:

Encaminhamento Acelerado (Expedited Forwarding - EF): proporciona baixo atraso, baixo jitter, baixa perda de pacotes. Uma boa discussão sobre esse PHB pode ser encontrada aqui.

Principal característica: definir um limite superior para atraso de encaminhamento em um nodo, assumindo que a fila de saída esteja usualmente vazia ou seja curta.

Finalidade: atender fluxos que necessitam de atrasos e jitter estritos.
De acordo com a RFC 3246:

Intuitively, the definition of EF is simple: the rate at which EF
traffic is served at a given output interface should be at least the
configured rate R, over a suitably defined interval, independent of
the offered load of non-EF traffic to that interface.

... e complementado pela RFC 3248:

For a traffic stream not exceeding a configured rate the goal of the
DB PHB is a strict bound on the delay variation of packets through a
hop.

Traffic MUST be policed and/or shaped at the source edge (for
example, on ingress to the DS-domain as discussed in RFC 2475 [5]) in
order to get such a bound.  However, specific policing and/or shaping
rules are outside the scope of the DB PHB definition.  Such rules
MUST be defined in any per-domain behaviors (PDBs) composed from the
DB PHB.

Encaminhamento Assegurado (Assured Forwarding - AF): oferece diferentes probabilidades de que pacotes sejam encaminhados.
- Principal característica: a probabilidade de que pacotes sejam encaminhados depende dos recursos alocados (buffer e largura de banda) para cada classe AF e respectivas precedências de descartes em caso de congestionamento.
- Finalidade: limitar a vazão de fluxos, respeitando rajadas em certa medida.
  De acordo com a RFC 2597:
```
In a DS node, the level of forwarding assurance of an IP packet thus
depends on (1) how much forwarding resources has been allocated to
the AF class that the packet belongs to, (2) what is the current load
of the AF class, and, in case of congestion within the class, (3)
what is the drop precedence of the packet.
```

As outras classes são Default PHB, que corresponde a um serviço melhor esforço, e Class Selector PHB, que se baseia na interpretação convencional do campo ToS do cabeçalho IP.

A implantação de um domínio DiffServ usando roteadores Linux implica usar as regras de controle de tráfego do Linux (via utilitários tc e iptables) para criar essas classes. Para isso precisamos ter claro o seguinte:

Como policiar tráfego que entra em um domínio DiffServ ?
Como modificar o campo DSCP de datagramas IP, e como usar o valor desse campo para identificar uma classe de tráfego ?
Como limitar atrasos de encaminhamento ?
Como garantir banda a um fluxo agregado, com certa tolerância a rajadas ?
Como fazer descartes com diferentes probabilidades e precedências ?

Marcação DiffServ

No DiffServ, o campo DSCP de datagramas IP é usado para indicar a classe a que pertence cada datagrama. Com base nesse valor, cada roteador pode aplicar seu PHB e assim condicionar o tráfego. Existem duas formas de marcar o campo DSCP e usar esse valor para classificação:

Usando o tc: isso pode ser feito diretamente com o tc, por meio de uma qdisc especial chamada DSMARK combinada a filtros. Essa forma de marcar e classificar datagramas é um pouco mais complexa, como se pode ver por este exemplo:

# Cria a qdisc DSMARK com 64 índices. 
tc qdisc add dev eth0 handle 1:0 root dsmark indices 64 set_tc_index

# Cria uma classe DSMARK para definir o valor do DSCP para 0xb8
tc class change dev eth0 classid 1:1 dsmark mask 0x3 value 0xb8

... e para escolher uma classe dependendo do valor DSCP:

# Filtro que usa o valor do DSCP para calcular o valor do handle de outro filtro. Quer dizer, 
# este filtro serve apenas para selecionar outro filtro.
tc filter add dev eth0 parent 1:0 protocol ip prio 1 tcindex mask 0xfc  shift 2

# Uma qdisc HTB com taxa de 100 kBps e duas classes .. apenas para exemplificar o uso do filtro tc_index mais abaixo
tc qdisc add dev eth0 parent 1:0 handle 2:0 htb default 13
tc class add dev eth0 parent 2:0 classid 2:1 htb rate 100kbps ceil 100kbps
tc class add dev eth0 parent 2:1 classid 2:12 htb rate 80kbps ceil 100kbps
tc class add dev eth0 parent 2:1 classid 2:13 htb rate 20kbps ceil 100kbps

# O filtro ao final selecionado escolhe a classe a receber o pacote. Esse filtro está vinculado a uma qdisc
# com handle 2:0, e se ativado classifica o datagrama na classe 2:12. O handle do filtro (0x2e) é o resultado do cálculo 
# feito pelo filtro tc_index sobre o campo DSCP ... simples, não ?
tc filter add dev eth0 parent 2:0 protocol ip prio 1 handle 0x2e tcindex classid 2:12 pass_on

... simples, não ???

Usando o iptables: na tabela mangle usa-se o alvo DSCP para marcar os datagramas. Para associar um datagrama a uma classe, de acordo com o valor DSCP, deve-se usar o módulo dscp e os alvos CLASSIFY ou MARK. Ex:

# Uma qdisc HTB com taxa de 100 kBps e duas classes .. apenas para exemplificar o uso do iptables mais abaixo
tc qdisc add dev eth0 root handle handle 1:0 htb default 13
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 100kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 80kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:13 htb rate 20kbps ceil 100kbps

# marca os datagramas vindos da rede 172.18.0.0/16 na classe AF41
iptables -t mangle -A PREROUTING -s 172.18.0.0/16 -j DSCP --set-dscp-class af41

# datagramas da classe DSCP AF41 vão para a classe 1:21 do tc
iptables -t mangle -A FORWARD -m dscp --dscp-class af41 -j CLASSIFY --set-class 1:12

Dicas para o iptables

Uma regra com iptables deve especificar basicamente quatro coisas:

Tabela: a tabela indica a finalidade da regra. No caso do classificador/marcador e também do PHB, deve ser mangle. Essa tabela contém regras que modificam valoers de cabeçalhos de pacotes (no caso, o DSCP).
Chain: em que chain deve ser adicionada.
- No caso do classificador/marcador, deve-se usar a chain PREROUTING (avalia os pacotes antes de serem roteados).
- No caso do PHB, deve-se usar a chain FORWARD (avalia as regras logo após consultar a tabela de rotas).
Seletor: informações a serem usadas para selecionar os pacotes a que ela deve ser aplicada.
Alvo (target): ação a ser executada sobre o pacote que ativar a regra.
- Dependendo do alvo pode haver opções adicionais .

Por exemplo, a regra abaixo marca com o DSCP AF41 os datagramas vindos da rede 172.18.0.0/16:

Desta forma, a escrita das regras depende de conhecer as opções para definição de seletores, e os possíveis alvos. Algumas opções de uso comum para composição de seletores são listadas abaixo, sendo que o que está entre colchetes ([]) é opcional. Um seletor pode ser composto por uma combinação dessas opções. Para mais detalhes leia o manual.

Opção	Descrição	Exemplo
-s IP[/Mascara]	endereço IP de origem	-s 200.135.37.64/26
-d IP[/Mascara]	endereço IP de destino	-d 8.8.8.8
-p Protocolo	protocolo de transporte (tcp ou udp)	-p tcp
--dport numero	Port de destino	--dport 80
--sport numero	Port de origem	--sport 53
--syn	Se flag SYN está acesa (somente TCP)
--tcp-flags Flags1 Flags2	Se somente as flags listadas em Flags1 estão acesas dentre as Flags2	--tcp-flags SYN,ACK,RST,FIN SYN
-i interface	Se pacote foi recebido pela interface	-i eth0
-o interface	Se pacote vai sair pela interface	-o eth1
-m state --state ESTADO	Identifica o estado do fluxo, o qual pode ser: NEW: início de um fluxo ESTABLISHED: parte de um fluxo estabelecido RELATED: inicia um novo fluxo, porém relacionado com um fluxo existente	-m state --state NEW,RELATED

Policiamento de tráfego

O policiamento de tráfego ocorre na recepção de pacotes por um roteador. Essa função é responsável por assegurar que os pacotes estejam dentro de limites definidos para sua classe. Caso um pacote não satisfaça a condição de policiamento, pode ser descartado ou reclassificado como melhor esforço. Assim, evita-se que fluxos com taxas maiores que a contratada entrem no roteador. Porém isso funciona plenamente somente com a qdisc CBQ, que por ser muito complexa não foi estudada aqui. De qualquer forma, filtros com policiamento podem ser usados para limitar tráfego de entrada usando a qdisc especial ingress. Essa qdisc não possui parâmetros, pois seu propósito é somente conter filtros para fins de policiamento. Seu funcionamento é limitado, pois provê apenas duas possibilidades: aceitar ou descartar pacotes.

Exemplo:

# Cria a qdisc ingress
tc qdisc add dev eth0 ingress

# Limita o tráfego de entrada vindo de 172.18.0.0/16 a 100kbps, descartando o que exceder esse limite.
tc filter add dev eth0 parent ffff: protocol ip u32 match ip src 172.18.0.0/16 police rate 100kbps buffer 10k drop flowid :1

Atividade

Um pequeno provedor possui uma rede como mostrado abaixo. Essa rede é usada para interligar seus clientes, no caso as empresas Ajax e Tabajara.

Configuração para o Netkit

B1[type]=gateway
B2[type]=gateway
N1[type]=gateway
Ajax1[type]=generic
Ajax2[type]=generic
Tabajara1[type]=generic
Tabajara2[type]=generic

# Preservando o script que cria as regras de QoS nos roteadores.
# OBS: não esqueça de exportar o projeto do Netkit após terminar a execução da rede ! Ver menu File->Export ...
B1[preserve]=/root/firewall.sh
B2[preserve]=/root/firewall.sh
N1[preserve]=/root/firewall.sh

# Links ...
B1[eth0]=link1:ip=192.168.0.254/24
B1[eth1]=link2:ip=192.168.10.254/24
B1[eth2]=link3:ip=10.0.0.1/28

N1[eth0]=link3:ip=10.0.0.2/28
N1[eth1]=link4:ip=10.0.0.18/28

B2[eth0]=link5:ip=192.168.1.254/24
B2[eth1]=link6:ip=192.168.11.254/24
B2[eth2]=link4:ip=10.0.0.17/28

Ajax1[eth0]=link1:ip=192.168.0.1/24
Ajax2[eth0]=link5:ip=192.168.1.1/24

Tabajara1[eth0]=link2:ip=192.168.10.1/24
Tabajara2[eth0]=link6:ip=192.168.11.1/24

# Rotas ...
Ajax1[default_gateway]=192.168.0.254
Ajax2[default_gateway]=192.168.1.254
Tabajara1[default_gateway]=192.168.10.254
Tabajara2[default_gateway]=192.168.11.254
B1[default_gateway]=10.0.0.2
B2[default_gateway]=10.0.0.18
N1[route]=192.168.0.0/24:gateway=10.0.0.1
N1[route]=192.168.10.0/24:gateway=10.0.0.1
N1[route]=192.168.1.0/24:gateway=10.0.0.17
N1[route]=192.168.11.0/24:gateway=10.0.0.17

Para implantar a estrutura DiffServ, deve-se começar com o seguinte:

i) Os roteadores de borda (B1 e B2) devem ser capazes de marcar, policiar e condicionar os datagramas dos clientes. A marcação deve ser feita de acordo com as classes de serviço escolhidas em cada caso.

ii) O roteador de núcleo (N1) deve ter um PHB capaz de atender tanto classes do tipo Encaminhamento Assegurado (AF) quanto Encaminhamento Acelerado (EF). A diferenciação nesse roteador deve ser feita de acordo com a marcação contida nos datagramas - e que foi realizada nos roteadores de borda.

OBS: os links dentro da rede do provedor estão superdimensionados, portanto não apresentam gargalos.
OBS 2: para medir os atrasos de transmissão pode-se usar este programa. Ele fornece uma estimativa dos atrasos médios, máximo, mínimo e jitter.
OBS 3: a marcação dos datagramas IP deve ser feita via Netfilter, cujas regras devem ser criadas por meio do utilitário iptables. A classificação dos datagramas pode ser feita tanto com iptables quanto com tc.

Tendo a estrutura inicial preparada, resolva os seguintes problemas:

1) O cliente Ajax contratou um link de 1256 kbps, e Tabajara contratou um link de 512 kbps. Em ambos os casos, os links são simétricos. Implemente uma estrutura DiffServ nesse provedor, assumindo que ambos clientes usem classes do tipo Encaminhamento Assegurado (AF).

PARA TESTAR:

Verifique se os pacotes estãop devidamente marcados (isso pode ser feito em N1 usando tcpdump ou wireshark)
Teste se a vazão esperada para dados está sendo obtida. Use o netperf:
```
netperf -f k -H IP_do_outro_computador
```
Teste também chamadas VoIP usando o siprtp.

2) O cliente Ajax precisa usar parte da capacidade contratada para transmitir streams de audio (voz). Assumindo que as streams estarão codificadas com codec PCMU, e que pode haver até 5 streams simultâneas, use a sua estrutura DiffServ para atender essa necessidade.

3) O cliente Tabajara precisa transmitir streams de audio e videoconferência. Assumindo que possam haver até 4 streams de audio simultâneas, codificadas com GSM, e a stream de video use 256 kbps, use a estrutura DiffServ para atender essa demanda.

4) DESAFIO: e se for necessário implementar precedências de descarte para as classes AF ? Por exemplo, dentro da classe AF1 podem existir três precedências de descarte: AF11, AF12 e AF13. A ideia é que, em caso de congestionamento, pacotes marcados com AF13 sejam descartados antes de AF12, e estes sejam descartados antes de AF11. Investigue e demonstre como isso poderia ser feito no Linux (dica: veja a disciplina de filas GRED).

02/06: Diffserv (continuação)

... continuação da atividade da aula anterior. Em particular, deve-se investigar como implementar precedência de descarte para a classe AF.

03/06: Diffserv (conclusão)

Hoje deve-se concluir a implantação de uma estrutura Diffserv na rede de teste. Isso implica:

Especificar e parametrizar os mecanismos de Qos nos roteadores de borda: esses mecanismos devem realizar a classificação, marcação, o condicionamento (shaping) e, por fim, os PHB.
Especificar e parametrizar os mecanismos de Qos nos roteadores de núcleo: esses mecanismos devem realizar os PHB.

Núcleo	Borda

A modelagem dos mecanismos de QoS nos roteadores deve em seguida ser aplicada às questões propostas na aula inicial sobre Diffserv.

TAREFA: Pesquisa sobre mecanismos de QoS em roteadores reais

Para próxima 3a feira (09/06):

Façam uma pesquisa sobre as disciplinas de fila, mecanismos de condicionamento de tráfego e suporte a Diffserv existentes em roteadores e switches de UM dos seguintes fabricantes:

Fabricante	Aluno
Cisco
Extreme Networks (Enterasys)
Alcatel
Juniper
HP/3Com
Huawei
IBM
Avaya
D-Link

... e prepare uma curta apresentação mostrando esses mecanismos, o que são capazes de fazer, que parâmetros são tipicamente necessários para usá-los (ex: taxa média, taxa de pico, peso, prioridade, ...), e como são utilizados para implantar Diffserv nesses roteadores.

OBS: Cada aluno deve escolher um fabricante.

09/06: IntServ: Serviços Integrados na Internet

IntServ: serviços integrados para provimento de QoS fim-a-fim. Nesse modelo, fluxos de pacotes entre um transmissor e um receptor têm seus requisitos de QoS atendidos pela infraestrutura de rede. Para isso, são efetuadas reservas de recursos (largura de banda, priorização) em todos os roteadores ao longo do caminho entre transmissor e um receptor.

IntServ é introduzido pela RFC 1633.

Elementos da arquitetura IntServ:

Especificação de fluxo: define as características de um fluxo e os recursos que ele precisa da rede:
- TSpec (Traffic Specification): especificação de características de um fluxo (gerada pelo transmissor): TokenBucketRate, TokeBucketSize, PeakRate, MinimumPolicedUnit, MaximumPacketSize
- RSpec (Reservation Specification): especificação de características de uma reserva de recursos (gerada pelo receptor). Contém os mesmos parâmetros que TSpec, além de uma classe de serviço (garantida, carga controlada ou melhor-esforço) e um filtro que descreve o fluxo (endereços IP dos pares, ports TCP ou UDP).
RSVP (Resource Reservation Protocol): protocolo de sinalização para negociar reservas de recursos ao longo do caminho a ser usado pelo fluxo.

A sinalização RSVP ocorre em duas etapas:

O transmissor do fluxo envia mensagens PATH para o receptor. Essas mensagens contém a descrição do fluxo (TSpec).
Se aceitar a especificação de fluxo contida na mensagem PATH, o receptor responde com uma mensagem RESV. Essa mensagem especifica a reserva a ser feita ao longo do caminho entre transmissor e receptor (i.e. contém um RSpec) . Cada roteador ao longo do caminho testa se a reserva pode ser satisfeita, e em caso afirmativo propaga a mensagem RESV ao próximo roteador.

Obs: o pedido de reserva feito pelo transmissor (mensagens PATH) deve ocorrer periodicamente. Caso os roteadores ou o receptor fiquem um certo tempo sem receber uma mensagem PATH, as reservas correspondentes são canceladas.
Obs 2: fluxos são unidirecionais, portanto as reservas são feitas também de forma unidirecional.

Segundo um artigo da Cisco, IntServ possui como pontos fortes:

Um tipo de serviço garantido que limita o atraso fim-a-fim e proporciona uma largura de banda para o tráfego que se adequade às especificações da reserva de recursos.
Um tipo de serviço de carga controlada, o qual provê um desempenho superior a melhor esforço, além de um atraso fim-a-fim baixo sob cargas leves ou moderadas na rede.
Possibilidade de proporcionar a qualidade de serviço pedida para cada fluxo na rede, contanto que tenha sido sinalizado usando RSVP e existam recursos disponíveis.

... mas tem também pontos fracos:

Cada equipamento ao longo do caminho de um pacote, incluindo os sistemas finais (ex: PCs e servidores), precisam entender e usar RSVP e serem capazes de sinalizar a QoS pedida.
Reservas de recursos em cada equipamento ao longo do caminho são "brandas", o que significa que precisam ser renovadas periodicamente. Com isso, há um tráfego de sinalização adicional que contribui para o aumento da carga na rede, o qual aumenta a chance de que a reserva expire se os pacotes de renovação forem perdidos.
A manutenção de estados sobre as reservas de recursos em cada roteador, combinada com controle de admissão e uma maior quantidade de memória necessária para suportar um grande número de reservas, aumenta a complexidade de cada nó da rede ao longo do caminho.
Como informação sobre estados para cada reserva precisa ser mantida em todos os roteadores ao longo do caminho, torna-se um desafio manter centenas de milhares de fluxos que passem pelo núcleo da rede.

A seguinte explicação (obtida aqui) aponta outras limitações do Intserv, e comenta sobre sua adoção em redes corporativas e de provedores:

Although IntServ is a straightforward QoS model, end-to-end service guarantees cannot be supported unless all 
nodes along the route support IntServ. This is obviously so because any best-effort node along any route can 
treat packets in such a way that the end-to-end service agreements are violated. In the case of end-end 
implementation of IntServ QoS model, it is recognized by the industry that the support of per-flow guarantees 
in the core of the Internet will pose severe scalability problems. Therefore, scalability is a key 
architectural concern for IntServ, since it requires end-to-end signaling and must maintain a per-flow 
soft state at every router along the path. Other concerns are, how to authorize and prioritize 
reservation requests, and what happens when signaling is not deployed end-to-end. Because of 
these issues, it is generally accepted that IntServ is a better candidate for enterprise 
networks (i.e., for access networks), where user flows can be managed at the desktop user level, 
than for large service provider backbones. A hybrid model (RSVP-DS) that uses RSVP at the edges 
and DiffServ in the backbone has been proposed and seems to be winning consensus as a backbone 
service architecture concept.

TAREFA: Leitura complementar

Leia os dois textos abaixo, e preparem uma breve apresentação para dia 15/06 que explique os conceitos básicos de MPLS-Diffserv e MPLS-TE, e compare-os evidenciando suas características e diferenças.

Leiam até a seção 3.2 (inclusive) deste texto sobre MPLS e Diffserv
Leiam este artigo da Cisco sobre engenharia de tráfego em redes MPLS. Em particular, estude a seção que trata de RSVP-TE, uma versão do protocolo RSVP adaptada para o uso em MPLS.

10/06: Projeto final

O projeto final de RMU trata de adicionar firewalls e mecanismos de QoS a uma rede contendo dois provedores VoIP e seus clientes. Nessa rede os links dos clientes são implantados com ADSL (na verdade, links PPPoE com taxas de downstream de 1 Mbps e upstream de 400 kbps). Há um firewal para cada provedor (fw1 e fw2), e existe um servidor web na LAN do provedor 1. Por fim, para reduzir o tamanho da rede foi retirado o cliente C (que continha o pbxc e fone5).

A rede com os PBX, telefones IP, e links PPPoE

As modificações a serem feitas nessa rede devem atender o seguinte:

Os diferentes tipos de tráfego devem ter seus requisitos de QoS atendidos:
As comunicações dos usuários devem ser policiadas:

A turma deve se dividir em equipes de até 02 alunos.

Prazo de entrega: 03/07

Detalhamento

O trabalho deve ser feito usando o Netkit2 (versão 2.15 ou superior).

Arquivo de projeto do Netkit para o projeto
OBS: Os links PPPoE entre AC e os Firewalls têm taxa de downstream de 1 Mbps, e de upstream de 400 kbps. Isso já está implantado na configuração do experimento.
Obs 2: o Asterisk pode ser iniciado automaticamente no boot. Isso foi explorado na configuração do projeto. Além do Asterisk, são iniciados automaticamente os servidores SSH nos firewalls, e o Apache em web.

Requisitos:

As redes dos clientes usam NAT para acessar a rede WAN. A rede do provedor usa IPs públicos.
Por default, tudo está bloqueado.
Chamadas VoIP têm prioridade a todos demais tipos de tráfego, porém limitadas a até duas chamadas VoIP simultâneas. Essa limitação deve ser imposta pelos provedores. Os recursos da rede necessários a essas chamadas devem ser garantidos pela rede.
O servidor web do provedor pode ser acessado da Internet para serviço Web (protocolos HTTP e HTTPS nas portas padrões).
Firewalls dos clientes (r1 e r2) e dos provedores (fw1 e fw2) podem ser acessados da Internet com SSH.
Usuários das redes da empresa podem acessar qualquer serviço da Internet baseado em TCP. Serviços baseados em UDP não são permitidos.
Os firewalls rodam servidores DNS, e assim os usuários das redes da empresa somente podem fazer consultas DNS nos Firewalls.
A implantação de um domínio Diffserv é obrigatória na rede WAN (incluindo os roteadores de borda dos clientes e provedores VoIP).
O tráfego para Internet deve ser do tipo melhor esforço.
A rede WAN pode opcionalmente usar roteamento dinâmico (ex: OSPF).

NAT e Asterisk

O NAT exige algumas configurações especiais para o Asterisk, do contrário as chamadas não funcionam (principalmente o que diz respeito ao RTP).

Nat e Asterisk

16/06: Projeto final

Exemplo de uso da interface imq

A interface imq serve para usar qdisc globalmente em um roteador (aplicável a pacotes a serem encaminhados a diferentes interfaces de rede de saída), ou para encadear qdisc (ex: condicionamento E depois priorização). Um exemplo simplificado de seu uso é mostrado a seguir.

A rede de demonstração tem esta topologia. Há um único roteador (r1), onde serão usadas qdisc e a interface imq.

As qdisc são associadas às interfaces desse roteador da seguinte forma:

Por fim, as regras que criam as qdisc são mostradas a seguir:

#!/bin/bash

# cria a interface imq0
ip link set imq0 up 2>/dev/null

# remove qdisc que porventura existam nas interfaces imq0, eth0 e eth1
tc qdisc del dev imq0 root
tc qdisc del dev eth0 root
tc qdisc del dev eth1 root

# adiciona uma qdisc HTB à interface imq0
tc qdisc add dev imq0 root handle 1: htb default 10
tc class add dev imq0 parent 1: classid 1:1 htb rate 256kbit ceil 256kbit
tc class add dev imq0 parent 1:1 classid 1:10 htb rate 192kbit ceil 256kbit
tc class add dev imq0 parent 1:1 classid 1:11 htb rate 64kbit ceil 256kbit

# adiciona qdisc prio às interfaces eth0 e eth1
tc qdisc add dev eth1 root handle 1: prio
tc qdisc add dev eth0 root handle 1: prio

# cria filtros na interface imq0 para classificar os pacotes
# isso faz com que segmentos TCP vão para a classe 1:10 e
# datagramas UDP vão para a classe 1:11
tc filter add dev imq0 parent 1:0 protocol ip prio 1 u32 match \
		ip protocol 17 0xff flowid 1:11
tc filter add dev imq0 parent 1:0 protocol ip prio 1 u32 match \
		ip protocol 6 0xff flowid 1:10

# faz com que pacotes que entrem pelas interfaces eth0 e eth1 sejam movidos para
# a interface imq0
iptables -t mangle -A PREROUTING -i eth0 -j IMQ --todev 0
iptables -t mangle -A PREROUTING -i eth1 -j IMQ --todev 0

# após o encaminhamento IP (que ocorre após a saída da imq0),
# classifica os pacotes para as classes da qdisc prio nas interfaces
# eth0 e eth1
iptables -t mangle -A POSTROUTING -p udp -j CLASSIFY --set-class 1:1
iptables -t mangle -A POSTROUTING ! -p udp -j CLASSIFY --set-class 1:2

23/06: Tecnologias para redes multimidia

Hoje será apresentada uma introdução à diferenciação de tráfego em redes IEEE 802.11. Isso envolve selecionar diferentes valores para DIFS (duração de intervalo entre quadros), Cwmin e Cwmax (respectivamente, menor e maior tamando de janela de disputa), de acordo com a especificação do suporte a QoS no padrão IEEE 802.11. Para uma boa visão geral do assunto, ler este texto da Cisco.

Atividade

O suporte a diferenciação de quadros (ou fluxos) em redes IEEE 802.11 será investigado por meio de um experimento. Diferentes fluxos serão gerados, e suas vazões serão medidas e plotadas em gráficos.

Experimento 1: fluxo prioritário em um único computador

Neste primeiro experimento, um computador deve receber e enviar um fluxo com maior prioridade, enquanto os demais geram fluxos de baixa prioridade. O fluxo mais prioritário usará a classe de acesso VO do WMM, a qual é selecionada pelo device driver da interface de rede (e pelo AP) para os datagramas IP com campo DSCP contendo o codepoint EF (0x2E). Os fluxos de baixa prioridade usarão o valor de DSCP Default (00). Os fluxos devem ser gerados com a ferramenta iperf.

No computador com o fluxo prioritário, deve-se definir o valor do campo DSCP para os datagramas:

# regra para fluxo gerado no computador
sudo iptables -t mangle -A OUTPUT -o wlan0 -p tcp --dport 5555 -j DSCP --set-dscp-class ef

# regra gerada para fluxo recebido no computador
sudo iptables -t mangle -A OUTPUT -o wlan0 -p tcp --sport 5555 -j DSCP --set-dscp-class ef

Nos demais computadores, não é necessário definir o valor DSCP. Isso automaticamente faz com que seus datagramas sejam classificados como classe Default.
A execução do iperf nos computadores deve ser sincronizada. Preparem-se para executá-lo como indicado a seguir, mas esperem o sinal do professor para iniciar a execução:
- No computador com fluxo prioritário, deve-se executar o iperf da seguinte maneira:
```
iperf -i 1 -t 60 -p 5555 -c 192.168.4.34 2>&1 > iperf.log
```
- Nos demais computadores, deve-se executar o iperf da seguinte maneira (XX é o número do computador no laboratório):
```
iperf -i 1 -t 60 -p 44XX -c 192.168.4.34 2>&1 > iperf.log
```
Após o término do iperf, os arquivos iperf.log devem ser entregues ao professor para que se possa criar um gráfico da vazão obtida ao longo do tempo pelos diferentes fluxos.
No experimento realizado, os fluxos fluiram dos computadores para o micro do professor. Agora vamos medir os fluxos no sentido contrário.
- No computador com fluxo prioritário, deve-se executar o iperf da seguinte maneira:
```
iperf -i 1 -t 60 -p 5555 -s 2>&1 > iperf2.log
```
- Nos demais computadores, deve-se executar o iperf da seguinte maneira (XX é o número do computador no laboratório):
```
iperf -i 1 -t 60 -p 4444 -s 2>&1 > iperf2.log
```
O professor iniciará o iperf em seu computador, de forma a gerar fluxos em direção aos computadores da rede sem-fio. Ao final da execução, os arquivos iperf2.log devem ser entregues para que se possa gerar um novo gráfico.

Experimento 2: fluxos prioritário e melhor esforço em todos computadores

Neste experimento, todos computadores recebem e enviam fluxos prioritários e melhor esforço de forma concorrente. Assim pode-se avaliar as vazões dos fluxos prioritários e dos fluxos melhor esforço quando ambos competem pelo uso da rede.

Em todos computadores deve-se definir o valor do campo DSCP para os datagramas (XX 'o número do computador):

# regra para fluxo gerado no computador
sudo iptables -t mangle -o OUTPUT -p wlan0 -p tcp -dport 55XX -j DSCP --set-dscp-class ef

# regra gerada para fluxo recebido no computador
sudo iptables -t mangle -o OUTPUT -p wlan0 -p tcp -sport 5555 -j DSCP --set-dscp-class ef

A execução do iperf nos computadores deve ser sincronizada. Preparem-se para executá-lo como indicado a seguir, mas esperem o sinal do professor para iniciar a execução:
- Abra duas telas de terminal em seu computador.
- Em uma das telas gera-se um fluxo prioritário:
```
iperf -i 1 -t 60 -p 55XX -c 192.168.4.34 2>&1 > iperf3.log
```
- Na outra tela gera-se um fluxo melhor esforço:
```
iperf -i 1 -t 60 -p 44XX -c 192.168.4.34 2>&1 > iperf4.log
```
Após o término do iperf, os arquivos iperf3.log e iperf4.log devem ser entregues ao professor para que se possa criar um gráfico da vazão obtida ao longo do tempo pelos diferentes fluxos.
No experimento realizado, os fluxos fluiram dos computadores para o micro do professor. Agora vamos medir os fluxos no sentido contrário.
- Em uma das telas deve-se esperar por um fluxo prioritário:
```
iperf -i 1 -t 60 -p 5555 -s 2>&1 > iperf5.log
```
- Na outra tela deve-se esperar por um fluxo melhor esforço:
```
iperf -i 1 -t 60 -p 4444 -s 2>&1 > iperf6.log
```
O professor iniciará o iperf em seu computador, de forma a gerar fluxos em direção aos computadores da rede sem-fio. Ao final da execução, os arquivos iperf5.log e iperf6.log devem ser entregues para que se possa gerar um novo gráfico.

Curiosidade: como mudar a prioridade dos fluxos de uma aplicação em particular

Especificar o valor do campo DSCP pode não ser prático. Isso envolve ter que criar regras com iptables para mudar o campo DSCP de datagramas, de acordo com alguma de suas características (ex: port). Porém uma aplicação pode especificar a prioridade dos datagramas por ela gerados. Pesquise como isso pode ser feito ...

RMU-2015-1

Redes Multimidia: Diário de Aula 2015-1

Bibliografia

Curiosidades

Listas de exercícios

Avaliações

Softwares

04/02: Apresentação

Redes multimidia

Atividade: compartilhando video pela rede

Exemplo 1: video streaming

Exemplo 2: Internet radio

TAREFA: leitura da semana

10/02: Apresentação do Projeto 1

Atividade

11/02: Início do projeto 1; transmissão de video

Formatos de video

24/02: Compressão de video

25/02: Compressão de video

Atividade

03/03: Caracterização de midias

Compressão de audio

Atividade

Transmissão de dados multimidia

Componentes do atraso fim-a-fim

04/03: Estratégias para tratar a variação de atraso

Atraso de reprodução fixo

Atraso de reprodução adaptativo

Exercícios

Atividade: atraso de reprodução

Estratégias para abrandar a perda de mensagens

Correção antecipada de erros

Intercalação

Atividade

TAREFA: pesquisa sobre modelos e mecanismos de distribuição de midia

Lista de exercícios

10/03: Projeto 1: conclusão

11/03: Projeto 2: um serviço de videophone usando a rede de computadores

Tarefa 1: definição da arquitetura do sistema

Introdução a Voz sobre IP (VoIP)

O protocolo SIP

Mensagens SIP

Diagramas de chamadas

Registro de agente SIP em um proxy SIP

Chamada direta entre dois agentes SIP

Chamada entre dois agentes SIP com intermediação de um Proxy SIP

Chamada entre dois agentes SIP com intermediação de um gateway de media

Chamada entre dois agentes SIP com intermediação de um gateway de media e uso de re-INVITE

Atividade 1: Ligação SIP ponto a ponto

17/03 e 18/03: Projeto 2: o PBX

Asterisk

Plano de discagem

Canais SIP

Atividade: fazendo chamadas por meio do Asterisk

Como testar as chamadas

24 e 25/03: Investigando os protocolos envolvidos nas chamadas

Sinalização com SIP

Chamada entre dois agentes SIP com intermediação de um gateway de media

Chamada entre dois agentes SIP com intermediação de um gateway de media e uso de re-INVITE

Atividade

31/03: Projeto 2: continuação e RTP

O transporte de midia com protocolo RTP

RTCP

Atividade

VoIP com SIP e NAT

01/04: Projeto 2: fazendo chamadas entre os PBX das equipes

Interligando PBX Asterisk por meio de troncos SIP ou IAX2

Tronco SIP

Atividade: estabelecendo chamadas entre diferentes PBX Asterisk

07, 08 e 14/04: Projeto 2: entrocamentos SIP e segurança

Chamadas seguras

Criação de certificados

Leitura complementar

15/04: Avaliação 1

22/04: Projeto 2: conclusão; correção da avaliação

28/04: Apresentação do projeto 2

29/04: Conclusão do projeto 2

04/05: Introdução à qualidade de serviço (Qos)

Uma pequena experiência

Uma outra experiência