Em nosso último artigo, discorremos sobre as definições dos termos SIP e o nível de maturidade e realidade atuais. Agora vamos finalizar o tema com as aplicações SIP.

Telefonia

Protocolos para áudio e vídeo em telefonia são, em princípio, plenamente roteados em ambientes IP, visto que a rede subjacente provê uma infraestrutura roteável sobre a qual enviar a mídia. Todavia, um terminal telefônico utilizável requer funcionalidades adicionais, incluindo a habilidade de encontrar o terminal do interlocutor e de negociar um tipo de mídia compatível para a conversação entre os usuários.

Para realizar uma chamada telefônica SIP, um SIP User Agent (UA) envia um request de INVITE. No corpo da mensagem desse request, ele coloca a descrição SDP (Session Description Protocol) dos canais de mídia suportados por ele. Esse request é encaminhado pelos Proxies através da rede até atingir o seu destino, ou até ser rejeitado com um response de erro.

Quando o User Agent (UA) chamado recebe esse request de INVITE, ele verifica se é capaz de aceitar essa chamada e, então, inicia o ringing telefônico. Nesse intervalo, ele envia um response provisional de volta ao UA chamador para dizer a ele que o telefone, agora, está tocando. Quando o telefone é atendido, o UA chamado envia um response positivo final com a descrição SDP dos seus canais de mídia, de volta ao UA chamador. Ao receber esse response, ambas as partes possuem as descrições SDP dos canais de mídia do outro e podem definir qual canal será utilizado. O UA chamador também reconhece o sucesso da recepção da mensagem de response enviando um ACK, que é um tipo especial de request, de volta ao UA chamado.

 

Se, durante uma chamada, ambas as partes quiserem alterar a mídia – por exemplo, abrir um canal de vídeo -, uma delas deverá enviar um RE-INVITE (um INVITE dentro de um diálogo estabelecido) com um corpo SDP descrevendo a nova mídia. Se aceitável, o recebedor responderá positivamente com o seu SDP. Por outro lado, se ele rejeitar o request, a sessão continuará inalterada. Quando uma das partes quiser desligar a chamada, ela enviará um request de BYE.

Instant Messaging (IM) e Presença

Trataremos estas duas aplicações em conjunto, por motivos que ficarão claros a seguir.

No mundo das telecomunicações, parece que sempre existem dois padrões para tratar a mesma coisa. Por exemplo, para controlar chamadas, existem o SIP e o H.323, enquanto nos EUA utilizam-se circuitos T1, e na Europa os entroncamentos são do tipo E1; com relação a codecs de voz e vídeo, existem múltiplas opções. Padrões competidores aparecem por diversos motivos, como substituir velhas ideias, incorporar novas tecnologias ou melhorar alguma característica específica. Todavia, em alguns casos, os padrões competidores atingem o mesmo objetivo, mesmo sem qualquer semelhança entre eles. Esse parece ser o caso entre os dois padrões mais difundidos de Instant Messaging (IM) e Presença, o SIP/SIMPLE e o XMPP.

O SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) foi ratificado em 2004 pelo IETF como padrão para IM e Presença. Ele foi adotado rapidamente pelo WG e por diferentes fabricantes como Microsoft, Avaya e Cisco.

O XMPP (Extensible Messaging and Presence Protocol) é uma evolução do Jabber que foi desenvolvido pela comunidade open source em 1999. Ele foi adotado mais tarde pelo IETF em 2002 e aprovado como padrão em 2004. Passou a ser usado pela Jabber e pelo Google Talk.

Existem diferenças entre eles, principalmente nas respectivas arquiteturas. O XMPP é inerentemente client-server. Deve existir algo entre dois clientes XMPP para administrar mensagens de estado e offline. Já o SIMPLE, como o SIP, foi projetado para funcionar no modo peer-to-peer, no qual a inteligência reside nos terminais. Não quer dizer que o SIP evoluiu para incluir diferentes servidores entre seus clients, mas a intenção do SIMPLE é de que esses servidores, simplesmente, não sejam necessários. Esse não é o caso do XMPP, que espera que exista alguém no meio das suas conversações.

Existem outras diferenças, como a formatação dos dados de IM, o modo como mídia e sinalização são separadas, a representação URI, a autenticação e os requerimentos da camada de transporte, mas nenhuma grande o suficiente para justificar a existência de dois protocolos com o mesmo objetivo. Atualmente, o XMPP é mais utilizado.

Até que chegue o dia em que exista apenas um protocolo, existem gateways para permitem a federação das informações de Presença e IM entre clients XMPP e SIMPLE. Isso possibilita que o client SIMPLE do Microsoft Lync receba uma IM de um client XMPP do Google Talk. Dessa forma, é altamente recomendável usar uma plataforma de Presença e IM que suporte ambos os protocolos, de modo a evitar problemas de interoperabilidade.

Em maio de 2013, o Google anunciou sua nova plataforma para IM e vídeo chat, o Google+ Hangouts, que substituiu três produtos de messaging utilizados pelo Google (Google Talk, Google+ Messenger e Hangouts). O Google projetou o Google+ Hangouts para ser o futuro do seu produto de telefonia, o Google Voice. Nas atuais versões do Android, o Google+ Hangouts é a aplicação default para mensagens de texto. Surpreendentemente, o Google+ Hangouts não suporta mais o XMPP, como fazia o Google Talk, passando a usar um protocolo proprietário. Por conta disso, não será mais possível para usuários do Google+ Hangouts trocar IMs e informações de Presença com usuários de clients Microsoft, Avaya, Cisco Jabber e Openfire, entre outros.