UNIVERSIDADE CATLICA DE GOIS DEPARTAMENTO DE COMPUTAO GRADUAO EM CINCIA DA COMPUTAO

VOZ SOBRE IP SEGURANA DE TRANSMISSES

GUILHERME VOLTAN JNIOR

DEZEMBRO 2005
1

UNIVERSIDADE CATLICA DE GOIS DEPARTAMENTO DE COMPUTAO GRADUAO EM CINCIA DA COMPUTAO

VOZ SOBRE IP SEGURANA DE TRANSMISSES

Trabalho de Projeto Final de Curso apresentado por Guilherme Voltan Jnior Universidade Catlica de Gois, como requisito parcial para obteno do ttulo de Bacharel em Cincia da Computao aprovado em 22/06/2005 pela Banca Examinadora: Professor Cludio Martins Garcia, MsC. UCG Orientador

VOZ SOBRE IP SEGURANA DE TRANSMISSES

GUILHERME VOLTAN JNIOR

Trabalho de Projeto Final de Curso apresentado por Guilherme Voltan Jnior Universidade Catlica de Gois, como parte dos requisitos para obteno do ttulo de Bacharel em Cincia da Computao.

________________________________ Professor Cludio Martins Garcia, MsC Orientador

_________________________________ Professor Jos Luiz de Freitas Jnior, Dr. Coordenador de Projeto Final de Curso

Ao Professor Cludio Martins Garcia, orientador acadmico e amigo, pelo apoio e confiana depositada. Aos meus verdadeiros amigos pelo apoio e compreenso. A minha famlia goiana, pelo incentivo e a todos os que fizeram parte da minha vida, pois sem essas pessoas seria muito mais difcil sobreviver longe do manto protetor dos pais e irmo. 4

 Deus pela sua sabia orientao e por me ajudar a destacar em meio ao seu rebanho, ao Santo Expedito que em momentos difceis me amparou, a Nossa Senhora Aparecida que em vrios momentos sorriu para apoiar minha querida mame e as lgrimas de felicidades e saudades despejadas pelos meus familiares.

RESUMO

Transmisses de voz sobre IP tiveram seus primeiros estudos nos anos setenta e de l para c vem apresentando grandiosos ndices de melhoria. Hoje VoIP conhecida mundialmente, pela sua economia em ligaes telefnicas, que so fceis de serem realizadas, precisa-se apenas de um terminal com acesso a rede mundial de computadores. As vantagens so inmeras e as desvantagens, claro existem, porm minimizadas, hoje o que mais afeta a VoIP a sua qualidade de servio, porm isso para usurios que contam com uma largura de banda relativamente boa torna-se um tanto quanto imperceptvel, porm existem outros problemas relativos a QoS que tambm afetam, como o caso do congestionamento, segurana e confiabilidade. Apesar de vrias desvantagens estarem presentes na VoIP, ela apresenta a cada dia que passa um numero maior de adeptos e um crescimento tecnolgico muito maior, o que pode levar as redes de telefonia tradicionais extino, j que a VoIP alm de prestar todos os servios prestados pela telefonia tradicional ainda tem a capacidade de oferecer muito mais servios, porm devemos levar em considerao que o maior alvo da VoIP, as redes tradicionais, tambm so seu maior concorrente e isto se deve sua alta disponibilidade e a sua viabilidade. Muitos estudos e protocolos fazem e fizeram da VoIP o que ela hoje, e podemos citar parte dessa histria atravs de vrios componentes, entre eles, os protocolos de sinalizao H.323 e o revolucionrio SIP que parece estar tomando frente junto s transmisses VoIP, o grandioso protocolo de transporte RTP que usado praticamente em todas as operaes de transmisses de voz, graas sua qualidade na entrega de pacotes, e o RTCP que atua juntamente ao RTP provendo controle, entre vrios outros, e por causa de todo este apanhado histrico e pela vontade sobre a descoberta de novos meios de comunicao que a VoIP poder em breve ser marco da histria mundial.

ABSTRACT

Transmissions of voice about IP had their first studies in the Seventies and since then they have presented huge indices of improvement. Today VoIP is known world-wide for its economy in telephone calls, that are easy to be carried through, its used only a terminal with access to the world-wide net of computers. disadvantages, however minimized, today what The advantages are innumerable and the affects more the VoIP is its quality of

service, however for some users who count on a width of relatively good band becomes imperceptible , nevertheless there are other problems related to the QoS that also affect it, such as the case of congestion, security and trustworthiness. Despite of some disadvantages presented in the VoIP, it presents each day a great number users and a very big technological growth, and due to this can jeopardize the telephone companies besides the VoIP has all the services done for the traditional telephone companies, still has the capacity to offer much more services, furthermore we must take in consideration that the target of the VoIP, the traditional companies are one of the strongest competitors because of their high availability and reliability. Many studies and protocols have helped the VoIP becomes what it is today, and we can explain part of this history through some components, such as, the protocols of H.323 transmissions and revolutionary SIP which is better together with VoIP transmissions, the huge protocol of transport RTP that has been practically used in all the operations of voice transmissions, thanks to its quality in the delivery of packages, and the RTCP that works together with the RTP providing, control and several others, and its because of all this historical background and for the discovery of new medias that the VoIP will be able to become the landmark of worldwide history.

Sumrio

REDES DE TRANSMISSO DE VOZ SOBRE IP ............................................................. 15 HISTRIA DO SURGIMENTO DAS REDES VOIP ...................................................... 15 LIGAO TELEFNICA ATRAVS DE REDES IP .................................................... 17 VANTAGENS DA TRANSMISSO DE VOZ SOBRE IP.............................................. 17 ARQUITETURA DAS REDES VOIP ............................................................................. 18 SERVIOS DA REDE VOIP .......................................................................................... 19 OBSTCULOS PARA CONSOLIDAO DA REDE VOIP ......................................... 20 PROTOCOLOS DE SINALIZAO .................................................................................. 20 H.323............................................................................................................................... 21 Introduo Histrica ..................................................................................................... 21 Componentes da Recomendao H.323........................................................................ 22 Recomendao H.323 para a Arquitetura Protocolar do H.323 ..................................... 24 Vantagens em se utilizar H.323 .................................................................................... 27 Chamada H.323............................................................................................................ 28 SIP ................................................................................................................................... 33 Introduo.................................................................................................................... 33 Caractersticas .............................................................................................................. 34 Arquitetura do SIP........................................................................................................ 34 Mensagens SIP............................................................................................................. 36 Chamadas SIP .............................................................................................................. 42 COMPARAO ENTRE H.323 E SIP............................................................................ 45 PROTOCOLO SDP ......................................................................................................... 46 PROTOCOLOS ENTRE GATEWAYS DE MDIA E CONTROLADORES DE MDIA 47 MGCP.............................................................................................................................. 47 Comandos MGCP ........................................................................................................ 50 MEGACO........................................................................................................................ 50 Comandos MEGACO................................................................................................... 51 COMPARAO ENTRE MGCP E MEGACO ............................................................... 51 PROTOCOLO RTP ............................................................................................................. 52 FUNCIONALIDADES DO RTP...................................................................................... 53 PACOTE RTP ................................................................................................................. 53 SESSO RTP .................................................................................................................. 55 QUALIDADE DE SERVIO .............................................................................................. 56 MODELO BSICO DE QoS ........................................................................................... 56 CONGESTIONAMENTO ............................................................................................... 57 Fifo .............................................................................................................................. 57 Fair Queueing............................................................................................................... 58 Priority Queueing......................................................................................................... 60 Custom Queueing......................................................................................................... 61 Comparao entre os Mtodos de Enfileiramento ......................................................... 63 Deteco RED e WRED............................................................................................... 63 PROTOCOLO RTCP....................................................................................................... 64 Funcionalidade do RTCP.............................................................................................. 64 Pacote RTCP................................................................................................................ 65 PROTOCOLO CRTP (Compressed Real-Time Protocol)................................................. 66 PROTOCOLO IEEE 802.1p priority queueing................................................................. 67 8

PROTOCOLO RSVP....................................................................................................... 68 Mensagens RSVP......................................................................................................... 70 PARMETROS QUE INFLUENCIAM NA QoS DA TECNOLOGIA VoIP................... 71 Atraso .......................................................................................................................... 71 Eco............................................................................................................................... 74 Sobreposio do Locutor.............................................................................................. 74 Jitter............................................................................................................................. 74 Perda de Pacotes........................................................................................................... 75 SOLUES PARA GARANTIA DE QoS EM REDES IP .............................................. 75 Dejitter Buffer .............................................................................................................. 76 Classificar ou Identificar o Trfego .............................................................................. 76 Enfileiramento, Priorizao e Disciplina de Despacho .................................................. 77 SEGURANA EM REDES VOZ SOBRE IP ...................................................................... 78 Introduo........................................................................................................................ 78 Ameaas .......................................................................................................................... 79 Captura de trfego e acesso indevido a informaes ..................................................... 79 Cdigo Malicioso ......................................................................................................... 80 Fraude Financeira, Uso indevido de recursos corporativos............................................ 81 Repdio........................................................................................................................ 81 Meios de proteo ............................................................................................................ 82 Segmentar o trfego de voz e dados.............................................................................. 82 Controlar o acesso ao segmento de voz com um Firewall especializado........................ 83 Evitar o uso de aplicaes de telefones para microcomputadores (PC-Based IP phones), utilizando preferencialmente telefones IP que suportem VLAN.................................... 84 Usar endereos IP privativos e invlidos (compatveis com RFC 1918) nos telefones IP. ..................................................................................................................................... 84 Configurar os telefones IP com endereos IP estticos, associados ao MAC Address ... 85 Utilizar servidores DHCP separados para voz e dados .................................................. 85 Monitorar os endereos MAC no segmento de voz....................................................... 86 Implementar mecanismos que permitam autenticar os usurios dos telefones IP ........... 86 Implementar um sistema IDS ....................................................................................... 86 Fazer o hardening do host onde est instalado o call manager ................................... 87 Monitorar a performance e status dos servios de VoIP ................................................ 88 Montar uma estrutura de Help Desk capacitada para dar suporte em VoIP.................... 88 Restringir o acesso fsico.............................................................................................. 88 Auditar o uso dos recursos............................................................................................ 89 Criptografar o trfego de VoIP ..................................................................................... 89 Concluso .................................................................................................................... 90 Benefcios da Convergncia ............................................................................................. 91 Riscos e Inibidores da convergncia ................................................................................. 92 SPIT em geral .................................................................................................................. 93 1. Origem e significado ................................................................................................ 93 2. Prejuzos causados pelo spit...................................................................................... 93 3. Envio de spit ............................................................................................................ 94 4. SPIT (spam over IP Telephony), abordagem geral .................................................... 94 SEGURANA NOS PROTOCOLOS H.323 E SIP.............................................................. 95 SIP ................................................................................................................................... 95 Segurana na troca de mensagens ................................................................................. 95 Segurana da mdia ...................................................................................................... 96 Firewalls SIP................................................................................................................ 97 H.323............................................................................................................................... 98 SNIFFERS VOIP ................................................................................................................. 99 9

Caractersticas dos Sniffers VoIP ..................................................................................... 99 EXEMPLO DE APLICAO DE SEGURANA EM REDES VOIP............................... 100 Encriptao de VoIP no sistema omnipcx enterprise....................................................... 100 Concluso ...................................................................................................................... 101 Concluses......................................................................................................................... 102 Referncias Bibliogrficas ................................................................................................. 103

10

LISTA DE FIGURAS

Fig. 1.1: Arquitetura de uma rede VoIP....................................................................... Fig. 1.2: Arquitetura Protocolar................................................................................... Fig. 1.3: Componentes do padro H.323..................................................................... Fig. 1.4: Troca de mensagens entre entidades H.323................................................... Fig. 1.5: Arquitetura Protocolar do H.323................................................................... Fig. 1.6: Padro H.323................................................................................................. Fig. 1.7: Fluxo bsico da conexo H.323..................................................................... Fig. 1.8: Negociao de Capacidades H.245............................................................... Fig.1.9: Abrindo canais lgicos................................................................................... Fig. 1.10: Conversao ativa H.323............................................................................. Fig. 1.11: Arquitetura Sip............................................................................................ Fig. 1.12: O formato de mensagem SIP....................................................................... Fig. 1.13: O formato da mensagem de pedido SIP...................................................... Fig. 1.14: O formato da resposta SIP........................................................................... Fig. 1.15: Chamada ponto-a-ponto SIP........................................................................ Fig. 1.16: Finalizao de uma chamada SIP................................................................ Fig. 1.17: Alterao de chamada SIP........................................................................... Fig. 1.18: Resposta busy here.................................................................................... Fig. 1.19: Exemplo da utilizao do SDP numa mensagem SIP................................. Fig. 1.20: Arquitetura MGCP geral............................................................................. Fig. 1.21: Arquitetura do MGCP - Residential Gateways - Soluo Clarent.............. Fig. 1.22: Arquitetura do MGCP Trunking Gateways Soluo MCI..................... Fig. 1.23: Comandos MGCP........................................................................................ Fig. 2.1: Pacote RTP.................................................................................................... Fig. 3.1: Modelo para QoS........................................................................................... Fig. 3.2: Operao da Fila FIFO.................................................................................. Fig. 3.3: Filas Fair Queueing....................................................................................... Fig. 3.4: Operao do Algoritmo WFQ....................................................................... Fig. 3.5: Filas WFQ...................................................................................................... Fig. 3.6: Operao do enfileiramento Priority Queueing............................................ Fig. 3.7: Filas Priority Queuening............................................................................... Fig. 3.8: Operao do enfileiramento Custom Queueing............................................. Fig. 3.9: Filas Custom Queueing.................................................................................. Fig. 3.10: Funcionamento do WRED........................................................................... Fig. 3.11: Protocolo RTCP........................................................................................... Fig. 3.12: Encapsulamento de pacote VoIP................................................................. Fig. 3.13: Protocolo RSVP em Mquinas do Usurio e Roteadores............................ Fig. 3.14: Camada de atuao do Protocolo RSVP...................................................... Fig. 3.15: Transmisso e Recepo de pacotes............................................................ Fig. 3.16: Atraso na formao de pacotes.................................................................... Fig. 3.17: Atraso em cada etapa da transmisso.......................................................... Fig. 3.18: jitter.............................................................................................................

18 21 24 26 27 27 30 31 32 33 36 37 40 43 44 45 45 46 48 49 50 51 51 55 58 59 60 60 61 62 62 63 64 65 67 68 70 71 71 75 75 77

11

LISTA DE TABELAS

Tabela 1.1: As seis categorias de cdigos de status..................................................... Tabela 1.2: Comandos MEGACO............................................................................... Tabela 1.3: comparao entre MGCP e MEGACO..................................................... Tabela 3.1: Mtodos de Enfileiramento....................................................................... Tabela 3.2: Classificao do atraso..............................................................................

42 52 53 64 74

12

LISTA DE ABREVIATURAS

ATM BECN CQ CRTP DE DiffServ DNS DoS FECN FIFO FQ GK GW HTTP IETF IIS IMTC INATEL IP IPsec IPtel ISDN ISI ITU LAN Mbone MC MCU MGCP MMUSIC MP ms PBX PQ PVP QoS RAS RDSI RED RFC RR RSVP RTCP RTP SDES SDP SIP SMTP SP

Asynchronous Transfer Mode Modo de transferncia Assncrono Backward Explicit Congestion Notification Custom Queueing Compressed Real-Time Transport Protocol Discard Eligible Differentiated Services Domain Name System Denial of Service Forward Explicit Congestion Notification First In First Out Fair queuing Gatekeeper Gateway HyperText Transfer Protocol Internet Engineering Task Force Internet Integrated Services International Multimedia Teleconferencing Consortium Instituto Nacional de Telecomunicaes Internet Protocol IP Security IP Telephony Integrated Services Digital Network Information Sciences Institute International Telecommunications Union Local rea Network Multicast Backbone on the Internet Multipoint Controller Multipoint Control Unit Media Gateway Controller Protocol Multiparty Multimedia Session Control Multipoint Processor Milisegundos Private Branch Exchanges Priority Queueing Packet Video Protocol Quality of Service Register, Admission and Status Rede de Servios Digitais Integrada Random Early Detection Request For Comment Receiver Reports Resource Reservation Protocol Real-Time Control Protocol Real-Time Transport Source Descriptions Session Description Protocol Session Initiation Protocol Simple Mail Transfer Protocol Single Space 13

SPIT SR TCP UA UAC UAS UDP UFRJ URI URL USC VoFR VoIP VOMIT WAN WFQ WRED

Spam Over IP Telephony Sender Reports Transmission Control Protocol User Agent User Agent Client User Agent Server User Datagram Protocol Protocolo de Datagrama do Usurio Universidade Federal do Rio de Janeiro Universal Resource Identifier Universal Resource Location University of Southern Califrnia Voice over Frame Relay Voice over IP Voz Sobre IP Voice Over Misconfigured Internet Telephones Wide rea Network Weighted Fair Queueing Weighted Random Early Detection

14

REDES DE TRANSMISSO DE VOZ SOBRE IP

A Telefonia sobre IP (IPtel IP Telephony) tambm designada como Voz sobre IP (VoIP Voice over IP) ou ainda Telefonia sobre Internet (Internet Telephony). A Telefonia sobre IP definida como a comunicao multimdia entre dois ou mais participantes, em outras palavras, significa dizer que uma ligao telefnica realizada atravs da rede IP. Porm o uso comum do termo telefonia IP no deve ser entendido somente como transporte de voz, mas tambm como transporte de outros tipos de meios como vdeo e dados. [sIPtel, p. 23]

HISTRIA DO SURGIMENTO DAS REDES VOIP

1970 Dany Cohen comea os esforos para transportar udio em redes de pacotes. Este relata uma experincia de transmisso de voz em pacotes e em tempo real entre o USC/ISI (University of Southern California/Information Sciences Institute) e o MITs Lincoln Lab.

1977 Surge o primeiro protocolo de internet para transportar voz em pacotes especificado formalmente por Dany Conhen [RFC 741, 1977]

1981 R. Cole prope o Packet Video Protocol (PVP), um protocolo para o transporte de vdeo em pacotes.

1992 - A Internet Engineering Task Force (IETF) realiza a primeira audiocast atravs da Multicast Backbone on the Internet (MBone), a partir de San Diego.

