UNIVERSIDADE PRESBITERIANA MACKENZIE

MARCOS PAULO HACK

Analisador Distribudo de Protocolo SIP para Sistemas de Telefonia IP

So Paulo 2009

MARCOS PAULO HACK

ANALISADOR DISTRIBUDO DE PROTOCOLO SIP PARA SISTEMAS DE TELEFONIA IP

Trabalho de concluso de Curso de Cincia da computao da Universidade Presbiteriana Mackenzie, apresentado como requisito parcial para obteno do Grau de Bacharel em Cincia da Computao

ORIENTADOR: Prof. Luciano Silva

So Paulo 2009

H11a Hack, Marcos Paulo. Analisador distribudo de protocolo SIP para sistemas de telefonia IP / Marcos Paulo Hack 2009. 77 f. : il. ; 30 cm. Trabalho de Graduao Interdisciplinar (Bacharelado em Cincia da Computao) Faculdade de Computao e Informtica, Universidade Presbiteriana Mackenzie, So Paulo, 2009. Bibliografia: f. 76-77. 1. SIP (Session Initiation Protocol). 2. Monitorao. 3. VoIP (Voice over Internet Protocol). 4. Sistemas distribudos. I. Ttulo. CDD 004.62

 minha esposa por toda a pacincia e companheirismo.

If you cannot measure it, you cannot improve it. (William Thomson)

RESUMO

O objetivo deste trabalho prover uma ferramenta de software capaz de monitorar o comportamento dos componentes de sistemas VoIP heterogneos que utilizam o protocolo SIP para controle de sesses, fornecendo uma visualizao centralizada das informaes obtidas atravs da coleta de dados em diversos componentes do sistema, ajudando administradores e arquitetos na investigao e identificao de problemas relacionados a sinalizao SIP, contribuindo assim para o processo de tomada de decises que podem evitar maiores problemas para os usurios finais do sistema.

Palavras-chave: SIP, monitorao, VoIP, Sistemas Distribudos.

ABSTRACT

The goal of this project is to develop a software tool to monitor the behavior of heterogeneous VoIP systems components that use the SIP signaling protocol, providing a centralized view of the information obtained through different components of the system, helping system administrators and architects to investigate and identify SIP signaling related problems, contributing to the decision making process that can avoid major problems to the final users of the system.

Keywords: SIP, monitoring, VoIP, Distrubuted Systems

LISTA DE ABREVIAES

GPL HTTP IP ISO JAXB JCP JSR NTP OSI POJO PSTN REST RPTC RTP SDP SIP SMTP TCP UAC UAS UA UDP URI

GNU General Public License Hiper Text Transfer Protocol Internet Protocol Internation Standards Organization Java Architecture for XML Binding Java Community Process Java Specification Requests Network Time Protocol Open Systems Interconnection Plain Old Java Object Public Switched Telephone Network Representational State Transfer Rede Pblica de Telefonia Comutada Real-time Transport Protocol Session Description Protocol Session Initiation Protocol Simple Mail Transfer Protocol Transport Control Protocol User Agent Client User Agent Server User Agent User Datagram Protocol Uniform Resource Identifier

LISTA DE FIGURAS

Figura 1: Hierarquia de comutao por circuitos...................................................................17 Figura 2: Rede de comutao de pacotes.............................................................................18 Figura 3: Modelos de referncia OSI e TCP/IP.....................................................................19 Figura 4: Modelo RPTC versus VoIP.....................................................................................22 Figura 5: Diagrama de sequncia de sinalizao SIP para sesso de voz e vdeo...............29 Figura 6: Diagrama de classes do subcomponente de captura de pacotes..........................41 Figura 7: Diagrama de sequncia das classes do componente de captura de pacoters.......42 Figura 8: Diagrama de classe SIPFactory.............................................................................42 Figura 9: Diagrama de classes SIPMessage, SIPRequest e SIPResponse..........................43 Figura 10: Diagrama de classes do componente de envio de mensagens............................45 Figura 11: Diagrama de classes da fbrica abstrata SenderFactory.....................................46 Figura 12: Diagrama de classes do servio MessageService...............................................47 Figura 13: Sincronizao de horrio dos Agentes utilizando o protocolo NTP.......................49 Figura 14: Diagrama de classes da classe SIPHandler.........................................................50 Figura 15: Diagrama de classes da classe SIPSession........................................................50 Figura 16: Diagrama de sequncia de sinalizao SIP da ferramenta Wireshark.................54 Figura 17: Diagrama de classe da classe SIPScenario.........................................................55 Figura 18: Diagrama de classe da classe SIPPerformanceMetrics.......................................55 Figura 19: Exemplo de formulrio de busca de sesses SIP atravs da interface Web........58 Figura 20: Exemplo de listagem da busca de sesses atravs da interface Web.................59 Figura 21: Diagrama de classe SIPSessionManager e SIPSessionFindParams...................60 Figura 22: Diagrama de classes SipanaAgent e ServiceLocator...........................................63 Figura 23: Diagrama de sequncia da classe SIPHandler do componente Agente...............64 Figura 24: Componentes do ambiente de testes...................................................................70 Figura 25: Formulrio de busca de sesses na Interface Web..............................................71 Figura 26: Diagrama de sequncia de sinalizao SIP na interface Web..............................71 Figura 27: Exemplo de acesso aos servios Web utilizando um navegador..........................72 Figura 28: Criao de diagrama de sinalizao SIP atravs dos servios Web....................72

LISTA DE TABELAS

Tabela 1: Componentes e responsabilidades do Analisador Distribudo de Protocolo SIP.. . .40 Tabela 2: Descrio e origem dos dados dos atributos da classe SIPMessage....................43 Tabela 3: Descrio e origem dos dados dos atributos da classe SIPResponse...................44 Tabela 4: Descrio e origem dos dados dos atributos da classe SIPRequest.....................45 Tabela 5: Descrio e origem dos dados dos atributos da classe SIPSession......................50 Tabela 6: Informaes apresentadas no Diagrama de Sequncia de Sinalizao SIP..........53 Tabela 7: Mtodos da classe SIPPerformanceMetrics e mtricas relacionadas....................56 Tabela 8: Parmetros de busca de sesses SIP atravs da interface Web...........................57 Tabela 9: Recursos e respectivos identificadores oferecidos pelos servios Web.................60 Tabela 10: Mdulos do Analisador Distribudo de Protocolo SIP............................................62 Tabela 11: Interfaces de servio e respectiva implementaes EJB3....................................67 Tabela 12: Recursos envolvidos nas visualizaes fornecidas pela interface Web...............68 Tabela 13: Identificadores, mtodos HTTP e implementao dos servios Web...................69

SUMRIO

INTRODUO.....................................................................................................................14 1 REDES DE TELEFONIA CONVENCIONAL E IP...............................................................17 1.1 REDE PBLICA DE TELEFONIA COMUTADA..........................................................18 1.2 REDES DE COMUTAO DE PACOTES..................................................................19 1.3 REDES IP...................................................................................................................20 1.4 VOIP...........................................................................................................................22 2 PROTOCOLO SIP..............................................................................................................25 2.1 FUNCIONALIDADES..................................................................................................25 2.2 ESTRUTURA DO PROTOCOLO................................................................................26 2.3 DIAGRAMA DE SEQUNCIA DE SINALIZAO SIP................................................30 2.4 MTRICAS DE PERFORMANCE DE SESSES SIP................................................31 3 ANALISADOR DISTRIBUDO DE PROTOCOLO SIP........................................................38 3.1 REQUISITOS..............................................................................................................38 3.2 MODELAGEM............................................................................................................41 3.3 IMPLEMENTAO.....................................................................................................62 3.4 TESTES......................................................................................................................70 4 CONCLUSES E TRABALHOS FUTUROS......................................................................71 REFERNCIAS BIBLIOGRFICAS.....................................................................................72

15

INTRODUO
A indstria de telefonia nasceu no final do sculo XIX, pouco depois da inveno do telefone por Alexander Graham Bell no ano de 1876. Naturalmente essa indstria foi criada e evoluiu durante mais de 100 anos sobre um modelo de negcios tradicional e centralizado, onde poucas empresas foram, e continuam sendo, responsveis pela pesquisa, desenvolvimento e produo das tecnologias envolvidas. Mais de meio sculo depois, em meados de 1950, o Departamento de Defesa dos Estados Unidos, no auge da Guerra Fria, tinha uma necessidade muito especial no campo das telecomunicaes, a qual a infraestrutura de rede da telefonia convencional no seria capaz de atender: uma rede de comunicao capaz de sobreviver uma guerra nuclear. Passaram-se quase vinte anos at que essa rede comeasse de fato a ser desenvolvida, e no final dos anos 60 uma rede completamente distribuda comearia a ser desenvolvida dentro dos laboratrios de pesquisa das universidades. Era o incio do desenvolvimento de uma rede que se espalharia por todo o planeta conectando computadores de universidades, empresas e pessoas de uma forma nunca antes imaginada, a Internet. A Internet foi desenvolvida sobre uma filosofia muito diferente da indstria de telefonia, seus padres e protocolos foram especificados e implementados, em grande parte, de forma aberta e compartilhada por pesquisadores e estudantes dentro das universidades, s mais tarde que empresas privadas comeariam a participar desse desenvolvimento. Um dos padres mais importantes desenvolvidos dessa forma foi o modelo de referncia e a pilha de protocolos TCP/IP, que se tornou o padro de protocolo de comunicao da Internet, e posteriormente tambm de redes privadas empresariais. E na medida que o volume de informaes e os investimentos, tanto na Internet como em redes de dados comerciais, foram aumentando, rapidamente se percebeu que um novo sistema de comunicaes poderia ser desenvolvido sobre essa infraestrutura, um modelo que permitiria no apenas poucas empresas ligadas aos fabricantes de equipamentos a desenvolverem aplicaes e servios, como ocorre na indstria de telefnica tradicional, mas praticamente todas as empresas de software que desejassem entrar nesse mercado. Esse modelo possvel pois a infraestrutura subjacente foi desenvolvida atravs de padres abertos, que permitem a interoperabilidade de sistemas desenvolvidos de forma independente de fornecedor, e foi exatamente sobre esse modelo que a tecnologia de Voz sobre IP foi desenvolvida. A tecnologia VoIP composta por um conjunto de padres e protocolos abertos utilizados para transportar no somente voz, mas tambm vdeo e outros tipos de contedos multimdia atravs de redes IP. Alguns desses protocolos so utilizados para transportar o

16 contedo das sesses, como voz e vdeo, em formato digital atravs de pacotes IP, enquanto outro conjunto distinto executa o trabalho de configurao, controle e trmino dessas sesses, so os chamados protocolos de sinalizao. Atualmente o protocolo SIP (Session Initiation Protocol) o mais utilizado para o desenvolvimento de aplicaes VoIP. Combinado a outros protocolos, por exemplo o SDP (Session Description Protocol) para especificao de parmetros da sesso, o protocolo SIP possibilita a criao de aplicaes e servios para o desenvolvimento de sistemas completos de comunicao sobre a infraestrutura de redes IP. Em termos de estrutura o protocolo SIP possui muitas similaridades com o protocolo HTTP (Hiper Text Transport Protocol), utilizado para transferncia de contedo na World Wide Web, uma das aplicaes mais populares da Internet. Assim como o HTTP, o protocolo SIP utiliza mensagens de requisio e resposta em formato texto, trocadas entre os participantes para estabelecer, controlar e finalizar as sesses. A criao de sistemas de comunicao VoIP utilizando redes IP, principalmente a Internet, como meio de comunicao e o protocolo SIP para controle das sesses, oferece um nmero enorme de possibilidades para o desenvolvimento de novos servios e aplicaes antes inviveis, tanto tcnica quanto comercialmente, considerando a estrutura rgida e muito acoplada aos fornecedores da Rede Pblica de Telefonia Comutada. Porm, as oportunidades so acompanhadas por muitos desafios para tornar a tecnologia VoIP to madura e confivel como a RPTC. Nas redes IP, e em especial a Internet, a perda de pacotes, assim como atrasos e variaes no tempo de entrega so caractersticas inerentes forma como a Internet foi construda. Entre dois computadores conectados Internet podem haver dezenas de redes, pelas quais os pacotes trocados entre eles tm de atravessar, que so controladas por empresas diferentes, com caractersticas e polticas de administrao distintas e que podem interferir no comportamento da comunicao IP. Neste cenrio, ferramentas de monitorao que possam fornecer informaes detalhadas sobre o comportamento e performance dos sistemas VoIP so essenciais para possibilitar o fornecimento de servios de qualidade atravs de redes IP como a Internet. Os administradores e arquitetos de sistemas VoIP precisam dessas informaes para tomar decises de qual provedor oferece servios que melhor atendem suas necessidades, assim como na investigao de problemas enfrentados por seus usurios. exatamente nesse contexto que se encaixa o Analisador Distribudo de Protocolo SIP desenvolvido nesse trabalho, fornecendo uma visualizao centralizada das informaes sobre a sinalizao SIP do sistema monitorado, obtidas atravs da coleta de dados em diversos componentes que compem o soluo. As informaes disponibilizadas incluem o detalhamento da troca de mensagens SIP durante as sesses, que podem ser

17 utilizadas para a investigao de problemas em sesses especficas, e mtricas de performance calculadas a partir de um conjunto definido de sesses, que possibilitam a identificao de padres e tendncias do comportamento do sistema. No Capitulo 1 apresentada uma viso geral da RPTC e como as redes de comutao de pacotes IP podem ser utilizadas como infraestrutura para o desenvolvimento de sistemas de comunicao VoIP, oferecendo uma alternativas rede de comutao de circuitos tradicionais e o modelo de negcios subjacente. O Captulo 2 fornece uma viso detalhada do protocolo SIP, descrevendo sua estrutura, funcionalidades, forma de representao e mtricas de performance associadas ao protocolo, utilizadas para fornecer a viso do comportamento do sistema monitorado. No Captulo 3 so apresentadas a modelagem do Analisador Distribudo de Protocolo SIP, incluindo seus requisitos, arquitetura e modelagem, detalhes de implementao, incluindo ferramentas e bibliotecas utilizadas para o seu desenvolvimento, assim como os testes utilizados para validao da soluo. Finalmente o Captulo 4 apresenta a concluso deste trabalho e possibilidades de trabalhos futuros a partir deste, relacionando sugestes de melhoria e novas funcionalidades que podem ser desenvolvidas.

18

1 REDES DE TELEFONIA CONVENCIONAL E IP

