acme: uma ferramenta automatizada para geração e · pdf fileresumo. acme, uma...

ACME: Uma ferramenta automatizada para geração e avaliação de qualidade de chamadas VoIP

Leandro C. G. Lustosa, André A. D. P. Souza, Paulo H. de A. Rodrigues, Douglas G. Quinellato

Laboratório de Voz Sobre IP – Núcleo de Computação Eletrônica – Universidade Federal do Rio de Janeiro (NCE/UFRJ) *

Caixa Postal 2324 – 20001-970 – Rio de Janeiro – RJ – Brasil

{leandro,andreabrantes,aguiar}@nce.ufrj.br, [email protected]

* Parcialmente suportados com recursos da Rede Nacional de Ensino e Pesquisa (RNP). Paulo H. de A. Rodrigues é também professor do Departamento de Computação/IM da UFRJ. Douglas G. Quinellato hoje é membro LAS (Laboratório de Administração e Segurança de Sistemas) do IC/UNICAMP.

Abstract. ACME, an automatic tool for the generation and quality evaluation of VoIP calls is presented. ACME analyses link bandwidths and node computing power capacities to determine the maximum number of simultaneous calls between pair of nodes in a given topology, besides supporting pre-programmed schedule of VoIP calls experiments. To demonstrate ACME versatility and efficacy, its use as an IP telephony service monitoring tool in a real environment is shown.

Resumo. ACME, uma ferramenta automatizada para geração e avaliação de qualidade de chamadas VoIP, é apresentada. A ACME analisa a disponibilidade de banda e capacidade de processamento para determinar o maior número de chamadas simultâneas que um nó pode operar numa determinada topologia, além de suportar a programação antecipada de experimentos. A eficácia e versatilidade da ferramenta é demonstrada com seu uso como um instrumento de monitoração de um serviço VoIP operacional.

1. Introdução

A ACME (Automatic Call Measurement Environment) é uma ferramenta capaz de desempenhar duas atividades básicas: a geração de chamadas VoIP (Voz sobre IP) e a aferição da qualidade das chamadas geradas. A ferramenta utiliza o potencial destas duas atividades fundamentais para construir um ambiente automatizado suportando duas classes de experimentos.

A primeira classe, denominada experimento de estresse (stress experiment), é utilizada basicamente para a determinação da capacidade (em número de chamadas simultâneas) que um determinado meio (cabeado ou sem fio) ou sistema (serviço ou conjunto de servidores VoIP) pode suportar, sem comprometer a qualidade de voz além de um determinado nível previamente estabelecido.

13º Workshop de Gerência e Operação de Redes e Serviços 27

A segunda classe, denominada experimento periódico (periodic experiment), é utilizada para averiguar a variação da qualidade de chamadas ao longo do tempo, possibilitando, inclusive, a monitoração de disponibilidade de um serviço VoIP.

A arquitetura da ACME foi desenvolvida a partir de uma infra-estrutura de avaliação de qualidade proposta pelo Laboratório de Voz sobre IP da UFRJ [Lustosa et. al. 2005a]. Esta infra-estrutura prevê que clientes VoIP (telefones IP ou gateways) sejam capazes de avaliar a qualidade da chamada recebida e emitir um registro de detalhamento da chamada (Call Detail Record ou CDR) específico para a qualidade denominado VQCDR (Voice Quality Call Detail Record). O VQCDR contém diversos indicadores referentes à qualidade de voz recebida, além de parâmetros de identificação da chamada e dos terminais envolvidos, podendo incluir um relatório com o histórico da variação dos indicadores de qualidade ao longo de toda a duração da recepção.

Os indicadores de qualidade do VQCDR são computados segundo o Modelo-E e suas extensões [ITU-T G.107 2003, ETSI 2002, ETSI 2003]. Pelo modelo, a degradação da qualidade de voz pode ser causada por diversos fatores [Lustosa et. al. 2004], tais como, perdas de quadros de voz (que podem ocorrer na rede ou nos buffers de compensação de jitter, devido à variação de atraso), o atraso fim-a-fim demasiado (que influi na interatividade da conversa), fatores relacionados ao codec (quantização inerente ao codec, robustez frente à um comportamento de perda, o uso de algoritmos compensadores de perda, detectores de atividade de voz, etc), entre outros. A saída do Modelo E é um fator escalar R, que é mapeável para a escala de pontuação MOS (Mean Opinion Score) [ITU-T P.800 1996]. O MOS indica a percepção humana da qualidade de voz e varia de 1 (péssimo) à 5 (excelente).

