Um estudo do protocolo SIP e sua utilizao em redes de telefonia mvel

Romildo Martins da Silva Bezerra1

1

Mestrado em Redes de Computadores (UNIFACS)

romildo@cdl.com.br

Resumo. Este trabalho visa apresentar o protocolo SIP (Session Initiation Protocol), explicando sua arquitetura e o processo de troca de mensagens. Alm disso mostra a utilizao do SIP em redes de telefonia mvel exibindo o funcionamento, problemas e sugestes para solues desses.

1. Viso geral do protocolo SIP

O Protocolo de Inicializao de Sesso, SIP - Session Initiation Protocol, foi definido na RFC 2543 em maro de 1999 e revisado em junho de 2002 pelo grupo de trabalho MMUSIC (Multiparty Multimedia Session Protocol) do IETF. Deste grupo destacamos dois pesquisadores J. Rosenberg da Dynamicsoft e H. Schulzrinne da Columbia University como principais colaboradores no desenvolvimento do SIP. O objetivo do SIP criar, modificar parmetros e terminar sesses entre o(os) usurio(os), onde nestas podem ser unicast (ponto a ponto) e multicast (conferncia) contendo qualquer tipo de trfego multimdia. Para fazer o controle das sesses, o SIP capaz de iniciar e encerrar uma chamada, incluir ou excluir participantes de uma sesso e ainda oferece transferncia/manuteno de ligaes e transio entre conexes ponto a ponto e conferncia. O SIP um protocolo de sinalizao utilizado para estabelecer endereos IP que os sistemas usaro para transferncia dos dados. Como o SIP envolve apenas trfego de sinalizao, no incluindo o trfego de dados, a filosofia atrs do SIP manter as necessidades das aplicaes e prover a interoperabilidade entre computadores no processo de construo de novos servios multimdia. Utiliza a arquitetura cliente-servidor, onde a mquina que solicita o chamado atua como cliente e a que recebe o chamado atua como servidor. Como protocolo de sinalizao, o SIP deve possuir : Localizao de usurios, envolve a determinao do sistema final a ser utilizado na ligao. Capacidades do usurio, envolve a determinao da mdia e de seus parmetros utilizados por um ou mais usurios.

Disponibilidade do usurio, serve para avaliar a disponibilidade do usurio a participar de uma sesso. Configurao de chamada, serve para estabelecimento da chamada em ambos os lados da comunicao. Manipulao de chamada, incluir transferncia e trmino do chamado.

Dos atrativos para utilizao do SIP destacam-se a possibilidade de mobilidade do usurio, a flexibilidade e simplicidade do protocolo, que sero melhores descritos no captulo quatro.

2. A arquitetura SIP
Uma rede SIP constituda de quatro entidades lgicas do SIP. Cada entidade tem uma funo especfica e participa na comunicao SIP como um cliente (solicitando pedidos), um servidor (respondendo os pedidos) ou ambos. Ou seja, um dispositivo fsico pode funcionalidades de uma ou mais entidades lgicas do SIP. Por exemplo, um servidor de rede trabalha como servidor proxy, mas executa a funo de Registrar ao mesmo tempo. A seguir descreveremos as quatro entidades lgicas utilizadas na arquitetura SIP: User Agent, Proxy Server, Redirect Server e Registrar. No SIP um User Agent (UA) uma entidade terminal, responsvel por inicializar e terminar a conexo atravs de trocas de pedidos e respostas. A RFC 3261 define o UA como uma aplicao que contm o User Agent Client e o User Client Server, definidos como: User Agent Client (UAC) uma aplicao cliente que inicializa o pedido SIP. User Agent Server (UAS) uma aplicao de servidor que localiza o usurio quando um pedido SIP recebido, respondendo tal pedido de acordo com o usurio.

Em outras palavras, se a aplicao inicia um pedido, age como um UAC durante a durao daquela transao. Se ela recebe um pedido assume o papel de um UAS durante o processo daquela transao. Alguns dos dispositivos que podem ter uma funo de UA em uma rede SIP so: estaes, telefones IP, servios de resposta automtica e agentes de chamada. Um proxy server uma entidade intermediria que age como um servidor e um cliente com o objetivo de fazer pedidos em nome de um cliente terminal. Um proxy l, interpreta, e se necessrio, reescreve a mensagem do pedido para s depois encaminhla. Um pedido pode ser roteado por diversos proxy, sendo importante que o retorno da mensagem siga o mesmo caminho do envio. Isso no um problema quando o TCP utilizado, mas para uso com o UDP o protocolo SIP j possui um campo no cabealho (Via) para este objetivo. Caso exista a necessidade de roteamento de todos os pedidos, o campo Record Route pode ser utilizado para gravar o caminho do pedido. Quando isto

