SMU29009: Sinalização

De MediaWiki do Campus São José
Ir para navegação Ir para pesquisar

Próxima aula



A sinalização é uma função capaz de negociar e estabelecer uma comunicação entre entidades de uma aplicação. Além das características de uma comunicação, a sinalização negocia o caminho e os recursos necessários com a infraestrutura de comunicação.

Em SMU será estudado o modelo SIP para sinalização, 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).

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 video no nosso caso, mas pode ser de voz, 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 agentes SIP envolvidos.

Uma sessão SIP envolve a interação entre duas entidades lógicas. 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 uma câmera em uma chamada de video. Cada entidade é identificada por uma URI (Uniform Resource Indicator) SIP. Além de identificar uma entidade lógica, a informação em uma URI SIP indica a forma com que essa entidade deve ser contatada via SIP. Exemplos de URI SIP seguem abaixo: 

# Uma URI simples, tipicamente usada em mensagens INVITE (que iniciam sessões SIP)
sip:1234@biloxi.example.com

# Uma URI mais elaborada, tipicamente usada em alguns cabeçalhos SIP (ex: Contact ou Refer-to)
sip:joseph.fourier@transform.org:5060;transport=udp;user=ip;method=INVITE;ttl=1;
maddr=240.101.102.103?Subject=FFT

As comunicações SIP seguem uma hierarquia, cujos níveis são:

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

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

Mensagens SIP


O protocolo SIP tem uma estrutura simplificada com mensagens de pedido e resposta, assemelhando-se ao protocolo HTTP. Essas mensagens possuem a seguinte estrutura: 

Linha inicial
Cabeçalho1: valor do cabeçalho 1
Cabeçalho2: valor do cabeçalho 2
...
CabeçalhoN: valor do cabeçalho N
<linha em branco>
corpo da mensagem (opcional)

A diferença básica entre pedidos e respostas SIP está na linha inicial: pedidos contém um método SIP e seus parâmetros, e respostas possuem um código de status junto com um curto texto informativo. Abaixo são mostradas duas mensagens SIP: um pedido e sua respectiva resposta. Nesse exemplo, ambas mensagens não possuem um corpo de mensagem (lembre que isso é opcional):


Sip-example1.png


Pedido: 

REGISTER sips:ss2.biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>
Content-Length: 0

Resposta: 

SIP/2.0 200 OK
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92
 ;received=192.0.2.201
From: Bob <sips:bob@biloxi.example.com>;tag=ja743ks76zlflH
To: Bob <sips:bob@biloxi.example.com>;tag=37GkEhwl6
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 2 REGISTER
Contact: <sips:bob@client.biloxi.example.com>;expires=3600
Content-Length: 0

O pedido exemplificado foi uma mensagem do tipo REGISTER, que é um tipo de método SIP. Um método pode ser entendido como um comando enviado de um participante a outro. A resposta contém o status 200 OK, que significa que o pedido foi atendido com sucesso. Por fim, ambas mensagens contiveram um conjunto de cabeçalhos necessários para caracterizá-las, dentre eles Via, From, To, Call-Id, CSeq, Contact e Content-Length. As tabelas a seguir descrevem resumidamente os principais métodos e cabeçalhos SIP.

Mé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: video). 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. O gateway de midia não necessariamente reside no mesmo equipamento onde está o proxy SIP. 

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

O primeiro experimento com uma chamada VoIP envolve estabelecer uma chamada diretamente entre dois softphones. Cada par de alunos deve fazer o seguinte:

  1. Obter o arquivo de configuração do Netkit.
  2. Carregar o arquivo de configuração em File->Load
  3. Iniciar a rede
  4. Copiar os arquivos pjsua1.cfg e pjsua2.cfg para pc1 e pc2, respectivamente (use o subdiretório lab na máquina real, e /hostlab na máquina virtual)
  5. Em pc1 ou pc2 iniciar o wireshark com captura na interface eth0.
  6. Executar em pc1 e em pc2: 
    pjsua --config-file=pjsua.cfg
  7. Em pc1, no menu do pjsua iniciar uma chamada. Para isso digite m seguido de ENTER, e depois digite 1 e ENTER.
  8. Observe as mensagens mostradas no wireshark.
  9. Após encerrar a chamada, analise mensagens SIP no wireshark (menu Telephony -> Voip Calls -> Graph)
  10. Disseque a sinalização SIP entre os softphones.
  11. Identifique como foi transportada a voz digitalizada.