1992 - Henning Schulzrinne comea a desenvolver o Real-Time Transport Protocol (RTP).

15

1992 - aps a primeira difuso de udio, feita pelo IETF, a partir de Boston atravs da Mbone a primeira difuso de udio e vdeo simultaneamente, utilizando as aplicaes vat e DVC respectivamente.

1995 O RTP foi publicado como IETF Proposed Standard.

1995 - Steve McCanne e Van Jacobson desenvolveram a vic, uma aplicao que utiliza o codificador normalizado H.261.

1995 - Surgiu outra aplicao, o CU-SeeMe, que foi dos primeiros prottipos de videoconferncia disponveis na Internet. Inicialmente para MacOs e depois para Windows, este prottipo utilizava um processo responsvel pela distribuio de sinais pelos vrios intervenientes da conferncia.

1996 - publicada pela International Telecommunications Union (ITU) a primeira verso da recomendao H.323 [H.323, 1996].

1996 - prestado pela Delta Three o primeiro servio comercial de Telefonia sobre IP, seguindo-se a Net2phone, iBasis e Telematrix.

1996 A Microsoft lana o seu primeiro sistema de conferncia sobre redes de pacotes. O Microsoft NetMeeting v1.0.

1999 O protocolo SIP foi aceite como norma, pelo IETF como um protocolo de sinalizao para a criao, modificao e finalizao de sesses com um ou mais participantes.

A partir de ento comeou a ocorrer vrias conferncias empresariais [sIPtel, p. 21 a 23]

16

LIGAO TELEFNICA ATRAVS DE REDES IP

Para que ocorra a comunicao multimdia entre dois ou mais participantes ser necessrio haver sinalizao entre eles, de modo que o chamador avise o chamado sobre sua inteno. Esta sinalizao tem como funo a criao, controle e a finalizao de chamadas. Este novo servio permite a troca de pacotes entre dois ou mais participantes atravs da rede, utilizando protocolos da Internet e o intercmbio da informao necessria para controlar essa troca. No chamador a voz capturada por um microfone e o vdeo obtido por uma cmara de vdeo sendo estes sinais geralmente digitalizados. Em seguida so codificados e encapsulados em pacotes que so enviados atravs da rede com a utilizao de protocolos de Internet. Do outro lado, esses pacotes so desencapsulados e decodificados, o sinal digital convertido em sinal analgico e reproduzido em alto-falantes enquanto o vdeo enviado para a tela.

VANTAGENS DA TRANSMISSO DE VOZ SOBRE IP

O que realmente incentiva e impulsiona o desenvolvimento deste tipo de tecnologia so os benefcios que ela traz tanto para as corporaes como para um usurio final. A idia geral da utilidade das transmisses de voz sobre IP para as corporaes ser para integrar as tecnologias de rede em uma s infra-estrutura, ou seja, as corporaes querem integrar a rede de dados com a rede de voz e vdeo. Essa integrao entre estas redes pode trazer vrios benefcios, entre eles esto:

- Reduo de custos: com a transferncia das ligaes telefnicas normais para as ligaes telefnicas VoIP, reduz-se em cerca de 90% os custos com contas telefnicas.

- Oferta de servios: Vrias pessoas se preocupam se com a convergncia para ligaes VoIP, obtero servios como, por exemplo, secretria eletrnica. A resposta SIM e alm destes servios normais, inmeros outros j so oferecidos pelas ligaes VoIP.

17

- Centralizao da gesto destas infra-estruturas: com a integrao de todas essas redes em uma nica rede, fica mais fcil para o responsvel pela infra-estrutura prover uma melhor qualidade de servio, gerir a rede, administrar a rede e etc. A rede agora no ficar mais espalhada por vrios fios e equipamentos, sua integrao permitir sua centralizao, o que traz reduo do uso de equipamentos e etc.

- Arquitetura aberta: sua arquitetura aberta e normalizada. Sua arquitetura possibilita a criao de novos servios.

- Privacidade: permite a autenticao de quem faz a chamada, atravs de uma palavrachave e certificados criptogrficos.

ARQUITETURA DAS REDES VOIP

O que difere as redes VoIP das redes telefnicas tradicionais a arquitetura de comutao. As redes telefnicas tradicionais so redes de comutao de circuitos enquanto a rede VoIP uma rede de comutao de pacotes.

Fig. 1.1: Arquitetura de uma rede VoIP [Inatel] Como visto na figura acima a rede VoIP composta por vrios dispositivos: 18

- Terminais: permitem executar os servios como, por exemplo fazer e receber chamadas. Os terminais so dispositivos inteligentes, pois possuem total controle sobre o estado da chamada, ao contrrio dos telefones tradicionais que apenas reagem a comandos de uma central controladora, refletindo uma arquitetura mestre-escravo.

- Gateways: permitem interligar duas redes que no usem a mesma tecnologia de comunicao.

- Servidores: funcionam ao nvel da aplicao, controlando o encaminhamento das mensagens de sinalizao. So tambm responsveis pelos servios de tarifao e controle de admisso. [sIPtel, p. 27]

SERVIOS DA REDE VOIP

Para se obter os servios de voz sobre ip so necessrios pelo menos cinco componentes. Estes componentes constituem o ncleo do servio das redes VoIP e so necessrios para a sua implementao.

- Transporte: responsvel pelo transporte de informaes entre as entidades, feito em tempo real atravs do protocolo RTP. Este componente resolve os problemas de congestionamento, perda de pacotes, minimizao de jitter e atraso de pacotes alm dos problemas relacionados ao prprio transporte.

- Controle de Transporte: responsvel pela administrao e controle do transporte de informaes. O controle feito atravs do protocolo RTCP.

- Sinalizao: responsvel pelo estabelecimento, controle e finalizao de chamadas.

- Aplicaes: Implementa as caractersticas da voz sobre ip como a sinalizao. Prov recursos como chamada em espera, conferncia e etc.

19

- Descoberta de recursos: descobre os servidores (gateways, terminais e servidores) presentes na rede. Para realizar esta operao utiliza-se por exemplo o protocolo DNS (Domain Name System).

OBSTCULOS PARA CONSOLIDAO DA REDE VOIP

Embora seja uma grande tecnologia, a VoIP ainda apresenta alguns problemas, que devem ser sanados para que ela se consolide de vez. Entre esses problemas esto:

- Qualidade de Servio: As redes IP atuais, atuam oferecendo um servio do tipo melhor esforo o que reduz a qualidade de servio.

- Segurana: Embora os novos servios j ofeream um mnimo de nvel de segurana, a VoIP tem um grande obstculo, a fama da internet de ser insegura.

- Custo elevado: Mesmo com uma incrvel reduo de custos sofrida pelo produtos VoIP, estes ainda no conseguem apresentar um custo compatvel com os oferecidos pelos produtos de telefonia tradicionais.

- Confiabilidade: Ainda falta confiana no sentido de se estar seguro quanto a disponibilidade do servio VoIP, quando se precisar dele como, por exemplo, para ligaes de emergncia.

PROTOCOLOS DE SINALIZAO

Os protocolos de sinalizao tornam-se importantes para as transmisses de voz sobre ip, pois so os componentes da rede necessrios para a troca de informaes de controle e gerenciamento dos servios de rede. Estes componentes podem fazer parte de dois grupos:

20

Protocolos mestre/escravo como, por exemplo, o MGCP e o Megaco e os Protocolos peerto-peer como, por exemplo, o H.323 e o SIP. Os protocolos mestre/escravo so usados quando os componentes inteligentes controlam os componentes sem inteligncia como, por exemplo, a sinalizao entre um SoftSwitch e um Media Gateway. J os protocolos peer-to-peer so utilizados em interaes entre elementos inteligentes como, por exemplo, a sinalizao entre um SoftSwitch e telefones IP. [Voip_revoluo_Telefonia.pdf]

Fig. 1.2: Arquitetura Protocolar. [sIPtel]

H.323

Introduo Histrica

Os primeiros passos para o surgimento do H.323 foram dados pelo setor de Telecomunicaes do ITU (International Telecommunication Union), o ITU-T, porm este 21

protocolo somente se deslanchou pelo mercado a partir da criao do frum Voice over IP (VoIP), quem mais tarde viria a fazer parte do IMTC (International Multimedia Teleconferencing Consortium), cuja funo seria, estabelecer padres para os produtos VoIP. O H.323 teve seu trabalho iniciado em maio de 1995 com o seguinte ttulo sistemas e equipamentos de telefone visual para redes locais que fornecem uma qualidade de servio no garantida, e somente teve sua primeira verso aprovada em 1996, tornando-se H.323v1, que apesar de todas as foras empregadas, no foi bem vinda, devido ao seu baixo desempenho e problemas de compatibilidade entre os diversos fabricantes. Porm os esforos no pararam por ai, em janeiro de 1998 a segunda verso da recomendao H.323 foi aprovada, com seu ttulo alterado para sistemas de comunicao multimdia com base em pacotes e acrescida de trs anexos: mensagens H.245 usadas pelos pontos finais H.323; procedimentos para codecs de vdeo em camadas; H.323 sobre ATM. Com isso a segunda verso melhorou o tempo de estabelecimento da chamada e eliminou a necessidade de extenses proprietrias e novos protocolos. Contudo, queria-se chegar alm, por isso em setembro de 1999 a terceira verso foi aprovada, contendo trs novos anexos: comunicao entre domnios administrativos diversos com o H.225; um novo mecanismo de sinalizao de chamadas com base no protocolo UDP; a especificao de um subconjunto do H.323 possvel de ser implementado em dispositivos de pequeno porte. A evoluo no parou por ai, pois em novembro de 2000 a quarta verso foi aprovada, trazendo melhorias em vrias reas importantes: confiabilidade, escalabilidade e flexibilidade. Sendo adicionadas novas caractersticas nas MCU (Gateways e Multipoint Control Unit), isso para deixar a recomendao conforme as exigncias do mercado crescente da poca. Finalmente chegamos a verso atual da recomendao H.323, a quinta verso, H.323v5, aprovada em julho de 2003. Esta verso se destaca pelo seu ar de estabilidade, pelo fato de conter somente adies modestas, alguns campos e somente um novo tipo de mensagem. No entanto o H.323 ainda no est totalmente concludo, sabendo-se que estudos para a aprovao da sexta verso esto acontecendo.

Componentes da Recomendao H.323

Em um sistema H.323 so definidos alguns componentes conforme a recomendao H.323: Gatekeeper, MP (Multipoint Processor), Terminal H.323, MC (Multipoint Controller), MCU (Multipoint Control Unit) e Gateway. Esses componentes possuem caractersticas 22

distintas, e podem pertencer a uma nica rede ou vrias redes independentemente de conter uma ou vrias infra-estruturas.

Gatekeeper: considerado o componente mais complexo da estrutura da recomendao H.323. Foi introduzido na primeira verso, H.323v1, apesar de na poca poucos entenderem sua utilidade. Contudo na segunda verso, a recomendao H.323 esclareceu o papel do gatekeeper, e hoje o entendemos como sendo um elemento opcional da(s) rede(s), com funes como: traduo de endereos que usado para se encontrar um alias; controle de chamadas o qual verifica a disponibilidade de recursos da rede; controle de admisso tanto rede como a terminais, Gateways e MCU, cuja funo verificar o direito de acessar recursos; controle de registro para poder contactar algum que est conectado ao sistema; reserva de recursos como largura de banda; localizao de gateways. Enfim resumese gatekeeper como sendo um servidor que prov servios multimdia para as entidades da rede e ainda gerencia toda a conferncia.

MCU (Multipoint Control Unit Unidade de Controle Multiponto): entidade, dispositivo que permite que vrios terminais e/ou gateways participem de uma conferncia Multiponto. Esta conferncia pode ser iniciada apenas com dois terminais (ponto-a-ponto) e logo aps poder tornar-se uma conferncia multiponto, com a entrada de mais terminais. A MCU composta de duas partes, o MC (multipoint Controller) que obrigatrio, e o MP (Multipoint Processor) que opcional. MC (Multipoint Controller Controladora Multiponto): geralmente um software que controla o uso de recursos nas conferncias multiponto, fazendo negociao com todos os terminais para obter uma comunicao igualitria. Tambm pode controlar outros recursos como por exemplo saber de quem uma emisso de vdeo multicast.

MP (Multipoint Processor Processador Multiponto): uma entidade, geralmente um hardware, fornecida para processar o fluxo de udio, vdeo e/ou dados em conferncias multiponto. O MP ainda pode prover o processamento, mistura ou comutao de fluxos de mdia sob o controle do MC (multipoint controller).

Terminal H.323: um endpoint (ponto final), terminal, de uma rede. Prov uma interface que permite ao usurio realizar a comunicao bidirecional em tempo real (transferncia de udio, vdeo e/ou dados) com outro terminal H.323, gateway ou MCU. Um terminal H.323 pode ser um hardware (telefone IP), ou um computador multimdia 23

(microfone, caixas de som e cmera) que esteja utilizando um softphone (software que simula um telefone IP).

Gateway: elemento da rede que realiza converso (traduo de protocolo) entre terminais distintos, permitindo a interoperabilidade entre sistemas H.323 e outros sistemas em redes distintas. Tambm realiza servios como compresso e empacotamento. Basicamente transforma a voz do usurio em pacotes de dados e vise-versa.

Fig. 1.3: Componentes do padro H.323 [Inatel]

Recomendao H.323 para a Arquitetura Protocolar do H.323

O departamento de telecomunicaes do ITU, o ITU-T, define que o padro H.323 um conjunto de protocolos necessrios pra que haja sinalizao e controle de comunicaes entre terminais H.323. Portanto fazem parte dessa recomendao os seguintes protocolos:

H.255.0 (Q.931 procedimento de sinalizao de comunicao entre os terminais das redes ISDN (RSDI)) que o protocolo de sinalizao de chamadas e encapsulamento de fluxo de dados multimdia para sistemas de comunicao baseada em pacotes. Define o mtodo para o estabelecimento de chamadas H.323. A terminologia H.225.0 (Q.931) usada devido

24

eficincia que o padro Q.931 tem em estabelecer chamadas e o desejo do padro H.225 se tornar compatvel com essas redes. As principais funes do padro H.225.0 so:

Sinalizao de chamadas: Sob o canal de sinalizao de chamadas (redes TCP/IP) trafegam vrias mensagens sob o formato da recomendao Q.931, estas tem como objetivo sinalizar (iniciar e terminar) chamadas e trafegam entre os equipamentos (terminais H.323 e GK, ou entre GKs) que fazem parte da comunicao. Se a rede no possuir um gatekeeper estas mensagens so passadas ponto-a-ponto usando o endereamento de sinalizao da chamada, j nas redes que possuem o gatekeeper, as mensagens so trocadas entre o terminal chamador e o gatekeeper, utilizando mensagens de endereamento RAS.

Controle de conferncia e equipamentos na rede: Esta fase realizada aps a sinalizao da chamada e so utlizadas mensagens do tipo RAS (Register, Admission and Status) responsveis pelo registro, admisso e status dos equipamentos da rede, estas mensagens definem o controle da rede e tem suporte aos pacotes UDP/IP.

Comunicao entre Gatekeepers: So mensagens utlizadas na comunicao entre GKs (gatekeepers), para estabelecer o processo de sinalizao e controle entre zonas distintas. Transporte de mdia: Para este evento utiliza-se os protocolos RTP (Real-Time Transport Protocol Protocolo de Transporte em Tempo Real) e o RTCP (Real-Time Control Protocol Protocolo de Controle em Tempo-Real), para o transporte de voz.

H.245 (Control Protocol for Multimedia Communication Protocolo de Controle para Comunicaes Multimdia) o protocolo que fornece os padres para o controle do transporte da voz entre as chamadas entre terminais. Estas mensagens tem suporte a TCP/IP e so enviadas entre Gateways e MCUs, de chamadas ponto-a-ponto ou ponto-multiponto. Este protocolo utilizado depois do estabelecimento da chamada. O H.245 tem a capacidade de se adaptar s mudanas que ocorrem na rede, como por exemplo: alteraes na disponibilidade da rede e/ou capacidades dos elementos H.323, isso deve-se a negociao dinmica que ocorre entre terminais, que negociam vrios aspectos da comunicao como por exemplo: formato de imagens e udio, codecs e taxa de transmisso. O controle feito atravs do canal lgico 0 (zero) que fica sempre aberto.

No estabelecimento de uma sesso bsica o H.323 utiliza trs protocolos de controle, o RAS, o H.225.0/Q931 e o H.245. 25

Fig. 1.4: Troca de mensagens entre entidades H.323. [sIPtel]

H.235 (Security and Encryption for H-Series (H.323 and other H.245-based) Multimedia Terminals Segurana e criptografia para terminais multimdia da srie H). uma recomendao que fornece os padres para autenticao e segurana entre comunicaes ponto-a-ponto e multiponto. Esta recomendao necessria para o estabelecimento de servios de segurana no padro H.323, como por exemplo: servios de privacidade, autenticao, no repudiao e integridade. Para que isto acontea o H.235 implementa tcnicas de criptografia.

H.450.X (Generic Funtional Protocol for the Support of Supplementary Services Protocolo de Funcionamento Genrico para o Suporte de Servios Suplementares). Este protocolo fornece os padres de sinalizao para os servios suplementares (comuns aos sistemas telefnicos atuais) para terminais, como por exemplo: atendimento simultneo, identificao de chamadas e etc. Cada suplemento fornecido pelo protocolo H.450 identificado atravs de um nmero inserido ao final da identificao do prprio protocolo H.450, como por exemplo: H.450.2 define o servio adicional de transferncia de chamada (call transfer).

26

Fig. 1.5: Arquitetura Protocolar do H.323 [sIPtel]

Fig. 1.6: Padro H.323 [Inatel]

Vantagens em se utilizar H.323

So vrias as vantagens que podemos descrever sobre a utilizao do padro H.323 para aplicaes multimdia, entre as quais citaremos:

Rede Independente: O protocolo H.323 no requer mudanas na estrutura da rede, ou seja, pode ser adaptado na prpria rede existente, isso se deve ao fato do protocolo H.323 ter sido projetado para ser usado em redes baseadas em pacotes, e hoje em dia a maioria das redes ter este aspecto.

27

Interoperabilidade de equipamentos e aplicaes: O H.323 permite que haja comunicao (interoperabilidade) entre equipamentos e aplicaes de diferentes fornecedores.

