Redes Multimídia (diário 2014-1): mudanças entre as edições
Linha 106: | Linha 106: | ||
=====Ligação intermediada por SIP Registrar/Proxy===== | =====Ligação intermediada por SIP Registrar/Proxy===== | ||
Foi utilizado o aplicativo pjsua nos terminais e Asterisk no servidor: | Foi utilizado o aplicativo pjsua nos terminais e Asterisk no servidor: | ||
* Servidor Registrar e Proxy (192.168.0.1) | * Servidor r0pbx0 (192.168.0.1) como SIP Registrar e Proxy. Foram configurados duas contas SIP no arquivos /etc/asterisk/sip.conf: | ||
<code> | |||
[100] | |||
type=friend ; ambos os sentidos | |||
host=dynamic | |||
defaultuser=100 | |||
[101] | |||
type=friend | |||
host=dynamic | |||
defaultuser=101 | |||
</syntaxhighlight> | |||
* No mesmo servidor, foi iniciado o serviço e verificadas as configurações (quem pode ligar, peers, e quem pode receber, users): | |||
<code> | |||
asterisk -c | |||
sip show peers | |||
sip show users | |||
</syntaxhighlight> | |||
* Depois, foi configurada a primeira conta (100) no terminal r0pc0, no arquivos /root/pjsua.cfg: | |||
<code> | |||
--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 | |||
</syntaxhighlight> | |||
* O mesmo foi feito para a segunda conta (101), em r0pc1 (mesmo arquivo): | |||
<code> | |||
--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 | |||
</syntaxhighlight> | |||
* Para acompanhar o registro, foi ativada a depuração de mensagens SIP no servidor (na CLI do Asterisk): | |||
<code> | |||
sip set debug on | |||
</syntaxhighlight> | |||
* E, em cada terminal (r0pc0 e r0pc1), foi executado o comando que inicia o registro das contas SIP: | |||
<code> | |||
pjsua --config-file=/root/pjsua.cfg | |||
</syntaxhighlight> | |||
Por fim, faltou apenas iniciar uma chamada telefônica, o que não foi possível pois o aplicativo pjsua não detectou placa de som - cancelando a operação. A ver na próxima aula. | |||
===12/03=== | ===12/03=== |
Edição das 00h45min de 12 de março de 2014
Endereço encurtado desta página: http://bit.ly/rmu20141
1 Sobre a disciplina
2 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.
2.1 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.
3 Aulas
3.1 Apresentação da disciplina e oportunidades
3.1.1 10/02
- Apresentação da disciplina: metodologia e avaliação.
3.1.2 12/02
- Definição da metodologia e escopo do problema: a rede de comunicação.
3.1.3 17/02
Não houve aula.
3.1.4 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.
3.2 Sinalização
3.2.1 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.
3.2.2 26/02
- SIP, intracentral.
3.2.3 10/03
- SIP, intercentrais.
- Um cenário possível para o experimento:
- Geral
- 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
- 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
</syntaxhighlight>
3.2.3.1 Experimentos
3.2.3.1.1 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>
3.2.3.1.2 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
[101]
type=friend
host=dynamic
defaultuser=101
</syntaxhighlight>
- 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
</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
</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
</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, o que não foi possível pois o aplicativo pjsua não detectou placa de som - cancelando a operação. A ver na próxima aula.
3.2.4 12/03
- SIP, modelo hierárquico e federado (com DNS).
- Entrega: sinalização com SIP.
3.3 Descrição de Mídia
3.3.1 17/03
- Estudo de caso: Skype e o codec SILK.
- Descrição de mídia, SIP/SDP.
3.3.3 26/03
- SIP/SDP.
- Entrega: codecs personalizados por canal/tronco.
3.4 Transmissão de Mídia
3.4.1 31/03
- 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.
- Convidado(?): Carlos Alberto Stahelin.
3.4.2 02/04
- Transmissão de mídia, RTP/RTcP.
- Entrega: análise latência, jitter e perda de pacotes e impacto na mídia.
3.5 Qualidade de Serviço
3.5.1 07/04
- Estudo de caso: Implementando qualidade de serviço para VoIP usando Cisco.
- Qualidade de serviço.
3.5.4 16/04
- Filas e priorização em redes sem QoS.
- Entrega: ambiente com e sem protocolo de QoS.
3.6 Segurança
3.6.1 21/4
- Estudo de Google Hangouts.
- Criptografia.
- Convidado: Patricia Domingos e/ou Paulo Vitor Chirolli Almeida.
3.6.4 30/4
- Criptografia opcional e obrigatório.
- Entrega: sinalização e mídia criptografados sob demanda, opcional e obrigatório.
3.7 Novas Tecnologias
3.7.1 05/05
- Estudo de caso: WebRTC.
- Novas tecnologias e a WWW.
- Convidado: Felipe Silva Borges.
3.7.4 14/05
- HTML5, Javascript, WebRTC.
- Entrega: ligação entre ramal analógico e canal WebRTC.
3.8 IP
3.8.6 04/07
- IPv6.
- Entrega: ligação entre canais com terminações IPv4 e IPv6.