O desenvolvimento do sistema de telefonia convencional teve incio no ano de 1876, quando Alexander Graham Bell patenteou a inveno do telefone. O modelo bsico do sistema telefnico criado por Graham Bell conectava pares de telefones atravs de fios metlicos atravs dos quais a voz humana era transmitida na forma de ondas eltricas. Para cada aparelho de telefone com o qual o usurio desejasse se comunicar era necessrio um novo par de fios para conect-los. Esse modelo no durou muito tempo pois logo se percebeu ser invivel passar fios por cima de rvores, ruas e casas para conectar pares de aparelhos telefnicos. Apenas dois anos mais tarde, em 1878, foi fundada a empresa que dominaria a indstria de telefonia nos Estados Unidos por mais de um sculo, a Bell Telephone Company, que mais tarde, por questes regulatrias, foi adquirida pela American Telephone and Telegraph, a AT&T. Em 1878 a Bell Telephone Company inaugurou a primeira estao de comutao telefnica (TANENBAUM, 2003). Nesse novo modelo cada aparelho era conectado central de comutao atravs de um par de fios, que ento poderia ser conectado a outros terminais atravs de conexes manuais realizadas por operadores da empresa utilizando painis de conexes. Era o incio das redes de circuitos comutados, que prevaleceram como tecnologia para transmisso de voz durante mais de um sculo e criaram um mercado de mais de 100 bilhes de dlares por ano (VARSHNEY, 2002). A tecnologia utilizada nos sistemas telefnicos evoluiu muito desde ento, os operadores e painis de conexo foram substitudos por equipamentos eletrnicos de comutao de circuitos, foram criadas diversas hierarquias de centrais de comutao e estas foram conectadas entre si atravs de canais de comunicao digitais utilizando fibras ticas de alta capacidade e satlites ao redor do mundo. Porm, o conceito fundamental das redes comutadas permaneceu o mesmo: um circuito fsico precisa ser alocado atravs de toda a rede para conectar dois terminais para que os usurios possam estabelecer um canal de comunicao de voz. Nas ltimas duas dcadas a demanda do mercado por novos servios e aplicaes, que so difceis e caros de serem implementados sobre a infraestrutura das redes de circuitos comutados, unido aos altos investimentos realizados nas redes de dados baseadas em comutao de pacotes e no protocolo IP, tanto pblicas quanto privadas, fizeram com que o interesse em transmitir voz atravs de redes IP crescesse rapidamente. A convergncia das redes de voz e dados traz diversos benefcios, dentre eles a diminuio de custos devido a utilizao de uma mesma infraestrutura e equipamentos, maior tolerncia a falhas devido a caracterstica distribuda das redes comutadas por pacotes, e por utilizar de forma mais eficiente os canais de comunicao.

19

1.1 REDE PBLICA DE TELEFONIA COMUTADA

Na RPTC (Rede Pblica de Telefonia Comutada) cada usurio possui um terminal telefnico conectado atravs de um par de fios de cobre a uma central telefnica local. Essa conexo entre o usurio final e a central de comutao local denominada rede de ltima milha ou lao local (local loop), e comumente chamada de linha telefnica (DAVIDSON, 2007). As centrais telefnicas locais, tambm chamadas de centrais de comutao de nvel 5, so ento conectadas centrais de comutao regionais ou de nvel 4, que por sua vez esto conectadas entre si diretamente ou atravs de centrais de nvel 3 ou tandem. Em casos onde h trfego suficiente entre as centrais locais, um circuito direto entre elas pode ser instalado a fim de aliviar a carga das centrais de nveis superiores. Essa hierarquia de centrais de comutao de circuitos chega a ter 5 nveis em algumas partes da rede. A Figura 1 ilustra a hierarquia de centrais de comutao na RPTC.

Figura 1: Hierarquia de comutao por circuitos (Fonte: DAVIDSON, 2007)

Quando um usurio tira o telefone do gancho e disca o nmero de outro terminal da rede, um circuito exclusivo de 64 kbps configurado atravs da rede para conectar os dois terminais e estabelecer uma chamada de voz. A RPTC muito eficiente para realizar a funo para a qual foi projetada, ou seja, estabelecer chamadas de voz entre os terminais conectados a ela. Porm, nos ltimos anos o mercado vem demandando por novas funcionalidades que so muito difceis ou muito caras de serem implementadas na rede atual, principalmente porque apenas os fabricantes de equipamento so capazes de desenvolver novas aplicaes e funcionalidades para funcionar em seus equipamentos. A infraestrutura da RPTC tambm utilizada para conectar redes de dados geograficamente distribudas, onde geralmente no vivel, ou permitido, instalar circuitos privados exclusivos para transmisso de dados. Nesses casos geralmente circuitos com maior capacidade do que as linhas telefnicas convencionais de 64 kbps de largura de

20 banda so utilizadas. Os provedores de telefonia oferecem circuitos ISDN BRI com dois canais de 64 kbps, ISDN PRI com 23 canais de 64 kbps, totalizando 1.472 Mbps de largura de banda, enlaces E1 de 2.048 Mbps e T1 de 1.544 Mbps, E3 de 34.368 Mbps e T3 de 44.736 Mbps, e finalmente os enlaces T4 que correspondem a 168 circuitos T1, totalizando 274.176 Mbps. O padro E* utilizado na Europa e tambm no Brasil, j o padro T* utilizado nos EUA e Japo (DAVIDSON, 2007). Uma das razes para a convergncia do trfego de voz como uma aplicao sobre as redes de dados que o trfego de dados j ultrapassou o de voz na RPTC, que originalmente foi projeta exclusivamente para trfego de voz e que no capaz de suportar sozinha o crescimento acelerado no volume de dados trafegados. Tecnologias de redes de comutao de pacotes como Fast Ethernet, Gigabit Ethernet, redes pticas e sem fio podem oferecem maior largura de banda e so mais eficientes para o trfego de dados, e em muitos casos j substituem linhas de transmisso atravs de circuitos comutados instalados sobre a infraestrutura da RPTC.

1.2 REDES DE COMUTAO DE PACOTES

As redes de comutao de pacotes foram projetadas com foco nico para a transferncia de dados entre computadores, portanto, diferente das redes de comutao de circuitos utilizadas na RPTC, cujo conceito fundamental o estabelecimento de circuitos fsicos, as redes por comutao de pacotes utilizam o conceito de pequenas unidades de informaes com um cabealho contendo, entre outras coisas, campos de identificao, ou endereo, de origem e destino de cada pacotes, que so ento transmitidas atravs da rede at encontrarem seu destino. A comunicao nesse modelo ocorre atravs da troca de um fluxo de pacotes discretos entre dois dispositivos, conforme ilustrado na A Figura 2.

Figura 2: Rede de comutao de pacotes (Fonte: TANENBAUM, 2003).

21 Em redes comutadas por pacotes a deciso do caminho pelo qual o pacote ser transmitido de responsabilidades dos roteadores, que so computadores especializados na comutao de pacotes de dados atravs de linhas de transmisso conectadas a eles. Em redes IP por exemplo (ver seco 1.3), existem diversos protocolos de roteamento capazes de decidir dinamicamente o caminho a ser utilizado para transmisso dos pacotes baseados em atributos como largura de banda das linhas de transmisso, latncia, disponibilidade, entre outros.

1.3 REDES IP
O termo Rede IP utilizado para denominar redes de comutao de pacotes que utilizam a pilha de protocolos TCP/IP, definida no chamado modelo de referncia TCP/IP, um modelo de camadas similar ao modelo de referncia OSI (Open Systems Interconnection) da ISO (International Standards Organization). Esses modelos so na verdade arquiteturas de rede que dividem em camadas as funes necessrias para se estabelecer comunicao entre computadores interconectados atravs de um meio fsico, fornecendo interfaces bem definidas entre as camadas com o objetivo de minimizar o fluxo de dados e encapsular a responsabilidade de cada uma delas (TANENBAUM, 2003). A Figura 3 ilustra esses dois modelos de referncia.

Figura 3: Modelos de referncia OSI e TCP/IP (Fonte: TANENBAUM, 2003).

O modelo OSI mais completo e detalhado que o TCP/IP, e geralmente utilizado como referncia conceitual na definio de arquiteturas de rede. Diferente do TCP/IP, que fortemente ligado sua pilha de protocolos, o modelo OSI foi desenvolvido antes da criao dos protocolos correspondentes, tornando-o mais flexvel e genrico facilitando a substituio dos protocolos em cada camada. Por outro lado, o modelo TCP/IP foi definido

22 depois dos protocolos, e o modelo na prtica apenas os descreve formalmente. Independente das questes polticas e de padronizao, e de deficincias e qualidades de cada modelo, a pilha de protocolos TCP/IP se tornou um padro para redes de computadores, e as principais razes para isso foram que as implementaes desses protocolos eram melhores que os da OSI e foram popularizadas atravs da implementao disponibilizada gratuitamente no meio acadmico atravs do sistema operacional UNIX, um dos primeiros a disponibilizar a pilha de protocolos (TANENBAUM, 2003).

1.3.1 PROTOCOLO IP
O protocolo IP (Internet Protocolo) faz parte da pilha de protocolos TCP/IP e trabalha na camada 3 do modelo de referncia OSI, a camada de Rede. Ele responsvel pelo roteamento dos pacotes, denominados datagramas, entre dois computadores, ou hosts, que podem estar conectados na mesma rede ou separados por diversas redes intermedirias. Cada datagrama IP possui um cabealho contendo, entre outras informaes, o endereo de origem e destino de cada datagrama, que sero utilizados pelos roteadores para encaminh-los at seu destino final. O protocolo IP no oferece mecanismos de garantia de entrega dos pacotes, deixando essa responsabilidade para os protocolos de camadas superiores, por exemplo o protocolo de camada de transporte TCP (Transmission Control Protocol), que oferece servio de transporte orientado a conexo (STEVENS, 1994). O roteamento IP realizado de forma completamente independente por cada roteador pelo o qual o datagrama passa durante seu caminho at o destino final, em outras palavras, os roteadores no mantm qualquer informao de estado dos pacotes processados, apenas as informaes contidas no cabealho de cada pacotes so consideradas para o seu roteamento. Em consequncia dessa caracterstica, possvel que os datagramas enviados por um host cheguem ao seu destino em uma ordem diferente da original, pois como cada datagrama processado independentemente pelos roteadores, estes podem decidir envi-los por caminhos diferentes, podendo influenciar na ordem de chegada ao destino. Assim a garantia de entrega citada anteriormente, o protocolo IP deixa a responsabilidade de ordenao para os protocolos de camadas superiores.

1.3.2 PROTOCOLOS TCP E UDP

Os protocolos TCP e UDP (User Datagram Protocol) so os responsveis pela camada de transporte da pilha de protocolos TCP/IP.

23 O TCP um protocolo orientado a conexo que oferece o servio de transporte confivel na pilha TCP/IP. O termo orientado a conexo significa que dois processos que queiram se comunicar atravs desse protocolo precisam antes estabelecer uma conexo. Uma analogia comum para esse conceito o de um usurio realizando uma chamada telefnica, onde ele disca um nmero, aguarda a outra parte atender e ento fala al antes de comear a conversa (STEVENS, 1994). O processo de estabelecimento de conexo TCP conhecido como handshake de trs vias (three-way handshake), que resumidamente realizado da seguinte forma: (1) o originador da conexo precisa enviar um pacote inicial com alguns atributos da conexo, (2) o destino ento envia uma mensagem de resposta com parmetros adicionais necessrios para o estabelecimento da conexo e tambm uma confirmao do recebimento da primeira mensagem, e (3) finalmente o originador envia uma confirmao e a conexo estabelecida e dados podem ser trocados atravs dela. J o protocolo UDP fornece o servio de transporte no-orientado a conexo e no confivel. Uma aplicao que utiliza esse protocolo simplesmente escreve os dados que deseja enviar na camada de transporte e ento um datagrama UDP enviado em um nico datagrama IP, sem garantia alguma que o pacote ao menos tenha alcanado seu destino. A responsabilidade de confirmao de recebimento e possveis retransmisses deixada para a camada de aplicao. Devido a essa caracterstica tentador pensar que o uso do protocolo UDP deva ser evitado e que conexes TCP devam sempre ser utilizadas, mas existem muitos casos onde o uso do UDP recomendado (STEVENS, 1994), como o caso de transmisso de voz sobre redes IP, apresentada na seco Erro: Origem da referncia no encontrado.

1.4 VOIP
A tecnologia de transmisso de Voz sobre IP fornece mecanismos para o estabelecimento de chamadas de voz, vdeo e tambm outros tipos de sesses multimdia, como troca de mensagens instantneas, atravs de redes IP. Porm, alm das funcionalidades oferecidas existe outra caracterstica, talvez ainda mais importante, que a tecnologia VoIP oferece, que uma infraestrutura aberta e baseada em padres sobre a qual ela implementada. Essa infraestrutura permite o desenvolvimento de novos servios e aplicaes mais rapidamente e abre a possibilidade para milhares de outras empresas participarem desse mercado, que no caso da RPTC era restrito a algumas poucas empresas geralmente ligadas aos fornecedores de equipamentos e infraestrutura das redes de circuitos comutados. Essas empresas so chamadas de Fornecedores Independentes de Software ou ISV (Independent Software Vendors). Uma analogia que ajuda a entender esse

24 conceito a substituio dos computadores Mainframes, onde poucos fornecedores desenvolviam aplicaes, pelo modelo cliente-servidor, onde diversas empresas independentes produzem software para rodar numa plataforma distribuda e baseada em padres (DAVIDSON, 2007). A Figura 4 ilustra a comparao do modelo da RPTC, onde os componentes so fortemente acoplados e por isso difceis de serem substitudos, e o modelo de infraestrutura da tecnologia VoIP, na qual cada camada define interfaces baseadas em padres abertos possibilitando a utilizao de diferentes fornecedores que atendem a tais padres. As camadas infraestrutura, controle de chamadas e de aplicaes e servios so discutidas nas seces 1.4.1, 1.4.2 e 1.4.3.

Figura 4: Modelo RPTC versus VoIP (Fonte: DAVIDSON, 2007).

Em ltima anlise essa infraestrutura aberta da tecnologia VoIP que permite que ferramentas como o Analisador Distribudo de Protocolo SIP possam ser desenvolvidas de forma completamente independente dos fornecedores de produtos VoIP. Todas as especificaes e padres esto disponveis de forma aberta e gratuita na forma de RFC (Request for Comments) na Internet, organizadas e controladas pela comunidade internacional IETF (Internet Engineering Task Force).

1.4.1 CAMADA DE INFRAESTRUTURA DE PACOTES

A camada de infraestrutura de pacotes a responsvel pelo transporte de todos os dados trafegados em um sistema VoIP, o que inclui os pacotes com o contedo das sesses multimdia, como voz, vdeo, texto e quaisquer outros dados utilizados pelas aplicaes, e

25 tambm as informaes de sinalizao discutidos na seco 1.4.2. Nessa camada o principal protocolo utilizado o RTP (Real-Time Transport Protocol), um protocolo genrico para o transporte de contedo multimdia em tempo real atravs de redes IP. O RTP implementado na camada de aplicao e normalmente utiliza o protocolo UDP como transporte. Diferente de alguns protocolos da camada de aplicao, o RTP encapsula o servio de transporte de pacotes e completamente independente das aplicaes que o utilizam. Sendo assim, talvez a melhor forma de definir o RTP seja um protocolo de transporte implementado na camada de aplicao (TANENBAUM, 2003). Todos os protocolos de sinalizao VoIP disponveis atualmente utilizam o protocolo RTP como meio de transporte de voz e vdeo (DAVIDSON, 2007).

1.4.2 CAMADA DE CONTROLE DE CHAMADAS

A camada de controle de chamadas ou sinalizao o alvo principal deste trabalho. nela que ocorre o roteamento, configurao, controle e finalizao das sesses multimdia em sistemas VoIP. Existem diversos protocolos que trabalham na camada de controle, cada um deles desenvolvido para atender determinado conjunto de problemas, em especial o protocolo SIP (Session Initiation Protocol), que vem ocupando um lugar de destaque nos sistemas VoIP, sendo utilizado como um padro para dispositivos terminais como aparelhos telefnicos IP, equipamentos de interligao com a RPTC, comumente chamados de gateways, assim como telefones implementados em software ou softphones e aplicaes de troca de mensagens instantneas. O protocolo SIP apresentado em detalhes no Captulo 2. Alm do SIP possvel citar alguns protocolos utilizados em aplicaes especficas em sistemas VoIP, como o H.248 ou MEGACO, utilizado para controle de mdia em gateways, publicado em conjunto pela ITU (International Telecommunication Union) e IETF, e o H.323, com funcionalidades similares a do protocolo SIP e com uma grande base instalada, principalmente por ter sido o primeiro protocolo de sinalizao VoIP a ser desenvolvido, mas que gradativamente est sendo substitudo pelo protocolo SIP.