Independncia de plataforma: O H.323 pode operar sob qualquer hardware ou sistema operacional.

Utilizao de padres de mdia: O H.323 faz uso de codecs de udio e vdeo comuns, isso devido a negociao dos codificadores em uma chamada, para que os integrantes utilizem os mesmos codecs. Flexibilidade nas aplicaes clientes: a capacidade que o H.323 tem de comunicar um cliente que apresenta apenas suporte a udio, com outro cliente que tenha suporte a udio, vdeo e/ou dados.

Interoperabilidade entre redes: a capacidade que o cliente, que se encontra em uma rede, por exemplo, baseada em pacotes (redes IP) tem de se comunicar com outro cliente que se encontra em uma rede por exemplo ISDN. Isso ocorre atravs da utilizao de um gateway.

Suporte a gerenciamento de largura de banda: O H.323 permite o gerenciamento do consumo de largura de banda e tambm prov a contabilidade de uso dos recursos da rede, atravs da utilizao do gatekeeper.

Permite conferncias multiponto: suporta alm de conferncias ponto-a-ponto, as multiponto, com trs participantes ou mais.

Suporte a multicast: Permite multicast em conferncias multiponto, enviando um pacote a todo o subconjunto participante da conferncia.

Chamada H.323

Ilustraremos aqui uma chamada H.323 entre dois usurios conectados a dois terminais IP distintos, desconsiderando assim aspectos como segurana e tarifao.

28

Para se estabelecer uma chamada H.323 fim a fim requer-se duas conexes TCP entre os dois terminais participantes, uma conexo que servir para se estabelecer a chamada e outra que tem como objetivo o controle da chamada e a troca de informaes sobre capacidades. O primeiro passo significa ocorrer a primeira conexo TCP, ou seja, significa dar inicio a chamada. Esta primeira conexo realizada da seguinte forma: - Primeiro o terminal chamador, estabelece uma conexo TCP com o terminal chamado atravs de uma porta conhecida. Nesta tentativa, a conexo transporta as mensagens de estabelecimento de chamada definidas no H.225.0. Esta conexo conhecida como canal de sinalizao de chamadas. - Aps estabelecer a chamada, o terminal chamado espera por outra conexo TCP em uma porta dinmica; o terminal chamado comunica o nmero dessa porta na mensagem de aceitao de chamada. - Somente agora o terminal chamador ento estabelece a segunda conexo TCP com o terminal chamado atravs da porta dinmica. Esta segunda conexo transporta as mensagens de controle de chamada definidas no H.245. - Depois de estabelecida a segunda conexo, a primeira conexo deixa de ser necessria e pode ser finaliza por qualquer um dos participantes. [Telefonia IP]

Mensagens de Chamadas H.323

As mensagens H.323 so enviadas entre o terminal chamador e o terminal chamado medida em que a conexo entre ambos ocorre.

PRIMEIRA FASE: INICIALIZANDO A CHAMADA

O H.323 usa um subconjunto do protocolo Q.931, utilizado em ISDN (Integrated Services Digital Network Rede Digital de Servios Integrados), de mensagens de sinalizao para controle de chamada na interface usurio-rede. As seguintes mensagens fazem parte do ncleo do H.323 e devem ser suportadas por todos os terminais: Setup, Alerting, Connect, Release Complete, Status Facility. [Telefonia IP] 29

10.2.3.4

Fig. 1.7: Fluxo bsico da conexo H.323 [UFRJ]

Na figura Csar, tendo aberto a sesso no terminal A, deseja ligar para Bill (IP 10.2.3.4). Primeiramente o terminal A envia ao terminal B uma mensagem Setup na porta conhecida do canal de sinalizao de chamadas (porta 1720, como definido pelo H.225.0, Apndice D) usando uma conexo TCP. Aps o recebimento da mensagem Setup por Bill, este envia a Csar as mensagens de Release Complete, Alerting, Connect ou Call Proceeding. Uma delas deve ser recebida pelo terminal de Csar antes que o temporizador de Setup expire (em geral, aps quatro segundos). Aps Alerting ter sido enviada, o usurio tem at trs minutos para aceitar ou recusar a chamada. [Telefonia IP]

SEGUNDA FASE: ESTABELECENDO O CANAL DE CONTROLE

O controle da chamada e as mensagens de troca de capacidades so enviados na segunda conexo TCP. As mensagens so definidas no H.245. O terminal chamador abre esse canal de controle H.245 imediatamente aps receber uma mensagem Alerting, Call Proceeding ou Connect, no importando qual delas especifica em primeiro lugar o endereo de transporte H.245 a ser usado. Esta segunda conexo que foi estabelecida dever ser mantida ao longo de toda a chamada.

30

Nesta fase determina-se os papis de quem ser mestre e quem ser escravo, isto necessrio quando a mesma funo ou ao pode ser executada por dois terminais durante uma conversao e necessrio escolher apenas um (p. ex.: escolha do MC ativo, abertura de canais bidirecionais). No H.235, o mestre responsvel por distribuir as chaves de criptografia dos canais de mdia para os demais terminais. A determinao de quem ser mestre feita pela troca de mensagens masterSlaveDetermination que contm um valor terminalType refletindo as capacidades do terminal e um nmero aleatrio.

Fig. 1.8: Negociao de Capacidades H.245. [UFRJ]

TERCEIRA FASE: INCIO DA CHAMADA

Agora o terminal A e o terminal B precisam abrir canais de mdia para voz e possivelmente para vdeo e dados. Para abrir um canal de voz at B, A envia uma mensagem H.245 OpenLogicalChannel que contm o nmero que ser dado ao canal lgico, alm de outros parmetros. B envia uma mensagem OpenLogicalChannelAck referente a esse canal lgico to logo esteja pronto para receber dados de A. Essa mensagem contm o nmero da porta UDP para qual A deve enviar os dados RTP e a porta UDP para a qual A deve enviar os dados

31

RTCP. Enquanto isso, B tambm pode ter aberto um canal lgico com A seguindo o mesmo procedimento. [Telefonia IP]

Fig.1.9: Abrindo canais lgicos. [UFRJ]

QUARTA FASE: DILOGO

Agora Csar e Bill podem conversar e ver um ao outro caso eles tambm tenham aberto canais lgicos para vdeo. Os dados da mdia so enviados em pacotes RTP. Os pacotes RTCP SR enviados por A so usados para permitir que B sincronize mltiplos fluxos RTP e tambm podem ser usados por B para estimar a taxa esperada de dados RTP e para medir a distncia ao transmissor. Os pacotes RTCP RR enviados por B permitem que A mea a qualidade de servio da rede entre A e B: as mensagens RTCP contm a frao de pacotes que foram perdidos desde o ltimo RR, a perda cumulativa de pacotes, o jitter entre chegadas e o mais alto nmero de seqncia recebido. Os terminais H.323 devem responder ao aumento da perda de pacotes reduzindo a taxa de envio dos mesmos. Observe que o H.323 manda usar apenas um par de portas RTP/RTCP para cada sesso. Podem haver trs sesses principais entre os terminais H.323: a sesso de udio, a sesso de vdeo e a sesso de dados, mas nada no padro impede que um terminal abra mais sesses. Para cada sesso deve haver apenas uma porta RTCP usada, isto , se houver simultaneamente um fluxo RTP de A para B e de B para A, o transmissor RTCP e os RRs para ambos os fluxos vo usar a mesma porta UDP. [Telefonia IP] 32

Fig. 1.10: Conversao ativa H.323. [UFRJ]

QUINTA FASE: FINALIZANDO UMA CHAMADA

Caso seja Csar quem vai finalizar a chamada, o terminal A deve enviar uma mensagem H.245 CloseLogicalChannel para cada canal lgico que A abriu. B acusa o recebimento dessas chamadas com uma mensagem CloseLogicalChannelAck. Depois de todos os canais lgicos terem sido fechados, A envia uma mensagem H.245 endSessionCommand, espera at que tenha recebido a mesma mensagem de B e fecha o canal de controle H.245. Finalmente, A e B devem enviar uma mensagem H.225 ReleaseComplete atravs do canal de sinalizao de chamadas se ele ainda estiver aberto; esse canal ento fechado, assim como a chamada.

SIP Introduo

SIP (Session Initiation Protocol Protocolo de Iniciao de Sesso), um protocolo de sinalizao/controle de chamadas em redes IP. uma arquitetura que se originou em 33

meados dos anos 90 na Universidade de Columbia e depois foi normalizada pelo grupo de trabalho MMUSIC ( Multiparty Multimedia Session Control) do IETF (Internet Engineering Task Force). Foi definida inicialmente pela RFC (Request For Comment) 2543 em maro de 1999, e logo aps teve alguns aspectos melhorados que foram definidos na RFC 3261 em 2002.

Caractersticas

As principais caractersticas do protocolo SIP so escalabilidade, flexibilidade e facilidade de criao de servios, o que o torna um protocolo de fcil integrao junto s aplicaes j existentes na internet, isso se deve as semelhanas com os protocolos HTTP (HyperText Transfer Protocol) e SMTP (Simple Mail Transfer Protocol). O SIP foi criado com a finalidade de ser um protocolo mais fcil do que os j existentes no mercado, exemplo H.323, esta facilidade esta presente na criao, modificao e finalizao de sesses, que podem ocorrer entre um ou vrios integrantes. SIP um protocolo cliente-servidor, e tem um sistema final que interage com o usurio.

Arquitetura do SIP

A arquitetura do SIP composta de vrios componentes denominados entidades SIP, entre eles esto:

User Agent SIP (UA SIP - Agente do Usurio SIP): So os terminais finais de comunicao (terminal SIP ou softphone). Este agente atua como um cliente/servidor, sendo a parte cliente conhecida como UAC User Agent Client, uma entidade lgica que realiza a inicializao da sesso atravs do envio de pedido(s) para o servidor. O servidor, tambm uma entidade lgica conhecida como UAS User Agent Server, realiza o envio de respostas aos pedidos recebidos do cliente, dessa forma o agente consegue ter controle sobre a sesso. 34

Servidor Proxy SIP: este servidor subdividido em outros componentes, que so explicados abaixo:

Proxy Server - Servidor Proxy: um servidor intermedirio, que pode atuar tanto como cliente quanto como servidor. Tem a funo de estabelecer chamadas entre os integrantes da chamada, encaminhando os pedidos recebidos at o destino, sendo assim pode passar ou no por outros servidores proxy. Pode ser utilizado para contabilidade, pois armazena informaes. Opera atravs das comunicaes stateful (circuito) ou stateless (TCP).

Redirect Server - Servidor de Redirecionamento: um servidor intermedirio, um UAS User Agent Server, cuja funo fornecer informaes sobre o usurio destino, para isso, utiliza o DNS que resolve nomes.

Registrer Registrador: entidade cuja finalidade fornecer informaes sobre as localizaes que conhece. Estas informaes esto gravadas na entidade, pois a mesma anteriormente j recebeu outra requisio igual.

Fig. 1.11: Arquitetura Sip. [UFRJ]

35

Mensagens SIP

Mensagens SIP so codificadas usando a sintaxe de mensagem http/1.1 (RFC 2068). O conjunto de caracteres o ISO 10646 com codificao UTF-8 (RFC 2279). H dois tipos de mensagens SIP: pedidos (requests) e repostas (responses). [Telefonia IP, p. 125] Os pedidos so feitos atravs dos clientes e as repostas so retornadas atravs do(s) servidor(es). A mensagem SIP constituda da linha de nicio, cabealhos, linha em branco e o corpo da mensagem.

Verso do SIP SP Cdigo de Status SP Frase-Motivo CRLF para resposta

Mtodo SP URL do pedido SP Verso do SIP CRLF para pedidos

Linha de incio aaa=bbb ccc=ddd eee=fff

Linha em branco Cabealhos

Corpo da mensagem (SDP limpo, SDP criptografado,)

Fig. 1.12: O formato de mensagem SIP [Telefonia IP, p. 124]

A linha de incio contm a verso do SIP, SP (single space espao simples) que um formato comum compartilhado entre as mensagens de pedidos e repostas, Cdigo de Status, Frase-Motivo, CRLF utilizado para resposta. Os cabealhos transportam informaes teis as entidades SIP, para que estas possam gerar mensagens de pedidos ou respostas. A parte cabealho da mensagem SIP dividida em trs partes: cabealho de geral, cabealho de pedido e cabealho de entidade. A linha em branco sempre utilizada logo aps os cabealhos para indicar o fim dos mesmos.

36

O corpo da mensagem opcional. Caso ele exista ir descrever a sesso atravs do protocolo SDP (Session Description Protocol Protocolo para descrio de sesso).

O cabealho geral contm campos que so comuns para as mensagens de pedidos e respostas. Estes campos so:

Call-ID: o identificador da chamada, deve ser igual em todas as mensagens geradas durante uma chamada.

Cseq: contm o nmero de seqncia que incrementado a cada novo pedido. Este nmero permite identificar e ordenar as mensagens dentro das transaes.

From: Contm o endereo do usurio chamador.

To: indica o endereo do destinatrio.

Via: indica a rota que a requisio dever seguir, contm o tipo de transporte e o endereo de destino.

Encryption: serve para identificar quando o corpo da mensagem e, possivelmente, alguns cabealhos de mensagem foram criptografados. [Telefonia IP, p. 126].

Content-Type: descreve o tipo [Telefonia IP, p. 126]

de mdia do contedo do corpo da mensagem.

Content-lenght: significa o nmero de octetos do corpo da mensagem. [Telefonia IP, p.126].

Mensagens de Pedidos (Requests) SIP

As mensagens de pedido realizadas pelo protocolo SIP, partem do cliente para o servidor. Existem vrios tipos de mensagens que ocorrem dessa forma e cada uma delas transportada em uma parte da mensagem. As mensagens transportadas no cabealho geral so: 37

ACK: um pedido ACK enviado pelo cliente para confirmar que ele recebeu uma resposta final do servidor, como 200 OK; [Telefonia IP, p. 126]

BYE: um pedido BYE enviado pelo agente de origem ou pelo agente de destino para interromper uma chamada; [Telefonia IP, p. 128]

Cancel: um pedido Cancel pode ser enviado para interromper um pedido que foi enviado anteriormente enquanto o servidor ainda no tiver enviado uma resposta final; [Telefonia IP, p. 128]

Invite: o pedido Invite usado para iniciar uma chamada; [Telefonia IP, p. 128]

Options: um cliente envia um pedido Option ao servidor para saber suas capacidades. O servidor envia de volta uma lista com os mtodos que ele suporta. Em alguns casos, ele tambm pode responder com o conjunto de capacidades do usurio mencionado na URL (Uniform Resource Locator Localizador Uniforme de Recursos) e como ele teria respondido a um convite; [Telefonia IP, p. 128]

Register: clientes podem registrar sua localizao atual (um ou mais endereos) com o pedido Register. Um servidor SIP capaz de aceitar uma mensagem Register chamado de registrar. [Telefonia IP, p. 128]

Alm do campos do cabealho geral, os pedidos podem transportar campos no cabealho de pedido:

Accept: indica quais os tipos de mdia so aceitveis na resposta. A sintaxe especificada no RFC 1288; [Telefonia IP, p. 128]

Accept-Language: indica as lnguas preferidas do originador da chamada. A sintaxe especificada no RFC 1288; [Telefonia IP, p. 129]

Expires: para uma mensagem Register, indica por quanto tempo o registro ser vlido. Para uma mensagem Invite, isso pode ser usado para limitar a durao de buscas; [Telefonia IP, p. 129] 38

Priority: os valores so os do RFC 2076, mais emergency; [Telefonia IP, p. 129]

Record-Route: alguns proxies podem adicionar / atualizar esse campo de cabealho, se eles quiserem estar no caminho de todas as mensagens de sinalizao. [Telefonia IP, p. 129]

Subject: um texto livre que deveria fornecer alguma informao sobre a natureza da chamada. [Telefonia IP, p. 129]
Linha de incio

INVITE SP sip: john@domain.com SP SIP/2.0 CRLF

Via: SIP/2.0/UDP 169.130.12.5 Call-ID; 187602141351@warchester.bell-telephone.com From: <sip:a.g.bell@bell-telephone.com> TO: T.A. Watson <sip:watson@bell-telephone.com> Call-ID: 187602141351@warchester.bell-telephone.com Cseq: 1 INVITE

Cabealho geral

Cabealho de pedido

Subject: Mr. Watson, come here.

Cabealho da entidade

Content-Type: application/sdp Content-Length: 885

Linha em branco

<CR LF>

v=0 o=bell 53655765 2353687637 IN IP4 128.3.4.5 c=IN IP4 135.180144.94 m=audio 3456 RTP/AVP 0 3 4 5 Fig. 1.13: O formato da mensagem de pedido SIP [Telefonia IP, p.128]

Dados SDP

39

Mensagens de Respostas (Responses) SIP

As respostas SIP so geradas no(s) servidor(es) para atender a uma mensagem pedido que recebeu anteriormente. As respostas SIP seguem um padro de cdigos de status: 100-199: Informao Provisria; 200-199: Sucesso; 300-399: Redirecionamento; 400-499: Erro no cliente; 500-599: Erro no servidor; 600-699: Falha global;

1xx

Informativo 100 180 181 182

Pedido recebido, continuando a processar o pedido Tentando Chamando A chamada est sendo retransmitida Colocado na fila A ao foi recebida, entendida e aceita com sucesso 200 OK Uma ao adicional deve ser tomada para completar o pedido 300 301 302 380 Mltiplas escolhas Movido permanentemente Movido temporariamente Servio alternativo O pedido contm sintaxe invlida ou no pode ser efetuado neste servidor 400 401 402 403 404 405 406 407 408 409 410 411 413 Pedido invlido No autorizado Necessrio pagamento Proibido No encontrado Mtodo no permitido No aceitvel Necessria autenticao no proxy Tempo para o pedido esgotado Conflito No mais presente Necessrio fornecer comprimento Corpo da mensagem de pedido muito grande

2xx

Sucesso

3xx

Redirecionamento

4xx

Erro do cliente

40

414 415 420 480 481 482 483 484 485 5xx 500 501 502 503 504 505 6xx 600 603 604 606

URL do pedido muito grande Tipo de mdia no suportado Extenso invlida Temporariamente no disponvel

