Um estudo do protocolo SIP e sua utilização em redes de telefonia

Um estudo do protocolo SIP e sua utilização em redes de
telefonia móvel
Romildo Martins da Silva Bezerra1
1
Mestrado em Redes de Computadores (UNIFACS)
[email protected]
Resumo. Este trabalho visa apresentar o protocolo SIP (Session Initiation
Protocol), explicando sua arquitetura e o processo de troca de mensagens.
Além disso mostra a utilização do SIP em redes de telefonia móvel exibindo o
funcionamento, problemas e sugestões para soluções desses.
1. Visão geral do protocolo SIP
O Protocolo de Inicialização de Sessão, SIP - Session Initiation Protocol, foi definido
na RFC 2543 em março 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 parâmetros e terminar sessões entre o(os)
usuário(os), onde nestas podem ser unicast (ponto a ponto) e multicast (conferência)
contendo qualquer tipo de tráfego multimídia. Para fazer o controle das sessões, o SIP é
capaz de iniciar e encerrar uma chamada, incluir ou excluir participantes de uma sessão
e ainda oferece transferência/manutenção de ligações e transição entre conexões ponto a
ponto e conferência.
O SIP é um protocolo de sinalização utilizado para estabelecer endereços IP que
os sistemas usarão para transferência dos dados. Como o SIP envolve apenas tráfego de
sinalização, não incluindo o tráfego de dados, a filosofia atrás do SIP é manter as
necessidades das aplicações e prover a interoperabilidade entre computadores no
processo de construção de novos serviços multimídia.
Utiliza a arquitetura cliente-servidor, onde a máquina que solicita o chamado atua
como cliente e a que recebe o chamado atua como servidor.
Como protocolo de sinalização, o SIP deve possuir :
•
Localização de usuários, envolve a determinação do sistema final a ser
utilizado na ligação.
•
Capacidades do usuário, envolve a determinação da mídia e de seus
parâmetros utilizados por um ou mais usuários.
•
Disponibilidade do usuário, serve para avaliar a disponibilidade do usuário a
participar de uma sessão.
•
Configuração de chamada, serve para estabelecimento da chamada em
ambos os lados da comunicação.
•
Manipulação de chamada, incluir transferência e término do chamado.
Dos atrativos para utilização do SIP destacam-se a possibilidade de mobilidade do
usuário, a flexibilidade e simplicidade do protocolo, que serão melhores descritos no
capítulo quatro.
2. A arquitetura SIP
Uma rede SIP é constituída de quatro entidades lógicas do SIP. Cada entidade tem uma
função específica e participa na comunicação SIP como um cliente (solicitando
pedidos), um servidor (respondendo os pedidos) ou ambos. Ou seja, um dispositivo
físico pode funcionalidades de uma ou mais entidades lógicas do SIP. Por exemplo, um
servidor de rede trabalha como servidor proxy, mas executa a função de Registrar ao
mesmo tempo. A seguir descreveremos as quatro entidades lógicas utilizadas na
arquitetura SIP: User Agent, Proxy Server, Redirect Server e Registrar.
No SIP um User Agent (UA) é uma entidade terminal, responsável por inicializar
e terminar a conexão através de trocas de pedidos e respostas. A RFC 3261 define o UA
como uma aplicação que contém o User Agent Client e o User Client Server, definidos
como:
•
User Agent Client (UAC) – uma aplicação cliente que inicializa o pedido
SIP.
•
User Agent Server (UAS) – uma aplicação de servidor que localiza o
usuário quando um pedido SIP é recebido, respondendo tal pedido de
acordo com o usuário.
Em outras palavras, se a aplicação inicia um pedido, age como um UAC durante a
duração daquela transação. Se ela recebe um pedido assume o papel de um UAS durante
o processo daquela transação.
Alguns dos dispositivos que podem ter uma função de UA em uma rede SIP são:
estações, telefones IP, serviços de resposta automática e agentes de chamada.
Um proxy server é uma entidade intermediária 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 necessário, reescreve a mensagem do pedido para só depois encaminhála.
Um pedido pode ser roteado por diversos proxy, sendo importante que o retorno
da mensagem siga o mesmo caminho do envio. Isso não é um problema quando o TCP é
utilizado, mas para uso com o UDP o protocolo SIP já possui um campo no cabeçalho
(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 localização atual do discador da chamada. É
recomendado para melhoria da escalabilidade de servidores de distribuição de
chamadas.
E por ultimo o Registrar, que tem como função aceitar os pedidos REGISTER e
em seguida atualizar um banco de dados de localização de usuários.
Agora que já é conhecida a definição das entidades SIP é possível descrever a
comunicação 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, serão descritos todos os passos1
de um pedido feito por [email protected] para [email protected].
1. Um User Agent (UA) SIP cria um pedido para [email protected] e o envia para
o proxy server.
2. O proxy local procura por ietf.org no servidor de domínio (DNS) e obtém o
endereço IP de destino do pedido SIP para este domínio e o seu proxy.
3. O servidor ietf.org conhece o usuário ricardo que está atualmente logado em
sbc.org.br. O servidor redireciona o proxy para este endereço.
1
Exceto o procedimento de autenticação no Registrar
4. O proxy local procura agora por sbc.org.br no DNS e obtém o endereço IP de
destino do pedido SIP para este domínio e o seu proxy.
5. O servidor SIP da sbc.org.br consulta uma base local (usando o registrar) e
localiza o usuário [email protected].
6. O servidor principal da SBC faz um pedido para o servidor proxy que o
usuário ricardo está localizado.
7. O servidor ao qual o usuário ricardo está localizado resolve seu endereço IP e
envia a mensagem para o usuário.
8. O usuário aceita a chamada e responde para o seu proxy, que irá reencaminhar
a mensagem até o destino.
3. O formato da mensagem
A codificação utilizada nas mensagens SIP utiliza a sintaxe HTTP/1.1, descrita RFC
2068, e o conjunto de caracteres é o ISSO 10646 com a codificação UTF-8, presente na
RFC 2279. As mensagens SIP podem ser apenas de dois tipos: pedidos e respostas. Para
simplificar, logo abaixo são apresentadas duas tabelas com a lista de opções de pedidos
e de respostas.
Método
Descrição
INVITE
Inicializa chamadas ou parâmetros 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 localização atual através do
INFO
Envia informações durante a sessão que não altera o seu estado
Tabela 1 – Pedidos do protocolo SIP
As mensagens de respostas do SIP contem códigos numéricos de respostas,
parcialmente baseados nos códigos do HTTP. Existem seis classes (vistas na Tabela 2)
diferentes, distribuídas em dois tipos de respostas:
•
Provisórias (classe 1xx) – respostas provisórias são utilizadas pelo
servidor para indicar o estado da sessão SIP, mas não a termina.
•
Finais (classe 2xx, 3xx, 4xx, 5xx e 6xx) – estes tipos de respostas
encerram as sessões SIP.
Todas as classes de respostas SIP estão especificadas a seguir.
Classe
Perfil
Descrição
1xx
Informativo
Pedido recebido, continuando a processar o pedido
2xx
Sucesso
Ação completada com sucesso
3xx
Redirecionamento
Necessidade de uma ação adicional para completar o
pedido
4xx
Erro do cliente
Pedido com sintaxe inválida ou não 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 são compostas de três campos, start line, headers e body. A
linha de início, ou start line, identifica o tipo da mensagem e a versão do protocolo.
Quando a mensagem é um pedido (request-line), a linha de início inclui uma Request
URI que indica o usuário ou o serviço ao qual este pedido está sendo encaminhado
(Diferentemente do campo To, onde o endereço pode ser escrito pelos servidores
proxy). E quando ela é uma resposta (status-line) guarda o código de status numérico 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 semântica é similar ao aos campos do
cabeçalho HTTP e todos seguem o formato <name>:<value>.
E por fim o campo Body é usado para descrever a sessão a ser iniciada. Os corpos
de mensagem podem aparecer no pedido e em mensagens de resposta. O protocolo SIP
faz uma distinção clara entre a informação de sinalização, carregada na linha de ínicio
do SIP e headers, e a sessão de descrição da informação, que fora ao escopo do SIP.
Este campo pode utilizar o SDP (Session Description Protocol), o MIME(Multipurpose
Internet Mail Extensions) ou outra futura implementação a ser definida pelo IETF.
Como ilustração coloremos duas mensagens SIP, um pedido e uma resposta, para
o fechamento de uma chamada de voz. O cliente SIP [email protected] está
convidando o usuário [email protected] para uma chamada e este aprova o pedido
realizado.
Campos do pedido
Descrição
INVITE sip:[email protected] SIP/2.0
Request line – composta do tipo da mensagem, request
URI e SIP version
Via: SIP/2.0/UDP 192.168.0.25
Endereço do nó anterior
From: Romildo. <sip: [email protected] >
Cliente SIP solicitante
To: Ricardo. <sip: [email protected] >
Cliente SIP convidado
Call-ID: 2325031978@[email protected]
ID único global para esta chamada
CSeq: 1 INVITE
Sequencia de comando
Subject: Resenha de Artigo.
Título 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 cabeçalho Sip e
o início do body.
v=0
Versão do SDP
o=Romildo 4532 235655 IN IP4 192.168.0.25
Criador, identificador da sessão e endereço
s=Call from Romildo
c=IN IP4 192.168.0.25
Informação da conexão
m=audio 3217 RTP/AVP 0 3 4 5
Descrição da media
Tabela 3 – Exemplo de uma mensagem de request SIP
Campos da resposta
Descrição
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: [email protected] >
Copiado do pedido
To: Ricardo. <sip: [email protected] >, tag=8643 Copiado do pedido
Call-ID: 2325031978@[email protected]
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 cabeçalho Sip e
o início do body.
v=0
Versão do SDP
o=Ricardo 3376 653897 IN IP4 192.168.0.17
Criador, identificador da sessão e endereço
s=Lunch
c=IN IP4 192.168.0.17
Informação da conexão
m=audio 50013 RTP/AVP 0 3
Descrição da media
Tabela 4 – Exemplo de uma mensagem de resposta SIP
4. Por que o SIP?
Nesta seção serão descritos alguns fatores que fazem o SIP ocupar mais espaço no
mercado, concorrendo com o H.323 e MEGACO, colocando SIP como protocolo
promissor, possuindo o maior crescimento no seu segmento.
Entretanto não é esperado um domínio completo do SIP devido a grande
plataforma instalada com protocolos antecessores a ele, o H.323 por exemplo, e à
evolução 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 execução de uma transação seja equivalente a quatro ou cinco
transações do H.323 versão 1 e à flexibilidade de usar UDP.
A possibilidade de utilização de multicast tanto em fluxo multimídia (como o
H.323) como também em mensagens de sinalização. O uso de multicast está
diretamente associado a localização de usuários numa empresa e a utilização em call
centers. Durante a utilização de multicast na sinalização, os pedidos SIP são
transportados usando-se UDP, pois só o UDP é capaz de transportar multicast sobre IP.
Priorização de tráfego de algumas linhas telefônicas com o uso do campo Priority
permite atender as necessidades legais de alguns países, bem como a necessidade dos
administradores de rede para indicar que usuário terá a preferência no uso dos recursos
da rede.
A princípio a utilização de URLs como identificadores não parece ser um item
poderoso. Entretanto um servidor SIP pode redirecionar chamadas SIP para servidores
não SIP com grande flexibilidade.
Outro ponto em favor do SIP relacionado a flexibilidade e escalabilidade, pelo
fato ser baseado em serviços de conferência distribuída 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 número de produtos no mercado que utilizam
SIP é bastante superior ao seu maior concorrente o H.323, confome pode ser visto na
figura 2. Além disso, os provedores de serviço em Telefonia IP estão mais preparados
para o SIP. Em relação a plataforma de pordutos e serviços instalados, o H.323 leva
uma imensa vantagem.
Figura 2 – Porcentagem de produtos no mercado por protocolo
Figura 3 – Porcentagem de prestadoras de serviço no mercado por protocolo
A interoperabilidade com o mundo Internet, a flexibilidade e a mobilidade abrem
possibilidade de uma infinidade de novos serviços 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 difusão do
protocolo SIP, pois a possibilidade de localização de um usuário 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 é necessária uma habilidade da infra-estrutra e
dos algoritmos utilizados para prover o deslocamento do usuário, sem causar impacto na
sua chamada ativa. Para isso é assumido que o dispositivo móvel pertença a uma rede
local na qual um SIP Server seja responsável em receber as mensagens informando a
localização do dispositivo. O grande problema é como manter atualizada tal localização
de forma freqüente e rápida para que uma mudança de estação de rádio não ocasione
uma perda da localização.
Na utilização do SIP com dispositivos móveis, quando um servidor SIP envia um
pedido para um dispositivo móvel, o redirect server tem a informação da localização do
dispositivo móvel redireciona o pedido, conforme é visto na figura a seguir.
Figura 4 – SIP na comunicação de dispositivos móveis
Se durante a sessão o dispositivo móvel se desloca, um novo pedido tem que ser
enviado ao dispositivo um novo pedido utilizando o mesmo identificador de chamada
usado na conexão original. Um novo IP deve ser colocado nas mensagens SIP que
corresponderá o servidor onde as futuras mensagens SIP serão enviadas. Para
redirecionamento do fluxo de tráfego com o deslocamento do dispositivo móvel, o
endereço IP deve ser alterado no memento em que o dispositivo mudar de estação
móvel (poderia ser dito também mudança de célula).
Figura 5 – Atualização constante de informações
Para o funcionamento desta arquitetura móvel com o protocolo SIP, se faz
necessário o constante registro da localização do dispositivo no SIP server local, para
que todos os redirecionamentos sejam feitos com exatidão. ë recomendado que neste
processo seja utilizado autenticação e criptografia nas mensagens SIP, utilizando o
conceito de chaves públicas/privadas.
Figura 6 – Atualização no SIP Redirect Server
Caso o dispositivo móvel esta utilizando Móbile IP, não é estritamente necessário
(embora útil) que o servidor SIP tenha a localização atual do dispositivo móvel. Além
de ser um desperdício de recursos manter a localização do usuário em dois servidores,
isto pode acarretar problemas de inconsistência e/ou gerenciamento do serviço.
Algumas soluções para correção de tal problema podem ser vistas em [Schulzrinne
2003].
Se um cliente SIP tem por algum motivo a localização antiga (e errada) do
dispositivo móvel é necessário um mecanismo para correção deste erro. Certamente este
erro será comum quando o UAC e o UAS sejam dispositivos móveis. Para isso é preciso
que durante o processo e diálogo entre os clientes, o SIP server local seja infromado de
todas as mudanças. A única exigência feita para este mecanismo é que o SIP server com
a base de localização dos usuários não seja também um idspositivo móvel ou o seu
endereço não seja alterado durante o processo.
Numa arquitetura para utilização de mobilidade com o protocolo SIP não
podemos utilizar o protocolo TCP, ficando restrito apenas ao uso do UDP. Numa
eventual utilização com o IP Móvel, os dois protocolos seriam utilizados para que
suporte a aplicações como FTP, TELNET e HTTP sejam utilizadas sem problemas.
Uma solução para tal problema seria a possibilidade de escolha por parte do dispositivo
móvel de quando utilizar cada protocolo, associando-o a qual endereço SIP (se o móvel
ou o fixo) será utilizado. Obviamente, tal escolha pode ficar totalmente transparente pra
o usuário se tal escolha estiver associada ao tipo de aplicação utilizada. Outra solução
seria uma readaptação dos protocolos de rede para o novo mundo da telefonia móvel.
Fatores relativos a implementação ainda não foram padronizados e não acredito
que tal padronização esteja perto de ocorrer, pois envolve uma gama de áreas distintas
(provedores de serviços, universidades, fabricantes de dispositivos moveis e de
equipamentos de telecomunicações, desenvolvedores de sistemas operacionais e
aplicações móveis, dentre outros).
Alguns problemas inerentes a esta solução como atraso fim-a-fim, delay do
handoff dos disposivos e a dependência da tecnologia wireless disponível pela
operadora de serviços móveis estão sendo estudados e tem uma vasta área de pesquisa a
ser percorrida.
6. Considerações finais
Existe uma enorme diversidade de serviços oferecidos com o SIP como disponibilização
de serviços de call centers virtuais [Kaish 2003], aplicações para serviços de mensagens
instantâneas [Schulzrinne 2002a] e serviços de localização de veículos. Entretanto foi
escolhido o serviço de telefonia móvel por atingir uma margem bem maior de usuários.
As capacidades que o SIP oferece são essenciais para a rede de telefonia móvel,
colocando-o numa posição confortável em relação aos seus correntes. O crescimento do
uso do protocolo SIP para estas aplicações deverá estar associado com a integração
crescente dos dispositivos móveis, a redução de custos e uma melhoria na largura de
banda do serviço (pelo menos aqui no Brasil) para que um leque maior de aplicativos
possam ser executados nos dispositivos.
Alguns detalhes do SIP terão ainda que evoluir como a segurança [Cisco 2002],
implementação de QoS e mecanismos de controle de prioridade [Schulzrinne 2002b].
Especificamente no serviço de telefonia móvel é preocupante o atraso fim-a-fim e delay
no handoff estão sendo ainda estudados.
7. Bibliografia
[Cisco 2002] Cisco Systems. Security in SIP-Based Networks.2002.
[Hersent 2002] Oliver Hersent. Telefonia IP – Comunicação 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.