O cômputo do Modelo E, na arquitetura proposta pela UFRJ, é responsabilidade da VQuality (Voice Quality Library) [Lustosa et. al. 2005b], biblioteca desenvolvida em C++ que é integrada aos clientes IP para torná-los aptos a emitir o VQCDR. Com uso do VQCDR, a ACME é capaz de gerar resultados extremamente detalhados e gráficos demonstrativos. Avaliar um determinado meio é uma tarefa mais complexa que a avaliação de uma chamada apenas. Para determinação da capacidade de um enlace, por exemplo, é necessário que diversas baterias de chamadas sejam realizadas para que seja obtida a capacidade de chamadas do enlace. A ACME utiliza um mecanismo automático de execução dinâmica de chamadas para obter este valor dentro de um tamanho máximo para o intervalo de confiança escolhido, impedindo que variações de qualidade das chamadas resulte em resultados imprecisos de capacidade.

Diversas ferramentas comerciais possibilitam a avaliação de qualidade de chamadas VoIP [Telchemy 2007, Empirix 2007, Brix 2007, Solarwinds 2007], mas não encontramos nenhuma que objetivasse a determinação de capacidade de enlaces e de servidores. Por meio dessas ferramentas seria até possível determinar a capacidade de um meio, mas seria exigido que todos os cálculos e execução de chamadas fossem realizados de forma manual, o que seria trabalhoso e suscetível a erros humanos em grandes sistemas.

O artigo está organizado em oito seções. Na Seção 2, a infra-estrutura de avaliação de chamadas VoIP da UFRJ é descrita. Na Seção 3, a arquitetura da ACME e seus componentes são apresentados. Nas Seções 4 e 5, os conceitos dos experimentos de estresse e dos experimentos periódicos são discutidos. A Seção 6 mostra como

28 13º Workshop de Gerência e Operação de Redes e Serviços

experimentos são executados concorrentemente. Na Seção 7, o uso da ACME é demonstrado e, por fim, na Seção 8, conclusões e trabalhos futuros são apresentados.

2. Arquitetura de avaliação de qualidade de chamadas VoIP da UFRJ

Segundo a arquitetura de avaliação de qualidade proposta pela UFRJ [Lustosa et. al. 2005a], os VQCDRs são coletados por uma entidade denominada VQCDR Server, que possui a responsabilidade de interpretar, autenticar e encaminhar os VQCDRs coletados para serem armazenados em uma base de dados. O VQCDR Server possui três módulos:

Collector Module (CM): responsável por coletar e interpretar o VQCDR, além de acionar o Authenticator Module (AM) e o Storage Module (SM).

Authenticator Module (AM): responsável por validar os VQCDRs recebidos pelo CM. Para ambientes controlados de testes e medições, o VQCDR Server oferece uma lista de acesso simples baseada em endereços IP. Já em ambientes de produção, que requerem uma verificação mais sofisticada, o uso de AM é mais adequado.

Storage Module (SM): responsável por armazenar os VQCDRs coletados pelo CM em uma base de armazenamento. Esta base pode ser, por exemplo, um banco de dados SQL ou um servidor RADIUS.

GnuGK AuthenticatorModule (GnuGk AM)

(Radius SM)Radius StorageModule

(CM)Colector Module

VQCDR Server

H.323 GatekeeperGnuGK

Radius Server

Autenticação

Armazenamento

SQL Server

Arm

azenamento

4

7

PQ RS

*

CISCO IP P HONE7902 SERI ES

1 2

A B C

3D EF

4 5

J K L

6

M N OG H I

7 8

T U V

9

W X Y ZP Q R S

* 0 #

Em

issã

o do

V

QC

DR

Web ServerO telefone IP

computa a qualidade da

chamada e emite um VQCR para o VQCDR Server

1

O CM coleta o VQCDR e aciona o AM

2

O Radius Server recebe o VQCDR e

acessa o SQL Server para

armazenar as informações do

VQCDR em uma base de dados

6

Estatísticas de qualidade das chamadas são disponibilizadas via interface web

7

Caso o VQCDR seja validado, o

SM aciona o Radius Server

para armazenar o VQCDR

5

O AM acessa o GnuGK

para validar o VQCDR

4

Telefone IP integrado a VQuality

O AM autentica o VQCR3

Figura 1: Arquitetura de avaliação de qualidade de chamadas VoIP da UFRJ

A Figura 1 ilustra o funcionamento da arquitetura em linhas gerais: Ao final da chamada, o telefone IP integrado à VQuality avalia a qualidade de voz recebida segundo sua perspectiva, e então, emite um VQCDR contendo indicadores de qualidade e identificadores de chamada (Figura 1-1). Este VQCDR é coletado pelo CM do VQCDR Server (Figura 1-2), que aciona o AM para verificar a legitimidade do VQCDR (Figura 1-3). No caso de um gatekeeper GnuGK [GnuGK 2007], a autenticação é realizada via um módulo específico para o GnuGK (Figura 1-4). Caso o VQCDR seja validado, o SM é acionado para armazenar o VQCDR. No caso de uso de RADIUS, o VQCDR é enviado via protocolo RADIUS para um servidor RADIUS (Figura 1-5). O servidor RADIUS