Questões:

  1. Quem foram o UAC e UAS nesse experimento ?
  2. Quantas requisições SIP foram realizadas para uma chamada completa ?
  3. Quantas mensagens, transações, diálogos e chamadas foram realizadas ?
  4. Como a voz digitalizada foi transportada ? Foi usado algum protocolo em especial ?
  5. Qual o CODEC selecionado por cada parte? Onde isso foi feito ?
  6. Qual a lista de CODECS suportados?

SDP (Session Description Protocol)

Ao iniciar uma chamada com SIP, a negociação de midia a ser transmitida é especificada no corpo da mensagem INVITE. O formato da especificação é descrito pelo protocolo SDP (Session Description Protocol), contendo as seguintes informações:

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

Assim como SIP, SDP codifica suas informações em texto simples. Uma mensagem SDP é composta por linhas de texto chamadas de campos, cujos nomes são abreviados por uma única letra. Os campos de uma mensagem SDP são:

Sdp-fields.png
Tabela de campos SDP


Um exemplo de mensagem SDP segue abaixo:

Sdp-msg.png


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


Atividade

  1. Usando o mesmo experimento do Netkit anterior, realize uma chamada 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
  2. Realize uma chamada para uma das câmeras IP. Em seguida, faça a mesma análise do ítem 1.

Sinalização no VMS

O VMS deve apresentar o video obtido de uma câmera. O acesso à câmera se faz via SIP, o que implica duas necessidades imediatas:

  1. Preparar a câmera para que possa ser acessada com SIP
  2. Incorporar ao VMS a funcionalidade de sinalização com SIP


As câmeras IP com suporte a SIP disponíveis demandam um servidor SIP onde devem se registrar. O servidor SIP é uma entidade que assume um ou mais papéis, tais como:

  • servidor de registro (registrar)
  • proxy
  • servidor de redirecionamento (redirect)


Num primeiro momento deseja-se implantar um cenário simplificado, em que o protótipo do VMS seja capaz de acessar uma câmera. O acesso ocorre em três partes:

  1. A câmera deve se registrar num Registrar SIP:
    Smu-Camera-sip-registro.jpg


  2. O VMS inicia uma chamada para a câmera, a qual é intermediada por um proxy SIP:
    Smu-Camera-sip-chamada.jpg


  3. Se a chamada for estabelecida, a stream de video flui da câmera diretamente para o VMS:
    Smu-Camera-sip-stream.jpg



A implantação desse cenário envolve primeiro associar a câmera a um servidor SIP. Em seguida, deve-se estender o protótipo do VMS para ser capaz de chamá-la.

O servidor SIP será implantado no computador do professor. Esse servidor inicialmente deve se apresentar como um simples PBX IP, sendo configurado para aceitar o registro da câmera. Seu endereço IP será 192.168.1.201.

VMS com SIP

Tornar o VMS capaz de iniciar uma chamada SIP com a câmera envolve usar uma API SIP. Isso envolve:

  1. Identificar uma API SIP que satisfaça os requisitos do VMS (iniciar, manter e terminar chamadas autenticadas de audio e video)
  2. Instalar o software dessa API
  3. Aprender a usar a API:
    • Identificar os elementos da API e seus papéis no estabelecimento de chamadas
    • Usar a API para fazer um registro no servidor SIP
    • Usar a API para fazer uma chamada de teste (audio) no servidor SIP
    • Usar a API para fazer uma chamada de teste (video) no servidor SIP
    • Iniciar a reprodução da stream de video no VMS com base nos dados de media obtidos no estabelecimento da chamada


Algumas API SIP:

API SIP simplificada

As API SIP existentes são pouco documentadas (ex: SipPy, Twisted, aiosip, libre), ou não atendem a necessidade do VMS (ex: PJSIP). Uma nova API foi desenvolvida sob medida para a necessidade do VMS. Essa API, chamada meuSip, oferece um UAC SIP capaz unicamente de realizar chamadas, além de se integrar facilmente ao ambiente gráfico ou mesmo a algum outro tipo de event loop. Segue um exemplo de realização de uma chamada: 

