Mudanças entre as edições de "Redes Multimídia (diário 2017-1)"

De MediaWiki do Campus São José
Ir para navegação Ir para pesquisar
Linha 1 168: Linha 1 168:
 
exten=> 7777,n,Hangup
 
exten=> 7777,n,Hangup
 
</syntaxhighlight>
 
</syntaxhighlight>
 +
 +
==== Extensões especiais ====
 +
 +
Além das extensões criadas pelo usuário, o Asterisk apresenta algumas extensões especiais, tais como:
 +
* '''s ''(start)'':''' tem por objetivo tratar qualquer chamada que entre em um contexto e que não tenha um destino específico.
 +
* '''i ''(invalid)'':''' tem por objetivo tratar entradas inv ́lidas em um menu interativo
 +
* '''t ''(timeout)'':''' Em um menu interativo intercepta a chamada caso o usuário não forneça uma entrada dentro de um período de tempo estipulado.
  
 
{{Collapse bottom | Aula 12}}
 
{{Collapse bottom | Aula 12}}

Edição das 18h08min de 1 de fevereiro de 2017

Endereço encurtado: http://bit.ly/rmu20162


Redes Multimidia: Diário de Aula 2017-1

Professora: Simara Sonaglio
E-mail: simara.sonaglio@ifsc.edu.br
Encontros:
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

Diário das aulas

13/02 - Apresentação da disciplina

Aula 1

Apresentação da disciplina: conteúdo, bibliografia e avaliação, laboratório.

14/02 - Etapa Asterisk: Introdução, plano de discagem e contas SIP

Aula 2

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

Voip-call.png


Nas nossas aulas faremos uso de um PBX IP Asterisk, que é um software desenvolvido pela Digium. O Asterisk roda em computadores do tipo PC que possuem sistema operacional baseado em Linux. Sua licença é livre, o que significa que não há custo de licenciamento para utilizá-lo.

PBX IP Asterisk


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)


Asterisk-ex1.png
Exemplo de cenário de uso do Asterisk


Canais SIP

Cada 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 ; 
context=alunos ; o contexto do plano de discagem para chamadas originadas neste canal
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 ;
context=alunos ; o contexto no plano de discagem para chamadas originadas neste canal
disallow=all
allow=gsm ; habilita este codec
allow=alaw ; outro codec
allow=ulaw ; mais um codec
qualify=yes; monitora o UAC


Plano de discagem

O 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:

Asterisk-fluxo.png


Um exemplo de plano de discagem simples pode ser visto 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=>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
  • identificador: o número ou usuário chamado
  • prioridade: a prioridade da extensão. Isso determina a ordem de execução das extensões que tratam do mesmo identificador.
  • aplicação: uma ação a ser realizada quando a extensão for processada. Por exemplo, a aplicação Dial determina que deve ser encaminhada a outro canal.

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
  • same: declara uma nova extensão com mesmo identificador da extensão imediatamente anterior

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


Experimento: comunicação entre telefones IP ou softphones por meio de um PBX IP

Para realizar esses exercícios você deve usar o Asterisk em uma máquina virtual. Para testar as chamadas, use um softphone em seu celular ou em um computador, e um telefone IP ou ATA.


1. Criar os seguintes canais SIP: 100 e 101 (escolha usuários e senhas para autenticação)

2. Crie um plano de discagem em que todos podem fazer chamadas para todos (isso é, 100 pode chamar 101, e vice-versa).

3. Agora configure o softphone de forma que se registre no PBX Asterisk, usando uma das contas SIP criadas previamente. Faça o mesmo com o telefone IP ou ATA.

4. A partir do softphone faça uma chamada para a conta do telefone IP. Verifique se o telefone IP 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.

5. Execute o comando rasterisk -vvv no computador do Asterisk.

6. Usando o comando sip show peers, visualize os estados dos canais SIP conhecidos pelo Asterisk.

7. Refaça uma chamada entre softphone e telefone IP, e observe o que aparece na tela do rasterisk.

8. Será possível verificar que chamadas estão em andamento no Asterisk usando o rasterisk ? Pesquise como se pode fazer isso.

