RMU-2015-1

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.

Avaliações

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

Softwares

• Opnet - simulador de rede
• Netkit2: emulador de redes com máquinas virtuais Linux (UML)

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:

1. Como funcionam esses serviços ? Como os conteúdos são acessados ?
2. Como os dados são representados ?
3. Como os dados são transportados através da rede ? Quais os protocolos envolvidos e como os dados são encapsulados em suas PDUs ?
4. 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:

• Netflix consome 35% de todo o tráfego Internet nos EUA
• Netflix e Youbute são os maiores geradores de tráfego nos EUA
• Tráfego total VoIP na Internet

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

• Popcorn Time
• VLC
• Darwin Streaming Server
• Kom(s) Streaming Server
• Live555 Media Server

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:

• Youtube
• phpmotion
• Netflix
  • Netflix revelado
• Popcorn Time
  • Características do Popcorn Time
• VLC
• Darwin Streaming Server
• Live555 Media Server
• Apple Quicktime Streaming Server

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	Características de armazenamento	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:

• WMV
• AVI
  • Outro texto sobre AVI
• MPEG4
• Matroska (mkv)

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

• Compressão com MPEG-2
• Introdução a MPEG-2
• Compressão de audio e video
• Formatos de containers de video (arquivos de video)
• Uma boa introdução sobre codecs e containers 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

• Compressão com MP3
• Compressão com Ogg
• FLAC
• Speex

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:

1. Visualize um video usando o mplayer:

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

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

1. Qual deveria ser o atraso de reprodução mínimo, em cada caso, para que o video pudesse ser reproduzido sem perdas ?
2. 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:

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

Introdução a Voz sobre IP (VoIP)

• Transparências
• Introdução a VoIP e SIP
• RFC 3261: Session Initiation Protocol (SIP)
• Tecnologias VoIP para smartphones
• QoS for VoIP (Cisco)
• QoS for VoIP (voip-info)
• ITU-T G.114: One Way Transmission Time
• SIP: Understanding the Session Initiation Protocol, 3rd ed (muito bom livro) ... (cópia online)
• Mensagens, Transações, Diálogos e Chamadas SIP

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:

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

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

Questões:

1. Quem foram o UAC e UAS nesse experimento ?
2. Quantas requisições SIP foram realizadas para uma chamada completa ?
3. Quantas mensagens, transações, diálogos e chamadas foram realizadas ?
4. Como a voz digitalizada foi transportada ? Foi usado algum protocolo em especial ?
5. Qual o CODEC selecionado por cada parte? Onde isso foi feito ?
6. 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.

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

1. Crie um plano de discagem em que todos podem fazer chamadas para todos. Isso implica haver um único contexto para os canais SIP.
2. 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
     

3. Adicione uma conta a cada softphone. Use as contas criadas no ítem 1.
4. 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.
5. Execute o wireshark, e ponha-o em modo de captura em todas as interfaces (pseudo-interface any).
6. Repita a chamada de um softphone a outro. No softphone destino atenda a chamada, e alguns segundos depois encerre-a.
7. 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.
8. 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:

1. Que papel desempenhou o Asterisk para os softphones ? UAS, UAC ou algo diferente ?
2. Entre que agentes ocorreram os diálogos identificados ?
3. A stream de audio seguiu o mesmo caminho que a sinalização SIP ?
4. 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.

1. 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).
2. 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]
   

3. 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).
4. 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:

1. Chamada com intermediação de gateway de midia
2. 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:

1. Estabeleça uma chamada VoIP entre dois softphones usando o Asterisk como intermediário.
2. Execute o wireshark no computador onde roda o Asterisk, e ative a captura de datagramas UDP.
3. 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.
4. Estime o jitter durante a recepção de ao menos 15 segundos de audio.
5. 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.

1. 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.
2. 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

• Introdução à Segurança
• Introdução à Segurança: criptografia
• Introdução à Segurança: certificação digital
• Introdução à Segurança: SSL e TLS
• Segurança em SIP

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

1. O que é necessário para ativar essas modalidades de chamadas ?
2. 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

• Um tutorial sobre comandos comuns do software Openssl
• Openssl Cookbook
• Preços e características de certificados digitais emitidos por diferentes autoridades certificadoras
• Uso de certificado cliente pelo jitsi ... meio trabalhoso ;-)

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

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

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

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

4. Mostrar o conteúdo de um certificado:

   openssl x509 -in cert.crt -text
   

5. Converter certificado para formato PEM:

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

6. 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:

• ENUM na wikipedia
• ENUM: The Collision of Telephony and DNS Policy

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:

1. Exercicios de fixação: 1, 2, 4, 5, 6, 7, 9, 10, 11, 12
2. 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:

• 2011-2
• 2011-2 (recuperação)
• 2012-1 (recuperação)
• 2012-2