104
1 UNIVERSIDADE CATÓLICA DE GOIÁS DEPARTAMENTO DE COMPUTAÇÃO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO VOZ SOBRE IP SEGURANÇA DE TRANSMISSÕES GUILHERME VOLTAN JÚNIOR DEZEMBRO 2005

Telefonia Voip

Embed Size (px)

Citation preview

Page 1: Telefonia Voip

1

UNIVERSIDADE CATÓLICA DE GOIÁS DEPARTAMENTO DE COMPUTAÇÃO

GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

VOZ SOBRE IP SEGURANÇA DE TRANSMISSÕES

GUILHERME VOLTAN JÚNIOR

DEZEMBRO 2005

Page 2: Telefonia Voip

2

UNIVERSIDADE CATÓLICA DE GOIÁS DEPARTAMENTO DE COMPUTAÇÃO

GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

VOZ SOBRE IP SEGURANÇA DE TRANSMISSÕES

Trabalho de Projeto Final de Curso apresentado por Guilherme Voltan Júnior à Universidade Católica de Goiás, como requisito parcial para obtenção do título de Bacharel em Ciência da Computação aprovado em 22/06/2005 pela Banca Examinadora: Professor Cláudio Martins Garcia, MsC. UCG – Orientador

Page 3: Telefonia Voip

3

VOZ SOBRE IP SEGURANÇA DE TRANSMISSÕES

GUILHERME VOLTAN JÚNIOR

Trabalho de Projeto Final de Curso apresentado por Guilherme Voltan Júnior à Universidade Católica de Goiás, como parte dos requisitos para obtenção do título de Bacharel em Ciência da Computação. ________________________________ _________________________________ Professor Cláudio Martins Garcia, MsC Professor José Luiz de Freitas Júnior, Dr. Orientador Coordenador de Projeto Final de Curso

Page 4: Telefonia Voip

4

Ao Professor Cláudio Martins Garcia,

orientador acadêmico e amigo, pelo apoio e confiança depositada. Aos meus verdadeiros amigos pelo apoio e compreensão. A minha família goiana, pelo incentivo e a todos os que fizeram parte da minha vida, pois sem essas pessoas seria muito mais difícil sobreviver longe do manto protetor dos pais e irmão.

Page 5: Telefonia Voip

5

À Deus pela sua sabia orientação e por me ajudar a destacar em meio ao seu rebanho, ao Santo Expedito que em momentos difíceis me amparou, a Nossa Senhora Aparecida que em vários momentos sorriu para apoiar minha querida mamãe e as lágrimas de felicidades e saudades despejadas pelos meus familiares.

Page 6: Telefonia Voip

6

RESUMO

Transmissões 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 ligações telefônicas, que são fáceis de serem realizadas,

precisa-se apenas de um terminal com acesso a rede mundial de computadores. As vantagens

são inúmeras e as desvantagens, claro existem, porém minimizadas, hoje o que mais afeta a

VoIP é a sua qualidade de serviço, porém isso para usuários que contam com uma largura de

banda relativamente boa torna-se um tanto quanto imperceptível, porém existem outros

problemas relativos a QoS que também à afetam, como é o caso do congestionamento,

segurança e confiabilidade. Apesar de várias desvantagens estarem presentes na VoIP, ela

apresenta a cada dia que passa um numero maior de adeptos e um crescimento tecnológico

muito maior, o que pode levar as redes de telefonia tradicionais à extinção, já que a VoIP

além de prestar todos os serviços prestados pela telefonia tradicional ainda tem a capacidade

de oferecer muito mais serviços, porém devemos levar em consideração que o maior alvo da

VoIP, as redes tradicionais, também são 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 história através de vários componentes, entre eles,

os protocolos de sinalização H.323 e o revolucionário SIP que parece estar tomando frente

junto ás transmissões VoIP, o grandioso protocolo de transporte RTP que é usado

praticamente em todas as operações de transmissões de voz, graças à sua qualidade na entrega

de pacotes, e o RTCP que atua juntamente ao RTP provendo controle, entre vários outros, e é

por causa de todo este apanhado histórico e pela vontade sobre a descoberta de novos meios

de comunicação que a VoIP poderá em breve ser marco da história mundial.

Page 7: Telefonia Voip

7

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, it’s used only a terminal with

access to the world-wide net of computers. The advantages are innumerable and the

disadvantages, however minimized, today what 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 it’s 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.

Page 8: Telefonia Voip

8

Sumário

REDES DE TRANSMISSÃO DE VOZ SOBRE IP ............................................................. 15 HISTÓRIA DO SURGIMENTO DAS REDES VOIP ...................................................... 15 LIGAÇÃO TELEFÔNICA ATRAVÉS DE REDES IP .................................................... 17 VANTAGENS DA TRANSMISSÃO DE VOZ SOBRE IP.............................................. 17 ARQUITETURA DAS REDES VOIP ............................................................................. 18 SERVIÇOS DA REDE VOIP .......................................................................................... 19 OBSTÁCULOS PARA CONSOLIDAÇÃO DA REDE VOIP ......................................... 20

PROTOCOLOS DE SINALIZAÇÃO .................................................................................. 20 H.323............................................................................................................................... 21

Introdução Histórica ..................................................................................................... 21 Componentes da Recomendação H.323........................................................................ 22 Recomendação H.323 para a Arquitetura Protocolar do H.323 ..................................... 24 Vantagens em se utilizar H.323 .................................................................................... 27 Chamada H.323............................................................................................................ 28

SIP................................................................................................................................... 33 Introdução.................................................................................................................... 33 Características .............................................................................................................. 34 Arquitetura do SIP........................................................................................................ 34 Mensagens SIP............................................................................................................. 36 Chamadas SIP .............................................................................................................. 42

COMPARAÇÃO ENTRE H.323 E SIP............................................................................ 45 PROTOCOLO SDP ......................................................................................................... 46 PROTOCOLOS ENTRE GATEWAYS DE MÍDIA E CONTROLADORES DE MÍDIA 47 MGCP.............................................................................................................................. 47

Comandos MGCP ........................................................................................................ 50 MEGACO........................................................................................................................ 50

Comandos MEGACO................................................................................................... 51 COMPARAÇÃO ENTRE MGCP E MEGACO ............................................................... 51

PROTOCOLO RTP ............................................................................................................. 52 FUNCIONALIDADES DO RTP...................................................................................... 53 PACOTE RTP ................................................................................................................. 53 SESSÃO RTP .................................................................................................................. 55

QUALIDADE DE SERVIÇO .............................................................................................. 56 MODELO BÁSICO DE QoS........................................................................................... 56 CONGESTIONAMENTO ............................................................................................... 57

Fifo .............................................................................................................................. 57 Fair Queueing............................................................................................................... 58 Priority Queueing......................................................................................................... 60 Custom Queueing......................................................................................................... 61 Comparação entre os Métodos de Enfileiramento .........................................................63 Detecção 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

Page 9: Telefonia Voip

9

PROTOCOLO RSVP....................................................................................................... 68 Mensagens RSVP......................................................................................................... 70

PARÂMETROS QUE INFLUENCIAM NA QoS DA TECNOLOGIA VoIP................... 71 Atraso .......................................................................................................................... 71 Eco............................................................................................................................... 74 Sobreposição do Locutor.............................................................................................. 74 Jitter............................................................................................................................. 74 Perda de Pacotes........................................................................................................... 75

SOLUÇÕES PARA GARANTIA DE QoS EM REDES IP .............................................. 75 Dejitter Buffer .............................................................................................................. 76 Classificar ou Identificar o Tráfego .............................................................................. 76 Enfileiramento, Priorização e Disciplina de Despacho ..................................................77

SEGURANÇA EM REDES VOZ SOBRE IP ...................................................................... 78 Introdução........................................................................................................................ 78 Ameaças .......................................................................................................................... 79

Captura de tráfego e acesso indevido a informações ..................................................... 79 Código Malicioso......................................................................................................... 80 Fraude Financeira, Uso indevido de recursos corporativos............................................ 81 Repúdio........................................................................................................................ 81

Meios de proteção ............................................................................................................ 82 Segmentar o tráfego de voz e dados.............................................................................. 82 Controlar o acesso ao segmento de voz com um Firewall especializado........................ 83 Evitar o uso de aplicações de telefones para microcomputadores (PC-Based IP phones), utilizando preferencialmente telefones IP que suportem VLAN.................................... 84 Usar endereços IP privativos e inválidos (compatíveis com RFC 1918) nos telefones IP...................................................................................................................................... 84 Configurar os telefones IP com endereços IP estáticos, associados ao MAC Address ... 85 Utilizar servidores DHCP separados para voz e dados.................................................. 85 Monitorar os endereços MAC no segmento de voz....................................................... 86 Implementar mecanismos que permitam autenticar os usuários 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 serviços de VoIP ................................................ 88 Montar uma estrutura de Help Desk capacitada para dar suporte em VoIP.................... 88 Restringir o acesso físico.............................................................................................. 88 Auditar o uso dos recursos............................................................................................ 89 Criptografar o tráfego de VoIP ..................................................................................... 89 Conclusão .................................................................................................................... 90

Benefícios da Convergência ............................................................................................. 91 Riscos e Inibidores da convergência................................................................................. 92 SPIT em geral .................................................................................................................. 93

1. Origem e significado ................................................................................................ 93 2. Prejuízos causados pelo spit...................................................................................... 93 3. Envio de spit ............................................................................................................ 94 4. SPIT (spam over IP Telephony), abordagem geral .................................................... 94

SEGURANÇA NOS PROTOCOLOS H.323 E SIP.............................................................. 95 SIP................................................................................................................................... 95

Segurança na troca de mensagens................................................................................. 95 Segurança da mídia ...................................................................................................... 96 Firewalls SIP................................................................................................................ 97

H.323............................................................................................................................... 98 SNIFFERS VOIP................................................................................................................. 99

Page 10: Telefonia Voip

10

Características dos Sniffers VoIP ..................................................................................... 99 EXEMPLO DE APLICAÇÃO DE SEGURANÇA EM REDES VOIP............................... 100

Encriptação de VoIP no sistema omnipcx enterprise....................................................... 100 Conclusão ...................................................................................................................... 101

Conclusões......................................................................................................................... 102 Referências Bibliográficas ................................................................................................. 103

Page 11: Telefonia Voip

11

LISTA DE FIGURAS

Fig. 1.1: Arquitetura de uma rede VoIP....................................................................... 18 Fig. 1.2: Arquitetura Protocolar................................................................................... 21 Fig. 1.3: Componentes do padrão H.323..................................................................... 24 Fig. 1.4: Troca de mensagens entre entidades H.323................................................... 26 Fig. 1.5: Arquitetura Protocolar do H.323................................................................... 27 Fig. 1.6: Padrão H.323................................................................................................. 27 Fig. 1.7: Fluxo básico da conexão H.323..................................................................... 30 Fig. 1.8: Negociação de Capacidades H.245............................................................... 31 Fig.1.9: Abrindo canais lógicos................................................................................... 32 Fig. 1.10: Conversação ativa H.323............................................................................. 33 Fig. 1.11: Arquitetura Sip............................................................................................ 36 Fig. 1.12: O formato de mensagem SIP....................................................................... 37 Fig. 1.13: O formato da mensagem de pedido SIP...................................................... 40 Fig. 1.14: O formato da resposta SIP........................................................................... 43 Fig. 1.15: Chamada ponto-a-ponto SIP........................................................................ 44 Fig. 1.16: Finalização de uma chamada SIP................................................................ 45 Fig. 1.17: Alteração de chamada SIP........................................................................... 45 Fig. 1.18: Resposta ‘busy here’.................................................................................... 46 Fig. 1.19: Exemplo da utilização do SDP numa mensagem SIP................................. 48 Fig. 1.20: Arquitetura MGCP geral............................................................................. 49 Fig. 1.21: Arquitetura do MGCP - Residential Gateways - Solução Clarent.............. 50 Fig. 1.22: Arquitetura do MGCP – Trunking Gateways – Solução MCI.....................

51

Fig. 1.23: Comandos MGCP........................................................................................ 51 Fig. 2.1: Pacote RTP.................................................................................................... 55 Fig. 3.1: Modelo para QoS........................................................................................... 58 Fig. 3.2: Operação da Fila FIFO.................................................................................. 59 Fig. 3.3: Filas Fair Queueing....................................................................................... 60 Fig. 3.4: Operação do Algoritmo WFQ....................................................................... 60 Fig. 3.5: Filas WFQ...................................................................................................... 61 Fig. 3.6: Operação do enfileiramento Priority Queueing............................................ 62 Fig. 3.7: Filas Priority Queuening............................................................................... 62 Fig. 3.8: Operação do enfileiramento Custom Queueing............................................. 63 Fig. 3.9: Filas Custom Queueing.................................................................................. 64 Fig. 3.10: Funcionamento do WRED........................................................................... 65 Fig. 3.11: Protocolo RTCP........................................................................................... 67 Fig. 3.12: Encapsulamento de pacote VoIP................................................................. 68 Fig. 3.13: Protocolo RSVP em Máquinas do Usuário e Roteadores............................ 70 Fig. 3.14: Camada de atuação do Protocolo RSVP...................................................... 71 Fig. 3.15: Transmissão e Recepção de pacotes............................................................ 71 Fig. 3.16: Atraso na formação de pacotes.................................................................... 75 Fig. 3.17: Atraso em cada etapa da transmissão.......................................................... 75 Fig. 3.18: jitter............................................................................................................. 77

Page 12: Telefonia Voip

12

LISTA DE TABELAS Tabela 1.1: As seis categorias de códigos de status..................................................... 42 Tabela 1.2: Comandos MEGACO............................................................................... 52 Tabela 1.3: comparação entre MGCP e MEGACO..................................................... 53 Tabela 3.1: Métodos de Enfileiramento....................................................................... 64 Tabela 3.2: Classificação do atraso.............................................................................. 74

Page 13: Telefonia Voip

13

LISTA DE ABREVIATURAS

ATM Asynchronous Transfer Mode – Modo de transferência Assíncrono BECN Backward Explicit Congestion Notification CQ Custom Queueing CRTP Compressed Real-Time Transport Protocol DE Discard Eligible DiffServ Differentiated Services DNS Domain Name System DoS Denial of Service FECN Forward Explicit Congestion Notification FIFO First In First Out FQ Fair queuing GK Gatekeeper GW Gateway HTTP HyperText Transfer Protocol IETF Internet Engineering Task Force IIS Internet Integrated Services IMTC International Multimedia Teleconferencing Consortium INATEL Instituto Nacional de Telecomunicações IP Internet Protocol IPsec IP Security IPtel IP Telephony ISDN Integrated Services Digital Network ISI Information Sciences Institute ITU International Telecommunications Union LAN Local Área Network Mbone Multicast Backbone on the Internet MC Multipoint Controller MCU Multipoint Control Unit MGCP Media Gateway Controller Protocol MMUSIC Multiparty Multimedia Session Control MP Multipoint Processor ms Milisegundos PBX Private Branch Exchanges PQ Priority Queueing PVP Packet Video Protocol QoS Quality of Service RAS Register, Admission and Status RDSI Rede de Serviços Digitais Integrada RED Random Early Detection RFC Request For Comment RR Receiver Reports RSVP Resource Reservation Protocol RTCP Real-Time Control Protocol RTP Real-Time Transport SDES Source Descriptions SDP Session Description Protocol SIP Session Initiation Protocol SMTP Simple Mail Transfer Protocol SP Single Space

Page 14: Telefonia Voip

14

SPIT Spam Over IP Telephony SR Sender Reports TCP Transmission Control Protocol UA User Agent UAC User Agent Client UAS User Agent Server UDP User Datagram Protocol – Protocolo de Datagrama do Usuário UFRJ Universidade Federal do Rio de Janeiro URI Universal Resource Identifier URL Universal Resource Location USC University of Southern Califórnia VoFR Voice over Frame Relay VoIP Voice over IP – Voz Sobre IP VOMIT Voice Over Misconfigured Internet Telephones WAN Wide Área Network WFQ Weighted Fair Queueing WRED Weighted Random Early Detection

Page 15: Telefonia Voip

15

REDES DE TRANSMISSÃO DE VOZ SOBRE IP

A Telefonia sobre IP (IPtel – IP Telephony) é também designada como Voz sobre IP

