Línguas
Páginas
Legal
Qu
M
Fa
ualidad
Mestrado Inte
aculdade de E
de de Se
Hél
Dissertaegrado em En
Ma
OrienCo-orie
Engenharia da
erviço
lder Barro
ção realizadngenharia Elejor Telecom
ntador: Profentador: Eng
Junho de
Universidade
em ch
oso Silva
a no âmbitoectrotécnicaunicações
. José Ruela g. Filipe Sous
2008
e do Porto
amada
do a e de Comp
sa
as VoIP
utadores
ii
©Hélder Barroso da Silva, 2008
iii
iv
v
Resumo
Esta dissertação tem como tema abrangente a qualidade de serviço, que no caso em
estudo se refere à qualidade em chamadas VoIP.
Pretende-se implementar/integrar uma funcionalidade que permita prever a qualidade de
chamadas para uma dada lista de contactos. Essa qualidade está definida por três níveis,
Bom, Aceitável e Mau.
Inicialmente, foi feito um levantamento de ferramentas para permitir a selecção de forma
consciente das mais adequadas para utilizar.
Foi implementada uma arquitectura VoIP para permitir o estabelecimento de chamadas
de forma a ser utilizada como cenário de teste. Os testes foram realizados numa rede sem
fios, tendo como principio a manipulação do fluxo de tráfego para analisar o comportamento
da rede a partir dos resultados obtidos pela aplicação realizada. Este teste permitiu a
compreensão da utilidade da ferramenta implementada, do comportamento da rede e a
forma como variam as métricas. Foi possível constatar que a rede tinha um comportamento
aceitável até ao instante em que o tráfego na rede se aproxima do ponto de saturação,
ficando com características bastante degradadas. Observou-se também que as métricas
utilizadas para analisar uma rede não variam da mesma forma e algumas são melhores
caracterizadoras do que outras.
Esta implementação tem então uma aplicação prática, que pode evitar uma má utilização
do serviço de VoIP ao informar os utilizadores da qualidade de serviço esperada.
Por fim, foram sugeridos melhoramentos e novas funcionalidades para serem efectuados
como trabalho futuro.
vi
vii
Abstract
This dissertation addresses the problem of network quality of service, and in particular in
the case under study the quality of VoIP calls.
The goal is to implement / integrate a feature that allows predicting the quality of voice
calls for a list of contacts. This quality is defined by three levels, Good, Acceptable and Bad.
Initially, an inventory of tools was elaborated to allow the selection of the most
appropriate to use.
A VoIP architecture was defined to enable the establishment of calls to be used in
scenario created for testing. Tests were performed in a wireless network, and the objective is
the manipulation of traffic flows to analyze the behavior of the network from results
achieved by the application. This test allowed understanding of the usefulness of the
implemented tool, the behavior of network and how the metrics vary. It was possible to see
that the network had an acceptable behavior until traffic approaches the point of saturation,
where degradation becomes noticeable. It was also observed that the metrics used to
characterize the network behaviour do not vary in the same way, and some are better than
others for that purpose.
This implementation then has a practical application that can prevent improper use of the
VoIP service because users are informed of the expected quality of service.
Finally, improvements and addition of new features were suggested as future work.
viii
ix
Agradecimentos
Esta dissertação é o culminar de todo um esforço, empenho e dedicação de acordo com o
grande objectivo académico que representa. Durante a realização desta tese recebi a ajuda
de algumas pessoas que foram extremamente importantes.
Estou imensamente agradecido aos meus orientadores, Prof. José Ruela e Eng. Filipe
Sousa por todo o empenho, disponibilidade e bons concelhos que sempre contribuíram.
Agradeço a todos os meus companheiros que me ajudaram a percorrer este percurso
académico.
Tenho que agradecer também, a toda a minha família que sempre me incentivou,
compreendeu e apoiou nos momentos mais delicados.
x
xi
Índice
1 Introdução ................................................................................................. 1
1.1 Objectivos ........................................................................................... 1
1.2 Enquadramento ..................................................................................... 2
1.3 Caracterização do Problema ..................................................................... 2
1.4 Estrutura............................................................................................. 3
2 Estado da Arte ............................................................................................ 5
2.1 Conceitos abordados ............................................................................... 5
2.1.1 Protocolo IP ................................................................................ 5
2.1.2 P2P (Peer-to-Peer) ........................................................................ 7
2.1.2.1 Arquitectura tradicional dos serviços na Internet ......................... 7
2.1.2.2 Arquitectura de uma rede Peer-to-Peer .................................... 8
2.1.3 QoS .......................................................................................... 9
2.1.3.1 Introdução QoS .................................................................. 9
2.1.3.2 Modelos de QoS ................................................................. 9
2.1.3.2.1 Modelo IntServ ....................................................... 9
2.1.3.2.2 Modelo DiffServ .................................................... 11
2.1.3.3 Medidas de Qualidade de Serviço para redes IP .......................... 12
2.1.3.3.1 Medidas Passivas ................................................... 12
2.1.3.3.2 Medidas Activas .................................................... 13
2.1.3 VoIP ........................................................................................ 14
2.1.3.1 Introdução VoIP ................................................................ 14
2.1.3.2 Tipos de ligações VoIP ........................................................ 15
xii
2.1.3.3 Alguns problemas VoIP ........................................................ 16
2.1.3.4 Algumas soluções VoIP ........................................................ 17
2.1.3.5 Funcionamento do VoIP ....................................................... 17
2.1.4 Protocolo de sinalização H323 ......................................................... 19
2.1.5 Protocolo de sinalização SIP ............................................................ 22
2.1.5.1 SDP (Session Dresciptor Protocol) ........................................... 23
2.1.5.2 Cabeçalho SIP .................................................................. 24
2.1.5.3 Sessão SIP sem Proxy .......................................................... 26
2.1.5.4 Sessão SIP com Proxy .......................................................... 27
2.2 Trabalhos relacionados ........................................................................... 28
3 Ferramentas .............................................................................................. 37
3.1 Introdução .......................................................................................... 37
3.2 Ferramentas de medidas Activas ............................................................... 37
3.3 Ferramentas de medidas Passivas .............................................................. 42
3.4 Outras ferramentas ............................................................................... 42
3.5 Componentes VoIP ................................................................................ 43
3.5.1 Servidores VoIP ........................................................................... 44
3.5.1.1 Asterisk .......................................................................... 45
3.5.1.2 OpenSER ......................................................................... 47
3.5.1.3 Asterisk vs OpenSER ........................................................... 49
3.5.2 Cliente VoIP ............................................................................... 49
3.5.3 Ekiga ....................................................................................... 50
4 Definição de requisitos e especificação.............................................................. 51
4.1- Introdução ......................................................................................... 51
4.2- Cenário de comunicação VoIP .................................................................. 51
4.3- Requisitos da aplicação de medidas .......................................................... 53
4.4- Especificação da arquitectura ................................................................. 54
5 Desenvolvimento e integração ........................................................................ 57
5.1- Introdução ......................................................................................... 57
5.2- Fluxograma demonstrativo do funcionamento .............................................. 57
5.3- Principais funções implementadas ............................................................ 60
xiii
5.4- Integração dos componentes ................................................................... 64
5.4.1- Asterisk ................................................................................... 64
5.4.2- Ekiga ...................................................................................... 66
5.4.3- X-lite ...................................................................................... 68
5.4.4- MGEN ...................................................................................... 69
5.4.5- NTP ........................................................................................ 69
6 Testes/Resultados ....................................................................................... 71
6.1- Introdução ......................................................................................... 71
6.2- Cenários de teste ................................................................................ 71
6.3- Testes efectuados ................................................................................ 73
6.3- Análise de resultados ............................................................................ 78
7 Conclusão/Trabalho futuro ............................................................................ 79
7.1- Conclusão .......................................................................................... 79
7.2 - Trabalho Futuro ................................................................................. 80
Anexo A ...................................................................................................... 81
Métodos e tipos de respostas SIP .................................................................... 81
Referências ................................................................................................. 85
xiv
xv
Lista de figuras
Figura 2.1 - Arquitectura TCP/IP [2]. ..................................................................... 6
Figura 2.2 - Formato do Pacote IP[2]. .................................................................... 6
Figura 2.3 - Arquitectura Tradicional dos Serviços na Internet [3]. ................................. 8
Figura 2.4 - Arquitectura de uma rede Peer-to-Peer [3]. ............................................. 8
Figura 2.5 - Reserva de Recursos [2]. ................................................................... 10
Figura 2.6 - Tráfego da Rede com medições Passivas [4]. ........................................... 12
Figura 2.7 - Tráfego na rede com medições Activas [4]. ............................................. 13
Figura 2.8 - VoIP Ligação PC-PC [6]. ..................................................................... 15
Figura 2.9 - VoIP Ligação PC-Telefone [6]. ............................................................. 16
Figura 2.10 - VoIP Ligação Telefone-Telefone [6]. .................................................... 16
Figura 2.11 - Protocolos de sinalização para VoIP [8]................................................. 17
Figura 2.12 - Formato de um pacote RTP (dados) [2]. ................................................ 18
Figura 2.13 - Conversão de um sinal analógico para digital ......................................... 18
Figura 2.14 - Pilha de protocolos do padrão H323 [9]. ............................................... 20
Figura 2.15 - Modelo H323 ................................................................................ 21
Figura 2.16 - Chamada entre um PC e um telefone convencional [10]. ........................... 22
Figura 2.17 - Pilha de protocolos SIP .................................................................... 22
Figura 2.18 - Mensagem SDP [14]. ....................................................................... 23
Figura 2.19 - Métodos de estabelecimento de uma sessão SIP ...................................... 25
Figura 2.20 - Sessão SIP sem Servidor Proxy [17]. ..................................................... 26
Figura 2.21 - Sessão SIP com um Servidor Proxy [17]. ................................................ 27
Figura 2.22 - H323 Beacon níveis de qualidade [19]. ................................................. 29
Figura 2.23 - H323 Beacon opções [19]. ................................................................ 30
Figura 2.24 - Relação entre a predição e a real perda de pacotes [20]. .......................... 31
Figura 2.25 - Diferenças de QoS 1999 e 2002 [21]. .................................................... 31
Figura 2.26 - Cenário de teste [79]. ..................................................................... 33
Figura 2.27 - Classificação MOS [79]. .................................................................... 33
Figura 2.28 - Classificação MOS dos codecs [79]. ...................................................... 34
Figura 2.29 - Relação MOS com % perdas [79]. ......................................................... 34
xvi
Figura 2.30 - Relação MOS e % perda, variando o tamanho dos pacotes [79]. .................... 35
Figura 2.31 - Relação entre % perda com jitter [79]. ................................................. 35
Figura 3.1 - Pathchirp [23]. ............................................................................... 38
Figura 3.2 - STAB [24]. ..................................................................................... 38
Figura 3.3 - Exemplo do funcionamento do MGEN .................................................... 40
Figura 3.4 - MRTG [32]. .................................................................................... 41
Figura 3.5 - Sistema recurso ao velho modelo de PABX/Softswitch [65]. ......................... 46
Figura 3.6 - Arquitectura com recurso ao Asterisk [65]. ............................................. 47
Figura 3.7 - Ficheiro de configuração do OpenSER .................................................... 48
Figura 4.1 - Chamada efectuada entre dois softphones Ekiga ...................................... 52
Figura 4.2 - Interligação entre dois Ekigas durante um teste ....................................... 54
Figura 4.3 - Interligação do Ekiga com a nova funcionalidade implementada .................... 55
Figura 5.1 - Fluxograma demonstrativo do funcionamento do trabalho implementado ......... 58
Figura 5.2 - Exemplo de configuração efectuada no Ekiga. .......................................... 67
Figura 5.3 - Exemplo de configuração do X-lite ....................................................... 68
Figura 6.1 - Cenário de teste apenas com um dos clientes a suportar a previsão da qualidade
de chamada .................................................................................................. 72
Figura 6.2 - Cenário de teste com ambos os clientes a suportarem a previsão da qualidade de
chamada ..................................................................................................... 73
Figura 6.3 - Variação do jitter na rede dependendo do tráfego injectado ........................ 76
Figura 6.4 - Variação das perdas na rede mediante o tráfego injectado .......................... 76
Figura 6.5 - Variação do atraso na rede mediante o tráfego injectado ............................ 77
Figura 6.6 - Relação entre tráfego na rede e nível de QoS .......................................... 77
xvii
Lista de tabelas
Tabela 2.1 - Modelo IntServ. .............................................................................. 10
Tabela 2.2 - Modelo DiffServ .............................................................................. 11
Tabela 2.3 - Ferramentas para efectuar medições de parâmetros QoS ............................ 14
Tabela 2.4- Comparação entre medidas Activas e Passivas .......................................... 14
Tabela 2.5 - Componentes do SIP ........................................................................ 24
Tabela 2.6 - SIP vs H323 ................................................................................... 27
Tabela 3.1 - Servidores VoIP .............................................................................. 43
Tabela 3.2 - Bibliotecas VoIP. ............................................................................ 44
Tabela 3.3 - Clientes VoIP ................................................................................. 44
Tabela 6.1 - Sem tráfego adicional na rede ............................................................ 74
Tabela 6.2 - Com tráfego adicional de 700 pacotes/s com 1024 bytes ............................ 74
Tabela 6.3 - Com tráfego adicional de 900 pacotes/s com 1024 bytes ............................ 75
Tabela 6.4 - Com tráfego adicional de 1100 pacotes/s com 1024 bytes. .......................... 75
Tabela 6.5 - Qualidade das chamadas VoIP para diferentes valores de tráfego na rede ........ 75
xviii
xix
Lista de Abreviaturas
ACK Acknowledgment
ARPANET Advanced Research Projects Agency Network
EF Expedite Forward
FDDI Fiber Distributed Data Interface
HTTP HyperText Transfer Protocol
IANA Internet Assigned Numbers Authority
IAX Inter-Asterisk eXchange
IETF Internet Engineering Task Force
IP Internet Protocol
ISP Internet Service Provider
ITU-T International Telecommunication Union
MCU Multipoint Conferencing Unit
Megaco Media Gateway Control Protocol
MGCP Media Gateway Control Protocol
NTP Network Time Protocol
PSTN Public Switched Telephony Network
QoS Quality of Service
RAS Registration, Admission and Status
RSVP Resource ReSerVation Protocol
RTCP RTP Control Protocol
RTP Real Time Protocol
SIP Session Initiate Protocol
SLA Service Level Agreement
SMTP Simple Mail Transfer Protocol
TCP Transport Control Protocol
TOS Type of Service
UAC User Agent Client
UAS User Agent Server
UDP User Datagram Protocol
xx
URI Uniform Resource Identifier
URL Uniform Resource Locator
VoIP Voice over Internet Protocol
1|1.1 Objectivos
Capítulo 1
Introdução
Este trabalho está inserido no âmbito da dissertação do Mestrado Integrado em Engenharia
Electrotécnica e de Computadores do major em Telecomunicações. O tema está orientado
para qualidade de serviço (QoS), no caso particular do serviço de voz sobre IP (VoIP).
Pretende-se desenvolver uma funcionalidade capaz de prever a qualidade de serviço de
chamadas para qualquer um dos contactos existentes.
O tema é interessante sob o ponto de vista de QoS, uma vez que VoIP é uma aplicação em
tempo real que necessita de garantir certos níveis de qualidade.
Este trabalho obrigou a um levantamento e avaliação de ferramentas a utilizar, pois não
tinha o objectivo principal o desenvolvimento mas, sobretudo a integração de módulos de
software.
A previsão da qualidade das chamadas será baseada numa conversão dos valores de
algumas métricas de QoS, para uma quantificação de um nível qualitativo, segundo critérios
bem definidos.
1.1 Objectivos
Para este trabalho de dissertação foi definido como objectivo principal a integração de
uma ferramenta capaz de efectuar medidas de QoS numa aplicação que permita estabelecer
ligações VoIP, de modo a ser possível prever individualmente a qualidade de chamada para os
possíveis contactos. Para além do objectivo principal que é o de elaborar uma ferramenta
capaz de quantificar a qualidade de uma ligação VoIP, outros objectivos acabam por ser
inerentes a este tais como, adquirir os conceitos envolvidos, conhecer o meio em que o tema
se insere, ter a noção do que já foi feito e do que ainda está por conceber ou desenvolver.
Daí que seja necessário obter conhecimento das ferramentas que existem, das que são
livres, das suas limitações e ainda compreender de que forma se podem complementar. É
2|Introdução
também necessário um estudo acerca de servidores VoIP tal como de clientes que suportem o
protocolo SIP.
1.2 Enquadramento
Este trabalho baseia-se na análise da qualidade de serviço em VoIP. É uma tecnologia que
está em grande expansão e que promete revolucionar toda a rede convencional de voz
(PSTN).
Esta tecnologia consiste na transmissão de voz através de pacotes, utilizando uma rede IP.
Já existem imensas aplicações de Clientes, Servidores e Bibliotecas para VoIP e muitos
mais ainda serão desenvolvidos, tal como vários protocolos. Para além de VoIP várias outras
aplicações necessitam de garantir certos níveis de qualidade de serviço, tal como as
aplicações que incluem vídeo.
Geralmente, as aplicações em tempo real são as mais problemáticas relativamente à
qualidade, daí requerem maiores cuidados. Por estes aspectos, o tema desta dissertação é
muito importante na análise do impacto da qualidade de serviço nas ligações de voz pela
Internet.
1.3 Caracterização do Problema
Neste trabalho o problema abordado é referente à qualidade de serviço existente numa
rede IP. Uma rede como a Internet tem como modelo base o best effort, logo não garante
QoS, salvo a excepção de existir um acordo entre o cliente e o seu provedor de serviços
Internet (ISP).
Como a Internet não foi concebida para aplicações em tempo real, o modelo best effort
era suficiente. Actualmente, já não é assim, parte da informação que circula na rede é
tráfego com requisitos de tempo real, o que exige melhor qualidade de serviço.
Todas as aplicações de tempo real, como é o caso de aplicações de voz ou vídeo, se
tiverem problemas de atrasos, perdas ou jitter na entrega dos pacotes são alvo de
degradação perceptível por parte do utilizador o que não é aceitável. Daí a necessidade de
garantir certos parâmetros de qualidade de serviço.
As aplicações que vão ser sujeitas a testes de qualidade de serviço são aplicações de voz
VoIP, ou seja, com requisitos de tempo real o que implica uma muito maior exigência da
parte da rede e consequentemente um fulcral controlo por parte das entidades responsáveis
para garantir um nível de satisfação por parte dos clientes.
Portanto, nesta dissertação vão ser efectuadas medições das métricas que caracterizam a
qualidade de uma rede de modo a permitir qualificar o nível de QoS, numa ligação entre dois
3|1.4 Estrutura
quaisquer clientes VoIP e se possível permitir a identificação de causas para possíveis
problemas.
1.4 Estrutura
Este relatório está organizado em sete capítulos bem definidos de forma a caracterizar
todo o trabalho realizado de forma sequencial.
Inicialmente, tem uma introdução para situar o contexto da dissertação expor os
objectivos, o enquadramento do tema abordado, a caracterização do problema e a
organização do conteúdo.
O segundo capítulo aborda o Estado da Arte, e consiste em explicar os conceitos
relacionados com o trabalho em causa e fazer referências a trabalhos relacionados com o
mesmo.
O terceiro capítulo faz referência a ferramentas úteis à dissertação. Foi feita uma
pesquisa e uma lista de ferramentas e software que permitiu uma escolha consciente de quais
utilizar.
No quarto capítulo faz-se um levantamento da arquitectura utilizada para o
funcionamento do VoIP, a interligação dos diferentes componentes que a compõem e ainda
uma ligeira abordagem ao funcionamento do Ekiga com a nova funcionalidade implementada.
O quinto capítulo corresponde à implementação, é uma das fases mais importantes do
projecto, pois é onde o projecto “ganha vida”. Pretende-se descrever todo o trabalho que
realmente foi realizado, com demonstração desde configurações da arquitectura da rede até
ao código implementado. O objectivo é apresentar as etapas com a devida cronologia.
O sexto capítulo da dissertação está reservado para a selecção de um cenário de teste
adequado aos objectivos pretendidos, e os consequentes testes que o comprovem. Com os
testes pretende-se comprovar a veracidade dos valores obtidos consoante a variação do
tráfego injectado na rede, e provar a automatização do sistema para funcionar
independentemente da localização dos utilizadores. E obviamente, comprovar o bom
funcionamento da solução implementada.
O sétimo e último capítulo é constituído pela conclusão, serve para fazer um balanço ao
que foi feito, informar quais os conhecimentos que foram apreendidos e claro fazer uma
introspecção e verificar se os objectivos foram ou não alcançados.
4|
5|2.1 Conceitos abordados
Capítulo 2
Estado da Arte
2.1 Conceitos abordados
2.1.1 Protocolo IP
A rede denominada de Internet, como a conhecemos actualmente, teve origem nos finais
dos anos 60 do século XX, mais propriamente em 1969. O Departamento de Defesa Americano
constituiu a ARPANET (Advance Research Projects Agency), que tinha como objectivo a
interligação de computadores utilizados em centros de investigação com fins militares.
Durante os anos 70, por razões de segurança a rede continuava a ser estritamente controlada
pelos militares.
Foi então dividida em dois grupos a MILNET, que era responsável pelas regiões militares e
a nova ARPANET, que era responsável pelas não militares.
Em 1970 teve origem o protocolo denominado de IP (Internet Protocol), tornava possível a
interligação entre as redes comutando o tráfego de uma rede para outra. Com a inclusão do
protocolo IP no UNIX, em 1982 várias universidades criaram as suas redes que por sua vez
também foram ligadas à Internet [1].
O IP é um protocolo que permite a troca de informação sobre a forma de pacotes de uma
máquina para outra, através da Internet. De um modo geral, quando um utilizador estabelece
uma ligação à Internet, o ISP (Internet Service Provider) atribui um endereço IP público ao
computador que o identifica de uma forma única em toda a rede. Quando um utilizador
quiser enviar informação, ela é dividida em pequenos pacotes (pacotes IP) que contêm o
endereço do destinatário e o seu.
Os pacotes IP podem ter um percurso complexo até chegarem ao seu destino, pois vão
passando por várias máquinas intermediárias. Cada pacote segue um caminho independente
6|
do
pr
|Estado da A
os restantes,
rimeiro lugar
O prot
protocolo
Arte
, o que pode
r não é nece
tocolo IP ape
de nível sup
e provocar um
ssariamente
enas entrega
perior – TCP (
Figura 2
Figura 2
ma chegada
o primeiro a
a os pacotes
(Transmissio
2.1 - Arquitect
.2 - Formato d
desordenada
a chegar ao
s, sendo por
on Control Pr
tura TCP/IP [2
do Pacote IP[2
a ao destino
destino.
isso necessá
rotocol) para
2].
2].
, isto é o que
ário recorre
a os reorden
e sair em
r a outro
ar.
7|2.1 Conceitos abordados
Descrição dos campos pertencentes a um pacote IP [2].
Versão: IPV4
HLEN: Comprimento do cabeçalho
Service type: usados em novas redes (QoS, DiffServ)
Total Lengh: Comprimento total do datagrama
ID: Identificação única do datagrama
Flags: DF (Don´t Fragment)
MF (More Fragment)
Fragment offset: Indica a posição de um fragmento em relação ao datagrama inicial
TTL: Tempo de vida é dado pelo número máximo de routers pelo qual cada pacote pode
passar
Protocol: Usado para desmultiplexagem
Header Checksum: Calculado sobre o cabeçalho
Source IP adress: Endereço IP de origem
Destination IP adress: Endereço IP de destino
IP options: Registo de rota
Registo de tempos
Encaminhamento definido pela origem
Data: Informação a ser efectivamente transmitida
2.1.2 P2P (Peer-to-Peer)
É a designação de um tipo de comunicação ponto a ponto entre dois utilizadores de uma
mesma rede, normalmente a Internet. Os utilizadores criam a ligação através de um servidor ou
mais servidores em que depois comunicam e fazem troca de dados entre si directamente. Os
utilizadores têm iguais responsabilidades e importâncias, ou seja, não existe a relação de
Cliente/Servidor mas sim estações, que tanto podem funcionar como Clientes como Servidores.
2.1.2.1 Arquitectura tradicional dos serviços na Internet
Como podemos visualizar na figura 2.3, esta arquitectura funciona como Cliente/Servidor, ou
seja, temos vários clientes e apenas um servidor que fornece toda a informação e ou serviços. A
grande vantagem desta arquitectura é o Cliente não necessita de grande poder computacional,
tornando o Cliente simples. O cliente é então denominado de passivo uma vez que requer serviços
mas não os fornece.
A grande desvantagem desta arquitectura reside no facto de a largura de banda disponível do
servidor ser limitada, o que implica um número limitado de atendimento de clientes [3].
8|
2.
as
en
no
fo
um
de
re
|Estado da A
.1.2.2 Arqu
Como se po
s ligações es
ntre si. Nest
o anterior, p
Portanto, a
ornecimento
ma vez que n
e largura de
A tecnolog
ede, garante
Arte
Figura
uitectura d
ode ver nest
stavam depe
te modelo de
ois são capa
a grande van
de serviços
não está dep
banda uma v
gia P2P tem p
uma maior
F
a 2.3 - Arquite
de uma red
ta arquitectu
endentes de
e comunicaç
azes de forne
ntagem resid
por todas as
pendente de
vez que a inf
por isso a ca
robustez na
Figura 2.4 - Ar
ectura Tradicio
de Peer-to
ura (figura 2
e um servido
ção as estaçõ
ecer e solicit
de no facto d
s máquinas e
apenas uma
formação é
apacidade de
disponibiliza
rquitectura de
onal dos Servi
o-Peer
.4), ao contr
or, todas as
ões não são
tar serviços.
de existir um
envolvidas, s
a estação, e
partilhada p
e maximizar
ação de recu
e uma rede Pe
iços na Interne
rário do mod
estações es
passivas, ao
ma distribuiç
sendo uma v
também dim
or todos os n
os recursos d
ursos a um cu
eer-to-Peer [3
et [3].
delo anterior
stão ligadas
o contrário d
ção da respo
antagem no
minui drastica
nós.
de todos os
usto reduzid
].
r em que tod
directamen
do que suced
nsabilidade
caso de falh
amente a fa
dispositivos
o.
das
nte
dia
de
ha,
lta
da
9|2.1 Conceitos abordados
2.1.3 QoS
2.1.3.1 Introdução QoS
O protocolo IP foi implementado e desenvolvido como um protocolo de comunicação com
controlo de tráfego baseado no serviço do melhor esforço (Best-effort Service).
O serviço Best-effort não prevê nenhum mecanismo de qualidade de serviço e portanto
nenhuma garantia de atribuição de recursos da rede.
Inicialmente, não se imaginava que a Internet se tornaria a grande rede que é, nem que
iria suportar voz, dados e vídeo numa única infra-estrutura de redes de pacotes. Com o
desenvolvimento de serviços de voz e vídeo em tempo real, houve a necessidade de
desenvolver protocolos de QoS (Qualidade de Serviço).
2.1.3.2 Modelos de QoS
Para satisfazer as necessidades de aplicações de dados e aplicações com requisitos de
tempo real foi necessário criar melhorias em relação ao modelo tradicional designado de
melhor esforço, de forma a incluir diferentes níveis de QoS e capacidade de gerir a atribuição
de recursos.
Actualmente, existem dois modelos de QoS IP, o modelo de Serviços Integrados
(Integrated Services - IntServ) e o modelo de Serviços diferenciados (Differentiated Services -
DiffServ). Foram ambos desenvolvidos pela organização encarregue pelos protocolos da
internet IETF (Internet Engineering Task Force).
2.1.3.2.1 Modelo IntServ
Este modelo aplica-se na qualidade de serviço fim a fim, ou seja, baseia-se na reserva de
recursos alocados pelos routers para garantir que os fluxos de pacotes tenham todos os
recursos necessários para a obtenção de um bom serviço.
IntServ pode, por exemplo, ser utilizado para possibilitar a transmissão de vídeo e som
sem interrupções. Fundamentalmente, é um serviço que garante a reserva de recursos para
ligações individuais. O modelo IntServ necessita de um protocolo de sinalização para a reserva
de recursos e que os routers mantenham a informação de estado por fluxo.
Para a sinalização o protocolo RSVP (Resource ReSerVation Protocol) é o utilizado, embora
não seja este o protocolo obrigatório.
10
RS
m
pe
0|Estado da
Modelo
IntServ
SVP (Resourc
Protocolo
odo a garant
A reserva
elo qual as m
Arte
o
v G
ce ReSerVati
de sinalizaç
tirem niveis
de recursos
mensagens RE
Tab
Classe de Se
Best-effo
Guaranteed S
Controlled-
Service
on Protocol)
ção para poss
de QoS solic
s é realizada
ESV podem p
Figura 2.
bela 2.1 - Mode
erviço
ort
N
se
d
Service G
a
-Load
e
O
c
c
a
)
sibilitar a re
citados.
a através de
passar a gara
5 - Reserva d
elo IntServ.
Não há qualq
erviço, nem
e tráfego (p
Garante a e
traso admiss
O objectivo
omo o ser
ondição de t
ser mais efi
eserva de rec
mensagens
antir os recu
de Recursos
Descriç
quer contro
qualquer ti
rivilégios).
entrega dos
sível e previa
desta class
rviço best-e
ter carga con
icaz.
cursos por p
PATH, que c
rsos necessá
[2].
ção
le de qualid
po de difere
s pacotes c
amente defin
se é que f
effort mas
ntrolada de
parte das est
constroem o
ários.
dade de
enciação
com um
nido.
funcione
com a
maneira
tações de
caminho
11|2.1 Conceitos abordados
IntServ Problemas
Escalabilidade: Possibilidade de ocorrer uma sobrecarga de processamento e memória
caso o número de fluxos seja demasiado, uma vez que a quantidade de informação de estado
aumenta de forma proporcional ao número de fluxos.
Complexidade dos routers: Todos os dispositivos têm de implementar RSVP, controle de
admissão, classificação e escalonamento de pacotes.
Para Guaranteed Service, a arquitectura tem de ser implementada de uma só vez.
2.1.3.2.2 Modelo DiffServ
O diffServ opera sobre grandes volumes de dados ao contrário das reservas individuais
utilizados pelo IntServ. A arquitectura DiffServ parte do princípio que domínios adjacentes
tenham um acordo sobre os serviços que serão disponibilizados entre os mesmos. Este acordo
denomina-se SLA – Service Level Agreement. Estes acordos especificam que classes de tráfego
serão servidas, que garantias são necessárias para cada classe, e qual o volume de dados para
cada classe.
No cabeçalho de um pacote IP, existe um campo chamado TOS (Type of Service) que pode
representar o tipo do serviço utilizado.
Tabela 2.2 - Modelo DiffServ
DiffServ
Classes de tráfego Descrição
Best effort
Não há qualquer controlo de
qualidade de serviço, nem
qualquer tipo de
diferenciação de tráfego
(privilégios).
Assured Forward (AF)
Inclui quatro classes de prioridade em que cada uma contém três níveis diferentes de prioridade de descarte.
Expedite Forward (EF) Tráfego com maior prioridade
12
2.
ut
ut
da
gr
ob
es
co
di
2.
m
na
m
pa
- Q
- T
- N
pa
- T
2|Estado da
.1.3.3 Med
Como já fo
tilizadores m
tilizada. Este
a rede, uma
randes falhas
Para se po
bter valores
stado em que
A qualidad
omo: atraso,
Para se o
stintas de se
.1.3.3.1 Me
As medida
odificar nad
a seguinte fig
Estas med
aneira a con
assam.
Alguns exe
Quantidade d
Tempos de c
Níveis da fila
acotes)
Tipos de tráf
Arte
didas de Qu
oi realçado,
mas também
e fenómeno
a vez que sã
s de serviço.
oder control
de alguns p
e se encontr
de de uma
perdas, dife
obter os val
e fazer, é po
edidas Pas
as passivas
da na rede, i
gura.
Figu
dições podem
nseguir capt
emplos de pa
de bits/ pac
chegada ou t
a dos buffer
fego/ protoc
ualidade d
a rede IP so
ao nível da
tornou impr
ão cada vez
lar e monito
parâmetros c
ra.
rede pode
erença entre
lores destes
ossível fazer
ssivas
consistem
isto é não se
ra 2.6 - Tráfe
m ser implem
turar e grava
arâmetros qu
cotes transmi
tempos entre
rs (que pode
colo recebido
e Serviço p
ofreu um gra
diversidade
rescindível a
mais as apl
orizar a qual
capazes de
por isso ser
e atrasos e la
s e outros p
a medição d
em control
e adiciona t
go da Rede co
mentadas ao
ar as caract
ue podem se
itidos
e chegada do
m ser usado
os
para redes
nde avanço
do tipo de a
a existência
licações em
lidade de se
caracterizar
r caracteriza
argura de ba
parâmetros
de forma pas
lar e monit
ráfego inútil
om medições
o adicionar
erísticas e a
er calculados
os pacotes
os como indic
s IP
não só a nív
aplicações p
de um cont
tempo real
erviço de um
r a rede de
ada por algu
nda.
equivalente
ssiva ou activ
torizar o tr
l à rede com
Passivas [4].
alguma inte
a quantidade
s à custa das
cadores de p
el de crescim
para o qual e
trole do dese
, o que não
ma rede é ne
forma a sab
uns parâmet
es há duas
va.
áfego sem
mo se pode v
eligência na
e dos pacote
medidas pa
perdas ou at
mento de
está a ser
empenho
o permite
ecessário
bermos o
tros, tais
maneiras
criar ou
visualizar
rede, de
es que lá
ssivas:
rasos nos
2.
As
at
pa
co
Ao
ad
Me
às
as
ex
pa
.1.3.3.2 Me
s medidas ac
trasos (delay
Para se ef
ara se notar
omportamen
o contrário
dicional.
edições que
- Atra
- Perd
- Varia
- Larg
Com o aum
s aplicações
s medições d
Embora nu
xemplo de
arâmetros já
edidas Act
ctivas são um
y) e variação
fectuar este
as alteraçõe
to [4].
das medida
Figu
podem ser o
so (Delay)
das (Loss)
ação do atra
ura de band
mento da im
de tempo re
dos vários pa
um capítulo
algumas fe
á referidos.
tivas
ma outra for
de atrasos (
tipo de me
es ou mesmo
as passivas
ura 2.7 - Tráfe
obtidas atrav
aso (Jitter)
a (Bandwidt
portância do
eal têm sido
râmetros.
o mais à fre
rramentas o
rma de conse
(jitter) de pa
dições é nec
o valores ca
como se p
ego na rede co
vés do métod
h)
o desempenh
implementa
ente se faça
open-source
eguir mediçõ
acotes na re
cessário inje
lculados dire
ode ver na
om medições
do activo:
ho das redes
adas muitas
a uma referê
capazes d
13|2.1
ões para as
de.
ectar tráfego
ectamente,
seguinte f
Activas [4].
s devido ao a
ferramentas
ência mais
e obter os
Conceitos a
perdas (pack
o apropriado
e daí perceb
figura existe
aumento do t
s capazes de
detalhada, f
vários val
bordados
ket loss),
o na rede
ber o seu
e tráfego
tráfego e
e fazerem
fica já o
ores dos
14|Estado da Arte
Tabela 2.3 - Ferramentas para efectuar medições de parâmetros QoS
Tipos de medidas Ferramentas Custo
Passivas MRTG, Nagios, NetFlow,
Statscout, whireshark
Open-source
Activas
Pathchirp, Fping, Mgen, Ping
Plotter, MRTG, Pathchar,
Pathload, Pathrate, Iperf, H.323
Beacon, OWAMP, Traceroute,
freeping, Napoleon, MCM, TRPR,
RSVP.
Open-source
Tabela 2.4- Comparação entre medidas Activas e Passivas
Medidas Vantagens Desvantagens
Activas
Consegue caracterizar melhor
as métricas pois testa mesmo
injectando tráfego próprio
para testar o comportamento
da rede.
Ocupação de largura de banda
provocada pelo tráfico injectado
artificialmente
Passivas
Não necessita de injectar
tráfego adicional na rede.
Necessita de mais informação nos
cabeçalhos dos pacotes para
poder obter e armazenar a
informação necessária.
2.1.3 VoIP
2.1.3.1 Introdução VoIP
VoIP (Voice over Internet Protocol) como a própria palavra explica é transmitir sinal de
voz através de uma rede de dados usando o protocolo internet. A informação é transportada
sobre a forma de pacotes quer dizer que é transmitido no formato digital e não analógico.
Tornou-se rapidamente numa tecnologia muito popular devido à grande vantagem de ser
grátis se usarmos software gratuito existente, porque desta forma estamos a fazer chamadas
dispensando os serviços das companhias telefónicas.
Outros factores também importantes para justificar este crescimento são nomeadamente
o aumento de locais com acesso de banda larga e a melhoria de qualidade de serviço que é
es
co
m
fr
re
pr
co
2.
ca
ou
de
ef
te
pa
a
stritamente
onvencional
VoIP é um
undial. Já e
reeCall, voip
As operado
evelam que j
Em Portug
rimeira a a
onsiderável r
Outra vant
.1.3.2 Tipo
PC ---- PC
apaz de efec
u então usar
emonstrada n
PC ---- Te
fectuar a lig
elefone conv
ara fazer a li
figura 2.9 de
necessária
rede telefón
ma tecnologia
existem vári
Stunt, VoipC
oras de todo
á este ano c
gal são cada
aparecer foi
redução de c
tagem é que
os de ligaç
: [6] Pode se
ctuar chamad
r um servido
na seguinte
lefone: Com
ação VoIP e
vencional tem
igação entre
escreve.
para a obt
nica à rede IP
a revolucion
ias aplicaçõe
Cheap e muit
o mundo estã
cerca de 32%
a vez mais
a Netcall
custos nas em
e além de voz
ões VoIP
er feita utili
das VoIP e n
or próprio p
figura.
Figura 2
mo foi explica
m relação a
m que se ut
e a rede IP e
tenção de u
P [5].
ária que pod
es como é
tas outras [6
ão a investir
das chamad
as empresas
criada em
mpresas supe
z também se
izando um c
ecessita de
ara encamin
2.8 - VoIP Liga
ado anterior
o telefone,
ilizar um ad
a rede PSTN
um bom se
de transform
o exemplo
6].
muito neste
das totais sej
s que ofere
2005, as
eriores a 40%
e pode trans
omputador p
ter conhecim
nhar a cham
ação PC-PC [6
rmente o PC
pode ser um
daptador ATA
N (Public Swi
15|2.1
erviço, e a
mar totalmen
do Skype, V
e sentido, me
jam chamad
cem serviço
suas oferta
%.
mitir vídeo.
pessoal com
mento do en
mada. Exemp
6].
deve ter um
m telefone IP
A (Analogue
itched Telep
Conceitos a
fácil integr
nte a rede te
VoipBuster,
esmo porque
as VoiP.
os de telefo
as baseiam-s
software ap
ndereço IP de
plo desta lig
m programa
P ou então s
Telephone
phony Netwo
bordados
ração da
elefónica
Asterisk,
e estudos
nia IP, a
se numa
propriado
e destino
ação é a
capaz de
se for um
Adapter)
ork) como
16
ch
ap
2.
po
m
co
6|Estado da
Telefone
hamada é fe
presentada.
.1.3.3 Algu
Para os ut
ois acabam p
As variaçõ
uito elevado
As perdas
onsideráveis
Arte
---- Telefone
eita sem qu
F
uns problem
tilizadores é
por se interro
ões de atras
os acabam po
de pacotes
perdas da co
Figura 2.9
e: Esta ligaç
ualquer com
Figura 2.10 - V
mas VoIP
é muito com
omper mutua
o jitter prov
or se perder
s causam in
onversação.
- VoIP Ligação
ção não nec
mplicação, c
VoIP Ligação T
plicado ter
amente ou f
vocam ruído
os pacotes,
terrupções,
o PC-Telefone
cessita de ne
omo se pod
Telefone-Tele
uma convers
falar em simu
os estranhos
pode se red
e se forem
e [6].
enhum comp
de visualizar
fone [6].
sa em que h
ultâneo.
na linha e
duzir usando
m muitos e c
putador e p
r na figura
haja grandes
se forem de
jitter buffe
consecutivos
por isso a
a seguir
s atrasos,
e valores
rs.
s causam
2.
Te
se
2.
pr
H3
Co
pr
de
pa
pr
ve
.1.3.4 Algu
er uma boa
erviço de QoS
.1.3.5 Func
Para o es
rotocolos de
323 embora
ontrol Protoc
Actualmen
rotocolo mai
Para ser p
escrição exac
No envio d
ara digital,
rotocolos RT
eremos estes
umas soluç
largura de
S e ainda ter
cionament
stabelecimen
sinalização.
haja outros
col), Skype,
nte, está-se
s simples e b
ossível o env
cta das sessõ
da voz/vídeo
de modo a
TP (Real Tim
s pormenores
Fig
ções VoIP
banda, se p
r jitter buffe
to do VoIP
nto, modific
Os protocol
s tais como
CorNet-IP, M
a adaptar
bastante par
vio dos dado
ões.
o efectivo é
a ser transm
me Protocol)
s com maior
gura 2.11 - Pro
possível ter
er para aten
cação ou fin
los mais utili
IAX (Inter A
MiNET, Mega
o protocol
recido com o
os são necess
é necessário
mitido. O t
) e RTCP (R
r detalhe.
otocolos de si
um bom ac
uar as difere
nalização de
izados são: S
Asterisk eXch
aco (Media G
o SIP em d
os já conheci
sários protoc
codecs para
ransporte n
Real Time C
nalização par
17|2.1
cordo com u
enças de atra
e uma cham
SIP (Session I
hange) e MG
Gateway Con
detrimento d
idos HTTP/SM
colos para um
a converter
ormalmente
Control Proto
ra VoIP [8].
Conceitos a
um ISP para
asos.
mada são ne
Initiation Pr
GCP (Media
troller) [8].
do H323 po
MTP.
ma negociaçã
o som, de a
e é efectua
ocol), mais
bordados
garantir
ecessários
rotocol) e
Gateway
ois é um
ão e uma
analógico
do pelos
à frente
18
RT
É
ge
o
of
O
tr
Se
se
Co
áu
pa
8|Estado da
TP (Real Tim
um protocol
eralmente UD
envio, adici
ferece qualq
RTP tem du
ansferência
erviço e é ta
essão.
odecs
Um codec
udio milhare
ara o envio e
Arte
me Protocol)
lo utilizado
DP como pro
iona a cada
uer garantia
uas compon
dos dados,
ambém resp
Fig
c, ou codific
es de vezes p
e vice-versa.
Figur
para aplicaç
otocolo de tr
fragmento
a de entrega.
entes distin
e o RTCP
ponsável pelo
gura 2.12 - Fo
cador/descod
por segundo,
ra 2.13 - Conve
ções em tem
ransporte. É
uma numera
.
tas, o própr
(RTP Contro
o envio dos
rmato de um
dificador faz
, converte c
ersão de um s
mpo real (ent
responsável
ação sequen
rio RTP que
ol Protocol)
dados sobre
pacote RTP (d
z a conversã
ada amostra
sinal analógico
trega de áud
por dividir o
cial e o tem
é o protoco
que monito
e os particip
dados) [2].
ão por amo
a para digita
o para digital
dio fim a fim
o fluxo de áu
mpo de entr
olo responsá
oriza a qual
pantes envo
ostragem do
al e depois c
m), utiliza
udio para
ega. Não
ável pela
idade de
lvidos na
sinal de
comprime
19|2.1 Conceitos abordados
Diferentes tipos de codecs
GSM - 13 Kbps (full rate)
iLBC - 15Kbps
ITU G.711 - 64 Kbps, baseado em amostra. Também conhecido por alaw/ulaw
ITU G.722 - 48/56/64 Kbps
ITU G.723.1 - 5.3/6.3 Kbps
ITU G.726 - 16/24/32/40 Kbps
ITU G.728 - 16 Kbps
ITU G.729 - 8 Kbps
Speex - 2.15 to 44.2 Kbps
LPC10 - 2.5 Kbps
DoD CELP - 4.8 Kbps
2.1.4 Protocolo de sinalização H323
O padrão H.323 é parte da família de recomendações ITU-T (International
Telecommunication Union Telecommunication Standardization sector) H.32x, que pertence a
série H da ITU-T, e que trata de "Sistemas Audiovisuais e Multimédia".
Define um conjunto de protocolos para permitir a comunicação de vídeo e áudio.
Não oferece garantias de qualidade de serviço, é independente da arquitectura da rede
por isso é compatível com Ethernet, Fast Ethernet, FDDI ou Token Ring. O H323 tem “perdido
terreno” e está seriamente ameaçado pelo SIP [7].
Os protocolos utilizados pelo H323 são os que estão representados na figura seguinte.
O já conhecido protocolo IP (Internet protocol), os protocolos de transporte TCP
(Transmission Control Protocol) que garante a entrega dos dados e a sua ordem de chegada e
UDP (User Datagram Protocol) que é adequado para aplicações que não necessitam de
reconstruir a sequência dos datagramas como é o caso das aplicações de tempo real [9].
O protocolo RTP (Real Time Protocol) funciona juntamente com o RTCP (RTP Control
Protocol). É utilizado para a entrega de dados áudio fim a fim em aplicações de tempo real e
utiliza o protocolo UDP para transporte.
O protocolo RTCP serve para obter feedback sobre a qualidade de distribuição dos dados.
RAS (Registration, Admission and Status) protocolo que transmite através de um canal não
confiável usando UDP mensagens de comunicação de registo, admissão, mudanças na largura
de banda e estado entre entidades H.323.
O protocolo H.245, é transmitido através de TCP, é utilizado para interligar todas as
entidades H.323. Negoceia facilidades entre os participantes de uma chamada H.323, tais
como abertura e fecho de canais lógicos (portas UDP para transporte de fluxos RTP e RTCP).
Q.931 é um protocolo de sinalização que é usado para realizar o setup e também o término
da chamada entre dois agentes H.323. Este protocolo é transmitido através de TCP.
20
vo
Un
Te
ob
re
m
ga
qu
Ga
de
Ga
au
e
Mu
m
(M
co
fo
pr
0|Estado da
O padrão
oz e vídeo e
nits (MCUs).
erminais: S
brigatoriame
ecursos para
Todos os t
ensagens re
atekeeper (R
É ainda ne
ue suportar o
ateways: Ga
e comunicaç
atekeepers:
utorização de
controla qua
ultipoint Co
ais pontos te
Multipoint C
onferência, i
O MP (Mu
ormatos, com
roveniente d
Arte
Fig
H.323 espec
em tempo re
São os com
ente garantir
vídeo.
terminais tê
elativas à s
RAS).
ecessário im
os protocolos
arante a con
ão distintos.
Apresenta
e chamadas,
ais os termin
ontrol Units
erminais. Ge
ontroller) g
dentificando
ultipoint Pro
mo por exem
e diferentes
gura 2.14 - Pil
cifica quatro
eal, são os T
mponentes m
r a transmis
m que imple
inalização d
mplementar o
s RTP/RTCP.
nversão apro
.
funções de
, supervision
nais possuem
(MCUs): Sup
eralmente, t
ere a negoc
o as capacida
ocessors) é
mplo de G.7
s fontes de á
ha de protoco
tipos de co
Terminais, G
mais básico
ssão de áudi
ementar o p
das chamad
o protocolo
.
opriada entr
controlo de
na o número
m chamadas e
porta funções
tem um cont
ciação H245
ades de áudi
responsável
711 para G.
áudio.
olos do padrão
mponentes q
Gateways, Ga
os de qualq
io e, opcion
protocolo H.2
as (Q.931)
H.245 descr
e formatos
e sinalização
de acessos e
estabelecida
s de controlo
trolador e um
de todos o
io e vídeo co
l pela conve
723.1 ou po
o H323 [9].
que permite
atekeepers e
quer rede
nalmente., p
225, que de
e para a c
rito anteriorm
de transmiss
de chamad
em simultâne
as.
o para confe
m processado
os dispositivo
ompatíveis co
ersão dos d
or transmitir
em a comuni
e Multipoint
com recurs
pode incluir
efine um con
comunicação
mente, tem
são e proced
das, controlo
eo de termin
erências entr
or multi-pon
os envolvent
om todos.
dados dos d
r o fluxo co
cação de
t Control
sos para
também
njunto de
o com o
também
dimentos
o sobre a
nais H323
re três ou
nto. O MC
tes numa
iferentes
ombinado
in
co
su
Ex
O
Ef
Um
la
Cr
pr
Ap
At
su
De
pe
Qu
Po
pa
A Unidade
tegrada no i
Ao visualiz
onstituiem u
ua zona, e o
xemplo de u
PC envia pa
fectua o regi
ma vez receb
rgura de ban
ria uma liga
rotocolo Q.9
pós estar est
través do pro
uas capacidad
epois são es
elo protocolo
ualquer uma
or fim, depo
ara poder lib
e de Control
nterior de u
zar a seguin
ma ligação
gateway que
uma chamad
cotes UDP p
isto no “Gate
bida a confir
nda para um
ação TCP com
31 para criar
tabelecida a
otocolo H.24
des, isto é, s
tabelecidas
o RTCP.
a das partes p
ois de termin
bertar os rec
lo Multipont
m Gateway,
nte figura, p
H323. Temo
e é responsá
Fig
da entre um
ara descobri
ekeeper”, en
rmação de su
a ligação.
m o gatekee
r a ligação a
ligação tele
45 há uma ne
suporte de v
duas ligaçõe
pode termin
nada a ligaç
ursos [10].
to pode ser
Gatekeeper
pode-se faci
os o Gatekee
vel pela inte
gura 2.15 - Mo
PC e um tel
ir o endereço
nviando uma
ucesso do re
eper para tr
ao telefone r
efónica, o PC
egociação po
vídeo, chama
es unidirecc
ar com a liga
ção, o PC co
um disposit
r ou Termina
ilmente ver
eper a contro
erligação ent
odelo H323
lefone conve
o IP do “Gat
a mensagem
egisto, envia
roca de men
emoto.
C comunica d
or ambas as p
adas em conf
cionais RTP n
ação utilizan
omunica o fi
21|2.1
ivo independ
al.
os diferente
olar os term
tre redes dif
encional
tekeeper”.
RAS.
nova mensa
nsagens de s
directamente
partes envol
ferência, qu
no caso de v
ndo o sinal Q
m da chama
Conceitos a
dente ou po
es compone
minais perten
ferentes.
agem RAS a r
sinalização
e com o gate
lvidas para a
ais os codecs
voz, que são
Q.931 HANGU
ada ao “gate
bordados
ode estar
ntes que
ncentes à
requisitar
usando o
eway.
acertar as
s, etc…
o geridas
UP.
ekeeper”
22
2.
(In
sim
ba
Vo
pa
Co
fo
2|Estado da
.1.5 Protoc
SIP (Sessio
nternet Engi
mples que o
astante aber
oIP. Actualm
adrão H323.
Os protoc
odecs para
ormato a usa
Arte
Figura 2.16
colo de sin
on Initiation
ineering Tas
o H323. O SIP
rto e flexíve
mente, é o pr
olos utilizad
a codificaçã
r nos fluxos
6 - Chamada e
nalização S
n Protocol)
sk Force), fo
P é um prot
el. Tem com
rotocolo em
dos pelo SIP
ão e o pro
multimédia,
Figura 2
entre um PC e
SIP
é um proto
oi projectad
tocolo muito
mo funções e
maior expa
são os já d
tocolo SDP
, codecs, orig
2.17 - Pilha de
e um telefone
ocolo de sina
do e conceb
o semelhante
estabelecer,
nsão e tem v
descritos RT
(Session De
gem e destin
e protocolos S
convencional
alização des
ido para ser
e ao HTTP, é
modificar e
vindo a subs
TP/RTCP par
escriptor Pr
no…
SIP
[10].
senvolvido p
r um protoc
é baseado e
e finalizar c
stituir o já c
ra o envio d
rotocol) espe
pelo IETF
colo mais
em texto,
chamadas
onhecido
do áudio,
ecifica o
2.
se
su
qu
Os
[1
.1.5.1 SDP
Como o pr
essões multi
uficientes pa
É o protoc
uanto ao tipo
As mensag
• Nome
• Tempo
• Inform
• Inform
s diferentes
6].
(Session D
róprio nome
imédia, com
ra permitir p
colo respons
o de dados a
gens do proto
da sessão e
o que a sessã
mação acerca
mação necess
componente
Dresciptor
indica é um
munica a ex
participantes
ável pela ne
a transmitir,
ocolo SDP inc
o seu objec
ão esta activ
a da sessão
sária para re
Figura 2.18 - M
es que const
Protocol)
m protocolo d
xistência de
s na sessão [
egociação en
o tipo de co
cluem as seg
tivo
va
ecepção (end
Mensagem SD
ituem o SIP
de descrição
e uma sess
[13].
ntre as duas
ompressão, e
guintes infor
dereços)
DP [14].
estão repres
23|2.1
o de sessão,
ão e negoc
partes envo
endereços de
rmações [14]
sentados na
Conceitos a
ou seja, des
ceia as info
olvidas na se
e origem e de
]:
tabela segui
bordados
screve as
ormações
essão SIP,
estino…
inte [11],
24|Estado da Arte
Tabela 2.5 - Componentes do SIP
Componente SIP Descrição
UAC (User Agent Client)
UAC juntamente com UAS formam a parte do UA (User
Agent). A aplicação UAC quando inicia uma sessão SIP
determina a informação que é essencial, como por exemplo
qual é o protocolo, a porta e o endereço IP do UAS para o
qual quer comunicar. Basicamente lança pedidos SIP ao UAS e
recebe as devidas respostas.
UAS (User Agent Server) È um dos componentes do UA, e tem como função gerar as
respostas aos pedidos SIP por parte do UAC.
Proxy Server
É um dos diferentes tipos de servidores existentes, é o
considerado servidor intermediário. Ao receber uma
solicitação SIP, tem como função encaminhá-la para a
entidade mais próxima do destinatário ou caso seja o mais
próximo encaminhar directamente.
Redirect Server
Este servidor recebe solicitações dos User Agents tal como o
Proxy SIP mas em vez de redireccionar para a entidade mais
próxima responde com a informação do endereço do servidor
mais próximo a ser contactado.
Registrar Server
É o servidor encarregue pelo registo dos utilizadores
guardando essa informação para poder fornecer a
correspondentes localizações e para poder resolver os
endereços pertencentes ao seu domínio.
2.1.5.2 Cabeçalho SIP
INVITE sip: [email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.server1.com;branch=z9hG4bK776asdhds Max-Forwards: 70
To: user2 <sip:[email protected]>
From: user1 <sip:[email protected]>;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 142
Se
m
de
po
fo
<s
ca
se
IN
ut
UR
Em
Fo
x:
y:
Po
egue uma ex
Via: Mostr
omento, ca
esignado de
ode passar.
To: Identi
oi enviada pa
From:
sip:user1@se
Call-ID: É
aso em concr
CSeq: Tem
equencial de
NVITE .
Contact:
tilizador que
Content-L
RI (Uniform R
É um iden
mail. Este id
ormato: sip:x
Nome do ut
Domínio on
ort: Porta pa
plicação dos
ra o protoco
ada proxy a
Max-Forwar
ficação do d
ara: user2 <s
Quem
erver1.com>;
um identific
reto tinha o
m como fun
e 32 bits e o
Contém um
e enviou a me
Length: Apre
Resource Ide
ntificador us
entificador p
x@y:Port
tilizador
de se encont
ara ser efect
Figura
s principais c
olo de trans
acrescenta
rd que indic
destinatário
sip:user2@se
enviou
;tag=192830
cador único e
identificado
nção ordenar
o método da
SIP URI (Un
ensagem. Ne
esenta o tam
entifiers)
sado pelo SI
permite loca
tra registado
uada a ligaç
2.19 - Método
campos:
sporte usado
uma linha
ca o número
da mensage
erver2.com>
a mensa
1774
e exclusivo d
or: a84b4c76e
r e identific
a requisição.
niform Reso
este caso <si
manho da me
IP com um f
alizar o desti
o, ou endere
ão.
os de estabele
o e indica o
neste camp
o máximo de
em. Neste ex
agem. N
de cada UA (
e66710@pc3
car as mens
. Neste exem
ource Identif
ip:user1@pc3
nsagem. Nes
formato bas
inatário quan
eço IP.
ecimento de u
25|2.1
caminho pe
po. Existe
e proxies ou
xemplo em q
este cas
(User Agent)
3.server1.co
sagens. Cons
mplo foi env
fiers), que é
33.server1.c
ste caso: 142
tante idênti
ndo se quer
uma sessão SIP
Conceitos a
ercorrido at
também um
u gateways p
questão a m
so foi:
. O User Age
om
siste em um
viado uma re
é a identific
om>
2 [17].
ico ao do se
iniciar uma s
P
bordados
té aquele
m campo
pelo qual
mensagem
user1
ent neste
m número
equisição
cação do
erviço de
sessão.
26
2.
fa
se
te
m
pa
re
RT
6|Estado da
.1.5.3 Sess
Agora ao
acilmente co
1- Inicialm
essão.
2- O telefo
entar estabel
3- Quando
ensagem 180
4- No mom
ara confirma
5- O utiliz
ecebeu a con
6- Inicia-s
TP/RTCP.
7- Quando
8- O outro
Arte
F
são SIP sem
analisarmos
ncluímos que
mente é env
one que rece
lecer a ligaç
o o telefone
0 (Ringing) p
mento em qu
ar o inicio de
ador que ini
nfirmação da
se assim a s
o um dos tele
o telefone re
Figura 2.20 - S
m Proxy
os passos d
e o SIP é um
viado o méto
ebeu o INVIT
ão.
que recebeu
para informa
ue o utilizado
e chamada.
ciou a cham
a chamada.
sessão com
efones é des
sponde envia
Sessão SIP sem
desta sessão
m protocolo b
odo de INVIT
TE responde c
u o INVITE co
ar que está a
or atende a
mada ao rece
os dados a
ligado pelo u
ando um 200
m Servidor Pro
o entre dois
bastante simp
TE por um d
com 100 (Try
omeçar com
chamar.
chamada o t
eber 200 (OK
serem tran
utilizador, é
0 (OK).
oxy [17].
utilizadores
ples e intuiti
dos utilizado
ying), ou sej
o toque de
telefone env
K), envia um
nsmitidos atr
enviada um
s com telefo
ivo.
ores para se
ja, a dizer q
chamada, e
via o sinal 20
ACK a confi
ravés dos p
a mensagem
ones SIP,
iniciar a
ue está a
nvia uma
00 (“OK”)
rmar que
rotocolos
m de BYE.
2.
re
sin
tr
P2
A
sin
.1.5.4 Sess
Neste exe
elativamente
nalização tê
ansmitidos o
2P.
tabela seg
nalização SIP
Comp
Prot
Enti
Fig
são SIP com
emplo temos
e ao exemplo
êm o proxy
os dados com
guinte faz u
P e H323 [12
onentes
ocolos
dades
gura 2.21 - Se
m Proxy
s um Servid
o anterior es
como inter
m o protoco
uma síntese
].
T
T
ssão SIP com
or Proxy en
stá no facto
rmediário. E
lo em que a
e da compa
abela 2.6 - SIP
H323
Terminal/Ga
Gatekeep
RAS/Q.9
H.245
ITU
um Servidor P
ntre os dois
que todas as
Excepto qua
a ligação é f
aração entr
P vs H323
ateway
per
931
5
27|2.1
Proxy [17].
clientes SIP
s perguntas/
ando estão a
feita directa
re os difere
Conceitos a
P, a única d
/respostas re
a ser efecti
amente com
entes proto
SIP
UA
Servidores
SIP
SDP
IETF
bordados
diferença
elativas à
ivamente
base em
colos de
28|Estado da Arte
Mensagens Binário Texto
Transporte RTCP/RTP RTCP/RTP
Endereçamento
Possui mecanismos de
endereçamento flexíveis
entre os quais se destacam
URL e o padrão de
numeração E.164.
Apenas permite o
endereçamento através de
URL.
CODECs
Suporta qualquer tipo de
CODEC.
Suporta qualquer CODEC
registado na IANA ou outro
CODEC cujo nome faz parte
de um acordo de
actualização.
Redundância
Define algumas
funcionalidades de controlo
de falhas em entidades
intermediárias da rede.
Como por exemplo, se um
gatekeeper falhar, o
protocolo está preparado
para utilizar um gatekeeper
alternativo. Os endpoints
H.323 podem se registar a
outro gatekeeper.
O SIP não dispõe de
procedimentos para controlo
de falhas nos dispositivos. Se
um agente SIP falha, não
existe meios para que o
Proxy venha detectar a
falha, excepto se o Proxy
enviar mensagens Invite para
o dispositivo e aguardar o
retorno dentro de um time-
out. Se o Proxy falhar, o
Agente SIP não possui
mecanismos para detectar a
falha.
2.2 Trabalhos relacionados
Neste capítulo vão ser apresentados alguns trabalhos já efectuados relacionados com o
tema em questão, neste caso de QoS e VoIP.
H323 Beacon
Foi desenvolvida uma ferramenta designada de H323 Beacon com o objectivo de
monitorizar a qualidade de uma sessão de vídeo-conferência baseada no padrão H323.
A arquitectura utilizada no H323 Beacon é baseada numa distribuição Cliente/Servidor,
para o seu desenvolvimento foram utilizadas as bibliotecas OpenH323, PWlib e PTLib.
A
co
do
2.
as
no
na
Ta
pa
re
jit
A ferrame
qualidade d
ompreendida
Este valor
os pacotes, e
Tem tamb
23).
O facto de
s aplicações
Uma alter
o cliente exi
as aplicaçõe
ambém não
ara além de
ede. Uma fu
tter [19].
enta foi testa
de serviço da
a entre 1 e 5
provém de
e são aprese
bém uma sér
e ter sido fei
que estão ag
ração que po
sta a obrigat
s existentes
faz separaçã
apenas util
ncionalidade
Fi
ada para ten
a sessão é a
, como a Fig
uma análise
ntados sob a
rie de opçõe
ita para o pa
gora a ser de
odia ser efec
toriedade de
s tipo skype
ão de testes
izar mediçõe
e interessant
gura 2.22 - H3
ntar descobri
avaliada num
gura 2.22 rep
dos parâme
a forma gráfi
es possíveis d
adrão H323 p
esenvolvidas
ctuada, pois
e inserção de
, os contact
s durante a s
es activas q
te é o facto
323 Beacon ní
ir onde ocor
ma escala idê
presenta.
etros de perd
ica.
de configura
pode ser con
utilizam na
s limita bast
e um endere
tos não são
sinalização e
ue pode alte
o de ser dim
íveis de qualid
29|2.2 Tr
rrem problem
êntica à já
das, atraso e
ção para o u
nsiderado um
sua maioria
ante a ferra
eço IP, uma v
directamen
e envio de d
erar o funcio
ensionável o
dade [19].
rabalhos rela
mas e as sua
conhecida M
e variação do
utilizador (v
ma desvantag
SIP.
amenta, é o
vez que na r
nte por ende
dados (voz o
onamento n
o tamanho d
acionados
s causas.
MOS, está
os atrasos
er Figura
gem, pois
facto de
realidade
ereço IP.
u vídeo),
ormal da
do buffer
30
Co
se
an
ga
qu
fe
re
to
de
pe
qu
qu
pa
es
qu
po
0|Estado da
ontrolo de a
Neste segu
essão basead
nteriores à c
arantir QoS p
ue em termo
eitas mediçõ
elativamente
O seguinte
otalidade da
epois feita u
erdas que po
ualidade mui
ue prejudica
O senão d
acotes, o qu
studo també
ualidade das
Para além
oder saber se
Arte
admissão de
undo trabalh
da numa esta
chamada e d
para chamad
os de custos
ões de perd
e a essas perd
e gráfico m
a chamada,
uma selecçã
oderá haver
ito má, ao m
riam as que
esta forma d
ue apenas p
ém relativam
chamadas.
m do inconve
e poderia efe
Figura 2.
chamadas
ho é aborda
atística de p
decidir a adm
das VoIP é um
é bom. Base
das de paco
das.
mostra a rela
que como s
ão na admis
r. Assim, gar
mesmo temp
já estavam
de admissão
previne cham
mente aos a
eniente do u
ectuar a cha
23 - H323 Bea
da uma form
redição, isto
missão basea
ma solução q
eia-se apenas
otes para se
ação entre a
se pode ver
ssão nas ch
rante em pa
po não está
a decorrer.
o é que é mu
madas muito
atrasos e às
utilizador te
amada [20].
acon opções [1
ma de obter
o é, baseado
ado nesses v
que não nece
s num teste
e perceber
a perda de
r tem valore
amadas dep
arte que não
a sobrecarre
uito limitativ
o desastrosa
suas variaç
r que esper
19].
r a qualidade
o em certos
valores. Port
essita de alt
em que por
como irá d
pacotes du
es bastante
pendendo do
o possam de
egar a rede
va pois só se
as. Seria por
ções pois tam
rar os tais 4
e de serviço
parâmetros
tanto, esta f
terar nada na
poucos segu
decorrer a
rante 10s a
aceitáveis.
o valor esti
ecorrer cham
com essas c
e baseia na
r isso neces
mbém influe
a 10 segun
o de uma
instantes
forma de
a rede, o
undos são
chamada
antes e a
É então
mado de
madas de
chamadas
perda de
sário um
enciam a
ndos para
An
ef
av
re
da
pa
pa
re
em
de
sid
in
De
nálise de qu
Agora vai
fectuar med
valiadas as m
Os testes
eceptor, mai
a América do
Não foi ut
acotes RTP d
ara se obter
Os resulta
esultados for
m 1999, tend
Foi també
e não ter sid
do efectuad
fluência rele
esenvolvime
Figura 2.24
ualidade de s
ser aprese
dições de qu
métricas de p
foram efec
s concretam
o Sul.
tilizado nenh
de dados, os
uma melhor
ados como se
ram também
do sido melh
m analisado
do contabiliz
as de forma
evante nos re
F
ento de soft
4 - Relação ent
serviço
ntado um t
ualidade de
perda, atraso
ctuados com
mente em alg
hum protoco
dados são p
r comparação
eriam de es
utilizados p
ores com um
o impacto d
zada a influ
a activa, lim
esultados [2
Figura 2.25 - D
tware VoIP
tre a predição
trabalho rea
serviço par
o e jitter dos
sessões qu
guns estados
lo de sinaliz
pré gravados
o.
perar foram
para uma com
ma redução b
do tamanho d
ência do pro
mita os resu
1].
Diferenças de
o e a real perd
alizado em 2
ra sessões d
s pacotes.
e tiveram v
dos EUA, al
zação, ou sej
de forma a
m mais anima
mparação co
bastante sign
dos pacotes
otocolo de s
ltados pois
QoS 1999 e 20
31|2.2 Tr
da de pacotes
2002, que t
de voz sobr
várias localiz
guns países
ja, apenas fo
ser enviada
adores nos E
om as mesma
nificativa (ve
na qualidad
sinalização e
são dois asp
002 [21].
rabalhos rela
s [20].
teve como o
re a rede IP
zações do e
da Europa e
oram transm
a mesma inf
EUA e na Eu
as medições
er Figura 2.2
e de serviço
e das medid
pectos que t
acionados
objectivo
P. Foram
emissor e
e também
mitidos os
formação
uropa. Os
retiradas
25).
o. O facto
as terem
têm uma
32|Estado da Arte
Foi um projecto que tinha como objectivos explicar a arquitectura dos vários protocolos
envolvidos no transporte da voz sobre IP, e no desenvolvimento de um telefone capaz de
efectuar sessões VVoIP (Video Voice over IP), a ferramenta a desenvolver foi designada de
SIPtel.
Foram utilizados os protocolos SIP para a sinalização, RTP/RTCP para o transporte, e tem
a possibilidade de usar vários codecs.
Foram implementadas as opções de chamadas em espera, e a possibilidade de iniciar uma
sessão com voz ou voz e vídeo em conjunto. Na implementação do software foi utilizada a
linguagem computacional Java, tendo existido a recorrência a duas APIs de código aberto.
No final houve alguns problemas com a interoperabilidade com outros softwares com
sinalização SIP.
Como trabalho futuro era recomendável desenvolver meios de detecção de QoS
individualizados para cada contacto [22].
Voice over IP - IEEE Potentials
Neste paper são feitas breves análises à rede IP, ao conceito de VoIP, e aos protocolos de
sinalização H323 e SIP. O objectivo é explicar estes conceitos de forma a se entender a
necessidade que existe de nas aplicações em tempo real ter em conta os níveis de QoS e dos
problemas que estão inerentes.
São também analisadas as diferenças entre os débitos dos diferentes codecs e a sua
influência no QoS das redes.
Há referência à diferença das redes serem ou não por fios, no que respeita à Qualidade de
Serviço, sendo que sem fios requer mais cuidados.
As métricas mais focadas são perda, atraso e diferença entre os atrasos dos pacotes.
Os valores que são apontados como limites para se ter QoS para VoIP são:
Perda de pacotes: A partir de 10% de perdas é intolerável.
Atraso: Até 200ms é tolerável.
Jitter: Não está definido nenhum valor específico, apenas é referida a solução do jitter
buffer para atenuar/eliminar o jitter existente [78].
On the influence of best-effort network conditions on the perceived speech quality of
VoIP connections
Neste trabalho foi efectuado um estudo acerca das diferenças entre os vários codecs,
nomeadamente dos seus valores de perdas e diferenças entre os atrasos [79].
33|2.2 Trabalhos relacionados
A forma utilizada para quantificar os níveis de QoS, para permitir ter a noção da realidade da
qualidade, foi utilizando os níveis MOS (Mean Opinion Score). A arquitectura utilizada para
teste foi a seguinte:
Figura 2.26 - Cenário de teste [79].
Vejamos, inicialmente é enviado um sinal de voz de uma máquina para outra, passando por
outra, que simplesmente faz o reencaminhamento do sinal, mas com as métricas a poderem
ser manipuladas conforme se pretenda. Após esta manipulação pode-se comparar os sinais de
origem e de destino utilizando o software DSLA (Digital Speech Level Analyser), que permite
analisar as diferenças e estabelecer a relação com a qualidade do sinal perceptível com o
ouvido humano. Essa classificação é denominada de MOS, que é constituinte por cinco
diferentes níveis de qualidade.
Figura 2.27 - Classificação MOS [79].
Neste gráfico é possível observar a qualidade segundo o critério MOS dos variados codecs
utilizados. Em que o melhor é PCM com 4.0 de classificação o que é excelente.
34|Estado da Arte
Figura 2.28 - Classificação MOS dos codecs [79].
Os seguintes gráficos apresentam os resultados dos testes efectuados que relacionam a
classificação MOS com a percentagem de perda de pacotes para os diferentes codecs.
Figura 2.29 - Relação MOS com % perdas [79].
Estes gráficos apresentam a relação entre a classificação MOS, a percentagem de pacotes
perdidos mas desta vez variando o tamanho dos pacotes codificados.
35|2.2 Trabalhos relacionados
Figura 2.30 - Relação MOS e % perda, variando o tamanho dos pacotes [79].
Por último é apresentada a relação entre a percentagem de perda com o jitter.
Figura 2.31 - Relação entre % perda com jitter [79].
Na figura pode-se verificar que aumenta o jitter com o aumento da perda, no entanto não
é de forma linear, o que era esperado.
36|Estado da Arte
37|3.1 Introdução
Capítulo 3
Ferramentas
3.1 Introdução
Este capítulo faz referência a ferramentas úteis à dissertação. Foi elaborada uma pesquisa
e uma lista de ferramentas e software que permitiu uma escolha consciente de quais a
utilizar.
3.2 Ferramentas de medidas Activas
Pathchirp
Pathchirp é uma ferramenta de medidas activas, pois induz tráfego na rede para obter a
largura de banda disponível durante uma ligação numa rede de comunicação.
O funcionamento desta ferramenta está descrito na figura 3.1, basicamente o emissor
envio tráfego com um formato próprio designado chirp, em que vai enviando e diminuindo o
tempo entre o envio dos chirps de forma exponencial até atingir o ponto de saturação do
canal obtendo assim o valor máximo de largura de banda [23].
38
ST
la
se
en
Pa
la
ar
Pa
la
ca
8|Ferrament
TAB
Esta é um
rgura de ban
eu valor. Est
nvio de chirp
athneck
É outra fe
rgura de ba
rtificialment
athrate
Esta é uma
rgura de ba
anal relativa
tas
ma ferrament
nda disponív
a ferrament
ps [24].
erramenta pa
nda é meno
e na rede [2
a ferramenta
anda. O path
mente à larg
Fig
ta que tem
vel é menor (
ta é mais co
F
ara localizar
or. A métrica
5].
a que compl
hrate mede
gura de band
ura 3.1 - Path
a capacidad
(engarrafam
mplexa que
Figura 3.2 - ST
r os bottlene
a é obtida d
lementa o Pa
a capacidad
da.
hchirp [23].
de de desco
entos do can
pathchirp e
TAB [24].
ecks isto é os
de forma act
athload, pois
de e o path
obrir a locali
nal), e tamb
embora tamb
s locais em
tiva pois uti
s há duas for
hload mede
ização do nó
ém consegue
bém seja ba
que a capac
liza tráfego
rmas de med
a disponibil
ó onde a
e obter o
seada no
cidade de
induzido
dições de
idade do
39|3.2 Ferramentas de medidas Activas
O pathrate mede a capacidade do canal, ou seja, obtém o valor máximo de largura de
banda que o canal tem disponível tendo em conta que não há tráfego naquele momento [26].
Pathload
Como já foi referido é utilizado para calcular a disponibilidade da largura de banda do
canal, quer isto dizer que é o valor que o canal ainda pode fornecer até atingir o valor
máximo que corresponde à sua capacidade [27].
Pathchar
Pathchar é uma ferramenta para estimar várias métricas ao longo de um caminho na rede
IP. Foi desenvolvido por Van Jacobon, e permite ao utilizador ter acesso a informações de
largura de banda, atrasos, tempo de espera médio nos buffers e as perdas em cada nó
pertencente caminho origem – destino na rede [28].
Fping
Fping é uma ferramenta que utiliza o protocolo ICMP (Internet Control Message Protocol)
para descobrir o estado de uma máquina, ou seja, se está presente na rede ou não e o tempo
de ida e volta entre o destinatário e o destino que um pacote demora. A diferença entre fping
e o ping convencional é que consegue enviar pacotes ICMP para vários hosts em simultâneo
[29].
Traceroute
Esta ferramenta permite saber o trajecto do tráfego até ao seu destino, e o atraso para
cada máquina interveniente na operação.
O número máximo de nós porque pode passar é definido pelo TTL (Time to Live).
Freeping
É uma ferramenta similar ao ping convencional, mas com melhoramentos quer a nível de
apresentação pois tem interface gráfica, quer a um maior número de funcionalidades tais
como alertas, se algum equipamento falhar a sua conexão, pingar várias máquinas em
simultâneo e uma série de estatísticas de métricas.
Tem ainda a vantagem de ser de fácil instalação e poder funcionar em Windows [30].
SmokePing
Permite medir o tempo de resposta, distribuição do tempo de resposta e a perda de
pacotes.
As estatísticas são apresentadas através de imagens gráficas. Uma vantagem desta
ferramenta é que as configurações são feitas num arquivo config.
40|Ferramentas
Mgen
MGEN (Multi-Generator) é um software de código livre desenvolvido pela NRL (Naval
Researh Laboratory) [31].
Esta ferramenta permite obter métricas tais como: perda de pacotes, atrasos e jitter.
O tráfego que pode ser analisado é UDP/IP (TCP ainda está em desenvolvimento). É uma
ferramenta que permite obter informações do estado da rede de forma activa.
O princípio utilizado por este software consiste em injectar tráfego inútil à rede e analisar
o comportamento da rede com esses pacotes.
Vejamos a seguinte figura.
Figura 3.3 - Exemplo do funcionamento do MGEN
Como podemos observar, em ambos os utilizadores da rede está a funcionar o MGEN
embora um esteja configurado como emissor e o outro como receptor.
Os pacotes enviados pelo Utilizador A levam a informação do tempo em que foram
realmente enviados, um número de sequência tendo em conta o fluxo a que pertencem, os
endereços IP de destino e origem e a caracterização do tráfego enviado. Os dados antes de
chegarem ao seu destino passam por uma série de dispositivos que influenciam o seu tempo
de propagação. Quando os pacotes chegam ao Utilizador B o software recebe e trata a
informação contida neles, guardando o instante em que os recebeu. Após ter todos estes
dados e fazendo uns simples cálculos obtém-se as métricas desejadas que caracterizam a rede
que separa ambos os utilizadores.
Esta ferramenta também tem a vantagem de controlar o tráfego que se envia
relativamente ao tamanho e à frequência dos pacotes, sendo apenas UDP e suporta
endereçamento IPV4 e IPV6. Suporta diversas funcionalidades que são configuradas por uma
série de comandos, no entanto apenas serão analisados em pormenor os utilizados.
Esta foi a ferramenta escolhida para o cálculo das métricas porque é bastante funcional,
com muita informação, é de instalação e utilização bastante simples, com vários comandos
capazes de modelar o tráfego gerado.
Portanto, ao utilizar este software garantimos fiabilidade, simplicidade e uma enorme
capacidade de manuseamento para modelar a rede, de forma a poder fazer os testes de modo
a atingir o melhor resultado final possível.
M
fe
gr
fig
Ip
co
(v
H
ef
ar
lin
N
lig
ca
5
O
co
as
de
MRTG
MRTG foi d
erramenta é
ráfico com o
Gráfico pr
gura 3.4:
perf
Iperf é um
omo UDP. Co
variação do a
.323 Beac
Esta é uma
fectuar med
rquitectura d
nguagem de
etQoS
Software p
gações, tais
aracterização
[35].
WAMP
One-Way A
omunicação e
ssim medir o
e forma activ
desenvolvido
capaz de m
tráfego que
roduzido pe
m software
om esta fer
atraso) e per
con
a ferramenta
ições, moni
de Cliente/S
programaçã
para monito
s como: nú
o da qualida
Active Measu
entre as máq
o atraso unila
va [36].
o em perl, fu
monitorizar
e por lá passa
lo MRTG na
F
Cliente/Serv
rramenta é p
rdas [33].
a unicament
torizar e qu
ervidor, util
o C/C++ [34]
rizar a perfo
úmero de c
ade baseada
urement Pro
quinas de te
ateral e aind
unciona nos
routers ou o
a [32].
a monitoriza
Figura 3.4 - MR
vidor para m
possível efec
te a pensar n
ualificar um
iza as biblio
].
ormance de
chamadas, m
na qualifica
otocol é uma
este, que imp
da a perda de
41|3.2
ambientes U
outro tipo d
ação de um
RTG [32].
medições ac
ctuar mediç
no protocolo
a sessão de
tecas open H
ligações VoI
minutos efe
ação segundo
proposta de
plementem a
e pacotes un
Ferramenta
UNIX/LINUX e
de dispositiv
router conf
ctivas, utiliz
ções de larg
o de sinalizaç
e vídeo-confe
H323 e foi co
IP, fornece i
ectuados, a
o MOS, que a
e protocolo a
as métricas u
nilateral. As
as de medida
e é de uso li
vo de rede e
forme exem
za tanto tráf
ura de band
ção H323. É
erência. Uti
oncebido uti
informações
atraso na v
abrange nota
a fim de pad
unidireccion
métricas são
as Activas
ivre. Esta
e faz um
mplifica a
fego TCP
da, jitter
capaz de
iliza uma
lizando a
sobre as
voz, e a
as de 1 a
dronizar a
ais. Pode
o obtidas
42|Ferramentas
tcpdump
É uma ferramenta para monitorizar tráfego numa rede IP, foi criado por Van Jacobson, e
funciona com sistemas operativos Unix.
Para Windows há uma outra ferramenta equivalente designada de Windump. Permite
interceptar e visualizar o tráfego que passe na rede, ao instalar este software nos respectivos
dispositivos em que se pretenda a monitorização, nomeadamente o tráfego não encriptado
[37], [38].
3.3 Ferramentas de medidas Passivas
TcpStat
É uma ferramenta que utiliza o método passivo para captar métricas que caracterizem a
qualidade de serviço de uma rede IP.
Fornece estatísticas extraídas de uma interface de rede ou de um arquivo criado pelo
tcpdump/libcap. As métricas reportadas por essa ferramenta dizem respeito à largura de
banda utilizada, número de pacotes por segundo e o tamanho médio dos pacotes [39].
TStat
O Tstat é também uma ferramenta de medidas passivas, é semelhante ao tcpstat que
além de reportar as métricas citadas acima possui ainda um analisador de fluxos de tráfego
TCP [40].
NTOP
NTOP é baseado na libcap, foi criada para ter compatibilidade com as plataformas UNIX e
Win32. Os utilizadores têm acesso a uma web browser para aceder as funcionalidades do
software. Tem ainda a vantagem de usar poucos recursos a nível de memória.
O NTOP trabalha no nível IP e é capaz de caracterizar o tráfego por endereço IP,
protocolo [41].
QoSMeT
É uma ferramenta para efectuar medições passivas de qualidade de serviço de aplicações
em redes IP. Embora todas as aplicações possam ser monitorizadas por esta ferramenta, as de
tempo real (p.e. VoIP, video conferência…) são as que melhores resultados obtêm.
As principais métricas efectuadas são: atrasos, jitter, perdas, o tempo de quebra de
conexão, número de pacotes e o volume de dados enviados/recebidos. Pode ainda efectuar as
medições apenas num sentido e não baseado nos tempos de ida e volta [42-44].
3.4 Outras ferramentas
43|
TRPR
TRPR (“Trace Plot Real-time”) é uma ferramenta que é utilizada para fazer o parsing dos
ficheiros texto gerados pelos programas MGEN ou tcpdump para poderem ser utilizados pelo
gnuplot de forma a apresentar os resultados sob forma gráfica até mesmo em tempo-real
[45].
Gnuplot
É uma ferramenta de grande utilidade para apresentação de dados estatísticos sob a
forma gráfica, permitindo o uso desta ferramenta para complementar outros softwares tais
como MGEN na apresentação de resultados.
Abrange a utilização dos seguintes formatos: eps, fig, jpeg, LaTeX, metafont, pbm, pdf,
png, postscript, svg… Tem também a vantagem de ser funcional em diversos sistemas
operativos tais como Windows, Unix, Linux, DOS [46].
3.5 Componentes VoIP
O VoIP está numa fase de enorme expansão, cada vez existe um maior número de
componentes livres. Estão a aparecer constantemente novas aplicações de Clientes,
Servidores, interfaces, bibliotecas e hardware para o VoIP, na grande maioria utilizam o
protocolo de sinalização SIP [47-64].
Tabela 3.1 - Servidores VoIP
Componente Nome Sistema Operativo Protocolo de
Sinalização
Servidores
Sip Express
Router (ser)
BSD, Linux, SunOS/Solaris SIP
Sippy Windows SIP
Openser Unix/Linux SIP
Ser Media Server
(sems)
BSD, Linux, SunOS/Solaris SIP
Asterisk Linux, Mac OS X, OpenBSD, FreeBSD e
Sun Solaris
SIP/H323
Callweaver Linux, FreeBSD, NetBSD, OpenBSD,
MacOS X/Darwin, Open/Solaris
H.323
Partysip Unix., BSD, Win32, Linux SIP
44|Ferramentas
Tabela 3.2 - Bibliotecas VoIP.
Componente Nome Linguagem de
programação
Sistema
Operativo
Protocolo de
Sinalização
Bibliotecas
Libmsip C/C++ Linux SIP
OpenH323 C/C++ Windows H323
ooh323c C/C++ Windows, Linux H323
sofia-sip C Windows, Linux,
OSX
SIP
PJSIP C Windows, Linux e
MacOS
SIP
OpenSipStack C Windows, Linux SIP
Tabela 3.3 - Clientes VoIP.
Componente Nome Linguagem de
programação
Sistema
Operativo
Protocolo de
Sinalização
Clientes
sipXezPhone Java Windows SIP
Ekiga C Linux SIP e H323
SIP-
communicator
Java Windows SIP
wxCommunicator C/C++ (wxWidgets) Windows SIP
x-lite C/C++ Mac OS e
Windows
SIP
SFLphone C/C++ (Bibliotecas cc++,
ccRTP, osip2+eXosip)
Linux SIP
SIPek Phone C, C# (Bibliotecas pjsip
SIP)
Windows SIP
SIPek2 Phone C, C# (Bibliotecas pjsip
SIP)
Windows SIP
3.5.1 Servidores VoIP
Para utilização como servidor VoIP para a execução de testes neste trabalho foi escolhido
o Asterisk.
Outra forte possibilidade era o OpenSER, no entanto para o objectivo pretendido o
Asterisk era mais que suficiente.
45|3.5 Componentes VoIP
E como o mais importante do trabalho não era o estudo dos servidores, optou-se apenas
por um, desde que fosse suficiente para a execução dos testes.
A escolha recaiu sobre o Asterisk porque entre os dois este é o mais completo e
possivelmente pode vir a ser útil o conhecimento adquirido desta experiência.
No entanto, foram analisados ambos os servidores em pormenor.
3.5.1.1 Asterisk
Asterisk é conhecido pelo símbolo asterisco (*), é um software de PABX open-source que
recebe contribuições de programadores de todo o mundo e que está disponível gratuitamente
[65].
Digium é a empresa que iniciou o desenvolvimento do Asterisk e que actualmente ainda o
promove tal como o hardware de baixo custo que lhe é compatível. Mark Spencer é o criador
e o principal responsável pela manutenção e gestão.
O Asterisk apenas é compatível com o sistema operativo Linux.
Resumindo, para se ter a noção do poder deste software, que nos permite fazer de um
simples PC uma poderosa central telefónica multi-protocolo.
Uma das grandes vantagens do Asterisk incide no facto de permitir conectividade em
tempo real entre a rede telefónica pública designada de Public Switched Telephony Network
(PSTN).
Com o Asterisk pode-se fazer imensas aplicações em que o limite imposto é a imaginação
e a criatividade de quem faz a devida configuração.
Alguns exemplos de aplicações que superam os designados PABX padrão são:
-Permitir conectividade entre colaboradores que trabalham a partir de casa com o PABX do
escritório sobre ligações de banda larga;
- Permitir a comunicação entre uma rede de escritórios separados geograficamente;
- Possibilidade de oferecer aos funcionários de uma empresa correio de voz, integrado com a
Web e e-mail;
- Construir aplicações de atendimento automático de voz, que pode reencaminhar para um
sistema de pedidos;
O Asterisk promove também um conjunto de recursos desde:
- Música em espera para clientes, com suporte a streaming de media, bem como música em
formato MP3;
- Integração com softwares para a sintetização da fala (text to speech);
- Registo detalhado de chamadas (call detail records) para integração com sistemas de tarifa
e bancos de dados SQL;
- Integração com reconhecimento de voz (automatic speech recognition).
Codecs suportados pelo Asterisk:
- G.711 ulaw (usado nos EUA) – (64 Kbps);
46|Ferramentas
- G.711 alaw (usado na Europa e no Brasil) – (64 Kbps);
- G.723.1 – Modo Pass-through;
- G.726 - 32kbps no Asterisk 1.0.3, 16/24/32/40kbps;
- G.729 – Precisa de licença, a menos que esteja usando o modo Pass-through.(8Kbps);
- GSM – (12-13 Kbps);
- iLBC – (15 Kbps);
- LPC10 - (2.5 Kbps);
- Speex - (2.15-44.2 Kbps).
Protocolos de iniciação de sessão que o Asterisk suporta:
-SIP
- H323
- IAXv1 e v2
- MGCP
- SCCP (Cisco Skinny)
- Nortel unistim
Diferenças entre o velho e o novo mundo
Para ser óbvia a utilidade do Asterisk, seguem duas figuras que mostram claramente uma
centralização de recursos tornando também o custo mais apetecível.
Figura3.5 - Sistema recurso ao velho modelo de PABX/Softswitch [65].
47|3.5 Componentes VoIP
Figura3.6 - Arquitectura com recurso ao Asterisk [65].
3.5.1.2 OpenSER
O OpenSER é um servidor de voz sobre IP gratuito baseado no protocolo SIP (Session
Initiated Protocol, RFC3261).
Este software suporta as funcionalidades de “Registar”(servidor de registo), SIP Proxy e
SIP Redirect Mode(redirecionamento) [66].
Tal como o asterisk, o OpenSER também não é compativel com windows.
As principais características que fazem deste software um dos mais utilizados em
aplicações VoIP são:
- Velocidade: relativamente à velocidade de processamento de chamadas é uma ferramenta
poderosa, pois consegue satisfazer milhares de chamadas por segundo mesmo em plataformas
de baixo custo. Obteve-se esta característica à custa de uma optimização do código em ANSI
C combinado com instruções em Assembler, e claro utilizando o SIP que é um protocolo
bastante simples.
- Flexibilidade: ferramenta bastante interessante sobre este aspecto, permite com certa
facilidade, através da criação e execução de scripts em texto, determinar o seu
funcionamento nomeadamente ao nível do roteamento SIP.
- Possibilidade de crescimento: o OpenSER pode facilmente ser dotado de novas
funcionalidades bastando para isso novos códigos em C, que podem ser desenvolvidos
independentemente do núcleo do software.
- Interoperabilidade: tem como base o protocolo SIP, o que garante a interoperabilidade
entre várias aplicações desde que suportem o mesmo protocolo.
48|Ferramentas
- Tamanho: o núcleo do OpenSER tem um tamanho de apenas cerca de 300k, com alguns
módulos adicionais pode chegar aos 630K, sendo assim, considerado um software apetecível
até no tamanho.
Para se notar a importância e o poder desta ferramenta, um exemplo de uma aplicação
em que se utiliza o OpenSER, é na implementação VoIP entre universidades, como são
exemplo Columbia e o MIT [67].
Este tipo de software, para instalação e posterior execução, necessita de alguns ficheiros
de configuração, que sejam editados de forma correcta de modo a executar o que cada um
pretende. No OpenSER em concreto, embora não seja único mas sem dúvida o mais
importante ficheiro de configuração é designado por openser.cfg. Este ficheiro é responsável
pelo controle dos módulos que são utilizados e a configuração dos mesmos.
Figura 3.7 - Ficheiro de configuração do OpenSER.
49|3.5 Componentes VoIP
3.5.1.3 Asterisk vs OpenSER
A primeira tentação quando se fala em servidores VoIP é investigar o Asterisk e OpenSER
pois são os mais utilizados open-source. No entanto, não se deve ter esse ponto de vista, uma
vez que, o mais correcto será implementar um sistema que inclua ambos. Digamos que não se
devem comparar, pois foram implementados para diferentes funcionalidades, em que juntos
complementam-se na perfeição. Para se entender, o melhor é dar alguns exemplos concretos
de aplicações e algumas das suas limitações [65].
O uso exclusivo do OpenSER não é muito funcional, é demasiado limitativo. Embora,
quando funciona em conjunto com o Asterisk torna-se um sistema VoIP bastante poderoso.
OpenSER apenas reconhece e trata das mensagens SIP, de forma a obter informações de
endereços IP, codecs, portas, etc. No entanto, não trata das mensagens RTP, que são as
responsáveis do envio efectivo do som.
O Asterisk já suporta as mensagens RTP, o que faz dele uma ferramenta mais valiosa com
maior variedade de funcionalidades. É capaz de atendimento automático personalizado, caixa
de correio com mensagem de voz, etc.
Outra das grandes vantagens do Asterisk passa pela capacidade de ligação entre chamadas
em diferentes redes, mais concretamente chamadas em telefones convencionais na rede
PSTN, VoIP rede IP.
O Asterisk suporta mais protocolos de inicialização do que o OpenSER.
Uma questão que é colocada variadas vezes é: o Asterisk é capaz de fazer tudo sozinho? A
resposta é sim, mas a questão não deveria ser essa, mas se será a melhor solução e nesse caso
a resposta seria não.
Em caso de vários utilizadores recorrerem ao Asterisk em simultâneo, não é um software
muito fiável pois é mais lento que o OpenSER, nesse aspecto. Quando se implementa um
servidor VoIP para inúmeros utilizadores, em princípio, tem que se esperar centenas de
ligações em simultâneo, o que não é compatível com apenas o Asterisk, mas sim com os dois
de forma a permitir o OpenSER trate das mensagens SIP enquanto o Asterisk trata das
mensagens RTP.
A conclusão que se pode tirar é que cada software é melhor e mais eficaz no que é
especialista, logo há que aproveitar o que de melhor têm, daí que se aconselhe o recurso aos
dois em simultâneo.
3.5.2 Cliente VoIP
O cliente VoIP escolhido para ser utilizado neste trabalho foi o Ekiga. Este foi o escolhido
porque interessava um cliente que fosse bastante utilizado, para obter uma maior utilidade a
um maior número de pessoas e como este já vem instalado no Ubuntu promove uma maior
utilização.
50|
O outro grande motivo desta escolha foi o facto de neste cliente já haver uma abordagem
à qualidade de serviço das chamadas, embora esta seja obtida de forma passiva, ao contrário
da que foi implementada.
Outros motivos, embora mais secundários, foram uma interface agradável e de fácil
configuração, é um projecto que não está parado, ou seja, estão a ser feitas novas versões.
3.5.3 Ekiga
Ekiga é um VoIP softphone, é open-source e já vem instalado, por exemplo, no Ubuntu.
Inicialmente, era conhecido por GnomeMeeting. O serviço é gratuito, pode-se também usar o
servidor existente no Ekiga, desde que se proceda ao registo do utilizador ([email protected]),
ou então pode-se registar em qualquer outro [69], [71-72].
Esta foi a primeira aplicação open-source que suporta vídeo e áudio em simultâneo e
como protocolos de sessão suporta SIP e H323. Já existe uma versão beta do Ekiga para
Windows.
Principais características do Ekiga:
Para SIP:
-Suporta o protocolo SIP, sendo por isso compatível com todas as outras aplicações que
também suportem o mesmo protocolo;
- Possibilidade de registo simultâneo em mais que uma conta;
- Pode-se pôr uma chamada em pausa/espera e retornar mais tarde;
- Suporta desvio da chamada de um utilizador para outro;
- Suporta transferência de chamada em caso de o cliente estar ocupado, não atender ou
sempre para outro SIP URI (Uniform Resource Identifiers) previamente definido;
- Suporta Proxy.
- Possibilidade de envio de mensagens instantâneas;
-Os codecs suportados são: iLBC, GSM-06.10, MS-GSM, G.711-Alaw, G.711-uLaw, G.726, G.721
e Speex Audio Codecs;
- Jitter Buffer configurável;
- Cancelamento de eco;
- Limite automático da largura de banda utilizada pelo vídeo;
- Controlo do vídeo e som.
51|4.1- Introdução
Capítulo 4
Definição de requisitos e especificação
4.1- Introdução Neste capítulo faz-se um levantamento da arquitectura utilizada para o funcionamento do
VoIP, a interligação dos diferentes componentes que a compõe e ainda uma ligeira abordagem
ao funcionamento do Ekiga com a nova funcionalidade implementada.
4.2- Cenário de comunicação VoIP
O sistema implementado baseia-se na comunicação por VoIP entre dois quaisquer clientes
que suportem SIP através de um servidor Asterisk. Esta arquitectura tem como objectivo
permitir efectuar chamadas para tornar possível fazer os diversos testes e obter a informação
sobre a qualidade das chamadas.
Para se perceber correctamente a função e a forma como estão integrados os
componentes VoIP que foram utilizados, segue uma imagem representativa de uma chamada
entre dois clientes SIP. Neste caso ambos os utilizadores estão a usar o software Ekiga [76].
52|Definição de requisitos e especificação
Figura 4.1 - Chamada efectuada entre dois softphones Ekiga.
Utilizando a figura 4.1 podemos facilmente analisar como o protocolo SIP se comporta
entre os clientes Ekiga e o servidor Asterisk.
Pode-se considerar que o estabelecimento de uma chamada pode ser dividido em quatro
fases.
Numa primeira fase é necessário um registo no servidor por todos os clientes que o
queiram utilizar como proxy. Daí o envio da mensagem Register por ambos os utilizadores
para o Asterisk. Neste caso exemplificado o identificador do utilizador e a sua palavra-chave
estavam correctos em ambos os clientes razão pela qual receberam um resposta OK. A partir
desse momento já podiam usufruir do servidor porque já se encontravam registados.
A segunda fase é o estabelecimento da chamada, no caso em concreto a chamada foi
efectuada pelo Utilizador 1 e tinha como destino o Utilizador 2. A mensagem a ser enviada
53|4.3- Requisitos da aplicação de medidas
para notificar o destino da existência de uma chamada é um INVITE. É de notar que todas as
mensagens de inicio de sessão, isto é antes de se iniciar a troca de efectiva de dados passam
pelo proxy. No instante em que o Utilizador 2 recebe a notificação do INVITE responde com
RINGING, que serve para informar o Utilizador 1 que o telefone está a chamar.
No momento em que o Utilizador 2 atende a chamada, é enviada uma mensagem OK para o
Utilizador 1, para avisar o início da conversação. O Utilizador 1 envia então a mensagem ACK,
mas agora sem passar pelo proxy, ou seja directamente para o destino para evitar o
desperdício de recursos por parte do servidor. Esta mensagem serve para se proceder à
conversação.
A terceira fase corresponde à conversação entre as partes envolvidas, ou seja à troca de
pacotes RTP que são os responsáveis pelo envio da voz.
A última etapa serve para o envio da mensagem para avisar o fim da chamada por uma
das partes.
4.3- Requisitos da aplicação de medidas
O principal requisito a cumprir da aplicação que se pretende implementar passa por
conseguir prever a qualidade de chamada para qualquer um dos contactos presentes na lista
de um utilizador.
Portanto a ideia é fazer testes em alguns momentos do dia, ou seja ter um horário
concreto para fazê-los. Os testes serão executados para todos os contactos da lista do
softphone Ekiga em causa.
Para ser possível quantificar a qualidade de chamada precisamos de calcular métricas
acerca do comportamento da rede. As métricas mais características são as perdas, o atraso e
a diferença entre atrasos dos pacotes. Para se obter estas métricas é necessária a integração
de uma ferramenta capaz de gerar tráfego na rede e daí obter os devidos resultados. A
ferramenta escolhida foi o MGEN.
Duas das questões a resolver são a sincronização dos relógios e a necessidade da obtenção
dos endereços IP das máquinas intervenientes nos testes.
Para a sincronização dos relógios utiliza-se o protocolo NTP (Network Time Protocol).
Relativamente aos endereços IP, como à partida não são predefinidos é necessário obtê-
los em cada caso particular. No entanto como foi visível na figura descritiva de uma chamada,
apenas quando se processa o início efectivo da conversação é que se obtém o IP, por isso há
necessidade de fazer uma chamada teste de uma duração mínima.
Segue agora uma imagem para ajudar a clarificar o que se pretende.
54|Definição de requisitos e especificação
Figura 4.2 - Interligação entre dois Ekigas durante um teste.
Nesta figura está representado um simples esquema que demonstra o funcionamento e as
principais fases do processo até se atingir o objectivo pretendido.
Como já foi referido anteriormente inicialmente é necessário fazer uma chamada teste
para se obter o endereço IP pretendido. Após se obter o endereço já se tem todos os dados
necessários que permitem fazer a configuração do MGEN que é a ferramenta que
efectivamente faz as medições para a obtenção das métricas que permitem quantificar o
nível de qualidade da chamada.
O funcionamento do MGEN baseia-se no envio de tráfego entre os clientes envolvidos no
teste e posterior análise do comportamento dos pacotes, daí o envio exemplificado na figura
e a consequente análise.
4.4- Especificação da arquitectura
Já fizemos uma breve introdução ao funcionamento dos testes entre diferentes clientes
que suportam a implementação de QoS, falta agora analisar o comportamento do Ekiga e a
interligação com as funções que foram implementadas durante a execução de um teste.
Mais uma vez recorre-se a uma figura de forma a facilitar a captação do conceito que se
pretende exemplificar.
55|
Figura 4.3 - Interligação do Ekiga com a nova funcionalidade implementada.
Na figura está representada a forma como o Ekiga tanto se relaciona com a biblioteca SIP
que utiliza, como com a sua nova funcionalidade implementada neste trabalho.
Os números representados significam a ordem pelas quais as etapas são efectuadas.
Os testes são efectuados para cada contacto, daí que a primeira etapa a realizar é obter
do Ekiga os contactos pertencentes à lista do utilizador. É também necessário obter os
endereços IP para cada contacto, para isso faz-se uma chamada teste para cada contacto com
uma duração pequena de forma a ter o mínimo de intrusão no funcionamento normal do
Ekiga.
O Ekiga para suportar o protocolo SIP para efectuar as chamadas VoIP recorre a uma
biblioteca SIP/H323 designada Opal. Esta biblioteca trata das mensagens SIP, e RTP por isso
na figura está representada a recorrência do Ekiga à Opal no momento de efectuar a chamada
teste.
Como o IP é obtido através da sinalização, o programa implementado vai directamente
obter o endereço pretendido na biblioteca Opal como está representado na etapa 4.
Depois de ter então as informações necessárias para o funcionamento correcto do MGEN,
procede-se a todo um processo que é feito paralelamente ao telefone VoIP.
Finalmente após terem sido obtidos todos os testes é necessário um último acesso à classe
Gmcontacts (classe responsável pelos contactos) para se proceder à actualização do nível de
qualidade de chamada.
56|
57|5.1- Introdução
Capítulo 5
Desenvolvimento e integração
5.1- Introdução
Esta é uma das fases mais importantes do projecto, pois é aqui que o projecto “ganha
vida” ou seja é implementado. Pretende-se demonstrar todo o trabalho que realmente foi
realizado com exemplificação desde as configurações da arquitectura da rede até ao código
implementado. O objectivo é apresentar as etapas com a devida cronologia com que foram
realizadas.
5.2- Fluxograma demonstrativo do funcionamento Este fluxograma apresenta em maior detalhe o funcionamento do código implementado,
tendo representado todos os passos importantes até se atingir o objectivo pretendido.
58|Desenvolvimento e integração
Figura5.1 - Fluxograma demonstrativo do funcionamento do trabalho implementado.
59|5.2- Fluxograma demonstrativo do funcionamento
No fluxograma está representado o ciclo de funções que são executadas para a obtenção
dos testes activos que permitem calcular as métricas e a sua posterior conversão num valor
representativo de QoS para cada contacto.
A aplicação foi feita de modo a ser executada em paralelo com o Ekiga e da forma menos
intrusiva possível e independente do comportamento habitual do programa. Para isso foi
necessária a criação de uma “thread” aquando do arranque do Ekiga.
Os testes estão programados para decorrerem em horas previamente definidas.
Quando o teste é iniciado, é necessário obter os IPs dos clientes que pertencem à lista de
contactos da aplicação em causa. A troca das mensagens SIP é feita entre os clientes e o
servidor (neste caso Asterisk), apenas quando há troca de pacotes RTP ou seja quando se
procede ao inicio da conversação a troca é feita directamente entre as partes envolvidas. Daí
que apenas nesse momento é enviado o endereço do IP do cliente que recebe a chamada para
o cliente responsável pela sua origem. Portanto para a obtenção dos endereços IP, é
necessário fazer uma chamada teste, ou seja é feita uma chamada com uma duração de cerca
de 2 segundos apenas para obter a informação necessária. É então percorrida a lista de
contactos e feita uma chamada para cada contacto, e apenas os que tiverem conectividade
conseguirão obter o IP.
Após obter uma lista dos IPs atribuídos naquele momento para cada contacto, pode-se
proceder à configuração do MGEN. O MGEN é a ferramenta utilizada neste trabalho para o
cálculo das métricas necessárias de forma a ser possível obter uma quantificação da
qualidade da chamada. As métricas responsáveis por esta caracterização são, perda, atraso e
a diferença entre os atrasos (jitter) dos pacotes.
Usando então os IPs obtidos dos vários contactos, efectua-se a devida configuração do
MGEN mais concretamente a definição do tráfego a ser enviado e quais as portas de escuta.
Essa configuração é feita num ficheiro que posteriormente é importado pelo gerador de
tráfego.
A partir do momento em que o ficheiro responsável pela configuração do MGEN está
correctamente efectuado, não é suficiente para o arranque do programa uma vez que o
objectivo é a obtenção das métricas e para isso é estritamente necessária a sincronização das
partes envolvidas. Para isso ser possível, temporizou-se o tempo de arranque do MGEN, ou
seja, o software arranca exactamente 3 minutos após o inicio do teste.
Depois de terminar a execução do MGEN, é analisado um ficheiro que é criado pelo
próprio programa e que contém toda a informação necessária para se proceder aos cálculos
de obtenção das métricas.
Utilizando esses resultados calcula-se a qualidade da chamada. Estão definidos três níveis
1 (Bom), 2 (Aceitável), 3 (Mau) para caracterizar de forma simples e intuitiva para os
utilizadores a qualidade que poderão esperar da chamada mediante esta classificação.
Portanto em cada teste obtém-se uma classificação para cada contacto, como é óbvio para
ser mais correcto tem que existir um histórico sobre todos os testes anteriormente feitos.
60|Desenvolvimento e integração
Existe um ficheiro denominado Store que guarda o histórico de todos os contactos, e que
é utilizado sempre que há a uma actualização dos resultados, para permitir que apenas se
edite na parte gráfica do Ekiga a classificação quando o número de testes de um certo nível
suplante todos os outros.
Para concluir e como demonstra o fluxograma os testes são feitos ciclicamente mas
apenas em momentos previamente programados, e cada teste demora cerca de sete minutos
a concluir.
5.3- Principais funções implementadas
Nesta secção é feita uma análise com maior pormenor dos aspectos implementados. O
código está dividido em funções, que foram integradas em diferentes ficheiros pertencentes
ao já existente programa Ekiga.
O programa implementado inicia-se logo após o Ekiga também ser iniciado, isto é após ser
criada a interface gráfica do Ekiga é lançada imediatamente uma thread para correr o
processo responsável pela funcionalidade de QoS. Quando ocorre o instante de teste, é
invocada uma função designada get_contact(); esta função é responsável por receber um
inteiro correspondente à posição de um contacto pretendido e devolve um apontador para a
sua estrutura, permitindo aceder aos seus dados nomeadamente à URI para poder fazer a
chamada teste.
Outra função implementada é get_IP() que basicamente é a responsável por efectuar as
chamadas de teste e guardar todos os endereços IP num vector.
Existe uma função para evitar erros e poupar recursos à máquina, que faz um teste ao IP
obtido e caso não corresponda a um formato de um endereço IP correcto não faz os testes
para esse contacto.
Há também as funções mgen_reception(), e mgen_transmission().
Mgen_reception() é a função responsável pela construção do ficheiro utilizado para configurar
o MGEN de recepção.
Tem a seguinte estrutura:
0.0 LISTEN UDP 5000
180.0 IGNORE UDP 5000
0.0 -> O tempo de offset após o inicio do programa (em segundos); neste caso inicia em
simultâneo.
LISTEN -> Comando para ficar à escuta de pacotes.
UDP -> O tipo de tráfego que espera receber neste caso UDP (nota: ainda não foi
implementado TCP).
5000 -> A porta na qual o programa fica à escuta.
180.0 -> O tempo após o inicio do programa para fazer uma acção. Este valor não é
aleatório. Pretende-se simular uma chamada VoIP para estudar o comportamento da rede
61|5.3- Principais funções implementadas
mediante essa alteração de tráfego. O MGEN é a ferramenta que vai simular essa chamada,
mas para isso tem de injectar tráfego de acordo com uma chamada VoIP real. Portanto este
valor de 180 segundos de tempo de recepção deve-se ao facto se ter tomado como base que
uma chamada em média tinha a duração de 3 minutos.
IGNORE -> Comando para terminar a receber pacotes.
UDP -> Tipo de tráfego que deixa de ser escutado.
5000 -> Porta na qual o programa deixa de receber dados.
Mgen_transmission() é a função encarregue por criar o ficheiro que serve de configuração de
envio do MGEN.
Tem a seguinte estrutura:
0.0 ON 3 UDP SRC 5003 DST 192.168.1.68/5000 PERIODIC [50 214]
0.0 -> O tempo de offset após o inicio do programa (em segundos); neste caso inicia em
simultâneo.
ON -> Comando para activar o envio do tráfego.
3 -> Número de fluxo atribuído a este envio de tráfego.
UDP -> Tipo de tráfego a enviar.
SRC -> Serve para informar que o próximo comando está relacionado com a máquina de
envio.
5003 -> A porta pela qual o tráfego é enviado.
DST -> Serve para informar que o próximo comando está relacionado com a máquina que
recebe este tráfego.
192.168.1.68/5000 -> Endereço IP da máquina de destino e a porta na qual está à espera de
receber este tráfego.
PERIODIC [50 214] -> Definição da frequência de envio, neste caso é constante a uma certa
cadência. O valor da frequência de envio tal como tempo de recepção de 3 minutos não é
aleatório. Estes valores foram obtidos para a frequência com que são enviados pacotes RTP
por segundo e com um certo tamanho. Representam o envio de 50 pacotes por segundo com
um tamanho de 214 bytes cada, e têm o objectivo de simular o tráfego de uma chamada real.
Os valores foram obtidos analisando uma chamada real com a ferramenta Wireshark que
permitiu analisar todos os pacotes que passavam na rede incluindo os SIP e claro os RTP que
forneceram estes valores. Foram obtidos para o codec G711.
A função responsável pelo inicio do MGEN é denominada mgen() e executa o seguinte
comando:
./mgen input example.mgn output example3.txt
O objectivo deste comando é o de iniciar o programa, forçá-lo a configurar-se pelo ficheiro
example.mgn e guardar os resultados no ficheiro de texto example3.txt.
62|Desenvolvimento e integração
O ficheiro example3.txt é gerado pelo MGEN, e o seu conteúdo é o registo dos pacotes
recebidos com os endereços IP de destino e origem, tempos de envio e recepção, números de
sequência, identificação de fluxo.
Para se ter a percepção exacta do tipo de informação em causa, segue um exemplo
retirado de um teste efectuado e a sua análise.
Neste exemplo apenas vamos usar um pacote de forma a ser o mais simples possível.
1ª 10:34:00.000442 START 10:34:00.000566 LISTEN proto>UDP port>5000
2ª 10:34:00.093337 RECV flow>1 seq>0 src>192.168.168.123/5001
dst>192.168.168.162/5000 sent>10:34:00.010012 size>214 3ª 10:34:30.038021 IGNORE proto>UDP port>5000
10:34:30.038048 STOP
Podemos considerar que o ficheiro de configuração está definido em três partes:
Inicialização, execução do programa e o fim do processo.
1º Contém o inicio do programa com o registo do momento exacto em que tal aconteceu.
Também inclui a definição do protocolo utilizado para o transporte dos pacotes e a porta na
qual espera o tráfego.
2º Demonstra a execução do programa, neste caso articular apenas está registado um
pacote. O registo dos pacotes engloba toda a informação necessária. Contém a hora exacta
em que foi recebido o pacote, o fluxo a que pertence, o número sequencial que é único, os
endereços IP e portas de destino e origem, hora exacta em que o pacote foi enviado e ainda o
tamanho.
3º É utilizada para registar o fim da execução do programa tal como o fecho da porta à
escuta de pacotes.
As funções que conseguem obter os resultados das métricas a partir do ficheiro gerado
pelo MGEN são o packet_loss(),delay(), e jitter(). Como é óbvio o packet_loss é responsável
pelo cálculo da perda de pacotes, o delay pelo atraso médio dos pacotes, e o jitter pela
diferença entre os atrasos.
A função que converte os valores das métricas num valor de qualidade de chamada é
QoS(). Recebe os valores dos parâmetros obtidos e faz uma selecção segundo uma série de
critérios. O objectivo é fazer uma conversão das métricas obtidas, numa real percepção para
o cliente do nível de qualidade de chamada. Isto é, pretende-se uma avaliação do género da
já conhecida Mean Opinion Score (MOS). Os níveis foram assim definidos para serem de fácil
compreensão para os utilizadores [75], [74].
Os valores foram escolhidos de forma a garantirem o nível de QoS uma vez que foram
ponderados com alguma margem.
63|5.3- Principais funções implementadas
Pacotes perdidos < 1% dos pacotes totais enviados (Bom)
> 1% dos pacotes totais enviados (Mau)
Atraso médio < 150 ms (Bom)
150 < atraso < 250 ms (Aceitável)
>250 ms (Mau)
Diferença entre < 50 ms (Bom)
atrasos consecutivos > 50 ms (Mau)
Outra função importante é o edit_contact() que edita os contactos após os testes serem
efectuados, caso seja necessário.
Para editar os contactos de forma correcta, existe uma função que lê um ficheiro
designado store.txt. Este é um simples ficheiro de texto que tem como objectivo guardar um
histórico dos testes já efectuados para cada contacto. A necessidade da existência deste
histórico reside no facto que é necessário este conhecimento para se poder atribuir de forma
correcta e exacta a qualidade esperada da chamada.
Formato utilizado neste ficheiro:
Nome do contacto > protocolo de sinalização: Nome do contacto@IP do servidor VoIP >>
Nº de testes com qualidade nível Bom >>> Nº de testes com qualidade nível Aceitável >>>> Nº
de testes com qualidade nível Mau .
Exemplo:
Ekiga >sip:[email protected] >>1 >>>0 >>>>0 .
A partir deste ficheiro é possível decidir o nível de qualidade seguindo critérios de
selecção.
O critério de escolha da classificação é extremamente simples. Como já foi referido
existem três níveis de qualidade e o nível adoptado para definir essa qualidade é aquele que
tem o maior número de testes. Isto é, por exemplo:
Contacto X: Bom: 2
Aceitável: 6
Mau: 3
64|Desenvolvimento e integração
Neste caso a qualidade a adoptar para informar o utilizador seria a aceitável.
No caso de igualdade no maior valor, a escolha recai para o pior nível, de forma a
prevenir o utilizador de ser induzido em erro.
Exemplo:
Contacto Y: Bom: 6
Aceitável: 2
Mau: 6
Neste caso o nível da qualidade seria Mau.
Existem também algumas pequenas mas também importantes funções responsáveis pela
sincronização de todo este sistema.
Vejamos, no caso de haver vários clientes ligados no momento do teste e que partilhem
alguns contactos das suas listas, gera-se o problema de colisões ao originar as chamadas
teste. Por isso a solução foi repetir para cada contacto a chamada no máximo três vezes caso
não fosse obtido o IP correctamente.
Outra questão está relacionada com a associação dos resultados ao contacto correcto;
para isso fez-se um filtro para analisar os resultados apenas para um IP de cada vez e fazer a
respectiva correspondência entre o IP e a posição que ele ocupa no vector de endereços IP
dos vários contactos.
Os testes são feitos em simultâneo por ambos os clientes para possibilitar minimizar o
tempo gasto nos testes.
5.4- Integração dos componentes
Nesta secção pretende-se apresentar as instalações e configurações efectuadas em todas
as ferramentas utilizadas nesta dissertação, nomeadamente no servidor e clientes VoIP, no
gerador de tráfego e no programa que permite a sincronização das máquinas.
5.4.1- Asterisk
A instalação do Asterisk foi executada em Ubuntu, foram feitos os seguintes comandos
Linux para uma versão base ou seja sem os pacotes Zapata (para instalação de hardware
extra) e sem a biblioteca Libpri (responsável pela interface PRI) [77].
Para instalar as dependências necessárias para o Asterisk:
apt-get install bison openssl libssl-dev libasound2-dev libc6-dev libnewt-dev libncurses5-dev
zlib1g-dev gcc g++ make
Entrar no directório onde o Asterisk é instalado:
cd /etc
Fazer download do código fonte do Asterisk:
65|5.4- Integração dos componentes
Wget http://www.digium.com/elqNow/elqRedir.htm?ref=http://downloads.digium.com/
pub/asterisk/releases/asterisk-1.4.21.tar.gz
Descompactar o ficheiro:
tar -vzxf asterisk-1.4.21.tar.gz
Ficheiros de configuração [68], [70], [77].
Sip.conf
Este ficheiro é utilizado para definir os utilizadores e as suas características, como nome
do utilizador, a palavra-chave, codecs preferenciais, a forma como se pretende a sua
identificação…
[xlite]
type=friend
username=xlite
secret=xlite
nat=yes
Host=dynamic
canreinvite=no
callerid="xlite" <200>
disalow=all
allow=G.711
[Ekiga]
type=friend
username=ekiga
secret=ekiga
nat=yes
Host=dynamic
reinvite=no
canreinvite=no
callerid="xlite" <200>
disalow=all
allow=G.711
[xlite]: Definição do utilizador para o qual as definições seguintes são válidas.
type=friend: Para funcionar como User e como Peer ou seja para permitir efectuar e receber
chamadas.
username=xlite: Nome do utilizador para o registo.
secret=xlite: Palava chave do utilizador para o registo.
nat=no: Existência ou não de NAT
Host=dynamic: Possibilidade de registo com diferentes endereços IP
66|Desenvolvimento e integração
canreinvite=no: Permitir o envio de pacotes RTP directamente entre os utilizadores.
callerid="xlite" <200>: Definição da identificação do utilizador.
disalow=all: Desactivar todos os codecs.
allow=GSM: Activar apenas este codec.
EXTENSIONS .CONF
Este ficheiro é utilizado para definir um plano de atendimento de chamada, ou seja como
fazer a ligação entre uma extensão e o utilizador, o tempo de toque, voice mail, possibilidade
de atendimento personalizado, definição de música durante um possível tempo de espera …
exten =>200,1,Dial(SIP/xlite,15)
exten =>200,2,Hangup
exten =>201,1,Dial(SIP/ekiga,15)
exten =>201,2,Hangup
Neste caso apenas foi necessária a configuração para um atendimento simples, vejamos
em pormenor:
Exten =>: Para definir a extensão que fará a ligação a um utilizador registado;
200: O número utilizado para a extensão em causa;
1: Número sequencial das operações efectuadas pelo Asterisk quando existe uma chamada;
Dial: Ordem para atendimento da chamada;
SIP: Definição do protocolo a utilizar;
Xlite: Utilizador que utiliza a extensão 200;
15: Número máximo de segundos durante o qual toca o sinal de chamada;
Hangup: Para terminar a chamada
5.4.2- Ekiga
Para a instalação e posterior compilação do Ekiga é necessária a instalação das bibliotecas
Pwlib, Opal e do próprio código fonte [73].
Compilação de Pwlib
Dependências:
Flex
Bison
OpenLDAP
Instalação:
Wget http://www.ekiga.org/admin/downloads/latest/sources/sources/pwlib-1.10.10.tar.gz
$ tar xfvz pwlib-1.10.10.tar.gz
$ ./configure –prefix=/usr –enable-plugins –disable-oss –enable-v412 && make
Sudo make install
67|5.4- Integração dos componentes
Compilação Opal
Instalação:
Wget http://www.ekiga.org/admin/downloads/latest/sources/sources/opal-2.2.11.tar.gz
$ tar xfvz opal-2.2.11.tar.gz
$ ./configure –prefix=/usr && make
Sudo make install
Compilação Ekiga
Dependências:
Libsdl
Libebook
dbus-glib
Instalação:
Wget http://www.ekiga.org/admin/downloads/latest/sources/sources/ekiga-2.0.12.tar.gz
$ tar xfvz ekiga-2.0.12.tar.gz
$ ./configure –prefix=/usr –sysconfdir=/etc && make
Sudo make install
Figura 5.2 - Exemplo de configuração efectuada no Ekiga.
Esta imagem mostra a configuração de uma conta no Ekiga, que serve para se proceder ao
registo no servidor VoIP.
Segue uma breve explicação dos campos:
Account Name: Nome da conta.
Protocol: Protocolo utilizado por esta conta.
68|Desenvolvimento e integração
Registrar: Endereço IP, ou consequente nome registado pelo DNS (Domain Name Server) onde
a conta está registada.
User: Nome de utilizador de acordo com o que está registado no servidor VoIP utilizado.
Password: Palavra chave associada ao nome de utilizador.
5.4.3- X-lite
Para instalação do X-lite no Ubuntu:
Ir ao endereço http://www.counterpath.com/13#Download e fazer o download do programa;
é necessário fornecer o nome e e-mail. Depois basta ir ao directório onde ficou alojado,
descompactá-lo e executar os seguintes comandos:
cd xten-xlite
./xtensoftphone
Figura 5.3 - Exemplo de configuração do X-lite.
No X-lite para configurar uma conta de utilizador basta preencher os seguintes campos:
Enabled: Para activar a conta.
Display Name: O nome utilizado para ser visualizado.
Username: Nome da conta registada no servidor.
Authorization User: Nome da conta registada no servidor.
Password: Palavra passe associada à conta.
Domain/Realm: Endereço IP, ou consequente nome registado pelo DNS (Domain Name
Server) onde a conta está registada.
69|5.4- Integração dos componentes
5.4.4- MGEN
Instalação:
Wget http://downloads.pf.itd.nrl.navy.mil/mgen/linux-mgen-4.2b4.tgz
tar xfvz linux-mgen-4.2b4.tgz
5.4.5- NTP
Para sincronizar as máquinas de forma a fazer os testes correctamente utilizou-se o protocolo
NTP.
Instalação:
Sudo apt-get install ntp
Configuração:
pico /etc/ntp.conf
É necessário adicionar o servidor ntp a utilizar; no trabalho utilizou-se ntp1.inescnporto.pt
mas este servidor não é público. Por isso fora do Inesc teria que se usar outro como é o caso
do servidor do Observatório Astronómico de Lisboa ntp02.oal.ul.pt.
cd /etc/ntp/ start; para iniciar a sincronização automática com o servidor definido.
Nos testes para a sincronização ser imediata, utilizou-se o comando:
sudo ntpdate -b ntp1.inescnporto.pt
70|Desenvolvimento e integração
71|6.1- Introdução
Capítulo 6
Testes/Resultados
6.1- Introdução Esta secção do trabalho está reservada para a selecção de um cenário de teste adequado
aos objectivos pretendidos e os consequentes testes que o comprovem.
Com os testes pretende-se comprovar a veracidade dos valores obtidos consoante a
variação do comportamento da rede, e provar a automatização do sistema para funcionar
independentemente da localização dos utilizadores. E obviamente comprovar o bom
funcionamento da solução implementada.
6.2- Cenários de teste
Os cenários para testes baseiam-se num simples sistema com dois clientes ligados ao
servidor VoIP por uma ligação wireless. Os cenários foram testados usando um ponto de
acesso no Inesc para obter conectividade entre os diferentes componentes da arquitectura.
A escolha recaiu sobre uma ligação sem fios, pois o objectivo era tornar o teste o mais
real possível, uma vez que o recurso às redes sem fios em ambientes domésticos tem
aumentado imenso.
Também teve o objectivo de testar nesta rede pois é mais sensível a níveis de QoS uma
vez que é mais instável e está sujeita a maiores erros de transmissão que por cabo. Para além
de que não é facilmente controlável, isto é não se pode controlar o tráfego nem em que
instantes passa na rede, o que acontece nas redes públicas.
72|Testes/Resultados
1º Cenário de teste
Utilizador 1(ekiga)
Utilizador 2(X-lite)Ponto de
acesso
Router
Figura 6.1 - Cenário de teste apenas com um dos clientes a suportar a previsão da qualidade de
chamada.
Nesta situação, a questão que se coloca é saber o que acontece caso um ou mais
utilizadores não suporte o software desenvolvido, de forma a verificar a qualidade de
previsão das chamadas VoIP.
Num cenário destes, como é fácil de constatar apenas o Ekiga iria tentar fazer os devidos
testes mas como não iria receber qualquer tipo de pacotes do outro utilizador não obtinha
resultados e consequentemente não registava nenhuma alteração. Neste exemplo foi utilizado
o X-lite, mas apenas para representar um utilizador com um dispositivo que não suportasse os
testes, por isso podia ser qualquer outro.
2º Cenário de teste
Com este cenário de teste, em que os dois clientes já suportam a funcionalidade
implementada para a previsão da qualidade de chamada, efectuaram-se as medidas que são
apresentadas de seguida.
73|
Figura 6.2 - Cenário de teste com ambos os clientes a suportarem a previsão da qualidade de chamada
6.3- Testes efectuados
Os testes efectuados, tinham como principal objectivo fazer um estudo da rede utilizada
e como se comportava mediante alterações significativas de tráfego.
Este tipo de testes também possibilita analisar as alterações das medidas efectuadas, que
servem como demonstração que os cálculos estão a ser correctamente efectuados.
Portanto nos seguintes gráficos estão representados as três métricas de forma separada
em que se alterou o tráfego injectado na rede de forma a poder analisar-se as diferenças
obtidas.
A rede onde foram efectuados os testes não é privada, portanto existem outros
utilizadores a usá-la pelo que o tráfego pode variar sem que isso seja controlável.
A tabela 10 relaciona os diferentes tráfegos testados com os resultados obtidos.
Para os testes efectuados que permitiram obter os valores que se seguem, o tráfego injectado
pelo MGEN apara realizar o teste é idêntico para todas as condições de tráfego testadas.
Características do tráfego de teste:
Frequência: 50 pacotes/segundo, distribuídos uniformemente no tempo
Tamanho: 214 bytes por pacote
Duração: 3 minutos
74|Testes/Resultados
Tabela 6.1 - Sem tráfego adicional na rede.
Medidas efecuadas
Nº do teste
Pacotes perdidos (%)
Atraso médio (ms)
Jitter (ms)
1 0 9,422064 10,85689
2 0,022222 3,283889 2,694188
3 0,011111 4,900322 3,067237
4 0,011111 3,454556 3,073786
5 0,011111 3,533667 3,246916
6 0,011111 3,919444 3,750972
7 0,011111 3,738444 3,13946
8 0,011111 6,037 4,972997
9 0,011111 3,567111 2,653073
Tabela 6.2 - Com tráfego adicional de 700 pacotes/s com 1024 bytes.
Medidas efecuadas
Nº do teste
Pacotes perdidos (%)
Atraso médio (ms)
Jitter (ms)
1 0,055556 71,92886 38,38177
2 0,077778 72,17767 38,69743
3 0,111111 72,38027 39,24961
4 0,055556 70,34426 39,39155
5 1,333333 80,67008 40,5393
6 0,077778 56,6491 39,19693
7 0,233333 47,65368 39,15726
8 0,044444 48,50406 40,36338
9 0,044444 46,01645 39,83971
75|6.3- Testes efectuados
Tabela 6.3 - Com tráfego adicional de 900 pacotes/s com 1024 bytes.
Medidas efecuadas
Nº do teste
Pacotes perdidos (%)
Atraso médio (ms)
Jitter (ms)
1 1,088889 81,65933 41,29859
2 1,4 81,2178 41,28217
3 1,666667 92,94656 41,74836
4 2,022222 94,48214 42,11726
5 0,611111 71,82001 38,65271
6 2,655556 61,09575 43,46821
7 1,044444 49,24363 42,48507
8 0,722222 44,02686 41,93934
9 0,955556 42,9742 42,50079
Tabela 6.4 - Com tráfego adicional de 1100 pacotes/s com 1024 bytes.
Medidas efecuadas
Nº do teste
Pacotes perdidos (%)
Atraso médio (ms)
Jitter (ms)
1 12,77778 124,5919 48,07312
2 17,04444 140,5089 50,3445
3 20,06667 147,8403 50,79858
4 20,56667 138,7027 51,12575
5 20,53333 135,5483 50,93440
6 15,35556 130,2713 52,76014
7 15,27778 136,5230 50,56582
8 14,08889 129,1042 51,21088
9 13,23333 127,0266 49,95178
Tabela 6.5 - Qualidade das chamadas VoIP para diferentes valores de tráfego na rede.
Medidas efectuadas
Nível Tráfego
S/Tráfego 700p/s 900p/s 1100p/s
Bom 9 8 3 0
Aceitável 0 0 0 0
Mau 0 1 6 9
76|Testes/Resultados
Figura 6.3 - Variação do jitter na rede dependendo do tráfego injectado.
Figura 6.4 - Variação das perdas na rede mediante o tráfego injectado.
05
1015202530354045505560
1 2 3 4 5 6 7 8 9
Jitter (m
s)
Número de testes
Jitter
S/ tráfego 700p/s 900p/s 1100p/s
0
3
6
9
12
15
18
21
24
1 2 3 4 5 6 7 8 9
% Perda
s
Número de testes
Perda de pacotes
S/ Tráfego 700p/s 900p/s 1100p/s
020406080
100120140160
Atraso (m
s)
Testes efectua
dos
Figura 6.5 -
Figura
1
sem
0
2
4
6
8
10
S/ T
Valor
- Variação do
a 32.6 - Relaçã
2 3
A
m tráfego
Tráfego7
res obtin
B
atraso na red
ão entre tráfe
4 5Número
Atraso m
700p/s
00p/s
Tráfego na r
idos pelníveis de
Bom Aceitá
de mediante o
ego na rede e
5 6de testes
médio
900p/s
900p/s
rede
la aplicae QoS
ável Mau
77|6.
tráfego injec
nível de QoS.
7 8
s 1100
1100p/s
ação pa
.3- Testes ef
ctado.
.
9
0p/s
ra
fectuados
78|Testes/Resultados
6.3- Análise de resultados
Perante os resultados obtidos podemos facilmente visualizar que as medidas alteram-se
significativamente de acordo com o tráfego injectado artificialmente na rede.
Como era de esperar os valores das métricas têm tendência para aumentar com o tráfego
existente na rede.
A forma como as métricas são influenciadas pelo tráfego na rede não é linear, isto é se o
tráfego aumentar para o dobro, os valores das métricas não aumentam de igual forma. Após
uma análise aos gráficos pode-se até concluir que a rede até um certo nível de tráfego
consegue manter níveis com alguma qualidade, no entanto quando se aproxima de um nível
de saturação a rede degrada-se substancialmente sendo essa a causa de valores tão distintos
para o tráfego de 1100 pacotes por segundo.
Uma característica importante é o facto que comparando os tráfegos de 700 e 900
pacotes/segundo os valores para o atraso e diferença entre atrasos não são muito diferentes.
A razão para estes valores está no facto de que as métricas não variam da igual forma. Ou
seja embora a rede consiga manter os níveis de atraso e de jitter, os pacotes perdidos
aumentam. Pode-se por isso concluir que apenas uma ou duas métricas não são suficientes
para caracterizar a rede, o pode facilmente induzir em erro.
Esta análise permite também concluir que algumas métricas são mais úteis para analisar
uma rede do que outras, ou seja têm pesos diferentes no comportamento o que permite
visualizar alguns problemas mais rapidamente, e claro os níveis de qualidade são mais
influenciáveis por umas do que por outras.
No exemplo anterior, se houvesse apenas conhecimento do atraso ou do jitter constatava-
se que a rede estava com alguma queda de qualidade, mas no entanto com a informação da
perda de pacotes visualizava-se rapidamente que a qualidade da rede estava degradada.
Na figura 6.6 estão representados os valores obtidos com a ferramenta implementada
para a previsão do nível de qualidade das chamadas, para diferentes tráfegos na rede. Como
era de esperar os extremos são quase simétricos, isto é um é muito mau enquanto o outro é
muito bom. Uma característica que se pode verificar é a ausência de testes com qualidade
Aceitável, isto porque como um dos critérios era o limite imposto pela perda de pacotes o
que não permitiu sequer chegar a atraso acima dos 150 ms nesta rede sem ultrapassar esse
valor de perda.
Uma das principais ilações a retirar desta análise está no facto que as aplicações em
tempo real que exigem qualidades de serviço muito elevadas, como é o caso do VoIP, podem
facilmente experimentar degradação de qualidade com alguma alteração do tráfego da rede.
Pode-se afirmar que o conhecimento dos níveis de QoS de uma rede permite descobrir
alguns problemas sistemáticos que possam existir.
Esta implementação tem então uma aplicação prática que pode evitar uma má utilização
do serviço de VoIP ao informar os utilizadores da qualidade de serviço esperada.
79|7.1- Conclusão
Capítulo 7
Conclusão/Trabalho futuro
7.1- Conclusão
A forma como a Internet foi concebida, isto é, baseada na transmissão de pacotes sem
qualquer tipo de prioridade e sem qualquer reserva de largura de banda, impede que haja à
partida uma garantia de qualidade de serviço.
Devido à gigantesca expansão do número de utilizadores e o aumento de utilização de
recursos por utilizador que se tem vindo a verificar na rede, podem por vezes ocorrer
problemas de congestionamento. Este aumento na utilização dos recursos aliado ao facto de a
Internet funcionar em best-effort, inviabiliza garantias de qualidade de serviço que são
estritamente necessárias para certas aplicações como são o caso das que funcionam em
tempo-real. Uma forma de atenuar este efeito, é incluir inteligência na rede nomeadamente
nos dispositivos que comutam os pacotes, de forma a garantir condições para atingir certos
níveis de qualidade de serviço. Daí existirem dois modelos de QoS para se poder aplicar na
rede, modelo de Serviços Integrados (IntServ) e Serviços Diferenciados (DiffServ). Para a
aplicação destes modelos de forma a garantir qualidade de serviço é necessário um
entendimento entre os clientes e os seus provedores de serviços (ISP).
Concluímos portanto que é de extrema importância assegurar níveis satisfatórios de QoS
nas aplicações em tempo-real como é o caso do VoIP. A forma de termos a noção do nível de
QoS durante uma ligação de VoIP é baseada em certas métricas que caracterizam a rede como
são os casos de perdas de pacotes, atrasos e variações no atraso. Foi por isso necessária
também uma abordagem a várias ferramentas capazes de fornecer informação acerca das
métricas da rede.
Existe uma grande variedade de ferramentas tanto a nível do cálculo de medidas passivas
como de activas.
As ferramentas estudadas foram no âmbito de custo zero ou seja open-source, e não há
nenhuma capaz de resolver todas as métricas, isto é, para se ter uma real noção da qualidade
80|Conclusão/Trabalho futuro
de serviço de uma aplicação é necessário mais que uma ferramenta de forma a se
complementarem.
Foram também abordados protocolos de sinalização utilizados no VoIP, nomeadamente na
expansão do SIP face ao H323.
Realizou-se também uma análise a softwares de componentes VoIP, como servidores,
clientes e bibliotecas que foram úteis no desenvolver do projecto.
Toda esta pesquisa promoveu um maior e perspicaz conhecimento acerca deste tipo de
aplicações, permitiu o conhecimento do que está a ser ou já foi desenvolvido nesta área.
Serviu também para ter a ideia da importância da qualidade de serviço na rede devido ao
aumento do número de aplicações em tempo-real.
Do ponto de vista da implementação de um modo geral conseguiu-se atingir os objectivos
que estavam propostos. Foi possível verificar o comportamento da rede mediante alterações
de tráfego significativas, e visualizar a forma como são afectadas as métricas que
caracterizam os níveis de QoS. Foram apreendidos conceitos inovadores nomeadamente por
ser uma integração de um serviço num sistema já existente houve uma adaptação em vez da
criação, o que no mercado de trabalho é muito frequente.
Podemos assim concluir que numa sociedade de competição imensamente elevada, são os
pormenores que fazem a diferença e a implementação de aplicações deste tipo podem
prevalecer.
7.2 - Trabalho Futuro
Para trabalho futuro de forma a tornar o software mais funcional na realidade seria
necessário fazer algumas correcções e adicionar algumas funcionalidades, embora o princípio
de funcionamento se mantenha.
A grande alteração que se deve efectuar está na forma como se obtém o IP dos
utilizadores. Neste momento é efectuada uma chamada com uma duração de cerca de 2
segundos, mas a solução mais correcta seria não fazer qualquer chamada. Uma possibilidade
seria alterar o servidor para permitir um protocolo bastante simples apenas para responder
com o IP pedido por parte de um utilizador registado. Outra hipótese seria a manipulação de
uma mensagem SIP, por exemplo SIP OPTIONS de forma a enviar o próprio IP no conteúdo da
mensagem quando esta fosse solicitada.
Também seria mais correcto fazer um sistema centralizado, quer isto dizer sempre que
um utilizador se registasse em qualquer sítio e em qualquer máquina pudesse obter sempre os
resultados dos testes já efectuados.
Outra implementação que se poderia fazer era a hipótese de alterar a configuração do
Asterisk para ser possível a comunicação à rede PSTN.
E ainda caso fosse necessário deve-se proceder à implementação do OpenSER juntamente
com o Asterisk para tornar o sistema mais robusto.
81|Métodos e tipos de respostas SIP
Anexo A
Métodos e tipos de respostas SIP
82|Anexo A
83|Métodos e tipos de respostas SIP
Métodos SIP
INVITE (convidar) = Método para iniciar uma sessão.
ACK (confirmar) = Confirmação do comando INVITE
BYE (Terminar) = Método para finalizar uma sessão.
CANCEL (cancelar) = Cancela um INVITE pendente
REGISTER (registo) = Informa a localização do utilizador (nome do usuário, IP)
OPTIONS (opções) = Informa a capacidade e disponibilidade dos telefones de chamada e
recepção SIP.
Tipos de respostas SIP [15]
1xx = respostas de informações
100 A tentar
180 A chamar
181 Encaminhar Chamada
182 Fila de espera
183 Progresso da Sessão
2xx = respostas de confirmação
200 OK
202 Aceite: Usado para referências
3xx = respostas de redireccionamento
300 Múltipla escolha
301 Movido Permanentemente
302 Movido Temporariamente
305 Use Proxy
380 Serviço Alternativo
4xx = comandos não realizados
400 Requerimento errado
401 Não autorizado: Restrito aos utilizadores registados. Proxys devem usar autorização 407
402 Necessário o Pagamento (Reservado para uso futuro)
403 Proibido
404 Não Encontrado: Utilizador não encontrado
405 Método Não Permitido
406 Não é permitido
407 Necessária Autenticação de Proxy
84|Anexo A
408 Timeout Pedido: Não foi possível localizar o utilizador a tempo
410 Saiu: O utilizador existe, mas não está mais disponível.
413 Pedido de Dados Muito Longo
414 Pedido URI Muito Longo
415 Tipo de dados não Compatível
416 Endereço URI não Compatível
420 Extensão errada: Erro na extensão utilizada do Protocolo SIP, não compreendida pelo
servidor
421 Extensão necessária
423 Intervalo Muito Breve
480 Temporariamente Não Disponível
481 Chamada/Transacção Não Existente
482 “Loop” Detectado
483 Demasiados “hops”
484 Endereço Incompleto
485 Ambíguo
486 Ocupado
487 Pedido Concluído
488 Não Aceite
491 Pedido Pendente
493 Indecifrável: Não foi possível descodificar S/MIME
5xx = erros do servidor
500 Erro Interno do Servidor
501 Não Implementado: O método de pedido SIP não está implementado
502 Problemas na Gateway
503 Serviço Não Disponível
504 Servidor em “Time-out”
505 Versão Não Compatível: O servidor não é compatível com essa versão do protocolo SIP
513 Mensagem Muito Longa
6xx = erros globais
600 Ocupado
603 Rejeitar
604 Não Existe
606 Não aceito
85|Métodos e tipos de respostas SIP
Referências
[1] Breve história da INTERNET. Disponível em http://piano.dsi.uminho.pt/
museu/INTERNET.PDF. Acesso em Dezembro de 2007.
[2] Prof. José Ruela, Apontamentos QoS.
Disponível em http://paginas.fe.up.pt/~jruela/Apontamentos. Acesso em Dezembro de
2007.
[3] Nuno Miguel Tavares de Sousa, “Peer-to-Peer Computing” Disponivel em http://
gnomo.fe.up.pt/~eol/MEMBERS/nuno_sousa/old/ppc/artigo.html. Acesso em Dezembro de
2007.
[4] Maheen Hasib e John A .Schormans, “Limitations of Passive & Active Measurement
Methods in Packet Networks”. Department of Electronic Engineering Queen Mary,
University of London. Disponível em http://www.ee.ucl.ac.uk/lcs/papers2003/ 113.pdf.
[5] VoIP. Disponível em http://www.apdc.pt/publicacoes/portfolio/revista/rev168/rev-
k.html. Acesso em Dezembro de 2007.
[6] “Voz sobre o protocolo de internet VoIP”. Disponível em http://www.anacom.pt/txt/
template25.jsp?categoryId=168642#9. Acesso em Dezembro de 2007.
[7] Prof. Joel Rodrigues, “Serviços de voz sobre IP”. Disponível em http://www.di.ubi.pt/
~joel/files/SC-Cap5.pdf. Acesso em Dezembro de 2007.
[8] Victor Chaves, Protocolos de sinalização VoIP.
Disponível em http://www.uniriotec.br/~victor.chaves/disciplinas/eda1/EDA1_relatorio
Final.pdf. Acesso em Dezembro de 2007.
[9] Protocol stack. Disponível em http://www.blogvoip.it/post/572/i-protocolli-h323. Acesso
em Dezembro de 2007.
[10] Voz sobre IP. Disponível em http://tele1.dee.fct.unl.pt/td_2002_2003/teo/td_11_
voip.pdf. Acesso em Dezembro de 2007.
[11] Protocolo SIP.
http://www.windowsnetworking.com/articles_tutorials/Session-Initiation-Protocol-
Functions.html. Acesso em Dezembro de 2007.
[12] Telefonia sobre IP. Disponível em http://www.rnp.br/_arquivo/sci/2003/telefonia_ip
.pdf. Acesso em Dezembro de 2007.
86|Referências
[13] SDP: Session Description Protocol Disponível em http://www.javvin.com/protocolSDP.
html
[14] Session Description. Disponível em http://www.tech-invite.com/Ti-sdp-abnf.html
[15] VoIP protocols. Disponível em http://www.en.voipforo.com/
[16] Session Initiation Protocol. Disponível em http://gpwm.devin.com.br/index.php/
Session_Initiation_Protocol_(SIP)#User_Agents. Acesso em Dezembro de 2007.
[17] Tecnologia VoIP e Protocolo SIP. Disponível em http://www.3cx.com.br/voip-sip/.
Acesso em Dezembro de 2007.
[18] Prof. José Ruela, “Arquitecturas Multimédia”. Disponível em http://paginas.fe.up.pt/
~jruela/Apontamentos/Arq_IETF.pdf. Acesso em Dezembro de 2007.
[19] H323 Beacon Tool.
Disponível em http://www.osc.edu/networking/itecohio.net/ beacon/. Acesso em
Dezembro de 2007.
[20] Olof Hagsand, Ignacio Más, Ian Marsh, and Gunnar Karlsson, “Self-admission control for ip
telephony using early quality estimation (Published Conference Proceedings style)”,In 3rd
IFIP-TC6 Networking Conference, Networking 2004, June 2004. Springer LNCS.
[21] Ian Marsh and Fengyi Li, “A VoIP measurement infra-structure (Published Conference
Proceedings style)”, In 16th Nordic Teletraffic Seminar, Helsinki, Finland, August 2002
[22] João Paulo Sousa e Eurico Carrapatoso, “Uma arquitectura IPtel baseada no protocolo
SIP”. Disponível em http://www.ipb.pt/~jpaulo/documentos/crc2003_jps_emc.pdf.
Acesso em Dezembro de 2007.
[23] PathChirp. Disponível em http://www.spin.rice.edu/Software/pathChirp/. Acesso em
Dezembro de 2007.
[24] Stab. Disponível em http://spin.rice.edu/Software/STAB/. Acesso em Dezembro de
2007.
[25] Pathneck. Disponível em http://www.cs.cmu.edu/~hnn/pathneck/. Acesso em Dezembro
de 2007.
[26] Pathrate. Disponível em http://www.cc.gatech.edu/fac/Constantinos.Dovrolis/
pathrate.html. Acesso em Dezembro de 2007.
[27] Pathrate. Disponível em http://www.pathrate.org. Acesso em Dezembro de 2007.
[28] Pathchar. Disponível em http://www.caida.org/tools/utilities/others/pathchar/. Acesso
em Dezembro de 2007.
[29] Fping. Disponível em http://fping.sourceforge.net/. Acesso em Dezembro de 2007.
[30] Freeping. Disponível em http://www.advtoolware.com/software/software-utlities/ free-
ping/free-ping.asp. Acesso em Dezembro de 2007.
[31] MGEN. Disponível em http://pf.itd.nrl.navy.mil/mgen/mgen.html. Acesso em Dezembro
de 2007.
[32] MRTG. Disponível em http://oss.oetiker.ch/mrtg/. Acesso em Dezembro de 2007.
[33] Iperf. Disponível em http://dast.nlanr.net/Projects/Iperf/. Acesso em Dezembro de
2007.
87|Métodos e tipos de respostas SIP
[34] H323 Beacon Tool. Disponível em http://www.osc.edu/oarnet/itecohio.net/beacon/.
Acesso em Dezembro de 2007.
[35] NetQoS. Disponível em http://www.netqos.com/solutions/voip_monitor/index.html.
Acesso em Dezembro de 2007.
[36] OWAMP. Disponível em http://e2epi.internet2.edu/owamp/. Acesso em Dezembro de
2007.
[37] TcpDump. Disponível em http://en.wikipedia.org/wiki/Tcpdump. Acesso em Dezembro
de 2007.
[38] TcpDump. Disponível em http://www.tcpdump.org/. Acesso em Dezembro de 2007.
[39] TCPStat. Disponível em http://www.mfcssoft.com/mfcstcpstat.htm~. Acesso em
Dezembro de 2007.
[40] Tstat. Disponível em http://tstat.tlc.polito.it/index.shtml. Acesso em Dezembro de
2007.
[41] Ntop. Disponível em http://www.ntop.org/. Acesso em Dezembro de 2007.
[42] Disponível em http://www.vtt.fi/liitetiedostot/innovaatioita/QoSMeT_passive%20tool
.pdf. Acesso em Dezembro de 2007.
[43] QoSMeT – “A passive tool formeasuring Quality of Service (QoS)of networking
applications”. Disponível em http://www.vtt.fi/liitetiedostot/innovaatioita/qosmet.pdf.
Acesso em Dezembro de 2007.
[44] Network monitoring tools. Disponível em http://www.slac.stanford.edu/xorg/nmtf/
nmtf-tools.html. Acesso em Dezembro de 2007.
[45] Trpr. Disponível em http://pf.itd.nrl.navy.mil/protools/trpr.html. Acesso em Dezembro
de 2007.
[46] GnuPlot. Disponível em http://www.gnuplot.info/. Acesso em Dezembro de 2007.
[47] SER. Disponível em http://www.iptel.org/ser/. Acesso em Março de 2008.
[48] OpenSER. Disponível em http://www.openser.org/. Acesso em Março de 2008.
[49] SIP Express media server.http://developer.berlios.de/projects/sems. Acesso em Março
de 2008.
[50] Asterisk. Disponível em http://www.asterisk.org/. Acesso em Março de 2008.
[51] CallWeaver. Disponível em http://www.callweaver.org/wiki/CallWeaver. Acesso em
Dezembro de 2007.
[52] PartySIP. Disponível em http://www.nongnu.org/partysip/. Acesso em Dezembro de
2007.
[53] OpenH323. Disponível em http://www.openh323.org/. Acesso em Dezembro de 2007.
[54] MiniSIP. Disponível em http://www.minisip.org/libmsip/. Acesso em Dezembro de 2007.
[55] Sofia-sip. Disponível em http://sofia-sip.sourceforge.net/. Acesso em Dezembro de
2007.
[56] PjSIP. Disponível em http://www.pjsip.org/. Acesso em Dezembro de 2007.
[57] Open Source SIP. Disponível em http://www.opensourcesip.org/. Acesso em Dezembro
de 2007.
88|Referências
[58] SIPX. Disponível em http://sipx-wiki.calivia.com/index.php/Legacy_Articles. Acesso em
Dezembro de 2007.
[59] Ekiga. Disponivel em http://www.ekiga.org/. Acesso em Março de 2008.
[60] Sip-Communicator. Disponível em http://sip-communicator.org/. Acesso em Dezembro
de 2007.
[61] Wxcommunicator. Disponível em http://wxcommunicator.sourceforge.net/. Acesso em
Dezembro de 2007.
[62] X-Lite. Disponível em http://www.counterpath.com/. Acesso em Março de 2008.
[63] Sflphone. Disponível em http://www.sflphone.org/. Acesso em Dezembro de 2007.
[64] “Voice over IP and related Technologies”
Disponível em http://www.pernau.at/kd/voip/. Acesso em Dezembro de 2007.
[65] Asterisk e OpenSER. Disponível em http://www.asteriskexperts.com.br/content/
section/4/28/. Acesso em Março de 2007.
[66] Telefonia IP com SIP Disponível em http://www.asteriskexperts.com.br/FreeChapters/
Portugues/ freeopenserchapters.htm. Acesso em Dezembro de 2007.
[67] “Growing Campus SIP Connectivity to Support Advanced Communications”. Disponível em
http://www.internet2.edu/sip.edu/. Acesso em Dezembro de 2007.
[68] Freenum. Disponível em http://freenum.org/cookbook/. Acesso em Dezembro de 2007.
[69] Asterisk. Disponível em http://www.asteriskonline.com.br/. Acesso em Março de 2008.
[70] Asterisk. Disponível em http://www.jeremy-mcnamara.com/2007/02/26/how-to-
configure asterisk-your-first-installation/. Acesso em Março de 2008.
[71] Ekiga. Disponível em http://wiki.ekiga.org/index.php/Main_Page. Acesso em Março de
2008.
[72] Ekiga. Disponível em http://www.gnomemeeting.org/index.php?rub=3. Acesso em Março
de 2008.
[73] Ekiga. Disponível em http://wiki.ekiga.org/index.php/Linux_Users. Acesso em Março de
2008.
[74] “Best Practices forMonitoring NortelCS1000 VoIP MetricsWith eHealth for Voice”.
Disponível em http://www.empowerednetworks.com/solution/pdf/CAeHVoice/nortel_
c1000 _voip_bestprac_wp_en_us.pdf. Acesso em Dezembro de 2007.
[75] QoS VoIP. Disponível em http://www.voipforo.com/en/QoS/QoS_Voip.php. Acesso em
Dezembro de 2007.
[76] SIP (RFC 3261). Disponível em http://www.ietf.org/rfc/rfc3261.txt. Acesso em Dezembro
de 2007.
[77] Gomillion, David e Dempster, Barrie, Building Telephony Systems with Asterisk.
Birmingham, capítulos 1-4, Packt Publishing Ltd, 2005.
[78] Mehta, Udani. “Voice over IP, IEEE Potentials, Volume 20, Issue 4, Oct/Nov 2001
Page(s):36 - 40.
[79] Duysburgh, B.; Vanhastel, S.; De Vreese, B.; Petrisor, C.; Demeester, P.Computer, On
the influence of best-effort network conditions on the perceived speech quality of VoIP
89|Métodos e tipos de respostas SIP
Connections”, Communications and Networks, 2001. Proceedings. Tenth International
Conference on Volume , Issue , 2001 Page(s):334 - 339.
Top Related