9. Use o rasterisk para testar chamadas. Use o comando console dial canal_SIP@contexto para chamar um canal SIP (substitua canal_SIP pelo número a ser chamado). Ao final, execute console hangup.

10. Acrescente mais um canal SIP, editando o arquivo sip.conf. Configure o softphone para usar esse novo canal (ou o telefone IP para se associar também a esse canal SIP).

11. Teste chamadas entre os telefones usando esse novo número.

Possíveis problemas

  1. Em cada softphone ou telefone IP crie uma conta SIP, que deve ser identificada por ramal@IP_do_PBX (ex: se o PBX tiver IP 192.168.2.110, as contas de alunos podem ser 100@192.168.2.110 e 101@192.168.2.110).
  2. Após definir as contas, verifique se os telefones indicaram que elas estão disponíveis (online). Você pode fazer essa verificação também no próprio Asterisk. Neste caso execute o seguinte comando para acessar o console do Asterisk:
    sudo rasterisk -vvv
    host*CLI> sip show peers
    host*CLI> sip show peers
    Name/username              Host             Dyn Nat ACL Port     Status     
    101/101                    192.168.2.10       D          11270    OK (6 ms)
    102/102                    192.168.2.210      D          63169    OK (12 ms)
    2 sip peers [Monitored: 2 online, 0 offline Unmonitored: 0 online, 0 offline]
    
  3. Se algum dos telefones não aparecer como OK no console do Asterisk, verifique se o número de ramal e a senha configuradas no telefone são os mesmos declarados em /etc/asterisk/sip.conf. Outro teste que se pode fazer é acessar o console do Asterisk, e depois tentar ativar as contas SIP nos telefones (i.e. colocá-las para indisponível ou offline, e depois reativá-las). O Asterisk irá mostrar algumas linhas informativas sobre os registros dos telefones..
  4. Se as contas SIP estão devidamente registradas no Asterisk, mas ainda assim as chamadas não são realizadas, o problema deve estar no plano de discagem. Neste caso, acesse o console do Asterisk e tente novamente fazer a chamada. Veja se o Asterisk informa na tela o motivo para a chamada não ser realizada. Em seguida, confira se seu plano de discagem (/etc/asterisk/extensions.conf) possui uma extensão que satisfaça a chamada que se deseja realizar. Isso é, se você estiver tentando chamar o ramal SIP 101@192.168.2.110, deve haver uma extensão assim:
    exten=>101,1,Dial(SIP/101)
    same=>n,Hangup
    

DICAS ASTERISK

Comandos válidos no CLI do Asterisk:

  1. Para entrar no CLI do Asterisk execute: rasterisk -vvv</syntaxhighlight>
  2. Recarregar as configurações do arquivo sip.conf: sip reload</syntaxhighlight>
  3. Recarregar as configurações do arquivo extensions.conf: dialplan reload</syntaxhighlight>
  4. Ver canais SIP criados: sip show peers</syntaxhighlight>
  5. Gerar uma ligação via console: console dial canal_sip@extensão</syntaxhighlight>

20/02 - Etapa Asterisk: Caracterização de mídia

Aula 3

Compressão de áudio

Técnicas usadas:

  • Remoção de silêncio
  • Uso de psicoacústica
  • Remoção de redundância


Exemplo de codificação:

Audio-codec.png

21/02 - Etapa Asterisk: Caracterização de mídia

Aula 4

Compressão de vídeo

Técnicas usadas para compressão de video:

  • Remoção de redundância espacial - codificação intraquadros (ex: JPEG)
  • Remoção de redundância espacial e temporal - codificação intraquadros e interquadros (H.261, MPEG)


Remoção de redundância temporal: iniciando com um intraquadro (quadro I), quadros sucessivos contém atualizações relativas a quadros anteriores (quadros P) ou a quadros anteriores e posteriores (quadros B). O conjunto de quadros entre quadros I se chama GOP (Group of Pictures):


Gop.png


Exemplos de codecs de video

  • MPEG-2
  • H-264
  • XVID
  • Theora

Exemplos de formatos de video usados em MPEG2 (i.e. em DVD): Mpeg2-video-formats.png

06/03 - Etapa Asterisk: Transmissão de mídia

Aula 5