1.4.3 CAMADA DE APLICAES E SERVIOS

Talvez a melhor forma de definir a camada de aplicaes e servios da infraestrutura VoIP seja separando-a em duas categorias: sendo a primeira um conjuntos de bibliotecas ou APIs (Application Program Interface) que fornecem acesso aos servios disponibilizados

26 pelas camadas de controle e infraestrutura de pacotes, e a segunda as aplicaes propriamente ditas, que oferecem servios e funcionalidades para o usurio final. Nesse novo modelo os fornecedores de equipamentos e infraestrutura preocupam-se basicamente com a primeira categoria da camada de aplicao, fornecendo aos ISVs a infraestrutura de software necessria para a criao de novas aplicaes e servios.

27

2 PROTOCOLO SIP
Neste captulo so apresentadas as principais caractersticas do protocolo SIP (Protocolo de Inicializao de Sesso) relevantes para o entendimento e desenvolvimento do Analisador Distribudo de Protocolo SIP. A definio formal do protocolo pode ser encontrada na RFC 3261 (ROSENBERG et al., 2001). SIP um protocolo de sinalizao de camada de aplicao utilizado para iniciar, controlar e terminar sesses multimdia entre dois ou mais participantes. Essas sesses multimdia incluem sesses de udio e vdeo, sesses interativas de jogos, aplicaes de mensagem instantnea entre outras. O protocolo SIP no especifica um sistema completo de comunicao, ele apenas define a infra-estrutura bsica para estabelecer sesses multimdia ponto-a-ponto. Para o desenvolvimento de sistemas multimdia completos outros protocolos so combinados ao SIP para prover os servios desejados. No caso de sesses de voz e vdeo pela Internet, por exemplo, tipicamente so utilizados os protocolos SDP (Session Description Protocol), para definio e controle dos atributos da sesso multimdia, e o RTP (Real-time Transport Protocol), para a transmisso do fluxo de pacotes contendo a voz ou vdeo.

2.1 FUNCIONALIDADES
O protocolo SIP fornece um conjunto de funcionalidades para o estabelecimento, controle e trmino de sesses multimdia conforme definido na RFC 3261 (ROSENBERG et al., 2001):

Localizao de usurios determinar a localizao final do usurio, fornecendo o endereo de rede atravs do qual possvel se comunicar com o usurio para o estabelecimento de uma sesso. A mobilidade do usurio inerentemente suportada pelo protocolo SIP;

Disponibilidade do usurio determinar se o usurio final deseja ou no participar de um determinado tipo de sesso;

Capacidades do usurio determinar as capacidades de mdia de um usurio, como codecs de udio e vdeo, capacidade de realizar troca de mensagens instantneas, dentre outras;

Configurao de sesso criar e configurar uma sesso entre dois elementos da rede SIP;

28

Gerenciamento

de

sesso

manipular

uma

sesso

previamente

estabelecida, incluindo alterao de atributos, transferncia e trmino da sesso estabelecida, assim como a invocao de novos servios, como por exemplo adicionar uma sesso de stream de vdeo em uma chamada de voz previamente estabelecida.

2.2 ESTRUTURA DO PROTOCOLO

O SIP um protocolo baseado em texto com uma estrutura muito similar aos protocolos HTTP e SMTP, largamente utilizados na Internet para transferncia de contedo multimdia e de mensagens de correio eletrnico, respectivamente. Toda a comunicao se d atravs de requisies e respostas trocadas entre os participantes da sesso (ver seces 2.2.1.1 e 2.2.1.2). O protocolo define diversas funes lgicas que os participantes de um sistema SIP podem assumir durante uma sesso. Algumas dessas funes so desempenhadas por todos os componentes do sistema enquanto outras so especficas para determinados tipos de entidades (DAVIDSON et al., 2007).

2.2.1 MENSAGENS SIP

Uma mensagem SIP pode ser tanto uma requisio de um cliente para um servidor como uma resposta de um servidor para um cliente. Mensagens de Requisio e Resposta usam o formato base definido na RFC 2822 (RESNIK, 2001), porm existem diferenas de sintaxe e conjunto de caracteres utilizados. O que diferencia requisies e respostas a primeira linha da mensagem SIP, chamada de Start-Line (linha inicial). A linha inicial de requisies e respostas so chamadas de Request-Line e Status-Line, respectivamente, cujos formatos sero apresentados nas seces 2.2.1.1 e 2.2.1.2.

2.2.1.1 REQUISIO
Uma mensagem SIP de requisio reconhecida pela presena de uma RequestLine como linha inicial:
Request-Line = Method SP Request-URI SP SIP-Version CRLF

29 onde Method o nome, em caixa alta, de um mtodo de requisio SIP, SP um espao simples (Single Space), Request-URI o endereo para o qual a requisio destinada,
SIP-Version a verso da especificao SIP utilizada na mensagem e CRLF significa os

caracteres de controle Carrier Return e Line Feed, geralmente representados por \r e \n respectivamente. A RFC 3261 (ROSEMBERG et al., 2001) define seis mtodos:

REGISTER registrar informao de contato do usurio, ou seja, serve para informar a localizao do usurio que est enviando a requisio;

INVITE iniciar uma nova sesso multimdia; ACK confirmar o recebimento de certos tipos de respostas; CANCEL cancelar uma requisio enviada anteriormente; BYE terminar uma sesso ativa; OPTIONS consultar capacidades de um User Agent (ver seco 2.2.2).

Mtodos adicionais so definidos em outras RFC que estendem as funcionalidades bsicas do protocolo SIP. Alguns exemplos comumente utilizados so:

MESSAGE transferncia de mensagens instantneas utilizando SIP, definido na RFC 3428 (CAMPBELL et al., 2002);

SUBSCRIBE e NOTIFICATION utilizados para requisio e envio de eventos de notificao, por exemplo notificao de mensagens de correio de voz disponvel para um usurio, definidos na RFC 3265 (ROACH, 2002).

2.2.1.2 RESPOSTA
Uma mensagem SIP de resposta reconhecida por ter uma Status-Line (Linha de Estado) como linha inicial:
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF

o tem Status-Code (Cdigo de Estado) contm um cdigo numrico de 3 dgitos e representa o resultado do processamento de uma requisio processada. O item ReasonPhrase (Razo Textual) um texto curto que descreve o cdigo numrico de resultado. O

cdigo numrico destinado para o processamento pelo computador, j a descrio textual tem por objetivo fornecer um significado desse cdigo numrico para a leitura por um usurio humano. Os demais campos so iguais aos apresentados na seco 2.2.1.1.

30 O primeiro dgito do cdigo de resultado define a classe de resposta. A verso 2.0 do protocolo SIP define 6 classes, e a relao completa dos cdigos de resposta de cada classe pode ser encontrada na RFC 3261 (ROSENBERG et al., 2001):

1xx Provisionamento: Resposta intermediria indicando que a requisio foi recebida e est sendo processada;

2xx Sucesso: Resposta final indicando que a requisio foi processada e aceita e a sesso est estabelecida;

3xx Redirecionamento: Resposta final indicando que a requisio est sendo redirecionada para outro servidor, cujo endereo informado no corpo da resposta. O cliente responsvel por enviar a requisio para o novo endereo.

4xx Erro no cliente: Resposta final indicando que a requisio contm erros de sintaxe ou no pode ser processada pelo servidor;

5xx Erro no servidor: Resposta final indicando que o servidor falhou ao processar uma requisio aparentemente vlida;

6xx Falha global: Resposta final indicando que a requisio no pde ser atendida por nenhum servidor.

2.2.2 FUNES LGICAS

A definio das principais funes lgicas, definidas na RFC 3261 (ROSEMBERG et al., 2001), so importantes para a modelagem do Analisador Distribudo de Protocolo SIP apresentada na seco 3.2:

User Agent (UA) entidade lgica que pode desempenhar ambos papis de User Agent Client e User Agent Server; Um UA pode ou no interagir diretamente com um usurio humano;

User Agent Client (UAC) entidade lgica que cria uma nova requisio SIP e a encaminha para uma entidade UAS. O papel de UAC tem durao de apenas uma transao (ver item 3.1.3). Isso significa que uma aplicao que cria uma nova requisio estar desempenhando o papel de UAC durante aquela transao. Se em seguida essa mesma aplicao responder a uma requisio criada por outro UA, estar agora desempenhando o papel de UAS para essa nova transao;

31

User Agent Server (UAS) entidade lgica que recebe e processa uma requisio SIP gerando uma resposta. A resposta pode aceitar, rejeitar ou redirecionar a requisio. Assim como na funo UAC, o papel de UAS dura apenas durante uma transao e pode, em seguida, desempenhar o papel de UAC para uma nova transao.

Proxy entidade intermediria que tem por objetivo principal rotear requisies recebidas de um UAC para o UAS de destino. Alm de roteamento, um Proxy pode realizar autenticao das requisies antes de encaminh-las ao destino. comum utilizar um Proxy para resolver o problema de traduo de endereos de rede (Network Address Translation ou NAT) em sistemas SIP;

Registrar (Servidor de Registro) atua como um UAS para tratar requisies SIP do tipo REGISTER, utilizadas para manter atualizada informaes sobre a localizao dos usurios;

Back-to-bask User Agent (B2BUA) entidade lgica intermediria que processa requisies SIP como um UAS. Para responder a requisio entrante o B2BUA tambm age como um UAC, criando novas requisies que iro determinar a resposta para a requisio original. Um B2BUA deve manter o estado dos dilogos e participa em todas as transaes dentro do dilogo.

2.2.3 TRANSAES E DILOGOS

Os conceitos de Transao e Dilogo so muito importantes em sistemas que utilizam o protocolo SIP, e uma definio clara desses conceitos muito importante para o bom entendimento da estrutura do protocolo. A definio formal desses conceitos podem ser obtidas na RFC 3261 (ROSEMBERG et al., 2001). Uma Transao SIP consiste de uma nica requisio e todas as respostas referentes a esta requisio, incluindo zero ou mais respostas intermedirias de provisionamento e uma ou mais respostas finais (ver tem 3.1.1). Cada transao possui um lado cliente e um lado servidor, denominadas transao cliente e transao servidor. A transao cliente envia a requisio e recebe as respostas, e a transao servidor recebe a requisio e envia as respostas. Um Dilogo SIP representa uma comunicao ponto-aponto entre dois UA que persiste durante um perodo. Um Dilogo pode ser formado por uma ou mais transaes e representa um contexto onde essas transaes ocorrem.

32

2.3 DIAGRAMA DE SEQUNCIA DE SINALIZAO SIP

Diagramas de sequncia UML (BOOCH et al., 1998) so uma forma conveniente de representar a troca de mensagens SIP entre os componentes envolvidos, chamada de sinalizao SIP. A Figura 5 exemplifica o uso deste tipo de diagrama para sinalizao SIP.

Figura 5: Diagrama de sequncia de sinalizao SIP para sesso de voz e vdeo

No diagrama apresentado na Figura 5 as linhas verticais representam os componentes participantes e as setas horizontais representam as mensagens trocadas,

33 sendo que o componente que est na origem da seta o transmissor e na outra extremidade (para onde a seta aponta) est o receptor da mensagem. As requisies so identificadas com o nome do mtodo SIP sobre a seta, enquanto as mensagens de resposta levam o contedo do campo Status-Code concatenado ao campo Reason-Phrase para facilitar a leitura. As setas bidirecionais azuis e vermelhas identificadas por Sesso de Mdia representam as sesses de mdia que foram estabelecidas utilizando o protocolo SIP, que geralmente utilizam o protocolo RTP como protocolo de transporte para o fluxo de pacotes de udio ou vdeo, porm outros protocolos podem ser utilizados. Diagramas de sinalizao SIP so especialmente teis durante o processo de deteco de problemas (troubleshooting) em sistemas SIP, pois atravs dele possvel visualizar o comportamento de cada componente do sistema durante o estabelecimento da sesso.

2.4 MTRICAS DE PERFORMANCE DE SESSES SIP

Os mecanismos de representao da sinalizao SIP descrita na seco 3.2 so teis para a anlise de problemas de sesses SIP especficas, mas no so apropriados para fornecer uma viso do comportamento do sistema como um todo durante um determinado perodo. Para o desenvolvimento do Analisador Distribudo de Protocolo SIP foram utilizadas as mtricas de performance definidas no Internet-Draft [IETF] intitulado SIP End-to-End Performance Metrics (Mtricas de Performance Ponto-a-Ponto para o protocolo SIP) (MALAS, 2009), desenvolvido sob a tutela do grupo de trabalho Performance Metrics for Other Layers (Mtricas de Performance para outras Camadas) do IETF (IETF):

Este documento define um conjunto de mtricas e suas respectivas utilizaes para avaliar a performance de servios baseados em sesses ponto-a-ponto utilizando o protocolo SIP. O propsito deste documento combinar um conjunto de mtricas comuns, possibilitando medies de performance de forma interopervel, facilitando a comparao de diferentes implementaes da indstria (MALAS, 2009).

Nas seces a seguir so descritas as mtricas de performance definidas neste trabalho e utilizadas para o desenvolvimento do Analisador Distribudo de Protocolo SIP.

34

2.4.1 ATRASO NA REQUISIO DE REGISTRO

Mtrica utilizada para detectar falhas ou no conformidades que estejam causando atrasos na resposta de uma requisio de registro. Calculada como a diferena de tempo entre o envio da requisio de registro e o recebimento da resposta final.

2.4.2 TENTATIVAS NO EFETIVADAS DE REGISTRO

Mtrica utilizada para detectar falhas ou no conformidades que impossibilitaram o devido recebimento e/ou processamento de uma requisio de registro pelo Servidor de Registro. Calculada como o cociente do nmero de requisies no efetivadas pelo nmero total de requisies de registro.

2.4.3 ATRASO NA REQUISIO DE CRIAO DE SESSO

Mtrica utilizada para detectar falhas ou no conformidades que estejam causando atrasos na resposta de uma requisio de criao de uma sesso. Essa mtrica calculada como o intervalo de tempo entre o envio da requisio de criao de sesso INVITE at o recebimento da primeira mensagem de provisionamento, exceto do tipo 100 Trying, ou uma mensagem final de erro.

2.4.3.1 ATRASO NA REQUISIO DE CRIAO DE SESSO ESTABELECIDA COM SUCESSO

Subitem da mtrica descrita na seco 2.4.3 para requisies de criao de sesso atendidas com sucesso. definido como o intervalo de tempo entre o envio da primeira requisio INVITE at o recebimento da primeira mensagem de provisionamento, exceto do tipo 100 Trying, pois esse tipo de reposta, quando utilizada, enviado antes que qualquer processamento pelo UAS e no prov sinal alguma ao usurio de que a sesso foi atendida.

2.4.3.2 ATRASO NA REQUISIO DE CRIAO DE SESSO MAL SUCEDIDA

Subitem da mtrica descrita na seco 2.4.3 para requisies de criao de sesso que falharam. definido como o intervalo de tempo entre o envio da primeira requisio INVITE at o recebimento de uma mensagem final de erro.

35

2.4.3.3 ATRASO NA REQUISIO DE MENSAGEM INSTANTNEA

Subitem da mtrica descrita na seco 2.4.3 para requisies de mensagem instantnea. Calculada como o intervalo de tempo entre o envio da requisio MESSAGE at o recebimento da mensagem de resposta 200 OK.

2.4.4 ATRASO NA DESCONEXO DE SESSO