Transao ou leg de chamada no existe Lao (loop) detectado Excesso de segmentos (hops)
Endereo incompleto Ambguo Erro de servidor Erro interno no servidor No implementado Gateway invlido Servio no disponvel Tempo esgotado no gateway Verso SIP no suportada Falha global Ocupados em todos os lugares Declnio No existe em lugar nenhum No aceitvel

Tabela 1.1: As seis categorias de cdigos de status. [Telefonia IP, p. 130]

41

SIP/2.0 302 Moved temporarily

Linha de status

From: sip: Charlie@caller.com To: sip: alice@anywhere.com; tag=2332462 Call-ID: 27182@caller.com Location: sip:bob@anywhere.com Expires: Wed, 29 jul 1998 9:00:00 GMT Cseq: 1 INVITE
Linha em branco cabealhos

Dados da resposta (SDP limpo, SDP criptografado, text/plain ou text/html)

Fig. 1.14: O formato da resposta SIP [Telefonia IP, p. 131]

Chamadas SIP

As chamadas SIP so compostas de vrias etapas: incio da chamada, finalizao da chamada, rejeio da chamada entre outros.

INICIANDO UMA CHAMADA SIP

Para que se inicie uma chamada SIP, o iniciador da chamada (cliente SIP) dever conhecer o endereo SIP da pessoa a ser chamada (servidor SIP). So vrios os tipos de endereos SIP. O cliente/servidor SIP identificado atravs do URI (Universal Resource Identifier Identificador Universal de Recursos) definido na RFC 3261 de 2002. O URI identifica o utilizador atravs das seguintes formas:

sip:utilizador@dominio, sip:utilizador@host, sip:utilizador@IP-address ou sip:numerotelefone@gateway. 42

Sabendo-se o URI da pessoa a ser chamada, o cliente dever ento abrir uma conexo entre ele prprio e o destino, este estabelecimento de chamada se da inicialmente atravs do envio de um INVITE para o destinatrio, neste ponto do processo aps o envio do INVITE, o terminal chamado recebe o invite, ambos trocam informaes (mdia, endereo de destino, porta e etc) sobre como a sesso ser realizada, o terminal chamado aceita a conexo, o terminal chamador confirma o aceite e finalmente ambos estabelecem a conexo.
Originador da chamada Pessoa a ser chamada

Envio do INVITE

Resposta OK e informaes sobre mdia, porta e etc

Mensagem ACK

Troca de informaes

Fig. 1.15: Chamada ponto-a-ponto SIP [Telefonia IP, p. 119]

FINALIZANDO UMA CHAMADA SIP

A finalizao de uma chamada SIP pode ser realizada por qualquer umas das partes envolvidas atravs do envio de um pedido BYE. Caso a conexo seja ponto-a-ponto, apenas o que ir mudar em relao a finalizao da chamada ser realizada pelo cliente ou pelo servidor ser a ordem dos campos From e To.

43

A
Troca de informaes

BYE sip: a@192.168.7.1 SIP/2.0 v: SIP/2.0/UDP 192.168.7.2:3456 i: a2e3a@192.168.7.1 From: sip:b@192.168.7.2 To: sip: a@192.168.7.1 Cseq 2 BYE SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.7.2:3456 Call-ID: a2e3a@192.168.7.1 From: sip: b@192.168.7.2 To: sip: a@192.168.7.1 Cseq 2 BYE

Fig. 1.16: Finalizao de uma chamada SIP [Telefonia IP, p. 122]

ALTERAO DE CHAMADA SIP

A alterao da chamada SIP consiste na troca de parmetros como, por exemplo, mdia, endereos e portas, entre as partes, chamador e chamado durante a realizao da mesma sem que para isso a sesso deva ser finalizada.

A INVITE

200 OK

ACK

Troca de informaes

Fig. 1.17: Alterao de chamada SIP [Telefonia IP, 122]

44

No caso da figura acima as alteraes foram aceitas com sucesso pelo utilizador B, isso pode ser visto atravs do envio por parte de B da mensagem 200 OK aps o recebimento do invite enviado por A. Porm caso B rejeita-se a troca de parmetros proposta por A, ambos continuariam a utilizar os parmetros antigos at o fim da chamada ou at uma nova tentativa de troca de parmetros que viesse a ter sucesso. importante saber que ambas as partes envolvidas na chamada, A e B, podem propor a qualquer momento da chamada uma troca de parmetros.

REJEIO DE CHAMADA SIP

A rejeio de chamada muito funcional pois, por vrios motivos a pessoa chamada pode no querer atender a ligao como tambm pode no poder atender no momento.

A
INVITE SIP/2.0 486 Busy Here Via: SIP/2.0/UDP 192.190.132.31:3456 Call-ID: a2e3a@192.190.132.20 From: sip: a@192.190.132.20 To: sip: john@192.190.132.31 Cseq 1 INVITE ACK sip: B@192.190.132.31 SIP/2.0 Via: SIP/2.0/UDP 192.190.132.20:3456 Call-ID: a2e3a@192.190.132.20 From: sip: a@192.190.132.20 To: sip: b@192.190.132.31 Cseq 2 ACK

Fig. 1.18: Resposta busy here [Telefonia IP, p.123]

COMPARAO ENTRE H.323 E SIP

A primeira coisa que impressiona ao se estudar o protocolo SIP sua velocidade e simplicidade em relao ao H.323, pois o SIP consegue fazer em uma transao o que o H.323 faz em vrias. Outra vantagem impressionante que o SIP funciona muito bem em

45

backbones com capacidade para multicast, no apenas para os fluxos de mdia como tambm para as mensagens de sinalizao. O SIP ainda toma vantagens no uso de URLs para identificao dos usurios pois ele mesmo especifica o protocolo na URL (Universal Resource Location), ao passo que o H.323 sempre considera que o protocolo de sinalizao que est sendo usado seja ele mesmo. Nas inmeras vantagens do protocolo SIP sobre o H.323 ainda podemos encontrar o campo de cabealho Priority que no existe no H.323. Mas no somente o SIP que tem vantagens, tambm podemos encontrar muitas vantagens ao se utilizar o protocolo H.323 como, por exemplo, o uso de canais lgicos pelo protocolo H.323. O H.323 faz uma distino clara entre os tipos de mdia que podem ser enviados ou recebidos e as combinaes que podem ser vlidas por um lado (capacidades) e os tipos de mdia que esto ativos e, de fato, enviados para a rede (canais lgicos) por outro lado. O cliente H.323 tambm toma vantagem ao precisar abrir um soquete apenas quando ele recebe uma mensagem OpenLogicalChannel (se no estiver no modo FastStart). O H.323 sozinho ou em combinao com o H.332, possui recursos poderosos para controle de conferncias. [Telefonia IP, p. 153 a 157]

PROTOCOLO SDP

SDP um protocolo utilizado pelo SIP para descrever sesses. O SDP (Session Description Protocol Protocolo de Descrio de Sesso) est definido na RFC 2237 de 1998 e tambm um produto do grupo de trabalho MMUSIC. [Telefonia IP, p. 131] Este protocolo define para um utilizador informaes como tipos de udio e vdeo que ele suporta, porta onde dever receber os dados, nome da sesso e propsito, durao da sesso, informao de contato, largura de banda e etc., estas informaes so transportadas juntamente com a mensagem SIP. A real finalidade do protocolo SDP atuar como um negociador entre as partes envolvidas na chamada j que este carrega consigo todas as informaes que so teis para o estabelecimento da chamada. Visto que nem sempre as partes se entendem sobre, por exemplo, que tipo de udio e vdeo iro utilizar, o SDP de ambas as partes ficam fornecendo 46

informaes sobre os udios e vdeos, entre outras informaes, que suportam at que ambos entrem em um consenso.

Fig. 1.19: Exemplo da utilizao do SDP numa mensagem SIP. [sIPtel, p. 43]

PROTOCOLOS ENTRE GATEWAYS DE MDIA E CONTROLADORES DE MDIA

So protocolos que atuam como uma interface entre um controlador de gateway de mdia e um gateway de mdia. Controlador de gateway de mdia um agente de chamada e o gateway de mdia, pode ser qualquer gateway VoIP. Citaremos agora os protocolos entre gateways de mdia e controladores de mdia mais atuais.

MGCP

MGCP (Media Gateway Controller Protocol Protocolo de Controle de Media Gateway), um protocolo que est definido atravs da recomendao RFC 2705 do IETF, 47

usado para controlar as conexes (chamadas) nos GWs presentes nos sistemas VoIP. O MGCP implementa uma interface de controle usando um conjunto de transaes do tipo comando resposta que criam, controlam e auditam as conexes (chamadas) nos GWs. Estas mensagens usam como suporte os pacotes UDP da rede IP, e so trocadas entre os GCs e GWs para o estabelecimento, acompanhamento e finalizao de chamadas. [Teleco]

Fig. 1.20: Arquitetura MGCP geral. [Unisal]

O gateway de telefonia um elemento de rede que prov conversao entre o sinal de udio transportado nos circuitos telefnicos e converte para pacotes de dados transportado na internet ou outras redes de pacotes. A RFC do MGCP suporta vrios tipos de gateways de telefonia, entre eles podemos citar: - gateways de tronco: Fazem a interface entre a rede telefnica e a rede VoIP; - gateways residenciais: Fazem uma interface analgica tradicional (RJ11) com a rede de VoIP; - gateways de acesso: Fazem uma interface analgica (RJ11) ou interface digital do PBX corporativo para a rede IP; - gateways corporativos: fazem uma interface padro digital com o PBX corporativo ou integrado como uma interface soft PBXpara uma rede VoIP; - Servidor de Acesso a rede: Podem associar a um modem ou um circuito telefnico e prover acesso de dados para internet, prover com o mesmo gateway acesso combinado para os servios das rede de voz e servios de rede. 48

O MGCP pode-se dizer que um protocolo mestre/escravo, pois os gateways ficam aguardando para executar comandos dos Call Agents. Em seu modelo de conexo, a contruo bsica so os endpoints e as conexes. Os endpoints so as fontes e pontos finais de dados. Entre os endpoints usa-se o protocolo SDP para a descrio de mdias na negociao das mesmas.

Fig. 1.21: Arquitetura do MGCP - Residential Gateways - Soluo Clarent [UFRJ]

Fig. 1.22: Arquitetura do MGCP - Trunking Gateways Soluo MCI [UFRJ]

O ambiente MGCP composto basicamente de um Call Agent, e um conjunto de gateways, incluindo pelo menos um mdia gatewayque realiza a converso das mdias entre 49

os circuitos e os pacotes, e pelo menos um gateway de sinalizao! Onde este conectado com uma rede controlada por SS7.

Comandos MGCP

Fig. 1.23: Comandos MGCP. [Unisal]

MEGACO

O protocolo Megaco uma evoluo do MGCP, resultado de um esforo conjunto do IETF e do ITU-T (Grupo de Estudo 16). O texto da definio do protocolo e o mesmo para o Draft IETF e a recomendao H.248, e representa uma alternativa ao MGCP e outros protocolos similares. Este protocolo foi concebido para ser utilizado para controlar GWs monolticos (1 nico equipamento) ou distribudos (vrios equipamentos). Sua plataforma aplica-se a gateway (GW), controlador multiponto (MCU) e unidade interativa de resposta audvel (IVR). Possui tambm interface de sinalizao para diversos sistemas de telefonia, tanto fixa como mvel. [Teleco]

50

Comandos MEGACO

Tabela 1.2: Comandos MEGACO. [Unisal]

COMPARAO ENTRE MGCP E MEGACO

51

Tabela 1.3: comparao entre MGCP e MEGACO. [Unisal]

PROTOCOLO RTP

O RTP (Real-Time Transport Protocol Protocolo de Transporte em Tempo Real) [RFC 1889, 1996] foi projetado para permitir que os receptores compensem o jitter e a perda de seqncia dos pacotes introduzidos pelas redes IP. O RTP pode ser usado para qualquer fluxo de dados em tempo real, como voz e vdeo. O RTP define um modo de formatar pacote IP que carregam dados iscronos e inclui: - Informao sobre o tipo de dado transportado; - timestamps; - nmeros de seqncia. [Telefonia IP, p. 10]

O RTP atua entre as aplicaes e os protocolos da camada de transporte. um protocolo independente das camadas de rede e de transporte por isso, pode ser implementado sob qualquer protocolo. Com a implementao do RTP sobre o UDP, seu uso mais comum, as vantagens obtidas tornam-se maiores ainda pois, alm da simplicidade do UDP mais dois servios so disponibilizados: a multiplexao e a correo de erros. O RTP implementado mais comumente sobre o UDP pois, ele no se preocupa com a entrega ou atraso de dados, QoS to quanto reserva de recursos, espera-se que este servio seja oferecido pelos protocolos que o encapsulam. [RTP_RTCP.pdf, p. 7] 52

FUNCIONALIDADES DO RTP

O protocolo RTP possui inmeras funcionalidades dentre elas esto:

Seqncia: o nmero que ordena os pacotes, usado para verificao de perdas e/ou reordenamento de pacotes;

Sincronismo: o RTP prov informaes sobre o tempo de cada pacote, isto necessrio para a reproduo da mdia com qualidade.

Identificao de quadro: quadros fazem parte de pacotes, o RTP marca o incio e o fim de cada pacote, necessrio para identificao deste quadro.

Identificao de origem: indica quem enviou o pacote.

Criptografia: Alguns streams de RTP podem ser criptografados.

Liberdade no controle da sesso: permite aos participantes trocarem informaes pessoais.

Qualidade de Servio: o destinatrio tem a possibilidade de fornecer informao sobre a qualidade da recepo. [VoIP, p. 19]

PACOTE RTP

O pacote RTP constitudo de um cabealho RTP fixo, uma lista de fontes de contribuio e um payload (contedo do pacote). [RTP_RTCP.pdf, p.8]

53

