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)

• Plano de Ensino

Objetivo Geral

1. Implantar um PABX IP integrado com serviços de telefonia fixa e móvel convencionais.
2. Prover a infraestrutura de rede necessária para o adequado funcionamento deste PABX IP.
3. 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

1. KUROSE, J. e ROSS, K. Redes de Computadores e a Internet: Uma abordagem top-down. Tradução da 3a edição, Addison Wesley, 2006.
2. COLCHER, Sérgio. VOIP: voz sobre IP. Rio de Janeiro: Elsevier, 2005.

Bibliografia complementar

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

Provedores VoIP no Brasil

• FaleMaisVoIP
• DirectCall
• outros ...

Avaliações

Aluno(a)	Avaliação 1	Avaliação 2	Avaliação 3	Nota final

Diário de Aula 2017-1

13/02: Apresentação da disciplina

Aula 1

O foco do Projeto Integrador IV está na 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. Além disso, também tem como objetivo a integração destes serviços de telecomunicações com outros serviços de rede como servidores Web, Email, Telefonia IP, administração de sistemas e usuários, compartilhamento de recursos, DNS, etc. Na figura abaixo é apresentado um esboço do cenário que foi desenvolvido durante o Projeto Integrador III. A proposta inicial é integrar a este cenário serviços de telefonia IP e convencional. Além disso, outros serviços podem ser integrados a ambos, como e-mail, DNS, acesso à câmeras IP, etc. Uma vez integrados os serviços de rede e de telefonia e tendo em mente que a qualidade de serviço é um ponto sensível à aplicações de telefonia IP, espera-se desenvolver métodos de medição de rede para assegurar seu correto funcionamento. Instalação do Asterisk 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. 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. Uma visão geral sobre Asterisk PBX IP Asterisk 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) Exemplo de cenário de uso do Asterisk O Asterisk é um software complexo e com muitos recursos. Porém sua função mais elementar, que é intermediar chamadas, pode ser entendida com base em dois elementos importantes desse tipo de PBX. Esses elementos são o plano de discagem e configurações de canais. Na terminologia do Asterisk, um canal pode ser entendido como um ramal ou tronco. Para ter o Asterisk funcionando como uma central simplificada, é suficiente configurar esses dois elementos. 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: Um exemplo de plano de discagem simples pode ser visto 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 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] 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 IP Para 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. 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. 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 Em cada softphone 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). 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] 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.. 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: Recarregar as configurações do arquivo sip.conf: sip reload</syntaxhighlight> Recarregar as configurações do arquivo extensions.conf: dialplan reload</syntaxhighlight> Ver canais SIP criados: sip show peers</syntaxhighlight> Gerar uma ligação via console: console dial extensão@contexto</syntaxhighlight> PBX baseados em Asterisk Existem softwares que implementam interfaces amigáveis para uso do Asterisk. Mais que isso, tais softwares criam um modelo de utilização do Asterisk, articulando seus recursos e funcionalidades de forma prática. Alguns deles são: FreePBX Elastix SNEP Algum deles poderia ser adequado ao projeto ? Ou seria melhor usar o Asterisk diretamente ?

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. Inicialmente criaremos a infraestrutura para chamadas VoIP, a qual aumentaremos gradualmente para podermos reproduzir o modelo aqui descrito. Tronco SIP Em 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: PBX sip.conf extensions.conf Norte [Sul] type=user secret=supersercreta host=IP_PBX_Norte disallow=all allow=ulaw ;canreinvite=no directmedia=no context=troncoSIP qualify=yes [ParaSul] type=peer fromuser=Norte username=Norte secret=supersecreta host=IP_PBX_Sul disallow=all allow=ulaw ;canreinvite=no directmedia=no qualify=yes [troncoSIP] ; Ligando para a outra central e, na sequência, o "ramal" de destino exten => 4000,1,Dial(SIP/ParaSul/4000) same=>n,Hangup Sul [Norte] type=user secret=supersercreta host=IP_PBX_Sul disallow=all allow=ulaw ;canreinvite=no directmedia=no context=troncoSIP qualify=yes [ParaNorte] type=peer fromuser=Sul username=Sul secret=supersecreta host=IP_PBX_Norte disallow=all allow=ulaw ;canreinvite=no directmedia=yes qualify=yes [troncoSIP] ; ; Ligando para a outra central e, na sequência, o "ramal" de destino exten => 2000,1,Dial(SIP/ParaNorte/2000) same=>n,Hangup Outra forma de fazer um entroncamento SIP é o seguinte: PBX sip.conf extensions.conf Central1 [central2] type=friend ;defaultuser=central1; Canal SIP criado na Central 1 username=central1 host=192.168.25.102 ;ip da Central 2 secret=123 context=alunos [alunos] ; Ligando para a outra central e, na sequência, o "ramal" de destino exten => 4000,1,Dial(SIP/central2/3000) same=>n,Hangup Central2 [central1] type=friend ;defaultuser=central2; Canal SIP criado na Central 2 username=central2 host=192.168.25.101 ;ip da Central 1 secret=123 context=alunos [alunos] ; ; Ligando para a outra central e, na sequência, o "ramal" de destino exten => 2000,1,Dial(SIP/central1/2000) same=>n,Hangup Atividade: estabelecendo chamadas entre diferentes PBX Asterisk Nesta 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: Defina esse plano de numeração Crie as regras de discagem entre ramais da empresa Teste as chamadas Investigue a comunicação através do tronco (use o wireshark)

20/02: O protocolo SIP