Mtrica utilizada para detectar falhas ou no conformidades que estejam causando lentido para a desconexo de sesses. Esta mtrica pode ser calculada tanto do ponto de vista do UAC como do UAS e definida como o intervalo de tempo entre o envio da requisio de desconexo BYE at o recebimento da mensagem de confirmao ou o esgotamento do tempo limite.

2.4.4.1 ATRASO NA DESCONEXO BEM SUCEDIDA DE SESSO

Subitem da mtrica 2.4.4 para requisies de desconexo atendidas com sucesso. Calculada como o intervalo de tempo entre o envio da requisio de desconexo BYE at o recebimento de uma mensagem de resposta de confirmao 200 OK.

2.4.4.2 ATRASO NA DESCONEXO MAL SUCEDIDA DE SESSO

Subitem da mtrica 2.4.4 para requisies de desconexo no atendidas. Calculada como o intervalo de tempo entre o envio da requisio de desconexo BYE at o esgotamento do tempo limite de reposta da requisio.

2.4.5 TEMPO DE DURAO DE SESSO

Mtrica utilizada para detectar falhas ou no conformidades que estejam causando sesses com durao muito curtas, como por exemplo chamadas de voz com baixa qualidade de udio que levariam o usurio a desligar uma chamada rapidamente. O tempo de durao de sesso calculado tanto para chamadas completadas com sucesso ou falha e definido como o perodo de tempo entre o recebimento da mensagem de resposta 200 OK referente a requisio INVITE para estabelecimento da sesso, at o envio da requisio BYE para encerramento da sesso ou o esgotamento do tempo limite para

36 confirmao da requisio BYE.

2.4.5.1 TEMPO DE DURAO DE SESSO COMPLETADA COM SUCESSO

Subitem da mtrica 2.4.5 para sesses que foram completadas com sucesso. Neste caso definida como o intervalo de tempo entre o recebimento da mensagem de resposta 200 OK de estabelecimento da chamada, at envio da requisio BYE para encerramento da sesso respondida com sucesso atravs de uma mensagem de resposta 200 OK.

2.4.5.2 TEMPO DE DURAO DE SESSO COMPLETADA COM FALHA

Subitem da mtrica 2.4.5 para sesses no completadas com sucesso. No completada significa que a sesso foi estabelecida com sucesso mas seu encerramento no ocorreu corretamente, causando o esgotamento do tempo limite para recebimento da resposta de confirmao da requisio BYE para encerramento da sesso. Neste caso a mtrica calculada como o intervalo de tempo entre o recebimento da mensagem de resposta 200 OK de confirmao do estabelecimento da chamada at o momento em que o tempo limite de recebimento da confirmao de encerramento da sesso for esgotado.

2.4.6 ELEMENTOS INTERMEDIRIOS POR REQUISIO

Mtrica utilizada para indicar possveis ineficincias no roteamento de requisies e ocorrncia de falhas relacionadas ao nmero de elementos pelos quais uma requisio teve que passar at ser processada.

2.4.7 TAXA DE ESTABELECIMENTO DE SESSO

Essa mtrica reflete a habilidade de um UA de tratar com sucesso requisies de estabelecimento de sesses. A mtrica definida como a taxa do nmero de requisies INVITE respondidas com 200 OK pelo o nmero total de requisies INVITE recebidas excluindo-se as requisies com resposta to tipo 3xx (redirecionamento).

37

2.4.7.1 TAXA DE ESTABELECIMENTO DE SESSO DE MENSAGEM INSTANTNEA

Subitem da mtrica 2.4.7 para sesses de mensagem instantnea (mtodo MESSAGE). Esta mtrica calculada com a taxa do nmero de requisies MESSAGE respondidas com 200 OK pelo o nmero total de requisies MESSAGE enviadas pelo UAC.

2.4.8 TAXA DE EFETIVIDADE NO ESTABELECIMENTO DE SESSO

Esta mtrica complementar mtrica 2.4.7, mas tem o objetivo de excluir da mtrica potenciais efeitos causados por UAS que estejam em processo de desligamento. definida como a taxa do nmero de requisies INVITE respondidas com 200 OK, 480 Temporarily Unavailable (servidor temporariamente indisponvel), 486 Busy Here (servidor ocupado) e 600 Busy Everywhere (todos os servidores ocupados), pelo nmero total de requisies INVITE que no receberam uma resposta.

2.4.9 TAXA DE ERRO NA CRIAO DE SESSO

Taxa de tentativas de criao de novas sesses no efetivadas devido a erros de processamento do UA. A mtrica definida como a taxa entre o nmero de requisies INVITE respondidas com respostas do tipo 500, 503 e 504 pelo o nmero total de requisies INVITE recebidas pelo UA.

2.4.10 TENTATIVAS INEFICIENTES DE CRIAO DE SESSO

Uma tentativa ineficiente de estabelecimento de sesso ocorre quando um UAS ou Proxy interrompem internamente o processamento de uma requisio devido a falhas ou condio de sobrecarga, resultando em respostas finais do tipo 408 Request Timeout (tempo esgotado para processamento da requisio), 500 Server Internal Error (erro interno no servidor), 503 Service Unavailable (servio indisponvel permanentemente) e 504 Server Timeout (tempo esgotado para processamento pelo servidor). A mtrica calculada como o a porcentagem entre o nmero de requisies respondidas com os tipos de respostas relacionadas anteriormente pelo nmero total de requisies de criao de sesso.

38

2.4.11 DESCONEXO DE SESSO CAUSADA POR FALHA

Uma sesso ativa pode ser desconectada devido a uma condio de falha detectada no UA e pode ser identificada pela presena de um cabealho REASON (Razo) (SCHULZRINNE et al., 2002) na requisio BYE para desconexo da sesso. Essa situao pode ocorrer, por exemplo, em um equipamento de converso entre uma rede SIP e a Rede Pblica de Telefonia Comutada (RPTC), conhecidos como gateways, que detecta um erro na conexo com a rede pblica e precisa desconectar a uma sesso SIP associada a esta conexo. Esta mtrica calculada como uma porcentagem do nmero total de requisies de estabelecimento de sesso completadas com sucesso.

2.4.12 TAXA DE COMPLETAMENTO DE SESSO

Uma sesso completada definida como um dilogo SIP que completou sem a ocorrncia de falhas devido a ausncia de respostas por um Proxy ou UA de destino. Esta mtrica calculada como uma porcentagem do nmero total de requisies de estabelecimento de sesso.

2.4.12.1 TAXA DE COMPLETAMENTO DE SESSO COM SUCESSO

Subitem da mtrica 2.4.12 que considera apenas as requisies completadas com sucesso, ou seja, iniciadas com uma requisio INVITE de criao da sesso confirmada com reposta de confirmao 200 OK, e posteriormente terminadas atravs de uma requisio BYE de desconexo da sesso seguida por uma resposta de confirmao 200 OK.

2.4.12.2 TAXA DE COMPLETAMENTO DE SESSO COM FALHA

Subitem da mtrica 2.4.12 que considera apenas as sesses cujas requisies

INVITE de estabelecimento da sesso foram respondidas com mensagens de erro, indicando que a requisio no foi processada. Note que, mesmo que o processamento de estabelecimento da sesso no tenha sido realizado, houve uma resposta para o UAC que originou a requisio, o que caracteriza a sesso como completada conforme definido na seco 2.4.12.

39

2.4.13 TAXA DE SUCESSO NO ESTABELECIMENTO DE SESSO

A taxa de sucesso no estabelecimento de sesso definida como a porcentagem de requisies de estabelecimento de sesso completadas com sucesso em relao s requisies que falharam (definidas nas seces 2.4.10 e 2.4.11).

40

3 ANALISADOR DISTRIBUDO DE PROTOCOLO SIP

A natureza heterognea e distribuda dos sistemas VoIP baseados no protocolo SIP trazem consigo uma srie de desafios em relao a monitorao e gerenciamento dos recursos envolvidos no processamento das requisies. Em muitos casos as mensagens de sinalizao SIP, assim como o fluxo de pacotes de voz, so transmitidos atravs de redes IP no confiveis e com mltiplos domnios de administrao (Autonomous System ou AS), como o caso da Internet. No caminho percorrido desde sua origem at seu destino final, uma requisio pode atravessar diversas redes com caractersticas de configurao e polticas de acesso e priorizao diferentes, que pode afetar diretamente a qualidade ou at mesmo impossibilitar o processamento correto das requisies dos usurios. Mesmo em redes privadas, onde existe um controle maior por parte dos administradores do sistema, existem diversos fatores que podem influenciar na qualidade e disponibilidade de um sistema VoIP, como por exemplo excesso de carga nos equipamentos de rede e servidores, falhas que podem causar alteraes ou at interrupes no caminho percorrido pelos pacotes de rede, entre outras. Em um cenrio como este ferramentas de monitorao capazes de auxiliar no processo de investigao de problemas tornam-se vitais para os administradores e arquitetos do sistema VoIP.

3.1 REQUISITOS
A seguir esto relacionados os principais requisitos do Analisador Distribudo de Protocolo SIP. O objetivo apresentar o conjunto de diretivas que auxiliaram o processo de modelagem e desenvolvimento do sistema nas seces 3.2 e 3.3. Nas seco 3.1.1 e 3.1.2 so apresentados os requisitos bsicos dos dois componentes principais da ferramenta: o componente Agente, responsvel pela captura das mensagens SIP em cada elemento do sistema monitorado e subsequente envio dessas informaes para o componente Servidor, responsvel pelo recebimento, processamento e armazenamento e apresentao dessas informaes.

3.1.1 AGENTE
Dependendo da topologia de rede e servidores do sistema monitorado o componente Agente poder estar instalado nas mesmas mquinas onde a aplicao monitorada

41 executada. Sendo assim o componente Agente deve afetar o mnimo possvel o sistema monitorado e falhas deste componente em hiptese alguma podem causar problemas no funcionamento da aplicao. Mecanismos de proteo de uso de recursos da mquina devem ser implementados de forma que o administrador do sistema possa ter controle sobre a quantidade de recursos que sero utilizados pelo componente Agente, fazendo com este interrompa sua execuo imediatamente caso esses limites sejam atingidos. Outra caracterstica importante em sistemas VoIP e que deve guiar a modelagem e implementao do componente Agente a heterogeneidade dos componentes que compem a soluo. comum observar solues em que cada funo lgica do sistema, conforme apresentadas na seco 2.1, realizada por produtos de diferentes fornecedores, comumente rodando em plataformas de hardware e software distintas. Dessa forma o componente de captura de mensagens deve ser independente da plataforma monitorada para possibilitar a monitorao completa do sistema.

3.1.1.1 CAPTURA DE MENSAGENS SIP

Pela natureza distribuda dos sistemas VoIP baseados no protocolo SIP, conforme apresentado no Captulo 2, o componente de captura de mensagens SIP dever prover mecanismos para suportar esse tipo de ambiente, possibilitando a captura simultnea e independente em sistemas lgica ou fisicamente distribudos, ou seja, aplicaes diferentes executando no mesmo hardware ou em hardware diferentes. Para atender essa necessidade o componente Agente deve permitir a instalao em diversas mquinas para capturar as mensagens SIP processadas por estas e ento envi-las para o componente Servidor (ver seco 3.1.1.2). Como cada componente do sistema monitorado pode ter caractersticas diferentes em relao a configuraes de hardware (p.ex. interfaces de rede), protocolo de transporte e portas utilizadas para comunicao, o componente de captura de mensagens deve permitir a parametrizao de tais configuraes em cada instalao, como por exemplo atravs de arquivos de configurao locais.

3.1.1.2 ENVIO DAS INFORMAES PARA O SERVIDOR

O componente Agente no raramente ser instalado em mquinas conectadas a redes diferentes das do componente Servidor, como por exemplo em centros de processamento (data centers) diferentes. Essas redes geralmente possuem sistemas de segurana (firewalls) que restringem determinados tipos de conexo. Para diminuir a necessidade de configuraes de permisso de acesso importante que o componente Agente utilize um protocolo padro para comunicao com o componente Servidor. O

42 protocolo HTTP um forte candidato para essa funo visto que amplamente utilizado e geralmente permitido para conexes originadas de dentro da rede. Em sistemas VoIP de grande porte o nmero de mensagens trocadas pode ser muito elevado, e consequentemente a quantidade de informaes que sero capturadas e enviadas para o servidor pode ser muito grande. Sendo assim importante que o envio seja realizado de forma cautelosa para que o trfego de rede gerado por essa operao no afete o funcionamento do sistema monitorado. Em um cenrio ideal, e principalmente em ambientes com alto trfego, uma rede especfica para monitorao (back-end network) deve ser utilizada para este fim. Mas independente da infra-estrutura de rede disponvel deve-se minimizar a utilizao de recursos de rede, utilizando por exemplo mecanismos de compresso e envio peridico com tamanho limitado de informaes para o servidor.

3.1.2 SERVIDOR
Uma sesso SIP, conforme apresentado na seco 2.2.3, formada por um conjunto de requisies e respostas trocadas entre os participantes da sesso. A observao das mensagens enviadas e recebidas por um nico participante pode no ser suficiente para determinar o comportamento do sistema como um todo durante o processamento da sesso. Sendo assim, necessrio reunir as informaes coletadas isoladamente pelos componentes Agente para ento process-las em conjunto e obter tal viso. O componente Servidor exerce exatamente esse papel no Analisador Distribudo de Protocolo SIP. O componente Servidor responsvel pelo recebimento, armazenamento, processamento e apresentao das informaes coletadas, fornecendo uma interface nica e centralizada para visualizao dessas informaes. A escolha natural para implementao dessa interface a de utilizar uma aplicao Web acessvel atravs de um navegador de Internet padro (browser), de forma a dispensar a necessidade de instalao e manuteno de programas clientes na estao de cada usurio que utiliza o sistema. Alm da interface para o usurio final o sistema dever disponibilizar as informaes armazenadas atravs de Servios Web (Web Services), para possibilitar a integrao com sistemas externos, como por exemplo ferramentas de monitorao e administrao do sistema VoIP monitorado.

43

3.2 MODELAGEM
Conforme apresentado na seco 3.1, o Analisador Distribudo de Protocolo SIP foi dividido em dois componentes principais, Agente e Servidor. A Tabela 1 apresenta as responsabilidades de cada um desses componentes e respectivas seces em que so discutidas em detalhes. Cada responsabilidade mapeia diretamente um subcomponente do componente principal, servindo de referncia para a definio dos mdulos da ferramenta durante sua implementao, discutida na seco 3.3.

Tabela 1: Componentes e responsabilidades do Analisador Distribudo de Protocolo SIP.

Componente Item 3.2.1 Agente 3.2.2 3.2.3 3.2.4 3.2.5 Servidor 3.2.6.3 3.2.6.4 Responsabilidades / Subcomponentes Captura de pacotes de rede Interpretao de mensagens SIP Extrao das informaes relevantes para a monitorao das sesses SIP Envio das mensagens para o servidor Recebimento das mensagens enviadas pelo Agente Processamento das mensagens conforme a lgica do protocolo SIP Apresentao das informaes armazenadas atravs de interface Web para o usurio final Apresentao das informaes armazenadas atravs de Servios Web para a integrao com sistemas externos

3.2.1 CAPTURA DE PACOTES DA REDE

A tarefa de capturar pacotes de rede est diretamente ligada ao subsistema de rede do sistema operacional e consequentemente requer implementaes nativas especficas para cada sistema. Sendo assim precisamos de uma camada de abstrao para o subcomponente de captura de pacotes de forma que este esteja desacoplado da implementao subjacente. O diagrama de classes UML (BOOCH et al., 1998) a seguir modela as interfaces dessa camada de abstrao. Os argumentos e valores de retorno dos mtodos, assim como seus tipos, so omitidos nos diagramas para facilitar sua leitura e so apresentados com mais detalhes na seco 3.3. A interface CaptureSession apresentada na Figura 6 representa uma sesso de captura de pacotes ativa no Agente. Seus mtodos devem prover as operaes de configurao e controle da sesso. Os mtodos foram definidos baseados na interface da

