Protocolo SIP

Stanza Objetivo Exemplo

para anunciar a

disponibilidade do usuário para comunicação.

<status>Tô com fome: no almoço</status>

</presence>

<iq>

Esta stanza (Info/Query) fornece uma estrutura para interações do tipo solicitação/resposta, similar aos métodos PUT e GET do HTTP.

<iq from="[email protected]/IdDE"

id="rr82a1z7"

to="[email protected]"

type="get">

<query xmlns="jabber:iq:roster"/>

</iq>

A stanza <message> é utilizada para o envio das instruções do protocolo do ambiente IdDE, descrito na seção 4.4. O exemplo da stanza <iq> mostra a solicitação da lista de contatos do usuário [email protected] para o usuário [email protected].

A comprovação das funcionalidades e do potencial do protocolo XMPP foi obtida através da criação de um protótipo inicial. Através deste protótipo, foi possível enviar mensagens de texto, nas quais estavam encapsuladas mensagens do protocolo do IdDE.

Todavia, este protótipo também apontou um problema significativo. Apesar de o protocolo XMPP permitir a comunicação via áudio, as bibliotecas disponíveis na linguagem Java possuem um suporte muito incipiente a este recurso, o que impossibilitou o estabelecimento de comunicação via áudio.

Face ao problema identificado, o qual inviabilizou a utilização deste protocolo para a comunicação via áudio, iniciou-se uma nova etapa de testes e experimentações em busca de outro protocolo que pudesse ser utilizado e que tivesse maior suporte de bibliotecas na linguagem de programação Java.

extensões para possibilitar mensagens instantâneas, presença e notificação de eventos. Nos testes realizados, a comunicação via áudio foi bem sucedida, demonstrando se tratar de uma opção viável para utilização no IdDE. Todavia, o suporte a mensagens instantâneas, presença e notificação de eventos não se mostrou tão eficaz quanto no protocolo XMPP, o que impossibilitou o seu uso como protocolo único para todos os serviços do IdDE. Dessa forma, a solução encontrada para suprir as necessidades propostas neste trabalho, foi a utilização de ambos os protocolos, XMPP e SIP.

De acordo com Sinnreich e Johnston (2006), as comunicações IP utilizam endereços similares aos e-mails, a exemplo de sip:[email protected], chamados de SIP URIs. Pode-se observar que se trata do mesmo tipo de formatação utilizada no protocolo XMPP. Para os casos nos quais a comunicação deva acontecer com um número de telefone, o formato do endereço SIP é: sip:[email protected]. Neste endereço, +55 representa o país, 51 o código de área e 98765432 o número do telefone. Esta formatação se aplica tanto a telefones convencionais quanto de telefonia móvel.

Existem diversos tipos de dispositivos que podem ser utilizados na comunicação SIP, como por exemplo: computadores, telefones IP, ATAs, dispositivos móveis, além de telefones convencionais e celulares (PSTN). Todavia, é importante observar que, para efetuar chamas oriundas da, e para a rede PSTN (rede pública de telefonia comutada), faz-se necessária sua interconexão com a rede SIP. Esse papel é desempenhado pelos gateways de empresas prestadoras de serviços de telefonia [Sinnreich e Johnston, 2006]. A Figura 20 exemplifica a estrutura e interconexão das redes PSTN e SIP, e seus respectivos dispositivos.

Dispositivos IP com suporte a SIP podem chamar uns aos outros diretamente, desde que saibam o endereço. Assim, uma chamada de telefone IP pode ser feita diretamente entre dois ou mais telefones SIP ou computadores. Inclusive, pequenas conferências podem ser realizadas por vários usuários se estes se conectarem a um dispositivo que atue como ponte da conferência. O papel de ponte pode ser desempenhado por um dos telefones SIP, que passará a ser tanto participante da conferência, quanto ponte da conferência. [Sinnreich e Johnston, 2006].

Os elementos básicos do protocolo são, de acordo com Davidson et al. (2006):