A transmissão de dados multimidia está sujeita a alguns fatores, destacando-se:

  • Banda disponível: cada tipo de transmissão demanda uma certa banda mínima (ver o exemplo dos videos gerados na aula anterior, que demandam em torno de 250 kbps). A banda requerida depende do codec, podendo mesmo ser variável (ver figura abaixo). Se a banda disponível na rede não for suficiente, a reprodução dos dados transmitidos não será possível (quer dizer, a reprodução contínua simultânea ao recebimento dos dados).
    Rt-transmission.png
  • Atrasos fim-a-fim: alguns tipos de transmissão são mais sensíveis a atrasos fim-a-fim, como por exemplo conversações VoIP, porém todas transmissões de dados multimidia apresentam pouca tolerância a variações de atraso. A variação de atraso excessiva causa a perda de sincronismo entre a transmissão e a recepção, impedindo a reprodução contínua dos dados recebidos.

Componentes do atraso fim-a-fim

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

Atraso Descrição Tipo Expressão
(F: tamanho de um pacote em bytes,
B: taxa de bits do link)
Transmissão Tempo entre o início da saída do 1o bit até a saída do último bit de um pacote pela interface de rede. Depende basicamente da taxa de bits do link onde se dá a transmissão. Variável (depende do tamanho do pacote)
Propagação Tempo entre a saída do 1o bit de um pacote da interface de rede do equipamento transmissor, e sua chegada na interface de rede do equipamento receptor. Depende basicamente da latência do meio de transmissão. Constante
Processamento Tempo entre a recepção de um pacote e a ação a ser feita sobre ele dentro de um equipamento de rede (seja encaminhá-lo por outro link, ou entregá-lo a uma aplicação que o consumirá) Usualmente desprezível
Enfileiramento Tempo de espera de um pacote na fila de saída de uma interface de rede por onde deve ser transmitido. Depende de quantos pacotes (e quantos bytes) estão na sua frente nessa fila. Variável


No exemplo abaixo, os links LAN (link1, link2, link7 e link8) possuem taxa de 1 Gbps, e os links WAN (demais links) possuem taxa de 10 Mbps. As filas dos roteadores podem conter até 100 pacotes de 1500 bytes (tamanho máximo de pacote). Os links WAN possuem latência de 2 ms (a dos links LAN é desprezível). Sendo assim, calcular o atraso mínimo e máximo que cada pacote pode sofrer entre sua saída do servidor de video e sua chegada no reprodutor. Os pacotes de vídeo têm tamanho de 1500 bytes:

Componentes-atraso.png

Atrasos de transmissão nos links WAN:
Atrasos de transmissão nos links LAN:
Atraso de enfileiramento em roteador: melhor caso
(fila vazia)
Atraso de enfileiramento em roteador: pior caso
(fila cheia):

O menor atraso pode ser calculado assim:


... e o maior atraso possível é:

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 (o caso do Youtube é um pouco mais complicado, pois sua infraestrutura é baseada em um tipo de CDN).

Se cada pacote está sujeito a um atraso variável, o reprodutor de video no receptor precisa de algum mecanismo para compensar essas variações e apresentar o video de forma contínua. O mesmo raciocínio vale para transmissões de audio.

Estratégias para tratar a variação de atraso

Mecanismos para compensar atraso e variação de atraso da rede:

  • Numerar cada mensagem com um número de sequência.
  • Registrar o instante em que cada mensagem foi gerada (i.e. registrar seu timestamp).
  • Atrasar a reprodução do conteúdo no receptor, para compensar variações de atraso.

Rt-traffic.png
Atrasos devido a transmissão


Esses mecanismos são combinados nas seguintes estratégias para compensar variação de atraso:


Atraso de reprodução fixo

Compensa atrasos de mensagens com a imposição de um atraso fixo q no reprodutor de midia. Mensagens recebidas após seu instante de reprodução (i.e. chegam após timestamp + q) são descartados.


Atraso-de-reproducao-fixo.png
Atraso de reprodução: midia será tocada somente no instante , sendo que . O atraso q corresponde ao atraso de reprodução imposto do lado do cliente, para compensar variações de atraso das mensagens.


Por exemplo, uma sequência de mensagens pode ser reproduzida da seguinte forma se for imposto um atraso fixo:

Atraso-de-reproducao-fixo2.png

Atraso de reprodução adaptativo

Procura minimizar o atraso de reprodução, estimando o atraso da rede e sua variação. O atraso de reprodução assim calculado é imposto no receptor antes de cada rajada de mensagens (isso faz mais sentido em transmissão de voz).


Por exemplo, uma sequência de mensagens pode ser reproduzida da seguinte forma se for imposto um atraso adaptativo:

Atraso-de-reproducao-adaptativo-1.png


Se uma determinada mensagem se atrasar além do tolerável, será descartada (não reproduzida):

Atraso-de-reproducao-adaptativo-2.png

Estratégias para abrandar a perda de mensagens

Reprodução de mensagens perdidas inadequada para aplicações interativas

  • Mensagens que realmente não chegaram
  • Mensagens que chegaram após instante de reprodução


Técnicas para abrandar a perda de mensagens e preservar uma boa (?!) qualidade de áudio

  • Correção antecipada de erros (FEC - Forward Error Correction)
  • Intercalação

Correção antecipada de erros

Emissor envia dados redundantes em suas mensagens, também conhecidos como um código de correção de erro.

Exemplo 1: envio de uma mensagem redundante para cada grupo de n mensagens. A mensagem redundante é calculada fazendo XOR das demais mensagens do grupo.

  • Tolera a perda de 1 mensagem
  • Aumento de banda de 1/n

Rmu-fec.png
Uso de mensagem redundante com XOR


Exemplo 2: envio de fluxos redundantes de diferentes qualidades.

  • Pode-se enviar um fluxo de qualidade inferior junto com o fluxo principal.

Intercalação

Consiste no resequenciamento das unidades de áudio antes de transmiti-las, de forma que unidades que estavam originalmente próximas sejam separadas por uma certa distância no fluxo a ser transmitido.

No exemplo abaixo, cada unidade de áudio tem 5 ms, e cada mensagem contém quatro unidades (totalizando 20 ms).


Rmu-intercalacao.png

Atividade

Pesquise sobre o uso de técnicas de abrandamento de perdas de mensagens em diferentes tipos de transmissão de midia: VoIP, video, radio on-line, ...

07/03 - Etapa Asterisk: Estudo do protocolo SIP

Aula 6

O protocolo SIP

O 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: mensagens de texto individuais trocadas entre agentes.
  • Transação: sequência de mensagens entre dois agentes iniciando com uma requisição e terminando com uma resposta final.
  • Diálogo: uma relação entre dois agentes que persiste por algum tempo, e identificada por um Call-ID.
  • Chamada: composta por todos os diálogos originados por um agente.

Sip-relation.gif
'Mensagens, transações, diálogos e chamadas

Mensagens SIP

O 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):


Sip-example1.png


Pedido:

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.


  • Métodos SIP:


Método SIP Descrição
REGISTER Usado por um agente para notificar a rede SIP (outros agentes) sobre sua URI de contato
INVITE Usado para estabelecer sessões entre dois agentes
ACK Confirma respostas finais a requisições INVITE
BYE Termina uma sessão previamente estabelecida
CANCEL Encerra tentativas de chamadas
OPTIONS Consulta um agente sobre suas capacidades

Tabela de métodos SIP (não exaustiva ... apenas os principais métodos)


  • Mensagens de resposta:
  1. Mensagens informativas (classe 1XX): Usadas pelo servidor para indicar o progresso da transação SIP;
  2. Mensagens finais (classes 2XX, 3XX, 4XX, 5XX e 6XX): Respostas finais que encerram a transação SIP.


Classe Funcionalidade Exemplo
1XX Informativa 180 Ringing
2XX Sucesso 200 OK
3XX Redirecionamento 302 Moved Temporarily
4XX Falha de requisição 404 Not Found
5XX Falha em servidor 503 Service Unavailable
6XX Falha global 600 Busy Everywhere


  • Cabeçalhos SIP:


Cabeçalho SIP Descrição Obrigatoriedade Uso
Via Registra a rota seguida por uma requisição, sendo usado para que respostas sigam o caminho inverso Requisição e resposta Requisição e resposta
To Identifica o destinatário de uma requisição Requisição e resposta Requisição e resposta
From Identifica o originador da requisição Requisição e resposta Requisição e resposta
Call-Id Identifica univocamente uma chamada entre um UAC e um UAS. Requisição e resposta Requisição e resposta
CSeq Numera as requisições de uma mesma chamada de um mesmo UAC Requisição Requisição e resposta
Contact Identifica o originador da requisição ou o recurso requisitado Requisição e resposta
Max-Forwards Máximo número de saltos que a requisição pode atravessar Requisição Requisição
Content-Length Informa a quantidade de bytes do corpo da mensagem Requisição e resposta
Date Informa a data e horário de uma requisição ou resposta Requisição e resposta
Supported Lista uma ou mais opções suportadas por um UAC ou UAS Requisição e resposta
User-Agent Informa sobre o agente (o programa) originador de uma requisição
Allow Informa os métodos SIP aceitos pelo UAS Resposta
Content-type Informa o tipo de conteúdo contido no corpo da mensagem
WWW-Authenticate Informa que o UAC deve se autenticar para o UAS (e como isso deve ser feito) Resposta
Authorization Contém as credenciais para autenticar o UAC para o UAS Requisição

Tabela de cabeçalhos SIP (não exaustiva ... apenas os principais cabeçalhos)

Diagramas de chamadas

Alguns tipos de chamadas VoIP com SIP são recorrentes, estando representadas nas subseções a seguir.

Registro de agente SIP em um proxy SIP

Esta 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 SIP

Uma 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 SIP

A 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 media

Este 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-INVITE

O 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 wireshark

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

13/03 - Etapa Asterisk: Estudo do protocolo SIP e SDP

Aula 7

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:

  • Endereço IP
  • Perfil RTP (usualmente RTP/AVP)
  • Número de port do protocolo de transporte (usualmente UDP)
  • Tipo de midia (audio, video, e possivelmente outros)
  • Esquema de codificação de midia (o tipo de codec a ser usado)
  • Assunto da sessão (uma descrição)
  • Horários de início e fim
  • Identificação do contato da sessão

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:

Sdp-fields.png
Tabela de campos SDP


Um exemplo de mensagem SDP segue abaixo:

Sdp-msg.png


A descrição completa de cada campo, e os possíveis valores que ele pode assumir, pode ser lida nas referências (em especial, este capítulo de livro).

14/03 - Etapa Asterisk: Estudo do protocolo RTP

Aula 8

Protocolo RTP


O protocolo RTP (Real-Time Protocol) foi desenvolvido para possibilitar o transporte de datagramas de tempo-real contendo voz, video, ou outro tipo de dados, sobre IP. Tanto H.323 quanto o modelo SIP usam RTP para o transporte de media, tornando-o o padrão mais comum para comunicações desse tipo na Internet. Apesar desse protocolo não prover qualidade de serviço (i.e. ele não possui mecanismos para atender tais tipos de requisitos), ele torna possível a detecção de alguns dos problemas introduzidos por uma rede IP, tais como:

  • Perda de pacotes
  • Atraso fim-a-fim variável
  • Chegada de pacotes fora de ordem


Esses problemas não são novidade ... nós já os discutimos nas aulas sobre transmissão de dados multimidia. O que há de novo é um protocolo que dá subsídios para as técnicas que buscam atender requisitos de qualidade de serviço. Esses subsídios são informações providas pelo RTP para ajudar a identificar os problemas citados acima, as quais são:

  • Identificação do tipo do conteúdo que está sendo carregado (codec): isso informa ao receptor como ele deve decodificar o conteúdo transportado (ver esta tabela de identificadores de codec usados pelo RTP)
  • Numeração de sequência: essa informação possibilita identificar pacotes perdidos ou fora de ordem.
  • Marcação de tempo (timestamp): com isso é possível efetuar o cálculo de variação de atraso e implementar algum mecanismo de sincronização com a fonte (ex: atraso de reprodução).


Essas informações fazem parte da PDU RTP, como se pode ver a seguir:

Localização do RTP na camada de transporte Cabeçalho RTP
Rtp1.png Tip-Rtp-header.png


Tip-Rtp-avp.png
Perfil RTP/AVP, com codecs e seus códigos numéricos