44 biblioteca LIBPCAP, amplamente utilizada para o desenvolvimento de ferramentas de monitorao de rede, como o tcpdump (STEVENS, 1994), e disponvel para a maioria dos sistemas operacionais modernos.

Figura 6: Diagrama de classes do subcomponente de captura de pacotes

Uma sesso de captura possui um CaptureListener, responsvel por processar cada pacotes que capturado atravs de seu mtodo onPacket(). Por fim temos a classe
CaptureManager, que basicamente define um mtodo para criao de sesses de captura,

implementando o padro Factory Method (Mtodo Fbrica) (GAMMA, 1995), alm de mtodos para adicionar, recuperar e remover sesses do controle do gerenciador. O diagrama de sequncia da Figura 7 mostra a iterao entre as classes que compem o componente de captura de pacotes.

45

Figura 7: Diagrama de sequncia das classes do componente de captura de pacoters

A classe Cliente na Figura 7 representa uma classe que utiliza os servios disponibilizados por essa camada.

3.2.2 INTERPRETAO DE MENSAGENS SIP

Durante o processo de interpretao de mensagens, ou parsing, as mensagens SIP so extradas dos pacotes UDP capturados na interface de rede e os objetos que as representam no domnio da aplicao so criados, contendo apenas os dados necessrios para o funcionamento do Analisador. A interpretao das mensagens realizado atravs do Factory Method (Mtodo Fbrica) createMessage() da classe SIPFactory, cujo diagrama de classe apresentado na Figura 8.

Figura 8: Diagrama de classe SIPFactory

46 O mtodo createMessage() recebe o contedo original da mensagem SIP, representada por um array de bytes extrado da campo de dados da mensagem UDP ou TCP, e retorna um objeto do tipo SIPRequest ou SIPResponse, que por sua vez herdam da classe abstrata SIPMessage. A Figura 9 apresenta o diagrama de classes das classes envolvidas na representao das mensagens SIP e seus respectivos atributos.

Figura 9: Diagrama de classes SIPMessage, SIPRequest e SIPResponse

A classe SIPSession apresentada nesta ilustrao sem atributos pois ser discutida em detalhes na seco 3.2.5. A Tabela 2 descreve os atributos e a origem dos dados da classe SIPMessage.

Tabela 2: Descrio e origem dos dados dos atributos da classe SIPMessage.

Atributo callID Descrio Origem

Identificador nico de um grupo de Contedo do cabealho Call-ID da mensagens que pertencem a uma mesma mensagem SIP, conforme definido na seco transao e/ou dilogo. 20.8 da RFC 3261 (ROSEMBERG et al., 2001). Endereo de origem da mensagem. Endereo de origem do pacote UDP ou TCP.

srcAddress

47
Atributo srcPort dstAddress dstPort requestAddr Descrio Porta de origem da mensagem. Endereo de destino da mensagem. Porta de destino da mensagem. URI da requisio SIP, chamada de Request-URI ou RURI. Identifica o usurio ou servio para o qual a requisio endereada. Identificador mensagem. lgico do originador Origem Porta de origem do pacote UDP ou TCP. Endereo de destino do pacote UDP ou TCP. Porta de destino do pacote UDP ou TCP. Poro Request-URI da Linha de Requisio, ou Request-Line, da mensagem, conforme definido na seco 7.1 da RFC 3261 (ROSEMBERG et al., 2001).

fromUser

da Poro URI do cabealho From da mensagem, conforme definido na seco 8.1.1.3 da RFC 3261 (ROSEMBERG et al., 2001).

toUser

Identificador lgico do destinatrio da Poro URI do cabealho To da mensagem, mensagem. conforme definido na seco 8.1.1.2 da RFC 3261 (ROSEMBERG et al., 2001). Representao textual do originador da Poro Display-Name do cabealho From da mensagem, para leitura por humanos. mensagem, conforme definido na seco 8.1.1.3 da RFC 3261 (ROSEMBERG et al., 2001). Representao textual do destinatrio da Poro Display-Name do cabealho To da mensagem, para leitura por humanos. mensagem, conforme definido na seco 8.1.1.2 da RFC 3261 (ROSEMBERG et al., 2001). Limite do nmero de servidores Cabealho Max-Forwards da mensagem, intermedirios pelos quais a mensagem conforme definido no tem 8.1.1.6 da RFC pode passar. No contexto do Analisador 3261 (ROSEMBERG et al., 2001). esse campo serve para identificar se um pacote foi capturado em duplicidade por Agentes diferentes. Data e hora em que a mensagem foi Data e hora em que o pacote UDP ou TCP capturada. foi capturado na interface de rede. Sesso SIP da qual a mensagem pertence. Discutido em mais detalhes na seco Erro: Origem da referncia no encontrado.

fromDisplay

toDisplay

maxForwards

time sipSession

A Tabela 3 descreve os atributos e a origem dos dados da classe SIPMessage.

Tabela 3: Descrio e origem dos dados dos atributos da classe SIPResponse.

Atributo statusCode Descrio Origem

Cdigo de Estado, conforme descrito na Poro Status-Code (Cdigo de Estado) da seco 2.2.1.2. Status-Line (Linha de Estado), conforme definido na seco 7.2 da RFC 3261 (ROSEMBERG et al., 2001). Razo textual do cdigo de estado, Poro Reason-Phrase (Razo Textual) da conforme descrito na seco 2.2.1.2. Status-Line, conforme definido no tem 7.2 da RFC 3261 (ROSEMBERG et al., 2001). Mtodo da requisio que originou a transao, utilizada como contexto para identificar o tipo de transao durante o processamento da resposta. Poro Method do cabealho CSeq da mensagem de resposta, conforme definido na seco 8.1.1.5 da RFC 3261 (ROSEMBERG et al., 2001).

reasonPhrase

relatedMethod

48 A Tabela 4 descreve os atributos e a origem dos dados da classe SIPMessage.

Tabela 4: Descrio e origem dos dados dos atributos da classe SIPRequest.

Atributo method Descrio Mtodo da requisio, descrito na seco 2.2.1.1. Origem conforme Poro Method da Request-Line (Linha de Requisio), conforme definido na seco 7.1 da RFC 3261 (ROSEMBERG et al., 2001).

3.2.3 ENVIO DAS INFORMAES PARA O SERVIDOR

Aps a captura e interpretao das mensagens SIP necessrio envi-las para o servidor para serem processadas e armazenadas, como veremos na seco 3.2.5. Conforme o requisito descrito na seco 3.1.1.2, esse envio dever ser realizado utilizando o protocolo HTTP para evitar a necessidade de configuraes adicionais nos equipamentos de segurana (firewall) da rede onde o Agente estiver instalado. Porm, para diminuir o acoplamento (LARMAN, 2004) entre o servio de envio de mensagens e os detalhes de comunicao em rede fornecida uma interface de alto nvel que abstrai esses detalhes das classes que a utilizam. Essa interface apresentada no diagrama de classe da Figura 10.

Figura 10: Diagrama de classes do componente de envio de mensagens

A interface Sender define dois mtodos send() atravs de sobrecarga de mtodo (SINTES, 2002), um que recebe como parmetro uma nica mensagem e outro que recebe uma lista de mensagens a serem enviadas para o servidor. Os mtodos start() e stop() controlam o incio e pausa de envio de mensagens para o servidor.

49 A classe HTTPSender implementa a interface Sender e utiliza a classe HTTPClient para o envio de mensagens HTTP contendo as mensagens SIP para o servidor. A classe
HTTPClient responsvel por todos os detalhes de comunicao atravs do protocolo

HTTP, incluindo autenticao, configurao e utilizao de HTTP proxy, dentre outros. A obteno de uma instncia de Sender ocorre atravs da fbrica abstrata (GAMMA, 1994) SenderFactory que fornece o mtodo createSender() conforme apresentado no diagrama de classes da Figura 11.

Figura 11: Diagrama de classes da fbrica abstrata SenderFactory

A classe concreta HTTPSenderFactory fornece uma implementao do mtodo

createSender() para criao de uma instncia de HTTPSender. O cliente, conforme a

definio de fbrica abstrata (GAMMA, 1994), s tem acesso s interfaces SenderFactory e Sender, ficando assim completamente desacoplado a implementao subjacente. Para atender os requisitos definidos na seco 3.1.1.2, a implementao da classe HTTPSender deve fornecer os mecanismos necessrios para o envio peridico e a compactao dos dados transmitidos. Tais mecanismos, porm, devem permanecer transparentes para os usurios da classe HTTPSender de forma que seu mtodo send() possa funcionar com ou sem os recursos de envio peridico e compactao sem a necessidade de alterao de cdigo, permitindo a alterao do comportamento atravs de parmetros de configurao do Agente.

3.2.4 RECEBIMENTO DAS MENSAGENS ENVIADAS PELO AGENTE

O requisito de envio de informaes para o servidor, descrito na seco 3.1.1.2, implica que o recebimento das mensagens no lado servidor ser realizado atravs do

50 protocolo HTTP. Dessa forma o componente servidor utilizar um servidor HTTP para tratar as requisies e extrair as informaes das mensagens SIP capturadas e enviadas pelo Agente. Porm, da mesma forma que o Agente utiliza uma interface de servio genrica para o envio de mensagens, conforme definido na seco 3.2.3, no lado servidor definiremos as interfaces de servio para recebimento das mensagens independente dos detalhes de comunicao em rede atravs do protocolo HTTP, que sero tratados na fase de implementao na seco 3.3. O servio de recebimento de mensagens representado pela classe

MessageService. Essa classe define dois mtodos processMessage(), um que recebe um

nico objeto SIPMessage e outro que recebe uma lista de mensagens a serem processadas, conforme apresentado na Figura 12.

Figura 12: Diagrama de classes do servio MessageService

A classe MessageService utiliza uma instncia da classe SIPMessageManager para persistir as mensagens recebidas atravs dos mtodos save() disponibilizados por essa classe. Esse modelo caracteriza a classe MessageService como uma implementao do padro Business Delegate (ALUR, 2001), enquanto que a classe SIPMessageManager implementa a camada de negcio referente ao processamento de mensagens SIP. O servio de recebimento de mensagens responsvel apenas pelo processamento das requisies de envio de mensagens realizadas pelos Agentes. Esse processamento se limita a verificao da integridade e validade das mensagens SIP, assim como o armazenamento destas para processamento posterior, conforme definido na seco 3.2.5.

3.2.5 PROCESSAMENTO DAS MENSAGENS ARMAZENADAS

Conforme descrito na seco 3.2.4 as mensagens recebidas dos Agentes so armazenadas para serem processadas posteriormente. A separao do recebimento e processamento das mensagens em duas fases devido a natureza distribuda do protocolo SIP. Conforme definido na seco Erro: Origem da referncia no encontrado, existiro

51 diversos componente Agente instalados em mquinas diferentes capturando e enviando, de forma paralela e independente, informaes sobre as mensagens SIP processadas naquela mquina ou conjunto de mquinas monitoradas por cada Agente. Em um ambiente distribudo e paralelo como este previsvel que mensagens pertencentes a uma mesma transao ou dilogo SIP sejam capturadas por Agentes diferentes e consequentemente enviadas para o servidor em momentos diferentes, pois no prevemos a implementao de um sistema de sincronizao entre os Agentes de forma que as mensagens capturadas sejam enviadas para o servidor de forma ordenada em relao a sua ocorrncia dentro da transao ou dilogo SIP. Um sistema de sincronizao como este demandaria comunicao direta entre todos os Agentes e uma grande complexidade neste componente para o processamento das mensagens de forma ordenada. Como o componente Servidor utilizado como um centralizador das informaes capturadas este foi utilizado para realizar essa sincronizao de forma mais simples. Basicamente o processamento das mensagens no servidor ocorrer periodicamente em um intervalo pr-definido conforme descrito na seco 3.2.5.1. Ser recuperada uma lista das mensagens armazenadas ordenadas pelo atributo time (ver a Tabela 2), e ento essa lista de mensagens processada linearmente. Como pr-requisitos para esta soluo os Agentes devem ter seus relgios sincronizados de forma que o horrio associado s mensagens (atributo time na Tabela 2) reflitam a ordem global em que foram capturadas nas mquinas correspondentes, e que o atributo time dos objetos SIPMessage sejam armazenados no mesmo fuso-horrio ou que este possa ser recuperado durante o processamento. O requisito de sincronizao de horrio entre os Agentes pode ser obtido atravs da utilizao do protocolo NTP, definido na RFC 1305 (MILLS, 1992), nas mquinas onde os Agentes so executados. A Figura 13 ilustra a utilizao dessa soluo.

Figura 13: Utilizao do protocolo NTP.

52

3.2.5.1 PROCESSAMENTO PERIDICO DAS MENSAGENS

O processamento da lista de mensagens armazenadas e no processadas, caracterizadas por no terem um valor associado ao atributo sipSession (ver descrio do atributo na Tabela 2), ser realizado pela classe SIPHandler, que recupera a lista de mensagens atravs do mtodo getPendingMessageList() da classe SIPMessageManager. Todas as mensagens que pertencem a uma mesma transao ou dilogo SIP sero agrupadas atravs de um objeto do tipo SIPSession, que representa uma transao ou dilogo SIP dentro da aplicao. Cada mensagem processada pelo SIPHandler ser associada a uma sesso existente ou a uma nova sesso, caso a mensagem seja uma requisio que inicia esta sesso. A classe SIPHandler utiliza a classe de negcio SIPSessionManager para recuperar e manipular objetos do tipo SIPSession. O mtodo findByCallID() desta classe recupera uma sesso a partir de um identificador da chamada, que pode ser recuperado atravs do atributo callID de cada objeto SIPMessage. O mtodo save() persiste as alteraes ou cria um novo objeto SIPSession passado como argumento. A Figura 14 apresenta o diagrama de classes das classes SIPHandler, SIPMessageManager e SIPSessionManager utilizadas para o processamento das mensagens.

Figura 14: Diagrama de classes da classe SIPHandler

Os mtodo run() da classe SIPHandler executa o lao principal do processamento da lista de mensagens pendentes. Cada mensagem da lista passada como parmetro para o mtodo
processMessage(),

que

por

sua

vez

utilizar

os

mtodos

processRequest() ou processResponse() conforme o tipo de mensagem. Esses mtodos

executam a lgica do protocolo SIP e manipulam o estado do objeto SIPSession associado a transao conforme as mensagens so processadas. O diagrama de classe e respectivos atributos da classe SIPSession so apresentados na Figura 15.

53

Figura 15: Diagrama de classes da classe SIPSession

A descrio e a origem dos dados dos atributos da classe SIPSession so relacionadas na Tabela 5. O diagrama de classes completo da classe SIPMessage foi apresentado na Figura 9 e seus atributos relacionados na Tabela 2 da seco 3.2.1.

Tabela 5: Descrio e origem dos dados dos atributos da classe SIPSession.

Atributo startTime Descrio Origem dos dados

Data em que a sesso SIP foi criada. Atributo time do objeto SIPRequest que Corresponde a data da requisio que originou a sesso. originou a sesso. Data em que a sesso SIP foi finalizada. Corresponde a data da ltima resposta final (ver seco 2.2.1.2) processada para a sesso. Atributo time do objeto SIPResponse representando a ltima resposta final recebida dentro da transao ou dilogo SIP.

endTime

firstResponseTime

