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

Redes Multimidia: Diário de Aula 2016-1

Professora: Simara Sonaglio
E-mail: simara.sonaglio@ifsc.edu.br
Encontros: 2a feira/09:40, 3a feira/09:40
Atendimento paralelo:

• Arquivo:Plano-ensino-2016-1.pdf

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

• Manual de instalação Zoiper Linux
• Netkit: emulador de redes com máquinas virtuais Linux (UML)

Avaliações

Aluno	Avaliação 1	Trabalho 1	Trabalho 2
Giovanni	8,75
Luiz	6,75
Valmir	6,25

Diário das aulas

Aula 1 - 22/03/16

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

Aula 2 - 28/03/16

Caracterização de midias

Slides Compressão de video Compressão com MPEG-2 Introdução a MPEG-2 Compressão de audio e video Formatos de containers de video (arquivos de video) Uma boa introdução sobre codecs e containers de video 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): Exemplos de codecs de video MPEG-2 H-264 XVID Theora Atividade 1) Copie esta imagem para seu computador, e recorte uma parte com dimensões 128x128 pixels (use o gimp). 1.1) Qual o tamanho dessa imagem no formato BMP com 24 bpp ? 1.2) Qual o tamanho dessa imagem no formato PNG ? E no formato JPG ? 1.3) Crie uma nova imagem com dimensões 128x128 pixels e que seja toda preta, e determina seu tamanho nos formatos BMP com 24 bpp, PNG e JPG. 1.4) O que se pode concluir quanto à representação digital das imagens ?

Aula 3 - 04/04/16

Aula 3 no dia 29/03/2016 foi suspensa e deverá ser reposta posteriormente.

Caracterização de midias

Compressão de audio Compressão com MP3 Compressão com Ogg FLAC Speex Técnicas usadas: Remoção de silêncio Uso de psicoacústica Remoção de redundância Pacotes a instalar sudo apt-get update sudo apt-get install build-essential sudo apt-get install dkms sudo bash VBoxLinuxAdditions.run sudo apt-get install mencoder libavcodec54 sudo apt-get install lame </syntaxhighlight> Atividade compressão de áudio 1) Copie este arquivo de audio para seu computador. Escute-o e confira sua qualidade sonora. Veja também o tamanho do arquivo. 2) Codifique esse arquivo com os seguintes codecs: MP3: time lame musica.wav musica.mp3 Ogg: time oggenc -o musica.ogg musica.wav Flac: time flac musica.wav -o musica.flac Speex: time speexenc --bitrate 8 musica.wav musica.spx 3) Toque os arquivos de audio codificados, comparando suas qualidades sonoras. Compare também os tamanhos dos arquivos. Atividade compressão de vídeo 1) Copie este arquivo compactado para seu computador, e em seguida descompacte-o. Note que ele contém um certo número de arquivos de imagem em formato JPG (experimente visualizar alguns deles). 1.1) Crie um video a partir dessas imagens. Esse video estará no formato MPJG (Motion JPG), que nada mais é que as imagens sequencializadas. cd figs mencoder mf://\*.jpg -fps 10 -ovc copy -o video.avi 1.2) Veja o tamanho do arquivo de video, e compare-o com o tamanho total das imagens. Em seguida, reproduza-o com vlc ou mplayer. 1.3) Recodifique o seu arquivo de video usando o codec XVID: mencoder -o video2.avi -ovc xvid -xvidencopts bitrate=1024 -oac copy video.avi ... e observe o tamanho do arquivo de video resultante. Em seguida reproduza-o com vlc ou mplayer. Como você o compara com o video gerado no item 2.2 ? 2) Codifique esse video para outros formatos de compressão: MPEG-2: mencoder -o video3.mpg -of mpeg -ovc lavc -lavcopts vcodec=mpeg2video:vbitrate=1024 -oac copy video.avi H-264: mencoder -o video4.mp4 -ovc x264 -x264encopts pass=1:turbo -oac mp3lame video.avi 3) Compare os tamanhos dos arquivos de video resultantes das codificações. Toque-os e veja se há diferença de qualidade de imagem entre eles. Transmissão de dados multimidia Slides Atrasos devido a transmissão O tráfego de midia pode variar o uso de banda dependendo da codificação: 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). 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) $A_{t}={\frac {F}{B}}$ 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 $A_{p}$ 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 $A_{x}$ 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 $A_{q}=\sum _{F\in Fila}{\frac {F}{B}}$ 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: Atrasos de transmissão nos links WAN: $A_{wan}={\frac {1500\cdot 8}{10\cdot 10^{6}}}=1,2\cdot 10^{-3}s$ Atrasos de transmissão nos links LAN: $A_{lan}={\frac {1500\cdot 8}{1\cdot 10^{9}}}=12\cdot 10^{-6}s$ Atraso de enfileiramento em roteador: melhor caso (fila vazia) $A_{q}=0~s$ Atraso de enfileiramento em roteador: pior caso (fila cheia): $A_{q}=100\cdot {\frac {1500\cdot 8}{10\cdot 10^{6}}}=120\cdot 10^{-3}s$ O menor atraso pode ser calculado assim: $A_{min}=4\cdot A_{lan}+4\cdot A_{wan}+4\cdot A_{p}=12,848\cdot 10^{-3}s$ ... e o maior atraso possível é: $A_{max}=4\cdot A_{lan}+4\cdot A_{wan}+4\cdot A_{p}+4\cdot A_{q}=492,848\cdot 10^{-3}s$ 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é $A_{max}-A_{min}=480ms$. 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). Exercício Mesma topologia, os links LAN (link1, link2, link7 e link8) possuem taxa de 100 Mbps, e os links WAN (demais links) possuem taxa de 5 Mbps. As filas dos roteadores podem conter até 90 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. 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 áudio. Atividade Pesquisar mecanismos para tratar variação de atraso e perda de pacotes. Entregar um resumo sobre os mecanismos encontrados.