(VoIP – Voice over IP) ou ainda Telefonia sobre Internet (Internet Telephony). A Telefonia

sobre IP é definida como a comunicação multimídia entre dois ou mais participantes, em

outras palavras, significa dizer que é uma ligação telefônica realizada através da rede IP.

Porém o uso comum do termo telefonia IP não deve ser entendido somente como transporte

de voz, mas também como transporte de outros tipos de meios como vídeo e dados. [sIPtel, p.

23]

HISTÓRIA DO SURGIMENTO DAS REDES VOIP

1970 – Dany Cohen começa os esforços para transportar áudio em redes de pacotes.

Este relata uma experiência de transmissão de voz em pacotes e em tempo real entre o

USC/ISI (University of Southern California/Information Sciences Institute) e o MIT’s 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 propõe o Packet Video Protocol (PVP), um protocolo para o transporte

de vídeo em pacotes.

1992 - A Internet Engineering Task Force (IETF) realiza a primeira audiocast através

da Multicast Backbone on the Internet (MBone), a partir de San Diego.

1992 - Henning Schulzrinne começa a desenvolver o Real-Time Transport Protocol

(RTP).

Page 16: Telefonia Voip

16

1992 - após a primeira difusão de áudio, é feita pelo IETF, a partir de Boston através

da Mbone a primeira difusão de áudio e vídeo simultaneamente, utilizando as aplicações vat e

DVC respectivamente.

1995 – O RTP foi publicado como IETF Proposed Standard.

1995 - Steve McCanne e Van Jacobson desenvolveram a vic, uma aplicação que utiliza

o codificador normalizado H.261.

1995 - Surgiu outra aplicação, o CU-SeeMe, que foi dos primeiros protótipos de

videoconferência disponíveis na Internet. Inicialmente para MacOs e depois para Windows,

este protótipo utilizava um processo responsável pela distribuição de sinais pelos vários

intervenientes da conferência.

1996 - É publicada pela International Telecommunications Union (ITU) a primeira

versão da recomendação H.323 [H.323, 1996].

1996 - É prestado pela Delta Three o primeiro serviço comercial de Telefonia sobre

IP, seguindo-se a Net2phone, iBasis e Telematrix.

1996 – A Microsoft lança o seu primeiro sistema de conferência sobre redes de

pacotes. O Microsoft NetMeeting v1.0.

1999 – O protocolo SIP foi aceite como norma, pelo IETF como um protocolo de

sinalização para a criação, modificação e finalização de sessões com um ou mais

participantes.

A partir de então começou a ocorrer várias conferências empresariais

[sIPtel, p. 21 a 23]

Page 17: Telefonia Voip

17

LIGAÇÃO TELEFÔNICA ATRAVÉS DE REDES IP

Para que ocorra a comunicação multimídia entre dois ou mais participantes será

necessário haver sinalização entre eles, de modo que o chamador avise o chamado sobre sua

intenção. Esta sinalização tem como função a criação, controle e a finalização de chamadas.

Este novo serviço permite a troca de pacotes entre dois ou mais participantes através

da rede, utilizando protocolos da Internet e o intercâmbio da informação necessária para

controlar essa troca. No chamador a voz é capturada por um microfone e o vídeo é obtido por

uma câmara de vídeo sendo estes sinais geralmente digitalizados. Em seguida são codificados

e encapsulados em pacotes que são enviados através da rede com a utilização de protocolos de

Internet. Do outro lado, esses pacotes são desencapsulados e decodificados, o sinal digital é

convertido em sinal analógico e reproduzido em alto-falantes enquanto o vídeo é enviado para

a tela.

VANTAGENS DA TRANSMISSÃO DE VOZ SOBRE IP

O que realmente incentiva e impulsiona o desenvolvimento deste tipo de tecnologia

são os benefícios que ela traz tanto para as corporações como para um usuário final.

A idéia geral da utilidade das transmissões de voz sobre IP para as corporações será

para integrar as tecnologias de rede em uma só infra-estrutura, ou seja, as corporações querem

integrar a rede de dados com a rede de voz e vídeo.

Essa integração entre estas redes pode trazer vários benefícios, entre eles estão:

- Redução de custos: com a transferência das ligações telefônicas normais para as

ligações telefônicas VoIP, reduz-se em cerca de 90% os custos com contas telefônicas.

- Oferta de serviços: Várias pessoas se preocupam se com a convergência para

ligações VoIP, obterão serviços como, por exemplo, secretária eletrônica. A resposta é SIM e

além destes serviços normais, inúmeros outros já são oferecidos pelas ligações VoIP.

Page 18: Telefonia Voip

18

- Centralização da gestão destas infra-estruturas: com a integração de todas essas

redes em uma única rede, fica mais fácil para o responsável pela infra-estrutura prover uma

melhor qualidade de serviço, gerir a rede, administrar a rede e etc. A rede agora não ficará

mais espalhada por vários fios e equipamentos, sua integração permitirá sua centralização, o

que traz redução do uso de equipamentos e etc.

- Arquitetura aberta: sua arquitetura é aberta e normalizada. Sua arquitetura possibilita

a criação de novos serviços.

- Privacidade: permite a autenticação de quem faz a chamada, através de uma palavra-

chave e certificados criptográficos.

ARQUITETURA DAS REDES VOIP

O que difere as redes VoIP das redes telefônicas tradicionais é a arquitetura de

comutação. As redes telefônicas tradicionais são redes de comutação de circuitos enquanto a

rede VoIP é uma rede de comutação de pacotes.

Fig. 1.1: Arquitetura de uma rede VoIP [Inatel]

Como visto na figura acima a rede VoIP é composta por vários dispositivos:

Page 19: Telefonia Voip

19

- Terminais: permitem executar os serviços como, por exemplo fazer e receber

chamadas. Os terminais são dispositivos inteligentes, pois possuem total controle sobre o

estado da chamada, ao contrário dos telefones tradicionais que apenas reagem a comandos de

uma central controladora, refletindo uma arquitetura mestre-escravo.

- Gateways: permitem interligar duas redes que não usem a mesma tecnologia de

comunicação.

- Servidores: funcionam ao nível da aplicação, controlando o encaminhamento das

mensagens de sinalização. São também responsáveis pelos serviços de tarifação e controle de

admissão. [sIPtel, p. 27]

SERVIÇOS DA REDE VOIP

Para se obter os serviços de voz sobre ip são necessários pelo menos cinco

componentes. Estes componentes constituem o núcleo do serviço das redes VoIP e são

necessários para a sua implementação.

- Transporte: é responsável pelo transporte de informações entre as entidades, é feito

em tempo real através do protocolo RTP. Este componente resolve os problemas de

congestionamento, perda de pacotes, minimização de jitter e atraso de pacotes além dos

problemas relacionados ao próprio transporte.

- Controle de Transporte: responsável pela administração e controle do transporte de

informações. O controle é feito através do protocolo RTCP.

- Sinalização: é responsável pelo estabelecimento, controle e finalização de chamadas.

- Aplicações: Implementa as características da voz sobre ip como a sinalização. Provê

recursos como chamada em espera, conferência e etc.

Page 20: Telefonia Voip

20

- Descoberta de recursos: descobre os servidores (gateways, terminais e servidores)

presentes na rede. Para realizar esta operação utiliza-se por exemplo o protocolo DNS

(Domain Name System).

OBSTÁCULOS PARA CONSOLIDAÇÃO 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 estão:

- Qualidade de Serviço: As redes IP atuais, atuam oferecendo um serviço do tipo

“melhor esforço” o que reduz a qualidade de serviço.

- Segurança: Embora os novos serviços já ofereçam um mínimo de nível de segurança,

a VoIP tem um grande obstáculo, a fama da internet de ser insegura.

- Custo elevado: Mesmo com uma incrível redução de custos sofrida pelo produtos

VoIP, estes ainda não conseguem apresentar um custo compatível com os oferecidos pelos

produtos de telefonia tradicionais.

- Confiabilidade: Ainda falta confiança no sentido de se estar seguro quanto a

disponibilidade do serviço VoIP, quando se precisar dele como, por exemplo, para ligações de

emergência.

PROTOCOLOS DE SINALIZAÇÃO

Os protocolos de sinalização tornam-se importantes para as transmissões de voz sobre

ip, pois são os componentes da rede necessários para a troca de informações de controle e

gerenciamento dos serviços de rede. Estes componentes podem fazer parte de dois grupos:

Page 21: Telefonia Voip

21

Protocolos “mestre/escravo” como, por exemplo, o MGCP e o Megaco e os Protocolos “peer-

to-peer” como, por exemplo, o H.323 e o SIP.

Os protocolos “mestre/escravo” são usados quando os componentes inteligentes

controlam os componentes sem inteligência como, por exemplo, a sinalização entre um

SoftSwitch e um Media Gateway. Já os protocolos “peer-to-peer” são utilizados em interações

entre elementos inteligentes como, por exemplo, a sinalização entre um SoftSwitch e

telefones IP. [Voip_revolução_Telefonia.pdf]

Fig. 1.2: Arquitetura Protocolar. [sIPtel]

H.323

Introdução Histórica

Os primeiros passos para o surgimento do H.323 foram dados pelo setor de

Telecomunicações do ITU (International Telecommunication Union), o ITU-T, porém este

Page 22: Telefonia Voip

22

protocolo somente se deslanchou pelo mercado a partir da criação do fórum Voice over IP

(VoIP), quem mais tarde viria a fazer parte do IMTC (International Multimedia

Teleconferencing Consortium), cuja função seria, estabelecer padrões para os produtos VoIP.

O H.323 teve seu trabalho iniciado em maio de 1995 com o seguinte título ‘sistemas e

equipamentos de telefone visual para redes locais que fornecem uma qualidade de serviço não

garantida’, e somente teve sua primeira versão aprovada em 1996, tornando-se H.323v1, que

apesar de todas as forças empregadas, não foi bem vinda, devido ao seu baixo desempenho e

problemas de compatibilidade entre os diversos fabricantes. Porém os esforços não pararam

por ai, em janeiro de 1998 a segunda versão da recomendação H.323 foi aprovada, com seu

título alterado para ‘sistemas de comunicação multimídia com base em pacotes’ e acrescida de

três anexos: mensagens H.245 usadas pelos pontos finais H.323; procedimentos para codecs

de vídeo em camadas; H.323 sobre ATM. Com isso a segunda versão melhorou o tempo de

estabelecimento da chamada e eliminou a necessidade de extensões proprietárias e novos

protocolos. Contudo, queria-se chegar além, por isso em setembro de 1999 a terceira versão

foi aprovada, contendo três novos anexos: comunicação entre domínios administrativos

diversos com o H.225; um novo mecanismo de sinalização de chamadas com base no

protocolo UDP; a especificação de um subconjunto do H.323 possível de ser implementado

em dispositivos de pequeno porte. A evolução não parou por ai, pois em novembro de 2000 a

quarta versão foi aprovada, trazendo melhorias em várias áreas importantes: confiabilidade,

escalabilidade e flexibilidade. Sendo adicionadas novas características nas MCU (Gateways e

Multipoint Control Unit), isso para deixar a recomendação conforme as exigências do

mercado crescente da época. Finalmente chegamos a versão atual da recomendação H.323, a

quinta versão, H.323v5, aprovada em julho de 2003. Esta versão se destaca pelo seu ar de

estabilidade, pelo fato de conter somente adições modestas, alguns campos e somente um

novo tipo de mensagem. No entanto o H.323 ainda não está totalmente concluído, sabendo-se

que estudos para a aprovação da sexta versão estão acontecendo.

Componentes da Recomendação H.323

Em um sistema H.323 são definidos alguns componentes conforme a recomendação

H.323: Gatekeeper, MP (Multipoint Processor), Terminal H.323, MC (Multipoint Controller),

MCU (Multipoint Control Unit) e Gateway. Esses componentes possuem características

Page 23: Telefonia Voip

23

distintas, e podem pertencer a uma única rede ou várias redes independentemente de conter

uma ou várias infra-estruturas.

Gatekeeper: é considerado o componente mais complexo da estrutura da

recomendação H.323. Foi introduzido na primeira versão, H.323v1, apesar de na época

poucos entenderem sua utilidade. Contudo na segunda versão, a recomendação H.323

esclareceu o papel do gatekeeper, e hoje o entendemos como sendo um elemento opcional

da(s) rede(s), com funções como: tradução de endereços que é usado para se encontrar um

alias; controle de chamadas o qual verifica a disponibilidade de recursos da rede; controle de

admissão tanto à rede como a terminais, Gateways e MCU, cuja função é verificar o direito

de acessar recursos; controle de registro para poder contactar alguém que está conectado ao

sistema; reserva de recursos como largura de banda; localização de gateways. Enfim resume-

se gatekeeper como sendo um servidor que provê serviços multimídia para as entidades da

rede e ainda gerencia toda a conferência.

MCU (Multipoint Control Unit – Unidade de Controle Multiponto): entidade,

dispositivo que permite que vários terminais e/ou gateways participem de uma conferência

Multiponto. Esta conferência pode ser iniciada apenas com dois terminais (ponto-a-ponto) e

logo após poderá tornar-se uma conferência multiponto, com a entrada de mais terminais. A

MCU é composta de duas partes, o MC (multipoint Controller) que é obrigatório, e o MP

(Multipoint Processor) que é opcional.

MC (Multipoint Controller – Controladora Multiponto): geralmente é um software

que controla o uso de recursos nas conferências multiponto, fazendo negociação com todos os

terminais para obter uma comunicação igualitária. Também pode controlar outros recursos

como por exemplo saber de quem é uma emissão de vídeo multicast.

MP (Multipoint Processor – Processador Multiponto): é uma entidade, geralmente um

hardware, fornecida para processar o fluxo de áudio, vídeo e/ou dados em conferências

multiponto. O MP ainda pode prover o processamento, mistura ou comutação de fluxos de

mídia sob o controle do MC (multipoint controller).

Terminal H.323: é um endpoint (ponto final), terminal, de uma rede. Provê uma

interface que permite ao usuário realizar a comunicação bidirecional em tempo real

(transferência de áudio, vídeo e/ou dados) com outro terminal H.323, gateway ou MCU. Um

terminal H.323 pode ser um hardware (telefone IP), ou um computador multimídia

Page 24: Telefonia Voip

24

(microfone, caixas de som e câmera) que esteja utilizando um softphone (software que simula

um telefone IP).

Gateway: elemento da rede que realiza conversão (tradução de protocolo) entre

terminais distintos, permitindo a interoperabilidade entre sistemas H.323 e outros sistemas em

redes distintas. Também realiza serviços como compressão e empacotamento. Basicamente

transforma a voz do usuário em pacotes de dados e vise-versa.

Fig. 1.3: Componentes do padrão H.323 [Inatel]

Recomendação H.323 para a Arquitetura Protocolar do H.323

O departamento de telecomunicações do ITU, o ITU-T, define que o padrão H.323 é

um conjunto de protocolos necessários pra que haja sinalização e controle de comunicações

entre terminais H.323. Portanto fazem parte dessa recomendação os seguintes protocolos:

H.255.0 (Q.931 – procedimento de sinalização de comunicação entre os terminais das

redes ISDN (RSDI)) que é o protocolo de sinalização de chamadas e encapsulamento de fluxo

de dados multimídia para sistemas de comunicação baseada em pacotes. Define o método

para o estabelecimento de chamadas H.323. A terminologia H.225.0 (Q.931) é usada devido à

Page 25: Telefonia Voip

25

eficiência que o padrão Q.931 tem em estabelecer chamadas e o desejo do padrão H.225 se

tornar compatível com essas redes. As principais funções do padrão H.225.0 são:

Sinalização de chamadas: Sob o canal de sinalização de chamadas (redes TCP/IP)

trafegam várias mensagens sob o formato da recomendação 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 comunicação. Se a rede não possuir um gatekeeper

estas mensagens são passadas ponto-a-ponto usando o endereçamento de sinalização da

chamada, já nas redes que possuem o gatekeeper, as mensagens são trocadas entre o terminal

chamador e o gatekeeper, utilizando mensagens de endereçamento RAS.

Controle de conferência e equipamentos na rede: Esta fase é realizada após a

sinalização da chamada e são utlizadas mensagens do tipo RAS (Register, Admission and

Status) responsáveis pelo registro, admissão e status dos equipamentos da rede, estas

mensagens definem o controle da rede e tem suporte aos pacotes UDP/IP.