então armazena as informações do VQCDR em uma base de dados, que pode ser, por exemplo, um servidor SQL (Figura 1-6). Estas informações são por fim disponibilizadas em forma de gráficos e estatísticas via interface Web (Figura 1-7).

A ACME utiliza toda esta infra-estrutura de geração e coleta de VQCDR em sua arquitetura e adiciona ainda novos elementos, os quais são descritos na Seção 3.

3. Arquitetura da ACME

A ACME possui uma arquitetura do tipo “mestre-escravo”. Um elemento central denominado ACME Master (ou simplesmente master) coordena uma série de elementos periféricos denominados ACME Slaves (ou simplesmente slaves), comandando-os a iniciarem chamadas ou se prepararem para receber chamadas.

Um slave recebe a denominação de slave passivo quando recebe chamadas e de slave ativo quando inicia chamadas. É importante salientar que um slave pode iniciar uma chamada para um destino que não seja necessariamente um slave. É possível, por exemplo, que um slave ativo chame um telefone IP a fim de averiguar a disponibilidade do sistema a que este telefone IP está associado.

Um ACME slave é composto basicamente por dois elementos: (1) um cliente VoIP (VoIP Client, ou simplesmente VC), que é um softphone capaz de realizar chamadas com o uso de um protocolo VoIP qualquer (por exemplo, SIP ou H.323) integrado à VQuality, para possibilitar a emissão de VQCDRs com indicadores de qualidade; (2) um interpretador para possibilitar a interação com o master, que é gerida por um protocolo denominado ACMEp, que será discutido na Seção 3.2.

Em um experimento de estresse é usual que múltiplas chamadas simultâneas sejam realizadas por um slave. Entretanto, o hardware sobre o qual o slave opera possui uma disponibilidade de recursos em termos de memória e processamento que limita a quantidade de chamadas simultâneas que podem ser realizadas sem que haja comprometimento de qualidade. A partir de certo momento, atrasos demasiados são injetados no processo de codificação/decodificação da voz e descartes nos buffers de compensação de jitter começam a ocorrer com freqüência. Como determinar a capacidade de um slave em receber ou gerar chamadas será apresentado na Seção 3.1.

Para avaliar a capacidade de um determinado hardware ou de um enlace de baixa velocidade, possivelmente dois hardwares (um para o slave passivo e outro para o slave ativo) sejam suficientes. O conceito de site permite que uma quantidade maior de chamadas paralelas seja realizada, possibilitando que enlaces de maior velocidade e hardware com maior recurso computacional sejam estressados com o uso de conjuntos de slaves operando sobre hardware de menor poder computacional. Experimentos são sempre realizados entre dois sites compostos de um ou mais slaves.

A ACME oferece uma interface Web que opera em um servidor HTTP, denominado User Interface Server (ou simplesmente UIS). Esta interface disponibiliza um mecanismo para que um usuário agende a realização de experimentos e visualize seus respectivos resultados.

A Figura 2 ilustra a arquitetura da ACME e seus principais componentes. No momento que o usuário cadastra um novo experimento através da interface Web, os dados referentes a este experimento são armazenados em um banco SQL e o master é


informado que um novo experimento foi cadastrado. Ao iniciar o experimento no momento programado, o master lê os parâmetros de configuração do experimento e ordena os slaves dos dois sites envolvidos para que as chamadas sejam realizadas e tenham a qualidade aferida. Ao executar as chamadas, os slaves emitem VQCDRs que são coletados pelo VQCDR Server e armazenados no banco SQL.

ACME Master

SQL Server

VQCDR Server

ACME UIS

Site A

ACME Slave

VC

ACME Slave

VC

Site B

ACME Slave

VCFluxos de voz

ACMEp: Comandos

master/slave

Coleta de VQCDR

Armazenamento de VQCDR

Leitura/atualização de informações do

experimento

Cadastro e visualização de experimentos

Notificação de experimento

Agendamento e visualização de experimentos

Usuário (browser

web)

Figura 2: Arquitetura da ACME

O UIS permite também que o usuário seja notificado através de e-mail sobre alguns status referentes aos experimentos, como, por exemplo, se algum erro ocorreu, se um experimento de estresse foi finalizado com sucesso, se algum slave está inalcançável, ou que a qualidade obtida está em nível alarmante, indicando que o sistema monitorado por um experimento periódico encontra-se em condição crítica.

Todo núcleo da ACME foi desenvolvido em C++, o banco de dados em PostgreSQL e o UIS em PHP. O projeto foi construído objetivando a execução em ambientes Linux, mas pode ser portado para outras versões de Unix. Os fluxos de voz utilizados são gravações com duração de 3 minutos, que mostrou suficiente para a deteção da degradação da voz com o aumento das chamadas simultâneas.