#!/usr/bin/python3

import meusip,siptrans
import selectors

# cria um UserAgent com originador "100" e IP do UAC=192.168.1.53
c = siptrans.UserAgent('100', ip='192.168.1.53')

# adiciona uma descrição de media do tipo audio ao UAC, incluindo
# respectivos codecs
media = meusip.SDPMedia('audio',4000)
media.add_codec(0, 'PCMU/8000')
media.add_codec(1, 'PCMA/8000')
c.add_media(media)

# inicia uma chamada para o contato "200" que está no UAS 192.168.1.54
c.call('200','192.168.1.54')

# Um loop de eventos simplificado:
# detecta eventos (mensagens recebidas, timeouts) e os encaminha ao UAC

sched = selectors.DefaultSelector()
sched.register(c.fileno, selectors.EVENT_READ)
while True:
    ev = sched.select(5000)
    if not ev: # se ocorreu timeout
        c.handle_timeout()
    else: # se uma mensagem foi recebida
        c.handle()
    if c.idle: break # se chamada encerrou, então termina

Uma demonstração de realização de chamada com a API meuSip, a qual faz uma única chamada. Note que a stream de audio é ignorada. Nesse exemplo, usa-se um DefaultSelector para despachar eventos para a API.'


A API meuSip pode ser obtida aqui:


A API meuSip se integra facilmente com a API gráfica. No caso de Gtk, que possui seu próprio 'event loop, devem-se usar IOChannel para monitorar o socket, e um tipo de timer próprio da Glib para o timeout: 

#!/usr/bin/python3
 
import meusip,siptrans
import selectors
import gi
gi.require_version('Gtk', '3.0')
gi.require_version('Vte', '2.91')
from gi.repository import Gtk
from gi.repository import GLib

Timeout = 5 # 5 seg
 
# cria um UserAgent com originador "100" e IP do UAC=192.168.1.53
c = siptrans.UserAgent('100', ip='192.168.1.53')
 
# adiciona uma descrição de media do tipo audio ao UAC, incluindo
# respectivos codecs
media = meusip.SDPMedia('audio',4000)
media.add_codec(0, 'PCMU/8000')
media.add_codec(1, 'PCMA/8000')
c.add_media(media)

# cria um IOChannel associado ao UAC
chan = GLib.IOChannel(c.fileno)

# define o IOChannel como não-bloqueante
chan.set_flags(GLib.IO_FLAG_NONBLOCK)

# registra um callback no IOChannel para condição de leitura
cond = GLib.IOCondition(GLib.IOCondition.IN)
chan.add_watch(cond, c.handle)

# cria um timer para o timeout
tout = GLib.timeout_add_seconds(Timeout, c.handle_timeout)

# inicia uma chamada para o contato "200" que está no UAS 192.168.1.54
c.call('200','192.168.1.52')
 
# O loop de eventos do ambiente gráfico !
Gtk.main()

Tarefa e avaliação 1

A avaliação 1 consiste do protótipo do VMS capaz de estabelecer uma chamada de video com uma câmera IP. Esse protótipo deve ser capaz de realizar uma chamada para uma câmera e, em caso de sucesso, receber e reproduzir a stream de video.

A entrega deve ser feita pelo Moodle, onde estão maiores detalhes sobre o que deve constar nesse protótipo.

Notificação de presença


O serviço de notificação de eventos é um requisito para algumas aplicações, tais como mensageiros (seja de voz ou texto). O serviço implica notificar os agentes interessados sobre a ocorrência de eventos predefinidos. Em aplicações de mensageiros, os eventos são tipicamente a presença ou ausência de contatos cadastrados (ver figura a seguir). No caso do VMS, a notificação de eventos pode ser usada para identificar as câmeras disponíveis, e obter suas URI de contato.


Smu-Presence-arch.jpg
Arquitetura típica de um serviço de presença


O protocolo SIP define três mensagens que podem ser usadas para um serviço de notificação de eventos. Com essas mensagens é possível realizar comunicações com um modelo publicador-assinante (PS).