RTCP

Alé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:

  • Número de pacotes enviados e recebidos
  • Número de pacotes perdidos
  • Jitter (variação de atraso)

Os cinco tipos de relatórios são:

  • Relatório do transmissor (Sender Report - SR)
  • Relatório do receptor (Receiver Report - RR)
  • Descrição da fonte (Source Description - SDES)
  • Bye
  • Específico da aplicação (Application Specific - APP)

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.

20/03 - Etapa Asterisk: Análise dos protocolos SIP, SDP e RTP utilizando o wireshark

Aula 9


21/03 - Etapa Asterisk: Asterisk e NAT

Aula 10

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:

  • Informando o endereço IP e port UDP que de fato aparecerão para a rede externa: proposta do STUN e ICE, porém nem sempre funciona (STUN) ou é complicado (ICE).
  • Usando gateway de midia: abordagem mais comum, por ser mais fácil de ser implantada e dar bons resultados.

Usando o Asterisk para contornar NAT

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

Se for o Asterisk que está atrás de NAT, então deve-se configurar seu IP válido, de forma que o PBX possa informá-lo nas mensagens SDP para as streams de audio. Para isso, deve-se acrescentar em sip.conf na seção [general] [1]:

[general]
externip=IP_público

; devem-se informar as redes privativas onde está o Asterisk (pode haver mais de uma ... basta repetir o 
; atributo localnet para cada subrede). Isso é importante para que o Asterisk saiba quando usar o IP
; público (para telefones fora de sua rede) ou privativo (telefones dentro de sua rede) nas mensagens
; SDP que especificam o IP e port UDP para as streams RTP.
localnet=prefixo/máscara


OBS: isso só funciona quando o Asterisk está no caminho da stream de áudio. No caso de telefones VoIP que conversam diretamente, só resta STUN ou alguma outra técnica do tipo ...

Atividade - Softphone atrás de NAT

Cenário1-Aula7.png

  1. A comunicação entre canais SIP internos a cada PABX IP de cada aluno deve estar funcionando corretamente (completamento e áudio) tanto com REINVITE como SEM REINVITE;
  2. A comunicação entre canais SIP de diferentes PABX IP deve estar funcionando corretamente tanto com REINVITE como SEM REINVITE;
  3. Cada aluno deve montar uma estrutura de rede que será apresentada em aula utilizando AP TP-LINK;
  4. Fazer as devidas configurações para que tenha áudio nas comunicações entre os diferentes PABX IP.


Dica para testar o áudio

Para testar o áudio com apenas um softphone logado você pode criar uma extension no arquivo extensions.conf que toque uma música. Segue abaixo:

exten=>999,1,Answer exten=>999,n,Playback(tt-monkeys) exten=>999,n,Hungup()</syntaxhighlight>

Atividade - Asterisk atrás de NAT

Cenário1-Aula8.png

  1. Configurar a rede indicada na figura acima;
  2. Abrir o Wireshark na máquina onde o Asterisk está instalado;
  3. Tentar registrar um usuário SIP usando o softphone mostrado na figura. Foi possível? A máquina Asterisk recebeu alguma solicitação?
  4. Fazer as configurações necessárias para que o Asterisk receba as as solicitações vindas do softphone;
  5. Uma vez o usuário estando registrado, fazer testes de chamadas e verificar se há áudio.

27/03 - Etapa Asterisk: Funções de PABX

Aula 11

Funções usando o plano de discagem

Para 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ções

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

Dial

Encaminha a chamada para um destino.

Exemplo:

exten=>_1XXXX,1,Dial(SIP/${EXTEN})
same=>n,hangup
Background

Toca 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
Playback

Toca 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
Wait

Forç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 Hangup

Answer atende uma chamada. Hangup termina uma chamada.

Exemplo:

exten=>666,1,Answer
same=>n,Playback(hello-world)
same=>n,Hangup
GoTo

Pula para um contexto (opcional), extensão, prioridade específica. Exemplo:

exten=>100,1,GoTo(vendas,s,1)
GoToIf

Trata-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
Set

Modifica 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
Log

Grava 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
NoOp

Não faz nada, sendo útil para depurar o plano de discagem. Exemplo:

