ANÁLISE DAS VULNERABILIDADES E ATAQUES AO PROTOCOLO SIP

Transcrição

1 UNIÃO EDUCACIONAL MINAS GERAIS S/C LTDA FACULDADE DE CIÊNCIAS APLICADAS DE MINAS Autorizada pela Portaria no 577/2000 MEC, de 03/05/2000 BACHARELADO EM SISTEMAS DE INFORMAÇÃO ANÁLISE DAS VULNERABILIDADES E ATAQUES AO PROTOCOLO SIP ANDERSON RODRIGUES SOUZA REZENDE UBERLÂNDIA - MG 2006

2 ANDERSON RODRIGUES SOUZA REZENDE ANÁLISE DAS VULNERABILIDADES E ATAQUES AO PROTOCOLO SIP Trabalho de Final de curso submetido à UNIMINAS como parte dos requisitos para a obtenção do grau de Bacharel em Sistemas de Informação. Orientador: Prof. Esp Flamaryon Guerin Gomes Borges UBERLÂNDIA - MG 2006

3 ANDERSON RODRIGUES SOUZA REZENDE ANÁLISE DAS VULNERABILIDADES E ATAQUES AO PROTOCOLO SIP Trabalho de Final de curso submetido à UNIMINAS como parte dos requisitos para a obtenção do grau de Bacharel em Sistemas de Informação. Orientador: Prof. Esp Flamaryon Guerin Gomes Borges Banca Examinadora: sobre Uberlândia, 16 de setembro de Prof. Esp Flamaryon Guerin Gomes Borges (Orientador) Prof. Esp. Carlos Henrique Barros Prof. Dr. Mauro Hemerly Gazzani UBERLÂNDIA - MG 2006

4 Pela emoção de me vêem crescer, por acreditarem em mim, pelo grande amor que me destinam, por sempre ensinarem aos seus filhos a verdadeira importância da honestidade e da ética. É para meus pais, Paulo e Maria, que dedico este trabalho, àqueles de especial significado pra mim, aos quais devo toda formação que tenho e todo futuro que me fora entregue.

5 AGRADECIMENTOS Ao professor e orientador Flamaryon Guerin Gomes Borges, que com seu apoio e conhecimento, tornou possível a elaboração deste trabalho. Muito obrigado por confiar à mim este tema. À professora Kátia Lopes Silva, por sua dedicação constante, buscando sempre extrair todo nosso potencial. Com sua inteligência e carisma inigualáveis, esteve sempre ao lado do aluno, ajudando em nossas dificuldades, e partilhando das nossas superações. Aos grandes amigos, Arnaldo e Fernando, companheiros de estrada, pessoas que aprendi a respeitar e confiar. Àqueles que considero como irmãos, sempre presentes em minha vida acadêmica, tanto nos momentos felizes, quanto nas dificuldades. E juntos conquistamos mais uma etapa importante em nossas vidas. Agradeço a vocês pela grande amizade, amizade esta, que prezo para que seja por minha parte, retribuída à altura. A namorada Lívia, uma pessoa muito importante e especial em minha vida. Uma mulher que é maravilhosa acima de tudo. Que pode com um sorriso provocar amor e felicidade. Uma pessoa que me encantou, e me encanta em todos os seus gestos, e que compartilha comigo grandes realizações. Meu grande amor. À Instituição UNIMINAS, e seus docentes, por sua excelente estrutura, onde fora possível a conquista desta vitória.

6 RESUMO No cenário atual, não há como ficar indiferente ao assunto de VoIP. Discussões em torno do tráfego de voz sobre o protocolo da Internet não dão sinais de cessar, por isso companhias apostam nesta tendência, que segundo pesquisas, promete confirmar-se numa grande explosão de consumo. Nesta evolução das comunicações, destaca-se o protocolo SIP (Session Initiation Protocol), um protocolo capaz de iniciar, alterar e finalizar sessões multimídia, garantindo a convergência em definitivo, da telefonia tradicional para telefonia IP. Porém apesar das grandes vantagens trazidas pela convergência, esta trouxe também uma nova preocupação: a segurança das informações, requisito que pode confirmar a maturidade da tecnologia. Implementações do protocolo SIP, são vulneráveis a ataques comuns baseados em redes IP, bem como a ataques que são únicos ao SIP. Este fato coloca em risco as Informações das empresas que utilizam sistemas de telefonia IP. Ataques que fazem uso das vulnerabilidades do protocolo SIP, podem resultar na interrupção de aplicações fundamentais ao negócio de corporações sustentadas em uma rede VoIP. Tal fato, dentro do contexto de concorrência global, tornará uma grande economia em sérios prejuízos. A proposta da pesquisa é demonstrar as vulnerabilidades e os possíveis ataques que fazem uso das brechas em implementações do Session Initiation Protocol, criando um documento com tais informações destinado a interessados e envolvidos com sistemas de comunicação baseados no protocolo SIP. Palavras-chave: SIP, vulnerabilidades, ataques, VoIP.

7 ABSTRACT In the current scene, it does not have as to be indifferent to the subject of VoIP. Quarrels around the traffic of voice on the protocol of the Internet do not give signals to cease, therefore company bets in this trend, that according to research, promises to confirm in a great consumption explosion. In this evolution of the communications, protocol SIP (Session Initiation Protocol) is distinguished, a protocol capable to initiate, to modify and to finish sessions multimedia, promising the convergence in definitive, of the traditional telephony for telephony IP. However although the great advantages brought for the convergence, this also brought a new concern: the security of the information, requirement that can confirm the maturity of the technology. Implementations of protocol SIP, are vulnerable the based common attacks in nets IP, as well as the attacks that are only to the SIP. This fact at risk places the Information of the companies who use systems of telephony IP. Attacks that make use of the vulnerabilities of protocol SIP, can result in the interruption of basic applications to the business of corporations supported in a VoIP net. Such fact, inside of the context of global competition, will become a great economy in serious damages. The proposal of the research is to demonstrate to the vulnerabilities and the possible attacks that make use of the breaches in implementations of the Session Initiation Protocol, creating a document with such information destined the involved interested parties and with based systems of communication in protocol SIP. Key-words: SIP, vulnerabilities, attacks, VoIP.