Método SIP Descrição
SUBSCRIBE Usado por um usuário SIP para assinar seu interesse por um certo tipo de evento (cabeçalho Event). A assinatura tem um duração dada pelo cabeçalho Expires, após a qual deve ser renovada.
NOTIFY Usado para notificar um assinante sobre o status do evento assinado.
PUBLISH Usado para publicar conteúdo associado a um evento, o qual é então divulgado para os assinantes por meio de mensagens NOTIFY.


Essas três mensagens implicitamente requerem uma entidade SIP intermediária que faz o papel de broker. No caso do serviço de presença, o intermediário é um servidor de presença, o qual mantém uma lista de assinantes e eventos. Assim, quando um broker recebe um PUBLISH, é sua responsabilidade gerar em consequência um NOTIFY para cada respectivo assinante. As duas figuras a seguir exemplificam o uso dessas mensagens e o papel do broker na intermediação.


Smu-Subscribe-ex.png
Sequência iniciada com SUBSCRIBE, mostrando as mensagens NOTIFY subsequente, com notificações de mudança de status do evento


Smu-Publish-ex.png
Publicação enviada com PUBLISH para o broker, e notificações subsequentes enviadas com NOTIFY para os assinantes


O serviço de presença SIP, além de usar as mensagens SUBSCRIBE e NOTIFY, especifica como essas mensagens devem ser usadas, quais cabeçalhos devem estar presentes e seus significados, e o formato do conteúdo a ser incluído no corpo das mensagem NOTIFY. Essa especificação faz parte do pacote presence, definido na RFC 3856. A figura a seguir ilustra uma mensagem com a descrição do status do contato Sophie.Germain@mathematica.org, informando que está disponível para comunicação.


Smu-Presence-body.png
Descrição baseada em XML sobre o status de presença de um contato. Esse conteúdo é enviado no corpo de uma mensagem NOTIFY


O serviço de presença SIP possibilita também a manutenção de listas de contatos, como explicado na RFC 4662. Com isso, um assinante precisa realizar uma única assinatura para a lista, para ser então notificado sobre o status de qualquer contato nela incluído. A lista de contatos é mantida em um servidor específico, chamado de RLS (Resource List Server), ou mesmo no servidor de presença.

Atividade

  1. Obtenha este arquivo de configuração do Netkit
  2. Importe-o no Netkit pelo menu File->Load only e inicie a rede
  3. Obtenha estes arquivos, e copie-os para o subdiretório lab dentro do diretório onde gravou o arquivo presence.conf:
  4. No Netkit2, em pbx1 execute: 
    cd /
tar xzf /hostlab/pbx1.tgz
    ... e em user1: 
    cd /
tar xzf /hostlab/user1.tgz
    ... e em user2: 
    cd /
tar xzf /hostlab/user2.tgz
  5. Em pbx1 execute o seguinte comando para iniciar o soft PBX, que funciona como um servidor de registro e de presença: 
    /etc/init.d/asterisk start
  6. Em user1 execute o agente SIP: 
    cd /root
pjsua --config-file=pjsua.cfg
  7. No prompt do agente SIP em user1 assine o interesse pela presença do contato 1 (que corresponde ao contato SIP 200). Digite s e tecle Enter. Em seguida, digite 1 e ENTER.
  8. Em user2 execute o agente SIP: 
    cd /root
pjsua --config-file=pjsua.cfg
  9. Observe no prompt de user1 se algum aviso sobre o contato sip:200@10.0.0.1 foi apresentado.
  10. Em user2 digite q e ENTER para terminar o agente SIP
  11. Observe novamente o prompt de user1 se algum aviso sobre o contato sip:200@10.0.0.1 foi apresentado.
  12. Em user1 digite q e ENTER para terminar o agente SIP
  13. Em pbx1 inicie o Wireshark para capturar na interface eth0
  14. Defina um filtro de apresnetação com conteúdo sip no wireshark, para que somente mensagens SIP sejam mostradas
  15. Repita os passos 4 a 6, e obsreve as mensagens capturadas pelo wireshark. Procure por transações inciadas por SUBSCRIBE e NOTIFY.
  16. Investigue os cabeçalhos e conteúdo das mensagens SUBSCRIBE e NOTIFY. Identifique as informações relativas ao serviço de presença.
  17. Como isso poderia ser usado no projeto do VMS ?
Disponível em “https://wiki.sj.ifsc.edu.br/index.php?title=SMU29009:_Sinalização&oldid=151677”