Mudanças entre as edições de "Redes Multimídia (diário 2016-1)"
Linha 1 399: | Linha 1 399: | ||
==Aula 24 - 14/06/16: Firewall - Continuação da atividade== | ==Aula 24 - 14/06/16: Firewall - Continuação da atividade== | ||
− | ==Aula 25 - | + | ==Aula 25 - 18/06/16: Firewall - Início do trabalho== |
O trabalho deverá ser feito utilizando a seguinte rede: | O trabalho deverá ser feito utilizando a seguinte rede: |
Edição das 09h58min de 20 de junho de 2016
Redes Multimidia: Diário de Aula 2016-1
Professora: Simara Sonaglio
E-mail: simara.sonaglio@ifsc.edu.br
Encontros: 2a feira/09:40, 3a feira/09:40
Atendimento paralelo:
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.
Softwares
Avaliações
Aluno | Avaliação 1 | Trabalho 1 | Trabalho 2 |
---|---|---|---|
Giovanni | 8,75 | ||
Luiz | 6,75 | ||
Valmir | 6,25 |
Diário das aulas
Aula 1 - 22/03/16
Apresentação |
---|
Apresentação da disciplina: conteúdo, bibliografia e avaliação, laboratório. |
Aula 2 - 28/03/16
Caracterização de midias |
---|
Compressão de video
Técnicas usadas para compressão de video:
Atividade1) 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 ? |
Aula 3 - 04/04/16
Aula 3 no dia 29/03/2016 foi suspensa e deverá ser reposta posteriormente.
Caracterização de midias | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Compressão de audioTécnicas usadas:
Pacotes a instalar
|
Aula 4 - 05/04/16
Transmissão de midias |
---|
Atividade Resolver Problemas 10, 11 e 12 da 5ª ed. do Kurose para entregar. |
Aula 5 - 11/04/16: Introdução a Voz sobre IP (VoIP)
Introdução ao VoIP |
---|
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). |
Aula 6 - 12/04/16: O protocolo SIP
O protocolo SIP | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
O protocolo SIPO 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 SIPO 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):
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.
Tabela de métodos SIP (não exaustiva ... apenas os principais métodos)
Tabela de cabeçalhos SIP (não exaustiva ... apenas os principais cabeçalhos) Diagramas de chamadasAlguns tipos de chamadas VoIP com SIP são recorrentes, estando representadas nas subseções a seguir. Registro de agente SIP em um proxy SIPEsta 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). Fone 1 Proxy SIP ou PBX IP
| |
| REGISTER |
|---------------------------->|
| 401 Unauthorized |
|<----------------------------|
| REGISTER |
|---------------------------->|
| 200 OK |
|<----------------------------|
| |
Chamada direta entre dois agentes SIPUma 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. 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 SIPA 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. 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 mediaEste 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-INVITEO 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 |<---------------|
|<---------------| |
| | |
|
Aula 7 - 18/04/16: O protocolo SIP - continuação
SDP |
---|
SDP – Session Description ProtocolPara garantir o processo de negociação das mídias a serem trocadas numa sessão, o SIP encapsula outro protocolo, comumente o SDP. O SDP, definido inicialmente em no RFC 2327 (HANDLEY e JACOBSON, 2011), teve como propósito original descrever sessões multicast estabelecidas sobre o backbone multicast da Internet, o MBONE e, portanto, vários de seus campos tem uso limitado (ou nenhum uso) para as sessões unicast estabelecidas atualmente com o SIP, mas foram mantidos na nova definição do protocolo, RFC 4566 (HANDLEY, JACOBSON e PERKINS, 2011), para garantir a compatibilidade. De acordo com (JOHNSTON, 2009), as principais informações carregadas numa mensagem SDP sobre a sessão de mídia são: endereço IP (IPv4 ou IPv6) ou nome de host, perfil RTP (tipicamente “RTP/AVP”), número da porta que será usada para troca de fluxo de mídia, tipo de mídia a ser trocada (vídeo, áudio, texto e etc.) e esquema de codificação de mídia. FONTE: Teleco. |
Aula 8 - 19/04/16: O protocolo SIP - continuação
Atividades realizadas
- Registro de ramais criados no Asterisk da máquina Professor;
- Testes de chamadas entre ramais;
- Análise de tráfego de com o Wireshark;
- Análise de tráfego de áudio com a opção Reinvite habilitada/desabilitada.
Aula 9 - 25/04/16: O protocolo RTP
RTP | ||||
---|---|---|---|---|
O transporte de midia com protocolo RTP
RTCPAlé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:
Os cinco tipos de relatórios são:
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. Lista de exercícios |
Aula 10 - 26/04/16: Exercícios
Aula 11 - 02/05/16: Prova
Aula 12 - 03/05/16: Asterisk - Apresentação
- 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
Aula 13 - 09/05/16: Asterisk - Canais SIP e plano de discagem
Canais SIP e plano de discagem | ||||
---|---|---|---|---|
Plano de discagemO 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:
[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=>199,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
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
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 SIPCada 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
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
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
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
Atividades
|
Aula 14 - 10/05/16: Asterisk - Continuação Aula 13
Aula 15 - 16/05/16: Asterisk - URA
URA |
---|
Uma URA implementa um menu audível para auto-atendimento. Sua construção é feita toda no plano de discagem, como se pode ver no exemplo abaixo: [default]
exten => 666,1,Goto(ura,s,1)
[ura]
exten => s,1,Answer
exten => s,2,NoOp(Ligação entrou na URA)
exten => s,n,Background(/var/lib/asterisk/sounds/benvindo)
exten => s,n,NoOp(Digite a opção/1-suporte/2-comercial/3-financeiro)
exten => s,n,WaitExten(6); caso nada tenha sido digitado durante a mensagem "benvindo", espera mais 6 segundos no máximo
exten => 1,1,NoOp(Chamada foi para Suporte)
same => n,Dial(SIP/2402,60)
same => n, Hangup
exten => 2,1,NoOp(Chamada foi para Comercial)
same => n,Dial(SIP/2801,60)
same => n, Hangup
exten => 3,1,NoOp(Chamada foi para Financeiro)
same => n,Dial(SIP/2000,60)
same => n, Hangup
exten => i,1,NoOp(Extensão inválida)
same => n,Play(beep)
same => n,GoTo(s,3); volta para o menu
exten => t,1,NoOp(Tempo esgotado)
same => n,Dial(SIP/3401,60)
same => n,Hangup
A URA é composta por mensagens de voz, que instruem o usuário sobre o que ele pode fazer (isto é, apresentam as opções), e músicas, que o entreteem (!?) enquanto aguarda uma operação ser realizada. Assim, para criar uma URA minimamente funcional são necessários esses arquivos de voz. Para gravá-los, pode-se criar uma extensão especial que atenda por 999. Ao chamar essa extensão, pode-se pronunciar a mensagem de voz assim que o Asterisk atender. Para encerrar a mensagem, deve-se digitar #. O arquivo de voz resultante estará no diretório /var/lib/asterisk/sounds, ou em qualquer outro diretório especificado na aplicação record. exten=999,1,answer()
exten=999,n,record(/var/lib/asterisk/sounds/${EXTEN}.wav,5,t)
exten=999,n,playback(/var/lib/asterisk/sounds/${EXTEN})
exten=999,n,hangup()
Ou:
exten=>998,1,Answer
same=>n,Wait(1)
same=>n,Playback(beep)
same=>n,Record(/tmp/novo:wav)
same=>n,Playback(beep)
same=>n,Playback(/tmp/novo)
same=>n,Hangup
A implantação de uma URA (e de muitas outras funções típicas de PBX) em um PBX Asterisk, é necessário conhecer os recursos que ele oferece. Dentre esses recursos, há aplicações, variáveis, e características (features). Hoje serão vistos alguns desses recursos, que usaremos para implantar uma URA. Funções usando o plano de discagemPara implantar funcionalidades conhecidas ou novas no Asterisk usando o plano de discagem, devem-se conhecer alguns recursos avançados. Aqui são apresentados três deles: extensões especiais, aplicações, padrões de extensões e variáveis. Extensões especiaisAlém das extensões criadas pelo usuário, o Asterisk apresenta algumas extensões especiais, tais como:
|
Aula 16 - 17/05/16: Asterisk - Desvio condicional
Usando Gotoif
Exemplo 1 |
---|
|
Exemplo 2 |
---|
|
Aula 17 - 23/05/16: Asterisk - Continuação de Desvio condicional
Aula 18 - 24/05/16: Asterisk - Tronco SIP
Tronco Sip | |||||||||
---|---|---|---|---|---|---|---|---|---|
Interligação entre PABX IPA 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 o áudio flui em separado com RTP. No segundo caso, o protocolo IAX2 (Inter-Asterisk eXchange) encapsula tanto a sinalização quanto os fluxos de áudio, o que simplifica o estabelecimento do tronco.
Tronco SIPEm 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:
Atividade: estabelecendo chamadas entre diferentes PBX AsteriskNesta atividade, vamos realizar chamadas entre softphones registrados em diferentes PBX Asterisk. Para isso, precisaremos estruturar o laboratório de forma que cada PBX Asterisk possua um tronco SIP com um PBX vizinho. |
Aula 19 - 30/05/16: Asterisk - Início do trabalho
Cada aluno será responsável por um Asterisk. Cada central IP deverá atender os seguintes pontos:
- As contas SIP de cada central deverão ser criadas nas faixas 1XX para a Central 1, 2XX para a Central 2 e 3XX para a Central 3;
- Para ligação interna a cada central, os usuários deverão discar 11XX, 22XX e 33XX. Por exemplo, ao discar 1100 a chamada deve ser encaminhada para a conta 100, ao discar para 1101 a chamada deve ser encaminhada para 101 e assim por diante;
- Cada central deverá ter um contexto chamado INTERNO, o qual será usado para que as chamadas internas a cada central sejam completadas;
- Todo o áudio das chamadas deverá passar por dentro da central;
- Todos os ramais devem se comunicar, inclusive devem ser capazes de ligar para a URA da mesma central;
- Cada ramal interno deverá ter um desvio se não atende para algum outro ramal da mesma central;
- Cada central deverá ter um número (ex: 1199) que será atendido por uma URA. Esta URA deverá atender aos seguintes pontos:
- Possuir mensagens de boas vindas e apresentação de opções de atendimento;
- Possuir ao menos duas opções de atendimento;
- Ao menos uma destas opções deve se atendida por um grupo de ramais que irá ringar todos os ramais ao mesmo tempo;
- Caso o usuário digite uma opção válida inválida, a chamada deverá retornar ao menu da URA por mais duas vezes. Após isso a chamada será finalizada;
- Caso o usuário não digite nenhuma número, a chamada deverá retornar ao menu da URA por mais duas vezes. Após isso a chamada será finalizada;
- Cada central deverá ter um tronco SIP para as demais centrais. Este tronco SIP deve utilizar o contexto EXTERNO;
- Um ramal de uma central deve ser capaz de ligar para qualquer numeração em outra central.
Avaliação:
- Será feita uma demostração de funcionamento das centrais no dia 06/06/16. Esta demonstração de funcionamento representará 70% da nota;
- No mesmo dia deverá ser entregue um documento em formato PDF contendo toda a configuração feita na central e devidas explicações a respeito destas configurações. Este documento representará 30% da nota.
Úteis para o trabalho
Ringando ramais simultaneamente |
---|
|
Aula 20 - 31/05/16: Asterisk - Continuação do trabalho
Aula 21 - 06/06/16: Asterisk - Apresentação do trabalho
Aula 22 - 07/06/16: Firewall
Firewall | |||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Uma introdução ao iptablesO filtro IP do Linux se chama NetFilter, e suas regras são configuradas por meio do utilitário iptables (ver também seu manual). Com iptables se podem adicionar ou remover regras do Netfilter, além de consultar estatísticas sobre essas regras (ex: contadores dos pacotes e bytes que selecionaram cada regra). As regras são agrupadas em conjuntos denominados chains ("cadeias"), as quais estão relacionadas com o contexto que cada pacote está sendo analisado. Existem três chains predefinidas:
Por exemplo, a regra abaixo permite o encaminhamento de todos os segmentos TCP destinados a porta 80:
Salvando e restaurando regras do iptablesUma vez obtido um conjunto de regras que funcione como desejado, deve-se poder salvá-lo para que possa ser reativado sempre que desejado (ex: no boot). Existem dois utilitários que auxiliam nessa tarefa, sendo eles:
AtividadeCada aluno deve implantar a seguinte rede virtual em seu computador utilizando a máquina virtual 1-Grafico para ser o Pc e a máquina 1-Servidor para ser o Firewall:
DICAÉ útil ativar o NAT na interface externa do firewall (eth0 na nossa rede de teste): iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Comando para tornar uma máquina Linux roteador: echo 1 > /proc/sys/net/ipv4/ip_forward
Cenário 1: Uma rede pequena sem servidoresEm uma rede pequena e que não oferece serviços, todos os fluxos se originam internamente. Assim, o firewall deve impor que somente fluxos internos possam passar. Com base nisso, configure seu firewall das seguintes formas:
|
Aula 23 - 13/06/16: Firewall
Atividade |
---|
Cada aluno deve implantar a seguinte rede virtual em seu computador utilizando a máquina virtual 1-Grafico para ser o PC e a máquina 1-Servidor para ser o Firewall:
OBS.: Não esquecer de prever regras de retorno!!!
1 - Ativar uma segunda interface de rede da máquina virtual em modo Brigde com a sua eth0: 2 - Configurar esta interface de rede conforme abaixo: sudo ifconfig eth1 10.1.X.Y/24
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo ifconfig eth0 10.1.X.Z/24
sudo route add default gw 10.1.X.Y
|
Aula 24 - 14/06/16: Firewall - Continuação da atividade
Aula 25 - 18/06/16: Firewall - Início do trabalho
O trabalho deverá ser feito utilizando a seguinte rede:
IMPLEMENTAR
Deverão ser atendidos os seguintes pontos:
- Definir a política das chain de acordo com o necessário;
- PC1 pode fazer apenas acesso VoIP ao servidor 172.18.135.175 e acesso Web ao servidor 172.18.135.17;
- PC2 pode fazer o que PC1 tem permissão. Além disso, pode fazer acesso externo SSH e Web;
- Todo o fluxo RTP deverá ocorrer na faixa de portas 10000-20000;
- A página www.ifsc.edu.br deve ser permitida para ambos os PCs;
- A máquina firewall somente aceita acesso SSH da máquina interna PC2. Ela não aceita acesso via SSH da rede externa;
- A máquina firewall somente deve bloquear ping da rede externa;
- A máquina firewall não deve iniciar trafego VoIP;
- Implementar mais regras de acordo com o desejado.
AVALIAÇÃO
- No dia 27/06 será demonstrado o funcionamento das regras implementadas (70% da nota);
- No mesmo dia deve ser entregue um relatório contendo todas as regras implementadas e explicação de funcionamento de cada uma delas (30% da nota).