Fig. 2.1: Pacote RTP [<http://www.breitband-isdn.ch/technic/ip/rtp.gif> 26/05/2005]

acesso

em:

V: Verso do RTP;

P: padding, indica se o payload sofreu enchimento para fins de alinhamento.

X: indica se h extenses aps eventuais CSRCs do cabealho fixo.

CC: informa quantos identificadores CSRC vm aps o cabealho fixo.

M: O H.225.0 informa que, para codificaes de udio que suportam supresso de silncio, ele deve ser colocado em 1 no primeiro pacote de cada perodo de fala subseqente a um perodo de silncio.

PT payload type: indica o tipo de payload.

Sequence Number: Nmero de seqncia , comea com um nmero aleatrio e incrementado a cada pacote RTP.

Time Stamp: indica a freqncia do clock para o tipo de payload.

Synchronization Source Identificator (SSRC): Identificador de fonte de sincronizao, todos os pacotes RTP com um SSRC comum possuem uma mesma referncia de tempo e de seqenciamento. 54

Contributive Source Identificator (CSRC): Identificador de fonte contribuinte, quando um fluxo RTP o resultado de uma combinao de vrios fluxos contribuintes feita por um misturador (mixer) RTP, a lista com os SSRCs de cada um dos fluxos contribuintes adicionada ao cabealho RTP do fluxo resultante como uma lista de CSRCs. O fluxo resultante tem o seu prprio SSRC.

Data: dados. [Telefonia IP, p.12 e 13]

SESSO RTP

Uma sesso RTP uma associao de participantes que se comunicam no RTP. Cada participante usa dois endereos de transporte para cada sesso: um para o fluxo RTP e um para as mensagens RTCP. Quando uma transmisso multicast usada, todos os participantes usam o mesmo par de endereos de transporte multicast. Fluxos de dados na mesma sesso devem compartilhar um canal RTCP comum. [Telefonia IP, p. 12] Se em uma conferncia estiver sendo transmitido udio e vdeo, estes sero transmitidos em sesses RTP distintas. Nestas sesses os pacotes RTCP de um emissor tero o mesmo identificador, e as sesses RTP podem associar-se. O objetivo da diviso permitir ao participante escolher as mdias que quer receber de acordo com seus recursos de rede e processamento local. [RTP_RTCP.pdf, p.12] Manter fluxos de mdias diferentes numa mesma sesso RTP traz uma srie de problemas: - Se o tipo de payload for mudado durante a sesso, no haver como saber qual dos valores antigos foi alterado; - O identificador SSRC designado para descrever apenas um escopo de temporizao e de nmero de seqncia; - RTCP sender e receiver reports podem indicar apenas uma fonte SSRC; - Um RTP mixer no saberia combinar mdias incompatveis; - No poderia haver usos e implementaes especficas de cada meio.

55

Embora a diviso de sesses no seja recomendada, a sincronizao de udio e vdeo pode ser obtida atravs das informaes de tempo carregadas nos pacotes RTCP. [RTP_RTCP.pdf, p.13]

QUALIDADE DE SERVIO

O conceito de QoS (Quality of Service Qualidade de servio) sobre redes IP somente foi pensado a pouco, em um passado no to distante o que apenas era oferecido era um servio, o de melhor esforo (best effort), o que no garantia QoS. O que realmente levou a qualidade de servio ao auge foram os novos servios que puderam ser oferecidos sobre as redes IP, udio e vdeo. Com a implantao desses novos servios vrios parmetros comearam a ser abordados, entre eles os mais comuns que caracterizam a qualidade de servio so: latncia, largura de banda e perda de pacotes ou de seqncia. Vrios institutos, pessoas e etc., tem se mobilizado para estudar melhores formas de prover qualidade de servio. A primeira das propostas foi feita pelo grupo de trabalho Integrated Services do IETF, foi uma arquitetura de integrao de servios, chamada Internet Integrated Services (IIS) que prope melhorar o desempenho da camada de rede, assegurando a reserva de recursos. A segunda proposta feita pelo grupo Differentiated Services (DiffServ) do IETF, uma arquitetura de diferenciao de servios na internet. A terceira proposta baseia-se na negociao de servios de rede, para a utilizao de mltiplos servios de rede. A quarta baseada na utilizao de mecanismos adaptativos que tentam reduzir as perdas e os atrasos de pacotes, atravs do uso de mecanismos adaptativos utilizados ponto a ponto. A quinta baseia-se no envio de correes de erro, fornecendo mecanismos de redundncia para ultrapassar a perda de pacotes em streams multimdia. [sIPtel, p. 28,29 e 30]

MODELO BSICO DE QoS

56

QoS nos dias de hoje tem o grande objetivo de priorizar o trfego interativo sensvel a retardo, em detrimento ao trfego referente transferncia de arquivos, que no sensvel a retardo.

Fig. 3.1: Modelo para QoS [ Voip_Ramon.pdf, p.21]

O que se pode observar na figura acima que a qualidade de servio dever ser tratada independentemente em cada umas das partes que passam/repassam o pacote de dados incluindo sua origem e destino.

CONGESTIONAMENTO

Pensar em congestionamento muito simples, basta lembrar-mos das horas que ficamos nos congestionamentos de trnsito, ou ento nos inmeros finais de ano que passamos tentando ligar para algum e as redes de telefonia encontram-se congestionadas devido aos inmeros telefonemas que ocorrem no mesmo instante. O mesmo ocorre nas redes IP, porm com um toque a mais de dificuldade, j que o que estamos tratando algo relativamente novo. Para resolver o problema de congestionamento em redes ip vrios artifcios foram estudados afim de se controlar e prevenir este tipo de problema. Estes artifcios so chamados de mecanismos de enfileiramento. Alguns desses mecanismos so:

Fifo

57

First In First Out primeiro a entrar, primeiro a sair. Tambm chamado de primeiro a chegar, primeiro atendido (First Come, First Served FCFS). Simplesmente emite os pacotes na ordem em que foram recebidos. Um exemplo da utilizao deste mtodo so nas conexes seriais dos roteadores.

Fig. 3.2: Operao da Fila FIFO [VoIP_Ramon.pdf, p. 22]

Os roteadores apresentam uma programao defaul quando so utilizados pela primeira vez, e continuam assim at que algum a mude. Esta programao default diz que a ordem de chegada dos pacotes que determina a alocao de banda, e o que chega primeiro logo atendido. A desvantagem de se usar FIFO quando ocorre trafego de rajada, isso pode causar atrasos, portanto FIFO no serve para aplicaes sensveis a QoS.

Fair Queueing

FQ - Fair queuing enfileiramento justo. Neste algoritmo as mensagens so ordenadas em sesses, e, para cada sesso, alocado um canal. A ordem na fila realizada atravs do ultimo bit que atravessa o canal. Essa operao prov uma alocao mais justa da banda entre os fluxos de dados. [VoIP_Ramon.pdf, p.22]

Fig. 3.3: Filas Fair Queueing [VoIP_Ramon, p. 22] 58

O algoritmo WFQ (Weighted Fair Queueing Enfileiramento Justo Balanceado) uma implementao Cisco na qual possvel ponderar determinados tipos de fluxo. O algoritmo escalona o trfego prioritrio na frente da fila, reduzindo o tempo de resposta. Ao mesmo tempo, compartilha o restante da banda com os outros tipos de fluxo de uma forma justa. O WFQ dinmico e se adapta automaticamente s mudanas das 2Mbps. [VoIP_Ramon.pdf, p. 23]

Fig. 3.4: Operao do Algoritmo WFQ [VoIP_Ramon.pdf, p.23]

Por apresentar um desempenho superior fila FIFO, a fila WFQ j vem prconfigurada nas interfaces seriais da maioria dos roteadores. [VoIP_Ramon.pdf, p. 23]

Fig. 3.5: Filas WFQ [VoIP_Ramon.pdf, p.23] 59

Como pode ser verificado na figura, a classificao dos fluxos de dados pode ser realizada de diversas formas: por endereo fonte ou destino, por protocolo, pelo campo preedncia IP, pelo par porta/socket, etc. A quantidade de filas configurvel e a ponderao pode ser estabelecida por preedncia IP, ou em conjunto com outros protocolos de QoS como o RSVP, ou ainda em trfego Frame Relay, como VoFR (Voice over Frame Relay) por exemplo, atravs dos parmetros FECN (Forward Explicit Congestion Notification), BECN (Backward Explicit Congestion Notification) e DE (Discard Eligible). [VoIP_Ramon.pdf, p.23]

Priority Queueing

Numa fila com Enfileiramento Priority Queueing - PQ (enfileiramento prioritrio), o trfego de entrada classificado em quatro nveis de prioridade: alta, mdia, normal e baixa (high, medium, normal e low). Os pacotes no classificados so marcados, por default, como normal.

Fig. 3.6: Operao do enfileiramento Priority Queueing [VoIP_Ramon.pdf, p.24]

A utilizao deste mtodo requer um cuidado especial, pois como visto acima os pacotes que tem prioridade, tem preferncia absoluta, isto pode causar atrasos e aumento de jitter nas aplicaes com menos prioridade alm de poder acontecer dos pacotes nunca serem enviados.

60

Fig. 3.7: Filas Priority Queuening [VoIP_Ramon.pdf, p.24]

Podemos classificar o trfego de uma fila PQ por protocolo, interface de entrada ou lista de acesso.

Custom Queueing

O algoritmo da fila CQ (Custom Queueing) permite especificar uma percentagem da banda para uma determinada aplicao (alocao absoluta da banda). A banda reservada compartilhada proporcionalmente, no percentual pr-definido, entre as aplicaes e os usurios. O restante da banda compartilhado entre os outros tipos de trfego. [VoIP_Ramon.pdf, p.25]

61

Fig. 3.8: Operao do enfileiramento Custom Queueing [VoIP_Ramon.pdf, p.25] O algoritmo CQ controla o trfego alocando uma determinada parte da fila para cada fluxo classificado. As filas so ordenadas ciclicamente num esquema round-robin, onde, para cada fila, enviado a quantidade de pacotes referente parte da banda alocada antes de passar para a fila seguinte. Associado a cada fila, h um contador configurvel que estabelece quantos bytes devem ser enviados antes da passar para a prxima fila. [VoIP_Ramon.pdf, p.25]

Fig. 3.9: Filas Custom Queueing [VoIP_Ramon.pdf, p.25]

At 17 filas podem ser definidas, mas a fila zero reservada para mensagens do sistemas como sinalizao, keep-alive, etc. A classificao CQ pode ser feita por endereo 62

fonte ou destino, por protocolo (IP, IPX, Appletalk, SNA, DecNet, etc), por precedncia IP, por interface de entrada e ainda por listas de acesso.

Comparao entre os Mtodos de Enfileiramento

Tabela 3.1: Mtodos de Enfileiramento [VoIP_Ramon.pdf, p. 26] Na tabela acima podemos ver um breve resumo sobre os mtodos de enfileiramento. Deve-se dar uma ateno especial a esta parte j que estas so as diretrizes bsicas a serem consideradas no incio de um projeto VoIP, porm no se deve esquecer de tambm analisar os prprios aspectos do projeto, como por exemplo, largura de banda disponvel, tipo de roteamento, etc.).

Deteco RED e WRED

Deteco RED (Random Early Detection Deteco Randmica Antecipada) um mecanismo de congestion avoidance ou seja serve para prevenir e impedir o congestionamento. Atua para evitar picos de trfego, atravs de uma anlise antecipada do trfego. Ao constatar irregularidades pode tomar vrias decises como, por exemplo, descartar pacotes, indicar fonte para que reduza a taxa de transmisso.

63

Deteco WRED (Weighted Random Early Detection Deteco Randmica Antecipada Balanceada) uma implementao Cisco que adiciona s funcionalidades RED a classificao de pacotes por precedncia IP.

Fig. 3.10: Funcionamento do WRED [VoIP_Ramon.pdf, p. 26]

PROTOCOLO RTCP

O RTCP (Real Time Control Protocol Protocolo de controle em Tempo Real) [RFC 1889, 1996] foi criado pelo IETF para auxiliar o RTP. usado para transmitir aos participantes, de tempos em tempos, pacotes de controle relativos a uma sesso RTP em particular. Esses pacotes de controle podem incluir informaes a respeito dos participantes e informaes sobre o mapeamento dos participantes em suas fontes de fluxo individuais. [Telefonia IP, p. 14]

Funcionalidade do RTCP

O protocolo RTCP funcional pois, prov informaes adicionais sobre seus participantes:

64

Retorno de informaes de Qualidade de Servio (QoS): Receptores podem retornar informaes sobre atraso, jitter, e perdas, que pode ser usadas para adaptar a aplicao, como por exemplo alterar o vocoder que est sendo utilizado. Sincronismo Intermdia: Necessrio para sinronizar diferentes fluxos, como udio e vdeo, caso sua origem seja de servidores diferentes.

Identificao do usurio: e-mail, nome, organizao, etc.

O RTCP necessita que as informaes citadas sejam enviadas periodicamente, no entanto sabe-se que este envio de informaes por parte dos participantes, consome em mdia 5% de largura de banda, portanto deve ser de suma importncia o controle sobre a taxa de envio de pacotes, para que assim possa-se evitar congestionamento entre outros problemas. O mesmo endereo utilizado pelo RTP usado pelo RTCP, porm em portas diferentes. Nem todas as aplicaes RTP utilizam RTCP, que no indispensvel para as aplicaes. [VoIP, p.19]

Pacote RTCP

Um pacote RTP um pacote de controle constitudo de um cabealho fixo seguido por elementos estruturados variando de acordo com o tipo de pacote RTCP.

- SR (Sender Reports): contm informaes de transmisso e recepo para transmissores ativos; - RR (Receiver Reports): contm informaes de recepo para ouvintes que no sejam tambm transmissores ativos; - SDES (Source Descriptions): descrevem vrios parmetros da fonte, inclusive o CNAME; - BYE: enviado por um participante quando ele abandona a conferncia; - APP: funes especficas de uma aplicao;

65

2 P

Octet 1 2 3-4

Version

Reception report count Packet type Length

RTCP structure

Fig. 3.11: Protocolo RTCP [Protocols]

Version - verso: espao reservado para indicao da verso do protocolo. O valor deve ser 2;

P padding: indica que o payload sofreu enchimento para fins de alinhamento. Devese lembrar que o ltimo octeto dos dados de preenchimento deve conter o nmero de octetos usados para preenchimento. Apenas o ultimo pacote do pacote composto RTCP prescisa receber preenchimento, uma vez que o pacote composto encriptadocomo um todo, caso necessrio;

Reception Report Count - Contador de Relatrio de Recepo: o nmero de blocos de relatrio (reception blocks) presentes no pacote SR. O valor 0 vlido.

Packet Type Tipo de pacote: serve para identificar qual o pacote RTCP em questo.

Lenght - comprimento: indica o comprimento do pacote RTCP em palavras de 32 bits menos um, incluindo o cabealho e qualquer informao de preenchimento. [RTP_RTCP.pdf, p.18]

PROTOCOLO CRTP (Compressed Real-Time Protocol)

Um dos problemas relacionados voz sobre IP a utilizao da largura de banda disponvel. Para tentar minimizar este problema foram criados protocolos que se relacionam com a voz transmitida nas chamadas, estes protocolos tentam realizar ao mximo uma 66

compresso de dados, para que assim possa-se trafegar mais dados na banda disponvel ou ter uma maior banda para trafegar os dados desejados, tambm usam tcnicas de fragmentao e interleaving para se obter um sinal de voz com maior qualidade. O protocolo CRTP (Compressed Real-Time Transport Protocol) comprime o cabealho do pacote RTP, que transporta o trfego de voz.
20 bytes 8 bytes 12 bytes 20 bytes

40 bytes

Fig. 3.12: Encapsulamento de pacote VoIP. [VoIP_Ramon.pdf, p. 27]

A partir da figura acima podemos ver para se transportar todos esses dados usa-se muita largura de banda, por isso o uso do protocolo CRTP, este protocolo comprime todo o cabealho de 40 para 2 Bytes. Seu funcionamento muito simples, o CRTP primeiramente classifica o trfego total que esta sendo enviado, em segundo lugar separa o que for RTP para que ocorra a compresso. A parte RTP passa pelo compressor e novamente anexado aos dados para serem transmitidos.

PROTOCOLO IEEE 802.1p priority queueing.

A relao entre o protocolo IEEE 802.1p e qualidade de servio est relacionada a questo de QoS em redes locais. At agora somente nos preocupamos em analisar a QoS fima-fim, porm esquecemos de visualizar o comportamento dos pacotes de udio e vdeo dentro das LANs (Local rea Network Rede Local). Por isso a partir de agora analisaremos como obter QoS de, por exemplo, um pacote enviado de um telefone ip at que este pacote alcance a rede de longa distncia e chegue rede remota com a QoS que a aplicao requer, ou seja, o protocolo 802.1p. O protocolo 802.1p define 8 nveis de prioridade de usurios, atravs de um rtulo (user_priority) de 3 bits que transmitido no quadro ethernet. 67

No caso do pacote enviado pelo telefone IP, este pacote foi primeiro setado no telefone IP com sua precedncia, em segundo o pacote chega ao switch, que pode ser compatvel ou no com o protocolo 802.1p, caso seja compatvel, o switch classificar o quadro ethernet, priorizando os de maior classe, caso no seja compatvel, o switch ignora os rtulos e o pacote no sofrer nenhum tratamento especial, em terceiro o pacote chega ao roteador que classifica o quadro ethernet e mapeia o nvel de prioridade 802.1p na precedncia IP correspondente, por ultimo, quando o pacote j alcanou a rede de longa distancia, este ter um tratamento de acordo com as vrias tcnicas de QoS j apresentadas.

PROTOCOLO RSVP

RSVP (Resource Reservation Protocol Protocolo de Reserva de Recursos) um protocolo de sinalizao, que permite ao equipamento (host e/ou roteadores) requisitar um nvel especfico de qualidade de servio para sua aplicao. Tambm utilizado na entrega de requisies de QoS de roteadores para roteadores entre outros. As requisies do protocolo RSVP, sempre que possvel, provem um nvel de QoS solicitado pelo equipamento (host), isto porque suas requisies fazem reservas de recursos na rede.

Fig. 3.13: Protocolo RSVP em Mquinas do Usurio e Roteadores. [RNP-RSVP]

68

Embora o protocolo RSVP se favorea dos protocolos de roteamento para determinar a rota a ser seguida pelos pacotes da origem at o destino, ele no um protocolo de roteamento. Atravs dessas tcnicas utilizadas pelo RSVP ele capaz de operar tanto em modo unicast como em modo multicast, apenas devemos ressaltar que o RSVP faz a reserva de recursos em um nico sentido (simplex), tratando assim distintamente receptores e transmissores, operando juntamente com a camada de transporte.

Fig. 3.14: Camada de atuao do Protocolo RSVP [RNP-RSVP]

Todas as mensagens RSVP apresentam um cabealho em comum.

4 Ver

8 Flags

16 Message type (Reserved) RSVP checksum RSVP length

32 bits

Send TTL

RSVP header structure

Fig. 3.15: Cabealho RSVP [Protocols]

Os campos do cabealho do protocolo RSVP so descritos abaixo:

Ver (Verso): nmero da verso do protocolo.

Flags: Nenhum flag est definido ainda.

Message type (Tipo de mensagem): identifica o tipo de mensagem RSVP que est sendo enviada.

RSVP Checksum: checksum.

Send TTL: O valor do IP TTL com o qual a mensagem foi enviada.

69

RSVP length: comprimento total da mensagem RSVP em bytes, incluindo o cabealho e os objetos que seguem.

Mensagens RSVP

O RSVP troca constantemente vrias mensagens entre as aplicaes e os equipamentos para assim prover qualidade de servio. As principais mensagens RSVP so PATH e RESV. A mensagem PATH constri o caminho pelo qual as mensagens RESV iro passar efetuando as reservas de recursos. A operao bsica do protocolo RSVP :