Data da primeira mensagem de Atributo time do objeto SIPResponse provisionamento ou intermediria (ver representando a primeira mensagem de seco 2.2.1.2) processada na sesso. provisionamento dentro da transao ou dilogo SIP. Data da requisio de desconexo da Atributo time do objeto SIPRequest cujo sesso. atributo method igual a BYE ou CANCEL que finaliza a transao ou dilogo SIP. Data da mensagem de resposta final 200 Atributo time do objeto SIPResponse OK recebida referente uma requisio representando a resposta 200 OK em INVITE, indicando o estabelecimento resposta a uma requisio do tipo INVITE. com sucesso da sesso SIP. Data da mensagem de resposta de Atributo time do objeto SIPResponse provisionamento 180 Ringing recebida representando a resposta 180 Ringing em indicando que o usurio de destino foi resposta a uma requisio do tipo INVITE. alertado em relao a requisio de estabelecimento da sesso SIP. Estado atual da sesso SIP representado Define a mquina de estados da sesso por um dos valores da enumerao SIP definida na seco 3.2.5.2. atribudo SIPSessionState. durante o processamento das mensagens da sesso conforme a lgica do protocolo SIP. Identificador nico da sesso. Atributo callID do objeto SIPRequest que

disconnectionStart

establishedTime

setupTime

state

callID

54
originou a sesso. requestMethod messages Mtodo da requisio que originou a Atributo method do objeto SIPRequest que sesso. originou a sesso. Lista de mensagens pertencentes a A lista populada durante o sesso. processamento das mensagens pela classe SIPHandler.

3.2.5.2 MQUINA DE ESTADOS DA SESSO SIP

O atributo state da classe SIPSession, definido na Tabela 5, representa o estado atual da sesso e representado por um dos valores da enumerao SIPSessionState. So definidos oito estados possveis que uma sesso pode assumir durante o processamento das mensagens:

INITIATED Estado inicial da sesso ao ser criada durante o processamento da primeira requisio.

PROVISIONED Resposta de provisionamento recebida, aguardando resposta final.

ESTABLISHED Sesso estabelecida com sucesso atravs do recebimento de uma resposta final 200 OK. Aplica-se apenas a requisies do tipo INVITE.

DISCONNECTING Sesso est em processo de finalizao atravs de uma requisio do tipo BYE.

COMPLETED Para sesses do tipo INVITE indica que a sesso foi finalizada normalmente atravs de uma requisio BYE confirmada com resposta 200 OK. Para os demais tipos de sesses indica que a requisio foi atendida com sucesso.

FAILED Resposta final de erro recebida. Indica que a requisio no pde ser atendida.

TIMEOUT Tempo de espera por reposta final esgotado (timeout) e a requisio no pde ser atendida. O tempo de espera para cada tipo de requisio definido na seco 17.1 da RFC 3261 (ROSEMBERG et al., 2002).

CANCELED Requisio cancelada atravs de requisio do tipo CANCEL.

O estado de cada sesso ser atribudo e alterado durante o processamento das mensagens no mtodo run() da classe SIPHandler.

55

3.2.5.3 PROCESSAMENTO DE MENSAGENS FORA DE ORDEM

O mecanismo de armazenamento e ps-processamento descrito anteriormente diminui mas no elimina a possibilidade de processamento fora de ordem das mensagens capturadas e enviadas pelos Agentes. Ao menos duas razes so previstas onde esta situao pode se configurar: Agentes configurados com perodos de envio de mensagens diferentes e falhas na comunicao entre os Agentes e o Servidor. No primeiro caso dois Agentes podem capturar mensagens pertencentes a uma mesma transao, por exemplo no caso de Agentes instalados em sistemas e/ou mquinas diferentes que participam do processamento de uma requisio. Se estes Agentes estiverem configurados para enviar as mensagens periodicamente, conforme descrito na seco 3.2.3, o envio poder ocorrer em momentos diferentes e serem intercalados por um ciclo de execuo do mtodo run() da classe SIPHandler. No segundo caso uma falha na comunicao entre um Agente e o Servidor adiar o envio das mensagens e consequentemente causar o mesmo efeito. Em ambos os casos, no prximo ciclo de execuo do mtodo run() da classe SIPHandler, havero mensagens no processadas que pertencem a uma sesso existente, criada durante o ciclo de execuo anterior, mas cujo estado pode ser alterado devido ao processamento das novas mensagens. Na ocorrncia deste senrio todas as mensagens, ou seja, aquelas j associadas associadas a sesso existentes assim como as novas mensagens, devero ser agrupadas, reordenadas pelo atributo time e reprocessadas, de forma que o estado do objeto
SIPSession reflita o processamento de todas as mensagens capturadas envolvidas na

transao ou dilogo SIP.

3.2.6 APRESENTAO DAS INFORMAES PROCESSADAS

Aps serem processadas, conforme descrito na seco 3.2.5, as informaes estaro disponveis para consulta atravs da interface Web para o usurio final, seco 3.2.6.3, ou atravs dos Servios Web (Web Services) para integrao com sistemas externos conforme a seco 3.2.6.4. Porm, antes de entrar em detalhes da Interface e dos Servios Web, sero apresentados os dois principais servios disponibilizados atravs dessas interfaces: Diagrama de Sequncia de Sinalizao SIP, seco 3.2.6.1, e Mtricas de Performance das Sesses SIP, seco 3.2.6.2. Estes servios estaro disponveis somente para sesses que j foram processadas conforme descrito na seco 3.2.5.1, consequentemente sua disponibilidade estar sujeita a atrasos conforme a periodicidade no qual este processamento ser realizado.

56

3.2.6.1 DIAGRAMA DE SEQUNCIA DE SINALIZAO SIP

Na seco 2.3 apresentamos um exemplo do Diagrama de Sequncia de Sinalizao SIP como uma forma de representar graficamente a troca de mensagens SIP entre as entidades envolvidas numa sesso SIP. Tal representao utilizada principalmente para a investigao de problemas no estabelecimento e controle de sesses, fornecendo informaes detalhadas de uma sesso ou conjunto de sesses SIP. A Tabela 6 relaciona as informaes que sero disponibilizadas atravs do Diagrama de Sequncia de Sinalizao SIP.

Tabela 6: Informaes apresentadas no Diagrama de Sequncia de Sinalizao SIP

Informao Participantes Descrio Endereo de cada participante da sesso SIP, apresentados como rtulos das linhas verticais do diagrama de sequncia. O endereo pode ser o endereo IP ou nome (hostname) do participante. Cada mensagem SIP trocada entre os participantes presentada como uma seta horizontal no diagrama. A origem da seta est conectada linha vertical que representa ao originador da mensagem, e a extremidade oposta da seta, para onde ela aponta, est conectada a linha vertical que representa o destinatrio da mensagem. No diagrama de sequncia cada mensagem est associada a um delta em relao ao incio da sesso (data da requisio que originou a sesso), ou seja, a diferena de tempo entre a primeira mensagem e a mensagem em questo. Quando mais de uma sesso for apresentada em uma mesmo diagrama essas devero ser claramente diferenciadas. Uma prtica comum a utilizao de cor de fundo diferentes para cada sesso.

Mensagens

Delta da Mensagem

Sesses

A Figura 16 mostra um exemplo de Diagrama de Sequncia de Sinalizao SIP obtido atravs da ferramenta Wireshark (WIRESHARK), um analisador de protocolos de propsito geral livre e de cdigo-fonte aberto, licenciado sob a GNU General Public Licence verso 2 (FSF, 1991).

57

Figura 16: Diagrama de sequncia de sinalizao SIP da ferramenta Wireshark.

No exemplo da Figura 16 podemos observar todas as informaes relacionadas na Tabela 6, inclusive a utilizao de cores de fundo diferentes para cada sesso SIP. A ferramenta Wireshark disponibiliza esse tipo de diagrama apenas para requisies do tipo INVITE para chamadas de voz e vdeo. O Analisador Distribudo de Protocolo SIP por sua vez deve disponibilizar essa visualizao para quaisquer tipo de sesso. A criao de diagramas de sequncia de sinalizao SIP realizada atravs do da classe SIPScenario, cujo diagrama de classe apresentado na Figura 17.

Figura 17: Diagrama de classe da classe SIPScenario.

O mtodo create() recebe um objeto do tipo OutputStream no qual o contedo binrio da imagem ser escrito, e uma lista de mensagens utilizada para a criao do

58 diagrama. Espera-se que a lista de mensagens esteja ordenada pelo atributo time dos objetos SIPMessage, pois as mensagens sero desenhadas no diagrama na ordem em que aparecem na lista.

3.2.6.2 MTRICAS DE PERFORMANCE DE SESSES SIP

Na seco 2.4 foram descritas as mtricas de performance para conexes ponto-aponto utilizando o protocolo SIP. A classe SIPPerformanceMetrics fornece os mtodos para o clculo dessas mtricas a partir das informaes processadas pelo Analisador Distribudo de Protocolo SIP, cujo diagrama de classe apresentado na Figura 18.

Figura 18: Diagrama de classe da classe SIPPerformanceMetrics.

Cada um dos mtodo da classe de servio SIPPerformanceMetrics corresponde a uma mtrica definida na seco 2.4, conforme relacionado na Tabela 7.

Tabela 7: Mtodos da classe SIPPerformanceMetrics e mtricas relacionadas.

Mtodo getRegistrationRequestDelay getIneffectiveRegistrationAttempts getSessionRequestDelay getSessionDisconnectDelay getSessionDurationTime getHopsPerRequest getSessionEstablishmentRatio getSessionEstablishmentEffectivenessRatio Seo/Mtrica 2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.4.6 2.4.7 2.4.8

59
getSessionDefectsRatio getIneffectiveSessionAttempts getSessionDisconnectFailures getSessionCompletionRatio getSessionSucessRatio 2.4.9 2.4.10 2.4.11 2.4.12 2.4.13

Algumas mtricas apresentadas na seco 2.4 possuem subitens que diferem apenas no conjuntos de sesses consideradas para o clculo desse item. Nesses casos o mesmo mtodo que calcula a mtrica principal deve ser utilizado porm sobre uma lista de sesses previamente filtradas para refletir o subconjunto desejado. Por exemplo, a mtrica definida na seco 2.4.12 define dois subitens para sesses completadas com sucesso e com falha, assim basta fornecer uma lista de sesses para o mtodo
getSessionCompletionRatio() cujos atributos status dos objetos SIPSession reflitam

cada um desses conjuntos para obter tais mtricas. Tais conjuntos de sesses, assim como outros conjuntos filtrados por endereo de origem e/ou destino, perodo, mtodo das requisies entre outros, podem ser obtidos atravs dos mtodos disponibilizados pela classe de servio SIPSessionManager, apresentada sesses. na seco 3.2.5, e ento submetidos aos mtodos da classe
SIPPerformanceMetrics para se obter as mtricas de performance destes conjuntos de

3.2.6.3 INTERFACE WEB PARA O USURIO FINAL

Em ltima instncia os dados coletados pelos Agentes e processados no Servidor sero exibidos atravs de uma interface Web centralizada para o usurio final. Atravs dessa interface o usurio ser capaz de consultar as sesses processadas para ento visualizar seus diagramas de sequncia de sinalizao SIP ou obter informaes sobre suas mtricas de performance, conforme definido nas seces 3.2.6.1 e 3.2.6.2. O alvo dessas consultas basicamente so objetos do tipo SIPSession. No caso dos diagrama de sequncia de sinalizao SIP, geralmente o usurio ir consultar e selecionar um pequeno conjunto de sesses correlacionadas para visualizar seu diagrama. J no caso das mtricas de performance a busca de sesses em geral deve ocorrer em termos de endereos e nome de usurios de origem e destino, perodos, entre outros, afim de agrupar as sesses no pela sua correlao, mas sim para restringir a busca a um determinado ambiente de instalao, cliente ou tipo de dispositivos e/ou aplicao, como gateways, proxies, URAs (Unidade de Resposta Audvel) entre outros.

60 Sendo objetos SIPSession os alvos dessas consultas, podemos definir os parmetros de busca com base nos atributos presentes nesse tipo de objeto, assim como os atributos da classe SIPMessage e derivadas, que possuem uma relao de agregao com a classe SIPSession e consequentemente podem ser utilizadas para restringir a busca. Com base nos diagramas de classes apresentados nas Figuras 9 e 15, das sees 3.2.2 e 3.2.5.1 consecutivamente, podemos definir os parmetros de busca atravs da interface Web conforme a relao apresentada na Tabela 8.

Tabela 8: Parmetros de busca de sesses SIP atravs da interface Web.

Parmetro Data de incio da sesso Data de trmino da sesso Mtodo da requisio Identificador da sesso Cdigo de resposta SIP Descrio Define o incio do intervalo. Atributo startTime do objeto SIPSession. Define fim do intervalo. Atributo endTime do objeto SIPSession. Mtodo da requisio inicial. Atributo method do objeto SIPSession. Cabealho Call-ID da requisio inicial da sesso. Atributo callID do objeto SIPSession. Cdigo numrico da mensagem SIP de resposta presente na sesso. Atributo responseCode do objeto SIPRespose associado a um objeto SIPSession. Cabealho From da requisio inicial da sesso. Atributo fromUser de um objeto SIPMessage associado a um objeto SIPSession. Cabealho To de qualquer requisio que faa parte da sesso. A utilizao de qualquer requisio e no s a primeira necessria pois o usurio de destino de uma sesso pode ser alterado durante o seu processamento, por exemplo um usurio com desvio configurado. Atributo toUser de um objeto SIPRequest associado a um objeto SIPSession. Endereo IP de origem de qualquer requisio que faa parte da sesso. Atributo srcAddress de um objeto SIPMessage que esteja associado a um objeto SIPSession. Porta de origem do pacote UDP ou TCP de qualquer requisio que faa parte da sesso. Atributo srcPort de um objeto SIPMessage que esteja associado a um objeto SIPSession. Endereo IP de destino de qualquer requisio que faa parte da sesso. Atributo dstAddress de um objeto SIPMessage que esteja associado a um objeto SIPSession. Porta de destino do pacote UDP ou TCP de qualquer requisio que faa parte da sesso. Atributo srcPort de um objeto SIPMessage que esteja associado a um objeto SIPSession. Reflete a situao da sesso, conforme definido na seco 3.2.5.2. Atributo state do objeto SIPSession.

Usurio de origem Usurio de destino

Endereo IP de origem

Porta de origem

Endereo IP de destino

Porta de destino

Estado da sesso

Para os pares de parmetros Usurio de origem e destino, e Endereo IP e Porta de origem e destino, a interface dever prover uma opo de seleo do operador lgico E ou OU para relacion-los, afim de fornecer ao usurio a capacidade de refinar a busca de sesses atravs da origem E destino, ou ento origem OU destino desses parmetros. A Figura 19 ilustra um formulrio de busca contendo os parmetros de busca

61 relacionados na Tabela 8, neste exemplo utilizamos o campo Endereo IP para ambos os parmetros Endereo IP e Porta de origem e destino, podendo utilizar o formato endereo:porta em cada um dos campos.

Figura 19: Exemplo de formulrio de busca de sesses SIP atravs da interface Web.

Ao pressionar o boto Buscar Sesses ser exibida uma lista de sesses que casam com os parmetros de busca selecionados pelo usurio. O boto Exibir Mtricas de Performance do formulrio da Figura 19 exibe as mtricas de performance das sesses que casam os parmetros de busca sem exibir uma listagem, pois o resultado desse tipo de consulta pode conter um nmero muito grande de sesses, e seria inconveniente para o usurio ter que selecion-las manualmente. Porm se o usurio desejar visualizar a listagem antes de obter as mtricas de performance ele poder utilizar o boto Buscar Sesses para testar os parmetros de busca e ento utilizar o boto Exibir Mtricas de Performance exibido no final da listagem, conforme exemplo apresentado na Figura 20.