Comunicação entre Gatekeepers: São mensagens utlizadas na comunicação entre GKs

(gatekeepers), para estabelecer o processo de sinalização e controle entre zonas distintas.

Transporte de mídia: 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

Comunicações Multimídia) é o protocolo que fornece os padrões para o controle do transporte

da voz entre as chamadas entre terminais. Estas mensagens tem suporte a TCP/IP e são

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 mudanças que ocorrem na rede, como por exemplo: alterações na disponibilidade

da rede e/ou capacidades dos elementos H.323, isso deve-se a negociação dinâmica que

ocorre entre terminais, que negociam vários aspectos da comunicação como por exemplo:

formato de imagens e áudio, codecs e taxa de transmissão. O controle é feito através do canal

lógico 0 (zero) que fica sempre aberto.

No estabelecimento de uma sessão básica o H.323 utiliza três protocolos de controle, o

RAS, o H.225.0/Q931 e o H.245.

Page 26: Telefonia Voip

26

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 – Segurança e criptografia para terminais multimídia da série H). É

uma recomendação que fornece os padrões para autenticação e segurança entre comunicações

ponto-a-ponto e multiponto. Esta recomendação é necessária para o estabelecimento de

serviços de segurança no padrão H.323, como por exemplo: serviços de privacidade,

autenticação, não repudiação e integridade. Para que isto aconteça o H.235 implementa

técnicas de criptografia.

H.450.X (Generic Funtional Protocol for the Support of Supplementary Services –

Protocolo de Funcionamento Genérico para o Suporte de Serviços Suplementares). Este

protocolo fornece os padrões de sinalização para os serviços suplementares (comuns aos

sistemas telefônicos atuais) para terminais, como por exemplo: atendimento simultâneo,

identificação de chamadas e etc. Cada suplemento fornecido pelo protocolo H.450 é

identificado através de um número inserido ao final da identificação do próprio protocolo

H.450, como por exemplo: H.450.2 define o serviço adicional de transferência de chamada

(call transfer).

Page 27: Telefonia Voip

27

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

Fig. 1.6: Padrão H.323 [Inatel]

Vantagens em se utilizar H.323

São várias as vantagens que podemos descrever sobre a utilização do padrão H.323

para aplicações multimídia, entre as quais citaremos:

Rede Independente: O protocolo H.323 não requer mudanças na estrutura da rede, ou

seja, pode ser adaptado na própria 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.

Page 28: Telefonia Voip

28

Interoperabilidade de equipamentos e aplicações: O H.323 permite que haja

comunicação (interoperabilidade) entre equipamentos e aplicações de diferentes fornecedores.

Independência de plataforma: O H.323 pode operar sob qualquer hardware ou sistema

operacional.

Utilização de padrões de mídia: O H.323 faz uso de codecs de áudio e vídeo comuns,

isso devido a negociação dos codificadores em uma chamada, para que os integrantes utilizem

os mesmos codecs.

Flexibilidade nas aplicações 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,

vídeo 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 através da utilização de um gateway.

Suporte a gerenciamento de largura de banda: O H.323 permite o gerenciamento do

consumo de largura de banda e também provê a contabilidade de uso dos recursos da rede,

através da utilização do gatekeeper.

Permite conferências multiponto: suporta além de conferências ponto-a-ponto, as

multiponto, com três participantes ou mais.

Suporte a multicast: Permite multicast em conferências multiponto, enviando um

pacote a todo o subconjunto participante da conferência.

Chamada H.323

Ilustraremos aqui uma chamada H.323 entre dois usuários conectados a dois terminais

IP distintos, desconsiderando assim aspectos como segurança e tarifação.

Page 29: Telefonia Voip

29

Para se estabelecer uma chamada H.323 fim a fim requer-se duas conexões TCP entre

os dois terminais participantes, uma conexão que servirá para se estabelecer a chamada e

outra que tem como objetivo o controle da chamada e a troca de informações sobre

capacidades.

O primeiro passo significa ocorrer a primeira conexão TCP, ou seja, significa dar

inicio a chamada. Esta primeira conexão é realizada da seguinte forma:

- Primeiro o terminal chamador, estabelece uma conexão TCP com o terminal

chamado através de uma porta conhecida. Nesta tentativa, a conexão transporta as mensagens

de estabelecimento de chamada definidas no H.225.0. Esta conexão é conhecida como ‘canal

de sinalização de chamadas’.

- Após estabelecer a chamada, o terminal chamado espera por outra conexão TCP em

uma porta dinâmica; o terminal chamado comunica o número dessa porta na mensagem de

aceitação de chamada.

- Somente agora o terminal chamador então estabelece a segunda conexão TCP com o

terminal chamado através da porta dinâmica. Esta segunda conexão transporta as mensagens

de controle de chamada definidas no H.245.

- Depois de estabelecida a segunda conexão, a primeira conexão deixa de ser

necessária e pode ser finaliza por qualquer um dos participantes. [Telefonia IP]

Mensagens de Chamadas H.323

As mensagens H.323 são enviadas entre o terminal chamador e o terminal chamado à

medida em que a conexão 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 Serviços Integrados), de mensagens de sinalização

para controle de chamada na interface usuário-rede. As seguintes mensagens fazem parte do

núcleo do H.323 e devem ser suportadas por todos os terminais: Setup, Alerting, Connect,

Release Complete, Status Facility. [Telefonia IP]

Page 30: Telefonia Voip

30

Fig. 1.7: Fluxo básico da conexão H.323 [UFRJ]

Na figura César, tendo aberto a sessão 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 sinalização de chamadas (porta 1720, como é definido pelo H.225.0,

Apêndice D) usando uma conexão TCP.

Após o recebimento da mensagem Setup por Bill, este envia a César as mensagens de

Release Complete, Alerting, Connect ou Call Proceeding. Uma delas deve ser recebida pelo

terminal de César antes que o temporizador de Setup expire (em geral, após quatro segundos).

Após Alerting ter sido enviada, o usuário tem até três 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 são enviados na

segunda conexão TCP. As mensagens são definidas no H.245. O terminal chamador abre esse

canal de controle H.245 imediatamente após receber uma mensagem Alerting, Call

Proceeding ou Connect, não importando qual delas especifica em primeiro lugar o endereço

de transporte H.245 a ser usado. Esta segunda conexão que foi estabelecida deverá ser

mantida ao longo de toda a chamada.

10.2.3.4

Page 31: Telefonia Voip

31

Nesta fase determina-se os papéis de quem será mestre e quem será escravo, isto é

necessário quando a mesma função ou ação pode ser executada por dois terminais durante

uma conversação e é necessário escolher apenas um (p. ex.: escolha do MC ativo, abertura de

canais bidirecionais). No H.235, o mestre é responsável por distribuir as chaves de

criptografia dos canais de mídia para os demais terminais.

A determinação de quem será mestre é feita pela troca de mensagens

masterSlaveDetermination que contém um valor terminalType refletindo as capacidades do

terminal e um número aleatório.

Fig. 1.8: Negociação de Capacidades H.245. [UFRJ]

TERCEIRA FASE: INÍCIO DA CHAMADA

Agora o terminal A e o terminal B precisam abrir canais de mídia para voz e

possivelmente para vídeo e dados. Para abrir um canal de voz até B, A envia uma mensagem

H.245 OpenLogicalChannel que contém o número que será dado ao canal lógico, além de

outros parâmetros.

B envia uma mensagem OpenLogicalChannelAck referente a esse canal lógico tão

logo esteja pronto para receber dados de A. Essa mensagem contém o número da porta UDP

para qual A deve enviar os dados RTP e a porta UDP para a qual A deve enviar os dados

Page 32: Telefonia Voip

32

RTCP. Enquanto isso, B também pode ter aberto um canal lógico com A seguindo o mesmo

procedimento. [Telefonia IP]

Fig.1.9: Abrindo canais lógicos. [UFRJ]

QUARTA FASE: DIÁLOGO

Agora César e Bill podem conversar e ver um ao outro caso eles também tenham

aberto canais lógicos para vídeo. Os dados da mídia são enviados em pacotes RTP. Os pacotes

RTCP SR enviados por A são usados para permitir que B sincronize múltiplos fluxos RTP e

também podem ser usados por B para estimar a taxa esperada de dados RTP e para medir a

distância ao transmissor. Os pacotes RTCP RR enviados por B permitem que A meça a

qualidade de serviço da rede entre A e B: as mensagens RTCP contêm a fração de pacotes que

foram perdidos desde o último RR, a perda cumulativa de pacotes, o jitter entre chegadas e o

mais alto número de seqüência 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

sessão. Podem haver três sessões principais entre os terminais H.323: a sessão de áudio, a

sessão de vídeo e a sessão de dados, mas nada no padrão impede que um terminal abra mais

sessões. Para cada sessão 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 vão usar a mesma porta UDP. [Telefonia IP]

Page 33: Telefonia Voip

33

Fig. 1.10: Conversação ativa H.323. [UFRJ]

QUINTA FASE: FINALIZANDO UMA CHAMADA

Caso seja César quem vai finalizar a chamada, o terminal A deve enviar uma

mensagem H.245 CloseLogicalChannel para cada canal lógico que A abriu. B acusa o

recebimento dessas chamadas com uma mensagem CloseLogicalChannelAck. Depois de

todos os canais lógicos 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

através do canal de sinalização de chamadas se ele ainda estiver aberto; esse canal é então

fechado, assim como a chamada.

SIP

Introdução

SIP (Session Initiation Protocol – Protocolo de Iniciação de Sessão), é um protocolo

de sinalização/controle de chamadas em redes IP. É uma arquitetura que se originou em

Page 34: Telefonia Voip

34

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 março de

1999, e logo após teve alguns aspectos melhorados que foram definidos na RFC 3261 em

2002.

Características

As principais características do protocolo SIP são escalabilidade, flexibilidade e

facilidade de criação de serviços, o que o torna um protocolo de fácil integração junto às

aplicações já existentes na internet, isso se deve as semelhanças 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 “fácil” do que os já

existentes no mercado, exemplo H.323, esta facilidade esta presente na criação, modificação e

finalização de sessões, que podem ocorrer entre um ou vários integrantes.

SIP é um protocolo cliente-servidor, e tem um sistema final que interage com o

usuário.

Arquitetura do SIP

A arquitetura do SIP é composta de vários componentes denominados entidades SIP,

entre eles estão:

User Agent SIP (UA SIP - Agente do Usuário SIP): São os terminais finais de

comunicação (terminal SIP ou softphone). Este agente atua como um cliente/servidor, sendo a

parte cliente conhecida como UAC – User Agent Client, uma entidade lógica que realiza a

inicialização da sessão através do envio de pedido(s) para o servidor. O servidor, também uma

entidade lógica 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 sessão.

Page 35: Telefonia Voip

35

Servidor Proxy SIP: este servidor é subdividido em outros componentes, que são

explicados abaixo:

Proxy Server - Servidor Proxy: é um servidor intermediário, que pode atuar tanto

como cliente quanto como servidor. Tem a função de estabelecer chamadas entre os

integrantes da chamada, encaminhando os pedidos recebidos até o destino, sendo assim pode

passar ou não por outros servidores proxy. Pode ser utilizado para contabilidade, pois

armazena informações. Opera através das comunicações stateful (circuito) ou stateless (TCP).

Redirect Server - Servidor de Redirecionamento: é um servidor intermediário, um

UAS – User Agent Server, cuja função é fornecer informações sobre o usuário destino, para

isso, utiliza o DNS que resolve nomes.

Registrer – Registrador: entidade cuja finalidade é fornecer informações sobre as

localizações que conhece. Estas informações estão gravadas na entidade, pois a mesma

anteriormente já recebeu outra requisição igual.

Fig. 1.11: Arquitetura Sip. [UFRJ]

Page 36: Telefonia Voip

36

Mensagens SIP

Mensagens SIP são codificadas usando a sintaxe de mensagem http/1.1 (RFC 2068). O

conjunto de caracteres é o ISO 10646 com codificação UTF-8 (RFC 2279).

Há dois tipos de mensagens SIP: pedidos (requests) e repostas (responses). [Telefonia

IP, p. 125]

Os pedidos são feitos através dos clientes e as repostas são retornadas através do(s)

servidor(es). A mensagem SIP é constituída da linha de ínicio, cabeçalhos, linha em branco e

o corpo da mensagem.

Linha de início

aaa=bbb

ccc=ddd

eee=fff

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

A linha de início contém a versão do SIP, SP (single space – espaço simples) que é um

formato comum compartilhado entre as mensagens de pedidos e repostas, Código de Status,

Frase-Motivo, CRLF utilizado para resposta.

Os cabeçalhos transportam informações úteis as entidades SIP, para que estas possam

gerar mensagens de pedidos ou respostas. A parte “cabeçalho” da mensagem SIP é dividida

em três partes: cabeçalho de geral, cabeçalho de pedido e cabeçalho de entidade.

A linha em branco é sempre utilizada logo após os cabeçalhos para indicar o fim dos

mesmos.

Cabeçalhos

Linha em branco

Corpo da mensagem (SDP limpo, SDP criptografado,…)

Versão do SIP SP Código de Status SP Frase-Motivo CRLF para resposta Método SP URL do pedido SP

Versão do SIP CRLF para pedidos

Page 37: Telefonia Voip

37

O corpo da mensagem é opcional. Caso ele exista irá descrever a sessão através do

protocolo SDP (Session Description Protocol – Protocolo para descrição de sessão).

O cabeçalho geral contém campos que são comuns para as mensagens de pedidos e

respostas. Estes campos são:

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

durante uma chamada.

Cseq: contém o número de seqüência que é incrementado a cada novo pedido. Este

número permite identificar e ordenar as mensagens dentro das transações.

From: Contém o endereço do usuário chamador.

To: indica o endereço do destinatário.

Via: indica a rota que a requisição deverá seguir, contém o tipo de transporte e o

endereço de destino.

Encryption: serve para identificar quando o corpo da mensagem e, possivelmente,

alguns cabeçalhos de mensagem foram criptografados. [Telefonia IP, p. 126].

Content-Type: descreve o tipo de mídia do conteúdo do corpo da mensagem.

[Telefonia IP, p. 126]

Content-lenght: significa o número 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 vários tipos de mensagens que ocorrem dessa forma e cada uma delas é

transportada em uma parte da mensagem. As mensagens transportadas no cabeçalho geral são:

Page 38: Telefonia Voip

38

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 não 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 métodos que ele suporta. Em alguns casos, ele

também pode responder com o conjunto de capacidades do usuário 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 localização atual (um ou mais endereços) com o

pedido Register. Um servidor SIP capaz de aceitar uma mensagem Register é chamado de

registrar. [Telefonia IP, p. 128]

Além do campos do cabeçalho geral, os pedidos podem transportar campos no

cabeçalho de pedido:

Accept: indica quais os tipos de mídia são aceitáveis na resposta. A sintaxe é

especificada no RFC 1288; [Telefonia IP, p. 128]

Accept-Language: indica as línguas 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á válido.

Para uma mensagem Invite, isso pode ser usado para limitar a duração de buscas; [Telefonia

IP, p. 129]

Page 39: Telefonia Voip

39

Priority: os valores são os do RFC 2076, mais ‘emergency’; [Telefonia IP, p. 129]

Record-Route: alguns proxies podem adicionar / atualizar esse campo de cabeçalho,

se eles quiserem estar no caminho de todas as mensagens de sinalização. [Telefonia IP, p.

129]

Subject: é um texto livre que deveria fornecer alguma informação sobre a natureza da

chamada. [Telefonia IP, p. 129]

INVITE SP sip: [email protected] SP SIP/2.0 CRLF

Via: SIP/2.0/UDP 169.130.12.5

Call-ID; [email protected]

From: <sip:[email protected]>

TO: T.A. Watson <sip:[email protected]>

Call-ID: [email protected]

Cseq: 1 INVITE

Subject: Mr. Watson, come here.

Content-Type: application/sdp

Content-Length: 885

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

Linha de início

Cabeçalho geral

Cabeçalho de pedido

Cabeçalho da entidade

Linha em branco

Dados SDP

Page 40: Telefonia Voip

40

Mensagens de Respostas (Responses) SIP

As respostas SIP são geradas no(s) servidor(es) para atender a uma mensagem pedido

que recebeu anteriormente. As respostas SIP seguem um padrão de códigos de status:

100-199: Informação Provisória;

200-199: Sucesso;

300-399: Redirecionamento;

400-499: Erro no cliente;

500-599: Erro no servidor;

600-699: Falha global;

1xx Informativo Pedido recebido, continuando a processar o pedido

100 Tentando

180 Chamando

181 A chamada está sendo retransmitida

182 Colocado na fila

2xx Sucesso A ação foi recebida, entendida e aceita com sucesso

200 OK

3xx Redirecionamento Uma ação adicional deve ser tomada para completar o pedido

300 Múltiplas escolhas

301 Movido permanentemente

302 Movido temporariamente

380 Serviço alternativo

4xx Erro do cliente O pedido contém sintaxe inválida ou não pode ser efetuado

neste servidor

400 Pedido inválido

401 Não autorizado

402 Necessário pagamento

403 Proibido

404 Não encontrado

405 Método não permitido

406 Não aceitável

407 Necessária autenticação no proxy

408 Tempo para o pedido esgotado

409 Conflito

410 Não mais presente

411 Necessário fornecer comprimento

413 Corpo da mensagem de pedido muito grande

Page 41: Telefonia Voip

41

414 URL do pedido muito grande

415 Tipo de mídia não suportado

420 Extensão inválida

480 Temporariamente não disponível

481 Transação ou leg de chamada não existe

482 Laço (loop) detectado

483 Excesso de segmentos (hops)

484 Endereço incompleto

485 Ambíguo

5xx Erro de servidor

500 Erro interno no servidor

501 Não implementado

502 Gateway inválido

503 Serviço não disponível

504 Tempo esgotado no gateway

505 Versão SIP não suportada

6xx Falha global

600 Ocupados em todos os lugares

603 Declínio

604 Não existe em lugar nenhum

606 Não aceitável

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

Page 42: Telefonia Voip

42

SIP/2.0 302 Moved temporarily

From: sip: [email protected]

To: sip: [email protected]; tag=2332462

Call-ID: [email protected]

Location: sip:[email protected]

Expires: Wed, 29 jul 1998 9:00:00 GMT

Cseq: 1 INVITE

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

Chamadas SIP

As chamadas SIP são compostas de várias etapas: início da chamada, finalização da

chamada, rejeição da chamada entre outros.

INICIANDO UMA CHAMADA SIP

Para que se inicie uma chamada SIP, o iniciador da chamada (cliente SIP) deverá

conhecer o endereço SIP da pessoa a ser chamada (servidor SIP).

São vários os tipos de endereços SIP. O cliente/servidor SIP é identificado através do

URI (Universal Resource Identifier – Identificador Universal de Recursos) definido na RFC

3261 de 2002. O URI identifica o utilizador através das seguintes formas:

sip:utilizador@dominio, sip:utilizador@host, sip:utilizador@IP-address ou sip:numero-

telefone@gateway.

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

Linha em branco

cabeçalhos

Linha de status

Page 43: Telefonia Voip

43

Sabendo-se o URI da pessoa a ser chamada, o cliente deverá então abrir uma conexão

entre ele próprio e o destino, este estabelecimento de chamada se da inicialmente através do

envio de um INVITE para o destinatário, neste ponto do processo após o envio do INVITE, o

terminal chamado recebe o invite, ambos trocam informações (mídia, endereço de destino,

porta e etc) sobre como a sessão será realizada, o terminal chamado aceita a conexão, o

terminal chamador confirma o aceite e finalmente ambos estabelecem a conexão.

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

FINALIZANDO UMA CHAMADA SIP

A finalização de uma chamada SIP pode ser realizada por qualquer umas das partes

envolvidas através do envio de um pedido BYE. Caso a conexão seja ponto-a-ponto, apenas o

que irá mudar em relação a finalização da chamada ser realizada pelo cliente ou pelo servidor

será a ordem dos campos From e To.

Envio do INVITE

Resposta OK e informações sobre mídia, porta e etc

Troca de informações

Mensagem ACK

Originador da chamada Pessoa a ser chamada

Page 44: Telefonia Voip

44

Fig. 1.16: Finalização de uma chamada SIP [Telefonia IP, p. 122]

ALTERAÇÃO DE CHAMADA SIP

A alteração da chamada SIP consiste na troca de parâmetros como, por exemplo,

mídia, endereços e portas, entre as partes, chamador e chamado durante a realização da

mesma sem que para isso a sessão deva ser finalizada.

Fig. 1.17: Alteração de chamada SIP [Telefonia IP, 122]

A B INVITE 200 OK ACK Troca de informações

BYE sip: [email protected] SIP/2.0 v: SIP/2.0/UDP 192.168.7.2:3456 i: [email protected] From: sip:[email protected] To: sip: [email protected] Cseq 2 BYE

Troca de informações

SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.7.2:3456 Call-ID: [email protected] From: sip: [email protected] To: sip: [email protected] Cseq 2 BYE

A B

Page 45: Telefonia Voip

45

No caso da figura acima as alterações foram aceitas com sucesso pelo utilizador B,

isso pode ser visto através do envio por parte de B da mensagem ’200 OK’ após o

recebimento do invite enviado por A. Porém caso B rejeita-se a troca de parâmetros proposta

por A, ambos continuariam a utilizar os parâmetros antigos até o fim da chamada ou até uma

nova tentativa de troca de parâmetros 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 parâmetros.

REJEIÇÃO DE CHAMADA SIP

A rejeição de chamada é muito funcional pois, por vários motivos a pessoa chamada

pode não querer atender a ligação como também pode não poder atender no momento.

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

COMPARAÇÃO ENTRE H.323 E SIP

A primeira coisa que impressiona ao se estudar o protocolo SIP é sua velocidade e

simplicidade em relação ao H.323, pois o SIP consegue fazer em uma transação o que o

H.323 faz em várias. Outra vantagem impressionante é que o SIP funciona muito bem em

A B INVITE SIP/2.0 486 Busy Here Via: SIP/2.0/UDP 192.190.132.31:3456 Call-ID: [email protected] From: sip: [email protected] To: sip: [email protected] Cseq 1 INVITE ACK sip: [email protected] SIP/2.0 Via: SIP/2.0/UDP 192.190.132.20:3456 Call-ID: [email protected] From: sip: [email protected] To: sip: [email protected] Cseq 2 ACK

Page 46: Telefonia Voip

46

backbones com capacidade para multicast, não apenas para os fluxos de mídia como também

para as mensagens de sinalização.

O SIP ainda toma vantagens no uso de URLs para identificação dos usuários pois ele

mesmo especifica o protocolo na URL (Universal Resource Location), ao passo que o H.323

sempre considera que o protocolo de sinalização que está sendo usado seja ele mesmo.

Nas inúmeras vantagens do protocolo SIP sobre o H.323 ainda podemos encontrar o

campo de cabeçalho ‘Priority’ que não existe no H.323.

Mas não é somente o SIP que tem vantagens, também podemos encontrar muitas

vantagens ao se utilizar o protocolo H.323 como, por exemplo, o uso de canais lógicos pelo

protocolo H.323. O H.323 faz uma distinção clara entre os tipos de mídia que podem ser

enviados ou recebidos e as combinações que podem ser válidas por um lado (capacidades) e

os tipos de mídia que estão ativos e, de fato, enviados para a rede (canais lógicos) por outro

lado.

O cliente H.323 também toma vantagem ao precisar abrir um soquete apenas quando

ele recebe uma mensagem OpenLogicalChannel (se não estiver no modo FastStart).

O H.323 sozinho ou em combinação com o H.332, possui recursos poderosos para

controle de conferências.

[Telefonia IP, p. 153 a 157]

PROTOCOLO SDP

SDP é um protocolo utilizado pelo SIP para descrever sessões. O SDP (Session

Description Protocol – Protocolo de Descrição de Sessão) está definido na RFC 2237 de 1998

e também é um produto do grupo de trabalho MMUSIC. [Telefonia IP, p. 131]

Este protocolo define para um utilizador informações como tipos de áudio e vídeo que

ele suporta, porta onde deverá receber os dados, nome da sessão e propósito, duração da

sessão, informação de contato, largura de banda e etc., estas informações são 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 informações que são úteis para o

estabelecimento da chamada. Visto que nem sempre as partes se entendem sobre, por

exemplo, que tipo de áudio e vídeo irão utilizar, o SDP de ambas as partes ficam fornecendo

Page 47: Telefonia Voip

47

informações sobre os áudios e vídeos, entre outras informações, que suportam até que ambos

entrem em um consenso.

Fig. 1.19: Exemplo da utilização do SDP numa mensagem SIP. [sIPtel, p. 43]

PROTOCOLOS ENTRE GATEWAYS DE MÍDIA E CONTROLADORES

DE MÍDIA

São protocolos que atuam como uma interface entre um controlador de gateway de

mídia e um gateway de mídia. Controlador de gateway de mídia é um agente de chamada e o

gateway de mídia, pode ser qualquer gateway VoIP.

Citaremos agora os protocolos entre gateways de mídia e controladores de mídia mais

atuais.

MGCP

MGCP (Media Gateway Controller Protocol – Protocolo de Controle de Media

Gateway), é um protocolo que está definido através da recomendação RFC 2705 do IETF, é

Page 48: Telefonia Voip

48

usado para controlar as conexões (chamadas) nos GW’s presentes nos sistemas VoIP. O

MGCP implementa uma interface de controle usando um conjunto de transações do tipo

comando – resposta que criam, controlam e auditam as conexões (chamadas) nos GW’s. Estas

mensagens usam como suporte os pacotes UDP da rede IP, e são trocadas entre os GC’s e

GW’s para o estabelecimento, acompanhamento e finalização de chamadas. [Teleco]

Fig. 1.20: Arquitetura MGCP geral. [Unisal]

O gateway de telefonia é um elemento de rede que provê conversação entre o sinal de

áudio transportado nos circuitos telefônicos e converte para pacotes de dados transportado na

internet ou outras redes de pacotes.

A RFC do MGCP suporta vários tipos de gateways de telefonia, entre eles podemos

citar:

- gateways de tronco: Fazem a interface entre a rede telefônica e a rede VoIP;

- gateways residenciais: Fazem uma interface analógica tradicional (RJ11) com a rede

de VoIP;

- gateways de acesso: Fazem uma interface analógica (RJ11) ou interface digital do

PBX corporativo para a rede IP;

- gateways corporativos: fazem uma interface padrão digital com o PBX corporativo

ou integrado como uma interface “soft PBX”para uma rede VoIP;

- Servidor de Acesso a rede: Podem associar a um modem ou um circuito telefônico e

prover acesso de dados para internet, prover com o mesmo gateway acesso combinado para os

serviços das rede de voz e serviços de rede.

Page 49: Telefonia Voip

49

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 conexão, a

contrução básica são os endpoints e as conexões. Os endpoints são as fontes e pontos finais de

dados. Entre os endpoints usa-se o protocolo SDP para a descrição de mídias na negociação

das mesmas.

Fig. 1.21: Arquitetura do MGCP - Residential Gateways - Solução Clarent [UFRJ]

Fig. 1.22: Arquitetura do MGCP - Trunking Gateways – Solução MCI [UFRJ]

O ambiente MGCP é composto basicamente de um Call Agent, e um conjunto de

gateways, incluindo pelo menos um “mídia gateway”que realiza a conversão das mídias entre

Page 50: Telefonia Voip

50

os circuitos e os pacotes, e pelo menos um “gateway de sinalização! Onde este é conectado

com uma rede controlada por SS7.

Comandos MGCP

Fig. 1.23: Comandos MGCP. [Unisal]

MEGACO

O protocolo Megaco é uma evolução do MGCP, resultado de um esforço conjunto do

IETF e do ITU-T (Grupo de Estudo 16). O texto da definição do protocolo e o mesmo para o

Draft IETF e a recomendação H.248, e representa uma alternativa ao MGCP e outros

protocolos similares.

Este protocolo foi concebido para ser utilizado para controlar GW’s monolíticos (1

único equipamento) ou distribuídos (vários equipamentos). Sua plataforma aplica-se a

gateway (GW), controlador multiponto (MCU) e unidade interativa de resposta audível (IVR).

Possui também interface de sinalização para diversos sistemas de telefonia, tanto fixa como

móvel. [Teleco]

Page 51: Telefonia Voip

51

Comandos MEGACO

Tabela 1.2: Comandos MEGACO. [Unisal]

COMPARAÇÃO ENTRE MGCP E MEGACO

Page 52: Telefonia Voip

52

Tabela 1.3: comparação 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 seqüência dos pacotes introduzidos pelas redes IP. O RTP pode ser usado para qualquer

fluxo de dados em tempo real, como voz e vídeo. O RTP define um modo de formatar pacote

IP que carregam dados isócronos e inclui:

- Informação sobre o tipo de dado transportado;

- timestamps;

- números de seqüência. [Telefonia IP, p. 10]

O RTP atua entre as aplicações 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 implementação do RTP sobre o UDP, seu uso mais comum, as vantagens

obtidas tornam-se maiores ainda pois, além da simplicidade do UDP mais dois serviços são

disponibilizados: a multiplexação e a correção de erros.

O RTP é implementado mais comumente sobre o UDP pois, ele não se preocupa com

a entrega ou atraso de dados, QoS tão quanto reserva de recursos, espera-se que este serviço

seja oferecido pelos protocolos que o encapsulam. [RTP_RTCP.pdf, p. 7]

Page 53: Telefonia Voip

53

FUNCIONALIDADES DO RTP

O protocolo RTP possui inúmeras funcionalidades dentre elas estão:

Seqüência: é o número que ordena os pacotes, usado para verificação de perdas e/ou

reordenamento de pacotes;

Sincronismo: o RTP provê informações sobre o tempo de cada pacote, isto é

necessário para a reprodução da mídia com qualidade.

Identificação de quadro: quadros fazem parte de pacotes, o RTP marca o início e o

fim de cada pacote, necessário para identificação deste quadro.

Identificação de origem: indica quem enviou o pacote.

Criptografia: Alguns streams de RTP podem ser criptografados.

Liberdade no controle da sessão: permite aos participantes trocarem informações

pessoais.

Qualidade de Serviço: o destinatário tem a possibilidade de fornecer informação sobre

a qualidade da recepção. [VoIP, p. 19]

PACOTE RTP

O pacote RTP é constituído de um cabeçalho RTP fixo, uma lista de fontes de

contribuição e um payload (conteúdo do pacote). [RTP_RTCP.pdf, p.8]

Page 54: Telefonia Voip

54

Fig. 2.1: Pacote RTP [<http://www.breitband-isdn.ch/technic/ip/rtp.gif> acesso em:

26/05/2005]

V: Versão do RTP;

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

X: indica se há extensões após eventuais CSRCs do cabeçalho fixo.

CC: informa quantos identificadores CSRC vêm após o cabeçalho fixo.

M: O H.225.0 informa que, para codificações de áudio que suportam supressão de silêncio,

ele deve ser colocado em 1 no primeiro pacote de cada período de fala subseqüente a um

período de silêncio.

PT – payload type: indica o tipo de payload.

Sequence Number: Número de seqüência , começa com um número aleatório e é

incrementado a cada pacote RTP.

Time Stamp: indica a freqüência do clock para o tipo de payload.

Synchronization Source Identificator (SSRC): Identificador de fonte de sincronização, todos

os pacotes RTP com um SSRC comum possuem uma mesma referência de tempo e de

seqüenciamento.

Page 55: Telefonia Voip

55

Contributive Source Identificator (CSRC): Identificador de fonte contribuinte, quando um

fluxo RTP é o resultado de uma combinação de vários fluxos contribuintes feita por um

misturador (mixer) RTP, a lista com os SSRCs de cada um dos fluxos contribuintes é

adicionada ao cabeçalho RTP do fluxo resultante como uma lista de CSRCs. O fluxo

resultante tem o seu próprio SSRC.

Data: dados.

[Telefonia IP, p.12 e 13]

SESSÃO RTP

Uma sessão RTP é uma associação de participantes que se comunicam no RTP. Cada

participante usa dois endereços de transporte para cada sessão: um para o fluxo RTP e um

para as mensagens RTCP. Quando uma transmissão multicast é usada, todos os participantes

usam o mesmo par de endereços de transporte multicast. Fluxos de dados na mesma sessão

devem compartilhar um canal RTCP comum. [Telefonia IP, p. 12]