8 LISTA DE FIGURAS FIGURA 1 - ARQUITETURA CLIENTE/SERVIDOR FIGURA 2 - ARQUITETURA DE PROTOCOLOS MULTIMÍDIA INTERNET FIGURA 3 - ARQUITETURA SIP FIGURA 4 - EXEMPLOS DE UA S FIGURA 5 - FUNCIONAMENTO DO REDIRECT SERVER FIGURA 6 - REGISTRO DA LOCALIZAÇÃO EM UM REGISTRAR SERVER FIGURA 7 - GATEWAY SIP/PSTN E GATEWAY SIP/H FIGURA 8 - ESTABELECIMENTO DE UMA SESSÃO SIP SIMPLES FIGURA 9 - CAMPOS DA MENSAGEM INVITE FIGURA 10 - CÁLCULO DO CAMPO CONTENT-LENGTH FIGURA 11 - DESCRIÇÃO DOS CAMPOS SDP FIGURA 12 - MÉTODOS DE REQUISIÇÕES SIP FIGURA 13 - MÉTODOS DE REQUISIÇÕES ESTENDIDAS DO SIP FIGURA 14 - CLASSES DE RESPOSTA SIP FIGURA 15 - ESTRUTURA DA MENSAGEM 180 RINGING FIGURA 16 - ESTRUTURA DA MENSAGEM 200 OK FIGURA 17 - ESTRUTURA DO ACK FIGURA 18 - ESTRUTURA DO BYE FIGURA OK CONFIRMAÇÃO DO BYE FIGURA 20 - CHAMADA SIP COM PROXY SERVER FIGURA 21 - INVITE REPASSADO AO PROXY FIGURA 22 - INVITE REPASSADO PELO PROXY AO DESTINO FIGURA 23 - MENSAGEM 180 RINGING ENVIADA AO PROXY FIGURA 24 - MENSAGEM DE RESPOSTA ENVIADA DO PROXY AO ORIGINADOR FIGURA 25 - CONFIRMAÇÃO 200 OK REPASSADA DO PROXY AO ORIGINADOR FIGURA 26 - REGISTER ENVIADO DIRETAMENTE PARA O SERVIDOR DE REGISTRO FIGURA 27 - REGISTRO DE UM AGENTE EM UM SERVIDOR DE REGISTRO VIA PROXY... 43

9 FIGURA 28 - MENSAGEM INVITE ENVIADA PARA O REDIRECT SERVER FIGURA 29 - REPOSTA ENVIADA PELO REDIRECT SERVER FIGURA 30 - REDIRECIONAMENTO VIA SERVIDOR PROXY FIGURA 31 - SIP X FIGURA 32 - SINALIZAÇÕES SIP X H FIGURA 33 - DIFERENÇAS NO STREAMMING SIP X H FIGURA 34 - SIP INVITE PASSÍVEL DE SNIFFING E SPOOFFING FIGURA 35 - MENSAGEM DE REGISTRO VÁLIDA FIGURA 36 - VERSÃO MODIFICADA DO REGISTRO FIGURA 37 - SPOOFING DO REGISTRO UTILIZANDO O SIVUS FIGURA 38 - ATAQUE DE REGISTRATION HIJACKING FIGURA 39 - ATAQUE DE PROXY IMPERSONATION FIGURA 40 - PASSOS PARA CAPTURAR A MÍDIA VOIP COM O ETHEREAL FIGURA 41 - ATAQUE DE ARP SPOOFING FIGURA 42 - A FERRAMENTA CAIN REALIZANDO O ATAQUE DE HOMEM-DO-MEIO FIGURA 43 - ATAQUE DE MESSAGE TAMPERING FIGURA 44 - ATAQUE DE SESSION TEAR DOWN FIGURA 45 - REMOÇÃO DO REGISTRO DO USUÁRIO PELO ATACANTE FIGURA 46 - FLUXO DO ATAQUE DE RE-INVITE FIGURA 47 - ATAQUE DE BYE FIGURA 48 - FLUXO DO ATAQUE DE UPDADE FIGURA 49 - MENSAGEM SIP INVITE BEM FORMADA FIGURA 50 - MENSAGEM SIP INVITE MAL FORMADA FIGURA 51 - DESCOBRINDO AS CAPACIDADES COM A REQUISIÇÃO OPTIONS FIGURA 52 - FLUXO NORMAL DE REGISTRO FIGURA 53 - ATAQUE CONTRA UM REGISTRAR SERVER FIGURA 54 - ATAQUE DE CANCEL FIGURA 55 - CÓDIGOS DE ERROS COMUNS FIGURA 56 - FLOODING DE INVITE FIGURA 57 - PRINCIPAIS MECANISMOS DE SEGURANÇA PARA O SIP... 84

10 FIGURA 58 - CONFIRMAÇÃO DO INVITE PELO PROXY FIGURA 59 - INVITE ORIGINAL COM A CONFIRMAÇÃO FIGURA 60 - TIPOS DE CONTEÚDO S/MIME FIGURA 61 - NEGOCIAÇÃO COM SERVIDOR TLS FIGURA 62 - SOLUÇÃO PARA SEGURANÇA REAL-TIME MEDIA STREAMS... 90

11 LISTA DE ABREVIATURAS E SÍMBOLOS ACK AES AH AOR ARP ASCII CCP CR DDoS DES DHCP DNS DoS ESP FTP HTML HTTP IETF IKE IP IPSEC - Acknowledgment - Advanced Encryption Standard - Authentication Header - address of record - Address Resolution Protocol - American Standard Code for Information Interchange - Connection Control Protocol - Carrier Return - Distributed Denial of Service - Data Encryption Standard - Dynamic Host Configuration Protocol - Domain Name Service - Denial of Service - Encapsulating Security Payload - File Transfer Protocol - Hyper Text Transfer Protocol - Hyper Text Transfer Protocol - Internet Engineering Task Force - Hyper Text Markup Language - Internet Protocol - Internet Protocol Security

12 IVS LF MD5 MIME MITL MMCC NGN OSI PC PCM PDA PGP PKI PSK PSTN QoS RAS RFC RTCP RTP - INRIA Videoconferencing System - Line Feed - Message Digest Algoritm - Multi-purpose Internet Mail Extension - man-in-the-middle - Multimídia Conference Control - Next Generations Network - Open System Interconnection - Pesonal Computer - Pulse-code modulation - Personal Digital Assistant - Pretty Good Privacy - Public key infraestructure - Pre-shared keys - Public Switched Telephone Network - Quality of Service - Registration Admission Status - Request For Comments - Real-Time Control Protocol - Real Time Protocol S/MIME - Security/Multi-purpose Internet Mail Extension SCIP SDP SHA - Simple Conference Invitation Protocol - Session Description Protocol - Secure Hash Algorithm

13 SIP SMTP SPIT SRTP SYN TCP - Session Initiation Protocol - Send Mail Transfer Protocol - Spam over Internet Telephony - Secure Real Time Protocol - Synchronous - Transmission Control Protocol TCP/IP - Transmission Control Protocol/Internet Protocol TLS UA UAC UAS UDP URL VoIP - Transport Layer Security - User Agent - User Agent Client - User Agent Server - User Datagram Protocol - Uniform Resource Locators - Voice over Internet Protocol

