Mudanças entre as edições de "Redes Multimídia (diário 2017-1)"
Linha 366: | Linha 366: | ||
{{collapse bottom | Aula 4}} | {{collapse bottom | Aula 4}} | ||
+ | |||
+ | ==06/03: O protocolo SIP== | ||
+ | |||
+ | {{collapse top | Aula 5}} | ||
+ | |||
+ | * [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-22.pdf Transparências] | ||
+ | * [[Arquivo: manual_do_usuario_ata_gkm_1000t_e_ata_gkm_2000t.pdf]] | ||
+ | * [http://www.siptutorial.net/SIP/relation.html Mensagens, Transações, Diálogos e Chamadas SIP] | ||
+ | * [https://drive.google.com/file/d/0B9THvsFZhI2NM2VGQUJiY0NIQ0k/view?usp=sharing Captura: com reinvite] | ||
+ | * [https://drive.google.com/file/d/0B9THvsFZhI2NUzR3OEV3SklWQ3M/view?usp=sharing 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 [http://tools.ietf.org/html/rfc3261#section-19.1 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: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | # 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 | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | 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. | ||
+ | |||
+ | [[imagem:Sip-relation.gif]] | ||
+ | <br>'''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: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | 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) | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | 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): | ||
+ | |||
+ | |||
+ | [[imagem:Sip-example1.png]] | ||
+ | |||
+ | |||
+ | '''Pedido:''' | ||
+ | <syntaxhighlight lang=text>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 | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | '''Resposta:''' | ||
+ | <syntaxhighlight lang=text>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 | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | 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. | ||
+ | |||
+ | {| border="1" cellpadding="2" | ||
+ | !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)'' | ||
+ | |||
+ | |||
+ | {| border="1" cellpadding="2" | ||
+ | !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)'' | ||
+ | |||
+ | {| border="1" cellpadding="2" | ||
+ | !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). | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | Fone 1 Proxy SIP ou PBX IP | ||
+ | | | | ||
+ | | REGISTER | | ||
+ | |---------------------------->| | ||
+ | | 401 Unauthorized | | ||
+ | |<----------------------------| | ||
+ | | REGISTER | | ||
+ | |---------------------------->| | ||
+ | | 200 OK | | ||
+ | |<----------------------------| | ||
+ | | | | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | ==== 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. | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | Fone 1 Fone 2 | ||
+ | | | | ||
+ | | INVITE | | ||
+ | |----------------------->| | ||
+ | | 180 Ringing | | ||
+ | |<-----------------------| | ||
+ | | | | ||
+ | | 200 OK | | ||
+ | |<-----------------------| | ||
+ | | ACK | | ||
+ | |----------------------->| | ||
+ | | RTP Media | | ||
+ | |<======================>| | ||
+ | | | | ||
+ | | BYE | | ||
+ | |<-----------------------| | ||
+ | | 200 OK | | ||
+ | |----------------------->| | ||
+ | | | | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | ==== Chamada entre dois agentes SIP com intermediação de um Proxy SIP ==== | ||
+ | |||
+ | A principal diferença entre este tipo de chamada e [[RMU-2013-1#Estabelecimento_de_chamada_diretamente_entre_dois_agentes_SIP|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. | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | 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 | | ||
+ | | |--------------->| | ||
+ | | | | | ||
+ | | | | | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | ==== 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. | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | 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 |<---------------| | ||
+ | |<---------------| | | ||
+ | | | | | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | ==== 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. | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | 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 |<---------------| | ||
+ | |<---------------| | | ||
+ | | | | | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | === 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 [https://2.na.dl.wireshark.org/src/wireshark-1.12.13.tar.bz2 versão mais recente do wireshark]: | ||
+ | |||
+ | <syntaxhighlight lang=bash> | ||
+ | sudo add-apt-repository ppa:wireshark-dev/stable | ||
+ | sudo apt-get update | ||
+ | sudo apt-get install wireshark-gtk | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | ... e após a instalação execute ''wireshark-gtk''. | ||
+ | |||
+ | <!-- <syntaxhighlight lang=bash> | ||
+ | sudo apt-get install bison flex libgtk-3-dev libnl-3-dev libnl-genl-dev libpcap-dev libcap-dev libssl-dev | ||
+ | wget https://2.na.dl.wireshark.org/src/wireshark-1.12.13.tar.bz2 | ||
+ | tar xjf wireshark-1.12.13.tar.bz2 | ||
+ | cd wireshark-1.12.13 | ||
+ | ./configure --with-qt=no --with-gtk3=yes | ||
+ | make | ||
+ | sudo make install | ||
+ | </syntaxhighlight> | ||
+ | --> | ||
+ | |||
+ | === 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: | ||
+ | #* [https://drive.google.com/file/d/0B9THvsFZhI2NM2VGQUJiY0NIQ0k/view?usp=sharing Captura: com reinvite] | ||
+ | #* [https://drive.google.com/file/d/0B9THvsFZhI2NUzR3OEV3SklWQ3M/view?usp=sharing 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 ? | ||
+ | |||
+ | |||
+ | {{collapse bottom}} | ||
<!-- | <!-- |
Edição das 07h40min de 6 de março de 2017
Endereço encurtado: http://bit.ly/rmu20171
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
- Trabalho 1: trabalho prático para ser apresentado;
- Trabalho 2: trabalho prático complementar a Trabalho 1 para ser apresentado;
- Trabalho 3: trabalho prático complementar a Trabalho 2 para ser apresentado.
Diário das aulas
13/02 - Apresentação da disciplina
Aula 1 |
---|
Apresentação da disciplina: conteúdo, bibliografia e avaliação, laboratório. Instalação do Asterisk
|
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.
PBX IP Asterisk
Características Básicas: faz tudo que um PABX pequeno e simples faz e pouco mais
Instalação do Asterisk
|
20/02 - Continuação Aula 2
Aula 3 |
---|
21/02: Entroncamentos SIP no Asterisk
Aula 4 | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
A empresa onde se deve implantar a infraestrutura telefônica possui uma matriz e uma filial. Ambas possuem seus próprios PBX e suas linhas telefônicas locais. Por padronização seus PBX possuem as mesmas funcionalidades. Por fim, chamadas entre ramais da matriz e filial da empresa são feitas por um tronco privativo implantado com VoIP.
Tronco SIPEm um entroncamento SIP (SIP trunking), um PBX pode encaminhar chamadas através de um tronco SIP. Essas chamadas podem ser originadas de diferentes formas, tais como telefones IP ou convencionais. Entre os PBX do entroncamento, as chamadas são sinalizadas com SIP e transmitidas com RTP e algum codec. A ativação de um entroncamento SIP entre dois PBX Asterisk pode ser feita seguindo o exemplo abaixo:
Atividade: estabelecendo chamadas entre diferentes PBX AsteriskNesta atividade, vamos realizar chamadas entre softphones registrados em diferentes PBX Asterisk. Isso implica definir um plano de numeração para os ramais da empresa. Sendo assim:
|
06/03: O protocolo SIP
Aula 5 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
O protocolo SIPO protocolo SIP segue um modelo P2P (peer-to-peer), em que dois ou mais participantes, chamados de agentes, trocam mensagens com a finalidade de estabelecerem algum tipo de sessão (de voz no nosso caso, mas pode ser de video, mensagem instantânea, ou algum outro tipo de serviço). Assim, cada agente em uma sessão SIP se comporta tanto como cliente (quando envia requisições SIP) quanto servidor (quando responde a requisições SIP). A parte que inicia requisições se chama UAC (User Agent Client), e a que responde requisições é denominada UAS (User Agent Server), estando ambas implementadas nos telefones IP e similares. Uma sessão SIP envolve a interação entre duas entidades lógicas, que no caso de chamadas VoIP são por vezes chamadas simplesmente de usuários. A diferença entre entidade lógica e agente é que a primeira é o usuário (recurso) que inicia ou recebe chamadas, e o segundo é a aplicação que contém os mecanismos para efetuar e receber chamadas - pense que a entidade seria uma pessoa, e o agente o aparelho telefônico em uma chamada telefônica convencional. Cada entidade é identificada por uma URI (Uniform Resource Indicator) SIP, semelhante a um número de telefone. Além de identificar uma entidade lógica, a informação em uma URI SIP indica a forma com que essa entidade deve ser contatada via SIP. Exemplos de URI SIP seguem abaixo: # Uma URI simples, tipicamente usada em mensagens INVITE (que iniciam sessões SIP)
sip:1234@biloxi.example.com
# Uma URI mais elaborada, tipicamente usada em alguns cabeçalhos SIP (ex: Contact ou Refer-to)
sip:joseph.fourier@transform.org:5060;transport=udp;user=ip;method=INVITE;ttl=1;
maddr=240.101.102.103?Subject=FFT
As comunicações SIP seguem uma hierarquia, cujos níveis são:
Mensagens SIPO protocolo SIP tem uma estrutura simplificada com mensagens de pedido e resposta, assemelhando-se ao protocolo HTTP. Essas mensagens possuem a seguinte estrutura: Linha inicial
Cabeçalho1: valor do cabeçalho 1
Cabeçalho2: valor do cabeçalho 2
...
CabeçalhoN: valor do cabeçalho N
<linha em branco>
corpo da mensagem (opcional)
A diferença básica entre pedidos e respostas SIP está na linha inicial: pedidos contém um método SIP e seus parâmetros, e respostas possuem um código de status junto com um curto texto informativo. Abaixo são mostradas duas mensagens SIP: um pedido e sua respectiva resposta. Nesse exemplo, ambas mensagens não possuem um corpo de mensagem (lembre que isso é opcional):
REGISTER sips:ss2.biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>
Content-Length: 0
Resposta: SIP/2.0 200 OK
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92
;received=192.0.2.201
From: Bob <sips:bob@biloxi.example.com>;tag=ja743ks76zlflH
To: Bob <sips:bob@biloxi.example.com>;tag=37GkEhwl6
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 2 REGISTER
Contact: <sips:bob@client.biloxi.example.com>;expires=3600
Content-Length: 0
O pedido exemplificado foi uma mensagem do tipo REGISTER, que é um tipo de método SIP. Um método pode ser entendido como um comando enviado de um participante a outro. A resposta contém o status 200 OK, que significa que o pedido foi atendido com sucesso. Por fim, ambas mensagens contiveram um conjunto de cabeçalhos necessários para caracterizá-las, dentre eles Via, From, To, Call-Id, CSeq, Contact e Content-Length. As tabelas a seguir descrevem resumidamente os principais métodos e cabeçalhos SIP.
Tabela de métodos SIP (não exaustiva ... apenas os principais métodos)
Tabela de cabeçalhos SIP (não exaustiva ... apenas os principais cabeçalhos)
Tabela com as classes de respostas Diagramas de chamadasAlguns tipos de chamadas VoIP com SIP são recorrentes, estando representadas nas subseções a seguir. Registro de agente SIP em um proxy SIPEsta chamada ocorre entre um agente SIP e um servidor de registro SIP (SIP Registar), que está implementado tipicamente em um proxy SIP, um gateway de media, ou um PBX IP (este último incorpora as funções dos dois primeiros com as de um PBX). O registro do agente SIP tem por finalidade fazer com que o servidor de registro SIP conheça a localização do agente (endereço IP e port usado pelo UAS). Fone 1 Proxy SIP ou PBX IP
| |
| REGISTER |
|---------------------------->|
| 401 Unauthorized |
|<----------------------------|
| REGISTER |
|---------------------------->|
| 200 OK |
|<----------------------------|
| |
Chamada direta entre dois agentes SIPUma chamada direta entre dois agentes envolve uma transação INVITE, em que um agente convida o outro a estabelecer uma sessão SIP com um determinado tipo de media (ex: audio). A chamada é finalizada quando um dos agentes inicia uma transação BYE. Fone 1 Fone 2
| |
| INVITE |
|----------------------->|
| 180 Ringing |
|<-----------------------|
| |
| 200 OK |
|<-----------------------|
| ACK |
|----------------------->|
| RTP Media |
|<======================>|
| |
| BYE |
|<-----------------------|
| 200 OK |
|----------------------->|
| |
Chamada entre dois agentes SIP com intermediação de um Proxy SIPA principal diferença entre este tipo de chamada e o anterior é o uso de um (ou mais) proxy SIP entre os dois agentes. O proxy SIP tem por finalidade ajudar na realização das chamadas, uma vez que usualmente incorpora a função de servidor de registro. Um proxy SIP encaminha chamadas para o agente chamado, ou para outro proxy mais próximo do destino, podendo aplicar regras de controle de acesso quanto a quem pode realizar chamadas para quem. Fone 1 Proxy SIP ou PBX IP Fone 2
(directmedia=yes)
| | |
| INVITE | |
|--------------->| INVITE |
| 100 Trying |--------------->|
|<---------------| 100 Trying |
| |<---------------|
| | |
| | 180 Ringing |
| 180 Ringing |<---------------|
|<---------------| |
| | 200 Ok |
| 200 Ok |<---------------|
|<---------------| |
| ACK | |
|--------------->| ACK |
| |--------------->|
| | |
| RTP Media |
|<===============================>|
| | |
| | BYE |
| BYE |<---------------|
|<---------------| |
| 200 Ok | |
|--------------->| 200 Ok |
| |--------------->|
| | |
| | |
Chamada entre dois agentes SIP com intermediação de um gateway de mediaEste caso é parecido com o anterior, que usa um proxy SIP. A diferença está na intermediação do fluxo de media, que é feita pelo gateway de media. Isso possibilita que dois agentes estabeleçam uma chamada mesmo usando codecs diferentes, pois o gateway de media fará a tradução entre codecs. Fone 1 PBX IP Fone 2
(directmedia=no)
| | |
| INVITE | |
|--------------->| INVITE |
| 100 Trying |--------------->|
|<---------------| 100 Trying |
| |<---------------|
| | 180 Ringing |
| 180 Ringing |<---------------|
|<---------------| |
| | 200 Ok |
| 200 Ok |<---------------|
|<---------------| |
| ACK | |
|--------------->| ACK |
| |--------------->|
| RTP Media | RTP Media |
|<==============>|<==============>|
| BYE | |
|--------------->| BYE |
| |--------------->|
| | 200 Ok |
| 200 Ok |<---------------|
|<---------------| |
| | |
Chamada entre dois agentes SIP com intermediação de um gateway de media e uso de re-INVITEO uso de re-invite possibilita que o fluxo de media seja estabelecido diretamente entre os agentes SIP, caso usem o mesmo codec. Assim, evita-se a carga de processamento envolvida na intermediação pelo gateway de media. Isso é feito com o envio pelo gateway de media (representado abaixo por um PBX IP) de um novo INVITE para cada agente SIP, após a sessão SIP estar estabelecida. Esse novo INVITE contém uma descrição de media (mensagem SDP embutida no corpo da mensagem INVITE) com a localização do outro agente SIP - isso é, seu endereço IP, port UDP para a stream RTP e codec a ser usado. Fone 1 PBX IP Fone 2
(directmedia=yes)
| | |
| INVITE | |
|--------------->| INVITE |
| 100 Trying |--------------->|
|<---------------| 100 Trying |
| |<---------------|
| | 180 Ringing |
| 180 Ringing |<---------------|
|<---------------| |
| | 200 Ok |
| 200 Ok |<---------------|
|<---------------| |
| ACK | |
|--------------->| ACK |
| INVITE |--------------->|
|<---------------| INVITE |
| 200 OK |--------------->|
|--------------->| 200 OK |
| ACK |<---------------|
|--------------->| ACK |
| |<---------------|
| |
| RTP Media |
|<===============================>|
| BYE | |
|--------------->| BYE |
| |--------------->|
| | 200 Ok |
| 200 Ok |<---------------|
|<---------------| |
| | |
Correção para o wiresharkO wireshark instalado no Ubuntu 14.04, como nas VM do laboratório, possui um bug que impede que se visualize a análise do fluxo de chamadas VoIP. Nessa versão, quando se seleciona no menu Telephony->VoIP Calls, e em seguida clica-se em uma das chamadas apresentadas e depois o botão Flow, o wireshark termina a execução. A solução para esse problema envolve instalar uma versão mais recente do wireshark: sudo add-apt-repository ppa:wireshark-dev/stable
sudo apt-get update
sudo apt-get install wireshark-gtk
... e após a instalação execute wireshark-gtk.
AtividadesNas análises pedidas a seguir, faça o seguinte:
|