3.1. Determinação de capacidade do slave

A capacidade dos slaves deve ser antecipadamente avaliada com experimentos de estresse, para que a limitação computacional não resulte em imprecisão dos experimentos. Na determinação de capacidade, aumenta-se gradativamente o número de chamadas simultâneas, enquanto a qualidade das chamadas executadas permanecerem com avaliação máxima. A condição de parada é o início de degradação de qualidade. Existem três cenários possíveis no processo de determinação da capacidade dos slaves:


1. Dois slaves com harware de poder computacional equivalente: A degradação de qualidade ocorre de forma simétrica. Quando a qualidade das chamadas começa a degradar, a capacidade dos slaves é determinada;

2. Um slave com poder computacional sabidamente superior e outro slave com poder computacional inferior: A degradação de qualidade ocorre de forma assimétrica. Quando a qualidade das chamadas começa a degradar, a capacidade do slave de menor recurso é determinada;

3. Um slave S com grande poder computacional e um conjunto de slaves que juntos possuem poder computacional superior ao slave S: A degradação de qualidade ocorre de forma assimétrica. Quando a qualidade das chamadas começa a degradar, a capacidade do slave S é determinada;

Na determinação de capacidade o recurso de rede deve ser amplo, garantindo que o fator limitante de capacidade seja o hardware dos slaves.

3.2. Protocolo ACMEp

O ACMEp é o protocolo utilizado na comunicação entre o ACME Master e o ACME Slave. O master comanda os slaves, informando-os para se prepararem para receber um determinado número chamadas (slave passivo); ou ordenado-os a iniciarem um determinado número de chamadas para destinos específicos (slave ativo). Neste processo, a configuração da chamada também é informada: codificador, duração da chamada e destino (IP e porta de sinalização, número telefônico ou usuário). O master também possui a capacidade de ordenar que o slave se registre em um dado servidor, possibilitando assim que o servidor, ou o ambiente associado a um determinado servidor, seja avaliado em um experimento. Neste último caso, informações relativas ao registro no servidor são informadas ao slave (endereço do servidor, conta de acesso e senha). O protocolo possui apenas três mensagens, descritas a seguir:

1. Start: Opera no sentido de master para slave. Comanda o slave a se preparar para receber chamadas, iniciar chamadas ou se registrar em um determinado servidor;

2. Status: Opera no sentido slave para master. É utilizada pelo slave para informar ao master se as chamadas foram realizadas com sucesso ou falha. O slave passivo também usa a mensagem status para informar quando está apto a receber chamadas;

3. Cancel: Opera no sentido de master para slave. Utilizada pelo master para informar ao slave passivo que este não será mais chamado pelo slave ativo. Basicamente o Cancel cancela uma mensagem Start previamente enviada a um slave passivo.

A Figura 3 ilustra um experimento realizado entre dois slaves. O master comanda o slave passivo a ficar pronto para receber chamadas (START); O slave passivo informa ao master que está apto a receber as chamadas (STATUS-READY, leia-se STATUS com um indicador READY); O master comanda o slave ativo a iniciar as chamadas (START); As chamadas são iniciadas e o fluxo de voz entre os slaves começa a ocorrer. Caso todas as chamadas ocorram com sucesso, ambos os slaves enviam ao master um STATUS com o indicador OK, caso contrário, é enviado um STATUS com indicador NOK (NOT OK). É importante notar que, caso alguma chamada não obtenha sucesso, toda a operação deve ser repetida, já que é imprescindível que o número correto


de chamadas concorrentes seja realizado, para que não se tenha um resultado incorreto da avaliação do ambiente em teste.

A Figura 4 também ilustra um experimento realizado entre dois slaves. Entretanto, neste caso, ocorre um erro no slave ativo; O master comanda o slave passivo a ficar pronto para receber chamadas (START); O slave passivo informa ao master que está apto a receber as chamadas (STATUS-READY); O master comanda o slave ativo a iniciar as chamadas (START), porém, por algum motivo, o slave ativo não consegue iniciar as chamadas e envia ao master um STATUS-NOK; O master então envia ao slave passivo um CANCEL, informando que, por algum motivo, o slave não receberá as chamadas que estava esperando.

ACME Master

ACME Passive Slave

ACME Active Slave

START

STATUS-READY

START

STATUS-OK

Voice flows

STATUS-OK

START

ACME Master

ACME Passive Slave A

ACME Passive Slave B

START

STATUS-READY

STATUS-NOK

STATUS-OK

CANCEL

Figura 3: Slave para slave com sucesso Figura 4: Slave para slave sem sucesso