14 SUMÁRIO 1 INTRODUÇÃO CENÁRIO ATUAL OBJETIVOS IDENTIFICAÇÃO DO PROBLEMA JUSTIFICATIVA ORGANIZAÇÃO DO TRABALHO FUNDAMENTOS DO PROTOCOLO SIP SURGIMENTO DO SIP INTRODUÇÃO COMPONENTES DO SIP SINALIZAÇÃO SIP SINALIZAÇÃO SIP COM SERVIDOR PROXY REGISTRO SIP REDIRECIONAMENTO SIP X H Diferenças na Sinalização Diferenças no Streaming VULNERABILIDADES DOS SISTEMAS VOIP BASEADOS EM SIP INTRODUÇÃO AMEAÇAS E ATAQUES AO SIP Registration Hijacking Proxy Impersonation Eavesdropping (Espionando) Message Tampering Session Tear Down Denial of Service ATAQUES UTILIZANDO DE MENSAGENS SIP Ataques a sistemas sem a autenticação aplicada Ataque de DoS utilizando mensagens de REGISTER SIP Ataque de Re-INVITE Ataque de BYE Ataque de UPDATE Ataques a sistemas com a autenticação aplicada (antes da autenticação) Ataques de Parser Ataques de REGISTER Ataques de CANCEL Fraudes em Respostas SIP Ataques a sistemas com a autenticação aplicada (após a autenticação) Ataque de Força Bruta Unusable Destinations (Destinos Inúteis) Ataques de INVITE MECANISMOS DE SEGURANÇA...83

15 4.1 HTTP BASIC AUTHENTICATION HTTP DIGEST AUTHENTICATION PRETTY GOOD PRIVACY (PGP) SECURE MIME (S/MIME) SIPS URI (TLS) IP SECURITY (IPSEC) SEGURANÇA SOBRE PROTOCOLOS DE TRANSPORTE EM TEMPO REAL Secure RTP (SRTP) IP Security (IPsec) CONCLUSÕES CONSIDERAÇÕES FINAIS PROPOSTAS PARA TRABALHOS FUTUROS REFRÊNCIAS BIBLIOGRÁFICAS...94

16 15 1 INTRODUÇÃO 1.1 Cenário Atual O envio de sinais de voz em pacotes digitais, conhecido como VoIP (Voice over IP Voz sobre Protocolo de Internet), manifesta diversas vantagens em relação as redes telefônicas tradicionais. Muitas dessas vantagens deve-se ao fato de consolidar a transmissão de voz e dados sobre uma mesma infra-estrutura, e de distribuir a inteligência do sistema entre diversos elementos, deixando de concentrála apenas nas centrais telefônicas. Como resultado, tem-se não só a redução drástica dos custos como também a possibilidade de criação de sistemas globais de comunicação. Com o amadurecimento da Internet e de seus protocolos de comunicação, a convergência de múltiplas mídias como voz, vídeo, dados e serviços como chat, Instant Messages, e Web, deixou de ser apenas uma curiosidade, para tornar-se uma grande oportunidade. Neste contexto é que surge a telefonia IP (Internet Protocol). Telefonia IP é uma modalidade de VoIP onde o serviço fornecido apresenta qualidade e funcionalidades no mínimo equivalentes aos serviços telefônicos convencionais. O usuário utiliza um telefone IP que é um telefone mais inteligente, ou um adaptador IP para um telefone convencional e uma conexão IP de banda larga para conectar-se a rede de telefonia IP. Adicionalmente pode-se acessar o serviço utilizando um computador com um programa especial para esse fim. Nesta evolução das comunicações, destaca-se o SIP (Session Initiation Protocol Protocolo de iniciação de sessão), um protocolo desenvolvido pelo IETF (Internet Engineering Task Force), que atua no nível de aplicação, capaz de estabelecer, gerenciar e terminar chamadas entre dois ou mais pontos de comunicação. O SIP é caracterizado por sua estrutura simples, fazendo uso dos serviços de outros protocolos para implementar sua arquitetura multimídia e desse modo deve ser o protocolo padrão nas comunicações mundiais. o SIP visa trazer algo semelhante ao que o IP trouxe para Internet no mundo, prometendo a convergência em definitivo, da telefonia tradicional para telefonia IP. Segundo Lazarini (2006), a Telefonia IP associada a outras aplicações como colaboração, presença, , voice mail, fax, e outras limitadas somente pela nossa capacidade

17 16 de criação, serão a base da comunicação do futuro e mudará a maneira como fazemos negócios. Existem, porém, aspectos importantes a serem revistos nas implementações SIP, a mais crítica refere-se a segurança. De acordo com Collier (2005), o sistema SIP é vulnerável aos ataques comuns baseados em redes IP, bem como a ataques que são únicos ao SIP. A disponibilidade do serviço de VoIP está ligada diretamente a disponibilidade da infra-estrutura IP, qualquer tipo de ataque, pode acarretar um sério impacto nas comunicações. Por ser um protocolo baseado nos protocolos da pilha TCP/IP (Transmission Control Protocol/ Internet Protocol), o SIP herdou destes suas tão exploradas vulnerabilidades. Hoje em dia o requisito mais importante para a VoIP é a segurança, e isso pode construir-se com componentes fiáveis e bom planeamento durante a colocação. As telecomunicações sempre tiveram requisitos altos de fiabilidade, mas devido ás redes de telecomunicações terem estado sempre fechadas, a segurança nunca foi um requisito. As coisas são diferentes para o VoIP. A prevenção da fraude é um dos tópicos principais quando se coloca a VoIP. A conectividade aberta é também frequentemente exigida, e isso cria um recreio para os hackers, expondo a rede de telecomunicações a ataques como vermes e vírus. A colocação inteligente requer um conhecimento das ameaças, vulnerabilidades e ataques. O desenvolvimento de produtos e sistemas de VoIP seguros é possível com testes à robustez, concentrando-se na eliminação das vulnerabilidades em cada parte do conjunto. Conhecendo os requisitos, e minimizando os riscos, permite-lhe construir um sistema de VoIP seguro, fiável e robusto. (TAKANEN,2006, tradução nossa). VoIP é um assunto de grande importância na evolução dos serviços de telecomunicações; é necessário rever algumas questões fundamentais como a segurança das comunicações e a harmonização sobre a regulamentação aplicada; o Session Initiation Protocol é a base para o seu desenvolvimento e disseminação no mercado. Sendo assim, a segurança em sistemas baseados no protocolo SIP, torna-se um ponto importante a ser pesquisado, já que o mesmo promete ser o protocolo universal que integrará a rede de voz e dados definitivamente. [...]Ao fazer ligações telefônicas pela internet, as empresas estão economizando milhões. Mas estão expondo seus sistemas de voz a todas as pragas que hoje atacam as redes de dados, como worms, vírus, spam sobre telefonia internet (SPIT), ataques DoS e fraudes. Além disso, abrem mais portas para que outras áreas da rede também sejam atacadas, afetando a infra-estrutura das empresas e