ocorre, o modelo de chamada fica bastante parecido com o modelo do gatekeeeper do H.323. Outra entidade da arquitetura SIP o redirect server, utilizado para responder a um pedido com um redirecionamento do mesmo. Quando utilizado junto com um registrar para redirecionar a chada para a localizao atual do discador da chamada. recomendado para melhoria da escalabilidade de servidores de distribuio de chamadas. E por ultimo o Registrar, que tem como funo aceitar os pedidos REGISTER e em seguida atualizar um banco de dados de localizao de usurios. Agora que j conhecida a definio das entidades SIP possvel descrever a comunicao numa rede SIP. O diagrama desta rede pode ser visto na figura 1.

Figura 1 Arquitetura de uma rede SIP Para descrever o funcionamento da figura acima, sero descritos todos os passos1 de um pedido feito por romildo@unifacs.br para ricardo@ietf.org. 1. Um User Agent (UA) SIP cria um pedido para ricardo@ietf.org e o envia para o proxy server. 2. O proxy local procura por ietf.org no servidor de domnio (DNS) e obtm o endereo IP de destino do pedido SIP para este domnio e o seu proxy. 3. O servidor ietf.org conhece o usurio ricardo que est atualmente logado em sbc.org.br. O servidor redireciona o proxy para este endereo.

Exceto o procedimento de autenticao no Registrar

4. O proxy local procura agora por sbc.org.br no DNS e obtm o endereo IP de destino do pedido SIP para este domnio e o seu proxy. 5. O servidor SIP da sbc.org.br consulta uma base local (usando o registrar) e localiza o usurio ricardo@sbc.org.br. 6. O servidor principal da SBC faz um pedido para o servidor proxy que o usurio ricardo est localizado. 7. O servidor ao qual o usurio ricardo est localizado resolve seu endereo IP e envia a mensagem para o usurio. 8. O usurio aceita a chamada e responde para o seu proxy, que ir reencaminhar a mensagem at o destino.

3. O formato da mensagem
A codificao utilizada nas mensagens SIP utiliza a sintaxe HTTP/1.1, descrita RFC 2068, e o conjunto de caracteres o ISSO 10646 com a codificao UTF-8, presente na RFC 2279. As mensagens SIP podem ser apenas de dois tipos: pedidos e respostas. Para simplificar, logo abaixo so apresentadas duas tabelas com a lista de opes de pedidos e de respostas. Mtodo INVITE ACK BYE CANCEL OPTIONS REGISTER INFO Descrio Inicializa chamadas ou parmetros da mesma Confirma um pedido do tipo INVITE Termina a chamada Cancela o processo de busca e discagem Utilizado para reconhecimento das capacidades do cliente Registra a localizao atual atravs do Envia informaes durante a sesso que no altera o seu estado Tabela 1 Pedidos do protocolo SIP As mensagens de respostas do SIP contem cdigos numricos de respostas, parcialmente baseados nos cdigos do HTTP. Existem seis classes (vistas na Tabela 2) diferentes, distribudas em dois tipos de respostas: Provisrias (classe 1xx) respostas provisrias so utilizadas pelo servidor para indicar o estado da sesso SIP, mas no a termina. Finais (classe 2xx, 3xx, 4xx, 5xx e 6xx) estes tipos de respostas encerram as sesses SIP.

Todas as classes de respostas SIP esto especificadas a seguir. Classe 1xx 2xx 3xx 4xx 5xx 6xx Perfil Informativo Sucesso Redirecionamento Erro do cliente Erro do servidor Falha Global Descrio Pedido recebido, continuando a processar o pedido Ao completada com sucesso Necessidade de uma ao adicional para completar o pedido Pedido com sintaxe invlida ou no pode ser executado neste servidor Erro no servidor Falha global