· User Agents (UA) – trata-se de uma função lógica que, na rede SIP, inicia ou responde às solicitações de transações SIP. O User Agent Client (UAC) é quem faz requisições SIP ou recebe respostas SIP, enquanto que o User Agent Server (UAS) aceita as requisições SIP e gera as respostas SIP;

· Proxy – é uma entidade intermediária na rede SIP, responsável por encaminhar requisições SIP para os respectivos UAS, ou outro proxy;

· Registrar Server – é um UAS que recebe solicitações de autenticação e é responsável por manter atualizadas as informações dos UA's;

· Redirect Server – é um UAS que direciona o UAC a contatar um URI alternativo.

As mensagens, chamadas de requisições SIP, são enviadas pelo cliente para o servidor, com o objetivo de realizar uma operação. O protocolo é baseado em mensagens de texto, similares ao HTTP e ao SMTP. Na Figura 21 é apresentado um exemplo de uma mensagem

Figura 20: Interconexão de redes SIP e PSTN, adaptada de [Sinnreich e Johnston, 2006]

SIP. Conforme pode ser observado no SIP URI (sip:[email protected]), esta requisição, do tipo INVITE, é destinada ao usuário John, que está conectado num dispositivo com o endereço IP 192.190.132.31. O envio ocorre através de UDP e, como a porta não foi informada, é utilizada a porta padrão 5060. É importante observar que a comunicação também pode ocorrer através de TCP, portas 5060 e 5061, esta última para conexão segura via TLS.

Figura 21: Exemplo de mensagem do protocolo SIP [Hersent, 2010]

A RFC 3261¹⁴ define seis requisições [Davidson et al, 2006]:

· INVITE: método utilizado para convidar o destinatário a participar de uma sessão;

· ACK: utilizado para indicar que o UAC recebeu a resposta a um INVITE que enviou;

· OPTIONS: utilizado para consultar as funcionalidades suportadas pelo UAS;

· BYE: utilizado para finalizar a sessão estabelecida;

· CANCEL: utilizado para cancelar uma requisição em andamento, a exemplo de um INVITE;

· REGISTER: utilizado para registrar um usuário num servidor SIP.

Normalmente, apenas o estabelecimento de uma sessão é feita através da porta 5060.

Quando a sessão está estabelecida, são utilizadas portas entre 10.000 e 20.000 para a transmissão do áudio em tempo real.

A Figura 22 mostra o fluxo de mensagens trocadas entre os usuários e o servidor, a partir do momento em que um usuário solicita o estabelecimento de uma sessão de voz com outro usuário.

14RFC 3261: http://www.ietf.org/rfc/rfc3261.txt

A análise do fluxo deve ser feita de cima para baixo, e a ordem das mensagens acompanha as numerações:

1. O Usuário 1 envia uma mensagem ao servidor, convidando o Usuário 2 a estabelecer uma sessão.

2. O servidor responde informando que a solicitação está em andamento.

3. O servidor encaminha a solicitação ao Usuário 2.

4. Se o Usuário 2 estiver conectado, o servidor receberá a resposta dando conta que ele está sendo chamado.

5. O servidor encaminha a informação ao Usuário 1.

6. Se o Usuário 2 aceitar a sessão, a respectiva mensagem é enviada ao servidor.

7. A mensagem de aceite é então repassada ao Usuário 1.

8. O Usuário 1 envia uma mensagem indicando que recebeu a resposta relativa ao seu comando INVITE (1).

9. A mensagem é repassada ao Usuário 2, para que na sequencia se estabeleça a sessão.

10.A sessão está estabelecida e os usuários podem conversar.

11.O Usuário 1 envia uma mensagem para finalizar a sessão.

12.O servidor encaminha a mensagem de fim de sessão para o Usuário 2.

Figura 22: Fluxo de uma chamada SIP

13.O Usuário 2 responde positivamente e encerra a sessão.

14.O servidor repassa a mensagem ao Usuário 1, e também encerra a sessão.