exten=>100,1,NoOp(${CONTEXT})

28/03 - Etapa Asterisk: Padrões de extensões e variáveis

Aula 12

Padrões de extensões

Extensõ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:

Caractere Descrição
X Qualquer dígito entre 0 e 9
Z Qualquer dígito entre 1 e 9
N Qualquer dígito entre 2 e 9
[13-6] Qualquer dígito entre os colchetes (no exemplo, 1,3,4,5,6)
. Qualquer sequência de um ou mais dígitos
! Qualquer sequência de zero ou mais dígitos

Variáveis

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

  • Para definir uma variável: VAR=valor
  • Para obter o valor de uma variável: ${VAR}

Existem três tipos de variáveis:

  • Variáveis globais: Variáveis que estarão disponíveis a todos os canais e contextos em um plano de discagem. Essas devem ser declaradas dentro do contexto [globals] existente no arquivo extensions.conf ou utilizando a função GLOBAL() no plano de discagem.
  • Variáveis do canal: Variáveis que estão associadas especificamente com uma unica ligação. São definidas durante a chamada e só estão disponíveis para os participantes desta chamada. O Asterisk já define algumas variáveis específicas ao canal (Ex: ${CALLERID(num)}).
  • Variáveis de ambiente: São as variáveis obtidas do sistema operacional. Estas são referenciadas através do comando ENV. Ex: ${ENV(path)}.

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 especiais

Além das extensões criadas pelo usuário, o Asterisk apresenta algumas extensões especiais, tais como:

  • s (start): tem por objetivo tratar qualquer chamada que entre em um contexto e que não tenha um destino específico.
  • i (invalid): tem por objetivo tratar entradas inv ́lidas em um menu interativo
  • t (timeout): Em um menu interativo intercepta a chamada caso o usuário não forneça uma entrada dentro de um período de tempo estipulado.

03/04 - Etapa Asterisk: Padrões de extensões e variáveis

Aula 13


04/04 - Etapa Asterisk: URA

Aula 14


10/04 - Etapa Asterisk: Interconexão de PABX utilizando SIP

Aula 15


11/04 - Etapa Asterisk: Desenvolvimento do trabalho

Aula 16


17/04 - Etapa Asterisk: Desenvolvimento do trabalho

Aula 17


18/04 - Etapa Asterisk: Desenvolvimento do trabalho

Aula 18


24/04 - Etapa Asterisk: Desenvolvimento do trabalho

Aula 19


25/04 - Etapa Asterisk: Apresentação do trabalho

Aula 20


02/05 - Etapa QoS: Introdução à Qualidade de Serviço

Aula 21


08/05 - Etapa QoS: Conceitos básicos de QoS

Aula 22


09/05 - Etapa QoS: QoS em roteador Linux

Aula 23


15/05 - Etapa QoS: QoS em roteador Linux

Aula 24


16/05 - Etapa QoS: Exercícios práticos

Aula 25


22/05 - Etapa QoS: Desenvolvimento do trabalho (continuação Etapa Asterisk)

Aula 26


23/05 - Etapa QoS: Desenvolvimento do trabalho (continuação Etapa Asterisk)

Aula 27


29/05 - Etapa QoS: Desenvolvimento do trabalho (continuação Etapa Asterisk)

Aula 28


30/05 - Etapa QoS: Apresentação do trabalho (continuação Etapa Asterisk)

Aula 29


05/06 - Etapa Firewall: Introdução a Firewall

Aula 30


06/06 - Etapa Firewall: Firewall com iptables

Aula 31


12/06 - Etapa Firewall: Exercícios práticos

Aula 32


13/06 - Etapa Firewall: Exercícios práticos

Aula 33


19/06 - Etapa Firewall: Desenvolvimento do trabalho (continuação Etapa QoS)

Aula 34


20/06 - Etapa Firewall: Desenvolvimento do trabalho (continuação Etapa QoS)

Aula 35


26/06 - Etapa Firewall: Desenvolvimento do trabalho (continuação Etapa QoS)

Aula 36


27/06 - Etapa Firewall: Apresentação do trabalho (continuação Etapa QoS)

Aula 37


03/07 - Recuperação

Aula 38


04/07 - Recuperação

Aula 39