Tabela 2 Classes ou categorias das respostas As mensagens SIP so compostas de trs campos, start line, headers e body. A linha de incio, ou start line, identifica o tipo da mensagem e a verso do protocolo. Quando a mensagem um pedido (request-line), a linha de incio inclui uma Request URI que indica o usurio ou o servio ao qual este pedido est sendo encaminhado (Diferentemente do campo To, onde o endereo pode ser escrito pelos servidores proxy). E quando ela uma resposta (status-line) guarda o cdigo de status numrico e sua frase textual associada. O segundo campo, headers, usado para transportar os atributos da mensagem e modificar o signicado deles. A sua sintaxe e semntica similar ao aos campos do cabealho HTTP e todos seguem o formato <name>:<value>. E por fim o campo Body usado para descrever a sesso a ser iniciada. Os corpos de mensagem podem aparecer no pedido e em mensagens de resposta. O protocolo SIP faz uma distino clara entre a informao de sinalizao, carregada na linha de nicio do SIP e headers, e a sesso de descrio da informao, que fora ao escopo do SIP. Este campo pode utilizar o SDP (Session Description Protocol), o MIME(Multipurpose Internet Mail Extensions) ou outra futura implementao a ser definida pelo IETF. Como ilustrao coloremos duas mensagens SIP, um pedido e uma resposta, para o fechamento de uma chamada de voz. O cliente SIP romildo@unifacs.br est convidando o usurio ricardo@ietf.org para uma chamada e este aprova o pedido realizado.

Campos do pedido
INVITE sip:ricardo@ietf.org SIP/2.0 Via: SIP/2.0/UDP 192.168.0.25 From: Romildo. <sip: romildo@unifacs.br >

Descrio
Request line composta do tipo da mensagem, request URI e SIP version Endereo do n anterior Cliente SIP solicitante

To: Ricardo. <sip: ricardo@ietf.org > Call-ID: 2325031978@romildo@unifacs.br CSeq: 1 INVITE Subject: Resenha de Artigo. Content-Type: application/SDP Content-Length:

Cliente SIP convidado ID nico global para esta chamada Sequencia de comando Ttulo da mensgem Tipo do body (neste caso SDP) Tamanho da mensagem Linha em branco para indicar o fim do cabealho Sip e o incio do body.

v=0 o=Romildo 4532 235655 IN IP4 192.168.0.25 s=Call from Romildo c=IN IP4 192.168.0.25 m=audio 3217 RTP/AVP 0 3 4 5

Verso do SDP Criador, identificador da sesso e endereo

Informao da conexo Descrio da media

Tabela 3 Exemplo de uma mensagem de request SIP

Campos da resposta
SIP / 2.0 200 OK Via: SIP/2.0/UDP 192.168.0.25 From: Romildo. <sip: romildo@unifacs.br >

Descrio
Status line SIP version, response code e reason phrase Copiado do pedido Copiado do pedido

To: Ricardo. <sip: ricardo@ietf.org >, tag=8643 Copiado do pedido Call-ID: 2325031978@romildo@unifacs.br CSeq: 1 INVITE Content-Type: application/SDP Content-Length: Copiado do pedido Copiado do pedido Tipo do body (neste caso SDP) Tamanho da mensagem Linha em branco para indicar o fim do cabealho Sip e o incio do body. v=0 o=Ricardo 3376 653897 IN IP4 192.168.0.17 s=Lunch c=IN IP4 192.168.0.17 m=audio 50013 RTP/AVP 0 3 Informao da conexo Descrio da media Verso do SDP Criador, identificador da sesso e endereo

Tabela 4 Exemplo de uma mensagem de resposta SIP

4. Por que o SIP?