Se em uma conferência estiver sendo transmitido áudio e vídeo, estes serão

transmitidos em sessões RTP distintas. Nestas sessões os pacotes RTCP de um emissor terão

o mesmo identificador, e as sessões RTP podem associar-se. O objetivo da divisão é permitir

ao participante escolher as mídias que quer receber de acordo com seus recursos de rede e

processamento local. [RTP_RTCP.pdf, p.12]

Manter fluxos de mídias diferentes numa mesma sessão RTP traz uma série de

problemas:

- Se o tipo de payload for mudado durante a sessão, não haverá como saber qual dos

valores antigos foi alterado;

- O identificador SSRC é designado para descrever apenas um escopo de temporização

e de número de seqüência;

- RTCP sender e receiver reports podem indicar apenas uma fonte SSRC;

- Um RTP mixer não saberia combinar mídias incompatíveis;

- Não poderia haver usos e implementações específicas de cada meio.

Page 56: Telefonia Voip

56

Embora a divisão de sessões não seja recomendada, a sincronização de áudio e vídeo

pode ser obtida através das informações de tempo carregadas nos pacotes RTCP.

[RTP_RTCP.pdf, p.13]

QUALIDADE DE SERVIÇO

O conceito de QoS (Quality of Service – Qualidade de serviço) sobre redes IP somente

foi pensado a pouco, em um passado não tão distante o que apenas era oferecido era um

serviço, o de melhor esforço (best effort), o que não garantia QoS.

O que realmente levou a qualidade de serviço ao auge foram os novos serviços que

puderam ser oferecidos sobre as redes IP, áudio e vídeo.

Com a implantação desses novos serviços vários parâmetros começaram a ser

abordados, entre eles os mais comuns que caracterizam a qualidade de serviço são: latência,

largura de banda e perda de pacotes ou de seqüência.

Vários institutos, pessoas e etc., tem se mobilizado para estudar melhores formas de

prover qualidade de serviço. A primeira das propostas foi feita pelo grupo de trabalho

Integrated Services do IETF, foi uma arquitetura de integração de serviços, chamada Internet

Integrated Services (IIS) que propõe 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 diferenciação de serviços na internet. A terceira

proposta baseia-se na negociação de serviços de rede, para a utilização de múltiplos serviços

de rede. A quarta é baseada na utilização de mecanismos adaptativos que tentam reduzir as

perdas e os atrasos de pacotes, através do uso de mecanismos adaptativos utilizados ponto a

ponto. A quinta baseia-se no envio de correções de erro, fornecendo mecanismos de

redundância para ultrapassar a perda de pacotes em streams multimídia. [sIPtel, p. 28,29 e 30]

MODELO BÁSICO DE QoS

Page 57: Telefonia Voip

57

QoS nos dias de hoje tem o grande objetivo de priorizar o tráfego interativo sensível a

retardo, em detrimento ao tráfego referente à transferência de arquivos, que não é sensível 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 serviço 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 trânsito, ou então nos inúmeros finais de ano que

passamos tentando ligar para alguém e as redes de telefonia encontram-se congestionadas

devido aos inúmeros telefonemas que ocorrem no mesmo instante. O mesmo ocorre nas redes

IP, porém 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 vários artifícios foram

estudados afim de se controlar e prevenir este tipo de problema. Estes artifícios são chamados

de mecanismos de enfileiramento. Alguns desses mecanismos são:

Fifo

Page 58: Telefonia Voip

58

First In First Out – primeiro a entrar, primeiro a sair. Também 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 utilização deste método são nas conexões seriais dos roteadores.

Fig. 3.2: Operação da Fila FIFO [VoIP_Ramon.pdf, p. 22]

Os roteadores apresentam uma programação defaul quando são utilizados pela

primeira vez, e continuam assim até que alguém a mude. Esta programação default diz que a

ordem de chegada dos pacotes é que determina a alocação 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 não serve para aplicações sensíveis a QoS.

Fair Queueing

FQ - Fair queuing – enfileiramento justo. Neste algoritmo as mensagens são ordenadas

em sessões, e, para cada sessão, é alocado um canal. A ordem na fila é realizada através do

ultimo bit que atravessa o canal. Essa operação provê uma alocação mais justa da banda entre

os fluxos de dados. [VoIP_Ramon.pdf, p.22]

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

Page 59: Telefonia Voip

59

O algoritmo WFQ (Weighted Fair Queueing – Enfileiramento Justo Balanceado) é

uma implementação Cisco na qual é possível ponderar determinados tipos de fluxo. O

algoritmo escalona o tráfego prioritário 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 é dinâmico e se adapta automaticamente às mudanças das 2Mbps.

[VoIP_Ramon.pdf, p. 23]

Fig. 3.4: Operação do Algoritmo WFQ [VoIP_Ramon.pdf, p.23]

Por apresentar um desempenho superior à fila FIFO, a fila WFQ já vem pré-

configurada nas interfaces seriais da maioria dos roteadores. [VoIP_Ramon.pdf, p. 23]

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

Page 60: Telefonia Voip

60

Como pode ser verificado na figura, a classificação dos fluxos de dados pode ser

realizada de diversas formas: por endereço fonte ou destino, por protocolo, pelo campo

preedência IP, pelo par porta/socket, etc. A quantidade de filas é configurável e a ponderação

pode ser estabelecida por preedência IP, ou em conjunto com outros protocolos de QoS como

o RSVP, ou ainda em tráfego Frame Relay, como VoFR (Voice over Frame Relay) por

exemplo, através dos parâmetros 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 prioritário), o

tráfego de entrada é classificado em quatro níveis de prioridade: alta, média, normal e baixa

(high, medium, normal e low). Os pacotes não classificados são marcados, por default, como

normal.

Fig. 3.6: Operação do enfileiramento Priority Queueing [VoIP_Ramon.pdf, p.24]

A utilização deste método requer um cuidado especial, pois como visto acima os

pacotes que tem prioridade, tem preferência absoluta, isto pode causar atrasos e aumento de

jitter nas aplicações com menos prioridade além de poder acontecer dos pacotes nunca serem

enviados.

Page 61: Telefonia Voip

61

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

Podemos classificar o tráfego 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 aplicação (alocação absoluta da banda). A banda reservada é

compartilhada proporcionalmente, no percentual pré-definido, entre as aplicações e os

usuários. O restante da banda é compartilhado entre os outros tipos de tráfego.

[VoIP_Ramon.pdf, p.25]

Page 62: Telefonia Voip

62

Fig. 3.8: Operação do enfileiramento Custom Queueing [VoIP_Ramon.pdf, p.25]

O algoritmo CQ controla o tráfego alocando uma determinada parte da fila para cada

fluxo classificado. As filas são 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 configurável que estabelece

quantos bytes devem ser enviados antes da passar para a próxima 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 sinalização, keep-alive, etc. A classificação CQ pode ser feita por endereço

Page 63: Telefonia Voip

63

fonte ou destino, por protocolo (IP, IPX, Appletalk, SNA, DecNet, etc), por precedência IP,

por interface de entrada e ainda por listas de acesso.

Comparação entre os Métodos de Enfileiramento

Tabela 3.1: Métodos de Enfileiramento [VoIP_Ramon.pdf, p. 26]

Na tabela acima podemos ver um breve resumo sobre os métodos de enfileiramento.

Deve-se dar uma atenção especial a esta parte já que estas são as diretrizes básicas a serem

consideradas no início de um projeto VoIP, porém não se deve esquecer de também analisar

os próprios aspectos do projeto, como por exemplo, largura de banda disponível, tipo de

roteamento, etc.).

Detecção RED e WRED

Detecção RED (Random Early Detection – Detecção Randômica Antecipada) é um

mecanismo de congestion avoidance ou seja serve para prevenir e impedir o

congestionamento. Atua para evitar picos de tráfego, através de uma análise antecipada do

tráfego. Ao constatar irregularidades pode tomar várias decisões como, por exemplo,

descartar pacotes, indicar à fonte para que reduza a taxa de transmissão.

Page 64: Telefonia Voip

64

Detecção WRED (Weighted Random Early Detection – Detecção Randômica

Antecipada Balanceada) é uma implementação Cisco que adiciona às funcionalidades RED a

classificação de pacotes por precedência 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 sessão RTP em

particular. Esses pacotes de controle podem incluir informações a respeito dos participantes e

informações sobre o mapeamento dos participantes em suas fontes de fluxo individuais.

[Telefonia IP, p. 14]

Funcionalidade do RTCP

O protocolo RTCP é funcional pois, provê informações adicionais sobre seus

participantes:

Page 65: Telefonia Voip

65

Retorno de informações de Qualidade de Serviço (QoS): Receptores podem retornar

informações sobre atraso, jitter, e perdas, que pode ser usadas para adaptar a aplicação, como

por exemplo alterar o vocoder que está sendo utilizado.

Sincronismo Intermídia: Necessário para sinronizar diferentes fluxos, como áudio e

vídeo, caso sua origem seja de servidores diferentes.

Identificação do usuário: e-mail, nome, organização, etc.

O RTCP necessita que as informações citadas sejam enviadas periodicamente, no

entanto sabe-se que este envio de informações por parte dos participantes, consome em média

5% de largura de banda, portanto deve ser de suma importância o controle sobre a taxa de

envio de pacotes, para que assim possa-se evitar congestionamento entre outros problemas.

O mesmo endereço utilizado pelo RTP é usado pelo RTCP, porém em portas

diferentes. Nem todas as aplicações RTP utilizam RTCP, que não é indispensável para as

aplicações.

[VoIP, p.19]

Pacote RTCP

Um pacote RTP é um pacote de controle constituído de um cabeçalho fixo seguido por

elementos estruturados variando de acordo com o tipo de pacote RTCP.

- SR (Sender Reports): contém informações de transmissão e recepção para

transmissores ativos;

- RR (Receiver Reports): contém informações de recepção para ouvintes que não

sejam também transmissores ativos;

- SDES (Source Descriptions): descrevem vários parâmetros da fonte, inclusive o

CNAME;

- BYE: enviado por um participante quando ele abandona a conferência;

- APP: funções específicas de uma aplicação;

Page 66: Telefonia Voip

66

0 1 2 3 4 5 6 7 Octet

Version P Reception report count 1

Packet type 2

3-4 Length

RTCP structure

Fig. 3.11: Protocolo RTCP [Protocols]

Version - versão: espaço reservado para indicação da versão do protocolo. O valor

deve ser ‘2’;

P – padding: indica que o payload sofreu enchimento para fins de alinhamento. Deve-

se lembrar que o último octeto dos dados de preenchimento deve conter o número de octetos

usados para preenchimento. Apenas o ultimo pacote do pacote composto RTCP prescisa

receber preenchimento, uma vez que o pacote composto é “encriptado”como um todo, caso

necessário;

Reception Report Count - Contador de Relatório de Recepção: o número de blocos de

relatório (reception blocks) presentes no pacote SR. O valor “0” é válido.

Packet Type – Tipo de pacote: serve para identificar qual é o pacote RTCP em

questão.

Lenght - comprimento: indica o comprimento do pacote RTCP em palavras de 32 bits

menos um, incluindo o cabeçalho e qualquer informação de preenchimento.

[RTP_RTCP.pdf, p.18]

PROTOCOLO CRTP (Compressed Real-Time Protocol)

Um dos problemas relacionados à voz sobre IP é a utilização da largura de banda

disponível. Para tentar minimizar este problema foram criados protocolos que se relacionam

com a voz transmitida nas chamadas, estes protocolos tentam realizar ao máximo uma

Page 67: Telefonia Voip

67

compressão de dados, para que assim possa-se trafegar mais dados na banda disponível ou ter

uma maior banda para trafegar os dados desejados, também usam técnicas de fragmentação e

interleaving para se obter um sinal de voz com maior qualidade.

O protocolo CRTP (Compressed Real-Time Transport Protocol) comprime o

cabeçalho do pacote RTP, que transporta o tráfego de voz.

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

cabeçalho de 40 para 2 Bytes.

Seu funcionamento é muito simples, o CRTP primeiramente classifica o tráfego total

que esta sendo enviado, em segundo lugar separa o que for RTP para que ocorra a

compressão. A parte RTP passa pelo compressor e novamente é anexado aos dados para

serem transmitidos.

PROTOCOLO IEEE 802.1p priority queueing.

A relação entre o protocolo IEEE 802.1p e qualidade de serviço está relacionada a

questão de QoS em redes locais. Até agora somente nos preocupamos em analisar a QoS fim-

a-fim, porém esquecemos de visualizar o comportamento dos pacotes de áudio e vídeo 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 distância e chegue à rede remota com a QoS que a aplicação requer, ou seja, o

protocolo 802.1p.

O protocolo 802.1p define 8 níveis de prioridade de usuários, através de um rótulo

(user_priority) de 3 bits que é transmitido no quadro ethernet.

20 bytes 8 bytes 12 bytes 20 bytes

40 bytes

Page 68: Telefonia Voip

68

No caso do pacote enviado pelo telefone IP, este pacote foi primeiro setado no

telefone IP com sua precedência, em segundo o pacote chega ao switch, que pode ser

compatível ou não com o protocolo 802.1p, caso seja compatível, o switch classificará o

quadro ethernet, priorizando os de maior classe, caso não seja compatível, o switch ignora os

rótulos e o pacote não sofrerá nenhum tratamento especial, em terceiro o pacote chega ao

roteador que classifica o quadro ethernet e mapeia o nível de prioridade 802.1p na

precedência IP correspondente, por ultimo, quando o pacote já alcançou a rede de longa

distancia, este terá um tratamento de acordo com as várias técnicas de QoS já apresentadas.

PROTOCOLO RSVP

RSVP (Resource Reservation Protocol – Protocolo de Reserva de Recursos) é um

protocolo de sinalização, que permite ao equipamento (host e/ou roteadores) requisitar um

nível específico de qualidade de serviço para sua aplicação. Também é utilizado na entrega de

requisições de QoS de roteadores para roteadores entre outros.

As requisições do protocolo RSVP, sempre que possível, provêem um nível de QoS

solicitado pelo equipamento (host), isto porque suas requisições fazem reservas de recursos na

rede.

Fig. 3.13: Protocolo RSVP em Máquinas do Usuário e Roteadores. [RNP-RSVP]

Page 69: Telefonia Voip

69

Embora o protocolo RSVP se favoreça dos protocolos de roteamento para determinar a

rota a ser seguida pelos pacotes da origem até o destino, ele não é um protocolo de

roteamento. Através dessas técnicas 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 atuação do Protocolo RSVP [RNP-RSVP]

Todas as mensagens RSVP apresentam um cabeçalho em comum.

4 8 16 32 bits

Ver Flags Message type RSVP checksum

Send TTL (Reserved) RSVP length

RSVP header structure

Fig. 3.15: Cabeçalho RSVP [Protocols]

Os campos do cabeçalho do protocolo RSVP são descritos abaixo:

Ver (Versão): número da versão 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.

Page 70: Telefonia Voip

70

RSVP length: comprimento total da mensagem RSVP em bytes, incluindo o cabeçalho

e os objetos que seguem.

Mensagens RSVP

O RSVP troca constantemente várias mensagens entre as aplicações e os

equipamentos para assim prover qualidade de serviço.

As principais mensagens RSVP são PATH e RESV. A mensagem PATH constrói o

caminho pelo qual as mensagens RESV irão passar efetuando as reservas de recursos.

A operação básica do protocolo RSVP é:

- A fonte especifica as características do tráfego a ser transmitido, através de

parâmetros do algoritmo Token-Bucket. Esta informação é transportada no objeto Sender

Tspec.

- O RSVP da fonte envia uma mensagem PATH ao destino (ou destinos) contendo a

especificação do tráfego feito pela fonte. A rota a ser seguida pela mensagem PATH é

definida pelo algoritmo de roteamento, e não pelo RSVP.

- Cada roteador RSVP-capaz ao longo da rota estabelece um "path-state" que inclui o

endereço do roteador RSVP-capaz imediatamente anterior (roteador que enviou a mensagem

PATH - upstream). Cada roteador envia seu endereço ao vizinho posterior (downstream)

através do objeto RSVP_HOP. Os roteadores podem incluir na mensagem PATH informações

sobre os recursos disponíveis e o atraso aproximado que ele irá introduzir, através do objeto

ADSpec. Assim, em qualquer ponto ao longo da rota, a mensagem PATH contém o endereço

