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

Descrio

INVITE

Inicializa chamadas ou parmetros da mesma

ACK

Confirma um pedido do tipo INVITE

BYE

Termina a chamada

CANCEL

Cancela o processo de busca e discagem

OPTIONS

Utilizado para reconhecimento das capacidades do cliente

REGISTER

Registra a localizao atual atravs do

INFO

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

Perfil

Descrio

1xx

Informativo

Pedido recebido, continuando a processar o pedido

2xx

Sucesso

Ao completada com sucesso

3xx

Redirecionamento

Necessidade de uma ao adicional para completar o

pedido

4xx

Erro do cliente

Pedido com sintaxe invlida ou no pode ser

executado neste servidor

5xx

Erro do servidor

Erro no servidor

6xx

Falha Global

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

Descrio

INVITE sip:ricardo@ietf.org SIP/2.0

Request line composta do tipo da mensagem, request

URI e SIP version

Via: SIP/2.0/UDP 192.168.0.25

Endereo do n anterior

From: Romildo. <sip: romildo@unifacs.br >

Cliente SIP solicitante

To: Ricardo. <sip: ricardo@ietf.org >

Cliente SIP convidado

Call-ID: 2325031978@romildo@unifacs.br

ID nico global para esta chamada

CSeq: 1 INVITE

Sequencia de comando

Subject: Resenha de Artigo.

Ttulo da mensgem

Content-Type: application/SDP

Tipo do body (neste caso SDP)

Content-Length:

Tamanho da mensagem
Linha em branco para indicar o fim do cabealho Sip e
o incio do body.

v=0

Verso do SDP

o=Romildo 4532 235655 IN IP4 192.168.0.25

Criador, identificador da sesso e endereo

s=Call from Romildo

c=IN IP4 192.168.0.25

Informao da conexo

m=audio 3217 RTP/AVP 0 3 4 5

Descrio da media

Tabela 3 Exemplo de uma mensagem de request SIP

Campos da resposta

Descrio

SIP / 2.0 200 OK

Status line SIP version, response code e reason

phrase

Via: SIP/2.0/UDP 192.168.0.25

Copiado do pedido

From: Romildo. <sip: romildo@unifacs.br >

Copiado do pedido

To: Ricardo. <sip: ricardo@ietf.org >, tag=8643 Copiado do pedido

Call-ID: 2325031978@romildo@unifacs.br

Copiado do pedido

CSeq: 1 INVITE

Copiado do pedido

Content-Type: application/SDP

Tipo do body (neste caso SDP)

Content-Length:

Tamanho da mensagem
Linha em branco para indicar o fim do cabealho Sip e
o incio do body.

v=0

Verso do SDP

o=Ricardo 3376 653897 IN IP4 192.168.0.17

Criador, identificador da sesso e endereo

s=Lunch
c=IN IP4 192.168.0.17

Informao da conexo

m=audio 50013 RTP/AVP 0 3

Descrio da media

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.