Aula 4 - 05/04/16

Transmissão de midias
Slides Atividade Resolver Problemas 10, 11 e 12 da 5ª ed. do Kurose para entregar.

Aula 5 - 11/04/16: Introdução a Voz sobre IP (VoIP)

Introdução ao VoIP

Transparências Arquivo:Manual do usuario ata gkm 1000t e ata gkm 2000t.pdf Introdução a VoIP e SIP RFC 3261: Session Initiation Protocol (SIP) Tecnologias VoIP para smartphones QoS for VoIP (Cisco) QoS for VoIP (voip-info) ITU-T G.114: One Way Transmission Time SIP: Understanding the Session Initiation Protocol, 3rd ed (muito bom livro) ... (cópia online) Mensagens, Transações, Diálogos e Chamadas SIP VoIP: transmissão de voz usando protocolos da arquitetura TCP/IP, com o objetivo de estabelecer chamadas semelhantes a chamadas telefônicas. Alguns exemplos de aplicações ou padrões VoIP são: Skype (mais material aqui) Whatsapp Viber SIP (padrão) H.323 (padrão) Uma chamada VoIP entre dois telefones IP é feita através da rede de dados. A realização de chamadas VoIP implica a necessidade de alguns mecanismos: Sinalização: deve haver alguma forma de um usuário iniciar uma chamada para outro usuário, de forma parecida com uma chamada telefônica convencional. A sinalização é responsável por possibilitar que um usuário convide outro para o estabelecimento de uma chamada, e para notificar sobre sua aceitação ou não. Além disso, a sinalização deve participar da definição sobre as características da chamada, tais como o codec de áudio. Transmissão de midia: a voz precisa ser digitalizada com algum codec então transmitida entre os participantes da chamada. O transporte da voz digitalizada implica o uso protocolos capazes de encapsulá-la e de atender ou dar subsídios ao atendimento de seus requisitos de qualidade de serviço (atrasos fim-a-fim e variação de atraso, taxa de perdas). Em RMU será estudado o modelo SIP para VoIP, o qual se compõe de um conjunto de padrões abertos para tratar dos vários aspectos envolvidos na realização de chamadas. Esse modelo, como diz seu nome, tem como principal elemento o protocolo de sinalização SIP (Session Initiation Protocol).

Aula 6 - 12/04/16: O protocolo SIP

O protocolo SIP

Transparências Arquivo:Manual do usuario ata gkm 1000t e ata gkm 2000t.pdf Mensagens, Transações, Diálogos e Chamadas SIP Captura: com reinvite Captura: com reinvite 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. '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): 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é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) 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 |<---------------| |<---------------| | | | |

