Mudanças entre as edições de "Redes Multimídia (diário 2014-1)"
(→28/05) |
(→28/05) |
||
Linha 504: | Linha 504: | ||
} | } | ||
</graphviz></center> | </graphviz></center> | ||
− | Configuração: | + | Configuração de roteamento baseada na RFC 4861, seção 8: |
* Terminal A: | * Terminal A: | ||
<syntaxhighlight lang=bash> | <syntaxhighlight lang=bash> |
Edição das 11h51min de 28 de maio de 2014
Endereço encurtado desta página: http://bit.ly/rmu20141
Sobre a disciplina
Metodologia
Metodologia orientada a projeto, sendo esse o desenvolvimento de uma solução de comunicação segura entre diversos nós espalhados pela Internet. Será usado, para tal, um concentrador que atuará como autenticador e ponto de integração com outras redes. A comunicação entre os nós poderá ser intermediada pelo concentrador ou mesmo direta entre os terminais. É obrigatória a segurança de todos os dados trafegados (sinalização e transmissão de mídia). A qualidade de serviço será necessária, seja intra-rede ou entre redes locais conectadas à Internet. Como o IFSC será uma dessas redes locais, o uso de IPv6 será necessário - tendo assim pilha dupla de operação. Novas tecnologias serão contempladas, como WebRTC e novos codecs projetados para redes IP.
Ferramentas
- Este diário de bordo.
- Netkit.
- Repositório dos arquivos do Netkit:
- Controle de versão com Git via HTTPS: https://tele.sj.ifsc.edu.br/projetos/rmu20141.
- Credenciais: acesso anônimo para cópia (leitura) do repositório, acesso autenticado para escrita mediante solicitação.
Avaliação
- Serão realizadas avaliações por temática/projeto em sala.
- Para aprovação: no máximo 2 Ds, e para cada D um A correspondente. Exceção: para o último projeto o conceito mínimo deve ser C.
Aulas
Apresentação da disciplina e oportunidades
10/02
- Apresentação da disciplina: metodologia e avaliação.
12/02
- Definição da metodologia e escopo do problema: a rede de comunicação.
17/02
Não houve aula.
19/02
Com a possibilidade de troca de professor da disciplina, foi tratado um tema relevante: o mercado de trabalho de Telecomunicações na Grande Florianópolis.
Sinalização
24/02
- Estudo de caso: Dropbox e transmissão de vídeo para várias plataformas.
- Telefona IP, sinalização, H.323, SIP e XMPP com a extensão Jingle.
- Material de apoio.
- Convidado(?): Carlos Eduardo Wagner.
26/02
- O protocolo SIP - RFC 3261.
10/03
- SIP, intracentral.
- Um cenário possível para o experimento:
- Geral
global[compact]=False
global[mem]=64
global[vm]=4
global[clean]=False
global[path]=/tmp/rmu20141/cenario0/lab
- Roteador
rt0[type]=router
- Rede 0
- Equipamentos
r0sw0[type]=switch
r0pbx0[type]=pbx
r0pc0[type]=generic
r0pc1[type]=generic
- Enlaces intra-rede
r0sw0[eth0]=p00
rt0[eth0]=p00:ip=192.168.0.254/24
r0sw0[eth1]=p01
r0pbx0[eth0]=p01:ip=192.168.0.1/24
r0sw0[eth2]=p02
r0pc0[eth0]=p02:ip=192.168.0.100/24
r0sw0[eth3]=p03
r0pc1[eth0]=p03:ip=192.168.0.101/24
- Rotas
r0pbx0[default_gateway]=192.168.0.254
r0pc0[default_gateway]=192.168.0.254
r0pc1[default_gateway]=192.168.0.254
- Arquivos a salvar
r0pbx0[preserve]=/usr/local/asterisk/etc/asterisk/sip.conf:/usr/local/asterisk/etc/asterisk/extensions.conf
r0pc0[preserve]=/root/pjsua.cfg:/root/chopin.wav
r0pc1[preserve]=/root/pjsua.cfg:/root/chopin.wav
- Rede 1
- Equipamentos
r1sw0[type]=switch
r1pbx0[type]=pbx
r1pc0[type]=generic
r1pc1[type]=generic
- Enlaces intra-rede
r1sw0[eth0]=p10
rt0[eth1]=p10:ip=192.168.1.254/24
r1sw0[eth1]=p11
r1pbx0[eth0]=p11:ip=192.168.1.1/24
r1sw0[eth2]=p12
r1pc0[eth0]=p12:ip=192.168.1.100/24
r1sw0[eth3]=p13
r1pc1[eth0]=p13:ip=192.168.1.101/24
- Rotas
r1pbx0[default_gateway]=192.168.1.254
r1pc0[default_gateway]=192.168.1.254
r1pc1[default_gateway]=192.168.1.254
- Arquivos a salvar
r1pbx0[preserve]=/usr/local/asterisk/etc/asterisk/sip.conf:/usr/local/asterisk/etc/asterisk/extensions.conf
r1pc0[preserve]=/root/pjsua.cfg:/root/debussy.wav
r1pc1[preserve]=/root/pjsua.cfg:/root/debussy.wav
</syntaxhighlight>
Experimentos
Ligação direta entre terminais
Foi utilizado o aplicativo siprtp em ambos os terminais:
- Terminal 0, r0pc0 (192.168.0.100), que operará como UAS:
siprtp -i 192.168.0.100
</syntaxhighlight>
- Terminal 1, r0pc1 (192.168.0.101), que operará como UAC:
siprtp -i 192.168.0.101 sip:192.168.0.100
</syntaxhighlight>
Ligação intermediada por SIP Registrar/Proxy
Foi utilizado o aplicativo pjsua nos terminais e Asterisk no servidor:
- Servidor r0pbx0 (192.168.0.1) como SIP Registrar e Proxy. Foram configurados duas contas SIP no arquivos /etc/asterisk/sip.conf:
[100]
type=friend ; ambos os sentidos
host=dynamic
defaultuser=100
context=rmu20141
canreinvite=no
[101]
type=friend
host=dynamic
defaultuser=101
context=rmu20141
canreinvite=no
</syntaxhighlight>
- E no arquivo /etc/asterisk/extensions.conf o plano de discagem:
[rmu20141]
exten => _1XX,1,Dial(SIP/${EXTEN})
exten => _1XX,n,Hangup()
</syntaxhighlight>
- Ainda no mesmo servidor, foi iniciado o serviço e verificadas as configurações (quem pode ligar, peers, e quem pode receber, users):
asterisk -c
sip show peers
sip show users
dialplan show rmu20141
</syntaxhighlight>
- Depois, foi configurada a primeira conta (100) no terminal r0pc0, no arquivos /root/pjsua.cfg:
--registrar sip:192.168.0.1
--proxy sip:192.168.0.1;lr
--realm *
--id sip:100@192.168.0.1
--username 100
--local-port 5060
--null-audio
</syntaxhighlight>
- O mesmo foi feito para a segunda conta (101), em r0pc1 (mesmo arquivo):
--registrar sip:192.168.0.1
--proxy sip:192.168.0.1;lr
--realm *
--id sip:101@192.168.0.1
--username 101
--local-port 5060
--null-audio
</syntaxhighlight>
- Para acompanhar o registro, foi ativada a depuração de mensagens SIP no servidor (na CLI do Asterisk):
sip set debug on
</syntaxhighlight>
- E, em cada terminal (r0pc0 e r0pc1), foi executado o comando que inicia o registro das contas SIP:
pjsua --config-file=/root/pjsua.cfg
</syntaxhighlight>
Por fim, faltou apenas iniciar uma chamada telefônica.
12/03
- SIP, aplicação em sala de ligação intracentral.
17/03
- SIP, intercentrais e modelo hierárquico e federado (com DNS).
- Adicionada a ferramenta de controle de versão dos arquivos.
24/03
Entrega: sinalização com SIP. A seguir, o roteiro.
- Em cada VM, iniciar o monitor de rede tshark (onde <maquina> é o nome da VM):
tshark -i eth0 -f "udp" -w /tmp/<maquina>.pcap &
</syntaxhighlight>
- Realizar a ligação entre: r0pc0 e r1pc1 (r0pc0-r0pbx0-r1pbx0-r1pc1) e r1pc0 e r0pc1 (r1pc0-r1pbx0-r0px0-r0pc1).
- Encerrar as ligações.
- Encerrar o monitor de rede. Em cada VM:
killall -TERM tshark
sleep 2
killall -KILL tshark
</syntaxhighlight>
- Copiar os arquivos gerados (*.pcap) para a máquina virtualizadora. O diretório /hostlab da VM se refere ao diretório lab da máquina real. Em cada VM (onde <maquina> é o nome da VM):
cp /tmp/<maquina>.pcap /hostlab/
</syntaxhighlight>
- Enviar, por email os 6 (seis) arquivos .pcap:
- lab/r0pc0.pcap
- lab/r0pc1.pcap
- lab/r0pbx0.pcap
- lab/r1pc0.pcap
- lab/r1pc1.pcap
- lab/r1pbx0.pcap
Descrição de Mídia
26/03
- Estudo de caso: Skype e o codec SILK.
- Descrição de mídia, SIP/SDP, codecs.
31/03
- SIP com SDP, definição de codecs. Roteiro utilizado a seguir.
- Configuração para a colagem do repositório Git:
cat > ${HOME}/.gitconfig << EOF
[http]
sslVerify = no
EOF
cd /tmp/
git clone https://tele.sj.ifsc.edu.br/projetos/rmu20141
cd rmu20141/cenario0
~/netkit/bin/gnome-netkit
- Em cada VM:
tshark -i eth0 -f udp -w /tmp/MAQUINA.pcap -q &
- Somente nos PBXs:
/usr/local/asterisk/sbin/asterisk -c
- Somente nos terminais:
pjsua --config-file=pjsua.cfg
- Em r0pc0 ligar para D (r1pc1):
m
sip:0101@192.168.0.1
- Em r0pc0 verificar a qualidade da ligação:
dq
- Em r1pc1 atender a ligação:
a
200
- Em r1pc1 verificar a qualidade da ligação:
dq
- Em r0pc0 parar o processo pjsua, copiar o arquivo e retomar o mesmo:
Ctrl + z
cp /tmp/r0pc0.pcap /hostlab/
fg
- O mesmo em r1pc1:
Ctrl + z
cp /tmp/r0pc0.pcap /hostlab/
fg
- Na máquina virtualizadora:
wireshark /tmp/rmu20141/cenario0/lab/r0pc0.pcap &
wireshark /tmp/rmu20141/cenario0/lab/r1pc1.pcap &
- Nos PBXs parar o processo Asterisk, editar os codecs e retomar o mesmo:
Ctrl + z
cat > /etc/asterisk/sip.conf << EOF
[100]
disallow=all
allow=alaw
[101]
disallow=all
allow=alaw
[r0pbx0-r1pbx0]
disallow=all
allow=alaw
[r1pbx0-r0pbx0]
disallow=all
allow=alaw
EOF
fg
sip reload
- Em r0pc0 desligar a atual ligação e ligar para D, verificando posteriormente a qualidade da ligação:
h
m
sip:0101@192.168.0.1
dq
- Em r1pc1 atender a ligação:
a
200
dq
- Em r0pc0 copiar a captura de rede:
Ctrl + z
cp /tmp/r0pc0.pcap /hostlab/
fg
- Em r1pc1 idem:
Ctrl + z
cp /tmp/r1pc1.pcap /hostlab/
fg
02/04
Entrega: codecs personalizados por canal/tronco.
- Configurar o ambiente para clonar o repositório git com as configurações vistas em aula:
cat > $HOME/.gitconfig << EOF
[http]
sslVerify=no
EOF
- Para evitar sobreposição de arquivos, e como o git é um DCVS, é fortemente recomendado o seu uso no diretório /tmp:
cd /tmp
rm -rf rmu20141
git clone https://tele.sj.ifsc.edu.br/projetos/rmu20141
cd rmu20141/cenario0
gnome-netkit
e abrir o laboratório /tmp/rmu20141/cenario0/lab.conf.
- Rodar os casos de ligações entre A-M-N-D e C-N-M-B (8 no total):
- As ligações são estabelecidas utilizando apenas G711 lei A (alaw); ou seja, em ambos os sentidos em cada ligação.
- As ligações são estabelecidas utilizando apenas GSM (gsm).
- As ligações não podem ser estabelecidas por incompatibilidade de codec.
- As ligações podem ser estabelecidas porque há um 'gateway' de mídia; ou seja, a transcodificação é necessária - em ambos os sentidos.
Dicas: o que ajuda no Asterisk de comando:
core show translation
core show channels
core show channel (nome do canal)
Transmissão de Mídia
07/04
- Estudo de caso: Há quase 10 anos, já se falava em compartilhamento e controle remoto de tela com RTP.
- Transmissão de mídia, RTP/RTcP.
09/04
- Transmissão de mídia, RTP/RTcP.
14/04
- Transmissão de mídia, RTP/RTcP.
16/04
- Transmissão de mídia, RTP/RTcP.
- Mudado o cenário: agora são dois roteadores com enlace PPP, com taxa de transmissão limitada, interligando-os (commit 0674122088242986472548f6bdf05dcef8fa777f do repositório).
- Nota: o antigo está disponível no repositório (versões antigas) ou em arquivo compactado.
23/04
Entrega 3 com 3 casos:
- 1 ligação sem perdas.
- Perda em 1 ligação (enlace PPP com taxa de transmissão insuficiente, provavelmente 56Kbps).
- Perda a partir da 2a. ligação concorrente e latência aumentada para 200ms no enlace PPP.
Exemplo de configuração do ambiente: versão c2e43743718c84fb1dc7818440f27d6d3457f269 do repositório.
Qualidade de Serviço
28/04
- Estudo de caso: Implementando qualidade de serviço para VoIP usando Cisco.
- Qualidade de serviço.
Leituras sugeridas para próxima aula
Recomendável, mas não obrigatório, pode-se ler também a RFC do TOS (Type Of Service)
30/04
- Classificação, marcação, política e aplicação (inclui shaping).
- TOS e DSCP e 802.1p.
- Atividade do dia: definir 3 casos de qualidade de serviço:
- Somente nas redes locais;
- Somente nos roteadores;
- Entre redes.
Para as próximas aulas: como implementar em cada caso:
- Como classificar o tráfego (e que tráfego)?
- Como marcar pacotes?
- Como definir e implantar políticas?
- Como verificar se descarte ou atraso estão, de fato, acontecendo?
05/05
- Filas e priorização em redes sem QoS.
- Entrega: ambiente com e sem protocolo de QoS.
- Leitura: RFC 2475, RFC 2474 e RFC 2460.
- A verificar: sala de conferência do servidor de Tele.
IP e Qualidade de Serviço
07/05
- Estatíticas de uso (Cisco): http://6lab.cisco.com/stats/
- IPv4, NAT, STUN, ICE, túneis (seguros ou não).
- 802.1p.
12/05
- IPv4, NAT, STUN, ICE, túneis (seguros ou não).
- TOS e DSCP.
- RFC 4594.
- Material de referência: http://eriberto.pro.br/wiki/index.php?title=Controle_de_tráfego_com_TC%2C_HTB_e_Iptables
Segue definições feitas em sala hoje.
1-Sinalização:
- 0 à 10Kbps.
- Perda zero.
- Latência boa.
- Prioridade máxima.
2-Transmissão:
- 100 à 500Kbps.
- Perda tendendo a zero.
- Latência baixa.
- Prioridade zero.
3-Demais:
- Resto da taxa de transmissão.
- Perda aceitável.
- Latência suficiente.
- Prioridade baixa.
14/05
- IPv6.
- Traffic class.
19/05
- IPv6.
- Traffic class.
21/05
- IPv6.
- Entrega: ligação entre canais com terminações IPv4 e IPv6.
- ATUALIZAÇÃO: problemas com a versão do Quagga no Netkit original (0.99.11, quando deveria ser 0.99.18+). A entrega, assim, será em duas etapas: configuração hoje e funcionalidade na próxima semana.
- ATUALIZAÇÃO 2: como o serialemu consome mais recursos que o enlace Ethernet convencional, e requer endereço inicial para ativar a interface, serão utilizados enlaces Ethernet entre os roteadores.
26/05
- Roteamento dinâmico com OSPF.
- Comandos úteis para o processo ospfd do Quagga:
ps aux | grep zebra
ps aux | grep ospfd
telnet localhost 2604
> show ip ospf neighbor
> show ip ospf interface eth0
> show ip ospf area 0.0.0.0 spf tree
> show ip ospf route
> show ip ospf database
</syntaxhighlight>
28/05
- IPv6: endereçamento, endereços reservados (RFC 4291, resumido pela RIPE.net), roteamento.
Exemplo de configuração do nosso cenário:
<graphviz>
graph IPv6 {
A [shape=record,label="<0>Terminal A|<1>eth0"]
B [shape=record,label="<0>Roteador B|<1>eth0|<2>eth1"]
C [shape=record,label="<0>Roteador C|<1>eth0|<2>eth1"]
D [shape=record,label="<0>Terminal D|<1>eth0"]
A:1 -- B:1 [label="2804:1454::/64"]
B:2 -- C:1 [label="2804:1454:0:1::/64"]
C:2 -- D:1 [label="2804:1454:0:2::/64"]
}
</graphviz>
Configuração de roteamento baseada na RFC 4861, seção 8:
- Terminal A:
ip -6 addr add 2804:1454::1/64 dev eth0
ip -6 route add 2804:1454:0:1::/64 via <B:eth0 link-local> #B-C
ip -6 route add 2804:1454:0:2::/64 via <B:eth0 link-local> #C-D
- Roteador B:
ip -6 addr add 2804:1454::2/64 dev eth0
ip -6 addr add 2804:1454:0:1::1/64 dev eth1
ip -6 route add 2804:1454:0:2::/64 via <C:eth0 link-local> #C-D
sysctl -w net.ipv6.conf.all.forwarding=1
- Roteador C:
ip -6 addr add 2804:1454:0.2::2/64 dev eth0
ip -6 addr add 2804:1454:0:2::1/64 dev eth1
ip -6 route add 2804:1454::/64 via <B:eth1 link-local> #A-B
sysctl -w net.ipv6.conf.all.forwarding=1
- Terminal D:
ip -6 addr add 2804:1454:0:2::2/64 dev eth0
ip -6 route add 2804:1454::/64 via <C:eth1 link-local> #A-B
ip -6 route add 2804:1454:0:1::/64 via <C:eth1 link-local> #B-C
Para visualizar a tabela de roteamento:
- No OSPF6d (via telnet ::1 2606): show ipv6 ospf6 route
- No Zebra (via telnet localhost 2601): show ipv6 route
- No Linux (CLI): ip -6 route show
Segurança
02/06
- Estudo de Google Hangouts.
- Criptografia.
- SSL, TLS, SIP com TLS.
04/06
- SRTP e zRTP.
09/06
- Criptografia opcional e obrigatório.
- Entrega: sinalização e mídia criptografados sob demanda, opcional e obrigatório.
11/06
- Entrega: criptografia de sinalização e de mídia.
Novas Tecnologias
- Estudo de caso: WebRTC.
- Novas tecnologias e a WWW.
- Servidor Web, HTML5, Javascript.
- HTML5, Javascript, WebRTC.
- HTML5, Javascript, WebRTC.
- Entrega: ligação entre ramal analógico e canal WebRTC.