18 17 seus sistemas.[...] (CIO REVISTA, 2004). [...] Na sua forma básica, o SIP trafega em texto puro, significando que ele é vulnerável aos softwares espiões. Segundo os especialistas é fácil interceptar as chamadas VoIP não criptografadas usando um ipod.[...](cio REVISTA, 2004). 1.2 Objetivos Este trabalho tem por objetivo demonstrar o funcionamento do protocolo SIP, expondo suas vulnerabilidades e evidenciando ataques à sua arquitetura, bem como alguns métodos de defesa à tais ofensivas maliciosas. Com isto, pretende-se fornecer subsídios de informações referentes à segurança no uso de sistemas de comunicação baseados no protocolo SIP, oferecendo condições aos ingressantes, de evoluir nesta área. Não é foco deste trabalho, aprofundar em métodos de defesa, nem em outros protocolos de sinalização, tais como o H323. Deve-se notar que o mesmo não trata de QoS Quality of Service (Qualidade de Serviço) VoIP. 1.3 Identificação do problema Devido ao grande interesse na redução de gastos, convergência e na criação de novos serviços de comunicação, a padronização de um protocolo capaz de gerir uma sessão multimídia torna-se inevitável. O fato de ser um protocolo de arquitetura simples e aberta faz do SIP um protocolo com grandes possibilidades de se tornar o padrão das comunicações sobre as redes IP. [...] Desenvolvedores de produtos VoIP, grandes e pequenos, estão adotando o SIP. A Microsoft introduziu o protocolo SIP em seu sistema operacional Windows XP, e baseou seu programa de mensagens instantâneas neste protocolo. A IBM reconheceu o SIP como o futuro para todos os produtos de comunicação que utilizam voz e vídeo[...]. (CHECK POINT SOFTWARE TECNOLOGIES LTD, CA, 2004, p. 4, tradução nossa).

19 18 Contudo Implementações do SIP, sem as devidas preocupações com a segurança podem acarretar em sérios prejuízos ao negócio. Documentar e tornar pública as vulnerabilidades do SIP facilita a correção de problemas, servindo como apoio tanto profissionais experientes em segurança da informação, quanto interessados em ingressar na nova tendência da comunicação multimídia sobre redes IP. 1.4 Justificativa A justificativa para elaboração de um documento de referência sobre as vulnerabilidades do protocolo SIP, explica-se pelo fato de ser um assunto pouco divulgado. Sabe-se da grande capacidade do SIP nas comunicações globais, porém suas falhas ainda são pouco conhecidas. O trabalho torna-se interessante à medida que detalha os ataques que exploram as vulnerabilidades deste protocolo, demonstrando como tais falhas podem abrir portas permitindo que pessoas mal intencionadas estejam aptas a explorá-las, e como conseqüência, gerar prejuízos ao sistema de comunicação. 1.5 Organização do trabalho No Capítulo 2, será apresentado o protocolo SIP, enfatizando além da sua arquitetura, componentes e estrutura, o seu funcionamento. Este capítulo ainda apresenta uma breve comparação do SIP com o H323, outro protocolo de sinalização, que está sendo substituído pelo Session Initiation Protocol. O Capítulo 3 trata das vulnerabilidades do sistema de comunicação que fazem uso do SIP, enfatizando os ataques e suas conseqüências. No Capítulo 4, serão analisadas algumas medidas de proteção, contudo, sem aprofundar nestas soluções, apenas expondo alguns procedimentos mais utilizados. E finalmente, o Capitulo 5, relatando tanto as conclusões obtidas pela pesquisa, quanto as dificuldades e limitações no estudo do tema.

20 19 2 FUNDAMENTOS DO PROTOCOLO SIP 2.1 Surgimento do SIP Segundo, Camarillo (2001), embora a primeira transmissão de voz sobre redes comutadoras de pacotes datam por volta de 1974, O primeiro sistema de conferência multimídia surgiu no inicio de 1990 desenvolvido por Terry Turletti. Nomeado de INRIA Videoconferencing System (IVS). Tratava-se de um sistema de transmissão de áudio e vídeo sobre a Internet. Mais tarde, Eve Schooler desenvolveu o Multimídia Conference Control (MMCC), um software capaz de prover teleconferências ponto-a-ponto e multiponto, com áudio e vídeo. Para conectar vários usuários, o MMCC fazia uso do Connection Control Protocol (CCP), um protocolo de controle orientado a transação. Uma transação consiste em um podido de um usuário, e a resposta de outro usuário remoto. Para o transporte dos pacotes o CCP utilizava o protocolo User Datagram Protocol (UDP), implementando o time-out, e a retransmissão para garantia da entrega dos pacotes. Estes dois primeiros sistemas de conferência multimídia abriram caminho para o desenvolvimento do Session Initiation Protocol (SIP). A primeira versão do SIP, o SIPv1, criada por Mark Handley e Eve Schooler, foi avaliada pelo IETF, como um modelo para Internet em vinte e dois de fevereiro de O SIPv1 era um protocolo baseado em texto, e fazia uso do Session Description Protocol (SDP) para descrever as sessões multimídia, e do UDP, para o transporte dos pacotes. O SIPv1 apresentou o conceito de registro de endereço em servidores de conferência multimídia, promovendo certo nível de mobilidade ao usuário, pois uma vez que este registre sua localização, um servidor de endereços é capaz de endereçar convites ao próprio usuário. Sendo assim, se um usuário estivesse distante de sua estação de trabalho, poderia escolher registrar-se em uma estação de trabalho temporária e continuar recebendo convites multimídia. Neste primeiro momento, o SIPv1 controlava apenas o estabelecimento e a finalização da sessão. Também em vinte e dois de fevereiro de 1996, Henning Schulzrinne, submeteu ao IETF um modelo de protocolo para Internet, capaz de convidar usuários para conferências ponto-a-ponto ou multicast chamado de Simple Conference Invitation Protocol

21 20 (SCIP). Este protocolo era baseado no HTTP, e utilizava o Transmission Control Protocol (TCP) para transporte dos pacotes. O SCIP fazia uso de endereços de e- mail para identificar os usuários, e era capaz de alterar parâmetros da sessão após seu estabelecimento. Então no 35th IETF meeting, foram apresentados os protocolos SIP e o SCIP. E durante este encontro, e se estendendo ao seguinte o 36th IETF meeting, Schooler e Schulzrinne decidiram então unir as funcionalidades dos dois protocolos, mantendo o nome SIP criando então o SIPv2. Em dezembro de 1996, surgiu o novo SIP, baseado em HTTP, é fazendo uso tanto do TCP, quanto do UDP para transporte dos pacotes. A partir deste momento o SIP, adquiriu sua verdadeira importância pelo IETF, que despende esforços para o desenvolvimento da maturidade deste protocolo que gradativamente esta se tornando o padrão para o estabelecimento, modificação e finalização de sessões multimídia. 2.2 Introdução Segundo as especificações contidas no Request For Comment 3261 (RFC 3261), algumas aplicações que utilizam a Internet necessitam do estabelecimento e gerenciamento de sessões. O fato dos usuários moverem-se entre terminais, estarem acessíveis por diferentes nomes, comunicarem-se utilizando diferentes mídias e às vezes simultaneamente, dificulta a implementação destas aplicações. Neste cenário destaca-se o protocolo SIP. Definido e implementado pelo Internet Engineering Task Force (IETF), trata-se de um protocolo de controle referente à camada de aplicação do Modelo de Referência OSI (Open System Interconnection), capaz de iniciar, modificar e terminar comunicações multimídia ou chamadas entre usuários, definindo como os equipamentos (computadores, telefones fixos, celulares, etc.) trocarão informações entre si. As aplicações atuais do SIP estão direcionadas para as sessões interativas de multimídia, tais como chamadas telefônicas ou conferências multimídia, mas o SIP pode ser utilizado em sistemas de mensagens instantâneas, notificação de acontecimentos, ou na gestão de outros tipos de sessão como, por exemplo, jogos distribuídos. Em meio as suas funcionalidades tem-se o estabelecimento de chamadas, a localização de usuários, suporte a unicast e multicast, administração na participação de chamadas, negociação de recursos entre as partes e a

