UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS...
64
UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS TECNOLÓGICAS CURSO DE ENGENHARIA DE TELECOMUNICAÇÕES PROTÓTIPO DE UM SISTEMA DE TELEFONIA IP CRIPTOGRAFADO BASEADO NO PADRÃO SIP HUMBERTO MAXCLIOFF CALVACHE BLUMENAU, 2005
Transcript of UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS...
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS TECNOLÓGICAS
CURSO DE ENGENHARIA DE TELECOMUNICAÇÕES
PROTÓTIPO DE UM SISTEMA DE TELEFONIA IP CRIPTOGRAFADO BASEADO
NO PADRÃO SIP
HUMBERTO MAXCLIOFF CALVACHE
BLUMENAU, 2005
I
HUMBERTO MAXCLIOFF CALVACHE
PROTÓTIPO DE UM SISTEMA DE TELEFONIA IP CRIPTOGRAFADO BASEADO
NO PADRÃO SIP
Trabalho de Conclusão de Curso submetido à
Universidade Regional de Blumenau para a
obtenção dos créditos na disciplina Trabalho
de Conclusão de Curso do curso de
Engenharia de Telecomunicações.
Prof. Francisco Adell Péricas – Orientador
BLUMENAU, 2005
II
PROTÓTIPO DE UM SISTEMA DE TELEFONIA IP CRIPTOGRAFADO BASEADO
NO PADRÃO SIP
HUMBERTO MAXCLIOFF CALVACHE
ESTE TRABALHO DE CONCLUSÃO DE CURSO FOI JULGADO ADEQUADO
PARA OBTENÇÃO DOS CRÉDITOS NA DISCIPLINA DE TRABALHO DE
CONCLUSÃO DE CURSO OBRIGATÓRIA PARA A OBTENÇÃO DO TÍTULO DE:
ENGENHEIRO DE TELECOMUNICAÇÕES
________________________________________________
Prof. Francisco Adell Péricas, Ms. – Orientador, FURB
________________________________________________
Prof. Fábio Luis Perez – Coordenador do TCC, FURB
BANCA EXAMINADORA
______________________________________________
Prof. Fábio Rafael Segundo
______________________________________________
Prof. Orlando José Tobias
Blumenau, 1 de Julho de 2005
III
DEDICATÓRIA
Dedico este trabalho à memória de meu avô
que me acompanha e me apóia lá do alto.
IV
AGRADECIMENTOS
A Deus por estar sempre presente na minha vida através do seu infinito
amor.
Aos meus amados pais Humberto Maxclioff Calvache Chiliquinga e Ionira
Machado Brincas pelo apoio e amor incondicional.
Aos meus queridos irmãos pelo companheirismo e amor que sempre
dispuseram.
À minha namorada pelo incentivo e carinho.
À todos amigos conquistados durante a graduação e que me deram força
para concluir o curso de engenharia.
Ao meu orientador Francisco Adell Pericas que acreditou no meu trabalho e
se dispôs a orientar-me.
V
RESUMO
A utilização da telefonia IP e a convergência total das comunicações possibilitam às organizações reduzir drasticamente os custos ao mesmo tempo em que potencializam novas formas de negócio. Este trabalho apresenta o desenvolvimento de um protótipo de um sistema de telefonia IP criptografado entre dois microcomputadores baseado no Padrão SIP, desenvolvido para comunicação full-duplex de voz em um ambiente Windows. Palavras chave: Telefonia IP, VoIP, SIP, Criptografia.
VI
ABSTRACT
The use of IP Telephony and total convergence of the communications enable the organizations to reduce drastically the costs at the same time that they make new ways of business capable. This work presents the development of a prototype of a system of IP Telephony Cryptographed between two microcomputers based on SIP standard, developed for voice full-duplex communication at a Windows environment.
Keywords: IP Telephony, VoIP, SIP, Cryptography.
VII
SUMÁRIO
1 INTRODUÇÃO.....................................................................................................9
1.1 MOTIVAÇÃO............................................................................................................9 1.2 OBJETIVOS DO TRABALHO ...............................................................................10 1.4 ORGANIZAÇÃO DO TRABALHO .......................................................................11
2 TELEFONIA IP ..................................................................................................12
2.1 INTRODUÇÃO........................................................................................................12 2.2 AMBIENTES PARA TELEFONIA IP ....................................................................15 2.3 VOZ..........................................................................................................................17 2.4 QUALIDADE DE SERVIÇO ..................................................................................19 2.5 PROTOCOLOS DE TELEFONIA IP ......................................................................21
2.5.1 TCP/IP .................................................................................................21 2.5.2 UDP .....................................................................................................22 2.5.3 RTP......................................................................................................23 2.5.4 RTCP ...................................................................................................26 2.5.5 SIP & H.323 .........................................................................................27
3 SIP .....................................................................................................................29
3.1 INTRODUÇÃO........................................................................................................29 3.2 ENDEREÇOS SIP....................................................................................................35 3.3 SDP...........................................................................................................................35 3.4 SEGURANÇA SIP ...................................................................................................36
4 CONCEITOS DE CRIPTOGRAFIA....................................................................38
4.1 INTRODUÇÃO........................................................................................................38 4.2 CRIPTOGRAFIA .....................................................................................................39
4.2.1 Sistemas de Chaves Simétricas ..........................................................40 4.2.2 Sistemas de Chaves Assimétricas.......................................................41
5 DESENVOLVIMENTO DO TRABALHO............................................................42
5.1 INTRODUÇÃO........................................................................................................42 5.2 REQUISISTOS DO PROTÓTIPO...........................................................................42 5.3 ESPECIFICAÇÃO ...................................................................................................43
5.3.1 Diagrama de Caso de Uso...................................................................44 5.3.2 Estrutura de Camadas do Protótipo.....................................................46 5.3.3 Diagrama de Classes...........................................................................47
5.4 IMPLEMENTAÇÃO ...............................................................................................49 5.4.1 Visual C++ 6 ........................................................................................50 5.4.2 JVOIPLIB .............................................................................................50 5.4.3 Protótipo ..............................................................................................53
6 CONCLUSÃO ....................................................................................................59
6.1 TRABALHOS FUTUROS.......................................................................................60
7 REFERÊNCIAS BIBLIOGRÁFICAS..................................................................61
VIII
LISTA DE FIGURAS
Figura 1 – Multiplexação Estatística ........................................................................................14 Figura 2 – Telefonia IP entre dois computadores.....................................................................15 Figura 3 – Telefonia IP entre um telefone e um computador...................................................16 Figura 4 – Telefonia IP entre dois telefones convencionais.....................................................17 Figura 5 – (a) Onda de áudio; (b) Amostragem; (c) Quantização ............................................18 Figura 6 – Codecs de Áudio do ITU-T.....................................................................................19 Figura 7 – Arquitetura do Protocolo TCP/IP............................................................................22 Figura 8 – Estrutura do Cabeçalho UDP ..................................................................................23 Figura 9 – Formato pacote RTP ...............................................................................................25 Figura 10 – Arquitetura SIP .....................................................................................................30 Figura 11 – Mensagem de pedido SIP......................................................................................31 Figura 12 – Valores do campo “Cseq” .....................................................................................32 Figura 13 – Resposta SIP .........................................................................................................34 Figura 14 – Sinalização completa da chamada.........................................................................34 Figura 15 – Criptografia de um pedido ....................................................................................37 Figura 16 – Formas de ação do invasor....................................................................................38 Figura 17 – Modelo Ilustrativo de Criptografia........................................................................39 Figura 18 – Criptografia Simétrica...........................................................................................40 Figura 19 – Criptografia Assimétrica .......................................................................................41 Figura 20 – Criptografia dos Pacotes de Voz ...........................................................................43 Figura 21 – Mensagem SIP ......................................................................................................44 Figura 22 – Diagrama de Caso de Uso .....................................................................................45 Figura 23 – Estrutura de Camadas do Protótipo.......................................................................47 Figura 24 – Diagrama de Classes de Controle e Gerenciamento .............................................48 Figura 25 – Ambiente de Trabalho do Visual C++ 6 ...............................................................50 Figura 26 – Classes de Criação da Sessão................................................................................52 Figura 27 – Classes Responsáveis pelo Tratamento da Voz ....................................................52 Figura 28 – Arquivo Contatos.txt .............................................................................................53 Figura 29 – Tela Inicial ............................................................................................................54 Figura 30 – Preenchimento de Campos....................................................................................55 Figura 31 – Pedido INVITE .....................................................................................................56 Figura 32 – Recepção do Pedido INVITE................................................................................56 Figura 33 – Estabelecimento de Sessão VoIP ..........................................................................57 Figura 34 – Finalização de Sessão por “BYE”.........................................................................58 Figura 35 – Finalização de Sessão por “CANCEL”.................................................................58
LISTA DE QUADROS
Quadro 1 – Protocolos utilizados no H.323 e SIP ....................................................................28 Quadro 2 – Endereços SIP........................................................................................................35 Quadro 3 – Casos de uso ..........................................................................................................45 Quadro 4 – JThread ..................................................................................................................53
9
1 INTRODUÇÃO
1.1 MOTIVAÇÃO
A troca de informações através dos meios de comunicações que estão
disponíveis atualmente não para de crescer. Quanto mais rápido é o acesso à
informação requisitada, mais eficaz e produtivo é o trabalho a ser realizado. Com
isso, tecnologias como a comunicação sem fio (wireless), telefonia e principalmente
a Internet vêm sofrendo grandes avanços ao longo dos anos. Dentro deste contexto,
surge um novo conceito com o nome de Next Generation Network (NGN), que nada
mais é do que a convergência das redes de telefonia e de dados existentes graças à
flexibilidade do Internet Protocol (IP). Para Nazario (2003), um dos parâmetros que
impulsionam essa nova realidade é a Telefonia IP. Esta almeja a substituição da
rede comutada por circuitos pela rede comutada por pacotes com o intuito de
realizar a integração dos serviços que envolvem voz, dados e aplicações multimídia
como as videoconferências. A utilização da Telefonia IP e a convergência total das
comunicações possibilitam às organizações reduzir drasticamente os custos ao
mesmo tempo em que potencializam novas formas de negócio.
Segundo Sousa (2001), a comunicação utilizando a tecnologia IP possui
basicamente o mesmo princípio da telefonia pública. Para realizar chamadas são
necessários protocolos de sinalização e controle para executar algumas tarefas
como localização de usuário, notificação de chamada, início de transmissão de voz,
finalização de transmissão de voz e desconexão.
Dois padrões disputam a hegemonia da Telefonia IP: o H.323 da ITU-T
(Internacional Telecommunications Union), presente em muitos equipamentos e
softwares VoIP, e o Session Initiation Protocol (SIP), proposto pelo IETF (Internet
Engineering Task Force), que apesar do curto tempo do processo de padronização,
tem mobilizado muitos fabricantes da área de telefonia e de dados, por causa da sua
flexibilidade e aderência a padrões genuinamente Internet e de arquitetura aberta.
O SIP é o padrão do IETF para conferência multimídia sobre IP. Ele é um
protocolo de controle/sinalização (definido no RFC 3261) que pode ser usado para
estabelecer, manter e terminar sessões ou chamadas multimídia entre usuários.
Como outros protocolos Voice Over IP (VoIP), o SIP é designado para endereçar
10
funções de sinalização e gerenciamento de sessão dentro de uma rede. A
sinalização permite que as informações da chamada sejam transmitidas entre os
limites da rede. O gerenciamento de sessão fornece a habilidade de controlar os
atributos de uma chamada fim a fim.
As principais funcionalidades exercidas por esse padrão são:
��localização de usuários;
��estabelecimento de chamadas;
��suporte a unicast ou multicast.
Para transmissão do fluxo de voz, utiliza-se o protocolo da camada de
aplicação do modelo de referência Transmission Control Protocol/Internet Protocol
(TCP/IP) denominado Real Time Protocol (RTP). O RTP utiliza preferencialmente o
serviço de transporte User Datagrama Protocol (UDP) para transmitir os pacotes.
Segundo Hersent (2002), o RTP foi projetado para permitir que os
receptores compensem o jitter (variação do tempo de atraso) e a perda de seqüência
dos pacotes introduzidos pelas redes IP, podendo ser utilizado para qualquer fluxo
de dados em tempo real, como voz e vídeo.
Observando a tendência do mercado e tendo em vista a preocupação na
confiabilidade necessária para implementação de serviços que regem a Telefonia IP,
este trabalho propõe aliar os dois fatores através de um protótipo de um sistema de
Telefonia IP Criptografado baseado no padrão SIP do IETF. Este se caracteriza por
um software para comunicação entre computadores de uma mesma LAN através
dos protocolos SIP e RTP que farão o transporte da voz entre os recursos da rede,
tendo como objetivo principal a redução dos custos que envolvem a telefonia
convencional.
1.2 OBJETIVOS DO TRABALHO
Este trabalho tem a finalidade de desenvolver um protótipo de um sistema
de Telefonia IP baseado no padrão SIP, com criptografia através da biblioteca
JVOIPLIB criada por Liesenborgs (2004).
Os objetivos específicos deste trabalho são:
11
��aquisição e análise da biblioteca JVOIPLIB desenvolvida por Liesenborgs
e disponibilizada gratuitamente na Internet;
��criação de uma sessão de Telefonia IP usando o padrão SIP;
��captura de áudio e criptografia do fluxo RTP de dados;
��decriptografia do fluxo RTP de dados e reprodução do seu conteúdo.
1.4 ORGANIZAÇÃO DO TRABALHO
Este trabalho está organizado em 6 capítulos.
Capítulo 1 – Introdução – Uma breve introdução sobre o assunto de
pesquisa justificando a motivação para realização do trabalho e apresentando o
objetivo principal a ser alcançado.
Capítulo 2 – Telefonia IP – Apresenta a fundamentação sobre o tema, os
protocolos que regem a comunicação, a qualidade de serviço e as suas principais
limitações.
Capítulo 3 – SIP – Apresenta o padrão estabelecido pelo IETF e adotado
neste trabalho.
Capítulo 4 – Criptografia – Faz uma revisão bibliográfica sobre os principais
conceitos de segurança.
Capítulo 5 – Implementação do Protótipo - Realiza a descrição do protótipo
através das suas especificações e características. Além de apresentar o software
desenvolvido e o seu funcionamento através das principais telas.
Capítulo 6 – Considerações Finais e Conclusão – algumas considerações
sobre os resultados obtidos e apresenta as principais conclusões deste trabalho.
12
2 TELEFONIA IP
2.1 INTRODUÇÃO
A possibilidade da comunicação por voz trafegando pela Internet, ao invés
do Sistema de Telefonia Pública Comutada (STFC), tornou-se realidade em fevereiro
de 1995 quando a Vocaltec Inc introduziu seu software chamado Telefone Internet.
Projetado para rodar em cima de um computador pessoal 486/33 MHz (ou superior)
e equipado com placa de som, alto-falante, microfone e modem, o software
comprimia o sinal de voz e o transformava em pacotes IP para sua transmissão na
rede. Segundo Cansado (2004), essa comunicação entre microcomputadores só era
possível se ambas as partes utilizassem o software.
Desde então, em um curto espaço de tempo, a Telefonia Internet tem
avançado rapidamente e despertado o interesse de muitos fabricantes.
A voz sobre IP (VoIP) abre mercado para inúmeras soluções de aplicações e
está sendo acompanhada por grandes fabricantes como Cisco, 3Com, Avaya e
AT&T. "VoIP está em curva exponencial de crescimento", opina o engenheiro de
produto da Siemens, Otávio Bruno (CRN, 2002).
A integração dos serviços de telecomunicações através da convergência das
redes de dados e de voz, tendo como acesso à apenas uma interface, dá vida ao
novo conceito de NGN que vem sendo amplamente discutido em palestras e
congressos realizados no mundo todo.
Essa transmissão conjunta de voz e dados através do protocolo IP é
implementada através da comutação de pacotes que caracteriza a tecnologia de
Telefonia IP.
Segundo Oliveira (2000), o termo Telefonia IP, Telefonia Internet ou ainda
Voz sobre IP, tem sido aplicado à utilização de redes baseadas no protocolo IP na
camada de rede para transporte de voz, em especial da Internet.
Para efetuar uma comparação entre a Telefonia IP e a telefonia
convencional atualmente praticada, precisa-se entender os processos de comutação
envolvidos.
A rede de telefonia convencional, representada pela rede de telefonia
pública ou Public Switched Telephonic Network (PSTN) é baseada no método de
13
multiplexação por divisão do tempo (TDM) e na comutação por circuitos. Nesta, um
assinante (usuário) A, ao se comunicar com outro assinante de destino B, necessita
de um circuito exclusivo para garantir o canal de comunicação. Este circuito, de
largura de banda determinada (limitada), normalmente 64 kbps, é usado para o
transporte de voz entre o assinante A e o assinante B, e multiplexado para
transmissão em um meio físico compartilhado. Vários canais podem ser
multiplexados em um feixe de canais do tipo E1 (32 canais) ou T1 (24 canais) para
ligação entre centrais telefônicas.
A restrição da largura de banda citada anteriormente decorre da
necessidade de compartilhar o canal entre muitos usuários a qualquer momento,
exigindo uma diminuição dessa largura de banda, utilizando apenas a banda de
freqüência essencial (300 a 3400 Hz) para uma transmissão satisfatória da voz
humana.
De acordo com Oliveira (2000) a comutação é dita como baseada em
circuitos porque os elementos do sistema que garantem que a voz chegue ao seu
destino são comutadores que estabelecem circuitos na fase de negociação da
chamada e mantêm estes circuitos até o seu término. Caso não haja comunicação
entre os dois assinantes, como em momentos de silêncio, o canal é desperdiçado.
Conforme Guimarães (1999), nas redes de comutação de pacotes, tais como
a Internet, intranet (redes IP privadas), e outras redes de dados, não há uma reserva
da largura de banda entre os pontos de origem e destino. Esta tecnologia de rede
faz a divisão das mensagens em pequenos pacotes (ou células, dependendo do
tamanho), onde cada pacote pode percorrer uma rota diferente, através da rede, que
é compartilhada com pacotes de mensagens de outros usuários. Desta maneira, a
comutação de pacotes requer que estes tenham um cabeçalho que garanta uma
rota de destino exata, com a reconstrução da mensagem na sua seqüência correta
no terminal de destino.
A vantagem das redes de comutação de circuitos é que elas proporcionam
uma largura de banda dedicada. Fato que pode garantir a qualidade de serviço (QoS
– Quality of Service) no tráfego da voz, que será abordada posteriormente. Como
desvantagem há a utilização ineficiente dos recursos da rede. Conforme descrito
anteriormente, se durante uma ligação telefônica os dois usuários ficam em silêncio,
nenhuma informação estará sendo transmitida, porém a linha (largura de banda)
continua reservada, isto é, outros usuários da rede de telefonia pública (no caso, os
14
seus assinantes) não poderão realizar uma chamada. Na telefonia convencional dois
canais são reservados para cada conversação, independente da existência ou não
de tráfego de voz nos circuitos, ou seja, mesmo nos momentos de silêncio. Esses
pequenos instantes de tempo significam desperdício de recursos, uma vez que hoje
em dia os processadores com algoritmos de supressão de silêncio, utilizados
principalmente em redes de comutação de pacotes, reconhecem uma largura de
banda não utilizada (inexistência de informação), liberando-a para outro usuário.
Isso é conhecido como “multiplexação estatística”, pois se trata de multiplexar várias
conversações em um único canal de comunicação, em vez de ocupar uma largura
de banda durante todo o tempo, esta “largura de banda individual“ pode ser usada
por outro usuário qualquer durante os momentos de silêncio, como pode ser
ilustrado na figura 1.
Figura 1 – Multiplexação Estatística
Na Telefonia IP há um melhor aproveitamento dos recursos disponíveis na
rede e uma perda na qualidade de serviço. Pois apesar da multiplexação estatística
otimizar recursos, ela introduz incertezas na rede como o jitter (atraso variável), que
precisa ser corrigido no lado do receptor. O jitter surge devido ao enfileiramento dos
pacotes nos roteadores da rede. Mesmo assim, a voz sobre IP se destaca como a
principal tecnologia para próxima geração da rede telefônica.
Segundo Oliveira (2000), as vantagens da utilização da tecnologia de
Telefonia IP são:
��compartilhamento da rede para tráfego de voz e dados (e-mail, FTP,
etc.);
��unificação das redes de transporte, sinalização e gerência sobre a
mesma rede, com economia de infra-estrutura e manutenção;
��meio de transmissão de baixo custo, comparado ao sistema telefônico;
15
��possibilidade de compactação e supressão de silêncio, reduzindo a
largura de banda utilizada;
��capilaridade da rede já instalada no mundo, a Internet, cujo o alcance é
indiscutível;
��possibilidade de oferecer outros serviços como correio de voz, call center
via internet, segunda linha virtual, com reconhecimento e síntese de voz,
através de interface telefônica.
Para Oliveira (2000), a redução de custos na Telefonia IP, deve-se
principalmente à tecnologia em si, ou seja, a comutação da rede IP é feita através de
software, por dispositivos como roteadores e switches (dispositivos que filtram e
encaminham pacotes entre segmentos de redes locais), e não através de hardware
como na rede pública atual. A rede IP não garante qualidade de serviços, como por
exemplo, atrasos na voz, perda de pacotes e ruídos na voz não previstos, serviços
estes garantidos na telefonia convencional que a deixam com custo mais elevado.
2.2 AMBIENTES PARA TELEFONIA IP
O tráfego da voz sobre pacotes IP através da Telefonia IP pode ser
estabelecido por meio de várias configurações entre os seus terminais. Estes podem
ser computadores ou mesmo telefones convencionais. Neste caso, um gateway é
necessário para converter os sinais de voz no formato que a rede de telefonia
convencional utiliza.
Figura 2 – Telefonia IP entre dois computadores
16
A figura 2 mostra o modelo mais simples de Telefonia IP, no qual está
baseado este trabalho. Nele a comunicação entre os dois usuários é feita através da
rede IP, portanto a rede telefônica convencional não é utilizada. A codificação de voz
é realizada pelas placas multimídia dos computadores. Segundo Oliveira (2000),
existem vários softwares para este tipo de aplicação, podendo utilizar um protocolo
proprietário ou padrão, permitindo, neste caso a interação de softwares de diferentes
fabricantes.
Figura 3 – Telefonia IP entre um telefone e um computador
No ambiente mostrado na figura 3 há a presença de um gateway. Este
equipamento faz a interface entre a rede de telefonia convencional e a rede de
Telefonia IP. O gateway é responsável por converter voz (analógico-digital),
sinalização e controle da rede telefônica convencional para a rede IP, permitindo a
comunicação entre os usuários dos dois ambientes: rede IP e telefonia
convencional.
Os protocolos envolvidos com a Telefonia IP terminam nesse equipamento
sendo processados e decodificados. A partir daí, a telefonia convencional fica
responsável pelo tráfego da voz.
17
Figura 4 – Telefonia IP entre dois telefones convencionais
Na figura 4 a Telefonia IP é utilizada para fazer ligação entre dois assinantes
da telefonia convencional. Sendo assim, a rede IP é utilizada como forma de
transporte da voz, com o intuito de reduzir os custos envolvidos em uma ligação, já
que a rede baseada na comutação de pacotes caracteriza-se por ser mais barata.
Um exemplo disso seria a utilização desse ambiente para realizar chamadas
interurbanas ou internacionais. As operadoras públicas podem ocasionalmente
substituir parte de sua rede convencional por uma rede IP.
2.3 VOZ
Segundo Tanenbaum (2003), o ouvido humano é surpreendentemente
sensível a variações de som que duram milésimos de segundo, ao contrário do olho
que não percebe mudanças no nível da luz que durem menos de alguns milésimos.
Isso significa que, em uma transmissão multimídia, o atraso afeta mais a qualidade
do som percebido do que a qualidade da imagem percebida. Essa condição é o
principal fator de limitação da tecnologia de Telefonia IP, pois a rede IP introduz
perdas de pacotes, atraso e jitter que degradam sensivelmente a qualidade de voz.
Para que a voz possa trafegar na rede IP ela precisa ser digitalizada,
necessitando-se, portanto, de uma conversão analógico-digital (A/D). O processo de
conversão A/D pode ser dividido em três fases:
18
��amostragem: trata-se do processo de medir valores instantâneos de um
sinal analógico em intervalos regulares. O intervalo entre as amostras é
determinado por um pulso de relógio e a freqüência desse relógio é
chamada de Taxa de Amostragem. De acordo com o teorema de Nyquist,
para reproduzir fielmente o sinal, a taxa ou freqüência de amostragem
deve ser de, pelo menos, o dobro da maior freqüência contida no sinal a
ser amostrado (OLIVEIRA, 2000). Um sinal analógico é convertido em
um sinal digital através da captura de uma série de amostras da fonte
analógica. A união dessas amostras forma o equivalente digital de uma
onda sonora;
��quantização: o sinal amostrado é convertido para valores discretos na
quantização, ou seja, é considerada a amplitude deste sinal apenas em
níveis discretos. Essa infinidade de valores obtidos do sinal analógico
passam a ser representados por uma quantidade finita de bits, para obter
um sinal digital. A figura 5 mostra o processo quantização de uma onda
de áudio em valores discretos;
Figura 5 – (a) Onda de áudio; (b) Amostragem; (c) Quantização
��compressão: para reduzir a banda do canal necessária para a
transmissão de voz digitalizada são usadas técnicas de compressão de
voz que devem acontecer em tempo real para possibilitar a comunicação
e a interação. Segundo Oliveira (2000) a compressão de sinais é
baseada em técnicas de processamento que retiram informações
redundantes, imprevisíveis e inúteis. Os dispositivos responsáveis pela
codificação da voz são conhecidos como voice codecs, ou simplesmente
vocoders. Os vocoders analisam o conteúdo espectral do sinal da fala e
identificam os parâmetros que são entendidos pelo ouvido. Estes
19
parâmetros são transmitidos e usados para sintetizar o padrão de voz. A
forma de onda resultante pode não ser semelhante a original, mas as
diferenças não são percebidas ou, ainda que o sejam, são consideradas
aceitáveis para a aplicação.
Segundo Guimarães (1999), os algoritmos de compressão de voz
possibilitam uma alta qualidade de voz fazendo um uso eficiente da largura de
banda do canal de comunicação. A compressão pode acontecer com ou sem perda
de informação. A escolha depende da degradação que se admite para o sinal e do
fator de compressão que se deseja atingir. O Pulse Code Modulation (PCM) é um
padrão de codificação da voz e consume 64Kbps por canal. Existem outros
algoritmos de compressão de voz que tentam modelar o PCM mais eficientemente
utilizando menos bits. Na figura 6 são demonstrados os principais codecs e suas
aplicações segundo recomendações do ITU-T.
Figura 6 – Codecs de Áudio do ITU-T
Fonte: Nazario, 2003. p. 16
2.4 QUALIDADE DE SERVIÇO
Conforme RNP (1999), desde a sua origem, o protocolo IP foi desenvolvido
e implementado como um protocolo de comunicação com controle de tráfego
utilizando a regra do melhor esforço (Best-effort ou Lak of QoS). Nele cada usuário
da rede envia seus dados e compartilha a largura de banda com todos os fluxos de
dados dos outros usuários. Os fluxos realizam a melhor forma possível para chegar
ao seu destino, conforme as rotas definidas e a largura de banda disponível. Quando
há congestionamento, os pacotes são descartados sem distinção. Desta forma não
20
há garantia de que o serviço será realizado com sucesso, nem mesmo de
desempenho. Entretanto muitas aplicações necessitam de tais garantias e uma
delas é a Telefonia IP, que é dita como uma aplicação intolerante de tempo real.
Isso se justifica porque segundo Nazario (2003) as pessoas não toleram atrasos na
voz de mais de 200ms, ou seja, o retardo fim a fim do tráfego de voz deve estar
dentro de limites que dependem da aplicação, podendo variar:
��0 a 150 ms – aceitável para a maioria das aplicações;
��150 a 400 ms – aceitável cuidando com o impacto do atraso na
aplicação;
��acima de 400 ms – inaceitável para a maioria das aplicações.
De acordo com Hersent (2002), os principais parâmetros responsáveis por
esses atrasos e que caracterizam uma rede de pacotes são:
��latência;
��largura de banda;
��perda de pacotes ou de seqüência.
Para resolver o problema da largura de banda, não adianta apenas
aumentar a capacidade de transmissão da linha até suprir as necessidades da
aplicação. Um provedor também deve assegurar que cada usuário da rede adquira
uma parte justa dessa banda (como uma reserva de recursos).
A perda de pacotes e a de seqüência estão intimamente ligadas com o
problema de largura de banda, mas além disso são influenciadas pela estabilidade
de rota da rede, administração eficiente de fila nos roteadores e o próprio uso de
controle de congestionamento (Internet Control Message Protocol (ICMP), o
protocolo de controle de mensagens na Internet – dissipação de recursos, etc.) nas
extremidades da rede e no backbone.
A latência é considerada o problema mais difícil a ser tratado. É comum
afirmarem que o IP é inadequado para transporte de dados com latência controlada,
mas segundo Hersent (2002), essa afirmativa não procede pois Parekh e Gallager
desenvolveram uma abordagem em 1993 que os levou à construção de uma família
de algoritmos de fila que eles chamaram de enfileiramento balanceado. Embora
21
esses algoritmos sejam difíceis de implementar na prática, eles podem garantir um
limite superior na latência em alguns fluxos de dados.
Segundo RNP (1999), atualmente existem dois modelos desenvolvidos pelo
IETF para implementar QoS na Internet: serviços integrados (IntServ) e serviços
diferenciados (DiffServ). IntServ é modelo baseado na reserva de recursos,
enquanto que serviços diferenciados é uma proposta onde os pacotes são marcados
de acordo com classes de serviços pré-determinadas.
2.5 PROTOCOLOS DE TELEFONIA IP
A seguir serão apresentados os principais protocolos envolvidos na
comunicação da Telefonia IP.
2.5.1 TCP/IP
A arquitetura TCP/IP é, na verdade, um grupo de protocolos que trabalham
conjuntamente, com o objetivo de estabelecer a comunicação e a transferência de
dados entre dois ou mais computadores ligados em rede.
O Transmission Control Protocol (TCP), como o próprio nome diz, controla a
transmissão dos dados, cuidando para que os dados enviados por um computador
cheguem integralmente ao destino correto.
O TCP nada mais é que uma biblioteca de rotinas instaladas nos
computadores origem e destino (ou seja, todos os computadores que utilizem a pilha
de protocolos TCP/IP para se comunicar) que as aplicações, como HTTP, e-mail,
Telnet, e outras, utilizam quando precisam executar o transporte de dados entre
computadores.
Para melhor gerenciar a transmissão, o TCP quebra os dados a serem
transmitidos em blocos menores, que chamamos de pacotes ou datagramas.
Utilizando esta estrutura o TCP é capaz de verificar se os datagramas chegam ao
destino correto ou se não houve perda de dados durante a transmissão,
retransmitindo o datagrama se necessário. Fará também o processo inverso,
juntando os datagramas no host destino para a reconstituição dos dados originais.
Enquanto o TCP cuida da segurança do envio e recebimento dos
datagramas, o IP é responsável pela transmissão em si, fazendo o serviço de
22
roteamento, ou seja, conduzindo os dados para os endereços corretos. Na verdade,
os dois protocolos se completam: enquanto o IP identifica os endereços e cuida para
que os dados sejam enviados pelo meio físico, o TCP verifica se estes dados
enviados foram transmitidos corretamente (TUTORIAL, 2004).
Os protocolos do TCP/IP atuam em camadas. A idéia é que cada camada de
software utilize e preste serviços para outras camadas. São 4 as camadas que
formam o TCP/IP:
��aplicação: trata das questões de representação, codificação e controle de
diálogo. Protocolos: HTTP, FTP, Telnet, etc.;
��transporte: lida com questões de qualidade de serviços, de
confiabilidade, controle de fluxo e correção de erros. Protocolos: TCP e
UDP;
��internet: tem por finalidade enviar pacotes da origem de qualquer rede na
Internet e fazê-los chegar ao destino, independentemente do caminho e
das redes que tomem para chegar lá. Protocolo: IP;
��acesso à rede: é a camada que se relaciona a tudo aquilo que um pacote
IP necessita para realmente estabelecer um link físico. Protocolo:
Ethernet, WiFi, etc.
Figura 7 – Arquitetura do Protocolo TCP/IP
2.5.2 UDP
O protocolo UDP é restringido a portas e sockets. Ele transmite os dados de
forma não orientada a conexão e atua no mesmo nível da camada de transporte do
23
protocolo TCP. O UDP nada mais é do que uma interface para o protocolo IP. Esse
protocolo substitui o protocolo TCP quando a transferência dos dados não precisa
estar submetida a serviços como controle de fluxo.
A função básica do UDP é servir como multiplexador e demultiplexador para
o tráfego de informações do IP. Assim como o TCP trabalha com portas que
orientam adequadamente o tráfego de informação a cada aplicação de nível
superior. Essas portas são:
��porta de destino: é uma parte do datagrama (uma extremidade) que
indica o aplicativo ao qual se deve enviar a informação que chega;
��porta de origem: localiza-se na outra extremidade do datagrama e indica
o aplicativo que enviou a mensagem. Pode ser usado para reenvio ou
quando não é utilizado é preenchido com zeros.
Figura 8 – Estrutura do Cabeçalho UDP
2.5.3 RTP
Segundo Medeiros (2004) o Real Time Transmission Protocol (RTP) foi
apresentado formalmente em janeiro de 1996 pelo Networkig Working Group do
IETF com objetivo de fornecer uma padronização de funcionalidades para os
aplicativos de transmissão de dados em tempo real como vídeo e áudio, tanto em
redes unicast como nas multicast, entretanto, sem garantir a qualidade de serviço
QoS ou reservar recursos de endereçamento.
O RTP é um protocolo que atua sobre a pilha UDP/IP, não garantindo a
entrega de pacotes (não orientado à conexão). Ele utiliza os serviços de
24
multiplexação e soma de verificação do UDP para estabelecer uma comunicação fim
a fim. As informações de áudio e vídeo produzidas pelo aplicativo remetente são
encapsuladas em pacotes RTP que por sua vez são encapsulados em um segmento
UDP. De acordo com Hersent (2002), quando uma transmissão é iniciada, uma
sessão RTP é criada a partir da comunicação entre os usuários da sessão. Cada
participante usa dois endereços de transporte, no caso do IP, por exemplo, são
utilizadas duas portas UDP na máquina local para cada sessão: uma para o fluxo
RTP e a outra para mensagens RTCP. Conforme Medeiros (2004), o RTP permite
basicamente a especificação dos requisitos de tempo e conteúdo pertinentes à
transmissão multimídia, tanto no envio quanto na recepção através de:
��número de seqüência: o RTP atribui número de ordem aos pacotes. Isto
pode ser usado para verificação das perdas, sequenciamento e possível
redirecionamento de pacotes;
��timestamp (selo de temporização): possibilita a correta temporização dos
pacotes contendo áudio e/ou vídeo;
��envio de pacotes sem retransmissão: característica fundamental das
transmissões multimídias onde o reenvio dos dados não se faz
necessário, pois pequenas perdas são suportadas pelo sistema fim a fim
não comprometendo a qualidade da informação. A não retransmissão
torna o sistema mais robusto. O RTP permite apenas ao receptor notar
as perdas e ou atrasos;
��identificação de origem: necessário para indicar quem enviou o pacote.
Numa conferência multicast, um mesmo fluxo pode ter várias origens;
��identificação de conteúdo: permite a alteração dinâmica dos vocoders em
redes sem garantia de QoS em função das perdas e do atraso a fim de
melhorar a qualidade final do áudio;
��sincronismo: pacotes de um mesmo fluxo podem sofrer diferentes
atrasos. A variação deste atraso é prejudicial à reprodução da mídia.
Buffers adicionais podem então ser utilizados para eliminar a diferença
entre os atrasos (jitter). Esses mecanismos processam informações de
tempo de cada pacote RTP que provê esta informação.
25
O protocolo RTP, por não ser orientado à conexão, não monitora a
transmissão e a recepção dos pacotes. Esta tarefa é realizada por outro protocolo, o
RTCP que será abordado posteriormente.
Na figura 9 é demonstrado o formato do pacote RTP.
Figura 9 – Formato pacote RTP
Abaixo segue a descrição dos campos do cabeçalho:
��V – Versão (2 bits): especifica a versão do RTP.
�� P – Preenchimento/padding (1 bit): Sinaliza a adição de octetos de
enchimento adicionais ao conteúdo da carga (payload) sem fazer parte
da mesma. O último octeto do preenchimento contém a informação de
quantos octetos foram inseridos. Este preenchimento adicional é
normalmente utilizado para uso de algoritmos de criptografia de tamanho
de blocos fixos ou para transmissão de pequenos conteúdos.
��X – Extensão/extension (1 bit): com esse bit marcado, é acrescentado
uma extensão ao cabeçalho original;
��CC – Contador de CSRC/CSRC count (4 bits): informa quantos
identificadores CSRC vem após o cabeçalho fixo. Cada fluxo de mídia
que é adicionado ao cabeçalho RTP incrementa o contador de CSRC
(lista que contém os fluxos contribuintes);
��M – Marcador/marker (1 bit): identifica as fronteiras de um quadro numa
corrente de pacotes;
��PT – Tipo de carga/payload type (7 bits): este campo identifica o formato
da carga do pacote RTP como também a determinação de sua
interpretação pela aplicação;
26
��número de seqüência (16 bits): o número de seqüência põe em ordem
os diversos pacotes de RTP. A cada novo pacote, a numeração é
incrementada de uma unidade. Basicamente, esse ordenamento serve
para o receptor detectar os pacotes perdidos e restaurar a seqüência de
pacotes;
��timestamp (32 bits): reflete o instante em que foi criado o primeiro octeto
de dados do pacote, este tempo deve ser fornecido por um clock preciso
e serve para efetuar a sincronização e o cálculo do jitter do lado do
cliente;
��identificador de fonte de sincronização (SSRC) (32 bits): fonte de um
fluxo RTP. Todos os pacotes RTP com um SSRC comum possuem uma
mesma referência de tempo e de sequenciamento;
��identificador de fonte contribuinte (CSRC) (0...15 x 32 bits cada):
quando um fluxo RTP é 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.
2.5.4 RTCP
Conforme Hersent (2002), o Real Time Control Protocol (RTCP) é
normalmente usado com o RTP para permitir o transporte de algum retorno sobre a
qualidade da transmissão como o jitter da rede, a perda média de pacotes, etc. Além
de poder transportar algumas informações a respeito da identidade dos
participantes, RTCP faz o controle sobre a conexão (transmissão e recepção)
ausente no RTP, diminuindo-se desta forma o overhead que o uso de um único
protocolo teria (LOUREIRO, 1999).
Durante uma sessão multimídia, pacotes são enviados periodicamente entre
participantes de uma sessão RTP. O RTCP, assim como o RTP, atua sobre o UDP,
apresentando diagnósticos de rede e controle de desempenho. O conjunto
RTP/RTCP permite aos receptores compensarem o jitter da rede, por meio do
controle do buffer e sequenciamento apropriado para que medidas corretivas
27
possam ser tomadas, como a diminuição da taxa de transmissão para limitar a
largura de banda utilizada.
Existem vários tipos de pacotes RTCP, um para cada tipo de informação
como é demonstrado a seguir:
��Sender Reports (SR): contém informações de transmissão e recepção
para transmissores ativos;
��Receiver Reports (RR): contêm informações de recepção para ouvintes
que não sejam também transmissores ativos. Cada um desses relatórios
trás informações sobre timestamp e o atraso desde o último relatório do
transmissor recebido;
��Source Description (SDES): nessa mensagem seguem informações
adicionais sobre cada participante de uma sessão RTP (e-mail, telefone,
localização geográfica, etc.) visando exclusivamente sua identificação;
��Bye: enviado por um participante quando ele abandona a conferência;
��APP: adicionam funções específicas de uma aplicação ao pacote RTP.
2.5.5 SIP & H.323
SIP e o H.323 foram criados com o mesmo objetivo: possibilitar o tráfego de
voz e multimídia IP. Tanto um quanto o outro utiliza a inteligência dos equipamentos
na ponta (end points). Porém a suas semelhanças terminam aí, pois além da
diferença de idade (o SIP nasceu três anos após o lançamento do H.323 pelo
Internacional Telecomunications Union (ITU-T) em 1996), eles diferem em outras
questões que serão abordadas a seguir.
Atualmente, por ter mais tempo de estrada, o H.323 leva vantagem em
relação ao SIP, pois vem sendo utilizado por grande parte das operadoras
tradicionais do mercado VoIP. No entanto, o SIP vem ganhando cada vez mais
espaço no setor, principalmente nos EUA e Europa, por sua facilidade de permitir o
desenvolvimento de aplicações.
Segundo Hersent (2002), o SIP faz em uma transação o que a primeira
versão do H.323 fazia em quatro ou cinco trocas de mensagens e pode usar o UDP
ao contrário do H.323 que nas duas primeiras versões tinham que usar o TCP.
28
Através da figura 10 pode-se ter uma idéia da simplicidade do SIP em
relação ao H.323, levando em consideração o número de protocolos utilizado por
cada um.
Quadro 1 – Protocolos utilizados no H.323 e SIP
Ao levar em consideração a questão da escalabilidade, em ambientes de
alto tráfego de chamadas, o SIP exige menos ciclos de CPU para gerar a sinalização
de mensagens. Com isso, o servidor tem condições de, teoricamente lidar com mais
transações do que o H.323, que usa mensagens definidas no H.225 para ajustar o
gatekeeper a ajustar o balanceamento de carga.
Além disso, na questão de segurança, o SIP possui mais alternativas ao
utilizar autenticação por HTTP (Hypertext Transfer Protocol), SSL (Secure Sockets
Layer) e PGP (Predy Good Privacy), ao contrário do H.323 que utiliza apenas o
H.235 (Gateway to Gatekeeper)
Por outro lado, o H.323 possui recursos poderosos para controle de
conferências, sozinho ou combinado com o H.332. Já no SIP, muitos dos recursos
necessários para fazer uma conferência controlada ainda não existem, pois ele não
foi projetado para efetuar esse controle. Porém essa realidade está mudando.
29
3 SIP
3.1 INTRODUÇÃO
Segundo o Request For Comment 3261 (RFC 3261), o Session Initiation
Protocol (SIP) é um protocolo de controle da camada de aplicação que pode
estabelecer, modificar e terminar chamadas ou sessões multimídia.
De acordo com Oliveira (2000), o SIP é um protocolo cliente-servidor
parecido tanto em sintaxe quanto em semântica com o HTTP, pois utiliza os mesmos
cabeçalhos, erros e regras de codificação.
Geralmente as requisições são geradas por uma entidade cliente e enviadas
para uma entidade receptora ou servidor. O servidor processa as mensagens e
então envia uma resposta para o cliente.
As entidades SIP se comunicam usando transações. O SIP chama cada
transação de pedido e cada pedido produz uma ou mais respostas. A entidade que
inicia um pedido SIP é chamada de cliente SIP e a entidade que responde são
denominadas de servidor SIP (HERSENT, 2002).
Segundo a Oliveira (2000), o SIP é um protocolo ponto a ponto onde seus
terminais em uma sessão são chamados de User Agents (UAs). Um agente de
usuário pode assumir um dos seguintes papéis:
��User Agent Client (UAC): é responsável por iniciar chamadas, enviando
requisições SIP;
��User Agent Server (UAS): é responsável por responder às chamadas,
enviando respostas.
Existem três tipos servidores que ficam espalhados numa rede de
arquitetura SIP:
�� servidores de registro e localização: recebem atualizações sobre a
localização corrente de cada usuário e disponibilizam essas informações
aos diversos usuários;
��servidores proxy: recebem requisições e enviam-nas para outros
servidores, conhecidos então como servidores next-hop. O servidor next-
30
hop pode ser outro servidor proxy, um UAS ou um servidor de
redirecionamento;
��servidores de redirecionamento: também recebe requisições e determina
um servidor next-hop. Entretanto, ao invés de reenviar neste caso, ele
retorna o endereço do servidor next-hope para o cliente.
Figura 10 – Arquitetura SIP
Para se iniciar uma comunicação SIP é necessário abrir uma conexão de
sinalização entre os pontos de origem e de destino da chamada. Os pontos finais
SIP podem usar TCP ou UDP. No protocolo UDP que será utilizado neste trabalho, o
endereço e a porta a serem usados para as respostas a pedidos SIP estarão
contidos no parâmetro de cabeçalho “Via” do pedido SIP, mostrado na figura 11.
A linha de início do pedido SIP contém o tipo de pedido enviado pelo cliente
SIP, o endereço SIP do usuário destino e a versão SIP utilizada.
31
Figura 11 – Mensagem de pedido SIP
De acordo com Hersent (2002), existem dois tipos de mensagens SIP:
pedidos (requests) e respostas (responses). Elas compartilham um formato comum
onde alguns campos do cabeçalho estão presentes tanto nos pedidos quanto nas
respostas (cabeçalho geral), que são descritos a seguir:
��Via: traz a versão SIP, o transporte usado, o endereço IP do usuário que
faz a chamada e a porta utilizada;
��Call-ID: a primeira parte deste campo deve ser um padrão único dentro
de cada computador e a última um nome de domínio ou endereço IP
(roteáveis) de uma máquina;
��From: este campo deve estar presente em todos os pedidos e respostas.
Ele contém um nome que pode ser mostrado opcionalmente e o
endereço do originador da chamada. Nas respostas, o campo “From” é
simplesmente copiado a partir do pedido, neste caso, não designa ser o
originador da chamada;
��To: este campo indica o destino da chamada, sendo obrigatório em todos
os pedidos e respostas SIP, sendo simplesmente uma cópia do campo
presente nos pedidos;
32
��Cseq: cada pedido deve possuir este campo, composto por um número
de seqüência sem sinal e pelo nome do método que identifica o pedido
que está sendo enviado. A cada novo pedido um número de seqüência é
incrementado iniciando com um valor aleatório. As únicas exceções são
os pedidos ACK e Cancel, que mantêm o número “Cseq” da resposta
recebida (para ACK) ou do pedido cancelado (para o Cancel). No caso
mensagens do tipo resposta, o servidor deve copiar o valor “Cseq” do
pedido para as respostas correspondentes conforme a figura 13.
��Encryption: esse campo de cabeçalho especifica que o corpo da
mensagem (Dados SDP conforme figura 11) e, possivelmente, alguns
cabeçalhos de mensagem foram criptografados. Mais detalhes serão
abordados posteriormente.
Figura 12 – Valores do campo “Cseq”
Conforme Hersent (2002), alguns campos de cabeçalho aplicam-se
diretamente ao corpo da mensagem e fazem parte do “cabeçalho de entidade”:
��Content-Type: descreve o tipo de mídia do conteúdo do corpo da
mensagem e o protocolo utilizado;
��Content-lenght: contém o número de octetos do corpo da mensagem.
33
Segundo Nazario (2003), além dos campos do cabeçalho geral, uma
mensagem de pedido pode transportar campos com informações específicas dos
pedidos. O campo “Accept” é utilizado para indicar os tipos de mídia aceitáveis na
resposta e o campo “Subject” para transportar informações sobre a natureza da
chamada.
Os campos que terminam com CR e LF são utilizados para determinar uma
linha em branco entre os campos.
Todos os pedidos SIP são enviados do terminal cliente para o terminal
servidor e podem ser realizados através de diferentes métodos:
��ACK: este pedido é enviado pelo cliente para confirmar que ele recebeu
uma resposta final do servidor, como 200 OK;
��BYE: este pedido é enviado pelo agente de origem ou de destino para
interromper uma chamada;
��Cancel: este pedido pode ser enviado para interromper um pedido que foi
enviado anteriormente enquanto o servidor ainda não tiver enviado uma
resposta final;
�� Invite: este pedido é usado para iniciar uma chamada;
��Option: um cliente envia este pedido ao servidor para saber as suas
capacidades. O servidor retorna uma lista com os métodos que ele
suporta;
��Register: este pedido possibilita aos clientes registrarem sua localização
atual em um servidor.
Segundo Hersent (2002), um servidor SIP responde a um pedido SIP com
uma ou mais respostas SIP, sendo que a maioria delas (2xx, 3xx, 4xx, 5xx, 6xx) são
respostas que finalizam a transação SIP, enquanto que as respostas 1xx são
provisórias e não finalizam a sessão.
34
Figura 13 – Resposta SIP
Sendo assim, o inicio de uma sessão SIP ocorre através do envio de um
pedido INVITE ao terminal de destino, que irá analisar o pedido observando qual o
tipo de mídia e o endereço de transporte que o originador da chamada deseja
receber os dados. Para indicar que aceita o pedido, o terminal de destino retorna a
origem uma resposta de OK. Esta também contém as capacidades de mídia do
ponto de destino da chamada e onde ele pretende receber os dados de mídia. O
originador da chama precisa confirmar que recebeu de maneira adequada à
resposta do ponto de destino com a mensagem ACK (HERSENT, 2002).
Figura 14 – Sinalização completa da chamada
35
3.2 ENDEREÇOS SIP
De acordo com Hersent (2002), os endereços SIP são URLs (Uniform
Resource Locators) que não se referem ao endereço de transporte a ser chamado,
mas a uma entidade abstrata que pode ser um usuário ou um servidor multimídia.
O formato geral das URLs SIP é user@host, onde a parte host pode se
referir a um nome de domínio. Em muitos casos, o endereço SIP de um usuário será
o mesmo que o seu e-mail, porém outras opções (contendo número de porta, por
exemplo) poderão ser adotadas conforme o quadro 2.
Quadro 2 – Endereços SIP
[email protected]: 1234 URL SIP comum
Userdomain.com Sem a parte do usuário, a porta padrão será 5060
[email protected]:2345;transport=UDP Deseja ser contatado usando UDP
192.190.234.3:8001 Contate o servidor neste endereço IP
[email protected];maddr=239.255.255.1;ttl=32 Suprima o nome normal do host e use o mecanismo
de endereço de transporte use multicast para
239.255.255.1 com um TTL de 32
[email protected];user=phone Número de telefone global
0231759329;isub=10;[email protected]; Número de telefone local com endereço ISDN, espere
user=phone pelo tom de discagem, então disque 11 (pausa) 11
usando DTMF
[email protected]?priority=high& customercode=1234 Usando cabeçalhos de extensão proprietários para
controlar a prioridade em um sistema ACD...
[email protected]; METHOD=REGISTER URLs anteriores causariam um pedido SIP Invite, esta
inicia um registro junto ao registrar do usergroup:
reg.usergroup.com
3.3 SDP
Segundo Oliveira (2000), Session Description Protocol (SDP) especificado
no RFC 3264 descreve sessões multimídia para telefonia e aplicações de difusão
como radio ou TV via Internet.
Conforme Nazario (2003), o SDP leva informações sobre tipo do fluxo de
mídia, endereços, portas, tipo de conteúdo, em formato textual assim como o SIP.
Quando um pedido INVITE é enviado, os parâmetros SDP descrevem as
capacidades do originador da chamada. Na resposta ao pedido, os parâmetros SDP
são modificados trazendo as capacidades do destino da chamada.
36
A lista contendo todos os campos do protocolo SDP está descrita no RFC
3264. Os campos utilizados por este trabalho e que foram descritos na área de
dados SDP dos pedidos e respostas SIP são:
��v: traz a versão do protocolo;
��o: nome do usuário/proprietário/criador e identificador de sessão;
��c: informação sobe a conexão (c=<tipo de rede><tipo de
endereço><endereço de conexão>). Ex.: IN IP4 192.190.132.31;
��m: nome da mídia e endereço de transporte
(m=<mídia><porta><transporte><lista de formatos>. Ex.: m=áudio 49170
RTP/AVT 0;
��k: armazena a chave de criptografia de mídia.
3.4 SEGURANÇA SIP
A segurança da mídia que envolve o SIP é implementada através do SDP.
Este especifica a criptografia de mídia utilizando o parâmetro “k”, definido no RFC
2327, e que armazena o algoritmo de segurança em uso bem como a chave
(HERSENT, 2002).
Para que a chave de criptografia de mídia fique protegida, tanto os pedidos
quanto as respostas SDP deverão ser criptografadas.
Essas medidas de segurança não servem apenas para omitir a origem e o
destino das chamadas. Mas isso vai além, com o artifício da autenticação das
mensagens SIP, que auxilia na contabilidade e tarifação, chamadas enganosas
podem ser evitadas.
O SIP define duas maneiras para exercer um sistema de criptografia fim a
fim: um é baseado em uma chave secreta compartilhada (simétrica) entre o
remetente e o receptor e a outra em um mecanismo de chave pública. Neste o
remetente criptografa a mensagem usando a chave pública do receptor. A
criptografia pode ser executada pelo remetente do pedido ou por um proxy de
segurança intermediário.
37
Caso seja usada uma chave secreta conhecida por ambos (emissor e
receptor), o receptor da mensagem será capaz de decriptografar a mensagem
criptografada pelo remetente.
A figura 15 mostra um exemplo de um pedido SIP criptografado.
Figura 15 – Criptografia de um pedido
Nele a linha de pedido e os cabeçalhos não criptografados são enviados em
primeiro lugar, devendo incluir o campo de cabeçalho Encryption, o qual mostra o
método de criptografia e a versão que está sendo utilizada. A parte criptografada
começa após a linha vazia (HERSENT, 2002).
Se apenas o corpo da mensagem tiver de ser criptografado, uma linha vazia
extra deverá ser inserida no corpo antes da criptografia, com o propósito de evitar
que o receptor confunda os dados do corpo da mensagem com os cabeçalhos
criptografados.
Um servidor SIP ao receber um pedido criptografado do remetente,
indicando qual chave deve ser utilizada para criptografar a resposta, não deve
retornar de maneira limpa (não-criptografada) qualquer campo que foi criptografado
anteriormente.
38
4 CONCEITOS DE CRIPTOGRAFIA
4.1 INTRODUÇÃO
Atualmente milhões de pessoas utilizam as redes de comunicação como a
Internet e Telefonia para fazer compras, consultar extratos bancários ou realizar
aplicações financeiras. Para que estes serviços sejam oferecidos de forma segura,
tanto para o usuário do serviço quanto para o fornecedor, certas medidas de
segurança (como a criptografia) devem ser adotadas para que nenhum dos níveis
envolvidos na comunicação sofra algum tipo de dano ou prejuízo causado por um
invasor. Este pode agir de duas formas: interceptando e alterando a informação ou
apenas tendo acesso a ela sem modificá-la conforme ilustra a figura 16.
Figura 16 – Formas de ação do invasor
Segundo Tanenbaum (2003), os problemas de segurança das redes podem
ser divididos nos seguintes campos interligados:
��sigilo: manter desconhecido para todos, com exceção de um grupo
controlado de usuários, o conteúdo de um documento;
��autenticação: a identidade das entidades deve ser legítima e confirmada;
��integridade: o conteúdo original de um documento não pode sofrer
qualquer modificação ou falsificação;
39
��não-repúdio: o emissor da mensagem não poderá negar posteriormente
a autoria da mesma.
A solução de um ou parte desses problemas pode ser obtida de formas
variadas. Uma das utilizadas atualmente, e disseminada pelo uso de redes de
computadores, é a criptografia.
4.2 CRIPTOGRAFIA
A criptografia se constitui de um conjunto de métodos e técnicas destinadas
a proteger o conteúdo de uma informação, tanto em relação às modificações não
autorizadas quanto a alteração da sua origem, sendo uma das técnicas que
possibilitam o atendimento dos requisitos básicos de segurança.
De acordo como Bezerra (2004) ela consiste em modificar o texto original da
mensagem (texto simples), através de uma seqüência de instruções (algoritmo),
gerando uma mensagem que se torna ilegível (texto cifrado). O texto cifrado é
enviado ao destino que a partir de um procedimento reverso recupera a mensagem
original (figura 17).
Figura 17 – Modelo Ilustrativo de Criptografia
Nos sistemas criptográficos modernos o segredo não está contido no
algoritmo, e sim na chave. A chave é como uma senha, uma informação secreta que
precisa ser fornecida para cifrar e posteriormente decifrar a mensagem. Existem dois
tipos de sistemas criptográficos: sistemas de chaves simétricas e sistemas de
chaves assimétricas.
40
4.2.1 Sistemas de Chaves Simétricas
Nos sistemas de chaves simétricas a criptografia é baseada em algoritmos
que dependem de uma mesma chave secreta, que é usada tanto no processo de
cifrar quanto no de decifrar o texto cifrado. Somente emissor e receptor devem
conhecer a chave secreta, pois a segurança da comunicação depende desse
segredo. A convenção utilizada neste trabalho adotará que “C” significa rotina de
ciframento e a “D” de deciframento. Subscrito a elas está a chave necessária para
realizar a criptografia (Figura 18).
Figura 18 – Criptografia Simétrica
De acordo com Tanenbaum (2003), os algoritmos de chave simétrica mais
comuns são: o DES (American Data Encryption Standart) e o Rijndael (Daemen e
Rijmen).
Neste trabalho será adotado o algoritmo AES (Advanced Encryption
Standard) de Rijndael para criptografar os pacotes de áudio produzidos durante a
conversação depois de estabelecida a sessão de VoIP através das mensagens SIP .
O AES é um algoritmo que encripta blocos de 128, 192 e 256 bits, podendo usar
chaves de 128, 192 ou 256 bits. Assim como o DES, o Rijndael utiliza substituição e
permutações, e também emprega várias rodadas, cujo número depende do tamanho
da chave e do tamanho do bloco, sendo 10 para chaves de 128 bits com blocos de
128 bits (TANENBAUM, 2003). Conforme o site da WIKIPEDIA, até o presente
momento o Rijdael é imune a qualquer tipo de criptoanálise, sendo que o único
ataque possível é por força bruta. Ou seja, tentar quebrar o criptograma testando
todo o espaço de chaves possíveis do algoritmo.
41
4.2.2 Sistemas de Chaves Assimétricas
Nos sistemas de chaves assimétricas a criptografia é baseada em algoritmos
que utilizam duas chaves diferentes, de forma que o texto cifrado pela chave 1
(chave pública) do par só poderá ser decifrado pela chave 2 (chave privada) do
mesmo par. A chave pública pode ser obtida pelo público em geral, enquanto que a
chave privada só poderá ser de conhecimento do seu titular.
Para exemplificar na figura 19 o emissor “B” processa seu documento “M”
com a chave pública “k” do receptor, que é conhecida. O texto cifrado “T” só poderá
ser decifrado pelo receptor “B”, uma vez que somente ele possui a chave privada “s”
relacionada à chave pública “k” que orientou a criptografia do documento “M”. Desta
forma cada usuário possui duas chaves uma pública e a outra privada.
Figura 19 – Criptografia Assimétrica
42
5 DESENVOLVIMENTO DO TRABALHO
5.1 INTRODUÇÃO
No Brasil algumas empresas já oferecem o serviço de VoIP aos seus
clientes como, por exemplo, GVT, IPPhone Brasil, Nikotel, Redevox, Simphonia,
Sun-isp, VOIPMAX e VoxFone. Porém, é importante ressaltar que na convergência
das redes de voz com as redes de dados baseadas em TCP/IP, há também a
convergência de vulnerabilidades inerentes as duas tecnologias. De acordo com
Galvão (2003), no VoIP o conteúdo das conversas telefônicas está trafegando na
rede de dados, encapsulado em pacotes IP, e a captura de pacotes de dados em
redes IP através das técnicas de “Sniffing” é relativamente trivial. Já existem na
Internet ferramentas como VOMIT (Voice Over Misconfigured Internet Telephones)
capaz de capturar pacotes de uma conversa telefônica, remontá-los e convertê-los
em um formato comum de áudio (*.wav).
Desta forma, este protótipo de Telefonia IP foi desenvolvido para atender
essas questões visando o cumprimento dos objetivos inicialmente traçados, com o
intuito de fornecer uma interface amigável ao usuário que queira estabelecer
chamadas telefônicas com segurança e baixo custo comparado as tarifas telefônicas
convencionais do STFC.
5.2 REQUISISTOS DO PROTÓTIPO
Para atender as necessidades citadas na seção anterior e viabilizar a
comunicação entre dois usuários da Telefonia IP o presente trabalho terá as
seguintes funcionalidades: criar uma sessão de VoIP, através da negociação de
mensagens SIP, capturar e comprimir a voz, criptografar a voz comprimida e enviá-la
em pacotes RTP através do protocolo IP. No usuário de destino, decriptografar a voz
comprimida, descomprimi-la e reproduzi-la na placa de som.
O protótipo do sistema de Telefonia IP desenvolvido tem como principal
embasamento o padrão SIP do IETF e o algoritmo de criptografia AES para
implementar um canal seguro entre os seus usuários. Estes encontram-se em uma
mesma LAN e são identificados através de endereços IP (fixo para cada usuário).
43
5.3 ESPECIFICAÇÃO
Conforme o item 3.4 relacionado à segurança SIP, a criptografia de mídia é
especificada pelo SDP. Desta forma, a ferramenta desenvolvida utiliza o campo “k”
do referido protocolo (que contém a chave secreta) para criptografar os pacotes de
voz produzidos durante a conversação entre dois usuários do sistema depois de
estabelecida a sessão de VoIP através das mensagens SIP.
O protótipo possui duas chaves secretas de 128 bits baseadas no algoritmo
de chave simétrica AES de Rijmaen. A primeira chave secreta “k” é a chave
escolhida pelo usuário originador da chamada. Ela tem a função de criptografar os
fragmentos de voz oriundos do processo de compressão, que posteriormente serão
transmitidos através do RTP. O diagrama de blocos da figura 20 ilustra este
processo:
Figura 20 – Criptografia dos Pacotes de Voz
44
A segunda chave secreta “q” é uma chave interna pré-definida no protótipo
de Telefonia IP que irá criptografar a chave de sessão “k” escolhida pelo originador
da chamada. Depois de criptografada a chave “k” será enviada através de um
pedido de “INVITE” ao receptor conforme o modelo de mensagem SIP construída
neste protótipo e ilustrada na figura 21.
Figura 21 – Mensagem SIP
5.3.1 Diagrama de Caso de Uso
Segundo Araújo (2005) o diagrama de caso de uso é utilizado para
descrever o comportamento do sistema em várias situações que podem ocorrer
durante sua operação.
A figura 22 ilustra o diagrama de caso de uso do protótipo e o quadro 3
descreve as suas possíveis situações, indicando o nome do caso de uso, o
respectivo ator e a descrição de cada um deles.
45
Figura 22 – Diagrama de Caso de Uso
Quadro 3 – Casos de uso
Caso de Uso Ator Descrição Habilitar Criptografia Usuário O usuário insere a chave secreta
que irá criptografar o pacotes de áudio transmitidos via RTP durante a sessão de VoIP.
Efetuar Ligação Usuário Depois de escolher a chave de sessão o usuário envia uma mensagem de pedido para um usuário destino (previamente escolhido) indicando que deseja estabelecer a conversação através de uma conexão segura.
Criar Sessão VoIP Efetuar Ligação A sessão é criada após a troca, entre os usuários participantes, de mensagens SIP conforme ilustra a figura 15 citada anteriormente.
46
Depois do originador da chamada receber o “200 OK” do receptor e enviar a resposta “ACK” para finalizar a negociação a sessão está praticamente estabelecida.
Enviar Áudio Criptografado Efetuar Ligação Após o estabelecimento da sessão VoIP o usuário está apto a enviar áudio capturado, comprimido, criptografado e enviado via RTP.
Receber Áudio Criptografado
Efetuar Ligação Após o estabelecimento da sessão VoIP o usuário está apto a receber áudio capturado, comprimido, criptografado e enviado via RTP.
Desligar Efetuar ligação Após o estabelecimento da sessão VoIP o tanto o originador da chamada quanto o receptor podem enviar um pedido “BYE” para finalizar a sessão.
Cancelar Ligação Efetuar ligação Antes do estabelecimento da sessão VoIP o originador da chamada pode enviar o pedido “CANCEL” ao receptor antes de receber a resposta do pedido de “INVITE” enviado anteriormente.
Desabilitar Criptografia Efetuar ligação Após o estabelecimento da sessão VoIP o usuário pode desabilitar a opção de criptografia dos pacotes de voz enviados via RTP.
Decriptografar Áudio e Reproduzi-lo
Receber Áudio Criptografado
O algoritmo AES decriptografa os pacotes de áudio recebidos via RTP através da chave secreta de sessão previamente definida e os reproduz via biblioteca utilizada.
Enviar MensagemSIP Criar Sessão VoIP
O envio de mensagem ocorre de acordo com a mensagem recebida, ou seja, as mensagens podem ser enviadas como um pedido ou como uma resposta a este.
5.3.2 Estrutura de Camadas do Protótipo
O protótipo desenvolvido pode ser visualizado em uma estrutura de
camadas hierárquicas, na qual as camadas inferiores fornecem serviços as camadas
superiores. A figura 23 ilustra os serviços fornecidos e transmitem a forma como foi
tratada e implementada a ferramenta.
47
Figura 23 – Estrutura de Camadas do Protótipo
5.3.3 Diagrama de Classes
Para Furlan, apud Nazario (2003, p.35) “o diagrama de classes é usado para
mostrar a estrutura lógica mostrando elementos tais como: classes, tipos atributos e
métodos”. A figura 24 mostra o diagrama de classes de controle e gerenciamento do
protótipo.
48
Figura 24 – Diagrama de Classes de Controle e Gerenciamento
Abaixo são descritos os papéis desempenhados por cada uma das classes
do diagrama de classes de controle e gerenciamento:
��Classe UDPClass: implementa o recurso de enviar e receber pacotes
UDP pela rede;
49
��Classe SIPClass: implementa o tratamento das mensagens SIP. Utiliza a
classe “UDPClass” para enviar e receber as mensagens sob forma de
pacotes UDP;
��Classe MngrClass: implementa a camada de gerenciamento. Essa classe
possui métodos para iniciar e terminar uma conversação sob VoIP. Ela
utiliza as classes “SIPClass” para controlar a sessão e a classe
“JVOIPSession” para prover a sessão de comunicação;
��Classe CTccDlg: classe da janela de diálogo que faz a interface com o
usuário. Implementa os recursos da camada de aplicação;
��Classe StrListClass: implementa recurso de manter uma lista de strings,
possibilitando que a classe “MngrClass” mantenha uma lista de contatos.
A camada de segurança foi implementada na classe responsável pela
compressão e descompressão da voz digitalizada. Logo após os procedimentos do
método de compressão da classe citada, a função de criptografia foi escrita, cifrando
os dados provenientes do resultado do método em questão.
Por outro lado, a função de decriptografia foi disposta no método de
descompressão da referida classe, decifrando os dados cifrados para que possam
ser descomprimidos.
5.4 IMPLEMENTAÇÃO
Os itens a seguir irão descrever as ferramentas de apoio utilizadas para o
desenvolvimento do protótipo bem como o seu funcionamento demonstrado através
das suas principais telas devidamente comentadas.
Para a implementação deste protótipo foi utilizada a linguagem de
programação C++ através do Visual C++ 6, baseando-se na biblioteca JVOIPLIB
versão 1.3.0 escrita por Liesenborgs (2004). O algoritmo de criptografia, necessário
à implementação de um canal seguro durante a sessão de VoIP estabelecida
através de JVOIPLIB, foi criado baseando-se no padrão “AES” de Rijmaen.
50
5.4.1 Visual C++ 6
De acordo com Hubbard (2003), o C++ é uma linguagem de programação
criada por Bjarne Stroustrup no início da década que 1980 e atualmente é uma das
linguagens mais populares para programação orientada a objetos.
Segundo Holzner (1995), o Visual C++ é um pacote imenso que oferece
muitos recursos com sua riqueza de editores, ferramentas, repositórios, bibliotecas
de classe, técnicas de depuração e muito mais. A figura 25 mostra o ambiente de
trabalho do Visual C++ 6.
Figura 25 – Ambiente de Trabalho do Visual C++ 6
5.4.2 JVOIPLIB
O termo JVOIPLIB significa Jori’s VoIP Library. Esta biblioteca foi escrita por
Jori Liesenborgs e fornece recursos para implementação de aplicações de VoIP
51
através de uma interface simples e extensível para criação e gerenciamento de
sessões VoIP (LIESENBORGS, 2004).
Ela possui basicamente a função de criar uma sessão de VoIP, transmitir
voz e destruir a sessão VoIP. Suas sessões altamente configuráveis permitem ainda
que atributos previamente escolhidos pelo usuário como a taxa de amostragem,
intervalo da amostra, tipo de compressão e etc, possam ser alterados durante a
sessão já estabelecida.
De acordo com Liesenborgs (2004) os seguintes módulos descritos contêm
os componentes a serem utilizados em uma aplicação VoIP:
��leitura de som na entrada e saída da placa de som;
��compressão de áudio nos padrões DPCM, Mu-law, GSM e LPC 5.4k;
��transmissão de dados via RTP;
��um voice mixer (junta sinais enviados pela conexão VoIP criada);
��método de localização.
Para adicionar VoIP a uma aplicação primeiramente deve-se criar uma
sessão com os parâmetros desejados (como a taxa de amostragem). Em seguida
adiciona-se destino a essa sessão. E quando não for mais necessária a VoIP, deve-
se simplesmente destruir a sessão. A seguir serão descritas de forma sucinta as
classes e métodos utilizados para realizar esse processo.
A sessão de VoIP é representada pela classe JVoIPSession. Cria-se a
sessão através da chamada da função Create utilizando parâmetros do tipo
JVoIPSessionParams, que contém parâmetros para sessão. O RTP é utilizado
através da classe JVoIPComponentParams. A figura 26 mostra o diagrama que
exemplifica as três classes citadas.
52
Figura 26 – Classes de Criação da Sessão
Depois que a sessão estiver ativa, torna-se necessário definir para onde os
dados VoIP devem ser enviados. As funções membro AddDestination e
DeleteDestination da classe JVoIPSession são responsáveis por essa definição
podendo especificar tanto destinos unicast como multicast. A função
DeleteDestination é utilizada na finalização da sessão.
Após o estabelecimento da sessão, a classe VoiceCall, em conjunto com
outras subclasses, fica responsável pelo tratamento e transmissão da voz sobre o
protocolo IP.
Figura 27 – Classes Responsáveis pelo Tratamento da Voz
53
Depois de terminada a conversação, para destruir a sessão é chamado o
método Destroy da classe JVoIPSession.
A biblioteca JVOIPLIB utiliza o serviço de outras duas bibliotecas para prover
a sessão VoIP. Uma delas é a JRTPLIB que dá suporte ao RTP no envio e
recebimento de pacotes. A outra JThread, como o próprio nome supõe, facilita o uso
de threads em diferentes plataformas.
Quadro 4 – JThread
5.4.3 Protótipo
Neste item serão demonstradas as principais telas que compõem o protótipo
e breve explanação sobre cada uma delas.
Antes que o usuário do Sistema de Telefonia IP Criptografado possa efetuar
uma ligação, ele deve editar a sua lista de contatos inserindo o nome e o endereço
IP do destinatário no arquivo “Contatos.txt”.
Figura 28 – Arquivo Contatos.txt
54
Após essa primeira etapa o usuário poderá inicializar o protótipo executando
o programa Tcc.exe, onde será lhe apresentada a tela da figura 29.
Figura 29 – Tela Inicial
A tela inicial representa a interface que o usuário possui para realizar suas
chamadas. A partir dela o usuário poderá:
��escolher um usuário de destino para o qual ele deseja ligar na “Lista de
Contatos” que é carregada na inicialização do protótipo;
��escrever um título sobre o assunto a ser tratado com o receptor;
��habilitar a criptografia dos pacotes de voz que serão transmitidos durante
a conversação através da inserção da chave secreta no campo “Chave
de Sessão”;
��desabilitar depois de criada a sessão VoIP;
��limpar o Log de monitoramento das mensagens SIP trocadas durante o
estabelecimento de sessão;
��fechar a aplicação.
55
Depois de escolher o usuário de destino e preencher os campos “Assunto” e
“Chave de Sessão”, o originador estará apto a realizar uma chamada pressionando
botão “Ligar” com o mouse para realizar uma chamada com o usuário de destino
escolhido através uma conexão segura conforme ilustra a figura 30.
Figura 30 – Preenchimento de Campos
Após pressionar o botão “Ligar” o originador envia um pedido de INVITE
para estabelecer uma sessão VoIP criptografada pela chave secreta escolhida
anteriormente (figura 31).
56
Figura 31 – Pedido INVITE
“Gerson” que neste caso é o receptor da chamada recebe o pedido de
INIVITE de “Humberto” conforme ilustra a figura 32.
Figura 32 – Recepção do Pedido INVITE
Caso Gerson aceite o convite, ele enviará a resposta “200” OK relacionada
ao pedido de “INVITE” de Humberto. Este por sua vez, envia o pedido “ACK” para
57
confirmar o recebimento da resposta “200 OK” enviada por Gerson e a sessão VoIP
é então estabelecida como mostra a figura 33.
Figura 33 – Estabelecimento de Sessão VoIP
Depois de estabelecida a sessão VoIP, Gerson fica sabendo da chave
secreta utilizada por Humberto para criptografar a sessão. O botão “Desabilitar
Criptografia” aparece na tela fornecendo esta opção tanto para Humberto quanto
para Gerson. Caso um dos dois decida desabilitar a criptografia e o outro continue
aplicando o algoritmo de segurança, não haverá um consenso entre os dois. Pois se
Humberto tiver desabilitado a criptografia, quando os pacotes de voz criptografados
chegarem, ele não aplicará a chave para decriptografá-los. Desta forma ele não vai
entender nada do que Gerson está falando. Gerson também não vai entender o que
Humberto diz porque Humberto não está usando mais a chave secreta para fazer a
criptografia. A comunicação volta ao normal quando ambos estiverem na mesma
condição, criptografia habilitada ou desabilitada.
Neste protótipo pode haver duas maneiras para que a sessão seja
finalizada. Uma através do envio de um pedido “BYE” como ilustra a figura 34.
58
Figura 34 – Finalização de Sessão por “BYE”
E a outra através de um pedido de “CANCEL” enviado pelo originador da
chamada antes de receber a resposta do seu pedido de “INVITE” enviado
anteriormente (figura 35).
Figura 35 – Finalização de Sessão por “CANCEL”
59
6 CONCLUSÃO
O presente trabalho procurou realizar um estudo detalhado do ambiente de
Telefonia IP, apresentando seus principais protocolos e padrões utilizados, suas
vantagens e desvantagens, e de como essa tecnologia poderia afetar o nosso
cotidiano.
Durante o desenvolvimento da fundamentação teórica foi vista a importância
de cada um dos protocolos necessários para sessão de VoIP, destacando-se o RTP
como sendo o protocolo crucial na implementação de aplicações que exijam
respostas em tempo real. Como é o caso do protótipo que foi desenvolvido.
O padrão SIP foi escolhido neste trabalho por causa da sua simplicidade na
criação de sessão em relação aos demais padrões. Isso pôde ser observado na
comparação feita com o H.323 que utiliza um número maior de protocolos em
relação ao SIP.
A biblioteca JVOIPLIB em conjunto com JRTPLIB e Jthread desenvolvida
por Liesenborgs forneceu os recursos necessários para a implementação do
protótipo dentro dos padrões pré-definidos.
O tipo de compressão DPCM e o algoritmo de criptografia AES adotados no
protótipo forneceram um desempenho satisfatório, pois apesar de haver um
pequeno atraso no fluxo de mídia, ele é quase imperceptível, durante as
conversações realizadas entre os usuários do sistema. Estes possuem uma interface
amigável para a criação e destruição de sessões VoIP criptografadas.
Na fase de desenvolvimento do trabalho os conceitos aprendidos durante a
fundamentação teórica foram de grande valia para dimensionar de forma correta a
solução do problema. Para aplicar o algoritmo de criptografia observou-se que seria
inviável aplicá-lo antes do processo de compressão. Isto porque a compressão de
sinais utiliza técnicas de processamento que retiram informações redundantes,
imprevisíveis e inúteis. Desta forma se a compressão retirar informações de dados
criptografados na origem, não será possível decriptografá-los no destino. A partir
deste princípio o algoritmo de criptografia foi aplicado após o processo de
compressão DPCM.
A forma como foi aplicada a criptografia de chave simétrica, torna-se
vulnerável por não atender o quesito de autenticação do usuário. Pois, caso um
intruso do sistema possua o software com a mesma chave interna dos outros dois
60
usuários que estão se comunicando e aplique a técnica de sniffing, este intruso vai
poder conhecer a chave de sessão e conseqüentemente a voz que está sendo
trafegada.
Apesar da aplicação desenvolvida possuir essa vulnerabilidade, o principal
objetivo de criar um sistema de Telefonia IP criptografado baseado no padrão SIP foi
atendido, já que o fluxo RTP de dados é criptografado e decriptografado para a
reprodução do áudio no seu receptor depois de estabelecida a sessão de VoIP
através das mensagens SIP.
6.1 TRABALHOS FUTUROS
Para dar continuidade ao desenvolvimento de um sistema de Telefonia IP
completo e seguro, baseado no padrão SIP, sugere-se:
��a implementação da autenticação por HTTP, SSL ou PGP para corrigir a
vulnerabilidade do protótipo desenvolvido, apontada na conclusão do
trabalho;
��a implementação desta tecnologia para uso em multicast para sistemas
de áudio-conferência.
61
7 REFERÊNCIAS BIBLIOGRÁFICAS
ARAÚJO, Lúcia Goretti Gonçalves de. Apostila de UML. Disponível em: <
http://www.sdsi.uri.br/geoob/>. Acesso em: 15 de mai. 2005.
BEZERRA, Fábio Fernandes. Ferramenta de análise modal de protocolos de
segurança para redes sem fio na Universidade Regional de Blumenau.
Blumenau, 2004. 69f. Trabalho de Conclusão de Curso (Engenharia de
Telecomunicações) – Centro de Ciências Tecnológicas, Universidade Regional de
Blumenau.
CANSADO, Jascinto Carlos Ascencio. Conectividade entre telecomunicações e
informática. Disponível em:
<http://www.geocities.com/jacintocansado/usp/usp_arquivos/Monografia_PCS5707.p
df>. Acesso em: 25 ago. 2004.
CRN. A hora e a vez da voz sobre IP. Brasil, [2002]. Disponível em:
<http://www.crn.com.br/recapa/artigo.asp?id=23059>. Acesso em: 24 jul. 2004.
GALVÃO, Márcio; ZATTAR, Alexandre. Aspectos de segurança em redes de voz
sobre IP, [2003]. Disponível em: < http://www.modulo.com.br/index.jsp>. Acesso em:
15 ago. 2004.
GUIMARÃES, José Liesse Bollos. Voz sobre IP. Brasil, [1999]. Disponível em:
<http://www.gta.ufrj.br/grad/98_2/liesse/relat.html>. Acesso em: 16 de ago. 2004.
HERSENT, Oliver; GURGLE, David; PETIT, Jean-Pierre. Telefonia IP: comunicação
multimídia baseada em pacotes. São Paulo: Addison Wesley, 2002. 451p.
HOLZNER, Steven. Programando Visual C++ 6: em tempo recorde. São Paulo:
Makron Books, 1995. 608 p.
HUBBARD, John R. Programação em C++: teorias e problemas de, 2. ed. Porto
Alegre: Editora Bookman, 2003. 393 p.
62
INTERNET ENGINEERING TASK FORCE. RFC 2327: Session Description Protocol.
New York, 2002. 16p.
INTERNET ENGINEERING TASK FORCE. RFC 3261: Session Internet Protocol.
New York, 2002. 269p.
INTERNET ENGINEERING TASK FORCE. RFC 3264: Session Description Protocol.
New York, 2002. 16p.
LIESENBORGS, Jori. JVOIPLIB, [2004]. Disponível em:
<http://research.edm.luc.ac.be/jori/jvoiplib/jvoiplib.html>. Acesso em: 20 nov. 2004.
LOUREIRO, Hélio; SAVARIS, Nixon. Protocolos Internet para Comunicação
Multimídia, Florianópolis, [1999]. Disponível em:
<http://www.das.ufsc.br/redes/redes99/helio/protocolos_multimidia/>. Acesso em: 15
ago. 2004.
MEDEIROS, Michel Souza. Protocolos de Suporte a Multimídia. Disponível em:
<http://www.gta.ufrj.br/grad/03_1/rtp/index.html>. Acesso em: 10 set. 2004.
NAZARIO, Débora Luciani. Protótipo de um sistema de telefonia IP para LANs
baseado no padrão SIP na Universidade Regional de Blumenau. Blumenau,
2003. 47 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da
Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de
Blumenau.
OLIVEIRA, Sérgio. Telefonia IP para ambientes móveis e usáveis, [2000] .
Disponível em: <http://www.dcc.ufmg.br/~sergiool/diss.pdf>. Acesso em: 16 de ago.
2004.
RNP. Qualidade de Serviço na Internet. Brasil, [1999]. Disponível em:
<http://www.rnp.br/newsgen/9911/qos.html>. Acesso em: 20 ago. 2004.
63
SOUSA, José Márcio de. Protótipo de um sistema VoIP (Voz sobre IP). Blumenau,
2001. 53f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da
Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de
Blumenau.
TANENBAUM, Andrew S. Redes de Computadores, 4. ed. São Paulo: Editora
Campus, 2003. 968 p.
TUTORIAL sobre TCP/IP. Disponível em:
<http://geocities.yahoo.com.br/conexaopcpc/artigos/tutorialtcpip.htm>. Acesso em:
10 ago. 2004.
