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

Transcrição

1 Um estudo do protocolo SIP e sua utilização em redes de telefonia móvel Romildo Martins da Silva Bezerra 1 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. 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.

2 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

3 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 passos 1 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 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 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 ricardo@sbc.org.br. 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 com a codificação UTF-8, presente na RFC 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 INVITE ACK BYE CANCEL OPTIONS REGISTER INFO Descrição Inicializa chamadas ou parâmetros 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 localização atual através do 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.

5 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 romildo@unifacs.br está convidando o usuário ricardo@ietf.org para uma chamada e este aprova o pedido realizado. Campos do pedido Descrição INVITE sip:ricardo@ietf.org SIP/2.0 Via: SIP/2.0/UDP From: Romildo. <sip: romildo@unifacs.br > Request line composta do tipo da mensagem, request URI e SIP version Endereço do nó anterior Cliente SIP solicitante

6 To: Ricardo. <sip: > Call-ID: 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 Título da mensgem Tipo do body (neste caso SDP) Tamanho da mensagem v=0 Versão do SDP o=romildo IN IP s=call from Romildo c=in IP m=audio 3217 RTP/AVP Linha em branco para indicar o fim do cabeçalho Sip e o início do body. Criador, identificador da sessão e endereço Informação da conexão Descrição da media Tabela 3 Exemplo de uma mensagem de request SIP Campos da resposta Descrição SIP / OK Via: SIP/2.0/UDP From: Romildo. <sip: romildo@unifacs.br > 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: @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 v=0 Versão do SDP o=ricardo IN IP s=lunch c=in IP m=audio RTP/AVP 0 3 Linha em branco para indicar o fim do cabeçalho Sip e o início do body. Criador, identificador da sessão e endereço Informação da conexão Descrição da media Tabela 4 Exemplo de uma mensagem de resposta SIP

7 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

8 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

9 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].

10 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.

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