22 21 possibilidade de interoperabilidade com o protocolo H323, através de um gateway. O SIP basea-se no modelo cliente/servidor, como demonstrado na figura 1, o cliente faz a requisição e o servidor retorna as respostas referentes ao pedido. Figura 1 - Arquitetura cliente/servidor A sintaxe e semântica do SIP assemelham-se ao HTML com campos explicitamente descritos, e herda do Hyper Text Transfer Protocol (HTTP) várias propriedades, uma delas: o suporte ao transporte de qualquer tipo de carga. E assim como o HTTP propiciou um grande impacto na Internet, o SIP promete o mesmo no que se refere à comunicação em tempo real: com celulares, ou telefones comuns, via mensagens instantâneas, ou utilizando qualquer dispositivo fundamentado em IP (Internet Protocol). De fato o potencial do SIP extrapola sua simplicidade e flexibilidade. Com uma estrutura textual, o SIP possibilita a inclusão de novas características de forma fácil e compatível com versões anteriores, o que é fundamental para um protocolo que pretende ter vida longa. Os endereços SIP são URLs (Unifomr Resource Locators), possibilitando a implementação de diferentes recursos, como permitir realizar uma chamada, apenas com o clique em

23 22 um link em uma página web. O protocolo SIP faz parte de uma arquitetura de protocolos de Conferência Multimídia da Internet, em desenvolvimento no IETF. A figura 2 apresenta a pilha de protocolos correspondente a esta arquitetura. Figura 2 - Arquitetura de protocolos multimídia Internet De acordo com a RFC 2543, que descreve as operações do SIP, este define algumas funcionalidades básicas, tais como: Estabelecimento, modificação e termino de sessões multimídia O protocolo SIP, estabelece, modifica e termina sessões multimídia, independente do tipo de sessão, seja ela uma vídeo conferência, uma chamada telefônica na Internet, um chat, ou até sessões de jogos entre participantes. O SIP determina as capacidades do meio de transmissão entre os usuários e estabelece o nível mínimo de comunicação possível entre dois pontos. Além disso, permite que os usuários determinem o tipo de informação que será trocada e seus respectivos parâmetros. Possibilita a alteração dinâmica das configurações estabelecidas no momento da conexão, por exemplo, a entrada de outros intervenientes na conferência, ou alterações nas características em uma sessão já iniciada. O SIP também detecta a transferência de chamadas, estabelecendo uma conexão entre o transmissor e o novo receptor, encerrando a conexão original. Se uma chamada não pode ser estabelecida porque o destinatário esta indisponível, o SIP e capaz de determinar o estado do mesmo, se este já está com outra chamada em curso, ou se não atende num determinado tempo. Mobilidade O SIP não pode iniciar uma sessão com um potencial participante até

24 23 que este seja localizado. É comum que um usuário se desloque entre estações de trabalho, podendo ser localizado em vários lugares. O SIP determina a localização do destino da chamada através da resolução de endereços, mapeamento de nomes e redirecionamento de chamadas. Para que os usuários possam ser localizados, estes registram-se em um servidor de localização, isto torna-se necessário para que um determinado usuário que possui um nome qualquer, possa ser localizado em algum momento da ligação. Os usuários em um ambiente SIP, são identificados através do SIP Uniform Resource Locators, (URL), cuja sintaxe assemelha-se aos endereços de correio eletrônico, geralmente constituído por um nome de usuário e a descrição do domínio, por exemplo: SIP:Arnaldo@empresa.com. 2.3 Componentes do SIP O IETF define um conjunto de componentes na arquitetura do SIP, operando em uma rede IP. Este conjunto de componentes é definido como Rede SIP, e é apresentado na figura 3. Figura 3 - Arquitetura SIP

25 24 SIP User Agent (UA) É o cliente da arquitetura, ou ponto final da comunicação multimídia, que provê a interface de interação com o usuário. O User Agent possui dois componentes: um User Agent Client (UAC), que é responsável por iniciar as chamadas enviando as requisições, e um User Agent Server (UAS) responsável por responder as requisições do UAC. Um UA tem a capacidade de atuar como UAC e UAS, porém de um modo a cada transação, dependendo de quem inicia o pedido. Os SIP UA s são implementados em diversos tipos de sistemas. Estes podem, por exemplo, operarem em um computador, através de uma aplicação, ou podem ser implementados em dispositivos dedicados como um SIP phone. A figura 4, ilustra alguns exemplos de UA s: Figura 4 - Exemplos de UA s SIP Proxy Server São intermediários em uma comunicação multimídia, é um servidor de redirecionamento de requisições e respostas. O SIP Proxy Server, recebe uma requisição e atua como sinalizador da chamada, redirecionando-a para o próximo servidor SIP da rede, como se fosse o requisitante. Assim que recebe a resposta, encaminha ao real chamador. O SIP Proxy Server também disponibiliza serviços