A Figura 5 ilustra um experimento realizado entre um slave (que neste caso é obrigatoriamente ativo) e um gateway, que pode entregar a chamada em destinos diversos (como, por exemplo, um número de telefone convencional da rede de telefonia pública, um número de um PBX, etc.). Neste caso, o master necessita apenas comandar o slave ativo, logo necessita apenas enviar um START ao slave e esperar por um STATUS-OK, que será recebido caso as chamadas obtenham sucesso. Este tipo de operação é útil, por exemplo, para monitorar a disponibilidade do gateway e sua capacidade de encaminhar chamadas para uma determinada rede.

ACME Master

ACME Active Slave

Asterisk:H.323/SIP and

H.323/PSTN GW

START

STATUS-OK

Voice flows

IVR (PBX, PSTN

or SIP)

Voice flows

Figura 5: Slave para gateway

O ACMEp opera sobre TCP e utiliza por padrão a porta 8000 (configurável). Até o momento nenhum mecanismo de criptografia é utilizado, mas aspectos de segurança estão sendo avaliados para aprimoramentos futuros. Para evitar que um master não autorizado comande qualquer slave, listas de acesso podem ser configuradas em cada slave. Entretanto, a mensagem START utilizada para comandar o registro do


slave é crítica, já que contém senha de autenticação não cifrada. O uso de TLS [Dierks 2006] deve ser suportado para operar com segurança.

4. Experimentos de estresse

O objetivo de um experimento de estresse é determinar a capacidade de um determinado meio. A capacidade é o número máximo de chamadas VoIP simultâneas que podem ser realizadas (com uso de um codec específico, como por exemplo, o G.711), sem que a média do MOS das chamadas (dentro de um intervalo de confiança de tamanho máximo) caia abaixo de um valor mínimo previamente estabelecido. Entenda-se meio como um enlace, uma rede, um sistema ou até mesmo um serviço de telefonia VoIP. A determinação da capacidade de um slave, por exemplo, é um experimento de estresse utilizado para avaliar um hardware e exige que o MOS médio não seja inferior ao MOS máximo obtido em condições ideais. É importante comentar que cada codec possui um MOS máximo que pode ser atingido, dada a degradação inerente causada pela compressão de voz. O G.711, por exemplo, obtém um MOS máximo de 4.41.

4.1. Teste (Test)

Um experimento de estresse é composto por uma série de testes. Cada teste possui um determinado número de chamadas concorrentes. Assim, caso o teste 1 que possui N chamadas simultâneas obtiver um valor médio de MOS igual ou superior ao valor médio de MOS estabelecido, um novo teste (teste 2) é executado. O teste 2 por sua vez, possuirá N + X chamadas simultâneas. Caso o teste 2 atinja resultado maior ou superior ao MOS médio estabelecido, um novo teste (teste 3) é realizado com (N+X)+X chamadas concorrentes. Ou seja, novos testes são executados dinamicamente até que o MOS médio estabelecido seja ultrapassado. O número inicial de chamadas concorrentes (N) e o número de incremento de chamadas (X) são parâmetros configuráveis.

4.2. Bateria (Round)

Ao configurar o MOS médio requerido para o experimento, o usuário também configura um grau de confiança (alvo), que é uma percentagem, por exemplo, 10% ou 20%. O resultado de um teste deve possuir obrigatoriamente um tamanho de intervalo de confiança menor ou igual à percentagem pré-definida do valor médio do intervalo. O valor médio do intervalo é o estimador do MOS médio das chamadas.

Para atingir o intervalo de confiança alvo (target), o teste deve ser executado repetidas vezes. Cada repetição é denominada bateria (ou round), segundo a nomenclatura da ACME. O experimento permite inclusive que um número mínimo de baterias seja estabelecido. Isso é importante para assegurar que testes com poucas chamadas concorrentes não atinjam o intervalo de confiança alvo sem que a média de MOS tenha realmente convergido.

O Quadro 1 ilustra a estrutura de um experimento. São apresentados três testes, sendo que o teste 1 (com 3 chamadas concorrentes) encontra-se expandido, permitindo assim que detalhes relativos às suas cinco baterias sejam visualizados. Este experimento foi configurado para ter um intervalo de confiança alvo de 10 %. Note que o alvo só é atingido na Bateria 5, quando o MOS médio para o teste resulta em 4,08. Ao atingir o alvo, o Teste 2 com 4 chamadas concorrentes é iniciado. É importante destacar que o


MOS médio e o intervalo de confiança é sempre calculado com base em todos os MOS de todas as chamadas realizadas por todas as baterias de um mesmo teste.

Test 1 → 3 Chamadas concorrentes

• Bateria 1 – MOS médio= 4.10, Int. de confiança = 0.81, Alvo= 0.41 (10%)

• Bateria 2 – MOS médio = 4.03, Int. de confiança = 0.71, Alvo = 0.4






Quadro 1: Estrutura do experimento