IP do roteador vizinho (upstream) e pode conter informações de capacidade e atraso

aproximado que cada nó irá introduzir.

- Para fazer a reserva de recursos, o receptor envia uma mensagem RESV (requisição

de reserva) na direção da fonte, contendo a especificação da qualidade de serviço requisitada

para o fluxo de dados (objeto FlowSpec). A mensagem RESV vai do receptor à fonte através

do mesmo caminho percorrido pela mensagem PATH. Isto é possível porque cada roteador

armazenou o endereço do vizinho (na direção 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 admissão para autenticar a requisição e alocar os

recursos necessários. Se a requisição não pode ser satisfeita (devido à insuficiência de

recursos, por exemplo), o roteador retorna uma mensagem de erro ao receptor (origem da

Page 71: Telefonia Voip

71

mensagem RESV). Se a requisição for aceita, o roteador envia a mensagem RESV ao

próximo roteador a upstream.

- Quando o último roteador (mais próximo da fonte) recebe a mensagem RESV e

aceita a requisição, ele envia uma mensagem de confirmação 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 característica permite reação dinâmica a alterações ocorridas

na fonte do fluxo, nos parâmetros de QoS estabelecidos pelo receptor, ou na rota.

[http://www.rnp.br/newsgen/0005/rsvp.html]

PARÂMETROS QUE INFLUENCIAM NA QoS DA TECNOLOGIA VoI P

Ainda hoje existem pessoas defendendo que os usuários preferem trocar qualidade por

preço, no entanto existem outras pessoas que defendem que sem uma qualidade mínima este

serviço de voz sobre ip não irá se consolidar.

São vários os obstáculos percorridos para que se possa garantir qualidade de serviço

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 não ponto a ponto o atraso implica no somatório dos atrasos inseridos pela

rede e pelos equipamentos.

Page 72: Telefonia Voip

72

Fig. 3.15: Transmissão e Recepção de pacotes. [Inatel, p. 11]

Este atraso é decorrente de vários aspectos como, por exemplo, qualidade do meio de

transmissão, algoritmos utilizados para codificação de voz e supressão de silêncio, estes

aspectos atingem diretamente a QoS.

Para o usuário 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 round-

trip, que corresponde a duas vezes o atraso.

Tabela 3.2: Classificação do atraso. [VoIP_Ramon.pdf, p.29]

A figura acima determina a classificação do atraso segundo o ITU-T, para os valores

que são ou não aceitáveis para o usuário.

O atraso final, percebido pelo usuário, é na verdade gerado por uma série de outros

pequenos atrasos:

- Atraso de formação de pacote: É o tempo necessário para o preencimento do pacote

de voz a ser enviado. Estes atrasos são da ordem de 20 a 30 ms.

- Atraso de rede: Tempo necessário para o transporte pela rede do pacote da origem até

o destino. Este tempo é variável pois depende da carga na rede.

Tanto o computador de origem e/ou destino como o gateway são providos de um

mecanismo de formação do pacote e outro correspondente para reprodução de voz.

Page 73: Telefonia Voip

73

Fig. 3.16: Atraso na formação de pacotes. [VoIP_Ramon.pdf, p.29]

A figura acima ilustra os responsáveis pelo atraso na formação de pacotes e a figura

abaixo mostra o atraso em cada etapa da transmissão.

Fig. 3.17: Atraso em cada etapa da transmissão. [gta-Alexandre-UFRJ]

Page 74: Telefonia Voip

74

Eco

Eco é um fenômeno físico que se realiza através da repetição 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 própria voz) ouvir sua própria voz, sem que esta cause desconforto a ele.

Nas redes de telefonia tradicionais o eco ocorre devido a um decasamento de

impedância nas híbridas utilizadas para conversão dos quatro fios do nó de comutação para os

dois fios do cabo telefônico tradicional.

Sobreposição do Locutor

Sobreposição 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 não sabe que A o enviou

uma mensagem, envia uma mensagem para A. Esta demora de B na escuta da fala de A, e o

início da conversação de B sem antes ter ouvido a mensagem de A caracteriza a sobreposição

do locutor.

Esta sobreposição do locutor ocorre também devido ao atraso, sendo que para se evitar

este tipo de falta de QoS, o atraso deve ser inferior a 400 ms, sendo recomendável pelo ITU-T

o limite de 200 ms.

Jitter

Jitter significa a variação do atraso da transmissão das informações. É causado pelas

variações no tráfego e alterações no roteamento.

Page 75: Telefonia Voip

75

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

Este problema é tratado através da supressão de jitter, isto significa que é necessário

um armazenamento de pacotes por um tempo superior ao maior jitter observado, no entanto

essa resolução gera um novo atraso, o atraso de supressão de jitter.

Perda de Pacotes

A perda de pacotes significa que um pacote enviado não conseguiu atingir seu destino

e isto implica na perda de qualidade para a aplicação, sendo que esta qualidade tem seu limite

variado de aplicação para aplicação. Estas perdas são causadas pelo descarte de pacotes

ocasionado pelos congestionamentos freqüentes em redes ip, atrasos excessivos e erros na

tecnologia de transporte.

Umas das soluções seria a utilização de protocolos de transporte confiáveis como, por

exemplo, o TCP, no entanto os atrasos gerados pelo seu uso tornam-no inutilizável para este

tipo de aplicação. Portanto até o presente momento a perda de pacotes é inevitável, isto reflete

significativamente na QoS de VoIP.

SOLUÇÕES PARA GARANTIA DE QoS EM REDES IP

Vários são os problemas percorridos pela QoS para se atingir um nível aceitável, e

através de várias técnicas podemos hoje dizer que sim, nós conseguimos chegar a um nível

aceitável em transmissões VoIP.

Page 76: Telefonia Voip

76

As técnicas utilizadas são as mais variadas possíveis, que vão desde prover qualidade

através de reserva de banda, minimização de atrasos de pacotes até eliminação de jitter de

atraso.

A seguir veremos algumas dessas técnicas.

Dejitter Buffer

Um dos vários problemas sofridos pela VoIP são as variações de atrasos (jitter), e para

minimizar ou até mesmo eliminar este problema, usamos uma técnica chamada dejitter buffer,

que significa utilizar buffers na recepção de informações.

Esta técnica 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 Tráfego

Na rede atual onde os pacotes de VoIP trafegam, cada tipo de informação recebe um

tratamento diferente dos nós da rede. A solução então seria, classificar os tipos de pacotes que

estão trafegando na rede.

A classificação por si só, somente proverá efeitos quando em conjunto com outras

técnicas como, por exemplo, políticas de priorização da transmissão, pois somente o tráfego

de pacotes classificados pelos roteadores e switchs não 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 vídeo.

Com a adição de outras técnicas, por exemplo, política de priorização da transmissão,

o pacote ao chegar a um roteador/switch poderia ser rapidamente passado à frente ou

colocado em uma fila de espera.

Esta política poderia classificar os pacotes de diferentes formas: informação contida

no pacote, porta de destino, MAC, endereço fonte/destino, etc. e esta classificação 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]

Page 77: Telefonia Voip

77

Enfileiramento, Priorização e Disciplina de Despacho

Sabe-se que uns dos grandes problemas enfrentados pelas redes IP hoje em dia são 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 são colocados em forma de fila.

A idéia então da disciplina de despacho é organizar esta fila que é montada pelo

roteador, de forma que os pacotes ganhem prioridades uns em cima dos outros, conforme

informações que eles estão 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.

Várias técnicas de disciplina de despacho são implementadas para se obter uma maior

qualidade de serviço em redes que trafegam voz sobre IP, algumas delas são:

Policiamento e Conformação de Tráfego

As funções de policiamento e conformação usualmente identificam as violações no

tráfego de uma mesma maneira. Elas diferem, contudo, na forma como elas respondem a estas

violações, por exemplo:

- A função de policiamento usualmente descarta o tráfego que não está conforme ou o

define como elegível para descarte.

- A função de conformação tipicamente atrasa o tráfego em excesso, através de

mecanismos de enfileiramento, retendo os pacotes e liberando-os de maneira tal que o fluxo

de saída esteja dentro dos parâmetros definidos. [cefetrio]

Fragmentação

Também é característico do tráfego VoIP, a presença de grandes pacotes de dados. A

técnica de fragmentação propõe justamente a este tipo de tráfego uma solução que seria,

fragmentar pacotes de dados que excedam a um máximo proposto em pacotes menores, sendo

estes pacotes menores tratados de forma independente pela rede.

Esta técnica eleva vantagens como: diminuição do tempo médio de enfileiramento de

pacote, que faz com que o pacote chegue mais rapidamente ao destino, e do desvio padrão

Page 78: Telefonia Voip

78

deste tempo, que resulta na diminuição do jitter de atraso na rede, o que vem a melhorar a

qualidade do sinal. [cefetrio]

SEGURANÇA EM REDES VOZ SOBRE IP

Introdução

Com o desenvolvimento das novas tecnologias, tornou-se possível a evolução dos

sistemas de transmissão, o que viabilizou a criação de redes de pacotes muito mais velozes.

Todo este desenvolvimento tem permitido a evolução das redes convergentes, que são

redes capazes de transportar pacotes de dados e voz digitalizados.

Hoje contamos com vários tipos de redes que são 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 são utilizados com mais freqüência, embora o ATM tenha sido

projetado para tal finalidade. O Transporte através da tecnologia Frame Relay e TCP/IP são

conhecidos como VoFR e o VoIP.

A diferença entre a utilização de tais redes é referente ao seu custo/beneficio. As redes

IP, estão associadas a camada 3 no modelo OSI, o que lhe da muitas vantagens, entre elas o

baixo custo e capacidade de operação em redes heterogêneas, em contrapartida recebe como

desvantagens a qualidade de serviço e questões relacionadas com a segurança. Já as redes

VoFR e VoATM, estão associadas com a camada 2 do modelo OSI, que então apresentam

como vantagem, maior qualidade de serviço pois requerem redes homogêneas para o tráfego

de informações, e como desvantagem, um custo elevado. [MSLAB, p. 2]

Page 79: Telefonia Voip

79

Ameaças

Hoje, ainda são mínimos os ataques documentados em cima de redes VoIP, talvez pela

ainda não familiarização dos “invasores” com os protocolos desta tecnologia.

No entanto já é sabido que em um curto espaço de tempo, esta realidade tomará rumos

diferentes, isto se deve a vários motivos, um deles é pelo valor das informações que trafegam

pelas redes VoIP, e que em mãos erradas poderão causar grandes prejuízos e lucros a diversas

pessoas.

É importante ressaltar que na convergência das redes de voz com as redes de dados

baseadas em TCP/ IP, houve também a convergência das vulnerabilidades inerentes as duas

tecnologias.

Ou seja, agora, um computador com telefone IP-compatível precisa ser protegido tanto

das ameaças relacionadas aos computadores quanto das ameaças relacionadas com a telefonia.

Por exemplo, um telefone IP instalado em uma estação de trabalho com o sistema operacional

Windows está suscetível às vulnerabilidades do Windows. [MSLAB, p. 3]

Captura de tráfego e acesso indevido a informações

Nas Redes que trafegam voz sobre IP, a voz é transportada juntamente com as

informações da rede de dados, encapsulado em pacotes IP, e a captura destes pacotes em uma

rede IP através de técnicas de "Sniffing" é relativamente trivial. Hoje já podemos contar com

algumas ferramentas que facilitam este trabalho para o usuário, por exemplo, o VOMIT

(“Voice Over Misconfigured Internet Telephones”), que utiliza a ferramenta tcpdump do Unix

para capturar pacotes de uma conversa telefônica, que está trafegando na rede de dados e

consegue remontá-los e convertê-los em um formato comum de áudio (*.wav). Ou seja, trata-

se de uma espécie de "grampo telefônico" em plena rede de dados.

No entanto estas ferramentas estão começando a surgir agora na internet e ainda

encontram-se limitadas a alguns padrões existentes, por exemplo, o CODEC G.711 utilizado

pela Cisco. Devemos ressaltar que é questão de tempo para que ferramentas mais poderosas se

Page 80: Telefonia Voip

80

adentrem à internet, já que os mecanismos de transporte de voz, por enquanto, não utilizam

criptografia, deixando assim os pacotes vulneráveis à qualquer destas ferramentas existentes.

Várias outras técnicas que podem ser ou não mais complexas podem ser utilizadas

pelos atacantes para obtenção de acesso indevido às informações que trafegam pela infra-

estrutura onde se localiza a rede VoIP. Por exemplo, no ataque de “Caller Identity Spoofing”

(algo como “falsificação da identidade do usuário que iniciou a chamada”), o atacante induz

um usuário remoto a pensar que ele está conversando com alguma outra pessoa, ou seja, finge

ser alguém que não é para obter informações sigilosas.

Este tipo de ataque requer apenas que o atacante obtenha acesso físico à rede e consiga

instalar um telefone IP não autorizado. Outra técnica que pode ser utilizada é a de (“MAC

Spoofing”), o atacante deverá conseguir que seu telefone IP assuma a "identidade" de um

telefone IP válido da rede empresa.

Boas políticas aplicadas nas empresas podem ser uma boa solução quando se pretende

evitar estes tipos de ataques, a integridade da rede aumentará ainda mais se for possível

combinar as políticas com uma boa administração da rede, por exemplo, sempre obtendo

controle de pontos de rede ativos que não estão sendo utilizados.

O treinamento e a boa orientação dos usuários destes tipos de rede, culminarão na

dificuldade dos atacantes em se aplicar engenharia social, assim seria mais difícil de se

induzir alguém que o atacante é quem ele não é. [MSLAB, p. 4]

Código 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 físico. Portanto a tecnologia

VoIP também esta susceptível às vulnerabilidades da rede de dados.

Algumas das vulnerabilidades que também podem afetar as redes de voz, são os

conhecidos vírus, “Trojan Horses” e outros tipos de códigos maliciosos que podem vir a

infectar os sistemas de telefonia IP baseados em PCs, os “Gateways”e outros componentes

críticos da infra-estrutura. Sendo assim, podemos concluir que até mesmo “técnicas” que não

surgiram para afetar as redes VoIP, podem causar a paralisação deste serviço. [MSLAB, p. 5]

Page 81: Telefonia Voip

81

Fraude Financeira, Uso indevido de recursos corporativos

Uma das ameaças às redes VoIP é a ameaça de “Toll Fraud”. Esta ameaça consiste no

uso não autorizado dos serviços de telefonia IP ou métodos de fraude para iludir os

mecanismos de bilhetagem e cobrança das ligações realizadas.

Existem vários métodos para se aplicar esta técnica. Um deles pode ser o uso indevido

de um telefone IP para realização de chamadas que sejam contabilizadas como tendo sido

originadas pelo endereço do telefone IP de alguma outra pessoa, a qual seria então

responsável ate o momento pelos gastos.

Um método mais sofisticado envolveria a instalação de um “Voice Gateway” (ponto

de convergência entre a redes) falsificado pelo atacante, pois é neste Gateway que passam

todas as ligações. Caso o “Voice Gateway” principal não seja comprometido, o atacante

deverá tentar instalar na rede um segundo “Gateway” e tentar redirecionar para ele o tráfego

destinado ao “host” original. Desta forma, é possivel bloquear, desviar e até mesmo escutar

ligações. [MSLAB, p. 5]

Repúdio

Repúdio em relação à tecnologia VoIP tem a ver com a negação, por parte de um

usuário que utilizou os serviços de telefonia IP para fazer uma ligação, de que ele tenha

realmente feito tal ligação.

Isto só poderá ser comprovado com a implantação de algum mecanismo eficiente para

autenticação, do contrário, não será possível identificar os usuários dos serviços, nem

discriminar quem executou quais chamadas a partir de quais telefones IP.

Indisponibilidade de serviços

Devido à utilização da rede de dados para se transportar voz, esta também torna-se

vulnerável aos ataques não só destinados à ela como também aos destinados à rede TCP/IP.

Um exemplo ao qual ela torna-se vulnerável é ao ataque de DoS ( “Denial of Service”), os

Page 82: Telefonia Voip

82

quais causam a paralisação dos serviços em redes TCP/ IP, sendo assim esta paralisação

afetará “por tabela” os serviços de voz, fax e vídeo que dependam deste transporte.

São vários os ataques que podem causar negação se serviço em redes TCP/IP, entre