26 25 como: autenticação, autorização, controle de acessos, roteamento, retransmissões de pedidos e segurança. Tipicamente, o Proxy Server, acessa uma base ou um serviço de localização para determinar o próximo hop (nó da rede). Esta interface entre proxy e serviço de localização não é definida pelo SIP. As bases acessadas pelo proxy, para determinar a localização, pode conter: informações de presença, registros SIP, ou qualquer outro tipo de informação que auxilie na localização do usuário. SIP Redirect Server Responsável por receber as requisições e Informar aos clientes o caminho que a chamada deve tomar, de forma que o cliente entre diretamente em contato com os próximos UAs. A função primária do Redirect Server é o roteamento de chamadas, ou seja, a determinação do conjunto de servidores que será utilizado como rota para a comunicação. Para que sejam determinadas as rotas, tanto o SIP Proxy Server quanto o SIP Redirect Server, podem utilizar meios tais como executar programas de consulta a banco de dados. Além disto, um servidor proxy também pode duplicar a requisição, enviando copias destas para os próximos servidores. Isto proporciona que uma requisição de inicio de chamada tente diferentes rotas, e a primeira localização que responder é conectada com o cliente chamador. Em resumo, o Redirect Server, faz o roteamento das requisições e respostas enviando uma mensagem aos clientes com o endereço SIP procurado, e não fazendo o papel de continuar a chamada. A Figura 5 ilustra o funcionamento do Redirect Server. Nesta figura, Lívia pretende iniciar uma chamada para Rodrigo, utilizando uma aplicação SIP em seu computador. Ao enviar o convite, o UA de Livia primeiramente tenta localizar Rodrigo pelo seu endereço público, porém, no domínio empresa.com, existe um SIP Redirect Server controlando os convites para inicio de sessão, que se destinam a este domínio. O Redirect Server sabe que Rodrigo pode ser encontrado tanto no endereço: SIP:Rodrigo.Souza@empresa.com, quanto no endereço: SIP: Rodrigo@universidade.com, então o Redirect Server informa Livia para que tente localizar Rodrigo, nos endereços conhecidos. Além disso, o servidor de redirecionamento é capaz de priorizar e informar para o UA de Livia que Rodrigo será localizado provavelmente no domínio empresa.com. Nota-se que neste exemplo, o Redirect Server meramente retorna uma lista de possíveis localidades do destinatário.

27 26 Figura 5 - Funcionamento do Redirect Server A arquitetura SIP pode ainda apresentar os seguintes componentes: SIP Registrars São responsáveis por processar os pedidos dos UAC, registrando sua localização, que é armazenada em algum dos servidores de localização da arquitetura. O Registrar ou Register Server pode ser incluído em um servidor proxy ou em um Redirect Server. A figura 6 mostra Rodrigo registrando sua localização em um SIP Registrar:

28 27 Figura 6 - Registro da localização em um Registrar Server Servidor de Localização usuários. Sua função é armazenar e consultar registros de localização de Gateway SIP O Gateway e responsável pela interoperabilidade entre redes SIP e outras que utilizam diferentes protocolos de sinalização, SIP H323 ou SIP PSTN (Public Switched Telephone Network). A figura 7 ilustra esta interoperabilidade.

29 28 Figura 7 - Gateway SIP/PSTN e gateway SIP/H Sinalização SIP Na figura 8, vê-se um exemplo do estabelecimento de uma sessão SIP simples, entre dois dispositivos SIP. Estes dispositivos podem ser telefones SIP, hand-helds, palmtops, telefones celulares, softwares para chamadas SIP, entre outros. No exemplo ilustrado por Jonhston (2001), assume-se que ambos dispositivos estão conectados em uma rede IP e cada um conhece o endereço IP do outro.

30 29 Figura 8 - Estabelecimento de uma sessão SIP simples Neste exemplo, o chamador Anderson inicia a troca de mensagens enviando uma mensagem SIP INVITE para Livia. A mensagem de INVITE, contem os detalhes do tipo de sessão que será estabelecida. Esta sessão pode ser tanto uma chamada com voz, uma conferência com vídeo, ou até uma sessão para uma partida de um jogo. Os campos da mensagem de INVITE são demonstrados na figura 9. INVITE sip:livia@empresa.com.br SIP/2.0 Via: SIP/2.0/UDP laboratorio.faculdade.com.br:5060;branch=z9hg4bkfw19b Max-Forwards: 70 To: Livia <sip:livia@empresa.com.br> From: Anderson <sip:anderson@faculdade.com.br>;tag=76341 Call-ID: @laboratorio.faculdade.com.br CSeq: 1 INVITE Subject: Preciso de sua ajuda... Contact: <sip:anderson@laboratorio.faculdade.com.br> Content-Type: application/sdp Content-Length: 158 v=0 o=anderson IN IP4 laboratorio.faculdade.com.br s=phone Call c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 Figura 9 - Campos da mensagem INVITE

31 30 A linha de início do INVITE SIP contém o tipo de pedido enviado pelo cliente SIP, o endereço SIP do usuário destino e a versão SIP utilizada. De acordo com Hersent (2001), o cabeçalho geral, comum tanto nos pedidos como nas respostas, contém os seguintes campos: Via: Traz a versão SIP, o protocolo da camada de rede, o endereço IP do usuário que faz a chamada e a porta utilizada. Call-ID: A primeira parte deste campo deve ser um padrão único dentro de cada agente, e a última parte, o nome de domínio ou endereço IP. Um novo Call- ID deve ser gerado para cada chamada. From: Este campo contém um nome que pode ser mostrado opcionalmente e o endereço do originador da chamada. Deve estar presente tanto nas requisições quanto nas respostas SIP. Nas respostas, o campo From simplesmente é copiado a partir do pedido e, portanto, não designa ser o originador da chamada. To: Este campo indica o destino da chamada, sendo obrigatório em todas as requisições e respostas SIP. Cseq: Este campo guarda um número escolhido aleatoriamente sem sinal, que é incrementado a cada novo pedido (com exceção dos pedidos do tipo ACK e CANCEL, onde o número é o mesmo da resposta recebida para o ACK; e o mesmo do pedido cancelado para o CANCEL) juntamente com nome do método, ou seja, que identifica o tipo de pedido que está sendo enviado. No caso de mensagens do tipo resposta, o servidor deve copiar o valor Cseq do pedido para as respostas correspondentes. Em ambos os tipos de mensagens (requisições e respostas), o campo Qseq é obrigatório. Além dos campos de cabeçalho geral (utilizado por requisições e respostas), uma requisição pode transportar campos com informações

32 31 específicas dos pedidos no cabeçalho, tais como: o campo Accept que transporta os tipos de mídias aceitáveis na resposta, o campo Subject para transportar informações sobre a natureza da chamada. Os campos que terminam com CR (Carrier Return) e LF (Line Feed) são utilizados para determinar o uso de uma linha em branco entre os campos. O cabeçalho da entidade é formado por campos de que se aplicam diretamente ao corpo da mensagem, são eles: Content-Type: Informa o tipo de conteúdo da mensagem. Content-Length: Contém o número de octetos do corpo da mensagem. Os campos Content-Type e Content-Length, indicam que o corpo da mensagem, vista na figura 9, é SDP (Session Description Protocol), contendo 169 octetos de dados. A demonstração da contagem dos octetos é ilustrada na figura 10. Uma linha em branco separa o corpo da mensagem dos campos de cabeçalho, que termina com o campo Content-Length. No exemplo da figura 9, pode-se observar sete linhas de informações SDP, que descrevem o tipo de mídia que o chamador Anderson prefere estabelecer com Livia. A informação de mídia descrita é necessária, pois o SIP não faz suposição da mídia utilizada, então o originador deve especificar exatamente seu tipo. Os nomes dos campos SDP são listados na figura 11. Linha Total v=0 05 o=anderson IN IP4 laboratotio.faculdade.com.br 70 s=phone Call 14 c=in IP t= m=audio RTP/AVP 0 25 a=rtpmap:0 PCMU/ Figura 10 - Cálculo do campo Content-Length