Nesta seo sero descritos alguns fatores que fazem o SIP ocupar mais espao no mercado, concorrendo com o H.323 e MEGACO, colocando SIP como protocolo promissor, possuindo o maior crescimento no seu segmento. Entretanto no esperado um domnio completo do SIP devido a grande plataforma instalada com protocolos antecessores a ele, o H.323 por exemplo, e evoluo dos seus concorrentes no intuito de agregar vantagens que possam concorrer com o SIP. A primeira vantagem do SIP sua velocidade. Esta decorrente da simplicidade do SIP que permite a execuo de uma transao seja equivalente a quatro ou cinco transaes do H.323 verso 1 e flexibilidade de usar UDP. A possibilidade de utilizao de multicast tanto em fluxo multimdia (como o H.323) como tambm em mensagens de sinalizao. O uso de multicast est diretamente associado a localizao de usurios numa empresa e a utilizao em call centers. Durante a utilizao de multicast na sinalizao, os pedidos SIP so transportados usando-se UDP, pois s o UDP capaz de transportar multicast sobre IP. Priorizao de trfego de algumas linhas telefnicas com o uso do campo Priority permite atender as necessidades legais de alguns pases, bem como a necessidade dos administradores de rede para indicar que usurio ter a preferncia no uso dos recursos da rede. A princpio a utilizao de URLs como identificadores no parece ser um item poderoso. Entretanto um servidor SIP pode redirecionar chamadas SIP para servidores no SIP com grande flexibilidade. Outro ponto em favor do SIP relacionado a flexibilidade e escalabilidade, pelo fato ser baseado em servios de conferncia distribuda e protocolos Internet j difundidos no mercado como o HTTP (Hypertext Transfer Protocol) e SMTP (Simple Mail Transfer Protocol). Segundo dados da Wind River, o nmero de produtos no mercado que utilizam SIP bastante superior ao seu maior concorrente o H.323, confome pode ser visto na figura 2. Alm disso, os provedores de servio em Telefonia IP esto mais preparados para o SIP. Em relao a plataforma de pordutos e servios instalados, o H.323 leva uma imensa vantagem.

Figura 2 Porcentagem de produtos no mercado por protocolo

Figura 3 Porcentagem de prestadoras de servio no mercado por protocolo A interoperabilidade com o mundo Internet, a flexibilidade e a mobilidade abrem possibilidade de uma infinidade de novos servios com este protocolo. A seguir descreveremos o uso da mobilidade com o protocolo SIP.

5. Mobilidade utilizando SIP

A mobilidade certamente ser o fator mais importante no processo de difuso do protocolo SIP, pois a possibilidade de localizao de um usurio independentemente de qual dispositivo ele esteja utilizando (PC, palmtop, notebook ou at um telefone celular) por si s bastante atrativa. Devido a possibilidade de roaming necessria uma habilidade da infra-estrutra e dos algoritmos utilizados para prover o deslocamento do usurio, sem causar impacto na sua chamada ativa. Para isso assumido que o dispositivo mvel pertena a uma rede local na qual um SIP Server seja responsvel em receber as mensagens informando a localizao do dispositivo. O grande problema como manter atualizada tal localizao de forma freqente e rpida para que uma mudana de estao de rdio no ocasione uma perda da localizao. Na utilizao do SIP com dispositivos mveis, quando um servidor SIP envia um pedido para um dispositivo mvel, o redirect server tem a informao da localizao do dispositivo mvel redireciona o pedido, conforme visto na figura a seguir.

Figura 4 SIP na comunicao de dispositivos mveis

Se durante a sesso o dispositivo mvel se desloca, um novo pedido tem que ser enviado ao dispositivo um novo pedido utilizando o mesmo identificador de chamada usado na conexo original. Um novo IP deve ser colocado nas mensagens SIP que corresponder o servidor onde as futuras mensagens SIP sero enviadas. Para redirecionamento do fluxo de trfego com o deslocamento do dispositivo mvel, o endereo IP deve ser alterado no memento em que o dispositivo mudar de estao mvel (poderia ser dito tambm mudana de clula).

Figura 5 Atualizao constante de informaes Para o funcionamento desta arquitetura mvel com o protocolo SIP, se faz necessrio o constante registro da localizao do dispositivo no SIP server local, para que todos os redirecionamentos sejam feitos com exatido. recomendado que neste processo seja utilizado autenticao e criptografia nas mensagens SIP, utilizando o conceito de chaves pblicas/privadas.

Figura 6 Atualizao no SIP Redirect Server Caso o dispositivo mvel esta utilizando Mbile IP, no estritamente necessrio (embora til) que o servidor SIP tenha a localizao atual do dispositivo mvel. Alm de ser um desperdcio de recursos manter a localizao do usurio em dois servidores, isto pode acarretar problemas de inconsistncia e/ou gerenciamento do servio. Algumas solues para correo de tal problema podem ser vistas em [Schulzrinne 2003].