5. Experimentos periódicos

Existem três tipos básicos de experimentos periódicos, listados a seguir:

1. Experimento de monitoração de disponibilidade (availability experiment): Em intervalos regulares um determinado destino é chamado a fim de monitorar sua disponibilidade. No presente momento, apenas o protocolo H.323 é suportado pela ACME, entretanto, o uso de um gateway H.323/SIP possibilita que destinos SIP sejam monitorados. De forma equivalente, o uso de um gateway para a telefonia convencional possibilita que destinos na RTFC (Rede de Telefonia Fixa Comutada) ou em um PBX (Private Branch eXtension) sejam alcançados, permitindo que o serviço de troca de tráfego com a telefonia convencional seja monitorado. O destino nestes experimentos são normalmente secretárias eletrônicas ou IVRs (Interactive Voice Response), já que estes respondem chamadas automaticamente;

2. Experimento de monitoração de qualidade (quality experiment): Por padrão todo experimento de disponibilidade avalia a qualidade da chamada recebida. A diferença do experimento de qualidade é que ele possibilita a configuração de limiares de alerta. Assim, ao obter medições de qualidade inferiores a um determinado valor, o usuário recebe uma notificação. Os experimentos de disponibilidade e de autenticação só emitem alerta em caso de erro;

3. Experimento de monitoração de autenticação (authentication experiment): Em intervalos regulares o slave tenta se autenticar em um determinado servidor para monitorar se o serviço de autenticação está operando corretamente. Até o presente momento apenas H.323 é suportado.

6. Concorrência de experimentos

Segundo a visão da ACME, os recursos utilizados nos experimentos são os slaves. Após cadastrados na ACME, os slaves podem ser incluídos em sites e ser utilizados por qualquer experimento. Slaves podem, inclusive, ser incluídos paralelamente em mais de um site, contando que os sites dos experimentos não possuam slaves em comum.

A granularidade de concorrência dos experimentos é o teste; assim, dois experimentos A e B podem ser executados concorrentemente e podem possuir slaves ou


até mesmo sites em comum. Entretanto, testes dos experimentos A e B nunca ocorrem simultaneamente, já que a ACME excuta apenas um teste por vez.

A Figura 6 ilustra a máquina de estados de um experimento periódico de qualidade. Ao ser agendado, o experimento entra no estado Scheduled e permanece neste estado até que esteja na hora programada de seu inicio e que não tenha nenhum experimento em sua frente esperando para ser executado. No momento em que seu primeiro teste (no caso de um experimento de qualidade um teste é uma chamada com aferição de qualidade) começa a ser executado, seu estado muda para Running. Findada a execução do teste, o seu estado muda para Ready-OK, caso o MOS obtido seja maior que o limiar crítico estabelecido. Caso o MOS seja inferior ou igual a este limiar, seu estado vai para Ready – Low MOS. Outra possibilidade é que ocorra algum erro e o teste não seja finalizado. Caso um erro esperado ocorra, como por exemplo, indisponibilidade de alcançar o destino, o estado muda para Ready- Can’t connect to host, ou outro estado que representa um erro definido. Em último caso, se um erro indefinido e irreversível ocorrer, o estado muda para Undefined error. O estado do experimento sempre retorna para Running quando o próximo teste deste mesmo experimento é executado. Porém, o estado Undefined error não permite mudança.

...

Scheduled Running *

Ready - OK

Ready – Low MOS

Ready – Can’t connect to host

Ready – Can’t authenticate

Undefined error

Figura 6: Máquina de estados de um experimento de q ualidade

Todos os experimentos possuem máquina de estado similar. Um experimento periódico só termina caso seu estado vá para Undefined error. Já os experimentos de estresse terminam quando o MOS limite é alcançado, quando os slaves disponíveis não estão aptos a incrementar o número de chamadas (pois já chegaram ao limite de sua capacidade) ou, em último caso, quando vão para o estado Undefined error.

A ordem de execução dos experimentos é uma derivação de um esquema Round-Robin de formato circular. Duas listas são mantidas, uma para os experimentos periódicos em estado Ready e outra para os experimentos de estresse em estado Ready. O scheduler (módulo da ACME que gerencia a concorrência) sempre pega o próximo experimento em estado Ready da lista dos experimentos periódicos. Caso esta lista esteja vazia, ele pega o próximo experimento da lista de experimentos de estresse. Este esquema prioriza os experimentos periódicos, pois estes possuem tempo de resposta crítico por monitorarem serviços.

7. Demonstrações

O cenário ilustrado na Figura 7 representa um enlace serial PPP de 500 kbps, interligando dois roteadores Cisco 2500. Os dois slaves presentes no cenário foram configurados para “marcarem” os pacotes IP referentes aos fluxos de voz com DSCP EF [Babiarz 2006], permitindo, assim, que os roteadores pudessem distinguir tais pacotes