eles podemos citar o “TCP SYN Flood” e suas variações, e também a exploração de falhas

nas pilhas de protocolo dos sistemas operacionais, como no “Ping of Death”, “LAND”,

“Teardrop” e vários outros ataques que podem tornar os serviços do VoIP indisponíveis.

Nas redes VoIP, os equipamentos de PBX (“Private Branch Exchanges”) tradicionais

são substituídos por aplicações PBXs IP-compatíveis que são executadas, por exemplo, em

servidores Windows NT. Estas aplicações de “Call Management” são críticas para a infra-

estrutura de VoIP, e no entanto estão sujeitas aos ataques que exploram vulnerabilidades não

só das próprias aplicações como também do sistema operacional. [MSLAB, p. 5]

Meios de proteção

A seguir são apresentadas algumas práticas para a implantação de uma estrutura VoIP

segura.

Segmentar o tráfego de voz e dados

As segmentações do tráfego de voz e dados podem ser feitas utilizando Switches. Esta

segmentação contribui para obtenção de uma melhor QoS além de facilitar a gerência da rede

de voz e simplificar sua manutenção. Ainda podemos com isso evitar que o segmento de voz

seja alvo de ataques de “eavesdropping” (captura não autorizada do tráfego de conversas

telefônicas que trafegam na rede encapsuladas em pacotes IP) realizados com o VOMIT e

outras ferramentas semelhantes.

Com a implementação da segmentação, vários 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 não estejam diretamente relacionados com a infra-estrutura de VoIP, podem

tornar estes serviços indisponíveis caso todo o tráfego esteja no mesmo segmento.

Page 83: Telefonia Voip

83

Por exemplo, os telefones IP normalmente utilizam o protocolo UDP com portas

acima de 16384 para sua comunicação. Sendo assim, um ataque de negação de serviços

baseado em “UDP Flood” no segmento de dados poderia afetar também os serviços de voz se

as redes não estiverem adequadamente segmentadas.

Para que se possa melhorar ainda mais os vários aspectos citados da rede de voz,

recomenda-se a separação dos segmentos de rede de voz e dados em VLANs distintas. Como

por exemplo, em uma instalação de pequeno porte, uma VLAN dedicada ao tráfego de voz

seria suficiente, onde seriam instalados o “Call Manager” e os telefones IP. Outros

componentes como estações de gerenciamento e sistemas de “Voice/Mail” podem residir no

segmento de dados. Já em instalações de grande porte, várias VLANs podem ser criadas, tanto

para voz quanto para dados. Por exemplo, os serviços 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

tráfego que seja endereçado à rede de voz e não seja necessário para o funcionamento destes

serviços. O firewall irá proteger o “Call Manager” de acessos indevidos por parte de telefones

IP não autorizados que sejam instalados em outros segmentos.

Logo, as portas e protocolos que serão configuradas no firewall irão depender do tipo

de solução/fabricante de solução VoIP em uso.

Um aspecto importante ao qual deve-se estar atento é ao de que o firewall deve ser

compatível com o protocolo H.323. Isto deve-se ao fato de que este protocolo aloca portas de

forma dinâmica para canais de áudio, vídeo 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]

Page 84: Telefonia Voip

84

Evitar o uso de aplicações de telefones para microcomputadores (PC-Based

IP phones), utilizando preferencialmente telefones IP que suportem VLAN

Não é recomendável a utilização de SoftPhones, convém utilizar telefones IP que

suportem VLANs, já que os SoftPhones estão sujeitos a um maior número de ataques que os

aparelhos de telefonia IP baseados em hardware.

Além do risco de falhas em seu próprio código, as aplicações de telefone IP para PCs

estão sujeitas às vulnerabilidades do sistema operacional e também de outras aplicações que

residem no computador onde estão instaladas, bem como vírus, worms e outros códigos

maliciosos.

Já os telefones IP executam sistemas operacionais proprietários com serviços limitados

(e portanto menos vulneráveis) . Além disso, como as aplicações de telefone IP para PC

precisam residir no segmento de dados da rede, elas são susceptíveis a ataques de negação de

serviços (como “floods” baseados em UDP ou TCP) que sejam destinados ao segmento como

um todo, e não apenas ao computador em que estão instalados. [MSLAB, p. 7]

Usar endereços IP privativos e inválidos (compatíveis com RFC 1918) nos

telefones IP.

Nos telefones IP devem ser utilizados endereços IP inválidos. Esta medida servirá para

reduzir a possibilidade de que o tráfego 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. Além disto o uso de IP’s inválidos sucumbirá em menores custos.

A utilização de endereços IP privativos e principalmente de classes diferentes nos

segmentos de voz e dados, de acordo com a orientação do RFC 1918 ( “Address Allocation

for Private Intranets”), servirá para facilitar a configuração de filtros e a monitoração. As

conexões com redes externas devem utilizar endereços IP válidos fornecidos por um firewall,

através do serviço NAT ( “Network Address Translation”) . [MSLAB, p. 7]

Page 85: Telefonia Voip

85

Configurar os telefones IP com endereços IP estáticos, associados ao MAC

Address

A utilização do MAC Address permite a autenticação dos telefones IP ou seja quando

um telefone IP tenta obter configurações da rede do “Call Manager”, seu Mac Address pode

ser verificado em uma lista de controle de acesso. Caso o endereço seja desconhecido, o

dispositivo não receberá a configuração.

Caso seja possível, deve-se aplicar endereços IP estáticos para os telefones IP, e

associa-los ao “Mac Address” do dispositivo. Sendo assim, cada telefone IP terá sempre o

mesmo endereço IP associado ao endereço MAC. Desta forma, para conseguir instalar um

telefone IP não autorizado na rede, um atacante teria que forjar tanto um endereço IP válido

para o segmento de voz quanto o endereço MAC a ele associado.

Alguns aspectos devem ser considerados antes de tal aplicação pois, dependendo das

características do ambiente da implantação, a associação entre endereço IP estático e “Mac

Address” nos telefones IP pode ser de difícil 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 negação de serviços (DoS) e outros lançados contra o

servidor DHCP no segmento de dados não vão interferir com a alocação de endereços IP para

os telefones no segmento de voz, e vice-versa, o que aumenta a tolerância da rede. [MSLAB,

p. 8]

Page 86: Telefonia Voip

86

Monitorar os endereços MAC no segmento de voz

A utilização de ferramentas como, por exemplo, o ARPWATCH para monitorar os

“MAC Addresses” de todos os dispositivos instalados no segmento de voz trará mais

segurança à rede. O ARPWATCH é capaz de registrar alterações não autorizadas na

associação entre endereço IP e endereço MAC. [MSLAB, p. 8]

Implementar mecanismos que permitam autenticar os usuários dos

telefones IP

Se a tecnologia em uso atualmente suportar, convém implementar os recursos de

autenticação dos usuários dos telefones IP, além de autenticar apenas os dispositivos através

de seus endereços MAC.

Hoje já podemos encontrar com certa facilidade, alguns modelos de telefones IP que

exigem do usuário um “login” e uma senha ou número de identificação (PIN) válidos para que

possam utilizar o dispositivo. Este tipo de autenticação reduz os riscos de uso indevido dos

recursos da rede de voz, e permite maior rastreabilidade no uso dos serviços, além de um

certo nível de não repúdio.

Algumas aplicações de telefone IP para a plataforma Windows suportam autenticação

integrada ao sistema operacional, enquanto outros modelos utilizam uma combinação de

nome de usuário / PIN. Em qualquer caso, as senhas utilizadas devem ser trocadas

periodicamente e devem ser de difícil dedução. [MSLAB, p. 8]

Implementar um sistema IDS

É sabido que os sistemas atuais de detecção de intrusão (IDS) ainda não são

compostos pelas assinaturas específicas de ataques para os protocolos de VoIP, no entanto

Page 87: Telefonia Voip

87

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, convém que uma aplicação ou aplliance de IDS seja instalado no

segmento onde estiver instalado o “Call Manager”, visando a detecção de ataques originados

principalmente no segmento de dados, onde estão localizadas as estações de trabalho dos

usuários.

Naturalmente, é necessário fazer o tunning do IDS para maximizar sua eficiência. Esta

operação é 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 tráfego

esperado no segmento de voz estará obrigatoriamente associado a um número limitado de

protocolos e portas, o que facilita a configuração do IDS e reduz o número de falsos positivos.

Qualquer tráfego TCP/ IP que não 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 número de serviços que podem estar sendo

oferecidos por estas aplicações.

O Call Manager, por exemplo, normalmente disponibiliza aplicações para controle de

chamadas, permite a configuração via Web, dá suporte a serviços de localização de telefones

(IP Phone browsing), serviços de conferência, e gerenciamento remoto por SNMP.

Por este motivo, convém que sejam implementados procedimentos para a

configuração segura (“Hardening“) do servidor onde o Call Manager está instalado. Como

recomendações genéricas, convém desabilitar todos os serviços desnecessários, instalar os

patches do sistema operacional e um bom antivírus. Os serviços inicializados pelo Call

Manager devem utilizar contas de baixo privilégio, e o acesso físico ao servidor deve ser

restrito a usuários autorizados. [MSLAB, p. 9]

Page 88: Telefonia Voip

88

Monitorar a performance e status dos serviços de VoIP

O objetivo deste controle é permitir a monitoração periódica, se possível em tempo

real, do desempenho da rede de voz, e detectar instabilidades, atrasos e latências que possam

comprometer a performance ou disponibilidade dos serviços. A monitoração pode ser feita

através de soluções proprietárias disponibilizadas pelos fabricantes (Cisco, etc) , ou de

soluções 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 implantação da estrutura VoIP não é suficiente para garantir sua

perfeita funcionalidade durante o decorrer do tempo, devemos aplicar métodos que ajudaram

a manter esta implantação em perfeito funcionamento durante sua existência no ambiente.

Para isso deveremos, se possível, ter presente no ambiente que foi implantando a estrutura

VoIP uma equipe treinada para realizar configurações necessárias nos equipamentos

(Switches, Roteadores e etc) e aplicações utilizados pela rede de voz além de prestar suporte

técnico para os usuários. Também é conveniente manter um contrato de Suporte Técnico com

algum integrador qualificado, ou com o próprio fabricante dos equipamentos adquiridos.

[MSLAB, p. 10]

Restringir o acesso físico

O acesso físico à rede em si deve ser restrito, isto devido à possibilidade de algum

atacante conseguir acesso físico indevido na rede e através dessa vulnerabilidade conseguir

tirar proveitos. Com acesso à rede física o atacante pode, por exemplo, instalar um telefone IP

Page 89: Telefonia Voip

89

não autorizado e utilizar técnicas de “MAC Spoofing” e “Caller Identity Spoofing” para

enganar os usuários, fazendo-os pensar que estão conversando com alguma outra pessoa,

quando na verdade estão conversando com o atacante. Desta forma informações sigilosas

poderão ser obtidas através de engenharia social.

Naturalmente, o acesso físico indevido também expõe os componentes da infra-

estrutura de VoIP a ameaças como fraudes, roubo, sabotagem ou danificação acidental ou

proposital dos equipamentos, podendo causar a indisponibilidade dos serviços. Por estes

motivos, convém que o acesso físico aos dispositivos mais críticos da rede (Switches,

Roteadores, Call Manager, Firewalls, etc), seja restrito apenas à usuários autorizados.

[MSLAB, p. 10]

Auditar o uso dos recursos

A verificação da qualidade de serviço prestada pelos equipamentos VoIP bem como

sua utilização pelos usuários deve ser auditada periodicamente. Para isso devemos manter

registros das informações sobre as sessões (data e horário do início e término, duração,

origem, destino, etc) além de informações relacionadas a QoS (latência, perda de pacotes, uso

de banda, etc).A auditoria pode ser implementada através de aplicações especializadas.

Para um auditoria mais prescisa, recomendamos que os usuários utilizem algum tipo

de autenticação quando utilizarem os serviços da rede de voz. [MSLAB, p. 10]

Criptografar o tráfego de VoIP

Recomendamos a criptografia de todo o tráfego passante entre o telefone IP e o “Call

Manager”. Esta medida tem como objetivo impedir o uso de ferramentas como o VOMIT

para violação da confidencialidade das conversações.

Um exemplo de criptografia que pode ser utilizada para tal ambiente seria a

implantação de um túnel IPSec entre as estações com telefones IP e o “Call Manager”. Para

Page 90: Telefonia Voip

90

as comunicações externas (matriz com filiais, por exemplo), deve-se considerar a

implementação de uma VPN (“Virtual Private Network”) para criptografar o tráfego de VoIP.

[MSLAB, p. 10]

Conclusão

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 estão vulneráveis. 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, exploração das vulnerabilidades dos sistemas operacionais, engenharia

social, roubo de identidade e spoofing, etc), isto porque a convergência das redes traz também

a convergência das ameaças.

É sabido também que um bom sistema de autenticação não só dos dispositivos

(telefone IP e etc) como também do usuário é 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 telefônicas, permitindo acesso indevido a informações

sigilosas, além de outros problemas como repúdio etc.

Hoje ainda não podemos contar com nenhuma solução completa para as redes de voz,

o que poderia vir a fornecer um ambiente mais homogêneo 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 recomendações que surgem sobre segurança VoIP,

estaremos minimizando as ocorrências de ameaças ao ambiente, tornando-o cada vez mais

seguro.

A implantação de um sistema VoIP em qualquer ambiente requer de início um bom

planejamento da infra-estrutura, um cabeamento adequado, dispositivos que suportem as

demandas de QoS requeridas, uma segmentação apropriada da rede, planejamento de serviços

como o DHCP. A implantação de uma Política de Segurança é muito importante, e deve

preceder a configuração de Switches, Roteadores, FireWalls, soluções de IDS e outros

Page 91: Telefonia Voip

91

dispositivos de proteção, cujo acesso físico deve ser restrito a usuários autorizados. O uso de

criptografia do tráfego de voz encapsulado na rede IP é recomendado em certos contextos.

Os equipamentos (por exemplo, telefones IP que suportem VLAN e soluções que ofereçam

recursos de autenticação mais sofisticados) devem ser escolhidos de forma mais crítica para

viabilizar um maior nível de segurança, bem como o treinamento do pessoal envolvido na

instalação, suporte e auditoria dos serviços. Em alguns casos, até mesmo um plano de

“Disaster Recovery” deve ser considerado, tal o impacto que a descontinuidade dos serviços

de voz pode trazer para a corporação.

Finalmente, é preciso conscientizar os usuários dos serviços VoIP no ambiente corporativo

sobre os riscos existentes, já que em muitos casos eles próprios poderão ser responsabilizados

pelo uso indevido, fraude e outras ações maliciosas executadas pelos atacantes.

Benefícios da Convergência

Redução de custos

Na infraestrutura convergente além de se aproveitar o cabeamento, as operações 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 usuário 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 motivação em até 30%. [innovagency]

Melhoria da Eficácia de pessoas e organizações:

As pessoas tornam-se mais eficazes perante uma rede convergente pois, as

comunicações tornam-se unificadas, a colaboração entre pessoas aumenta consideravelmente,

os recursos são alocados de forma otimizada, independente da localização geográfica.

O ritmo do projeto de convergência é importante

Processo de melhoria constante

Implementação baseada: começar por onde fizer sentido [innovagency]

Page 92: Telefonia Voip

92

Convergência chegou, e está para ficar !

Não se perspectivam novos desenvolvimentos na voz tradicional (TDM)

Riscos e Inibidores da convergência

Não existem, neste momento, entraves de maior.

Benefícios evidentes

Tecnologia disponível. [innovagency]

Mas alguns aspectos pertinentes podem atrasar a implementação

Salientamos que mesmo com as diversas vantagens apresentadas para se utilizar redes

convergentes, é de nosso parecer que sempre que for possível deve-se utilizar circuitos

independentes de dados e voz devido a diversas características como, por exemplo:

Segurança,

Gestão de SLA,

QoS & Desenho de rede,

Interoperabilidade de “standards”,

Existência de know-how interno à organização,

Monitorização & gestão da qualidade VoIP.

Page 93: Telefonia Voip

93

SPIT em geral

1. Origem e significado

A expressão spit teve sua provável origem no artigo publicado por Bruce Schneier na

data de 13 de maio de 2005 em seu blog “Schneier on Security”. [schneier]

2. Prejuízos causados pelo spit