- A fonte especifica as caractersticas do trfego a ser transmitido, atravs de parmetros do algoritmo Token-Bucket. Esta informao transportada no objeto Sender Tspec. - O RSVP da fonte envia uma mensagem PATH ao destino (ou destinos) contendo a especificao do trfego feito pela fonte. A rota a ser seguida pela mensagem PATH definida pelo algoritmo de roteamento, e no pelo RSVP. - Cada roteador RSVP-capaz ao longo da rota estabelece um "path-state" que inclui o endereo do roteador RSVP-capaz imediatamente anterior (roteador que enviou a mensagem PATH - upstream). Cada roteador envia seu endereo ao vizinho posterior (downstream) atravs do objeto RSVP_HOP. Os roteadores podem incluir na mensagem PATH informaes sobre os recursos disponveis e o atraso aproximado que ele ir introduzir, atravs do objeto ADSpec. Assim, em qualquer ponto ao longo da rota, a mensagem PATH contm o endereo IP do roteador vizinho (upstream) e pode conter informaes de capacidade e atraso aproximado que cada n ir introduzir. - Para fazer a reserva de recursos, o receptor envia uma mensagem RESV (requisio de reserva) na direo da fonte, contendo a especificao da qualidade de servio requisitada para o fluxo de dados (objeto FlowSpec). A mensagem RESV vai do receptor fonte atravs do mesmo caminho percorrido pela mensagem PATH. Isto possvel porque cada roteador armazenou o endereo do vizinho (na direo da fonte) recebido na mensagem PATH. - Cada roteador RSVP-capaz ao longo da rota (upstream), ao receber a mensagem RESV, utiliza um processo de controle de admisso para autenticar a requisio e alocar os recursos necessrios. Se a requisio no pode ser satisfeita (devido insuficincia de recursos, por exemplo), o roteador retorna uma mensagem de erro ao receptor (origem da 70

mensagem RESV). Se a requisio for aceita, o roteador envia a mensagem RESV ao prximo roteador a upstream. - Quando o ltimo roteador (mais prximo da fonte) recebe a mensagem RESV e aceita a requisio, ele envia uma mensagem de confirmao ao receptor. - O RSVP opera com o conceito de soft state, o que significa que o transmissor e o receptor devem enviar periodicamente mensagens de PATH e RESV para revalidar (ou atualizar) as reservas feitas. Esta caracterstica permite reao dinmica a alteraes ocorridas na fonte do fluxo, nos parmetros de QoS estabelecidos pelo receptor, ou na rota. [http://www.rnp.br/newsgen/0005/rsvp.html]

PARMETROS QUE INFLUENCIAM NA QoS DA TECNOLOGIA VoIP

Ainda hoje existem pessoas defendendo que os usurios preferem trocar qualidade por preo, no entanto existem outras pessoas que defendem que sem uma qualidade mnima este servio de voz sobre ip no ir se consolidar. So vrios os obstculos percorridos para que se possa garantir qualidade de servio em redes IP:

Atraso

o tempo gasto por um pacote para ir da origem ao seu destino. Sobre voz, significa dizer que o tempo que a voz leva do momento que pronunciada at o momento em que produzida. Em redes no ponto a ponto o atraso implica no somatrio dos atrasos inseridos pela rede e pelos equipamentos.

71

Fig. 3.15: Transmisso e Recepo de pacotes. [Inatel, p. 11]

Este atraso decorrente de vrios aspectos como, por exemplo, qualidade do meio de transmisso, algoritmos utilizados para codificao de voz e supresso de silncio, estes aspectos atingem diretamente a QoS. Para o usurio este atraso se reflete da seguinte forma: o locutor ir perceber um intervalo entre suas falas igual a duas vezes ao atraso. Este tempo recebe o nome de roundtrip, que corresponde a duas vezes o atraso.

Tabela 3.2: Classificao do atraso. [VoIP_Ramon.pdf, p.29]

A figura acima determina a classificao do atraso segundo o ITU-T, para os valores que so ou no aceitveis para o usurio. O atraso final, percebido pelo usurio, na verdade gerado por uma srie de outros pequenos atrasos: - Atraso de formao de pacote: o tempo necessrio para o preencimento do pacote de voz a ser enviado. Estes atrasos so da ordem de 20 a 30 ms. - Atraso de rede: Tempo necessrio para o transporte pela rede do pacote da origem at o destino. Este tempo varivel pois depende da carga na rede. Tanto o computador de origem e/ou destino como o gateway so providos de um mecanismo de formao do pacote e outro correspondente para reproduo de voz.

72

Fig. 3.16: Atraso na formao de pacotes. [VoIP_Ramon.pdf, p.29]

A figura acima ilustra os responsveis pelo atraso na formao de pacotes e a figura abaixo mostra o atraso em cada etapa da transmisso.

Fig. 3.17: Atraso em cada etapa da transmisso. [gta-Alexandre-UFRJ]

73

Eco

Eco um fenmeno fsico que se realiza atravs da repetio dum som. causado devido ao atraso, se o atraso fim-a-fim for maior que 25 ms, dever haver um mecanismo para se cancelar o eco. Por que 25 ms? Porque este tempo que o ser humano suporta (confunde-se com o som da prpria voz) ouvir sua prpria voz, sem que esta cause desconforto a ele. Nas redes de telefonia tradicionais o eco ocorre devido a um decasamento de impedncia nas hbridas utilizadas para converso dos quatro fios do n de comutao para os dois fios do cabo telefnico tradicional.

Sobreposio do Locutor

Sobreposio do locutor ocorre quando o locutor A fala algo para B, no entanto a mensagem de A leva muito tempo para chegar em B. B que ainda no sabe que A o enviou uma mensagem, envia uma mensagem para A. Esta demora de B na escuta da fala de A, e o incio da conversao de B sem antes ter ouvido a mensagem de A caracteriza a sobreposio do locutor. Esta sobreposio do locutor ocorre tambm devido ao atraso, sendo que para se evitar este tipo de falta de QoS, o atraso deve ser inferior a 400 ms, sendo recomendvel pelo ITU-T o limite de 200 ms.

Jitter

Jitter significa a variao do atraso da transmisso das informaes. causado pelas variaes no trfego e alteraes no roteamento.

74

Fig. 3.18: jitter [Inatel, p.12]

Este problema tratado atravs da supresso de jitter, isto significa que necessrio um armazenamento de pacotes por um tempo superior ao maior jitter observado, no entanto essa resoluo gera um novo atraso, o atraso de supresso de jitter.

Perda de Pacotes

A perda de pacotes significa que um pacote enviado no conseguiu atingir seu destino e isto implica na perda de qualidade para a aplicao, sendo que esta qualidade tem seu limite variado de aplicao para aplicao. Estas perdas so causadas pelo descarte de pacotes ocasionado pelos congestionamentos freqentes em redes ip, atrasos excessivos e erros na tecnologia de transporte. Umas das solues seria a utilizao de protocolos de transporte confiveis como, por exemplo, o TCP, no entanto os atrasos gerados pelo seu uso tornam-no inutilizvel para este tipo de aplicao. Portanto at o presente momento a perda de pacotes inevitvel, isto reflete significativamente na QoS de VoIP.

SOLUES PARA GARANTIA DE QoS EM REDES IP

Vrios so os problemas percorridos pela QoS para se atingir um nvel aceitvel, e atravs de vrias tcnicas podemos hoje dizer que sim, ns conseguimos chegar a um nvel aceitvel em transmisses VoIP. 75

As tcnicas utilizadas so as mais variadas possveis, que vo desde prover qualidade atravs de reserva de banda, minimizao de atrasos de pacotes at eliminao de jitter de atraso. A seguir veremos algumas dessas tcnicas.

Dejitter Buffer

Um dos vrios problemas sofridos pela VoIP so as variaes de atrasos (jitter), e para minimizar ou at mesmo eliminar este problema, usamos uma tcnica chamada dejitter buffer, que significa utilizar buffers na recepo de informaes. Esta tcnica armazena os pacotes recebidos por um certo tempo e adiciona ao pacote um atraso antes de envia-lo ao receptor, desta forma o atraso total dos pacotes fica igual.

Classificar ou Identificar o Trfego

Na rede atual onde os pacotes de VoIP trafegam, cada tipo de informao recebe um tratamento diferente dos ns da rede. A soluo ento seria, classificar os tipos de pacotes que esto trafegando na rede. A classificao por si s, somente prover efeitos quando em conjunto com outras tcnicas como, por exemplo, polticas de priorizao da transmisso, pois somente o trfego de pacotes classificados pelos roteadores e switchs no teria efeito algum, o rotedor/switch apenas saberia que o que passou por ali era um pacote classificado como, por exemplo, pacote de voz ou vdeo. Com a adio de outras tcnicas, por exemplo, poltica de priorizao da transmisso, o pacote ao chegar a um roteador/switch poderia ser rapidamente passado frente ou colocado em uma fila de espera. Esta poltica poderia classificar os pacotes de diferentes formas: informao contida no pacote, porta de destino, MAC, endereo fonte/destino, etc. e esta classificao pode ser feita por dispositivos de borda ou pelos dispositivos de backbone da rede, preferencialmente deve ser feita na rede LAN antes do pacote ser enviado a redde WAN. [cefetrio]

76

Enfileiramento, Priorizao e Disciplina de Despacho

Sabe-se que uns dos grandes problemas enfrentados pelas redes IP hoje em dia so os congestionamentos. Para minimizar este problema foram implantados nos roteadores buffers que servem para armazenar temporariamente os pacotes que chegam at ele, estes pacotes armazenados em buffer so colocados em forma de fila. A idia ento da disciplina de despacho organizar esta fila que montada pelo roteador, de forma que os pacotes ganhem prioridades uns em cima dos outros, conforme informaes que eles esto trafegando. Sendo assim os pacotes de voz teriam prioridade sobre os pacotes de dados, o que levaria a minimizar os atrasos sofridos pelos pacotes de voz, j que estes seriam rapidamente despachados pelo roteador. Vrias tcnicas de disciplina de despacho so implementadas para se obter uma maior qualidade de servio em redes que trafegam voz sobre IP, algumas delas so:

Policiamento e Conformao de Trfego

As funes de policiamento e conformao usualmente identificam as violaes no trfego de uma mesma maneira. Elas diferem, contudo, na forma como elas respondem a estas violaes, por exemplo:

- A funo de policiamento usualmente descarta o trfego que no est conforme ou o define como elegvel para descarte. - A funo de conformao tipicamente atrasa o trfego em excesso, atravs de mecanismos de enfileiramento, retendo os pacotes e liberando-os de maneira tal que o fluxo de sada esteja dentro dos parmetros definidos. [cefetrio]

Fragmentao

Tambm caracterstico do trfego VoIP, a presena de grandes pacotes de dados. A tcnica de fragmentao prope justamente a este tipo de trfego uma soluo que seria, fragmentar pacotes de dados que excedam a um mximo proposto em pacotes menores, sendo estes pacotes menores tratados de forma independente pela rede. Esta tcnica eleva vantagens como: diminuio do tempo mdio de enfileiramento de pacote, que faz com que o pacote chegue mais rapidamente ao destino, e do desvio padro

77

deste tempo, que resulta na diminuio do jitter de atraso na rede, o que vem a melhorar a qualidade do sinal. [cefetrio]

SEGURANA EM REDES VOZ SOBRE IP

Introduo

Com o desenvolvimento das novas tecnologias, tornou-se possvel a evoluo dos sistemas de transmisso, o que viabilizou a criao de redes de pacotes muito mais velozes. Todo este desenvolvimento tem permitido a evoluo das redes convergentes, que so redes capazes de transportar pacotes de dados e voz digitalizados. Hoje contamos com vrios tipos de redes que so capazes de transportar pacotes de dados e voz, por exemplo, redes baseadas em ATM, Frame Relay e TCP/IP. Destas apenas o Frame Relay e o TCP/IP so utilizados com mais freqncia, embora o ATM tenha sido projetado para tal finalidade. O Transporte atravs da tecnologia Frame Relay e TCP/IP so conhecidos como VoFR e o VoIP. A diferena entre a utilizao de tais redes referente ao seu custo/beneficio. As redes IP, esto associadas a camada 3 no modelo OSI, o que lhe da muitas vantagens, entre elas o baixo custo e capacidade de operao em redes heterogneas, em contrapartida recebe como desvantagens a qualidade de servio e questes relacionadas com a segurana. J as redes VoFR e VoATM, esto associadas com a camada 2 do modelo OSI, que ento apresentam como vantagem, maior qualidade de servio pois requerem redes homogneas para o trfego de informaes, e como desvantagem, um custo elevado. [MSLAB, p. 2]

78

Ameaas

Hoje, ainda so mnimos os ataques documentados em cima de redes VoIP, talvez pela ainda no familiarizao dos invasores com os protocolos desta tecnologia. No entanto j sabido que em um curto espao de tempo, esta realidade tomar rumos diferentes, isto se deve a vrios motivos, um deles pelo valor das informaes que trafegam pelas redes VoIP, e que em mos erradas podero causar grandes prejuzos e lucros a diversas pessoas. importante ressaltar que na convergncia das redes de voz com as redes de dados baseadas em TCP/ IP, houve tambm a convergncia das vulnerabilidades inerentes as duas tecnologias. Ou seja, agora, um computador com telefone IP-compatvel precisa ser protegido tanto das ameaas relacionadas aos computadores quanto das ameaas relacionadas com a telefonia. Por exemplo, um telefone IP instalado em uma estao de trabalho com o sistema operacional Windows est suscetvel s vulnerabilidades do Windows. [MSLAB, p. 3]

Captura de trfego e acesso indevido a informaes

Nas Redes que trafegam voz sobre IP, a voz transportada juntamente com as informaes da rede de dados, encapsulado em pacotes IP, e a captura destes pacotes em uma rede IP atravs de tcnicas de "Sniffing" relativamente trivial. Hoje j podemos contar com algumas ferramentas que facilitam este trabalho para o usurio, por exemplo, o VOMIT (Voice Over Misconfigured Internet Telephones), que utiliza a ferramenta tcpdump do Unix para capturar pacotes de uma conversa telefnica, que est trafegando na rede de dados e consegue remont-los e convert-los em um formato comum de udio (*.wav). Ou seja, tratase de uma espcie de "grampo telefnico" em plena rede de dados. No entanto estas ferramentas esto comeando a surgir agora na internet e ainda encontram-se limitadas a alguns padres existentes, por exemplo, o CODEC G.711 utilizado pela Cisco. Devemos ressaltar que questo de tempo para que ferramentas mais poderosas se

79

adentrem internet, j que os mecanismos de transporte de voz, por enquanto, no utilizam criptografia, deixando assim os pacotes vulnerveis qualquer destas ferramentas existentes. Vrias outras tcnicas que podem ser ou no mais complexas podem ser utilizadas pelos atacantes para obteno de acesso indevido s informaes que trafegam pela infraestrutura onde se localiza a rede VoIP. Por exemplo, no ataque de Caller Identity Spoofing (algo como falsificao da identidade do usurio que iniciou a chamada), o atacante induz um usurio remoto a pensar que ele est conversando com alguma outra pessoa, ou seja, finge ser algum que no para obter informaes sigilosas. Este tipo de ataque requer apenas que o atacante obtenha acesso fsico rede e consiga instalar um telefone IP no autorizado. Outra tcnica que pode ser utilizada a de (MAC Spoofing), o atacante dever conseguir que seu telefone IP assuma a "identidade" de um telefone IP vlido da rede empresa. Boas polticas aplicadas nas empresas podem ser uma boa soluo quando se pretende evitar estes tipos de ataques, a integridade da rede aumentar ainda mais se for possvel combinar as polticas com uma boa administrao da rede, por exemplo, sempre obtendo controle de pontos de rede ativos que no esto sendo utilizados. O treinamento e a boa orientao dos usurios destes tipos de rede, culminaro na dificuldade dos atacantes em se aplicar engenharia social, assim seria mais difcil de se induzir algum que o atacante quem ele no . [MSLAB, p. 4]

Cdigo Malicioso

Como j vimos anteriormente, a tecnologia VoIP est presente nas redes convergentes, ou seja, aquelas redes que trafegam dados e voz no mesmo meio fsico. Portanto a tecnologia VoIP tambm esta susceptvel s vulnerabilidades da rede de dados. Algumas das vulnerabilidades que tambm podem afetar as redes de voz, so os conhecidos vrus, Trojan Horses e outros tipos de cdigos maliciosos que podem vir a infectar os sistemas de telefonia IP baseados em PCs, os Gatewayse outros componentes crticos da infra-estrutura. Sendo assim, podemos concluir que at mesmo tcnicas que no surgiram para afetar as redes VoIP, podem causar a paralisao deste servio. [MSLAB, p. 5]

80

Fraude Financeira, Uso indevido de recursos corporativos

Uma das ameaas s redes VoIP a ameaa de Toll Fraud. Esta ameaa consiste no uso no autorizado dos servios de telefonia IP ou mtodos de fraude para iludir os mecanismos de bilhetagem e cobrana das ligaes realizadas. Existem vrios mtodos para se aplicar esta tcnica. Um deles pode ser o uso indevido de um telefone IP para realizao de chamadas que sejam contabilizadas como tendo sido originadas pelo endereo do telefone IP de alguma outra pessoa, a qual seria ento responsvel ate o momento pelos gastos. Um mtodo mais sofisticado envolveria a instalao de um Voice Gateway (ponto de convergncia entre a redes) falsificado pelo atacante, pois neste Gateway que passam todas as ligaes. Caso o Voice Gateway principal no seja comprometido, o atacante dever tentar instalar na rede um segundo Gateway e tentar redirecionar para ele o trfego destinado ao host original. Desta forma, possivel bloquear, desviar e at mesmo escutar ligaes. [MSLAB, p. 5]

Repdio

Repdio em relao tecnologia VoIP tem a ver com a negao, por parte de um usurio que utilizou os servios de telefonia IP para fazer uma ligao, de que ele tenha realmente feito tal ligao. Isto s poder ser comprovado com a implantao de algum mecanismo eficiente para autenticao, do contrrio, no ser possvel identificar os usurios dos servios, nem discriminar quem executou quais chamadas a partir de quais telefones IP. Indisponibilidade de servios

Devido utilizao da rede de dados para se transportar voz, esta tambm torna-se vulnervel aos ataques no s destinados ela como tambm aos destinados rede TCP/IP. Um exemplo ao qual ela torna-se vulnervel ao ataque de DoS ( Denial of Service), os

81

quais causam a paralisao dos servios em redes TCP/ IP, sendo assim esta paralisao afetar por tabela os servios de voz, fax e vdeo que dependam deste transporte. So vrios os ataques que podem causar negao se servio em redes TCP/IP, entre eles podemos citar o TCP SYN Flood e suas variaes, e tambm a explorao de falhas nas pilhas de protocolo dos sistemas operacionais, como no Ping of Death, LAND, Teardrop e vrios outros ataques que podem tornar os servios do VoIP indisponveis. Nas redes VoIP, os equipamentos de PBX (Private Branch Exchanges) tradicionais so substitudos por aplicaes PBXs IP-compatveis que so executadas, por exemplo, em servidores Windows NT. Estas aplicaes de Call Management so crticas para a infraestrutura de VoIP, e no entanto esto sujeitas aos ataques que exploram vulnerabilidades no s das prprias aplicaes como tambm do sistema operacional. [MSLAB, p. 5]

Meios de proteo

A seguir so apresentadas algumas prticas para a implantao de uma estrutura VoIP segura.

Segmentar o trfego de voz e dados

As segmentaes do trfego de voz e dados podem ser feitas utilizando Switches. Esta segmentao contribui para obteno de uma melhor QoS alm de facilitar a gerncia da rede de voz e simplificar sua manuteno. Ainda podemos com isso evitar que o segmento de voz seja alvo de ataques de eavesdropping (captura no autorizada do trfego de conversas telefnicas que trafegam na rede encapsuladas em pacotes IP) realizados com o VOMIT e outras ferramentas semelhantes. Com a implementao da segmentao, vrios outros ataques deixam de existir para a rede de voz, como por exemplo, os ataques baseados em TCP/IP que, mesmo destinados a outros alvos que no estejam diretamente relacionados com a infra-estrutura de VoIP, podem tornar estes servios indisponveis caso todo o trfego esteja no mesmo segmento. 82

Por exemplo, os telefones IP normalmente utilizam o protocolo UDP com portas acima de 16384 para sua comunicao. Sendo assim, um ataque de negao de servios baseado em UDP Flood no segmento de dados poderia afetar tambm os servios de voz se as redes no estiverem adequadamente segmentadas. Para que se possa melhorar ainda mais os vrios aspectos citados da rede de voz, recomenda-se a separao dos segmentos de rede de voz e dados em VLANs distintas. Como por exemplo, em uma instalao de pequeno porte, uma VLAN dedicada ao trfego de voz seria suficiente, onde seriam instalados o Call Manager e os telefones IP. Outros componentes como estaes de gerenciamento e sistemas de Voice/Mail podem residir no segmento de dados. J em instalaes de grande porte, vrias VLANs podem ser criadas, tanto para voz quanto para dados. Por exemplo, os servios de Voice/Mail podem ocupar uma VLAN dedicada. [MSLAB, p. 6]

Controlar o acesso ao segmento de voz com um Firewall especializado

O uso de um firewall especializado servir para controlar o acesso ao segmento de rede onde est instalado o Call Manager, este tem como objetivo, filtrar todo o tipo de trfego que seja endereado rede de voz e no seja necessrio para o funcionamento destes servios. O firewall ir proteger o Call Manager de acessos indevidos por parte de telefones IP no autorizados que sejam instalados em outros segmentos. Logo, as portas e protocolos que sero configuradas no firewall iro depender do tipo de soluo/fabricante de soluo VoIP em uso. Um aspecto importante ao qual deve-se estar atento ao de que o firewall deve ser compatvel com o protocolo H.323. Isto deve-se ao fato de que este protocolo aloca portas de forma dinmica para canais de udio, vdeo e dados. Alguns fabricantes oferecem aplliances de firewall/VPN customizados para suas tecnologias, como por exemplo o Contivity Secure IP Services Gateway da NORTEL. [MSLAB, p. 6]

83

Evitar o uso de aplicaes de telefones para microcomputadores (PC-Based IP phones), utilizando preferencialmente telefones IP que suportem VLAN

No recomendvel a utilizao de SoftPhones, convm utilizar telefones IP que suportem VLANs, j que os SoftPhones esto sujeitos a um maior nmero de ataques que os aparelhos de telefonia IP baseados em hardware. Alm do risco de falhas em seu prprio cdigo, as aplicaes de telefone IP para PCs esto sujeitas s vulnerabilidades do sistema operacional e tambm de outras aplicaes que residem no computador onde esto instaladas, bem como vrus, worms e outros cdigos maliciosos. J os telefones IP executam sistemas operacionais proprietrios com servios limitados (e portanto menos vulnerveis) . Alm disso, como as aplicaes de telefone IP para PC precisam residir no segmento de dados da rede, elas so susceptveis a ataques de negao de servios (como floods baseados em UDP ou TCP) que sejam destinados ao segmento como um todo, e no apenas ao computador em que esto instalados. [MSLAB, p. 7]

Usar endereos IP privativos e invlidos (compatveis com RFC 1918) nos telefones IP.

Nos telefones IP devem ser utilizados endereos IP invlidos. Esta medida servir para reduzir a possibilidade de que o trfego de voz possa ser monitorado de fora da rede interna e para evitar que os atacantes consigam mapear o segmento de voz em busca de vulnerabilidades. Alm disto o uso de IPs invlidos sucumbir em menores custos. A utilizao de endereos IP privativos e principalmente de classes diferentes nos segmentos de voz e dados, de acordo com a orientao do RFC 1918 ( Address Allocation for Private Intranets), servir para facilitar a configurao de filtros e a monitorao. As conexes com redes externas devem utilizar endereos IP vlidos fornecidos por um firewall, atravs do servio NAT ( Network Address Translation) . [MSLAB, p. 7]

84

Configurar os telefones IP com endereos IP estticos, associados ao MAC Address

A utilizao do MAC Address permite a autenticao dos telefones IP ou seja quando um telefone IP tenta obter configuraes da rede do Call Manager, seu Mac Address pode ser verificado em uma lista de controle de acesso. Caso o endereo seja desconhecido, o dispositivo no receber a configurao. Caso seja possvel, deve-se aplicar endereos IP estticos para os telefones IP, e associa-los ao Mac Address do dispositivo. Sendo assim, cada telefone IP ter sempre o mesmo endereo IP associado ao endereo MAC. Desta forma, para conseguir instalar um telefone IP no autorizado na rede, um atacante teria que forjar tanto um endereo IP vlido para o segmento de voz quanto o endereo MAC a ele associado. Alguns aspectos devem ser considerados antes de tal aplicao pois, dependendo das caractersticas do ambiente da implantao, a associao entre endereo IP esttico e Mac Address nos telefones IP pode ser de difcil gerenciamento. [MSLAB, p. 8]

Utilizar servidores DHCP separados para voz e dados

Preferencialmente deve-se utilizar servidores DHCP separados para os segmentos de voz e dados. Sendo assim, os ataques de negao de servios (DoS) e outros lanados contra o servidor DHCP no segmento de dados no vo interferir com a alocao de endereos IP para os telefones no segmento de voz, e vice-versa, o que aumenta a tolerncia da rede. [MSLAB, p. 8]

85

Monitorar os endereos MAC no segmento de voz

A utilizao de ferramentas como, por exemplo, o ARPWATCH para monitorar os MAC Addresses de todos os dispositivos instalados no segmento de voz trar mais segurana rede. O ARPWATCH capaz de registrar alteraes no autorizadas na associao entre endereo IP e endereo MAC. [MSLAB, p. 8]

Implementar mecanismos que permitam autenticar os usurios dos telefones IP

Se a tecnologia em uso atualmente suportar, convm implementar os recursos de autenticao dos usurios dos telefones IP, alm de autenticar apenas os dispositivos atravs de seus endereos MAC. Hoje j podemos encontrar com certa facilidade, alguns modelos de telefones IP que exigem do usurio um login e uma senha ou nmero de identificao (PIN) vlidos para que possam utilizar o dispositivo. Este tipo de autenticao reduz os riscos de uso indevido dos recursos da rede de voz, e permite maior rastreabilidade no uso dos servios, alm de um certo nvel de no repdio. Algumas aplicaes de telefone IP para a plataforma Windows suportam autenticao integrada ao sistema operacional, enquanto outros modelos utilizam uma combinao de nome de usurio / PIN. Em qualquer caso, as senhas utilizadas devem ser trocadas periodicamente e devem ser de difcil deduo. [MSLAB, p. 8]

Implementar um sistema IDS

sabido que os sistemas atuais de deteco de intruso (IDS) ainda no so compostos pelas assinaturas especficas de ataques para os protocolos de VoIP, no entanto 86

eles podem ser teis para monitorar ataques baseados em UDP e HTTP que podem ser executados contra os componentes da infra-estrutura. Por este motivo, convm que uma aplicao ou aplliance de IDS seja instalado no segmento onde estiver instalado o Call Manager, visando a deteco de ataques originados principalmente no segmento de dados, onde esto localizadas as estaes de trabalho dos usurios. Naturalmente, necessrio fazer o tunning do IDS para maximizar sua eficincia. Esta operao dependente do tipo de tecnologia e protocolos de VoIP em uso. De qualquer forma, se tiverem sido separados os segmentos de voz e dados como recomendado, o trfego esperado no segmento de voz estar obrigatoriamente associado a um nmero limitado de protocolos e portas, o que facilita a configurao do IDS e reduz o nmero de falsos positivos. Qualquer trfego TCP/ IP que no esteja relacionado aos protocolos utilizados pela tecnologia VoIP em uso deve gerar alarmes no sistema IDS. [MSLAB, p. 9]

Fazer o hardening do host onde est instalado o call manager

Preferencialmente os atacantes tentam explorar as vulnerabilidades do Call Manager da infra-estrutura de VoIP, devido ao grande nmero de servios que podem estar sendo oferecidos por estas aplicaes. O Call Manager, por exemplo, normalmente disponibiliza aplicaes para controle de chamadas, permite a configurao via Web, d suporte a servios de localizao de telefones (IP Phone browsing), servios de conferncia, e gerenciamento remoto por SNMP. Por este motivo, convm que sejam implementados procedimentos para a configurao segura (Hardening) do servidor onde o Call Manager est instalado. Como recomendaes genricas, convm desabilitar todos os servios desnecessrios, instalar os patches do sistema operacional e um bom antivrus. Os servios inicializados pelo Call Manager devem utilizar contas de baixo privilgio, e o acesso fsico ao servidor deve ser restrito a usurios autorizados. [MSLAB, p. 9]

87

Monitorar a performance e status dos servios de VoIP

O objetivo deste controle permitir a monitorao peridica, se possvel em tempo real, do desempenho da rede de voz, e detectar instabilidades, atrasos e latncias que possam comprometer a performance ou disponibilidade dos servios. A monitorao pode ser feita atravs de solues proprietrias disponibilizadas pelos fabricantes (Cisco, etc) , ou de solues de mercado como o VoIP Manager da Net IQ ou o VoIP Test Suite da Brix Networks. [MSLAB, p. 10]

Montar uma estrutura de Help Desk capacitada para dar suporte em VoIP

Apenas uma boa implantao da estrutura VoIP no suficiente para garantir sua perfeita funcionalidade durante o decorrer do tempo, devemos aplicar mtodos que ajudaram a manter esta implantao em perfeito funcionamento durante sua existncia no ambiente. Para isso deveremos, se possvel, ter presente no ambiente que foi implantando a estrutura VoIP uma equipe treinada para realizar configuraes necessrias nos equipamentos (Switches, Roteadores e etc) e aplicaes utilizados pela rede de voz alm de prestar suporte tcnico para os usurios. Tambm conveniente manter um contrato de Suporte Tcnico com algum integrador qualificado, ou com o prprio fabricante dos equipamentos adquiridos. [MSLAB, p. 10]

Restringir o acesso fsico

O acesso fsico rede em si deve ser restrito, isto devido possibilidade de algum atacante conseguir acesso fsico indevido na rede e atravs dessa vulnerabilidade conseguir tirar proveitos. Com acesso rede fsica o atacante pode, por exemplo, instalar um telefone IP 88

no autorizado e utilizar tcnicas de MAC Spoofing e Caller Identity Spoofing para enganar os usurios, fazendo-os pensar que esto conversando com alguma outra pessoa, quando na verdade esto conversando com o atacante. Desta forma informaes sigilosas podero ser obtidas atravs de engenharia social. Naturalmente, o acesso fsico indevido tambm expe os componentes da infraestrutura de VoIP a ameaas como fraudes, roubo, sabotagem ou danificao acidental ou proposital dos equipamentos, podendo causar a indisponibilidade dos servios. Por estes motivos, convm que o acesso fsico aos dispositivos mais crticos da rede (Switches, Roteadores, Call Manager, Firewalls, etc), seja restrito apenas usurios autorizados. [MSLAB, p. 10]

Auditar o uso dos recursos

A verificao da qualidade de servio prestada pelos equipamentos VoIP bem como sua utilizao pelos usurios deve ser auditada periodicamente. Para isso devemos manter registros das informaes sobre as sesses (data e horrio do incio e trmino, durao, origem, destino, etc) alm de informaes relacionadas a QoS (latncia, perda de pacotes, uso de banda, etc).A auditoria pode ser implementada atravs de aplicaes especializadas. Para um auditoria mais prescisa, recomendamos que os usurios utilizem algum tipo de autenticao quando utilizarem os servios da rede de voz. [MSLAB, p. 10]

Criptografar o trfego de VoIP

Recomendamos a criptografia de todo o trfego passante entre o telefone IP e o Call Manager. Esta medida tem como objetivo impedir o uso de ferramentas como o VOMIT para violao da confidencialidade das conversaes. Um exemplo de criptografia que pode ser utilizada para tal ambiente seria a implantao de um tnel IPSec entre as estaes com telefones IP e o Call Manager. Para 89

as comunicaes externas (matriz com filiais, por exemplo), deve-se considerar a implementao de uma VPN (Virtual Private Network) para criptografar o trfego de VoIP. [MSLAB, p. 10]

Concluso

Assim podemos entender todos os riscos (telefones IP, roteadores, Switches, Gateways, sistemas de Voice Mail, Firewalls e outros) e problemas (delay, jitter, perda de pacotes, Toll Fraud ( fraudes de pagamento), IP Phone Spoofing, etc) inerentes pelos quais as redes de voz esto vulnerveis. Compreendemos ainda que estes riscos e problemas aumentam caso a estrutura da rede de voz esteja na mesma estrutura da rede de dados, pois assim a rede de voz herdar todos os perigos das redes de dados (mapeamentos, TCP/IP Denial of Service, explorao das vulnerabilidades dos sistemas operacionais, engenharia social, roubo de identidade e spoofing, etc), isto porque a convergncia das redes traz tambm a convergncia das ameaas. sabido tambm que um bom sistema de autenticao no s dos dispositivos (telefone IP e etc) como tambm do usurio essencial para um perfeito controle do ambiente da rede de voz, evitando assim que ferramentas como o VOMIT possam vir a comprometer a confidencialidade das conversas telefnicas, permitindo acesso indevido a informaes sigilosas, alm de outros problemas como repdio etc. Hoje ainda no podemos contar com nenhuma soluo completa para as redes de voz, o que poderia vir a fornecer um ambiente mais homogneo e mais seguro do que os ambientes atuais. No entanto devemos estar cientes de que quando mais separada a rede de dados da rede de voz melhor, e que seguindo as recomendaes que surgem sobre segurana VoIP, estaremos minimizando as ocorrncias de ameaas ao ambiente, tornando-o cada vez mais seguro. A implantao de um sistema VoIP em qualquer ambiente requer de incio um bom planejamento da infra-estrutura, um cabeamento adequado, dispositivos que suportem as demandas de QoS requeridas, uma segmentao apropriada da rede, planejamento de servios como o DHCP. A implantao de uma Poltica de Segurana muito importante, e deve preceder a configurao de Switches, Roteadores, FireWalls, solues de IDS e outros

90

dispositivos de proteo, cujo acesso fsico deve ser restrito a usurios autorizados. O uso de criptografia do trfego de voz encapsulado na rede IP recomendado em certos contextos. Os equipamentos (por exemplo, telefones IP que suportem VLAN e solues que ofeream recursos de autenticao mais sofisticados) devem ser escolhidos de forma mais crtica para viabilizar um maior nvel de segurana, bem como o treinamento do pessoal envolvido na instalao, suporte e auditoria dos servios. Em alguns casos, at mesmo um plano de Disaster Recovery deve ser considerado, tal o impacto que a descontinuidade dos servios de voz pode trazer para a corporao. Finalmente, preciso conscientizar os usurios dos servios VoIP no ambiente corporativo sobre os riscos existentes, j que em muitos casos eles prprios podero ser responsabilizados pelo uso indevido, fraude e outras aes maliciosas executadas pelos atacantes.

Benefcios da Convergncia

Reduo de custos Na infraestrutura convergente alm de se aproveitar o cabeamento, as operaes ficam mais simplicadas, as rotas tem um menos custo devido ao compartilhamento dos circuitos e a rede apresenta maior escalabilidade. [innovagency]

Ganhos de produtividade As redes convergentes apresentam ganho de produtividade pois permite mobilidade, ou seja, conectividade para o usurio onde quer que ele esteja e em qualquer momento, sendo assim as empresas podem aplicar o teletrabalho que aumenta a produtividade em at 50% e a motivao em at 30%. [innovagency]

Melhoria da Eficcia de pessoas e organizaes: As pessoas tornam-se mais eficazes perante uma rede convergente pois, as comunicaes tornam-se unificadas, a colaborao entre pessoas aumenta consideravelmente, os recursos so alocados de forma otimizada, independente da localizao geogrfica.

O ritmo do projeto de convergncia importante Processo de melhoria constante Implementao baseada: comear por onde fizer sentido [innovagency] 91

Convergncia chegou, e est para ficar ! No se perspectivam novos desenvolvimentos na voz tradicional (TDM)

Riscos e Inibidores da convergncia

No existem, neste momento, entraves de maior. Benefcios evidentes Tecnologia disponvel. [innovagency]

Mas alguns aspectos pertinentes podem atrasar a implementao Salientamos que mesmo com as diversas vantagens apresentadas para se utilizar redes convergentes, de nosso parecer que sempre que for possvel deve-se utilizar circuitos independentes de dados e voz devido a diversas caractersticas como, por exemplo: Segurana, Gesto de SLA, QoS & Desenho de rede, Interoperabilidade de standards, Existncia de know-how interno organizao, Monitorizao & gesto da qualidade VoIP.

92

SPIT em geral

1. Origem e significado

A expresso spit teve sua provvel origem no artigo publicado por Bruce Schneier na data de 13 de maio de 2005 em seu blog Schneier on Security. [schneier]

2. Prejuzos causados pelo spit

So diversos os prejuzos causados pela tcnica de spit, entre eles podemos citar:

1. Os custos que o spammer tem para manter sua conexo com a Internet, conta como o provedor, linha telefnica e energia eltrica. Sabemos ainda que quanto mais tempo se permanece on-line, maiores so os custos. No caso dos prejuzos causados pelo spit para os receptores, quem o recebe obrigado a ficar mais tempo ouvindo aquelas mensagens indesejveis deixadas no seu correio de voz, o que acaba gerando custos com energia eltrica, conexo com internet alm dos prejuzos psicolgicos (raiva, angustia, stress e etc); [schneier]

2. O segundo prejuzo a ser citado o tempo. Primeiro porque o receptor obrigado a ficar mais tempo on-line. Segundo por que se perde um tempo precioso para bloquear cada um dos nmeros telefnicos dos spammers, tempo este que poderia ser utilizado de forma mais til; [schneier]

3. O terceiro prejuzo fica por conta das enormes dificuldades e prejuzos para provedores e servidores tambm, visto que quanto mais spit acumulado, maior ser o custo de armazenamento e comunicao. Finalizando, o mau uso da Internet poder retardar o tempo de resposta das conexes. [schneier] 93

3. Envio de spit

O meio mais comum de envio do spit baseado no telemarketing, o spammer grava a mensagem e atravs de um mtodo automatizado envia a mesma, em massa para diversos destinatrios. Este sistema automatizado capaz de realizar ligaes aleatrias ou seqenciais e a cada atendimento o sistema dispara a gravao feita pelo spammer.

4. SPIT (spam over IP Telephony), abordagem geral

Um dos problemas previstos a acontecerem nas redes VoIP refere-se a uma tcnica j conhecida na telefonia tradicional como telemarketing e suas derivaes, em VoIP essa tcnica receber o nome de SPIT. Spit conhecido como sendo o spam over IP Telephony, em outras palavras, spit so as mensagens no solicitadas que chegam por meio de Voz sobre IP (VoIP) aos usurios da tecnologia. Esta uma tendncia derivada do spam, assim como muitas outras, que agora atinge os meios de comunicao de voz sobre ip. O spam sobre telefonia IP associado hoje em dia por alguns especialistas ao telemarketing, pois assim como o ele o spit poder/pode nos enviar mensagens indesejveis, em momentos indesejveis, com propostas indesejveis a quaisquer telefones. Logo podemos pensar que o spit por vez pode ainda contar com a vantagem da gratuidade da ligao, o que no ocorre no telemarketing. Devemos assim sobressaltar que este exemplo apenas uma analogia, pois podemos pensar em ambas as tcnicas com o sentido de invaso de privacidade, da insistncia em vender ou oferecer algo que o cliente realmente no pediu e nem est interessado. Assim podemos ver o spit como uma tcnica promissora pois desperta sentimentos em muitos, pois poderiam agora praticar o telemarketing de forma gratuita. Hoje infelizmente no podemos contar com nenhuma ferramenta especializada em combater o spit assim como encontramos ferramentas que combatem o spam. No entanto devemos ressaltar que mesmo as ferramentas especializadas em spam no conseguem elimina-lo completamente, apenas dribla-lo, isto porque na maioria das vezes os e-mails spam ficam armazenados nas pastas de quarentena.

94

Igualmente como o spam o spit ir acarretar problemas, pois tambm far uso de recursos computacionais alm de sobrecarregar a internet, principal veculo de transporte das redes VoIP. Desta maneira, os filtros ainda so e sero a soluo (paliativa) para o spam e o spit. Imaginemos ento, por enquanto, as diversas formas de spam como algo do nosso cotidiano que temos que conviver, pois no encontramos soluo para ela, assim iremos ate podermos dar a carta final ao spam dando dribles no cotidiano. [cicilini]

SEGURANA NOS PROTOCOLOS H.323 E SIP

SIP

Segurana na troca de mensagens

As mensagens SIP devem ser criptografadas por uma srie de motivos os quais englobam, por exemplo, no caso se a chave de criptografia de mdia tiver de ser protegida , os pedidos e respostas SDP devero ser criptografados, deve-se esconder a origem e o destino das chamadas e os campos de informao relacionados, deve-se evitar que o usurio receba mensagens enganosas alm do seu uso para contabilidade e tarifao. O protocolo SIP conta com vrios sistemas de segurana para se evitar vrias ameaas ao ambiente VoIP, como por exemplo, preservao da integridade e confidencialidade, preveno de ataques que possam vir a desviar mensagens, provocar DoS ou ainda proporcionar a autenticao de atacantes que possam vir a violar a privacidade dos participantes numa sesso. A criptografia das mensagens a melhor opo de segurana para a sinalizao, isto garante a confidencialidade e a integridade das mensagens. Porm o protocolo SIP no permite a criptografia das mensagens ponto a ponto, pois estas podem vir a trafegar por vrios outros equipamentos da rede como, por exemplo, Proxy Server cuja funo analisar os pedidos e respostas para que assim possa encaminha-los de forma correta. Naturalmente, o 95

Proxy Server poder ainda remover ou adicionar informaes como, por exemplo, os cabealhos Via. No entanto, caso seja necessrio tal grau de segurana, ser necessrio que a segurana seja aplicada em um nvel mais baixo, no qual as mensagens devero ser cifradas entre as entidades SIP e assim podero permitir aos terminais a verificao da identificao dos servidores destinatrios, para os quais so enviadas as mensagens de forma segura, utilizandose apenas de um sistema e autenticao criptogrfica. A soluo prevista no caso citado a cima o uso dos protocolos TLS (Transport Layer Security) [RFC 2246, 1999] e IPSEC [RFC 2401, 1998], os quais fornecero s camadas de transporte e rede um maior nvel de segurana, que permitir a integridade e confidencialidade das mensagens. Podemos tambm contar com os chamados SIPS URI que permitem o estabelecimento de sesses seguras, garantindo que utilizado transporte criptogrfico (TLS) para entregar as mensagens. A autenticao da identidade dos utilizadores fica por conta do mtodo Digest [RFC 3261, 2002], um mtodo de autenticao que se baseia no esquema de autenticao HTTP Digest, utilizado pelo protocolo HTTP. Este mtodo permite aos utilizadores identificarem-se perante uma entidade atravs do nome do utilizador e de uma palavra-chave cifrada, utilizando a informao que lhe fornecida pelas respostas 401 ou 407. Por exemplo, quando um utilizador se pretende registar num Registrar ou enviar um INVITE atravs de um SIP Proxy, o servidor responde com uma resposta 401 ou 407 indicando que necessria a sua autenticao e transportando as suas credenciais. Quando o utilizador recebe a resposta formula um novo pedido, que desta vez transporta a informao necessria para confirmar a sua identidade. Este mecanismo de segurana permite evitar ataques em que utilizadores mal intencionados assumem a identidade no autorizada de outros utilizadores; no entanto no garante a confidencialidade e integridade das mensagens. [sIPtel, p. 62]

Segurana da mdia

A criptografia de mdia especificada pelo SDP [RFC 2327]. O parmetro k do SDP armazena o algoritmo de segurana em uso bem como a chave. A RFC supracitada define os seguintes formatos: 96

K=clear:<chave de criptografia>

Esse formato refere-se aos algoritmos de criptografia descritos no RFC 1890 (perfil RTP para conferencias de udio e vdeo com controle mnimo). O RFC 1890 descreve primeiro como extrair uma chave a partir de uma pass phrase de uma forma padro. A pass phrase colocada em uma forma cannica (espaos em branco no inicio e no fim removidos, caracteres colocados em minsculo etc.) e, ento, dividida em 16 octetos pelo algoritmo MD5. Chaves com menos de 128 bits so formadas truncando-se o sumrio MD5. As chaves so extradas em ordem para os algoritmos que precisam de mais de uma (p. ex.: trs chaves para DES triplo). [Telefonia IP, p. 150] O nome do algoritmo em uso inserido antes da chave e separado dela com uma nica barra. Identificadores padro para os algoritmos mais comuns podem ser encontrados no RFC 1423: DES-CBC, DES-ECB; o padro DES-CBC. O RFC 1423 tambm descreve como armazenar parmetros adicionais necessrios para determinados algoritmos, como o vetor de inicializao de 64 bits do DES-CBC, por exemplo: K=clear:DES-CBC/aZ25rYg7/12eR5t6y

K=base64:<chave de criptografia codificada>

O formato o mesmo que o anterior, mas o base64 codificado para esconder caracteres no permitidos pelo SDP.

K=prompt

Solicita ao usurio uma chave. O algoritmo padro o DES-CBC. [Telefonia IP, p. 150]

Firewalls SIP

Os terminais SIP podem ser configurados para enviar todos os seus pedidos para um servidor proxy SIP, em vez de tentar alcanar o servidor SIP apropriado usando registros 97

DNS. O suporte nativo para o NAT ((Network Address Translation) uma tcnica usada para segurana, bem como para evitar problemas de re-endereamento) por parte das entidades SIP permite a configurao de sinalizao para comunicaes de sada sem nenhum requisito especfico no firewall. Mas, para os fluxos de mdia, o firewall prescisa estar ciente dos fluxos UDP que chegam, para repassa-los entidade apropriada. As chamadas que chegam precisam ser tratadas por um proxy de sinalizao SIP do firewall. [Telefonia IP, p. 152]

H.323

O H.235 o responsvel pela implementao de segurana nos ambientes H.323. Este protocolo implementa tamanha segurana que hoje em dia torna-se mais difcil escutar uma chamada telefnica H.323 do que grampear uma linha telefnica, uma vez que o atacante precisar implementar o algoritmo do codec. Alguns especialistas afirmam que em uma rede protegida pelo H.235, mesmo que o atacante tenha acesso livre rede IP, este no conseguir escutar qualquer conversa, alm disso o H.235 permite que o terminal chamador esconda o nmero de destino que est tentando alcanar. [Telefonia IP, p. 64] A segurana implementada pelo H.235 realizada atravs do uso de algoritmos de criptografia, que visam manter a privacidade, autenticao e integridade do trfego da rede. Atualmente o H.235 utiliza duas tcnicas principais de criptografia, a criptografia simtrica mais conhecida como criptografia de chave secreta e a criptografia assimtrica ou criptografia de chave pblica. Criptografia de chave secreta baseia-se em um mtodo onde destinatrio e emissor das mensagens compartilham um segredo, que pode vir a ser um algoritmo usado para codificar a mensagem ou uma chave usada como parmetro em um algoritmo bem conhecido. Criptografia de chave publica baseia-se em uma maneira pragmtica de se considerar a segurana da informao: algumas informaes esto seguras no apenas quando voc no sabe como extrair a informao, mas tambm quando voc sabe como extrair a informao, porm voc praticamente no pode faze-lo porque isso demandaria tempo demais para executar o algoritmo de extrao, mesmo para o mais rpido computador existente. [Telefonia IP, p. 64]

98

SNIFFERS VOIP

Com a convergncia das redes telefnicas normais para as redes telefnicas baseadas em pacotes. Muitas necessidades surgiram. Uma dessas necessidades a de controlar as redes VoIP. necessidade do administrador de rede, saber estatsticas atuais, momentneas sobre o trfego corrente dos pacotes VoIP. Para ajudar esses profissionais, hoje em dia no mercado j possvel contar com algumas ferramentas que os auxiliaram nesta jornada. Essas ferramentas so denominadas Sniffers. O principal papel do sniffer capturar todo o trafego (entrante/sainte), e trazer dados funcionais tela do administrador. Com esses dados o responsvel pela rede poder ento achar defeitos, monitorar, controlar o comportamento da rede conforme o nvel de trafego e/ou realizar uma percia sobre sua performance. Com isso ser possvel assegurar a QoS nas redes de voz sobre ip, alm de realalas em todos os nveis e alm disso poder otimizar a gerencia de voz, vdeo e dados sobre uma nica rede. E todas essas opes podero, atravs de Sniffers, serem realizadas em tempo real. [Sniffer] possvel saber se a rede comporta a demanda de usurios.

Caractersticas dos Sniffers VoIP

identificam os problemas de rede rapidamente; fornecem anlise para uma larga escala de protocolos VoIP; Oferecem anlise de problemas, tais como: o perda de pacotes; o atraso de pacotes; o pacotes que chegam fora de seqncia; o duracao das chamadas; o Tempo de resposta de comando.

99

Anlise completa das camadas de Aplicao e sesso para as conexes VoIP. Para a perfeita funcionalidade deste mdulo usase o protocolo Skinny Client Control Protocol (SCCP).

Realiza alertas preventivos, sobre possveis problemas da rede. [Sniffer]

EXEMPLO DE APLICAO DE SEGURANA EM REDES VOIP

Encriptao de VoIP no sistema omnipcx enterprise

A segurana vista, em alguns casos, como uma entrave adoo de telefonia sobre IP em detrimento de sistemas de telefonia tradicionais. Para obviar esta realidade a Alcatel desenvolveu, em conjunto com a empresa Thales (fornecedor reconhecido em mercados como a Defesa), uma soluo que garante a segurana do trfego de voz sobre IP, atravs de mecanismos como autenticao, integridade e encriptao dos fluxos de comunicao. Um nvel de segurana, responsvel pela encriptao, colocado entre os componentes da soluo OmniPCX Entreprise (Call Server, Media gateways e telefones IP) e a LAN ou a WAN, a partir das quais podero ser lanados ataques. Este nvel constitudo por hardware dedicado, denominado Call Server Security Module - SSM e Media Security Module - MSM, para proteco do Call Server e das Media Gateways, respectivamente. Os telefones IP, IP- Touch, suportam este servio de uma forma nativa . A voz encriptada utilizando SRPT (secure RTP) atravs do algoritmo de encriptao AES (modo contador). A vantagem do SRTP que no introduz overhead quando comparado com trfego no encriptado, simplificando tambm alguns dos servios na rede como sejam QoS, deteco de falhas e firewalling. So utilizadas chaves simtricas que mudam em cada nova sesso RTP e so enviadas pelo Call Server para os pontos terminais atravs de sesses de sinalizao encriptadas. A gesto da soluo feita a partir da plataforma OmniVista 4760, podendo ser integrada em clientes com siste mas Alcatel OmniPCX Enterprise. [Alcatel]

100

Concluso

A segurana deve ser encarada no como um produto mas sim como um conjunto de processos e mentalidades, na qual os equipamentos representam apenas uma das componentes. As empresas devem por isso ter uma estratgia clara na definio de solues de segurana, no que diz respeito ao desenvolvimento dos seus pro- dutos, bem como dos servios dispo- nveis quando integrados em redes de comunicaes IP. Esta , a nosso ver, uma estratgia evolutiva procurando acompanhar as constantes necessidades dos merca- dos empresariais.

101

Concluses

Visto que muito j foi feito pela tecnologia VoIP, podemos dizer que a tecnologia de transmisses de voz sobre IP pode funcionar muito bem sob as infra-estruturas que temos acesso hoje em dia, alm de ser uma tima opo quando pensa-se em reduo de custos. Depois de avaliar todas as caractersticas que a VoIP apresenta, salientamos que alm de todos os servios oferecidos pelas redes de telefonia tradicionais, ela apresenta muito mais por muito menos. Embora a VoIP esteja em alta e as redes tradicionais em desvantagem, sabido que a maior concorrente de VoIP so estas mesmas. Essa concorrncia presente na capacidade de as redes tradicionais terem uma disponibilidade elevadssima em comparao VoIP, e sua viabilidade. Apesar da VoIP ainda conter muitos aspectos desfavorveis como, por exemplo, ainda pouca qualidade de servio, outros aspectos vem favorecer como, por exemplo, o protocolo SIP, que apresenta nativo em sua ultima verso um bom nvel de segurana, o que leva uma grande aceitao da VoIP pelas empresas. Podemos tambm discursar sobre a consolidao da VoIP que por poucas atualizaes, pode vir a ser em pouqussimo tempo o novo boom que a humanidade presenciar depois da internet.

102

Referncias Bibliogrficas

HERSENT, OLIVER., GURLE, DAVID. E PETIT, JEAN-PIERRE. Telefonia IP. Traduo por Adriano Vilela Barbosa e Hugo Bastos de Paula: Makron, 2002. XAVIER, SIDINEY. Voz sobre IP na PBH. Belo Horizonte: PRODABEL/PUC, 2000. 50p. SOUZA, JOO PAULO PEREIRA DE. sIPtel Um sistema de IPtel com suporte para vdeo utilizando o protocolo SIP. Utad: Universidade de Trs-os-Montes e Alto Douro, 2003. 134p. MARQUES, ALEXANDRE FERNANDEZ. Segurana em Redes IP. 2001. 175p. FERNANDES, NELSON LUIZ LEAL. Voz sobre IP: Uma viso geral. 22p. Disponvel em: <http://www.ravel.ufrj.br/arquivosPublicacoes/nelson_voip.pdf>. Acesso em: 03 maio 2005. QUEIROZ, DANIEL CRUZ DE. Voz sobre IP em Redes Corporativas. Fortaleza: Universidade de Fortaleza/UNIFOR. 2002. 63p. GOMES, CARLOS HENRIQUE VICENTINI. Voz sobre IP. Santa Rita do Sapuca: Instituto Nacional de Telecomunicaes/INATEL. 34p. Disponvel em: http://www.inatel.br/posgraduacao/redes/download/VoIP_Pos_Graduacao_Brasilia.pdf Acesso em: 22 abril 2005 LEO, OSMAR RIBEIRO., Regras para proteo de redes IP. Universidade Catlica do Salvador. 2001. 118p. GALVO, MRCIO., ZATTAR, ALEXANDRE., Aspectos de segurana em redes voz sobre IP, MSLAB (Mdulo Security Lab), 2003, 13p. YOSHIOKA, SERGIO., Aspectos de Segurana em Telefonia IP, 2004, 62p. D. RICHARD KUHN, THOMAS J. WALSH, STEFFEN FRIES., Security Considerations for Voice Over IP Systems, 2005, 99p. < http://www.voip.nce.ufrj.br/index_curso_rnp.htm > acesso em: 20 maro 2005 < http://www.packetizer.com/voip/h323/ > acesso em: 28 maro 2005 < http://www.packetizer.com/voip/sip/ > acesso em: 28 maro 2005 < http://www.pr.gov.br/batebyte/edicoes/1999/bb90/redes.htm > acesso em: 2 abril 2005 < http://www.rnp.br/newsgen/0111/h323.html > acesso em: 6 abril 2005-06-03 <http://www.videnet.gatech.edu/cookbook.pt/list_page.php?topic=3&url=sip.htm&level=1&s equence=7&name=Session%20Initiation%20Protocol%20(SIP) > Acesso em: 12 abril 2005

103

< http://www.gta.ufrj.br/grad/00_2/alexandre/VoIP.html > Acesso em 28 maio 2005 <http://www.cefetrio.hpg.ig.com.br/ciencia_e_educacao/8/trabalhos/rlc_1_2003/VoIP/#_Toc 44927842 > Acesso em: 18 maio 2005 < http://www.voip.nce.ufrj.br/courses/nce/aula8.pdf > Acesso em: 19 maio 2005 < http://www.am.unisal.br/graduacao/ansi/pdf/palestra-ssi-2004.pdf > Acesso em: 20 maio 2005 <http://www.poprn.rnp.br/videoconf/textos/final.ppt#332,31,Trabalhos%20Futuros%20na%20Ferramenta >Acesso em: 22 maio 2005

< http://www.protocols.com/pbook/h323.htm#RTCP > Acesso em: 25 maio 2005 < http://www.rnp.br/newsgen/0005/rsvp.html > Acesso em: 25 maio 2005 < http://www.protocols.com/pbook/tcpip4.htm > Aceso em: 25 maio 2005 < http://www.suigeneris.pro.br/direito_dci_ajspamrm.htm > Acesso em: 20 setembro 2005 < http://www.schneier.com/blog/archives/2005/05/combating_spam.html > Acesso em: 27 setembro 2005 < http://www.4linhas.com.pt/revistas%20PDF/RevUp-004.pdf > Acesso em: 10 outubro 2005 < http://www.voipsa.org > Acesso em: 22 outubro 2005 < http://www.sniffer.com > acesso em: 20 agosto 2005 <http://www.modulo.com.br/index.jsp?page=3&catid=2&objid=447&pagecounter=0&idiom =0 > Acesso em: 18 agosto 2005

< http://www.cicilini.com.br/ > Acesso em: 23 agosto 2005

< http://www.alcatel.com.br/ > Acesso em: 15 novembro 2005

<http://idcsite.innovagency.com/resources/PPTs/TelefoniaIP05/5_NextiraOne.pdf > Acesso em: 13 novembro 2005

104