“marcados” de outros pacotes referentes ao gerador/refletor de pacotes UDP, utilizado para gerar tráfego concorrente ao tráfego de voz.

Slave 1

Traffic generator

Trafficreflector

Slave 2Voice flows:

G.711

Concurrent traffic:

200 kpbs

500 kpbs PPP link

Priority Queue:320 kbps guaranteed

Figura 7: Cenário do experimento de estresse demonstrativo

O gerador UDP [Leocadio 2000] foi configurado para gerar uma taxa constante de 200 kbps em direção ao refletor. Os roteadores foram configurados para operar uma fila PQ (Priority Queue) [Cisco Systems 2007] com taxa garantida de 320 kbps para os pacotes marcados com DSCP EF (fluxos de voz). O codec utilizado foi o G.711, portanto, o fluxo de cada chamada correspondia à uma taxa aproximada de 80 kpbs no nível de enlace PPP.

Figura 8: Resultado do experimento de estresse demonstrativo

A Figura 8 apresenta o resultado do experimento. A ordenada representa o valor médio de MOS e a abcissa o número de chamadas simultâneas de cada teste. Nota-se que com até quatro chamadas concorrentes o MOS obteve o valor máximo, que é 4.41 para o G.711. A partir da quinta chamada o MOS cai abruptamente e o intervalo de confiança (linhas que cortam a curva do MOS) vai subindo gradativamente. O resultado é esperado, já que a PQ de 320 kpbs só acomoda quatro fluxos de voz de 80 kbps. Este experimento foi configurado com intervalo de confiança alvo de 10%.

O cenário de demonstração dos experimentos periódicos foi montado para testar o fone@RNP [RNP 2007]. Este serviço utiliza uma arquitetura heterogênea baseada nos padrões H.323 e SIP que, além de interconectar os sistemas PBX de uma série de instituições acadêmicas, fornece uma plataforma para utilização de telefones IP e


interconexão com a RTFC. O objetivo da demonstração é monitorar o serviço oferecido na UFRJ e em outra instituição fictícia montada nos moldes exatos de uma instituição participante do fone@RNP, que chamaremos de “Instituição 1”. Como ilustrado na Figura 9, cada instituição monitorada representa um site e possui um slave local. O slave central, por sua vez, representa um terceiro site que interagirá com os sites monitorados.