Aula 7 - 18/04/16: O protocolo SIP - continuação

SDP

SDP – Session Description Protocol Para garantir o processo de negociação das mídias a serem trocadas numa sessão, o SIP encapsula outro protocolo, comumente o SDP. O SDP, definido inicialmente em no RFC 2327 (HANDLEY e JACOBSON, 2011), teve como propósito original descrever sessões multicast estabelecidas sobre o backbone multicast da Internet, o MBONE e, portanto, vários de seus campos tem uso limitado (ou nenhum uso) para as sessões unicast estabelecidas atualmente com o SIP, mas foram mantidos na nova definição do protocolo, RFC 4566 (HANDLEY, JACOBSON e PERKINS, 2011), para garantir a compatibilidade. De acordo com (JOHNSTON, 2009), as principais informações carregadas numa mensagem SDP sobre a sessão de mídia são: endereço IP (IPv4 ou IPv6) ou nome de host, perfil RTP (tipicamente “RTP/AVP”), número da porta que será usada para troca de fluxo de mídia, tipo de mídia a ser trocada (vídeo, áudio, texto e etc.) e esquema de codificação de mídia. FONTE: Teleco.

Aula 8 - 19/04/16: O protocolo SIP - continuação

Atividades realizadas

1. Registro de ramais criados no Asterisk da máquina Professor;
2. Testes de chamadas entre ramais;
3. Análise de tráfego de com o Wireshark;
4. Análise de tráfego de áudio com a opção Reinvite habilitada/desabilitada.

Aula 9 - 25/04/16: O protocolo RTP

RTP

O transporte de midia com protocolo RTP Transparências Uma FAQ sobre RTP (muito boa) RFC 3550: RTP: A Transport Protocol for Real-Time Applications Capítulo 11 do livro SIP: Understanding the Session Initiation Protocol, 3rd ed Cap. 7 do livro Redes de Computadores e a Internet, 5a edição, de James Kurose. Captura: com reinvite Captura: sem reinvite 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 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. Lista de exercícios (Arquivo:Lista2.pdf)

Aula 12 - 03/05/16: Asterisk - Apresentação

• Transparências
• Site oficial do Asterisk
• Asterisk Guru
• Dicas sobre Asterisk
• Livro online gratuito sobre Asterisk
• Introdução a VoIP e SIP
• Livro Asterisk: Guia de Configuração - 5a geração, de Flávio Gonçalves.

Asterisk: uma solução completa de PABX baseado em software, permitindo ligar o mundo IP ao mundo da rede pública de telefonia comutada.

Características Básicas: faz tudo que um PABX pequeno e simples faz e pouco mais

• ˆ Transferência, música de espera, siga-me, etc.
• Conferência, correio de voz, URA, fila de chamadas, monitoramento de chamadas, integração com o Jabber (Google talk)

Características Avançadas: o que seria interessante para grandes empresas

• Uso de banco de dados (MySQL), integração com o LDAP, DUNDi, DNS SRV, geração de bilhetagem

Exemplo de cenário de uso do Asterisk

Aula 13 - 09/05/16: Asterisk - Canais SIP e plano de discagem

• Transparências

