Redes Multimídia (diário 2014-1)

Endereço encurtado desta página: http://bit.ly/rmu20141

Sobre a disciplina

• Ementa

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:

1. Geral

global[compact]=False global[mem]=64 global[vm]=4 global[clean]=False global[path]=/tmp/rmu20141/cenario0/lab

1. Roteador

rt0[type]=router

1. Rede 0
3. Equipamentos

r0sw0[type]=switch r0pbx0[type]=pbx r0pc0[type]=generic r0pc1[type]=generic

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

2. Rotas

r0pbx0[default_gateway]=192.168.0.254 r0pc0[default_gateway]=192.168.0.254 r0pc1[default_gateway]=192.168.0.254

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

1. Rede 1
3. Equipamentos

r1sw0[type]=switch r1pbx0[type]=pbx r1pc0[type]=generic r1pc1[type]=generic

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

2. Rotas

r1pbx0[default_gateway]=192.168.1.254 r1pc0[default_gateway]=192.168.1.254 r1pc1[default_gateway]=192.168.1.254

2. 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):
  1. As ligações são estabelecidas utilizando apenas G711 lei A (alaw); ou seja, em ambos os sentidos em cada ligação.
  2. As ligações são estabelecidas utilizando apenas GSM (gsm).
  3. As ligações não podem ser estabelecidas por incompatibilidade de codec.
  4. 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.  1 ligação sem perdas.
2. Perda em 1 ligação (enlace PPP com taxa de transmissão insuficiente, provavelmente 56Kbps).
3. 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

• DSCP
• 802.1 para cobrir o tópico da 802.1p

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:

1. Como classificar o tráfego (e que tráfego)?
2. Como marcar pacotes?
3. Como definir e implantar políticas?
4. 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.

Diagrama exposto em sala de aula.

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.

Diagrama da rede que estamos trabalhando:

14/05

• IPv6.
• Traffic class.

19/05

• IPv6.
• Traffic class.

Diagrama da aula:

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á feita APENAS com a configuração.
  • 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, parágrafo 3:

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

oBS.:Para estudar os itens acima, nos próximos experimentos, não iremos mais utilizar o Netkit, mas sim a máquina virtual.

Objetivo inical da aula: compilar o asterisk. Passos seguidos:

• 1)Abrir uma máquina virtual;
• 2)sudo su
• 3)cd /usr/local/src
• 4)wget -t0 http://donwloads.esterisk.org/pub/telephony/asterisk/asterisk-11-current.tar.gz
• 5)tar xzv asterisk-11-10.0
• 6)cd asterisk-11-10.0
• 7)vi README*
• 8)./configure --help|less
• 9) apt-get install build-essential
• 10) apt-get install libncurses-dev
• 11) apt-get install libxml2-dev
• 12) apt-get install libsqlite3-dev
• 13) apt-get install libssl-dev
• 14) apt-get install libsrtp-dev
• 15)./configure --prefix=/usr/loca/asterisk-11.0.0 --exec-prefix=/usr/local/asterisk-11.10.0 --with-srtp --with-ssl
• 16) make menuselect
• 17)make
• 18)make install
• 19)make samples

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.