62

Figura 20: Exemplo de listagem da busca de sesses atravs da interface Web.

A primeira coluna da listagem de exemplo apresentada na Figura 20 possui botes de seleo para cada linha de resultado. O usurio utiliza esses botes para selecionar um subconjunto de sesses desse resultado para ento disparar uma das opes de visualizao atravs dos botes Exibir Diagrama de Sequncia ou Exibir Mtricas de Performance. A busca de sesses realizada atravs do mtodo find() da classe de servio SIPSessionManager. Esse mtodo recebe os parmetros relacionados na Tabela 8 como parmetros de entrada representados por um objeto do tipo SIPSessionFindParams, e retorna uma lista de sesses. A Figura 21 apresenta o diagrama de classe completo da classe SIPSessionManager e da SIPSessionFindParams.

Figura 21: Diagrama de classe SIPSessionManager e SIPSessionFindParams.

Para obteno do diagrama de sequncia de sinalizao SIP e das mtricas de performance, a lista de sesses selecionadas utilizada como parmetro para os mtodos das classes SIPScenarios e SIPPerformanceMetrics.

63

3.2.6.4 SERVIOS WEB PARA INTEGRAO COM SISTEMAS EXTERNOS

Alm da interface Web para os usurios finais, apresentada na seco 3.2.6.3, o Analisador Distribudo de Protocolo SIP prov acesso s informaes processadas e aos servios de diagrama de sinalizao SIP e mtricas de performance atravs de servios Web, com o objetivo de permitir a utilizao dessas informaes em sistemas externos. Os servios Web foram desenvolvidos utilizando a arquitetura REST (Representational State Transfer) (FIELDING, 2000) e a Tabela 9 apresenta os recursos e respectivos identificadores disponibilizados pelo Analisador Distribudo de Protocolo SIP. A coluna Recurso descreve os recursos e fornece informaes sobre como os dados associados so obtidos utilizando as classes de servio do sistema.

Tabela 9: Recursos e respectivos identificadores oferecidos pelos servios Web.

Identificador /sipsessions/ Recurso Lista de sesses filtrada atravs dos parmetros de busca relacionados na Tabela 8. Utiliza o mtodo find(SIPSessionFindParams) da classe SIPSessionManager para realizar a busca de sesses. Sesso especfica identificada atravs do parmetro sessionID, um nmero inteiro correspondente ao atributo id do objeto SIPSession. Utiliza o mtodo find(Long) da classe SIPSessionManager. Mensagem especfica identifica pelo parmetro messageID, um nmero inteiro correspondente ao atributo id do objeto SIPMessage. Utiliza o mtodo find(Long) da classe SIPMessageManager. Lista de mensagens pertencentes a sesso identificada pelo parmetro de caminho sessionIdList, uma linha de texto contendo os identificadores numricos das sesses (atributo id do objeto SIPSession) separados por vrgula. Utiliza o mtodo findBySessionID(List<Long> sessionIdList) da classe de servio SIPMessageManager. Mtricas de performance SIP, apresentadas na seco 2.4, de um conjunto de sesses definido pelos parmetros parmetros de busca relacionados na Tabela 8. O mtodo find(SIPSessionFindParams) da classe SIPSessionManager utilizado para buscar as sesses que so utilizadas como parmetros para os mtodos da classe SIPPerformanceMetrics para obter as mtricas de performance.

/sipsessions/{sessionID}

/sipmessages/{messageID}

/sipmessages/session/{sessionIdList}

/sipmetrics/

Os recursos relacionados na Tabela 9 produzem uma representao no formato XML (Extensible Markup Language) dos dados obtidos que so ento retornadas ao cliente.

64

3.3 IMPLEMENTAO
O Analisador Distribudo de Protocolo SIP foi desenvolvido como software livre e de cdigo-fonte aberto sob a licena GPL. O projeto recebeu o nome Sipana1 e mantido no servio de hospedagem de projetos Google Code2. O trabalho foi desenvolvido na linguagem de programao Java, utilizando a plataforma Java SE (Java Standard Edition) verso 6 para o componente Agente e a plataforma Java EE (Java Enterprise Edition) verso 5 para o componente Servidor. A implementao Java EE escolhida foi o servidor de aplicaes JBoss3 verso 4.2.3. O sistema Maven4 foi utilizado para gerenciamento do projeto, fornecendo mecanismos para controle de dependncias, automatizao dos processos de compilao, empacotamento e testes, e gerenciamento de configurao dos artefatos binrios. O projeto foi dividido nos sete mdulos relacionados na Tabela 10, onde tambm fornecida uma breve descrio de cada mdulo e a seco correspondente onde so apresentados os detalhes da implementao.

Tabela 10: Mdulos do Analisador Distribudo de Protocolo SIP.

Mdulo sipana-agent sipana-commons Descrio Seces

Implementao do componente Agente, cujo as funcionalidades foram 3.3.1 descritas nas seces 3.2.1, 3.2.2 e 3.2.3. Implementao das classes utilizadas em ambos nos Agente e 3.3.1.2 e 3.3.2.1 Servidor, contm as classes responsveis pela criao e representao de mensagens SIP. Mdulo auxiliar para empacotamento do componente Servidor para 3.3.2 instalao no servidor de aplicaes Java EE. Implementao das classes de servio e persistncia de dados, 3.3.2.1 utilizando a tecnologia EJB3 (Enterprise Java Beans verso e). Implementao da interface Web do componente Servidor utilizando a 3.3.2.2 tecnologia JSF (Java Server Faces). Implementao dos Servios Web do componente Servidor utilizando a 3.3.2.3 tecnologia JAX-RS (Java API for RESTful Services). Implementao da biblioteca para criao de diagramas de sequncia 3.3.2.4 de sinalizao SIP.

sipana-server-ear sipana-server-ejb sipana-server-war sipana-server-ws sipana-sipscenario

1 2 3 4

http://sipana.googlecode.com/ http://code.google.com/hosting http://www.jboss.org/ http://maven.apache.org/

65

3.3.1 AGENTE
O componente Agente foi desenvolvido como uma aplicao Java SE atravs do mdulo sipana-agent. As seces 3.2.1, 3.2.2 e 3.2.3 definiram, de forma independente de implementao, as interfaces dos subcomponentes funcionais desse mdulo, porm essa modelagem no inclui detalhes de como tais subcomponentes so integrados durante sua execuo. Nesta seco so apresentados os detalhes dessa integrao e nas subsees 3.3.1.1, 3.3.1.2 e 3.3.1.3 so apresentados os detalhes da implementao de cada subcomponente. A classe org.sipana.agent.SipanaAgent do mdulo sipana-agent o ponto inicial de execuo do componente Agente, ela responsvel pela criao e configurao dos objetos necessrios para o funcionamento do componente. A criao dos objetos realizada atravs de mtodos fbrica (GAMMA, 1995) da classe org.sipana.agent.service.
ServiceLocator, que implementa o padro de Service Locator (Localizador de Servios)

(ALUR, 2001) e o padro Singleton (GAMMA, 1995). A Figura 22 apresenta o diagrama de classes dessas classes assim como os tipos cujas instncias so obtidas atravs da classe
ServiceLocator.

Figura 22: Diagrama de classes SipanaAgent e ServiceLocator.

O mtodo start() da classe SipanaAgent obtm as instncias e configura as classes de servio (listadas do lado esquerdo da Figura 22), j o mtodo stop() utiliza essas instncias para parar os servios durante a finalizao do Agente.

66 A classe org.sipana.agent.sip.SIPHandler responsvel pela intermediao entre a captura de pacotes, realizada atravs de uma instncia da classe CaptureSession, a interpretao dos pacotes e criao das mensagens, utilizando a classe SIPFactory, e finalmente o envio dessas para o componente servidor, realizado atravs de uma implementao da interface Sender, neste caso a classe HTTPSender. A Figura 23 apresenta um diagrama de sequncia que ilustra a iterao entre essas classes durante o processamento de uma mensagem.

Figura 23: Diagrama de sequncia da classe SIPHandler do componente Agente.

O diagrama de sequncia da Figura 23 complementar ao diagrama apresentado na Figura 7 da seco 3.2.1. Aqui temos a classe SIPHandler implementando a interface
CaptureListener e recebendo os pacotes capturados atravs de mensagens onPacket().

A instncia da classe CaptureSession obtida atravs do mtodo fbrica (GAMMA, 1995)

createCaptureSession() da classe de servio CaptureManager, e configurada durante a

inicializao do Agente pela classe SipanaAgent. As configuraes utilizadas no componente Agente so obtidas atravs da classe
org.sipana.agent.config.ConfigManager,

que

implementa

padro

Singleton

(GAMMA, 1995) e fornece um ponto nico de acesso s configuraes. As configuraes so carregadas a partir do arquivo sipana-agent.properties, localizado no diretrio conf da instalao do componente Agente. Neste arquivo so definidos os parmetros de configurao da captura de pacotes, envio envio de mensagens, endereo do servidor, entre outros. Esta classe utilizada em todas as classes de servio do componente Agente e sua instncia obtida atravs do mtodo fbrica (GAMMA, 1995) getInstance() da classe
ConfigManager.

As subsesses a seguir fornecem informaes sobre a bibliotecas externas e detalhes de implementao dos subcomponentes do componente Agente do Analisador Distribudo de Protocolo SIP.

67

3.3.1.1 CAPTURA DE PACOTES DA REDE

O subcomponente de captura de mensagens, definido na seco 3.2.1, foi desenvolvido utilizando a biblioteca Jpcap5 para realizar a interface com as bibliotecas nativas de captura de pacotes de rede. A biblioteca Jpcap atualmente testada e distribuda para os sistemas operacionais Linux, FreeBSD, Solaris, Microsoft Windows e Mac OS X, possibilitando a instalao do componente Agente nesses sistemas sem a necessidade de alteraes do cdigo-fonte ou configuraes especiais. As classes CaptureSessionJpcap e CaptureManagerImpl do pacote Java
org.sipana.agent.capture.impl

implementam

as

interfaces

CaptureSession

CaptureManager, apresentadas no diagrama de classes da Figura 6 na seco 3.2.1,

encapsulando a utilizao da biblioteca Jpcap.

3.3.1.2 INTERPRETAO DAS MENSAGENS SIP

Para realizar a interpretao de mensagens SIP (parsing) foi utilizada a biblioteca JAIN-SIP6, uma implementao de referencia da especificao JSR (Java Specification Request) nmero 32 da JCP (Java Community Process), que define a interface de programao para o protocolo SIP na linguagem de programao Java. A utilizao dessa biblioteca encapsulada na classe org.sipana.protocol.sip.SIPFactory do mdulo
sipana-commons, cujo diagrama de classe foi apresentado na Figura 8 na seco 3.2.2. As

classes SIPMessage e derivadas, utilizadas para representao das mensagens SIP foram implementadas no pacote Java org.sipana.protocol.sip do mdulo sipana-commons.

3.3.1.3 ENVIO DAS INFORMAES PARA O SERVIDOR

O subcomponente de envio de mensagens do componente Agente, modelado na seco 3.1.1.2, foi implementado utilizando o arcabouo cliente da biblioteca JBoss RESTeasy7. Esta biblioteca, conforme apresentada na seco 3.3.2.3, implementa a especificao JAX-RS do JCP, que define um padro para implementao de servios REST (FIELDING, 2000) na linguagem de programao Java. O arcabouo cliente fornecido por essa biblioteca no faz parte da especificao JAX-RS, mas utiliza as mesmos mecanismos definidos por ela para a implementao de classes cliente que consumiro os servios implementados do lado servidor. Esse recurso facilita a implementao do componente cliente do servio pois uma nica biblioteca precisa ser utilizada tando no lado cliente como
5 6 7 Biblioteca Jpcap: http://netresearch.ics.uci.edu/kfujii/jpcap/doc/ Biblioteca NIST JAIN-SIP: https://jain-sip.dev.java.net/ Biblioteca JBoss RESTeasy: http://www.jboss.org/resteasy/

68 servidor. A utilizao da biblioteca RESTeasy foi encapsulada na classe

org.sipana.agent.sender.http.HTTPSender do mdulo sipana-agent que implementa a

interface Sender, conforme apresentado no diagrama de classes da Figura 10 da seco 3.2.3. No foi necessria a implementao de uma classe HTTPClient para tratar dos detalhes de comunicao atravs do protocolo HTTP, como sugere o diagrama de classes da Figura 10, pois o arcabouo cliente da biblioteca JBoss RESTeasy encapsula a biblioteca Apache HttpClient8 que realiza exatamente essa funo.

3.3.2 SERVIDOR
O componente Servidor do Analisador Distribudo de Protocolo SIP foi implementado com uma aplicao Java EE e composto pelos mdulos sipana-server-ear, sipana-serverejb, sipana-server-war e sipana-server-ws, responsveis pelo empacotamento do componente Servidor em um servidor de aplicaes Java EE (Java EE Container), implementao das classes de servio e persistncia de dados, interface Web para o usurio final, e Servios Web para integrao com sistemas externos, consecutivamente. A tecnologia Java EE foi especificada para ser independente em relao aos de fornecedores de implementao da plataforma (Container). Porm existem detalhes de instalao das aplicaes, realizadas atravs de arquivos de configurao, que no so definidas na especificao e consequentemente so especficas para cada fornecedor. A implementao do componente Servidor do Analisador Distribudo de Protocolo SIP foi realizada utilizando o servidor de aplicao JBoss Application Server9 verso 4.2.3.GA. As subsees 3.3.2.1, 3.3.2.2, 3.3.2.3 e 3.3.2.4 apresentam os detalhes de implementao de cada um dos subcomponentes, assim como as tecnologias e bibliotecas utilizadas.

3.3.2.1 CLASSES DE SERVIO E PERSISTNCIA DE DADOS

As classes de servio do componente Servidor foram implementadas no mdulo sipana-server-ejb como classes do tipo Stateless Session Beans, definidas pela tecnologia EJB10 (Enterprise JavaBeans) verso 3.
8 9 Biblioteca Apache HttpClient: http://hc.apache.org/httpclient-3.x/ Plataforma Java EE JBoss Application Server: http://www.jboss.org/jbossas/

10 Tecnologia EJB: http://java.sun.com/products/ejb/

69 A Tabela 11 apresenta uma listagem relacionando as interfaces de servio fornecidas pelo componente Servidor, definidas nas subseces da seco 3.2, com as respectivas implementaes utilizando a tecnologia EJB e uma breve descrio das funcionalidades oferecidas por essas classes.

Tabela 11: Interfaces de servio e respectiva implementaes EJB3.

Interface de Servio Classe de Implementao Descrio Responsvel pelo processamento das mensagens enviadas pelos Agentes atravs dos Servios Web (seco 3.3.2.3). Utiliza as classe de negcio SIPSessionManager para armazenar as mensagens recebidas. Implementa a camada de negcios referente ao processamento de mensagens SIP, fornecendo mtodos para o armazenamento das mensagens de forma persistente no componente Servidor, assim como mtodos para obteno e manipulao desses objetos. Fornece servios para o clculo das mtricas de performance ponto-a-ponto do protocolo SIP definidas na seco 2.4. Implementa a camada de negcios referente ao processamento de sesses SIP, fornecendo mtodos para o armazenamento das sesses de forma persistente no componente Servidor, assim como mtodos para obteno e manipulao desses objetos. utilizada pela classe de servio SIPHandler para o processamento agendado de mensagens armazenadas (ver seco 3.2.5.1)

MessageService