Aula 3

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: sem 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) Resposta Classe 1XX Informativas 2XX Sucesso 3XX Redirecionamento 4XX Falha na requisição 5XX Falha no servidor 6XX Falha global Tabela com as classes de respostas 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. Atividades Nas análises pedidas a seguir, faça o seguinte: Desenhe um diagrama dos diálogos SIP identificados, destacando os agentes SIP envolvidos, métodos SIP e códigos de resposta. Investigue os cabeçalhos das mensagens SIP, identificando as informações que relacionam as mensagens de um mesmo diálogo. Diagnostique o resultado da chamada: se teve sucesso ou não (e qual foi o problema, caso tenha falhado). Descubra a duração das chamadas com base na captura. Capture os pacotes de uma chamada com sucesso entre dois ramais. Identifique a sequência de mensagens que formam o diálogo SIP em questão. Repita a captura, porém para uma chamada feita para um ramal que não exista (ou extensão inexistente). Repita a captura, porém para uma chamada feita para um ramal existe, mas que não esteja registrado. Repita a captura, porém para uma chamada feita para um uma extensão que seja atendida pela própria central. Capture os pacotes de uma chamada com sucesso entre dois ramais. Além de identificar a sequência de mensagens que formam o diálogo SIP, analise os parâmetros de midia da chamada. Analise estes arquivos de captura, e descreva as chamadas ali realizadas: Captura: com reinvite Captura: sem reinvite Configure uma extensão em sua central para receber uma chamada vinda de uma câmera IP (que será ativada pelos professores). Em seguida, capture uma chamada vinda da câmera, e analise como se constiui o diálogo SIP e a descrição de midia vindos da câmera. Que semelhanças (e diferenças) existem em relação a chamadas entre ramais ?

21/02: Continuação Aula 3

Aula 4

06/03: Continuação Aula 3 e o protocolo SDP

Aula 5

SDP (Session Description Protocol) RFC 4566: SDP Um bom texto sobre SDP 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: Tabela de campos SDP Um exemplo de mensagem SDP segue abaixo: 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). Atividade Realize uma chamada usando softphones, e capture seus datagramas UDP com wireshark. Em particular, observe os corpos da mensagem SIP INVITE e de sua correspondente resposta 200 OK. Identifique os atributos das mensagens SDP contidas nos corpos dessas mensagens SIP Analisando essas mensagens SDP, informe o seguinte: endereços IP e port para fins de transmissão de midia entre participantes codecs que podem ser usados em cada direção o tipo de midia a ser transportada Realize uma chamada para uma das câmeras IP. Em seguida, faça a mesma análise do ítem 1. Ative o suporte a chamada de video em seus softphones e no Asterisk. O seguinte atributo deve ser adicionado à seção general em sip.conf no Asterisk: videosupport=yes Faça uma chamada de video entre os softphones e repita a análise do ítem 1. 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. 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. Atividade Essa atividade busca ilustrar os fluxos RTP com um exemplo: Estabeleça uma chamada VoIP entre dois softphones usando o Asterisk como intermediário. Execute o wireshark no computador onde roda o Asterisk, e ative a captura de datagramas UDP. Observe os pacotes RTP capturados pelo Wireshark. Selecione alguns deles e investigue as informações contidas em seu cabeçalho. Procure identificar o codec usado e as marcações de tempo. Compare as marcações de tempo do RTP com os instantes de recepção desses pacotes. Estime o jitter durante a recepção de ao menos 15 segundos de audio. Observe os relatórios RTCP: Que tipos de relatórios são enviados ? Com que frequência esses relatórios são transmitidos ? Que informações esses relatórios contêm ?

07/03: Investigando os protocolos envolvidos nas chamadas

Aula 6

Sinalização com SIP As chamadas que realizamos por meio do Asterisk foram iniciadas e terminadas usando protocolo SIP. Elas podem ser enquadradas em dois casos: Chamada com intermediação de gateway de midia Chamada com intermediação de gateway de midia, porém usando re-INVITE 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 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 |<---------------| |<---------------| | | | | Atividade Execute o wireshark no hospedeiro, e deixe-o capturando datagramas UDP (especifique isso em Capture->options). Realize uma chamada entre dois softphones, usando as contas do seu servidor Asterisk. Observe as mensagens trocadas entre softphones e Asterisk (use menu Telephony->VoIP Calls e depois Graph). Em particular, observe quem é o receptor e transmissor de cada mensagem SIP e também dos pacotes de midia (protocolo RTP). Edite o arquivo sip.conf do seu Asterisk, e defina a opção directmedia=yes (isso deve estar no perfil que você definiu para as contas). Faça o Asterisk reler o sip.conf: rasterisk > sip reload Refaça a chamada entre os softphones, e observe no wireshark as mensagens SIP e pacotes RTP. O que mudou em relação à chamada anterior ? Em qual caso, dentre os apresentados no início da aula, cada chamada se enquadra ? O que se pode concluir quanto ao papel do Asterisk em cada caso ?

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: 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. 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 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; A comunicação entre canais SIP de diferentes PABX IP deve estar funcionando corretamente tanto com REINVITE como SEM REINVITE; Cada aluno deve montar uma estrutura de rede que será apresentada em aula utilizando AP TP-LINK; Fazer as devidas configurações para que tenha áudio nas comunicações entre os diferentes PABX IP. Atividade 2- Asterisk atrás de NAT Configurar a rede indicada na figura acima; Abrir o Wireshark na máquina onde o Asterisk está instalado; Tentar registrar um usuário SIP usando o softphone mostrado na figura. Foi possível? A máquina Asterisk recebeu alguma solicitação? Fazer as configurações necessárias para que o Asterisk receba as as solicitações vindas do softphone; Uma vez o usuário estando registrado, fazer testes de chamadas e verificar se há áudio. 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>