You are on page 1of 104

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

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

2
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

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

4
À 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.

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

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

7
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

8
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

9
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

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

11
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

12
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

13
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

14
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).

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

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

17
- 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:

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

19
- 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:

20
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

21
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

22
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

23
(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 à

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

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

H.235 (Security and Encryption for H-Series (H.323 and other H.245-based)
Multimedia Terminals – 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).

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

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

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

29
10.2.3.4

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.

30
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

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

33
meados dos anos 90 na Universidade de Columbia e depois foi normalizada pelo grupo de
trabalho MMUSIC ( Multiparty Multimedia Session Control) do IETF (Internet Engineering
Task Force). Foi definida inicialmente pela RFC (Request For Comment) 2543 em 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.

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

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

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

Linha de início
aaa=bbb
Cabeçalhos
ccc=ddd
eee=fff
Linha em branco

Corpo da mensagem (SDP


limpo, SDP criptografado,…)

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.

36
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:

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

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

Cancel: um pedido Cancel pode ser enviado para interromper um pedido que foi
enviado anteriormente enquanto o servidor ainda 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]

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

Linha de início

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

Via: SIP/2.0/UDP 169.130.12.5 Cabeçalho geral

Call-ID; 187602141351@warchester.bell-telephone.com
From: <sip:a.g.bell@bell-telephone.com>
TO: T.A. Watson <sip:watson@bell-telephone.com>
Call-ID: 187602141351@warchester.bell-telephone.com
Cabeçalho
Cseq: 1 INVITE de pedido

Subject: Mr. Watson, come here.

Cabeçalho
da entidade
Content-Type: application/sdp
Content-Length: 885
Linha em branco

<CR LF>

v=0 Dados SDP

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]

39
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

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

41
SIP/2.0 302 Moved temporarily Linha de status

From: sip: Charlie@caller.com


To: sip: alice@anywhere.com; tag=2332462 cabeçalhos

Call-ID: 27182@caller.com
Location: sip:bob@anywhere.com
Expires: Wed, 29 jul 1998 9:00:00 GMT
Cseq: 1 INVITE
Linha em branco

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

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

Chamadas SIP

As chamadas SIP 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.

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

Originador da chamada Pessoa a ser chamada

Envio do INVITE

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

Troca de
informações

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.

43
A B
Troca de informações

BYE sip: a@192.168.7.1 SIP/2.0


v: SIP/2.0/UDP 192.168.7.2:3456
i: a2e3a@192.168.7.1
From: sip:b@192.168.7.2
To: sip: a@192.168.7.1
Cseq 2 BYE

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

Fig. 1.16: 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.

A B

INVITE

200 OK

ACK

Troca de informações

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

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

A B

INVITE

SIP/2.0 486 Busy Here


Via: SIP/2.0/UDP 192.190.132.31:3456
Call-ID: a2e3a@192.190.132.20
From: sip: a@192.190.132.20
To: sip: john@192.190.132.31
Cseq 1 INVITE

ACK sip: B@192.190.132.31 SIP/2.0


Via: SIP/2.0/UDP 192.190.132.20:3456
Call-ID: a2e3a@192.190.132.20
From: sip: a@192.190.132.20
To: sip: b@192.190.132.31
Cseq 2 ACK

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

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

45
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

46
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, é

47
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.
48
O MGCP pode-se dizer que é um protocolo mestre/escravo, pois os gateways ficam
aguardando para executar comandos dos Call Agents. Em seu modelo de 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

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

50
Comandos MEGACO

Tabela 1.2: Comandos MEGACO. [Unisal]

COMPARAÇÃO ENTRE MGCP E MEGACO

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

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

53
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.
54
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.

55
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

56
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

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

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

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

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

61
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

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

63
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:

64
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;

65
0 1 2 3 4 5 6 7 Octet

Version P Reception report count 1

Packet type 2

Length 3-4

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

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

20 bytes 8 bytes 12 bytes 20 bytes

40 bytes

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

A partir da figura acima podemos ver para se transportar todos esses dados usa-se
muita largura de banda, por isso o uso do protocolo CRTP, este protocolo comprime todo o
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.

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

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

69
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

70
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 VoIP

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.

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

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

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

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

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

76
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

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

78
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

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

80
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

81
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.
82
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]

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

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

85
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

86
eles podem ser úteis para monitorar ataques baseados em UDP e HTTP que podem ser
executados contra os componentes da infra-estrutura.
Por este motivo, 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]

87
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

88
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

89
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

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

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

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

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

94
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

95
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:
96
K=clear:<chave de criptografia>

Esse formato refere-se aos algoritmos de criptografia descritos no RFC 1890 (“perfil
RTP para conferencias de áudio e 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
97
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]

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

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

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

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

102
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&s
equence=7&name=Session%20Initiation%20Protocol%20(SIP) > Acesso em: 12 abril 2005

103
< http://www.gta.ufrj.br/grad/00_2/alexandre/VoIP.html > Acesso em 28 maio 2005

<http://www.cefetrio.hpg.ig.com.br/ciencia_e_educacao/8/trabalhos/rlc_1_2003/VoIP/#_Toc
44927842 > Acesso em: 18 maio 2005

< http://www.voip.nce.ufrj.br/courses/nce/aula8.pdf > Acesso em: 19 maio 2005

< http://www.am.unisal.br/graduacao/ansi/pdf/palestra-ssi-2004.pdf > Acesso em: 20 maio


2005

<http://www.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

104

You might also like