São diversos os prejuízos causados pela técnica de spit, entre eles podemos citar:

1. Os custos que o spammer tem para manter sua conexão com a Internet, conta como

o provedor, linha telefônica e energia elétrica. Sabemos ainda que quanto mais tempo se

permanece on-line, maiores são os custos. No caso dos prejuízos causados pelo spit para os

receptores, quem o recebe é obrigado a ficar mais tempo ouvindo aquelas mensagens

indesejáveis deixadas no seu correio de voz, o que acaba gerando custos com energia elétrica,

conexão com internet além dos prejuízos “psicológicos” (raiva, angustia, stress e etc);

[schneier]

2. O segundo prejuízo 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 números telefônicos dos spammers, tempo este que poderia ser utilizado de forma

mais útil; [schneier]

3. O terceiro prejuízo fica por conta das enormes dificuldades e prejuízos para

provedores e servidores também, visto que quanto mais spit acumulado, maior será o custo de

armazenamento e comunicação. Finalizando, o mau uso da Internet poderá retardar o tempo

de resposta das conexões. [schneier]

Page 94: Telefonia Voip

94

3. Envio de spit

O meio mais comum de envio do spit é baseado no telemarketing, o spammer grava a

mensagem e através de um método automatizado envia a mesma, em massa para diversos

destinatários. Este sistema automatizado é capaz de realizar ligações aleatórias ou seqüenciais

e a cada atendimento o sistema dispara a gravação feita pelo spammer.

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

Um dos problemas previstos a acontecerem nas redes VoIP refere-se a uma técnica já

conhecida na telefonia tradicional como telemarketing e suas derivações, em VoIP essa

técnica receberá o nome de SPIT.

Spit é conhecido como sendo o “spam over IP Telephony”, em outras palavras, spit

são as mensagens não solicitadas que chegam por meio de Voz sobre IP (VoIP) aos usuários

da tecnologia. Esta é uma tendência derivada do spam, assim como muitas outras, que agora

atinge os meios de comunicação 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 indesejáveis,

em momentos indesejáveis, com propostas indesejáveis a quaisquer telefones. Logo podemos

pensar que o spit por vez pode ainda contar com a vantagem da gratuidade da ligação, o que

não ocorre no telemarketing. Devemos assim sobressaltar que este exemplo é apenas uma

analogia, pois podemos pensar em ambas as técnicas com o sentido de invasão de

privacidade, da insistência em vender ou oferecer algo que o cliente realmente não pediu e

nem está interessado. Assim podemos ver o spit como uma técnica promissora pois desperta

sentimentos em muitos, pois poderiam agora praticar o telemarketing de forma “gratuita”.

Hoje infelizmente não 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 não conseguem

elimina-lo completamente, apenas dribla-lo, isto porque na maioria das vezes os e-mails spam

ficam armazenados nas pastas de quarentena.

Page 95: Telefonia Voip

95

Igualmente como o spam o spit irá acarretar problemas, pois também fará uso de

recursos computacionais além de sobrecarregar a internet, principal veículo de transporte das

redes VoIP. Desta maneira, os filtros ainda são e serão a solução (paliativa) para o spam e o

spit.

Imaginemos então, por enquanto, as diversas formas de spam como algo do nosso

cotidiano que temos que conviver, pois não encontramos solução para ela, assim iremos ate

podermos dar a carta final ao spam dando dribles no cotidiano. [cicilini]

SEGURANÇA NOS PROTOCOLOS H.323 E SIP

SIP

Segurança na troca de mensagens

As mensagens SIP devem ser criptografadas por uma série de motivos os quais

englobam, por exemplo, no caso se a chave de criptografia de mídia tiver de ser protegida , os

pedidos e respostas SDP deverão ser criptografados, deve-se esconder a origem e o destino

das chamadas e os campos de informação relacionados, deve-se evitar que o usuário receba

mensagens enganosas além do seu uso para contabilidade e tarifação.

O protocolo SIP conta com vários sistemas de segurança para se evitar várias ameaças

ao ambiente VoIP, como por exemplo, preservação da integridade e confidencialidade,

prevenção de ataques que possam vir a desviar mensagens, provocar DoS ou ainda

proporcionar a autenticação de atacantes que possam vir a violar a privacidade dos

participantes numa sessão.

A criptografia das mensagens é a melhor opção de segurança para a sinalização, isto

garante a confidencialidade e a integridade das mensagens. Porém o protocolo SIP não

permite a criptografia das mensagens ponto a ponto, pois estas podem vir a trafegar por vários

outros equipamentos da rede como, por exemplo, Proxy Server cuja função é analisar os

pedidos e respostas para que assim possa encaminha-los de forma correta. Naturalmente, o

Page 96: Telefonia Voip

96

Proxy Server poderá ainda remover ou adicionar informações como, por exemplo, os

cabeçalhos Via.

No entanto, caso seja necessário tal grau de segurança, será necessário que a segurança

seja aplicada em um nível mais baixo, no qual as mensagens deverão ser cifradas entre as

entidades SIP e assim poderão permitir aos terminais a verificação da identificação dos

servidores destinatários, para os quais são enviadas as mensagens de forma segura, utilizando-

se apenas de um sistema e autenticação criptográfica.

A solução prevista no caso citado a cima é o uso dos protocolos TLS (Transport Layer

Security) [RFC 2246, 1999] e IPSEC [RFC 2401, 1998], os quais fornecerão às camadas de

transporte e rede um maior nível de segurança, que permitirá a integridade e

confidencialidade das mensagens.

Podemos também contar com os chamados SIPS URI que permitem o estabelecimento

de sessões seguras, garantindo que é utilizado transporte criptográfico (TLS) para entregar as

mensagens.

A autenticação da identidade dos utilizadores fica por conta do método Digest [RFC

3261, 2002], um método de autenticação que se baseia no esquema de autenticação HTTP

Digest, utilizado pelo protocolo HTTP.

Este método permite aos utilizadores identificarem-se perante uma entidade através do

nome do utilizador e de uma palavra-chave cifrada, utilizando a informação que lhe é

fornecida pelas respostas 401 ou 407. Por exemplo, quando um utilizador se pretende registar

num Registrar ou enviar um INVITE através de um SIP Proxy, o servidor responde com uma

resposta 401 ou 407 indicando que é necessária a sua autenticação e transportando as suas

credenciais. Quando o utilizador recebe a resposta formula um novo pedido, que desta vez

transporta a informação necessária para confirmar a sua identidade. Este mecanismo de

segurança permite evitar ataques em que utilizadores mal intencionados assumem a identidade

não autorizada de outros utilizadores; no entanto não garante a confidencialidade e

integridade das mensagens. [sIPtel, p. 62]

Segurança da mídia

A criptografia de mídia é especificada pelo SDP [RFC 2327]. O parâmetro k do SDP

armazena o algoritmo de segurança em uso bem como a chave. A RFC supracitada define os

seguintes formatos:

Page 97: Telefonia Voip

97

K=clear:<chave de criptografia>

Esse formato refere-se aos algoritmos de criptografia descritos no RFC 1890 (“perfil

RTP para conferencias de áudio e vídeo com controle mínimo”). O RFC 1890 descreve

primeiro como extrair uma chave a partir de uma pass phrase de uma forma padrão. A pass

phrase é colocada em uma forma canônica (espaços em branco no inicio e no fim removidos,

caracteres colocados em minúsculo etc.) e, então, dividida em 16 octetos pelo algoritmo MD5.

Chaves com menos de 128 bits são formadas truncando-se o sumário MD5. As chaves são

extraídas em ordem para os algoritmos que precisam de mais de uma (p. ex.: três 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 padrão para os algoritmos mais comuns podem ser encontrados no RFC

1423: ‘DES-CBC’, ‘DES-ECB’; o padrão é DES-CBC. O RFC 1423 também descreve como

armazenar parâmetros adicionais necessários para determinados algoritmos, como o vetor de

inicialização 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 não permitidos pelo SDP.

K=prompt

Solicita ao usuário uma chave. O algoritmo padrão é 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 alcançar o servidor SIP apropriado usando registros

Page 98: Telefonia Voip

98

DNS. O suporte nativo para o NAT ((Network Address Translation) é uma técnica usada para

segurança, bem como para evitar problemas de re-endereçamento) por parte das entidades SIP

permite a configuração de sinalização para comunicações de saída sem nenhum requisito

específico no firewall. Mas, para os fluxos de mídia, 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 sinalização SIP do firewall. [Telefonia IP, p. 152]

H.323

O H.235 é o responsável pela implementação de segurança nos ambientes H.323. Este

protocolo implementa tamanha segurança que hoje em dia torna-se mais difícil escutar uma

chamada telefônica H.323 do que “grampear” uma linha telefônica, 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 não conseguirá escutar qualquer conversa, além

disso o H.235 permite que o terminal chamador esconda o número de destino que está

tentando alcançar. [Telefonia IP, p. 64]

A segurança implementada pelo H.235 é realizada através do uso de algoritmos de

criptografia, que visam manter a privacidade, autenticação e integridade do tráfego da rede.

Atualmente o H.235 utiliza duas técnicas principais de criptografia, a criptografia

simétrica mais conhecida como criptografia de chave secreta e a criptografia assimétrica ou

criptografia de chave pública.

Criptografia de chave secreta baseia-se em um método onde destinatário e emissor das

mensagens compartilham um “segredo”, que pode vir a ser um algoritmo usado para codificar

a mensagem ou uma “chave” usada como parâmetro em um algoritmo bem conhecido.

Criptografia de chave publica baseia-se em uma maneira pragmática de se considerar a

segurança da informação: algumas informações estão seguras não apenas quando você não

sabe como extrair a informação, mas também quando você sabe como extrair a informação,

porém você praticamente não pode faze-lo porque isso demandaria tempo demais para

executar o algoritmo de extração, mesmo para o mais rápido computador existente. [Telefonia

IP, p. 64]

Page 99: Telefonia Voip

99

SNIFFERS VOIP

Com a convergência das redes telefônicas normais para as redes telefônicas baseadas

em pacotes. Muitas necessidades surgiram. Uma dessas necessidades é a de controlar as redes

VoIP.

É necessidade do administrador de rede, saber estatísticas atuais, momentâneas sobre o

tráfego corrente dos pacotes VoIP.

Para ajudar esses profissionais, hoje em dia no mercado já é possível contar com

algumas ferramentas que os auxiliaram nesta jornada. Essas ferramentas são denominadas

Sniffers.

O principal papel do sniffer é capturar todo o trafego (entrante/sainte), e trazer dados

funcionais à tela do administrador.

Com esses dados o responsável pela rede poderá então achar defeitos, monitorar,

controlar o comportamento da rede conforme o nível de trafego e/ou realizar uma perícia

sobre sua performance.

Com isso será possível assegurar a QoS nas redes de voz sobre ip, além de realçalas

em todos os níveis e além disso poderá otimizar a gerencia de voz, vídeo e dados sobre uma

única rede. E todas essas opções poderão, através de Sniffers, serem realizadas em tempo real.

[Sniffer]

È possível saber se a rede comporta a demanda de usuários.

Características dos Sniffers VoIP

• identificam os problemas de rede rapidamente;

• fornecem análise para uma larga escala de protocolos VoIP;

• Oferecem análise de problemas, tais como:

o perda de pacotes;

o atraso de pacotes;

o pacotes que chegam fora de seqüência;

o duracao das chamadas;

o Tempo de resposta de comando.

Page 100: Telefonia Voip

100

• Análise completa das camadas de Aplicação e sessão para as conexões VoIP. Para a

perfeita funcionalidade deste módulo usase o protocolo Skinny Client Control

Protocol (SCCP).

• Realiza alertas preventivos, sobre possíveis problemas da rede. [Sniffer]

EXEMPLO DE APLICAÇÃO DE SEGURANÇA EM REDES VOIP

Encriptação de VoIP no sistema omnipcx enterprise

A segurança é vista, em alguns casos, como uma entrave à adoção 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 solução que garante a segurança do tráfego de voz sobre IP, através de

mecanismos como autenticação, integridade e encriptação dos fluxos de comunicação.

Um nível de segurança, responsável pela encriptação, é colocado entre os

componentes da solução OmniPCX Entreprise (Call Server, Media gateways e telefones IP) e

a LAN ou a WAN, a partir das quais poderão ser lançados ataques.

Este nível é constituído por hardware dedicado, denominado “Call Server Security

Module - SSM” e “Media Security Module - MSM”, para protecção do Call Server e das

Media Gateways, respectivamente. Os telefones IP, IP- Touch®, suportam este serviço de

uma forma nativa .

A voz é encriptada utilizando SRPT (secure RTP) através do algoritmo de encriptação

AES (modo contador). A vantagem do SRTP é que não introduz “overhead” quando

comparado com tráfego não encriptado, simplificando também alguns dos serviços na rede

como sejam QoS, detecção de falhas e firewalling.

São utilizadas chaves simétricas que mudam em cada nova sessão RTP e são enviadas

pelo Call Server para os pontos terminais através de sessões de sinalização encriptadas. A

gestão da solução é feita a partir da plataforma OmniVista 4760, podendo ser integrada em

clientes com siste mas Alcatel OmniPCX Enterprise. [Alcatel]

Page 101: Telefonia Voip

101

Conclusão

A segurança deve ser encarada não 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 estratégia clara na definição de soluções

de segurança, no que diz respeito ao desenvolvimento dos seus pro- dutos, bem como dos

serviços dispo- níveis quando integrados em redes de comunicações IP. Esta é, a nosso ver,

uma estratégia evolutiva procurando acompanhar as constantes necessidades dos merca- dos

empresariais.

Page 102: Telefonia Voip

102

Conclusões

Visto que muito já foi feito pela tecnologia VoIP, podemos dizer que a tecnologia de

transmissões de voz sobre IP pode funcionar muito bem sob as infra-estruturas que temos

acesso hoje em dia, além de ser uma ótima opção quando pensa-se em redução de custos.

Depois de avaliar todas as características que a VoIP apresenta, salientamos que além

de todos os serviços 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 são estas mesmas. Essa concorrência é presente na capacidade de

as redes tradicionais terem uma disponibilidade elevadíssima em comparação à VoIP, e à sua

viabilidade.

Apesar da VoIP ainda conter muitos aspectos desfavoráveis como, por exemplo, à

ainda pouca qualidade de serviço, outros aspectos vêem à favorecer como, por exemplo, o

protocolo SIP, que apresenta nativo em sua ultima versão um ‘bom’ nível de segurança, o que

leva à uma grande aceitação da VoIP pelas empresas.

Podemos também discursar sobre a consolidação da VoIP que por poucas atualizações,

pode vir a ser em pouquíssimo tempo o novo ‘boom’ que a humanidade presenciará depois da

internet.

Page 103: Telefonia Voip

103

Referências Bibliográficas

HERSENT, OLIVER., GURLE, DAVID. E PETIT, JEAN-PIERRE. Telefonia IP. Tradução 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, JOÃO PAULO PEREIRA DE. sIPtel – Um sistema de IPtel com suporte para vídeo utilizando o protocolo SIP. Utad: Universidade de Trás-os-Montes e Alto Douro, 2003. 134p. MARQUES, ALEXANDRE FERNANDEZ. Segurança em Redes IP. 2001. 175p. FERNANDES, NELSON LUIZ LEAL. Voz sobre IP: Uma visão geral. 22p. Disponível 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 Telecomunicações/INATEL. 34p. Disponível em: http://www.inatel.br/posgraduacao/redes/download/VoIP_Pos_Graduacao_Brasilia.pdf Acesso em: 22 abril 2005 LEÃO, OSMAR RIBEIRO., Regras para proteção de redes IP. Universidade Católica do Salvador. 2001. 118p. GALVÃO, MÁRCIO., ZATTAR, ALEXANDRE., Aspectos de segurança em redes voz sobre IP, MSLAB (Módulo Security Lab), 2003, 13p. YOSHIOKA, SERGIO., Aspectos de Segurança 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 março 2005 < http://www.packetizer.com/voip/h323/ > acesso em: 28 março 2005 < http://www.packetizer.com/voip/sip/ > acesso em: 28 março 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&sequence=7&name=Session%20Initiation%20Protocol%20(SIP) > Acesso em: 12 abril 2005

Page 104: Telefonia Voip

104

< 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/#_Toc44927842 > 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.pop-rn.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