PJI4-2017-1
Endereço encurtado: http://bit.ly/pji4-20171
Presença: Presença
Projeto Integrador IV
Professores: Marcelo Maia Sobral ( Facebook) e Simara (simara.sonaglio@ifsc.edu.br)
Encontros: 2a feira/19:00, 3a feira/19:00
Atendimento paralelo: 2a e 3a feira 18:30 h
Coordenadoria pedagógica (Graciane): graciane@ifsc.edu.br (3381-2890, 3381-2842)
Objetivo Geral
- Implantar um PABX IP integrado com serviços de telefonia fixa e móvel convencionais.
- Prover a infraestrutura de rede necessária para o adequado funcionamento deste PABX IP.
- Integrar os serviços de telefonia com outros serviços de rede.
Ementa
O foco do Projeto Integrador está oferta de serviços ao usuário final e na convergência de serviços de telecomunicações, incluindo a integração dos serviços de telefonia fixa, móvel e VoIP. Na parte de redes de computadores, além do suporte de comunicação para a convergência de serviços, também será tratado a instalação de servidores Web, Email, Telefonia IP, administração de sistemas e usuários, compartilhamento de recursos, etc.
Bibliografia básica
- KUROSE, J. e ROSS, K. Redes de Computadores e a Internet: Uma abordagem top-down. Tradução da 3a edição, Addison Wesley, 2006.
- COLCHER, Sérgio. VOIP: voz sobre IP. Rio de Janeiro: Elsevier, 2005.
Bibliografia complementar
- VALLE, O. T. Administração de Redes com Linux: Fundamentos e práticas. Publicação IFSC. 2010.
Links interessantes
- VoIP Hacking Techniques
- Asterisk não é um SIP proxy
- FoneRNP
- SwitchVox: PBX virtual
- Net Fone da Embratel é VoIP, mas não usa SIP]
- Estatísticas sobre VoIP no mundo
Provedores VoIP no Brasil
Avaliações
Aluno(a) | Avaliação 1 | Avaliação 2 | Avaliação 3 | Avaliação 4 | Nota final |
---|---|---|---|---|---|
ANDERSON | |||||
CHRISTIEN | |||||
GIORDANO | |||||
HIGINO | |||||
KLEITON | |||||
MIKE | |||||
TIAGO |
Diário de Aula 2017-1
13/02: Apresentação da disciplina
Aula 1 |
---|
Instalação do AsteriskUm PBX IP funciona como uma central telefônica, porém intermediando chamadas VoIP. Com isso, as chamadas são feitas de um telefone IP em direção ao PBX IP, que a encaminha ao telefone IP de destino de acordo com suas regras de discagem. A figura abaixo ilustra como funciona uma chamada VoIP típica através de um PBX IP.
PBX IP Asterisk
Características Básicas: faz tudo que um PABX pequeno e simples faz e pouco mais
Plano de discagemO plano de discagem define como cada chamada deve ser processada. As instruções de processamento residem no arquivo de configuração /etc/asterisk/extensions.conf. O fluxo de processamento de chamadas pode ser visto resumidamente abaixo:
[default]; o nome deste contexto ... default é o contexto predefinido do Asterisk
# 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
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]
defaultuser=maria ; 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 ;
disallow=all
allow=gsm ; habilita este codec para o João.
allow=alaw ; outro codec
allow=ulaw ; mais um codec
qualify=yes; monitora o UAC
; Canal 1000 (outro exemplo)
[1000]
defaultuser=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 ;
disallow=all
allow=gsm ; habilita este codec
allow=alaw ; outro codec
allow=ulaw ; mais um codec
qualify=yes; monitora o UAC
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 ;
disallow=all
allow=gsm ; habilita este codec
allow=alaw ; outro codec
allow=ulaw ; mais um codec
qualify=yes; monitora o UAC
; Canal 2000
[2000](alunos); a sequência "(alunos)" copia as definições do perfil "alunos"
defaultuser=maria ; o nome do usuário para fins de autenticação
secret=kabrum
; Canal joao
[joao](alunos)
defaultuser=joao ; o nome do usuário para fins de autenticação
secret=blabla
Experimento: comunicação entre telefones IP ou softphones por meio de um PBX IPPara realizar esses exercícios você deve usar o Asterisk na máquina virtual Grafico-2. Para testar as chamadas, use um softphone em seu celular ou em um computador.
2. Crie um plano de discagem em que todos podem fazer chamadas para todos (isso é, 100 pode chamar 101, e vice-versa). 3. Configure os softphones de forma que se registrem no PBX Asterisk, usando as contas SIP criadas previamente. 5. A partir de um softphone faça uma chamada para a conta do outro softphone. Verifique se o softphone de destino acusou o recebimento de chamada. Caso isso não tenha ocorrido, verifique seu plano de discagem. Em seguida faça uma chamada em sentido contrário. 6. Execute o comando rasterisk -vvv no computador do Asterisk. 7. Usando o comando sip show peers, visualize os estados dos canais SIP conhecidos pelo Asterisk. 8. Refaça uma chamada entre os softphones, e observe o que aparece na tela do rasterisk. 9. Será possível verificar que chamadas estão em andamento no Asterisk usando o rasterisk ? Pesquise como se pode fazer isso. 10. Use o rasterisk para testar chamadas. Use o comando console dial canal_SIP para chamar um canal SIP (substitua canal_SIP pelo número a ser chamado). Ao final, execute console hangup. 11. Acrescente mais um canal SIP, editando o arquivo sip.conf. Configure um dos softphones para usar esse novo canal. 12. Teste chamadas entre os softphones usando esse novo número. Possíveis problemas
DICAS ASTERISKComandos válidos no CLI do Asterisk:
|
14/02: Interligação de PBX Asterisk
Aula 2 | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Supondo que cada cliente do provedor tenha seu próprio PBX, pode ser necessário interligar suas centrais com o PBX do provedor. A interligação entre PBX Asterisk pode ser feita via rede de dados usando os protocolos SIP ou IAX2 (porém este segundo está em desuso). 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 (mais detalhes sobre esses protocolos serão vistos em aulas posteriores). 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. Isso implica definir um plano de numeração para os ramais da empresa. Sendo assim:
|
20/02: O protocolo SIP
Aula 3 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
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)
Tabela com as classes de respostas 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 |<---------------|
|<---------------| |
| | |
Correção para o wiresharkO wireshark instalado no Ubuntu 14.04, como nas VM do laboratório, possui um bug que impede que se visualize a análise do fluxo de chamadas VoIP. Nessa versão, quando se seleciona no menu Telephony->VoIP Calls, e em seguida clica-se em uma das chamadas apresentadas e depois o botão Flow, o wireshark termina a execução. A solução para esse problema envolve instalar uma versão mais recente do wireshark: sudo add-apt-repository ppa:wireshark-dev/stable
sudo apt-get update
sudo apt-get install wireshark-gtk
... e após a instalação execute wireshark-gtk.
AtividadesNas análises pedidas a seguir, faça o seguinte:
|
21/02: Continuação Aula 3
Aula 4 |
---|
06/03: Continuação Aula 3 e o protocolo SDP
Aula 5 | ||||
---|---|---|---|---|
SDP (Session Description Protocol)Ao iniciar uma chamada com SIP, a negociação de midia a ser transmitida é especificada no corpo da mensagem INVITE. O formato da especificação é descrito pelo protocolo SDP (Session Description Protocol), contendo as seguintes informações:
Assim como SIP, SDP codifica suas informações em texto simples. Uma mensagem SDP é composta por linhas de texto chamadas de campos, cujos nomes são abreviados por uma única letra. Os campos de uma mensagem SDP são:
Atividade
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. AtividadeEssa atividade busca ilustrar os fluxos RTP com um exemplo:
|
07/03: Investigando os protocolos envolvidos nas chamadas
Aula 6 |
---|
Sinalização com SIPAs chamadas que realizamos por meio do Asterisk foram iniciadas e terminadas usando protocolo SIP. Elas podem ser enquadradas em dois casos:
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 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 |<---------------|
|<---------------| |
| | |
Atividade
|
13/03: VoIP e NAT
Aula 7 |
---|
A existência de um ou mais tradutores NAT entre telefones dificulta o estabelecimento de chamadas. Isso porque o NAT modifica o endereço IP e port (UDP ou TCP) de origem de pacotes que viajam da rede interna para a externa, o que fica inconsistente com o que foi negociado na chamada com SDP. Há alguma abordagens para contornar esse problema:
Para entendermos os problemas causados pelo NAT na telefonia IP, iremos primeiramente fazer uma investigação utilizando como base para isso todo o conhecimento sobre os protocolos SIP, SDP e RTP previamente adquiridos. Assim, iremos implementar os cenários descritos na Atividade 1 e posteriormente Atividade 2, fazer chamadas de teste, capturar os pacotes destas chamadas utilizando o Wireshark e posterior análise destes.
Atividade 1- Softphone atrás de NAT
Solução utilizando o AsteriskO Asterisk pode ajudar a viabilizar a comunicação com telefones VoIP que estão atrás de gateways NAT. Na definição de cada canal SIP devem-se incluir as opções: nat=yes
qualify=yes
directmedia=no
Aqui tem uma boa explicação sobre o que fazem essas opções.
Atividade 2- Asterisk atrás de NAT
Solução utilizando o Asterisk
Para fazermos o redirecionamento de um fluxo entrante para outro servidor, devemos executar o seguinte:
|
14/03: Continuação Aula 7
Aula 8 |
---|
20/03: Funções de PABX
Aula 9 | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
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 quatro deles: extensões especiais, aplicações, padrões de extensões e variáveis. AplicaçõesAs aplicações são usadas no plano de discagem. Assim, o processamento de uma chamada se faz pela execução sucessiva de aplicações, de forma a se obter o efeito desejado. DialEncaminha a chamada para um destino. Exemplo: exten=>_1XXXX,1,Dial(SIP/${EXTEN})
same=>n,hangup
BackgroundToca um arquivo de som como música de fundo. Esse arquivo deve estar em /usr/share/asterisk/sounds, e ser codificado com codec PCM ou WAV. Exemplo: exten=>666,1,Answer
same=>n,Background(hello-world)
same=>n,Hangup
PlaybackToca um arquivo de som. A diferença em relação a Background é que Playback devolve o controle ao Asterisk (i.e. ao plano de discagem) somente após tocar todo o arquivo. Esse arquivo deve estar em /usr/share/asterisk/sounds, e ser codificado com codec PCM ou WAV. Exemplo: exten=>666,1,Answer
same=>n,Playback(hello-world)
same=>n,Hangup
WaitForça uma espera durante o processamento da chamada. Exemplo: exten=>666,1,Answer
same=>n,Playback(hello-world)
same=>n,Wait(1)
same=>n,Playback(beep)
same=>n,Hangup
Answer e HangupAnswer atende uma chamada. Hangup termina uma chamada. Exemplo: exten=>666,1,Answer
same=>n,Playback(hello-world)
same=>n,Hangup
GoToPula para um contexto (opcional), extensão, prioridade específica. Exemplo: exten=>100,1,GoTo(vendas,s,1)
GoToIfTrata-se do comando GoTo condicional. Sua sintaxe é: GoToIf(condição?[rótulo se verdade]:[rótulo se falso]) Os rótulos podem assumir a forma: [[contexto],extensão,]prioridade Exemplo: [alunos]
exten=>6111,1,GoToIf($["${CALLERID(num)}" != "6112"]?2:4)
same=> n,Dial(SIP/6111,30)
same=> n,Hangup
same=> n,Answer
same=> n,Playback(hello-world)
same=> n,Hangup
SetModifica o valor de uma variável. Exemplo: exten=>666,1,Set(Tentativas=1)
same=>2,Dial(SIP/666,10)
same=>3,Set(Tentativas=${Tentativas}+1)
same=>4,GoToIf($[${Tentativas} < 2]?2:5)
same=>5,Hangup
LogGrava um texto qualquer no log do Asterisk. Exemplo: exten=>666,1,Log(DEBUG,"Chamada para 666")
same=>n,Dial(SIP/666,10)
same=>n,Hangup
NoOpNão faz nada, sendo útil para depurar o plano de discagem. Exemplo: exten=>100,1,NoOp(${CONTEXT})
Padrões de extensõesExtensões podem ser representadas de forma compacta com padrões de extensões. Com esse recurso, muitas extensões podem ser atendidas com um único conjunto de regras, evitando um plano de discagem repetitivo. Por exemplo, se uma empresa possui ramais entre 100 e 199, o plano de discagem pode ser escrito assim: exten=>_1XX,1,Dial(SIP/${EXTEN})
same=>n,Hangup
A extensão _1XX contida na primeira linha está escrita como um padrão (pattern), pois inicia com o caractere _. Os caracteres que seguem _ indicam cada dígito que deve aparecer para satisfazer essa extensão. Nesse exemplo, deve aparecer 1 seguido de dois dígitos quaisquer entre 0 e 9 (é esse o significado do caractere X). Desta forma, essa extensão atende qualquer número entre 100 e 199. Por fim, o número de fato chamado é armazenado na variável ${EXTEN}, que pode assim ser usada dentro da regra de discagem. Alguns caracteres têm significado especial em padrões, como mostrado no exemplo (caractere X). A tabela abaixo lista esses caracteres:
VariáveisO uso de variáveis no Asterisk possui funcionamento semelhante àquele encontrado nas linguagens de programação, permitindo ao “programador” utilizar variáveis já definidas pelo Asterisk bem como definir suas próprias variáveis. As definições das variáveis devem ser feitas no arquivo extensions.conf. A sintaxe para trabalhar com variáveis no Asterisk é semelhante a do c-shell, porém as variáveis definidas pelo usuário não são sensíveis a caixa, ou seja, VAR e var referem-se à mesma variável.
Existem três tipos de variáveis:
Abaixo se pode ver um exemplo de plano de discagem que usa variáveis: [globals]
; definicao de uma variavel global
VENDAS=SIP/6112
[alunos]
; definicao de uma variavel global atraves do comando Global e aplicacao Set
exten=> 6666,1,Set(GLOBAL(COMPRAS)=SIP/6113)
exten=> 6666,2,NoOp(${GLOBAL(COMPRAS)})
; definicao de uma variavel especifica ao canal
exten=> 7777,1,Set(teste=1)
exten=> 7777,n,NoOp(${teste})
exten=> 7777,n,Set(teste=$[${teste} + 1])
exten=> 7777,n,NoOp(${teste})
exten=> 7777,n,Hangup
Extensões especiaisAlém das extensões criadas pelo usuário, o Asterisk apresenta algumas extensões especiais, tais como:
Atividades
|
21/03: Continuação da Aula 9
Aula 10 |
---|
27/03: Qualidade da comunicação
Aula 11 | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Componentes do atraso fim-a-fimO 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.
O menor atraso pode ser calculado assim:
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é . 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. Se cada pacote está sujeito a um atraso variável, o reprodutor de midia no receptor precisa de algum mecanismo para compensar essas variações e reproduzir a midia de forma contínua. Isso usualmente se faz com buffers de reprodução. Atividade1. Deve-se implantar esta rede:
3. Devem ser realizadas chamadas entre softphones, dando atenção à qualidade do áudio. OBS: nos PBX devem-se capturar os pacotes das chamadas para posterior análise. 4. Após realizar as chamadas, devem-se analisar suas respectivas capturas. A análise deve se concentrar em informações que forneçam uma medida de qualidade de serviço. Dica: vejam o menu Telephony->RTP. 5. Os passos 3 e 4 devem ser repetidos conforme orientação dos professores. |
28/03: Funções de PBX: URA e correio de voz
Aula 12 |
---|
O que é uma URA (Unidade de Resposta Audível) ? Clique na imagem abaixo ... 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,Playback(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, por exemplo, que atenda por 9005nome_de_um_arquivo. 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=>_9005.,1,answer()
same=>n,record(/var/lib/asterisk/sounds/${EXTEN:4}.wav,5,0)
same=>n,playback(/var/lib/asterisk/sounds/${EXTEN:4})
same=>n,hangup()
Para 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 e variáveis, já estudados em aulas anteriores, e características (features). Hoje serão vistos alguns desses recursos, que usaremos para implantar uma URA. Correio de voz
|
03/04: Outras funções de PBX
Aula 13 |
---|
Após experimentar a implantação de um correio de voz e uma URA, podem-se conhecer outras possíveis funções de PBX existentes no Asterisk, tais como:
Essas funções podem ser úteis na infraestrutura de telefonia a ser implantada na primeira etapa do projeto. Como exemplo, algumas delas são apresentadas a seguir. Música de esperaO Asterisk permite o uso de MP3 como música de espera, porém MP3 são arquivos complicados de se trabalhar pois requerem o uso de aplicações externas para que possam ser reproduzidos, como por exemplo mpg123. Seu funcionamento também pode não agradar muito já que em alguns casos a música pode ser reproduzida em alta rotação além de elevar a carga de processamento da máquina no caso de soluções de grande porte. A partir da versão 1.2 do Asterisk se sugere não mais usar o mpg123. O melhor é converter arquivos MP3 para um formato que o Asterisk trate nativamente, como por exemplo, wav ou pcm (μLaw). A ferramenta ffmpeg pode ser usada para converter arquivos MP3 para WAV ou PCM. # convertendo o arquivo musica.mp3 para musica.wav e musica.pcm
ffmpeg -i musica.mp3 -ar 8000 -ac 1 -ab 64 musica.wav -ar 8000 -ac 1 -ab 64 -f mulaw
musica.pcm -map 0:0 -map 0:0
Os arquivos de música devem ficar em um diretório especificado para cada contexto, conforme definido no arquivo musiconhold.conf: # configuracao no arquivo musiconhold.conf
[alunos]
mode=files
directory=/var/lib/asterisk/moh
sort=random
# deve-se colocar os arquivos wav e/ou pcm no diretorio especificado acima
Para testar a música em espera no plano de discagem, pode-se usar a aplicação MusicOnHold: exten=>667,1,Set(CHANNEL(musicclass)=alunos)
same=>n,Answer
same=>n,MusicOnHold()
same=>n,Dial(SIP/667)
same=>n,Hangup
Filas de atendimentoAmplamente utilizadas nos sistemas de 0800. A configuração é feita no arquivo queues.conf: [fila-suporte]
musicclass=default
strategy=ringall; roundrobin, rrmemory
timeout=10
wrapuptime=30
periodic-announce = em-breve
periodic-announce-frequency=60
member=>SIP/6111
member=>SIP/6112
No plano de discagem a fila de atendimento pode ser usada da seguinte forma: [suporte]
exten=> s,1,Set(CHANNEL(musicclass)=suporte)
exten=> s,2,Playback(bem-vindo)
exten=> s,3,Queue(fila-suporte)
Captura de chamadasA captura possibilita que se puxe uma chamada de um colega no mesmo grupo de chamadas. Isso evita que se tenha que levantar para atender um telefone do seu vizinho que não para de tocar. A captura pode ser feita discando *8 (isso pode ser alterado no arquivo features.conf).
Para habilitar a captura de chamadas é suficiente definir a que grupo de chamadas cada canal pertence (parâmetro callgroup), e de que grupos se pode capturar chamadas (parâmetro pickupgroup). No caso de canais SIP isso fica em sip.conf: [joaozinho]
callgroup=1
pickupgroup=1,2
...
Estacionamento de chamadasO estacionamento de chamadas é feito no arquivo features.conf fazendo uso dos seguintes parâmetros:
Abaixo se pode ver um exemplo de plano de discagem que usa estacionamento de chamadas: [vendas]
include=>parkedcalls
exten=>6200,1,Dial(SIP/6200,30,tT)
exten=>6200,n,Hangup
Atividades
AVALIAÇÃO: análise de chamadasA primeira avaliação envolve analisar um conjunto de chamadas entre agentes SIP e PBX Asterisk. Essas chamadas tiveram seus pacotes capturados e gravados em arquivos de captura compatíveis com Wireshark e tcpdump. Os arquivos de captura são estes:
|
04/04: Conexão com a PSTN e PABX legado
Aula 14 |
---|
A rede pública de telefonia comutada (do inglês Public switched telephone network ou PSTN) é o termo usado para identificar a rede telefônica mundial comutada por circuitos destinada ao serviço telefônico. A PSTN é administrada pelas operadoras de serviço telefônico e inicialmente foi projetada como uma rede de linhas fixas e analógicas, porém atualmente é digital e inclui também dispositivos móveis como os telefones celulares. Através dela podem ser realizadas chamadas locais (chamada realizada na mesma cidade/região), longa distância (chamada realizada para outra cidade/região) ou internacionais (chamada realizada para outros países). Além da PSTN, existem também as Centrais Privadas de Comutação Telefônica (PABX). Os PABXs operam de forma similiar a PSTN, porém são restritas ao ambiente de uma empresa. Os PABXs tem a função de interligar os telefones dos usuários da empresa (ramais) e também conectar-se a Central Pública (PSTN) através de uma ou mais linhas telefônicas (linhas tronco). Ambos, PSTN e PABX convencional, operam de forma similar e fazem uso de comutação de circuitos. Mais recentemente, surgiu o conceito de PBX IP que funciona como uma central telefônica convencional (PABX), porém intermediando chamadas VoIP. Com isso, as chamadas são feitas de um telefone IP em direção ao PBX IP, que a encaminha ao telefone IP de destino de acordo com suas regras de discagem. O PBX IP, diferentemente da PSTN e do PABX convencional, não utiliza a comutação de circuitos, mas sim opera sobre a rede de dados utilizando comutação de pacotes. O Asterisk é uma solução completa de PABX baseado em software, permitindo ligar o mundo IP ao mundo da rede pública de telefonia comutada. Para funcionar como um PABX IP puramente, o Asterisk não necessita de nenhum item adicional. Basta apenas instala-lo em um computador e fazer as devidas configurações. Porém, se deseja-se que o Asterisk se comunique com a PSTN ou com PABX convencional, são necessários placas ou gateways que façam a interface com o mundo da telefonia baseada em comutação de circuitos. Abaixo temos o exemplo de algumas placas que podem ser adicionas à máquina onde foi instalado o Asterisk:
Através destas placas podemos integrar o Asterisk em diversos cenários, como abaixo:
Refazendo o Asterisk para conectá-lo com a PSTN
Instalando o Channel Driver da Khomp
Fazendo chamadas através de canais Khomp
exten=>9,1,Dial(Khomp/bXcY)
same=>n,hangup
AtividadesUma vez adicionado o módulo Khomp e este estando com status UP, pode-se fazer as configurações para que as chamadas sejam roteadas através dele.
|
10/04: Conexão com a PSTN e PABX legado: continuação
Aula 15 |
---|
11/04: Conexão com a PSTN e PABX legado: continuação
Aula 16 |
---|
17/04: Etapa 1: conclusão
Aula 17 |
---|
A conclusão da etapa 1 envolve implantar o modelo de serviço de telefonia a ser oferecido aos clientes do seu provedor. Um cliente recebe uma central virtualizada, a qual pode configurar como desejar. Essa central deve possuir algumas configurações predefinidas pelo provedor, as quais não devem ser modificadas pelos clientes. Cada central de cliente possui um tronco SIP estabelecido com a central geral do provedor, e um ramal de emergência que pode ser usado para contatar a equipe de suporte. A central geral integra todas as centrais de clientes, e possui troncos SIP para chamadas VoIP externas e troncos para a PSTN. A partir dessa definição básica, cada equipe deve especificar o modelo de serviço de telefonia a ser oferecido aos clientes. Isso inclui a central do provedor E o modelo de central de cliente. Deve-se também definir a forma com que clientes podem configurar suas centrais, porém obedecendo às restrições impostas pelo provedor. O resultado dessa atividade final é:
|
18/04: Etapa 1: conclusão
Aula 18 |
---|
24/04: Etapa 1: apresentação
Aula 19 |
---|
25/04: Etapa 2: introdução
Aula 20 |
---|
Cada cliente possui um enlace de dados sem-fio com o provedor. Esse enlace usa roteadores sem-fio com alcance de até 5 km e taxas de transmissão típicas de redes IEEE 802.11n (150 Mbps). Nas redes dos clientes residem basicamente computadores, telefones IP, softphones e possivelmente outros equipamentos de uso cotidiano. Toda a implantação e configuração do enlace de dados é realizada pelo provedor, o que inclui o fornecimento do roteador sem-fio devidamente configurado.
Atividade
|
02/05: Etapa 2: configuração do cenário a ser utilizado
Aula 21 |
---|
A figura a seguir ilustra a infra-estrutura do provedor, e exemplifica um cliente.
|
08/05: Etapa 2: configuração do cenário a ser utilizado
Aula 22 |
---|
|
09/05: Etapa 2: integração com serviços de rede
Aula 23 | ||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Existem serviços de rede essenciais para o provedor, e que devem ser integrados à infraestrutura existente. São eles:
Na aula de hoje será feita uma revisão sobre DNS, e em seguida sua implantação para o provedor.
Integração com o DNS1. No arquivo /etc/bind/named.conf.local será criado o domínio nome-provedor.com.br e seu reverso: ... zone "nome-provedor.com.br" { type master; file "/etc/bind/nome-provedor.com.br"; }; zone "10.in-addr.arpa" { type master; file "/etc/bind/10.in-addr.arpa"; };
$TTL 86400 @ IN SOA ns1.nome-provedor.com.br. admin.nome-provedor.com.br. ( 2010033101 ; serial 1d ; refresh 1h ; retry 1w ; expire 1d ; negative cache ttl ) @ IN NS ns1 ns1 IN A IP-maquina-ns1 www IN CNAME ns1 servidor IN CNAME ns1
3. Configuração do DNS reverso, arquivo /etc/bind/10.in-addr.arpa: $TTL 86400 @ IN SOA ns1.nome-provedor.com.br. admin.nome-provedor.com.br. ( 2010033101 ; serial 1d ; refresh 1h ; retry 1w ; expire 1d ; negative cache ttl ) @ IN NS ns1.nome-provedor.com.br. 1.0.0 IN PTR ns1 4. Utilitário para testar o arquivo que contém o conteúdo de uma zona: named-checkzone nome_do_dominio arquivo_da_zona ==> Aponta possíveis erros no arquivo de configuração.
|
15/05: Etapa 2: integração com serviços de rede
- Realizar a avaliação docente através deste link
Aula 24 |
---|
16/05: Etapa 2: Novos serviços para o provedor: WWW
Aula 25 |
---|
O provedor pode implantar outros serviços úteis tanto para os clientes quanto para suas equipes de suporte e gerência. Um dos serviços mais difundidos e utilizados é WWW, em que documentos, recursos genéricos ou mesmo aplicações são disponibilizados segundo um modelo cliente-servidor. Exemplos de uso desse serviço são:
Hoje será feita uma revisão sobre o serviço WWW. Em seguida, algumas aplicações para esse serviço no provedor serão identificadas.
WWW e protocolo HTTPWWW (World Wide Web) é um sistema de documentos em hipermidia que são ligados e acessados na Internet (FONTE: Wikipedia). Tendo início em 1990 como uma aplicação experimental desenvolvida por Tim Berners-Lee, que então trabalhava no CERN, na Suíça, em pouco tempo caiu no gosto de demais usuários e se difundiu. WWW se tornou tão popular que para muitos passou a ser sinônimo de Internet (equivocadamente). Por trás da sua rápida aceitação há um protocolo de aplicação simples e funcional, além claro do modelo de informação em hipermidia que agradou as pessoas. Se o WWW é um sistema de documentoshipermidia online mantido de forma distribuída na Internet, o protocolo HTTP (Hypertext Transfer Protocol) é o protocolo usado para acessá-los. Esse protocolo segue o modelo cliente-servidor, e as comunicações são feitas com mensagens de pedido e resposta. Um cliente (navegador web) envia uma mensagem HTTP de pedido a um servidor web, que a responde com uma mensagem de resposta contendo o conteúdo solicitado. O protocolo HTTP usa o protocolo TCP para transmitir suas mensagens. Mensagens de pedido HTTPMensagens HTTP de pedido possuem a seguinte estrutura: Método URI HTTP/versão_do_protocolo
Cabeçalho1: valor do cabeçalho1
Cabeçalho2: valor do cabeçalho2
Cabeçalho3: valor do cabeçalho3
CabeçalhoN: valor do cabeçalhoN
corpo da mensagem
A primeira linha usa o campo método para indicar o tipo de pedido a ser realizado. O método HTTP pode ser entendido como um comando a ser realizado pelo servidor. Os métodos mais comuns são:
O campo URI (Uniform Resource Indicator) identifica o documento que o servidor deve acessar. Ele se aparenta com um caminho de arquivo (pathname), porém possui algumas extensões para poder enviar informação adicional. Os cabeçalhos servem para complementar o pedido, informando ao servidor mais detalhes sobre o que está sendo requisitado. Por fim, o corpo da mensagem é opcional, podendo conter dados a serem enviados ao servidor quando necessário. Tendo entendido os componentes de um pedido HTTP, segue abaixo um exemplo de uma requisição real (note que ela não possui corpo de mensagem): GET /wiki/ HTTP/1.1
Host: wiki.sj.ifsc.edu.br
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Cookie: wiki2010UserID=614; wiki2010UserName=Msobral; wiki2010Token=4ed97239498a2fc74596b0f0a62331b5; wiki2010_session=f4e6b1hl4ctlkbpe5gc5gkosi4
Connection: keep-alive
If-Modified-Since: Mon, 20 May 2013 00:38:20 GMT
Mensagens de resposta HTTPMensagens HTTP de resposta possuem a seguinte estrutura: HTTP/versão_do_protocolo status info
Cabeçalho1: valor do cabeçalho1
Cabeçalho2: valor do cabeçalho2
Cabeçalho3: valor do cabeçalho3
CabeçalhoN: valor do cabeçalhoN
corpo da mensagem
A linha inicial informa o resultado do atendimento do pedido (se teve sucesso ou não), contendo um código numérico de status seguido de uma breve descrição. Os códigos numéricos e info mais comuns são:
Após a linha inicial há os cabeçalhos, usados da mesma forma que em pedidos HTTP. Por fim, pode haver o corpo da mensagem (opcional). Um exemplo de mensagem de resposta segue abaixo: HTTP/1.1 200 OK
Date: Thu, 23 May 2013 20:43:31 GMT
Server: Apache
Last-Modified: Fri, 10 May 2013 14:09:58 GMT
ETag: "757236-40-4dc5db8df272a"
Accept-Ranges: bytes
Content-Length: 64
Vary: Accept-Encoding
Connection: close
Content-Type: text/plain; charset=UTF-8
Este é um pequeno arquivo de teste, sem informação útil ...
Captura de página somente HTML Captura de página HTML com uma figura Captura de página HTML com duas figuras
ApacheVer capítulo 26 da apostila. O servidor Apache (Apache server) é o mais bem sucedido servidor web livre. Foi criado em 1995 por Rob McCool, então funcionário do NCSA (National Center for Supercomputing Applications), Universidade de Illinois. Ele descende diretamente do NCSA httpd, um servidor web criado e mantido por essa organização. Seu nome vem justamente do reaproveitamento do NCSA httpd (e do fator de tê-lo tornado modular) fazendo um trocadilho com a expressão "a patchy httpd (um httpd remendável). Para ter ideia de sua popularidade, em maio de 2010, o Apache serviu aproximadamente 54,68% de todos os sites e mais de 66% dos milhões de sites mais movimentados. O servidor é compatível com o protocolo HTTP versão 1.1. Suas funcionalidades são mantidas através de uma estrutura de módulos, podendo inclusive o usuário escrever seus próprios módulos — utilizando a API do software. É disponibilizado em versões para os sistemas Windows, Novell Netware, OS/2 e diversos outros do padrão POSIX (Unix, GNU/Linux, FreeBSD, etc). Um servidor web é capaz de atender requisições para transferência de documentos. Essas requisições são feitas com o protocolo HTTP (HyperText Transfer Protocol), e se referem a documentos que podem ser de diferentes tipos. Uma requisição HTTP simples é mostrada abaixo: GET / HTTP/1.1 Host: www.ifsc.edu.br
Para o servidor Web, os principais componentes de uma requisição HTTP são o método HTTP a executar e o localizador do documento a ser retornado (chamado de URI - Uniform Resource Indicator). No exemplo acima, a requisição pede o método GET aplicado à URI /. O resultado é composto do status do atendimento, cabeçalhos informativos e o conteúdo da resposta. No exemplo, o status é a primeira linha (HTTP/1.1 200 OK), com os cabeçalhos logo a seguir. Os cabeçalhos terminam ao aparecer uma linha em branco, e em seguida vem o conteúdo (ou corpo) da resposta. Todo documento possui um especificador de tipo de conteúdo, chamado de Internet media Type. O cabeçalho de resposta Content-type indica o media type, para que o cliente HTTP (usualmente um navegador web) saiba como processá-lo. No exemplo acima, o documento retornado é do tipo text/html, o que indica ser um texto HTML. Outros possíveis media types são: text/plain (texto simples), application/pdf (um texto PDF), application/x-gzip (um conteúdo compactado com gzip). Um documento no contexto do servidor web é qualquer conteúdo que pode ser retornado como resposta a uma requisição HTTP. No caso mais simples, um documento corresponde a um arquivo em disco, mas também podem ser gerados dinamicamente. Existem diversas tecnologias para gerar documentos, tais como PHP, JSP, ASP, CGI, Python, Perl, Ruby, e possivelmente outras. Todas se caracterizam por uma linguagem de programação integrada intimamente ao servidor web, obtendo dele informação sobre como gerar o conteúdo da resposta. Atualmente, boa parte dos documentos que compõem um site web são gerados dinamicamente, sendo PHP, JSP e ASP as tecnologias mais usadas. Informações gerais sobre Apache no Ubuntu
Uma configuração básicaO servidor Apache precisa de algumas informações básicas para poder ativar um site:
Neste caso, para distinguir uma página Web da outra é utilizado um endereço de IP ou portas diferentes para cada um. Em caso de um servidor que possua mais de um endereço IP configurado, é possível associar cada Virtual Host a um destes IPs. Já se o servidor possui apenas um endereço IP, é possível distinguir cada Virtual Host por um número diferente de porta.
# O nome de servidor
ServerName www.prj.edu.br
# As portas onde se atendem requisições HTTP
Listen 8080
# Onde estão os documentos desse site
DocumentRoot /var/www/html/prj
# As restrições de acesso aos documentos
<Directory /var/www/html/prj>
Options Indexes
DirectoryIndex index.html index.php
order allow,deny
allow from all
</Directory>
Neste caso, para distinguir uma página Web da outra é verificado o parâmetro ServerName declarado dentro do arquivo de configuração de cada página Web.
<VirtualHost *:80>
# Onde estão os documentos desse site
DocumentRoot /var/www/html/prj2
# O nome de servidor
ServerName www.redes2.edu.br
# As restrições de acesso aos documentos
<Directory /var/www/html/prj2>
Options Indexes
DirectoryIndex index.html index.php
order allow,deny
allow from all
</Directory>
</VirtualHost>
AtividadeNa atividade abaixo, define-se um servidor WWW chamado www.<seu_domínio>.br, que atende requisições no ports 8080.
Obs.: Para criar páginas HTML um pouco mais completas você pode ler o tutorial disponível aqui Configuração no Servidor da equipe
|
22/05: Etapa 2: Email
Aula 26 |
---|
Ver capítulo 27 da apostila. O correio eletrônico (email) é um dos principais serviços na Internet. De fato foi o primeiro serviço a ser usado em larga escala. Trata-se de um método para intercâmbio de mensagens digitais. Os sistemas de correio eletrônico se baseiam em um modelo armazena-e-encaminha (store-and-forward) em que os servidores de email aceitam, encaminham, entregam e armazenam mensagens de usuários. Uma mensagem de correio eletrônico se divide em duas partes:
Received: from zeus.das.ufsc.br (zeus.das.ufsc.br [150.162.12.8])
by mx.google.com with ESMTP id e12si8422753vcx.66.2010.04.25.07.40.18;
Sun, 25 Apr 2010 07:40:19 -0700 (PDT)
Received: from submissoes.sbc.org.br (submissoes.sbc.org.br [143.54.31.12])
by zeus.das.ufsc.br (Departamento de Automacao e Sistemas (DAS-UFSC)) with ESMTP id BA97E7BD90
for <tele@ifsc.edu.br>; Sun, 25 Apr 2010 11:30:00 -0300 (BRT)
Received: from submissoes.sbc.org.br (localhost [127.0.0.1])
by submissoes.sbc.org.br (8.14.3/8.14.3/Debian-4) with ESMTP id o3PEZ70L029107
for <tele@ifsc.edu.br>; Sun, 25 Apr 2010 11:35:07 -0300
Received: (from www-data@localhost)
by submissoes.sbc.org.br (8.14.3/8.14.3/Submit) id o3PEZ7kH029104;
Sun, 25 Apr 2010 11:35:07 -0300
Date: Sun, 25 Apr 2010 11:35:07 -0300
Message-Id: <201004251435.o3PEZ7kH029104@submissoes.sbc.org.br>
From: WTR 2010 <lbecker@das.ufsc.br>
To: "Telê Santana" <tele@ifsc.edu.br>
Subject: Final version and registration
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
Dear Coach,
Please remember to upload the camera-ready version of your paper and to
register in the competition by April 27.
See you in Spain,
FIFA World Cup Staff - Spain - 1982
Na mensagem acima, os cabeçalhos são as linhas iniciais. Os cabeçalhos terminam quando aparece uma linha em branco, a partir de que começa o corpo da mensagem. Funcionamento do emailOs componentes da infraestrutura de email são:
A figura abaixo ilustra uma infraestrutura de email típica. Os protocolos envolvidos são:
EndereçamentoEndereços de email estão intimamente ligados ao DNS. Cada usuário de email possui um endereço único mundial, definido por um identificador de usuário e um domínio de email, escritos usando-se o símbolo especial @ (lê-se at, do original em inglês) para conectá-los: tele@ifsc.edu.br Nesse exemplo, o identificador de usuário é tele, e o domínio é ifsc.edu.br. Os domínios de email tem correspondência direta com domínios DNS. De fato, para criar um domínio de email deve-se primeiro criá-lo no DNS. Além disto, o domínio DNS deve ter associado a si um ou mais registros MX (Mail exchanger) para apontar os MTAs responsáveis por receber emails para o domínio. Por exemplo, o domínio DNS ifsc.edu.br possui esse registro MX: > dig ifsc.edu.br mx
;; QUESTION SECTION:
;ifsc.edu.br. IN MX
;; ANSWER SECTION:
ifsc.edu.br. 3581 IN MX 5 hermes.ifsc.edu.br.
... e o domínio gmail.com: > dig gmail.com mx
;; QUESTION SECTION:
;gmail.com. IN MX
;; ANSWER SECTION:
gmail.com. 3600 IN MX 20 alt2.gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 30 alt3.gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 40 alt4.gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 5 gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 10 alt1.gmail-smtp-in.l.google.com.
Um exemplo de MTA muito popular: PostfixO primeiro software MTA usado em larga escala na Internet foi o sendmail. Esse MTA possui muitas funcionalidades, e enfatiza a flexibilidade em sua configuração. No entanto, configurá-lo e ajustá-lo não é tarefa fácil. Além disto, houve vários problemas de segurança no passado envolvendo esse software. Assim outras propostas surgiram, como qmail e postfix. Tanto qmail quanto postfix nasceram como projetos preocupados com a segurança nas operações de um MTA, e também se apresentaram como MTAs mais simples de configurar e operar. Em nossas aulas será usado o postfix, mas recomenda-se experimentar usar as outras duas opcões citadas. O postfix é um MTA modularizado, que divide as tarefas de processamento das mensagens em diversos componentes que rodam como processos separados. Isto difere bastante do sendmail, que se apresenta como um software monolítico. No postfix, um conjunto de subsistemas cuida de processar cada etapa da recepção ou envio de uma mensagem, como mostrado na figura abaixo: Outros MTA populares são: Atividades
|
23/05: Etapa 2: integração com serviços de rede
Aula 27 |
---|
29/05: Etapa 2: monitoramento da rede do provedor
Aula 28 |
---|
O monitoramento da rede e dos serviços é essencial para garantir a disponibilidade do provedor. Quando problemas ocorrem, tais como quedas de links ou de servidores, a equipe técnica deve ser notificada o mais rápido possível para que possa repará-los. Devido à complexidade da estrutura do provedor, são necessárias ferramentas para auxiliar em seu monitoramento. NMS (Network Management System) é um sistema (incluindo hardware e software) onde se executam softwares para gerenciar uma rede de computadores. Um termo parecido para NMS é Network Monitoring System, que se trata de um tipo específico de software para monitorar elementos de rede e seus serviços (ex: HTTP, SMTP, LDAP, DNS).
Existem muitos sistemas de monitoramento de rede, uma vez que o acompanhamento eficiente da saúde da rede é uma tarefa fundamental da gerência. Em uma grande rede, composta de muitos servidores, equipamentos de rede e diversos serviços, a equipe responsável precisa de ferramentas de auxílio ao acompanhamento de seu bom funcionamento. Essas ferramentas devem idealmente não somente mostrar se os componentes da rede estão funcionando como esperado, mas também alertar os responsáveis quando identificar algo errado. Além disso, como existe dependência tanto entre serviços de rede quanto entre equipamentos (e entre ambos), essas ferramentas devem senão apontar a causa raiz dos problemas, ao menos localizar os prováveis candidatos. Finalmente, é desejável que esses sistemas identifiquem e mostrem tendências de eventos na rede, a partir do histórico de funcionamento de seus componentes. São portanto muitos requisitos para os NMS, os quais não são totalmente atendidos por todos os softwares existentes. Alguns NMS interessantes: Monitoramento com CactiCacti é um coletor de dados e gerador automático de gráficos para fins de monitoramento e histórico de desempenho. Os dados devem ser numéricos, para possibilitar a geração de gráficos. Uma interface web possibilita a administração e visualização dos gráficos, como se pode ver abaixo:
Muitos exemplos e tipos de dispositivos ou fontes de dados estão predefinidos no Cacti. Por exemplo, existem todas as definições para obter estatísticas de interfaces de rede usando SNMP. Como o cacti é muito flexível, podem-se criar novos tipos de fontes de dados, bastando definir como os dados devem ser coletados. Mas afinal o que é SNMP ??? Basicamente, SNMP é um protocolo de gerenciamento de redes que possibilita, dentre outras coisas, obter informações sobre elementos de rede. Porém primeiro será instalado o Cacti, e depois isso será investigado com maiores detalhes ... Instalando o cactiNo Ubuntu a instalação se mostra muito simplificada, pois o sistema de pacotes já configura todos os detalhes do cacti após a instalação. Se for instalado a partir do código fonte serão necessárias a configuração do banco de dados MySQL (para guardar informações administrativas. como definições de dispositivos, fontes de dados e gráficos) e a instalação de algumas extensões PHP.
Atividades
|
30/05: Etapa 2: monitoramento de eventos e geração de alertas na rede do provedor
Aula 29 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Cacti é útil para registrar a atividade e acompanhar o uso de recursos na rede, porém não para identificar automaticamente situações que requeiram atenção da equipe técnica. O monitoramente de recursos para geração de alertas pode ser realização por outras ferramentas de gerenciamento, tais como Nagios. Basicamente, o Nagios é uma plataforma configurável de monitoramento de serviços e equipamentos de rede, capaz de emitir alertas e de efetuar ações de recuperação de falhas. Cada serviço ou tipo de equipamento pode ser monitorado com um plugin especializado, que assim efetua testes de disponibilidade sob medida. Por exemplo, um plugin de monitoramento do serviço HTTP (Web) pode tentar buscar uma ou mais páginas, e analisar tanto o status da resposta do servidor quanto o tempo que levou para obtê-la. A dependência entre os serviços pode ser configurada, de forma que ao se detectarem falhas por diferentes plugins, o Nagios possa apontar a causa raiz do problema. O ponto de partida do Nagios é a descrição da rede e de todos os serviços a serem monitorados. Cada monitoramento de serviço ou equipamento precisa ser parametrizado (por exemplo, quais os atrasos de resposta aceitáveis para o roteador de um link), para que se possam identificar as situações anômalas. Essas informações residem na configuração do Nagios, e precisam ser criadas manualmente.
Instalação
Exemplos de configuraçõesA configuração do Nagios fica no diretório /etc/nagios3. Todos os arquivos mencionados abaixo se referem a esse diretório, salvo se for indicado o contrário. O arquivo de configuração principal se chama nagios.cfg, que contém opções globais e inclusões de outros arquivos com configurações específicas. Em particular, arquivos que tratam de objetos monitorados e informacões relacionadas (hosts, serviços, comandos e templates). ficam dentro do subdiretório objects. Definições de hostsPara configurar o Nagios, devem-se primeiro criar definições de hosts (equipamentos monitorados). Esas definições ficam em algum arquivo dentro do subdiretório conf.d, o qual deve estar incluído em nagios.cfg (veja o exemplo contido em localhost_nagios2.cfg). Cada host definido é automaticamente monitorado com PING, de forma a verificar se está no ar. Um host é declarado como a seguir: define host{
use generic-host ; Nome do template de host a ser usado
; Este host irá herdar toas a variáveis que estão definidas
; no template linux-server (ou que foram herdadas por ele).
host_name gateway ; nome do host na rede
alias Gateway do Lab. ; Descrição do host
address 192.168.2.1
parents localhost ; qual o próximo host em direção ao Nagios
}
O uso de templates simplifica a definição de hosts, pois evita a repetição de muitas opções comuns (veja como seria a definição completa de um host). Os templates estão nos arquivos generic-host_nagios2.cfg e generic-service_nagios2.cfg. A opção parents tem grande importância para possibilitar que o Nagios faça a distinção entre hosts ou serviços falhos ou inalcançáveis. O primeiro caso trata de serviços cujos testes programados falharam, e o segundo caso são aqueles que não podem ser testados, porque dependem de um host intermediário (um gateway) que falhou. Assim pode-se evitar a emissão de alertas para todos os serviços, concentrando-os na causa raiz do problema. Definições de serviçosEm cada host devem ser criadas definições de serviços a serem monitorados. Cada serviço possui um comando de verificação específico, para que o teste seja mais fidedigno. Duas definições de serviços são mostradas abaixo (para IMAP e DNS): define service{
use generic-service ; Nome do template de serviço a ser usado
host_name localhost ; Host onde reside o serviço
service_description IMAP
check_command check_imap ; Comando para verificar o serviço
notifications_enabled 0 ; Notificações desabilitadas
}
define service{
use generic-service
host_name localhost
service_description DNS
check_command check_dns
notifications_enabled 0
}
Assim como no caso de hosts, usam-se templates para evitar a repetição de opções de uso comum (ver definição completa de um serviço). Definições de comandosOs comandos de verificação de serviço são programas especializados, e que são fornecidos pelo pacote nagios-plugins (que foi instalado junto com o Nagios). A lista de plugins segue abaixo:
msobral@ger:~$ cd /usr/lib/nagios/plugins
msobral@ger:/usr/lib/nagios/plugins$ ./check_dns -h
check_dns v1.5 (nagios-plugins 1.5)
Copyright (c) 1999 Ethan Galstad <nagios@nagios.org>
Copyright (c) 2000-2008 Nagios Plugin Development Team
<nagiosplug-devel@lists.sourceforge.net>
Esse complemento utiliza o programa nslookup para obter o endereço IP do host/domínio consultado.
Um servidor DNS opcional pode ser especificado.
Se um servidor DNS não é especificado, o(s) servidor(es) padrão(es) no arquivo /ect/resolv.conf serão utilizados.
Uso:
check_dns -H host [-s server] [-a expected-address] [-A] [-t timeout] [-w warn] [-c crit]
Opções:
-h, --help
Imprime uma tela de ajuda detalhada
-V, --version
Imprime informação da versão
--extra-opts=[seção][@arquivo]
Ler opções de um arquivo ini. Veja http://nagiosplugins.org/extra-opts
para exemplos de utilização.
-H, --hostname=HOST
O nome ou endereço que você deseja consultar
-s, --server=HOST
Servidor DNS opcional que você que utilizar para fazer consultas
-a, --expected-address=IP-ADDRESS|HOST
ENDEREÇO-IP opcional que você espera o servidor DNS retornar. SERVIDOR deve acabar com
um ponto (.). Essa opção pode ser repetida várias vezes (Retorna OK se qualquer
corresponde ao valor). Se vários endereços são retornados de uma vez, você tem que combinar
a cadeia completa de endereços separados por vírgulas (ordenados alfabeticamente)
-A, --expect-authority
Opcionalmente a espera pelo servidor DNS deve ser autorizada para a pesquisa
-w, --warning=seconds
Retorna um aviso se o tempo decorrido exceder o valor. Padrão off
-c, --critical=seconds
Retorno crítico se o tempo decorrido exceder o valor. Padrão off
-t, --timeout=INTEIRO
Segundos antes da conexão expirar (padrão: 10)
Enviar e-mail para nagios-users@lists.sourceforge.net se você tiver dúvidas
quanto ao uso deste software. Para enviar correções ou sugerir melhorias,
enviar e-mail para nagiosplug-devel@lists.sourceforge.net
msobral@ger:/usr/lib/nagios/plugins$
Nem todos os plugins acima são adicionados automaticamente à configuração do Nagios na instalação. O arquivo commands.cfg contém os comandos preconfigurados. Assim, caso seja necessário adicionar um plugin que ainda não esteja ali (ex: check_dns), deve-se criar uma definição de comando: define command{
command_name check_dns
command_line $USER1$/check_dns -H www.google.com.br -s $HOSTADDRESS$
}
O importante acima é a definição de como o plugin deve ser executado, incluindo os parâmetros que devem ser passados. Alguns parâmetros são predefinidos pelo Nagios, estando disponíveis em macros:
Para exemplificar como passar parâmetros para os plugins, veja o caso de um teste do tipo PING: define service{
host_name linuxbox
service_description PING
check_command check_ping!200.0,80%!400.0,40%
}
O comando check_ping deve ser chamado com dois argumentos (separados por !): 200.0,80% e 200.0,80%. A definição do comando check_ping, por sua vez, os utiliza da seguinte forma: define command{
command_name check_ping
command_line $USER1$/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$
}
Ativando as novas configuraçõesSempre que modificar a configuração o Nagios deve ser reiniciado: sudo service nagios restart
Caso ocorra um erro, e o nagios não inicie, significa que existe um ou mais erros nos arquivos de configuração. Para encontrá-los execute o nagios com a opção -v, que faz uma verificação desses arquivos: $ cd /usr/local/nagios
$ bin/nagios -v etc/nagios.cfg
Total Warnings: 3
Total Errors: 0
Things look okay - No serious problems were detected during the pre-flight check
Atividades
|
05/06: Etapa 2: SNMP
Aula 30 |
---|
Desde o lançamento da primeira versão, na década de 80, o SNMP mantém-se como um protocolo simples de gerenciamento e é amplamente utilizado no gerenciamento de sistemas na Internet. Por isso, esse modelo também é denominado de Modelo da Internet de Gerenciamento. O modelo SNMP, e a maior parte dos sistemas de gerenciamento disponíveis, se baseia no modelo Agente/Gerente, que normalmente é formado pelos seguintes elementos:
O protocolo SNMPO protocolo SNMP transmite as informações das operações de gerência entre gerente e agentes. Ele usa o protocolo UDP, com port padrão 161. Há quatro comandos básicos (SNMPv1) que operam em modo comando-resposta (com exceção de TRAP):
Nomenclatura de objetos na MIBTodos os objetos acessados pelo SNMP devem ter nomes únicos definidos e atribuídos. Além disso, o Gerente e o Agente devem concordar sobre os nomes e significados das operações GET e SET. O conjunto de todos os objetos SNMP é coletivamente conhecido como MIB (do inglês: Management Information Base). O padrão SNMP não define o MIB, mas apenas o formato e o tipo de codificação das mensagens. A especificação das variáveis MIB, assim como o significado das operações GET e SET em cada variável, são especificados por RFCs próprios. Cada variável em uma MIB se chama objeto da MIB, e é definida usando a linguagem de descrição de dados SMI. Um dispositivo de rede pode ter muitos objetos, que correspondem aos diferentes elementos de hardware e software nele contidos. Para possibilitar que novos objetos de MIB sejam facilmente definidos, grupos de objetos de MIB relacionados estão definidos em RFCs separadas chamados de módulos MIB.
.iso.org.dod.internet.mgmt.mib-2.application
.1.3.6.1.2.1.27.1.1.8.2
system.syslocation.0 ... corresponde na verdade ao OID: .iso.org.dod.internet.mgmt.mib.system.syslocation.0 Software net-snmpO projeto net-snmp provê uma implementação de um agente SNMP e de utilitários para fazer operações sobre MIBs (assim, fornece também a base para a implementação de um gerente). Para instalá-lo deve-se executar: sudo apt install -y snmpd
Esse pacote contém os seguintes programas:
O agente SNMP vem preconfigurado para atender somente requisições vindas de localhost (127.0.0.1). Edite o arquivo /etc/snmp/snmpd.conf, e modifique a variável agentAddress para que ele aceite requisições vindas de outras interfaces. Ela pode ficar desta forma: agentAddress udp:0.0.0.0:161
Atividades
|
06/06: Etapa 2: Conclusão
Aula 31 |
---|
Na aula de 25/04 foi introduzida a etapa 2, quando se apresentou o cenário a ser implantado para o provedor (ilustrado na figura a seguir). Além de prover acesso a Internet a seus clientes, o provedor oferece um serviço de telefonia IP com centrais privativas para cada cliente. Essas centrais são virtualizadas e hospedadas no datacenter do provedor, cabendo aos clientes administrá-las. Serviços de rede essenciais são também mantidos pelo provedor, tais como DNS e WWW. Por fim, o provedor monitora os recursos de sua rede para fins de contabilização de uso de recursos (ex: utilização dos links) e detecção de falhas.
Avaliação
|
12/06: Etapa 2: Conclusão
Aula 32 |
---|
13/06: Etapa 2: Apresentação
Aula 33 |
---|
19/06: Etapa 3: Avaliação de desempenho da infraestrutura VoIP do provedor
Aula 34 |
---|
Após a implantação do provedor, é necessário avaliar sua infraestrutura VoIP. Com isso pode-se dimensionar a quantidade de clientes que podem ser atendidos, e a qualidade das chamadas por eles realizadas. Essa avaliação envolve:
|
20/06: Etapa 3: Avaliação de desempenho da infraestrutura VoIP do provedor
Aula 35 |
---|
O objetivo da aula de hoje é o uso das ferramentas listadas na Aula 34.
|