33 32 Parâmetros SDP Descrição v=0 Numero da versão o=anderson IN IP4 Nome do originador laboratorio.faculdade.com.br s=phone Call Assunto c=in IP Conexão t=0 0 Tempo m=audio RTP/AVP 0 Mídia a=rtpmap:0 PCMU/8000 Atributos Figura 11 - Descrição dos campos SDP A figura 11 inclui: O endereço de conexão IP O formato da Mídia áudio. O numero da porta utilizada O protocolo de transporte de Mídia RTP (Real Time Protocol). Codificação da Mídia - PCM u Law. Taxa de amostragem 8000Hz. O INVITE SIP, é apenas um exemplo de requisição SIP. Segundo especificações na RFC 3261, existem ainda cinco outros tipos ou métodos de requisições SIP, e mais alguns em extensões desta RFC. As tabelas 12 e 13 apresentam os seis métodos de requisições SIP e os métodos estendidos respectivamente. Método INVITE ACK BYE CANCEL REGISTER OPTIONS Funcionalidade Convida pessoas para participar de uma sessão Confirma o recebimento de uma resposta final para um INVITE Solicita o término de uma sessão Solicita que uma sessão prévia seja cancelada, diferente do BYE Registra a informação de contato de um indivíduo Consulta servidores com respeito a suas capacidades Figura 12 - Métodos de requisições SIP

34 33 Método RFC Funcionalidade INFO 2976 Carrega informações de controle geradas durante a sessão MESSAGE 3428 Permite a transferência de mensagens instantâneas NOTIFY 3265 Permite a notificação de eventos específicos PRACK 3262 Confirma a recepção de uma mensagem de resposta informativa PUBLISH 3903 Publica o estado de um evento REFER 3515 Solicita que o receptor faça contato com um terceiro participante SUBSCRIBE 3265 Permite se subscrever para um estado particular de um recurso UPDATE 3311 Permite a atualização dos parâmetros de uma sessão Figura 13 - Métodos de requisições estendidas do SIP A próxima mensagem vista no fluxo da figura 8 é a 180 Ringing, enviada em resposta ao INVITE. Esta mensagem indica que a outra parte, no caso Lívia recebeu o INVITE, e esta sendo alertada de que alguém quer contatá-la. O alerta pode ser o toque do telefone, uma mensagem piscando no display, alerta vibratório, ou qualquer outra forma que indique a intenção da chamada. O 180 Ringing é um tipo de mensagem SIP de resposta. As mensagens de resposta são numéricas e classificadas pelo primeiro dígito da seqüência. O 180 Ringing é qualificado como classe de informação, identificado pelo primeiro digito, o número 1. Existem seis classes de respostas SIP, as primeiras cinco, foram herdadas do HTTP versão 1.1, a sexta e ultima foi criada especificamente para o SIP. A figura 14 define cada classe de resposta SIP: Classe Descrição Ação 1xx Informativo Indica o status da chamada antes que esta se complete 2xx Sucesso A requisição foi recebida com sucesso 3xx Redirecionamento O servidor retornou possíveis localidades. O cliente deve reenviar a requisição para outros servidores 4xx Erro no Cliente A requisição falhou devido a um erro no cliente 5xx Falha no Servidor A requisição falhou devido a um erro no servidor 6xx Falha Global A requisição falhou. A requisição não deve ser enviada a este ou outros servidores Figura 14 - Classes de resposta SIP

35 34 A figura 15 demonstra a estrutura da mensagem 180 Ringing. SIP/ Ringing Via: SIP/2.0/UDP laboratorio.faculdade.com.br:5060;branch=z9hg4bkfw19b ;received= To: Livia <sip:livia@empresa.com.br>;tag=a53e42 From: Anderson <sip:anderson@faculdade.com.br>;tag=76341 Call-ID: @laboratorio.faculdade.com.br CSeq: 1 INVITE Contact: <sip:livia@torre.empresa.com.br> Content-Length: 0 Figura 15 - Estrutura da mensagem 180 Ringing Esta mensagem é composta pela cópia de alguns campos da mensagem INVITE, como: Via, To, From, Call-ID e QSeq. Então uma linha de inicio é adicionada a mensagem contendo a versão do SIP, o código de resposta e a frase que indica a razão: Ringing (tocando). O parâmetro received é adicionado ao campo Via, que contem o endereço IP de quem o origina a chamada, que tipicamente é o mesmo endereço URI no campo Via, resolvido por um DNS (laboratorio.faculdade.com.br). Nota-se que os campos To e From não se inverteram, o que poderia se esperar, já que a mensagem partiu de Livia, porém o SIP indica a direção da requisição, e não a direção da mensagem. Agora o campo To, possui uma tag gerada por Lívia. Desde então, todas as requisições e respostas da sessão terão as tags geradas por ambos. A resposta também contém o campo Contact, que descreve o endereço pelo qual Livia pode ser contatada diretamente uma vez que a sessão tenha sido estabelecida. Quando a parte chamada aceita a sessão, atendendo ao telefone, por exemplo, uma resposta de 200 OK é enviada ao originador da chamada, que também significa que o tipo de mídia proposta foi aceito. A figura 16 ilustra a estrutura da mensagem 200 OK, enviada por Lívia.

36 35 SIP/ OK Via: SIP/2.0/UDP laboratorio.faculdade.com.br:5060;branch=z9hg4bkfw19b ;received= To: Livia From: Anderson Call-ID: CSeq: 1 INVITE Contact: <sip:livia@torre.empresa.com.br> Content-Type: application/sdp Content-Length: 155 v=0 o=livia IN IP4 torre.empresa.com.br s=phone Call c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 Figura 16 - Estrutura da mensagem 200 OK A mensagem 200 OK é estruturada da mesma forma que a 180 Ringing, contendo o mesmo tag do campo To, e o URI do contato. As capacidades da mídia devem ser explicitadas no corpo da mensagem SDP adicionada na resposta. No caso da figura 16, o corpo SDP contém: Endereço do ponto final da comunicação Formato da mídia áudio. Número da porta Protocolo de transporte de mídia RTP. Codificação da mídia PCM u Law. Taxa de amostragem 8000Hz. A etapa final para confirmação e inicio da sessão, é feita por uma requisição de reconhecimento (acknowledgment). Este reconhecimento indica que o originador da chamada, no caso Anderson, recebeu com sucesso, do destino, Livia, uma resposta. Esta troca de informações de mídia permite que a sessão seja estabelecida usando outro protocolo, o RTP, por exemplo. A figura 17 mostra a estrutura do acknowledgment (ACK).