Se um cliente SIP tem por algum motivo a localizao antiga (e errada) do dispositivo mvel necessrio um mecanismo para correo deste erro. Certamente este erro ser comum quando o UAC e o UAS sejam dispositivos mveis. Para isso preciso que durante o processo e dilogo entre os clientes, o SIP server local seja infromado de todas as mudanas. A nica exigncia feita para este mecanismo que o SIP server com a base de localizao dos usurios no seja tambm um idspositivo mvel ou o seu endereo no seja alterado durante o processo. Numa arquitetura para utilizao de mobilidade com o protocolo SIP no podemos utilizar o protocolo TCP, ficando restrito apenas ao uso do UDP. Numa eventual utilizao com o IP Mvel, os dois protocolos seriam utilizados para que suporte a aplicaes como FTP, TELNET e HTTP sejam utilizadas sem problemas. Uma soluo para tal problema seria a possibilidade de escolha por parte do dispositivo mvel de quando utilizar cada protocolo, associando-o a qual endereo SIP (se o mvel ou o fixo) ser utilizado. Obviamente, tal escolha pode ficar totalmente transparente pra o usurio se tal escolha estiver associada ao tipo de aplicao utilizada. Outra soluo seria uma readaptao dos protocolos de rede para o novo mundo da telefonia mvel. Fatores relativos a implementao ainda no foram padronizados e no acredito que tal padronizao esteja perto de ocorrer, pois envolve uma gama de reas distintas (provedores de servios, universidades, fabricantes de dispositivos moveis e de equipamentos de telecomunicaes, desenvolvedores de sistemas operacionais e aplicaes mveis, dentre outros). Alguns problemas inerentes a esta soluo como atraso fim-a-fim, delay do handoff dos disposivos e a dependncia da tecnologia wireless disponvel pela operadora de servios mveis esto sendo estudados e tem uma vasta rea de pesquisa a ser percorrida.

6. Consideraes finais
Existe uma enorme diversidade de servios oferecidos com o SIP como disponibilizao de servios de call centers virtuais [Kaish 2003], aplicaes para servios de mensagens instantneas [Schulzrinne 2002a] e servios de localizao de veculos. Entretanto foi escolhido o servio de telefonia mvel por atingir uma margem bem maior de usurios. As capacidades que o SIP oferece so essenciais para a rede de telefonia mvel, colocando-o numa posio confortvel em relao aos seus correntes. O crescimento do uso do protocolo SIP para estas aplicaes dever estar associado com a integrao crescente dos dispositivos mveis, a reduo de custos e uma melhoria na largura de banda do servio (pelo menos aqui no Brasil) para que um leque maior de aplicativos possam ser executados nos dispositivos. Alguns detalhes do SIP tero ainda que evoluir como a segurana [Cisco 2002], implementao de QoS e mecanismos de controle de prioridade [Schulzrinne 2002b]. Especificamente no servio de telefonia mvel preocupante o atraso fim-a-fim e delay no handoff esto sendo ainda estudados.

7. Bibliografia
[Cisco 2002] Cisco Systems. Security in SIP-Based Networks.2002. [Hersent 2002] Oliver Hersent. Telefonia IP Comunicao baseada em pacotes. Addison Waley. 2002. [Kaish 2003] Henning Schulzrinne. How Sip Is Transforming The Call Center Industry. Interney Telephony. 2003. [Nelson 2002] Jim Nelson. SIP For Next-Generation Mobile Services:Mobile IP and SIP). 2002. [Oslo 2002] University of Oslo. Applying different types of mobility on one network (particular case:Mobile IP and SIP). 2002. [Schulzrinne 2001] Henning Schulzrinne SIP for emergency services. 2001. [Schulzrinne 2002] Henning Schulzrinne RFC 3261 - SIP: Session Initiation Protocol. IETF. 2002. [Schulzrinne 2002a] Henning Schulzrinne RFC 3428 - Session Initiation Protocol (SIP) Extension for Instant Messaging. IETF. 2002. [Schulzrinne 2002b] Henning Schulzrinne Draft IETF - Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP). IETF. 2002. [Schulzrinne 2003] Henning Schulzrinne. Mobiliby support using SIP. 2003. [Ubiquity 2001] Uniquity Software Corporation. Application-Layer Mobility Using SIP. Ubiquity. 2001. [Ubiquity 2002] Uniquity Software Corporation. SIP Enhanced Mobile Network Service. Ubiquity. 2002.