Canais SIP e plano de discagem

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 extensions.conf. O fluxo de processamento de chamadas pode ser visto resumidamente abaixo: 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=>199,1,Playback(beep) same=>n,Wait(1) same=>n,Playback(hello-world) same=>n,Wait(1) same=>n,Playback(beep) same=>n,Hangup A estrutura do plano de discagem é composta por extensões (um termo específico do Asterisk). Cada extensão identifica um número (ou usuário) que pode ser chamado, e como essa chamada deve ser processada. A sintaxe pode ser vista abaixo: exten=>identificador,prioridade,aplicação 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 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] username=2000 ; o nome do usuário para fins de autenticação secret=kabrum type=friend ; pode efetuar e receber chamadas host=dynamic ; pode conectar-se a partir de qualquer endereço IP context=alunos ; o contexto padrão do João. O arquivo extensions.conf o definirá disallow=all allow=gsm ; habilita este codec para o João. Os vários codecs serão vistos em se guida, ; já que cada um deles tem suas particularidades. allow=alaw ; outro codec allow=ulaw ; mais um codec qualify=yes; mostra a qualidade, em ms, da conexão entre UAC e UAS. ; Canal joao (outro exemplo) [joao] username=joao ; o nome do usuário para fins de autenticação secret=blabla type=friend ; pode efetuar e receber chamadas host=dynamic ; pode conectar-se a partir de qualquer endereço IP context=alunos ; o contexto padrão do João. O arquivo extensions.conf o definirá disallow=all allow=gsm ; habilita este codec para o João. Os vários codecs serão vistos em se guida, ; já que cada um deles tem suas particularidades. allow=alaw ; outro codec allow=ulaw ; mais um codec qualify=yes; mostra a qualidade, em ms, da conexão entre UAC e UAS. Como se pode notar, a declaração de um canal SIP envolve muitos parâmetros que envolvem autenticação, controle de acesso, localização na rede, codecs e possivelmente outras capacidades. Como os valores de alguns parâmetros podem ser iguais para vários canais, o Asterisk possibilita a declaração de perfis (templates): ; Perfil alunos [alunos](!); a sequência "(!)" define isto como um perfil type=friend ; pode efetuar e receber chamadas host=dynamic ; pode conectar-se a partir de qualquer endereço IP context=alunos ; o contexto padrão do João. O arquivo extensions.conf o definirá disallow=all allow=gsm ; habilita este codec para o João. Os vários codecs serão vistos em se guida, ; já que cada um deles tem suas particularidades. allow=alaw ; outro codec allow=ulaw ; mais um codec qualify=yes; mostra a qualidade, em ms, da conexão entre UAC e UAS. ; Canal 2000 [2000](alunos); a sequência "(alunos)" copia as definições do perfil "alunos" username=2000 ; o nome do usuário para fins de autenticação secret=kabrum ; Canal joao [joao](alunos) username=joao ; o nome do usuário para fins de autenticação secret=blabla Atividades Instalar o Asterisk na máquina virtual sudo apt-get install asterisk</syntaxhighlight> Criar os contextos alunos, professores e coordenaçãoo e contas SIP pertencentes a estes contextos; Criar um plano de discagem de forma que as contas SIP do contexto alunos só possam atingir outras contas SIP deste contexto. O mesmo deve ser feito para o contexto professores. Já as contas SIP do contexto coordenação poderão atingir, além das contas SIP deste contexto, as contas dos contextos alunos e professores; Testes de chamadas entre ramais; Criar um contexto comum a todos os demais contextos e nele criar os próximos dois itens; Criar um número no plano de discagem que seja atendido por uma gravação; Criar um número no plano de discagem que permita fazer uma gravação. sip.conf [100] type=friend secret=100 host=dynamic canreinvite=no context=alunos disallow=all allow=gsm allow=alaw allow=ulaw [101] type=friend secret=101 host=dynamic context=alunos canreinvite=no disallow=all allow=gsm allow=alaw allow=ulaw [102] type=friend secret=102 host=dynamic context=professores canreinvite=no disallow=all allow=gsm allow=alaw allow=ulaw [103] type=friend secret=103 host=dynamic context=professores canreinvite=no disallow=all allow=gsm allow=alaw allow=ulaw [104] type=friend secret=104 host=dynamic context=coordenacao canreinvite=no disallow=all allow=gsm allow=alaw allow=ulaw [105] type=friend secret=105 host=dynamic context=coordenacao canreinvite=no disallow=all allow=gsm allow=alaw allow=ulaw extensions.conf [alunos] exten=>100,1,Dial(SIP/100,30) exten=>100,2,Hangup exten=>101,1,Dial(SIP/101,30) exten=>101,n,Hangup include=>geral [professores] exten=>102,1,Dial(SIP/102,30) same=>n,Hangup exten=>103,1,Dial(SIP/103,30) exten=>103,n,Hangup include=>geral [coordenacao] exten=>104,1,Dial(SIP/104,30) same=>n,Hangup exten=>105,1,Dial(SIP/105,30) exten=>105,n,Hangup include=>alunos include=>professores include=>geral [geral] exten=999,1,answer() exten=999,n,record(/var/lib/asterisk/sounds/teste:wav) exten=999,n,playback(/var/lib/asterisk/sounds/teste) exten=999,n,hangup Aula 14 - 10/05/16: Asterisk - Continuação Aula 13