37 36 ACK SIP/2.0 Via: SIP/2.0/UDP laboratorio.faculdade.com.br:5060;branch=z9hg4bk321g Max-Forwards: 70 To: Livia From: Anderson Call-ID: CSeq: 1 ACK Content-Length: 0 Figura 17 - Estrutura do ACK O campo CSeq, tem o mesmo número do INVITE que originou a sessão, porém o método agora é o ACK. Neste momento a sessão de mídia é iniciada, utilizando os parâmetros estabelecidos na troca de mensagens SIP. A comunicação acontece utilizando outro protocolo, tipicamente o RTP. O parâmetro branch contido no campo Via guarda um novo identificador da transação, isso ocorre após o reconhecimento de uma das partes da comunicação através do 200 OK, considerando uma nova transação. Estas mensagens trocadas, mostram que o Session Initiation Protocol é um protocolo de sinalização fim-a-fim, ou seja, uma rede SIP ou um Servidor SIP, não é requerido para que o protocolo seja usado. Dois end-points, utilizando a pilha de protocolo SIP e conhecendo o endereço IP um do outro, podem fazer uso do SIP para configurar uma sessão entre eles. Quando o chamador, Anderson, origina um INVITE, esta agindo como cliente, e quando Livia, responde a esta requisição, esta agindo como servidor. Depois de estabelecida a conexão, Livia envia uma requisição de BYE, agindo então como um cliente, e Anderson agora age como o servidor, quando responde a requisição. Este é o motivo pelo qual um ponto final da comunicação deve implementar tanto o software cliente quanto o servidor. Jonhston (2001) ressalta ainda, que esta é a diferença do SIP em relação a outro protocolo cliente\servidor como o HTTP ou FTP. No HTTP, por exemplo, o browser (navegador) age sempre como o cliente, e o Web Server age sempre como o servidor, similar ao FTP. A figura 18 demonstra a requisição de BYE, que indica que uma das partes, no caso Livia, deseja encerrar a sessão:

38 37 BYE SIP/2.0 Via: SIP/2.0/UDP torre.empresa.com.br:5060;branch=z9hg4bk392kf Max-Forwards: 70 To: Anderson From: Livia Call-ID: CSeq: 1 BYE Content-Length: 0 Figura 18 - Estrutura do BYE Pode-se observar na figura 18 que o campo Via do BYE possui o endereço do host de Livia, e também um novo identificador de transação. Isso ocorre pois o BYE é considerado como uma nova transação, independente do INVITE e do ACK. Os campos From e To mostram que a mensagem agora parte de Livia. Assim Anderson consegue identificar a sessão pelo campo Call-ID, que é o mesmo do INVITE, e então finalizar a sessão correta. A confirmação da resposta do BYE é o 200 OK, visto na figura 19, nota se que a resposta mantém o valor CSeq da requisição de BYE. SIP/ OK Via: SIP/2.0/UDP torre.empresa.com.br:5060;branch=z9hg4bk392kf ;received= To: Anderson <sip:anderson@faculdade.com.br>;tag=76341 From: Livia <sip:livia@empresa.com.br>;tag=a53e42 Call-ID: @laboratorio.faculdade.com.br CSeq: 1 BYE Content-Length: 0 Figura OK confirmação do BYE 2.5 Sinalização SIP com Servidor Proxy Jonhston (2001), explica ainda, que no exemplo ilustrado na figura 8, o originador da chamada, Anderson, conhecia o endereço IP do destinatário do convite, possibilitando que a requisição de INVITE pudesse ser diretamente enviada ao destino, o que não acontece em geral. Um endereço IP não pode ser utilizado como um número de telefone, isto porque os endereços IPs são geralmente dinâmicos, obtidos pelo host quando este se conecta a um servidor DHCP, por exemplo. Este endereço IP mantém-se fixo durante o tempo em que o host

39 38 permanece conectado, porém o endereço será diferente a cada conexão com o servidor. Com isto conclui-se que o endereço IP, não identifica unicamente um usuário, e sim um host em uma rede particular. Contudo, existe um protocolo que identifica o usuário através de um endereço, independente de onde este esteja, este protocolo é o SMTP (Send Mail Transfer Protocol). O SMTP entrega as mensagens pelo endereço de , permitindo que o destinatário seja alcançado, independente de qual seja seu endereço IP, ou onde este esteja localizado. Sendo a comunicação usuário-a-usuário e não dispositivo-a-dispositivo, o SIP utiliza um esquema de endereçamento semelhante ao de . Este endereçamento é parte da família de endereços da Internet conhecidos como URI (Universal Resource Identifier). O SIP URI é um nome, que é resolvido em endereço IP utilizando-se um SIP Proxy Server e consultas a um DNS (Domain Name Server), no momento da chamada, como visto na figura 20. Nesta figura, observa-se uma típica chamada SIP utilizando-se um Proxy Server. Figura 20 - Chamada SIP com Proxy Server

40 39 O SIP Proxy Server, não configura ou termina a sessão, este age apenas como intermediário, situando-se entre as trocas de mensagens, apenas recebendo as requisições e repassando-as. Na figura 20 vê-se apenas um servidor proxy, porém podem existir múltiplos servidores no caminho da sinalização. O SIP possui duas categorias de URIs: a primeira corresponde ao usuário, e a segunda corresponde ao dispositivo ou ponto final da comunicação. As URI de usuário ou user URI são conhecidas como address of record (AOR). Requisições destinadas a AORs necessitam de buscas em bancos de dados de localização, podendo resultar no envio da requisição para um ou vários dispositivos, já o URI de dispositivo, conhecido como contato, não necessita de busca a banco de dados. O address of record é geralmente usado nos campos de cabeçalho: To e From, enquanto um URI de dispositivo é usado no campo de cabeçalho Contact. O método que relaciona as URIs de dispositivo com um address of record é denominado REGISTER. Este método é detalhado na sessão 2.6. Na demonstração da figura 20, Anderson desconhece a localização de Rodrigo, então o SIP Proxy Server é usado para repassar o INVITE. Primeiramente ocorre uma busca do URI SIP do domínio de Rodrigo, que retorna o endereço IP do SIP Proxy Server deste domínio, então o INVITE é repassado a este endereço. A figura 21 mostra a estrutura do INVITE. INVITE sip:rodrigo@escritorio.com.br SIP/2.0 Via: SIP/2.0/UDP :5060;branch=z9hG4bKmp17a Max-Forwards: 70 To: Rodrigo <sip: Rodrigo@escritorio.com.br > From: Anderson <sip:anderson@faculdade.com.br>;tag=42 Call-ID: 10@ CSeq: 1 INVITE Subject: Onde você está exatamente? Contact: <sip:anderson@pc33.faculdade.com.br> Content-Type: application/sdp Content-Length: 159 v=0 o=anderson IN IP s=phone Call t=0 0 c=in IP m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 Figura 21 - INVITE repassado ao Proxy