MessageServiceBean

SIPMessageManager

SIPMessageManagerBean

SIPPerformanceMetrics

SIPPerformanceMetricsBean

SIPSessionManager

SIPSessionManagerBean

As interfaces de servio apresentadas na Tabela 11 foram implementadas no pacote

org.sipana.server.ejb, enquanto que as classes de implementao desses servios

pertencem ao pacote org.sipana.server.ejb.impl do mdulo sipana-server-ejb.

3.3.2.2 INTERFACE WEB

A interface Web para os usurios finais do Analisador Distribudo de Protocolo SIP foi desenvolvida utilizando o arcabouo de desenvolvimento de aplicaes Web do lado servidor JSF11 (Java Server Faces), definida na especificao JSR 31412 da JCP. A implementao da interface Web faz parte do mdulo sipana-server-war. Basicamente a interface fornece trs visualizaes para o usurio: busca e listagem de sesses SIP baseadas nos parmetros de busca definidos na Tabela 8 da seco
11 Java Server Faces: http://java.sun.com/javaee/javaserverfaces/ 12 JSR 314: http://www.jcp.org/en/jsr/detail?id=314

70 3.2.6.3, visualizao do diagrama de sequncia, modelado na seco 3.2.6.1, e a visualizao das mtricas de performance do protocolo SIP de um conjunto de sesses SIP, conforme apresentado na seco 3.2.6.2. A Tabela 12 apresenta os recursos envolvidos na implementao dessas visualizaes. As classes Java e pginas JSP referenciadas na coluna Recurso esto armazenadas no diretrio de cdigo-fonte do mdulo sipana-serverwar.

Tabela 12: Recursos envolvidos nas visualizaes fornecidas pela interface Web.
Visualizao Recurso SIPSessionController Busca e Listagem de Sesses sipsession/list.jsp SIPScenarioController Diagrama de sequncia sipsession/details.jsp Descrio do recurso Front Controller (ALUR, 2001) para a busca e listagem de sesses SIP. Formulrio de busca e visualizao da listagem de sesses SIP. Front Controller (ALUR, 2001) para visualizao de diagrama de sequncia de sinalizao SIP. Visualizao do diagrama de sequncia de sinalizao SIP. Front Controller (ALUR, 2001) para visualizao das mtricas de performance de um conjunto de sesses SIP. Visualizao das mtricas de performance de um conjunto de sesses SIP.

SIPMetricsController Mtricas de performance sipmetrics/show.jsp

Na sesso 3.4 so apresentados os testes realizados em cada uma das visualizaes apresentados na Tabela 12.

3.3.2.3 SERVIOS WEB

Os Servios Web do Analisador Distribudo e Protocolo SIP foram desenvolvidos utilizando o padro REST (FIELDING, 2000) para servios Web. A biblioteca JBoss RESTeasy, apresentada na seco 3.3.1.3, foi utilizada na implementao desse servios e est contida no mdulo sipana-server-ws. Alm de fornecer os recursos necessrios para integrao com sistemas externos, conforme discutido na seco 3.2.6.4, os servios Web tambm foram utilizados para o recebimento das informaes enviadas pelos componentes Agente, trabalhando em conjunto com a classe de servio MessageService apresentada na seco 3.2.4 e implementada no mdulo sipana-server-ejb (ver seco 3.3.2.1). A Tabela 13 relaciona os recursos apresentados na Tabela 9 da seco 3.2.6.4 mais

71 os recursos para o recebimento das informaes enviadas pelos Agentes, com os mtodos HTTP utilizados para cada recurso e as respectivas classes do mdulo sipana-server-ws envolvidas no seu processamento, implementadas no pacote Java org.sipana.server.ws.

Tabela 13: Identificadores, mtodos HTTP e implementao dos servios Web.

Identificador /sipsessions/ /sipsessions/{sessionID} /sipmessages/{messageID} /sipmessages/session/{sessionIdList} /sipmessages/ /sipmetrics/ Mtodo HTTP Implementao GET GET GET GET PUT GET Mtodo getSessionList() da classe SIPSessionWS. Mtodo getSession() da classe SIPSessionWS. Mtodo getMessage() da classe SIPMessageWS. Mtodo getMessageList() da classe SIPMessageWS. Mtodo saveMessageList() da classe SIPMessageWS. Mtodo getMetrics() da classe SIPMetricsWS.

Os mtodos das classes associadas aos recursos apresentados na Tabela 13, retornam ou recebem como parmetros objetos ou listas de objetos do domnio da aplicao, que precisam ser transformados de objetos Java para o formato XML, ou o contrrio para recursos com mtodo HTTP PUT. A biblioteca RESTeasy fornece mecanismos automticos para realizar essa transformao para classes cujos os mtodos e/ou atributos estejam anotados com as anotaes fornecidas pela biblioteca JAXB (Java Architecture for XML Binding). Sendo assim, as classes POJO (Plain Old Java Object) do mdulo sipanacommons utilizadas para representao de dados do domnio da aplicao foram devidamente anotadas dessa forma para fazer uso dos recursos de codificao e decodificao XML/Objeto oferecidos pelas bibliotecas RESTeasy e JAXB.

3.3.2.4 DIAGRAMA DE SEQUNCIA DE SINALIZAO SIP

A criao de diagramas de sequncia de sinalizao SIP foi implementada atravs da classe org.sipana.sip.SIPScenario no mdulo sipana-sipscenario. Esta classe faz uso dos recursos do pacote javax.imageio para criao de imagens binrias para representao da sinalizao SIP.

72

3.4 TESTES
Nesta seco so apresentados os testes executados com a implementao do Analisador Distribudo de Protocolo SIP realizada neste trabalho, assim como detalhes do ambiente e ferramentas utilizadas. O objetivo no fornecer um conjunto exaustivo de testes funcionais e no-funcionais, mas mostrar a ferramenta em funcionamento em um ambiente controlado. Para simular um sistema VoIP baseado no protocolo SIP foram utilizados o servidor Kamailio13 para intermediar as mensagens trocadas atravs atravs da ferramenta de testes SIPp14, capaz de gerar requisies e respostas a partir de cenrios criados de forma declarativa utilizando arquivos XML e que realizou os papeis de UAC e UAS durante os testes. A Figura 24 ilustra a disposio desses componentes.

Figura 24: Componentes do ambiente de testes.

O componente Agente foi instalado e configurado para capturar as mensagens SIP processadas pelo servidor Kamailio, que ento so enviadas para o componente servidor atravs dos servios Web utilizando requisies HTTP. A ferramenta SIPp disponibiliza um cenrio padro para testes utilizando requisies SIP do tipo INVITE, tanto para o UAC, que gera as requisies, quanto para o UAS, que as reponde. Por questes de facilidade de configurao e para possibilitar que os testes pudessem ser executados durante a fase de desenvolvimento, todos os componentes do ambiente de teste apresentado na Figura 24 foram instalados e configurados em um mesmo computador, utilizando portas UDP diferentes para cada processo: SIPp UAC na porta 5070, SIPp UAS na porta 5080, e o servidor Kamailio utilizando a porta 5060.
13 Kamailio SIP Proxy: http://kamailio.org/ 14 SIPp SIP protocol traffic generator: http://sipp.sourceforge.net/

73 Aps gerar algumas requisies no ambiente de teste possvel utilizar a interface Web da ferramenta para realizar uma busca das sesses. A Figura 25 apresenta a tela do formulrio de busca com parte do resultado aps a execuo do teste.

Figura 25: Formulrio de busca de sesses na Interface Web.

Ao selecionar uma ou mais sesses na lista de resultados e pressionar o boto Details (Detalhes) exibido o diagrama de sequncia da sinalizao SIP, conforme apresentado na Figura 26.

Figura 26: Diagrama de sequncia de sinalizao SIP na interface Web.

74 possvel realizar as mesmas operaes de busca e detalhamento de sesses apresentados nas Figura 25 e 26 atravs dos servios Web disponibilizados pelo Analisador Distribudo de Protocolo SIP. Para ilustrar essa funcionalidades a Figura 27 exibe uma busca realizada atravs dos servios Web que retornam os mesmo resultados da busca atravs da interface Web, utilizando os parmetros de data inicial e final, mtodo da requisio SIP e endereo IP de origem ou destino.

Figura 27: Exemplo de acesso aos servios Web utilizando um navegador.

A Figura 28 apresenta o diagrama de sequncia criado a partir dos servios Web.

Figura 28: Criao de diagrama de sinalizao SIP atravs dos servios Web.

A criao de diagramas de sequncia atravs dos servios Web permite incorporalos em stios Web e aplicaes externas.

75

4 CONCLUSES E TRABALHOS FUTUROS

Sistemas VoIP baseados no protocolo SIP, principalmente quando implementados sobre uma infraestrutura catica como a Internet, precisam lidar com diversos desafios para garantir a qualidade e disponibilidade dos servios. Os problemas passam por perda de pacotes e atrasos de entrega at sistemas cujo funcionamento degradam lentamente e tornam sua identificao muito difcil sem a ajuda de ferramentas apropriadas. O Analisador Distribudo de Protocolo SIP desenvolvido nesse trabalho fornece uma ferramenta que pode ajudar administradores e arquitetos de sistema VoIP a investigar problemas desse tipo e obter informaes valiosas sobre o comportamento de seus sistemas rapidamente, contribuindo para a tomada de decises que podem evitar problemas maiores para seus usurios. Neste trabalho foram desenvolvidos dois componentes principais para realizar a coleta e processamento dos dados relacionados a sinalizao SIP em sistemas VoIP. O componente Agente responsvel pela captura de pacotes de redes, interpretao das mensagens SIP e o envio dessas para o componente Servidor, podendo ser instalado em diversos pontos da rede possibilitando uma viso mais completa da sinalizao. O componente Servidor recebe as informaes enviadas pelos Agentes, as processa para extrair as informaes de sinalizao e mtricas de performance, e as armazena para consulta atravs da interface e servios Web. A maior vantagem da arquitetura distribuda do Analisador Distribudo de Protocolo SIP que no h necessidade de processos manuais para coleta, transferncia e processamento das informaes, como o caso da ferramenta de anlise de protocolos Wireshark. Alm disso com o armazenamento das informaes coletadas e a implementao do clculo das mtricas de performance SIP definidas no trabalho SIP Endto-End Performance Metrics (MALLAS, 2009) possibilitam analisar o comportamento do sistema de forma histrica, o que no est disponvel nas ferramentas de monitorao SIP oferecidas atualmente. A implementao realizada nesse trabalho completamente funcional e est disponvel atravs de um projeto de software livre e cdigo-fonte aberto hospedado na encubadora de projetos Google Code atravs do nome Sipana. Esse modelo de desenvolvimento possibilita que o projeto continue sendo desenvolvido ou sirva de referncia para estudantes e profissionais de computao interessados na rea de monitorao de sistemas VoIP, ou apenas na infraestrutura distribuda implementada que serve como base para novas ferramentas de monitorao para outros tipos de sistemas e protocolos.

76 A interface Web implementada neste trabalho muito simples e serve basicamente como prova de conceito da ferramenta. necessrio melhor-la para atender as necessidades dos usurios de forma adequada. A parte visual e de usabilidade devem ser revistas para oferecer recursos como um sistema de paginao dos resultados de busca de sesses, pois em sistemas reais a quantidade de informaes coletadas pode ser muito grande, e tambm uma forma de armazenar perfis de busca que possam ser reutilizados atravs da interface, facilitando consultas recorrentes. Ainda em relao apresentao das informaes armazenadas, necessrio implementar a visualizao das mtricas de performance, pois o clculo dessas mtricas foram implementos mas no a sua consulta atravs interface e dos servios Web. Outro ponto importante a ser desenvolvido a partir desse trabalho est relacionado a segurana. Na implementao atual no h controle de acesso s informaes, tando atravs da Interface Web quanto nos servios Web, incluindo o servio de recebimento das informaes enviadas a partir dos Agentes. A implementao desses recursos de segurana tornariam o sistema mais confivel e passvel de ser instalado em sistemas onde no h proteo de acesso implementados na camada de rede, como por exemplo atravs de firewalls.

77

REFERNCIAS BIBLIOGRFICAS

ALUR, Deepak; CRUPI, John; MALKS, Dan. Core J2EE Patterns: Best Practices and Design Strategies. Person Education, 2001. BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. The Unified Modeling Language User Guide. Addison-Wesley, 1998. CAMPBELL, Ben, et al. RFC 3428 Session Initiation Protocol (SIP) Extension for Instant Messaging. 2002. Disponvel em: <http://tools.ietf.org/html/rfc3428>. Acessado em: 08 mai. 2009. DAVIDSON, Jonathan; et al. Voice Over IP Fundamentals: A Systematic Approach to Understending the Basics of Voice over IP, Second Edition. Cisco Press, 2007. EGEVANG, Kjeld; FRANCIS, Paul. RFC1631 - The IP Network Address Translator (NAT). 1994. Disponvel em: <http://tools.ietf.org/html/rfc1631>. Acessado em: 14 Abr. 2009. FIELDING, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000. GAMMA, Erich; HELM, Richard; JOHNSON, Ralph; VLISSIDES, John. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. HANDLEY, Mark; JACOBSON, Van. RFC 2327 SDP: Session Description Protocol. 1998. Disponvel em: <http://tools.ietf.org/html/rfc2327>. Acessado em: 29 Nov. 2009. IETF. Inernet-Drafts. Disponvel em: <http://www.ietf.org/ID.html>. Acessado em: 03 Mar. 2009. IETF. Performance Metrics for Other Layers. Disponvel <http://www.ietf.org/html.charters/pmol-charter.html>. Acessado em: 16 Mai. 2009. em

LARMAN, Craig. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. Prentice Hall PTR, 2004. MALAS, Daryl. SIP End-to-End Performance Metrics. 2008. Disponvel <http://tools.ietf.org/html/draft-ietf-pmol-sip-perf-metrics>. Acessado em: 02 mar. 2009. em:

MILLS, David L. RFC 1305 Network Time Protocol (Version 3) Specification, Implementation and Analysis. 1992. Disponvel em: <http://tools.ietf.org/html/rfc1305>. Acessado em: 10 Mai. 2009. RESNIK, Peter W. RFC 2822 Internet Message Format. 2001. Disponvel em: <http://tools.ietf.org/html/rfc2822>. Acessado em: 29 Nov. 2008. ROACH, Adam. RFC 3265 Session Initiation Protocol (SIP)-Specific Event Notification. 2002. Disponvel em: <http://tools.ietf.org/html/rfc3428>. Acessado em: 08 mai. 2009. ROSENBERG, Jonathan, et al. RFC 3261 SIP: Session Initiation Protocol. 2001. Disponvel em: <http://tools.ietf.org/html/rfc3261>. Acessado em: 29 nov. 2008.

78 SCHULZRINNE, Henning; et al. RFC 3550 RTP: A Transport Protocol for Real-Time Applications. 2003. Disponvel em: <http://tools.ietf.org/html/rfc3550>. Acessado em: 29 Nov. 2009. SCHULZRINNE, H.; ORAN, D.; CAMARILLO, G. RFC 3326 The Reason Header Field for the Session Initiation Protocol (SIP). 2002. Disponvel em: <http://tools.ietf.org/html/rfc3326>. Acessado em: 17 Mai. 2009. SINTES, Anthony. Object Oriented Programming in 21 Days. Sams Publishing, 2002. STEVENS, W. Richard. TCP/IP Illustrated: the protocols. Addison-Wesley, 1994. TANENBAUM, Andrew S. Computer Networks. Prentice Hall, 2003. VARSHNEY, Upkar; et al. Voice Over IP. The Communications of ACM Volume 45, 2002.