`

WEB Browser:Agendamento e resultado dos esperimentos

MasterVQCDR Server

ACME VIS SQL Database

HTTP

Slave CentralAsterisk:

H323/SIP GWVoIP/PBX GW

SIP Proxy

PBX

PBX Phone

PSTN Phone

SIPPhone

H.323Phone

Site “UFRJ”

Slave local

Asterisk:H323/SIP GWVoIP/PBX GW

SIP Proxy

PBX

PBX Phone

PSTN Phone

SIPPhone

H.323Phone

Site “Institution 1”

Slave local

H.323 GKH.323 GK

Figura 9: Cenário de experimentos periódicos demonstrativos

Segundo os moldes do fone@RNP, cada instituição possui um gatekeeper H.323 para atender os usuários H.323, um proxy SIP para atender os usuários SIP, e um gateway para interoperação SIP/H.323 e para encaminhamento de chamadas para a RTFC (Rede de Telefonia Fixa Comutada) e PBX.

Seis experimentos periódicos foram montados para cada instituição:

1. SIP Phone: Monitora a disponibilidade de serviço SIP executando chamadas regulares para um softphone SIP configurado com respostas automáticas (auto-answer). O gateway converte a chamada H.323 do pelo slave central para SIP;

2. H.323 Phone: Monitora a disponibilidade de serviço H.323 executando chamadas regulares para o slave local;

3. PBX Phone: Monitora o encaminhamento de chamadas para o PBX executando chamadas regulares para um IVR do PBX. O gateway encaminha a chamada H.323 realizada pelo slave central ao PBX;

4. PSTN Phone: Monitora o encaminhamento de chamadas para a RTFC executando chamadas regulares para um IVR da RTFC (um serviço 0800). O gateway encaminha a chamada H.323 realizada pelo slave central à RTFC;

5. H.323 Authentication: Monitora a autenticação do ambiente H.323 através do processo de autenticações periódicas do slave local ao gatekeeper H.323;

6. Quality: Monitora a qualidade das chamadas realizadas periodicamente entre o slave central e o slave local.

Figura 10 apresenta o painel de monitoração da ACME: experimentos com status positivo são mostrados em verde; experimentos problemáticos são mostrados em


vermelho, indicando uma falha no sistema monitorado; já os experimentos que apresentam condições críticas, como um MOS inferior ao estabelecido como aceitável, são apresentados em amarelo. A configuração do painel permite que indicadores amarelos e vermelhos disparem alertas aos operadores do sistema via e-mail.

Figura 10: Painel de monitoração da ACME

8. Conclusões e trabalhos futuros

Uma ferramenta automatizada de geração e avaliação de qualidade de chamadas VoIP foi apresentada e sua eficácia e versatilidade foram demonstradas em ambientes reais.

Para a classe de experimentos de estresse, foi mostrado como um enlace configurado com mecanismos específicos de gerenciamento de filas pode ser analisado em termos de chamadas concomitantes. O uso de execução dinâmica e automática de chamadas e a geração de resultados com gráficos e intervalo de confiança é um diferencial entre as ferramentas de avaliação de qualidade de voz, permitindo que a determinação da capacidade de sistemas VoIP possa ser avaliada com precisão.

Para a classe de experimentos periódicos, foi mostrado como a ACME pode ser utilizada na monitoração do serviço fone@RNP, um ambiente complexo e heterogêneo que opera sobre SIP e H.323, integrando sistemas de telefonia de dezenas instituições.

A ACME vem sendo também utilizada com sucesso em cursos na UFRJ e, no futuro, planeja-se seu uso no monitoramento do serviço fone@RNP. Outro grande potencial da ferramenta é o seu uso em pesquisas. A funcionalidade de determinação de capacidade permitirá, entre outros estudos, a avaliação de ambientes sem fio com uso de variados mecanismos de QoS (Quality of Service), bem como a análise de políticas de gerência de filas em roteadores objetivando maximizar a qualidade de chamadas VoIP.

O suporte ao TLS no protocolo ACMEp é alvo de desenvolvimentos futuros, já que o transporte seguro eliminará vulnerabilidades na comunicação entre master e slave. O suporte ao protocolo SIP nativo já está em desenvolvimento, o que permitirá que a verificação de disponibilidade de elementos SIP não dependa de gateways de sinalização.

Referências

Babiarz, J., Chan, K., Baker, F (2006). Configuration Guidelines for DiffServ Service Classes, IETF. RFC 4594.


Brix, BrixCall. (2007). <http://www.brixnet.com/products/ >. Acesso dez. 2007.

Cisco Systems. (2007). VoIP over PPP Links with Quality of Service. <http://www.cisco.com/warp/public/788/voice-qos/voip-mlppp.html>. Acesso em dez. 2007.

Dierks, T., Rescorla E. (2006). The Transport Layer Security (TLS) Protocol Version 1.1. IETF. RFC 4346.

Empirix. (2007). VoIP and IMS Hammer Call Analyzer. <http://www.empirix.com/products-services/v-hca.asp>. Acesso dez. 2007.

ETSI TS 101 329-5 v1.1.2.(2002). Telecommunications and Internet Protocol Harmonization Over Networks Release 3, End-to-end Quality of Service in TIPHON systems; Part 5: Quality of Service (QoS) measurement methodologies.

ETSI TS 102 024-5 v4.1.1. (2002). Telecommunications and Internet Protocol Harmonization Over Networks Release 4, End-to-end Quality of Service in TIPHON systems; Part 5: Quality of Service (QoS) measurement methodologies.

GnuGK. The GNU Gatekeeper. (2007). <http://www.gnugk.org/>. Acesso em dez. 2007.

ITU-T G.107. (2003). The E-Model, a computational model for use in trans. planning.

ITU-T P.800. (1996). Methods for subjective determination of transmission quality.

Leocadio, M. A. P., Rodrigues, P. H. A. (2000). Uma Ferramenta para Geração de Tráfego e Medição em Ambiente de Alto Desempenho. In: XVIII. SBRC.

Lustosa, L.C.G., Carvalho, L.S.G., Rodrigues, P.H.A., Mota, S. E. (2004). Utilização do Modelo E para avaliação da qualidade da fala em sistemas de comunicação baseados em voz sobre IP, in: Anais do XXII SBRC.

Lustosa, L.C.G., Rodrigues, P.H.A., David, F., Quinelato, G. D. (2005a). Arquitetura de Monitoração de Qualidade de Chamadas Telefônicas IP, XXIII SBRC.

Lustosa, L.C.G., Rodrigues, P.H.A., David, F., Quinelato, G. D. (2005b) VQuality: Uma Biblioteca Multiplataforma para Avaliação de Qualidade de Chamadas Telefônicas IP, XXIII SBRC.

RNP. (2007). fone@RNP. <http://www.rnp.br/voip/>. Acesso em dez. 2007.

Solarwinds. (2007). VoIP Monitor. <http://www.solarwinds.com/products>. Acesso dez. 2007.

Telchemy. (2007). SQmon. <http://www.telchemy.com/products.html>. Acesso dez. 2007.


acme: uma ferramenta automatizada para geração e · pdf fileresumo. acme, uma...

Documents